#ubuntu-arm 2009-01-27
<doko_> somebody aware of the hal install failure on armel? causes build failures on the buildds (openjdk-6)
<ogra> install failure ?
<ogra> it installed fine yesterday here in a local bootstrap
<doko_> ogra: https://edge.launchpad.net/ubuntu/+source/openjdk-6/6b14-0ubuntu10/+build/848818
<ogra> thats udev, no ?
<ogra> cat: /sys/kernel/uevent_seqnum: No such file or directory
<ogra> invoke-rc.d: initscript udev, action "restart" failed.
<ogra> dpkg: error processing udev (--configure):
<ogra>  subprocess post-installation script returned error exit status 1
<doko_> maybe
<ogra> well, i pinged keybuk ...
<suihkulokki> ogra: that'n nutty, buildd's shouldn't be installing hal/udev to the build chroot.
<suihkulokki> ogra: check which package is pulling them in
<ogra> suihkulokki, its already fixed in udev
<ogra> udev shouldnt start if installed in a chroot
<ogra> there are packages that depend on stuff that in turn depends on hal
<ogra> so you cant really avoid things like that
<ogra> packages like hal, dbus and udev need special casing
<suihkulokki> no
<Stskeeps> shouldn't they "just" fake invoke-rc.d and start-stop-daemon? :P
<ogra> all of xorg depends on hal
<suihkulokki> you build-depend on libhal-dev libdus-dev etc
<ogra> Stskeeps, thats what they do, but udev had a bad grep in the posinst before
<suihkulokki> and none of those -dev packages should pull their respective daemon in
<ogra> feel free to look at the build log
<ogra> but i know the fix got into udev already so that might be moot
<ogra> http://launchpadlibrarian.net/21658731/buildlog_ubuntu-jaunty-armel.openjdk-6_6b14-0ubuntu10_FAILEDTOBUILD.txt.gz
<ogra> https://lists.ubuntu.com/archives/jaunty-changes/2009-January/003929.html is the fix
<suihkulokki> ogra: that's fixing the symptom, not fixing the root of the problem - ie. "why is udev getting installed in the first place"
<ogra> probably becuse the package needs a running X env ... we have a bunch of packages that need xvfb for example ...
<ogra> dont ask me, i'm neither maintaining the buildds, nor maintain the openjdk package nor am i resonsible for udev :)
<ogra> and the udev maintainer obviously considered that fis as appropriate
<persia> suihkulokki, Probably a side effect of recommends-by-default
<suihkulokki> persia: ...which is why recommends-by-default is not used on buildd's ;)
<suihkulokki> at least, on debian that is
<ogra> beyond fixing that particular buildd issue it will also fix chroot building in general (in case you dont have sysfs mounted in your chroot during bootstrapping)
<ogra> well, ubuntu doesnt use dak :)
<persia> suihkulokki, Heh.  Well, that's one way to fix it.
<persia> Personally, I'd rather it did, because many maintainers seem to build packages on their personal local systems, with all sorts of random stuff installed, and certainly recommends.
<persia> Mind you, this is getting *lots* better, but still.
<suihkulokki> ogra: I don't claim that udev bug was not worth fixing - merely that there is most likely still a unnecessary depends somewhere
<suihkulokki> but if you don't care, whatever.
<ogra> suihkulokki, well, ask doko_ about it ... :)
<ogra> he was bringing it up since he tried to build openjdk
<ogra> no idea what pulls it in
<doko_> suihkulokki: pulseaudio sucks it in
<persia> And pulse needs to do device analysis if the daemon is running.
<persia> doko_, Why does OpenJDK need both libpulse-dev and pulseaudio to build?  Would libpulse-dev itself not be sufficient?
<persia> Is this for the test suite?
<doko_> AC_DEFUN([FIND_PULSEAUDIO],
<doko_> [
<doko_>   AC_PATH_PROG(PULSEAUDIO_BIN, "pulseaudio")
<doko_>   if test -z "${PULSEAUDIO_BIN}"; then
<doko_>     AC_MSG_ERROR("pulseaudio was not found.")
<doko_>   fi
<doko_>   AC_SUBST(PULSEAUDIO_BIN)
<doko_> ])
<persia> Blech.  No helping it then, really.
 * suihkulokki grumbles
<suihkulokki> 1) i would still check if that configure check can be fixed
<suihkulokki> 2) if pulseaudio does really need to depend on hal
<suihkulokki> then again, if the build system is pulling in recommends, this ranting is completly moot
<ogra> there are more packages like that
<ogra> all the stuff that uses xvfb for their test suites will run into the same now that xorg hard depends on hal
<ogra> i think you should start to consider it a common case that udev *might* show up in buildd chroots
<suihkulokki> that depends on how much you care about quality and bloat
<ogra> well, self tests can improve the quality ... so i'D rather call it a philosophical thing :)
<suihkulokki> I doubt even with current xorg xvfb would really hard-depend on hal
<suihkulokki> so in other words, someone took the lazy route
<ogra> xvbf runs X
<ogra> and X needs hal to run
<ogra> *vfb
 * ogra humms "times are changin ..."
 * suihkulokki humms unverified bullshit
<ogra> heh
<ogra> well, fix X to not use hal ... but i doubt upstream will accept any patches that revert this behavior ... they made quite a hard cut and dropped much backwards compatibility with this release
<suihkulokki> you are confusing the dependency on libhal and dependency on hald
<ogra> xorg moaning loudly if hald doesnt run doesnt help though :) but right, it doesnt have a dep on hal itself
<NCommander> hola
<ScriptRipper> NCommander: hi
<NCommander> hey ScriptRipper
<ScriptRipper> Did you think about the e-mail for the apt repo layout?
<ScriptRipper> NCommander: your last comment was: i think about it under the shower, if i remeber correctly :)
<ScriptRipper> NCommander: what did your shower say :)
<NCommander> ScriptRipper, "ack, it burns"
#ubuntu-arm 2009-01-29
<ScriptRipper> persia, ogra: how far did you come with the new kernel?
 * persia doesn't tend to do much kernel stuff
<ScriptRipper> persia, ogra: I had a whish for you: a patch for a DVB-USB Frontend patch that seems not to be in the kernel officially
<ogra> ScriptRipper, we were more focusing on images than on kernels atm ... (kernels are done by the ubuntu kernel team and in the works)
<ogra> ScriptRipper, thats something that can be discussed if linux-omap is merged ... currently the focus is to get the existing debian arches proper
<ogra> linux-omap will likely take another week or so
<ogra> (have a look at http://cdimage.ubuntu.com/ports/daily/current/ ;) we have our first iso (no kernels on it yet))
<ScriptRipper> i can also build a kernel myself, no problem. this is not my first time.
<ScriptRipper> i would just need the sources with the build kernel..
<ogra> just use the linux-omap tree
<ScriptRipper> ok
 * ogra twiddles thumbs ... 
<ogra> ... watching d-i ....
#ubuntu-arm 2009-01-30
<ogra> ScriptRipper, so i found the missing bit that caused mouse/kbd not to work, CONFIG_INPUT_EVDEV is missing in the kernel, the new hal infrastructure for X needs that
<ogra> next kernel upload will have it
<ScriptRipper> aha.
<ScriptRipper> that was the reason why, I have to use 2.6.27 atm - right? you talk about 2.6.28?
<ogra> yes
<ogra> next upload will be there latest by monday
<ScriptRipper> i was a bit confused, because i have mouse and keyboard running - ...
<ScriptRipper> first
<ScriptRipper> ok.
#ubuntu-arm 2010-02-01
<cwillu_at_work> what's new in arm land?
#ubuntu-arm 2010-02-02
* 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.ub
* 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 | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | build probs with your packages in lucid ? see https://wiki.ub
* 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 | 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
<ogra> sorry for the noise
<asac> armin76: there?
<NCommander> armin76, ping?
<asac> ok ;)
<NCommander> armin76, mind if I PM you?
<asac> dyfet: https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList#High/Medium Prority Packages
<asac> dyfet: http://launchpadlibrarian.net/36400628/glib2.0_2.23.0-1ubuntu1_2.23.0-1ubuntu2.diff.gz
<NCommander> ugh
 * NCommander grumbles
<NCommander> xchat ates its configuration :-/
<NCommander> *ate
<asac> dyfet: http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
<asac> dyfet: http://launchpadlibrarian.net/38628422/mono_2.4.3%2Bdfsg-1_2.4.3%2Bdfsg-1ubuntu1.diff.gz
<Donno> Is it possible to mount the 9.10 image for dove board? If so how, i tried loop but requires a file system
<eggonlea> hi, NCommander. Karmic seems costs more memory than Jaunty because of larger library dependencies and more daemons. Do you have any analysis on the memory footprint, especially for the coming Lucid?
<NCommander> eggonlea, no, sorry :-/
<eggonlea> Donno, I don't know how to deal with livecd, but you could do that with alternative image absolutely.
<Donno> ah, thought it was a hdd image or something
<eggonlea> NCommander, thanks! do you have any suggestion on that if we have to start optimizing the memory footprint?
<eggonlea> Donno, it's just a image which could be written to USB disk, SD card or HDD.
<Donno> ah
<eggonlea> "dd if=the.image of=/dev/sdx" should work fine
<Donno> ah thanks
<armin76> asac: pong, but i'm leaving soon for work
<armin76> asac: i'm here
<persia> I've not seen traffic from asac for nearly 12 hours, and have a suspicion it may be 4-5 more before he's responding.  I suspect he'll get the pings in backscroll :)
<armin76> persia: he hides from me :P
<persia> armin76: Quite possibly :)
<ogra> davidm, http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-6877-27588-28309
<ogra> dmart, ^^^ seen that ?
<asac> armin76: hi ... did ncommander get in touch with you?=
<asac> persia: ffox 36 for jaunty/karmic here: https://launchpad.net/~asac/+archive/armel1/
<dmart> ogra, looks interesting
<dmart> lucid performance looks very similar to Karmic (the differences are small enough that they may not be statistically significant, but it depends on the workings of the benchmark)
<dmart> The sheevaplug comparison looks interesting... maybe differences in cache configuration and memory system are causing some of the performance differences.
<dmart> These benchmarks don't look like they necessarily tell us much about how the system performs when thrashing (which dominates boot and app launch times)
<ogra> asac, http://paste.ubuntu.com/367714/
<armin76> asac: nope, he didn't
<armin76> NCommander: pong, no need to ask for pm :)
<ogra> asac, http://paste.ubuntu.com/367714/
<armin76> asac: fyi -fno-tree-sink fixed my failures on gcc-4.3 as well
<armin76> on armv7a, that is, haven't tried armv5te but i guess it still fails
<asac_> armin76: nice
<armin76> btw, not sure if you guys know, but qualcomm snapdragon(the one in the nexus one) has vfp
<ogra> lool, did you find a solution to the versatile vs qemu probs in lucid ?
<ogra> i just noticed i see the same issue you mentioned, no output at all
<ogra> lool, [    1.773302] CLCD: unknown LCD panel ID 0x00001000, using VGA
<ogra> [    1.778543] CLCD: Versatile hardware, VGA display
<ogra> here it hangs for me
<lool> ogra: I didn't look further
<ogra> lool, well, i just gave apw my config i used for the rotstock image, that should at least boot but might miss stuff
<ogra> so we should have a starting point
<lool> ogra: But it's another version, right?
<ogra> its .31, yes
<ogra> http://people.canonical.com/~ogra/arm/qemu/vmlinuz-2.6.31-rc3versatile1-cortex-a8.config
<lool> Mine is 2.6.31 too and works, but lucid versatile is .32
<lool> I intended to rebase it, but didn't have the time
<ogra> yes, but has a ton of options enabled
<ogra> options the .31 versions didnt have
<ogra> specificaly framebuffer stuff and the like
<ogra> i suspect the issue lies there somewhere
<ogra> since it at least starts for me if i use -nographic ...
<ogra> but then hangs at the CLCD step
<ogra> without -nographic there is no output at all
<ogra> its a bit sad since i just wrote a function for rootstock to make use of the deb from ports.u.c
<ogra> just to find it hangs :P
#ubuntu-arm 2010-02-03
<juan__> hy...I am having troubles building a device driver for an ubuntu/arm platform...can anybody help me?
<zumbi> juan__: what problem?
<juan__> I tried to get the package of the ubuntu headers...but it is not in the repositories...
<juan__> then I tried to compile the ubuntu kernel from scratch...but it claims to have many errors..
<zumbi> juan__: what are you doing? what commands do you type?
<juan__> make dep
<juan__> make zImage
<juan__> those worked fine
<juan__> and then "make modules"
<zumbi> juan__: maybe you need to use debuild or friends or kernel-package (make-kpkg)
<lool> juan__: What's your kernel tree?
<juan__> the latest ubuntu jaunty..
<lool> juan__: How did you get it?  apt-get source?  git?
<lool> juan__: For which platform are you building?
<juan__> i am trying the make-kpkg...but it is asking the same questions that the "make oldconfig" (I forgot to say I used that before the other commands)
<juan__> 1) git  2)arm-cortexa8
<lool> I actually don't think you want to make-kpkg
<lool> What's your target board?
<juan__> a beagleboard..
<lool> I don't think the jaunty git tree supports beagleboard
<lool> Recent upstream git trees have basic support for beagleboard (I'm told) but I only ever build working kernels from upstream linux-omap tree
<juan__> the system is running indeed... I got it working using a tool called rootfs
<lool> Never heard of that one; so it wasn't "rootstock"?
<lool> juan__: Are you building natively, or cross-compiling?
<juan__> sorry...I mixed names...its rootstock..you are right..
<juan__> cross-compiling...
<lool> juan__: So I wouldn't recommend make-kpkg, nor using Ubuntu git trees for the task you're trying to achieve: the Ubuntu kernel tree has special expectations such as ABI files, udebs, specific common config helpers etc.
<lool> It does support cross-compiling though
<lool> Also, I wouldn't recommend basing of ubuntu-januty.git
<lool> This is old and it's based of torvalds' tree, not linux-omap
<juan__> I already have a compiler setup in the beagleboard...however I decided to go for cross-compiling because I just couldnt get the headers
<lool> For beagleboard, you can use prebuilt binary kernels which are provided by Robert Nelson IIRC
<lool> Or you can build your own
<lool> You don't need the headers to cross-compile a kernel
<lool> You just need a cross-toolchain and the kernel source
<juan__> I know..but I need them to build the device driver
<lool> juan__: Ok; so you have two options: either copy your driver into your kernel tree and built everything in there
<lool> (kernel + modules)
<lool> Or build your own kernel + modules and install the kernel headers, then build your driver against that
<juan__> do you think the rest of the system would work fine if i change the kernel?
<lool> I don't know which kernel you use; I got most of the devices working with a linux-omap git tree, so I guess it would
<lool> It is however unlikely you will get your modules to work if you build them against a different kernel than the one you're currently running...
<juan__> ok, I will change the kernel to see what happens and if its ok I will build the device driver for that kernel
<juan__> thanks for the help!
<xranby> quick porting question   if i have ASM code like   ldmia sp!,{r0,r1,r2,r3,lr,pc}    that fails to compile using lucid thumb2       can this be simply replaced with pop {r0,r1,r2,r3,lr,pc}      ?
<ogra> persia, https://wiki.ubuntu.com/ARM/BuildEABIChroot
<persia> ogra: Thanks.
#ubuntu-arm 2010-02-04
<eggonlea> hi, any tips to solve the "sudo: must be setuid root" issue when running "sudo" command in a chroot+qemu-arm-static environment?
 * persia tests
<persia> Well, it doesn't happen in my lucid armel chroot (on amd64), so I wonder if there is some other factor involved.
<persia> What does `ls -l /usr/bin/sudo` show?
<eggonlea> it's of correct attribute
<persia> -rswr-xr-x ?
<eggonlea> -rwsr-xr-x 2 root root 98880 Jan 29 15:29 /usr/bin/sudo
<eggonlea> the problem, I think, is in /usr/bin/qemu-arm-static
<eggonlea> is it?
<persia> Hrm.  I saw this before when the rootfs data had been copied in and out of a FAT32 filesystem, but that's not your issue.]
<persia> Well, I'd agree, except that I don't get that message :)
<persia> How did you construct your chroot?
<eggonlea> build-arm-chroot lucid
<eggonlea> I chroot this arm rootfs in a x86 PC
<eggonlea> so "sudo" after "chroot" is executed via qemu-arm-static actually
<persia> Indeed.
<persia> Looking at build-arm-chroot, I don't know of any reason that command wouldn't build the chroot you expect.
<eggonlea> so, do you mean you could run sudo command correctly in such a chroot env?
<persia> I'm on amd64.  Are you on i386?  I wonder if that might be a difference.
<eggonlea> y
<eggonlea> I'm running Karmic on i386
<persia> In that case, I'm inclined to agree with you that it's qemu-arm-static, as that seems to have been changed between karmic and lucid.
<eggonlea> I tried chroot into an "installed arm rootfs from livecd" as well. same error.
<persia> build-arm-chroot is the same.
<eggonlea> so I don't think it's caused by build-arm-chroot.
<persia> Neither I, as my chroot is also created by build-arm-chroot (albeit embedded from another script)
<persia> Anyone else using build-arm-chroot with Karmic?  Do you get the error eggonlea mentions?
<eggonlea> persia, what's your Ubuntu version on amd64?
<persia> lucid
<persia> Upgraded just a few hours back.
<persia> I don't recommend this for production use unless you're prepared to get two pieces when it breaks, but it's a good way to check to make sure one's preferred bugs get fixed.
 * eggonlea testing in Lucid/vmware
<persia> Now there's an idea!
<persia> If you see a difference, file a bug clearly indicating that it doesn't work in karmic and it does work in Lucid.  I'm not sure we can get an update, but a backport is likely possible if a few people can test.
 * eggonlea hates the slow network...
<persia> Indeed.
<eggonlea> same error in lucid/vmware + build-arm-chroot/qemu-arm-static
<persia> Very odd.  I wonder why I don't get the error.
<persia> Please file a bug about this (`ubuntu-bug qemu-kvm`)
<eggonlea> do you have i386 host?
<eggonlea> ok
<persia> I don't.  Just amd64.
<eggonlea> bug filed.
<eggonlea> thanks for your kindness.
<lool> persia: Great to see qemu-arm-static support in ubuntu-dev-scripts!  You might want to test for presence of build-arm-chroot instead of checking whether the arch is either i386 or amd64 (error would then be "you need the qemu-arm-static package..." and you could use a suggests instead of recommends); BTW the package just got renamed to qemu-kvm-extras-static
<dmart> asac: hi
<persia> lool: I did in mk-sbuild-lv.  I'm not as sure how to do that with pbuilder-dist.  I'd appreciate a hand if you have any ideas.
<lool> persia: Sure
<lool> persia: I thought you implemented that though?
<persia> python != shell :)
<persia> Plus, the logic in pbuilder-dist is particularly opaque to me.
<persia> (plus I don't use pbuilder, which makes verification interesting)
<lool> persia: Sorry, to clarify: you're more confortable writing shell than python and you would prefer me to improve the logic in pbuilder-dist; correct?
<lool> dmart: asac is travelling in the west coast; might be easier to email him
<persia> lool: please :)
<dmart> lool: I did... not urgent anyway. Thanks
<asac> dmart: hi
<dmart> Oh, hi there
<asac> what can i do ;)?
<dmart> how's the sprint?
<StevenK> lool: He isn't travelling, he's at the sprint, and has been for 4 days
<asac> quite good ... some crisis here and there ;) ... but we seem to have a good new lead on dove
<asac> will know more soon
<lool> StevenK: He is not at home, so he is on travel for work, hence travelling; sorry if my English explanations suck, but the effect is the same   :-)
 * persia blames the awkwardnesses of English spelling and grammar
<dmart> at least it's not C++ grammar
<dmart> :P
<StevenK> Haha
<persia> At least that's documented in a single way :)
 * StevenK laments his lack of C++ to make a joke that builds on dmart's joke
<lool> C++?  haha
<asac> dmart: wonder ... could you add examples or give pointers how to properly do the "mov" fixes for thumb2
<asac> ?
<asac> would like to get the thumb2 list down a bit more this week
<dmart> I had some thoughts about that...  did you get a chance to look at the stuff on https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
<dmart> It still rather incomplete, but progressing gradually.
<dmart> I've tried to keep the amount of extra information down, but it may still be quite indigestible to a newcomer.
<dmart> I was thinking maybe we should schedule a sort of mini-sprint with some mobile team guys sometime next week... the best way to get people up to speed may be for everyone to pick up a package and try to work out how to fix it... then watch the discussion on IRC.
<dmart> Does that sound like a good idea?
<asac> dmart: no ... didnt know that page exists
 * asac checks
<asac> looks like a good start
<asac> will check that
<asac> thanks
<asac> dmart: ^
<asac> dmart: yes. i like the idea of making porting sessions
<asac> i think we fixed almost all swp ones now
<asac> (boost upload pending)
<asac> so mov is the most pressing one left i think
<dmart> Yes... particularly since these don't generally show up as ftbfs, we need to be more careful.
<dmart> OK; I'll probably try and flesh out the missing bits of that wiki page by early next week and we can discuss the way forward at the ubuntu-mobile IRC meeiting.
<dmart> asac: ^ I was trying to look at the evolution-data-server update to help sanity-check, but looking in debian/patches I couldn't find the new patches described in the update.
<dmart> Should I see the patches after apt-get source, or do I actually need to build the package (or look in bzr etc.)
<asac> dmart: i also committed it to bzr, yes.
<asac> dmart: you couldnt find the patches?
<asac> hmm
<asac> guess i messed that
<asac> darn ;)
<dmart> I think I have the right package version; debian/changelog mentions the patches
<dmart> I tried a build anyway... it hasn't fallen over yet, but it's not finished...
<asac> yes
<asac> i think i failed to add it to bzr
<asac> darn
<asac> sigh ... i knew i should have uploaded without doing bzr first
<asac> guess i have to redo it
 * asac hopes he still has the build tree somewhere
<persia> As far as I can tell, if one uploads whilst ignoring bzr, automated systems do the right thing.
<asac> good still have it in a porter bux
<asac> persia: i remembered seb wanting me to commit it
<asac> so i wanted to be nice
 * asac goes and redoes
<lool> asac: You might have it in your checkout still
<lool> or in the package itself
<lool> Ah no
<lool> Your debdiff is definitely empty
<asac> i did the checkout in /tmp/ ;)
<asac> but i found it on the porter machine :-P
<asac> \o/
<asac> dmart: you can check boost1.40
<dmart> ok... I'll try and take a look, probably tomorrow.
<asac> yes
<asac> make more sense
<asac> dmart: check boost1.40
<asac> i think thats uploaded ;)
<dmart> ok, will do
<Marrs> hi all, I'm looking for some information about running openjdk on ARM, does anybody here have links to some info on this (are there binary packages available for it, etc..)?
<lool> Marrs: https://launchpad.net/ubuntu/+source/openjdk-6
<lool> Marrs: The latest lucid version is still building on armel, but yes, there are usually binaries available for armel
<persia> There's been a couple reports about some code paths causing VM issues, so heavy testing and reporting of any issues would be very welcome.
<Marrs> ideally, I'm looking for a stable binary release, so that would be the karmik one?
<Marrs> karmic that is :)
<Marrs> persia: I'm definitely going to try to kick its tires :)
<persia> karmic is a stable binary release, but if you find issues, those are easier to fix in lucid (and moreso if previously verified in lucid).
<persia> I'd recommend starting with karmic, and maybe testing against lucid in a chroot if you encounter issues.
<Marrs> persia: understood
<Marrs> btw, I'm not so experienced in the ARM architecture, I'm more of a Java guy, could you take a look at this ARM based board and tell me if you think it will run openjdk? (looking up link now..)
<persia> Better question is whether it can run Ubuntu, and which releases :)
<persia> Running OpenJDK is mostly a side-effect of that.
<Marrs> fair enough... supplier says it can run ubuntu, I have yet to find out which version, but this is the board: http://www.msc-ge.com/de/produkte/com/exm32/3640-www.html
<Marrs> whoops, that was the german page, hit the english flag in the top right corner for an instant translation ;)
<persia> Deutsh ist also gut.
 * persia can't spell today
<Marrs> ;) ok
<persia> I'd recommend against this one.  I think it can run Jaunty with a custom kernel, but it wouldn't be able to run karmic or lucid.
<Marrs> ouch :(
<Marrs> what's the main problem?
<Marrs> or, what type of board should I look for
<persia> You want something that can handle the ARMv7 ISA.
<persia> So, if looking at something using an i.MX processor, you'll want at least the i.MX51.
<persia> There's also stuff from other vendors, of course :)
<Marrs> ok
<Marrs> if you have any links to a board you could recommend, that would be welcome
<lool> Marrs: The boards which are officially supported in Ubuntu kernels aren't that cheap or common, but it's improving quickly; popular boards around here are OMAP 35xx or 34xx based boards e.g. beagleboard
<lool> beagleboard is probably the one we get the most pinged about
<Marrs> thanks
<Marrs> I'll look for those and see if we can use them
<armin76> lool: +available
#ubuntu-arm 2010-02-05
<who_> I just tried to build a Lucid rootfs with rootstock but it doesn't seem to work when I try and boot it in qemu. rootstock didn't look to finish cleanly but there wasn't a good error message - I dug the image, rootfs and log out of the tmp directory. I was using debotstrap from Karmic, but I got the latest rootstock from launchpad and ran the script locally. Is it surprising it didn't work, or is there something curious going on?
<who_> i.e, is this a bug I should try and report, or just something that would be expected this early on in the release cycle...
<who_> Oh, and while I'm here: does anyone else get keyboard and mouse working in X when booting a graphical rootfs in qemu? I don't, and have to ssh in in order to do anything - is that also a bug?
<ogra> who_, the karmic rootstock cant build lucid yet, it needs the patch from http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/31
<who_> ogra: I used rootstock from trunk in LP: would that have had the patch?
<ogra> yes, that should have it but is in active development atm, i havent tried to build anything with it under karmic
<ogra> it works under lucid
<who_> (i.e revision 42)
<who_> ogra: so would my best bet be to use rootstock revision 31? Are you interested in any bug reports atm for using trunk rootstock on karmic?
<ogra> sure, i might want to backport it, but dont expect them to be high prio atm :)
<ogra> rev31 should definately work
<rcn-ee> ogra, just a note rootstock is failing (revision 42 just ran) with --dist lucid  "mount: mount point /dev/pts does not exist" i'm guessing the verstaile kernel is missing CONFIG_DEVTMPFS same bug i ran into with the beagle kernel on karmic -> lucid..
<ogra> rcn-ee, that shouldnt be an issue, its just a warning
<ogra> there is a patch already in the code to use the versatile kernel from the archive under lucid, sadly the kernel package needs fixing first (doesnt boot at all)
<rcn-ee> i was thinking that too, since it worked a week ago, not sure why rootstock is dying shortly after...
<ogra> well, i'm currently actively developing features in trunk :)
<ogra> might be that they introduce new bugs
<who_> ogra: and about using qemu with X: that's a problem I have with all my rootfs', (ones that work on real hardware...)
<rcn-ee> i saw those, everything looked safe...
<ogra> well, the code surely needs cleanup, i'm currently caring more for shrinking my TODO than having it perfect ... i'll do a deep code review sometime next week
<ogra> btw i plan to add a plugin system that will spit out compete SD card images so you can just use "--board beagle" and will have something that can be dd'ed and booted right away
<ogra> will indeed need people to submit plugins for their HW
<rcn-ee> sounds like a plan, i uploaded the logs here  http://rcn-ee.homeip.net:81/dl/rootstock/  ...  What prompted it, my alpha-2 lucid image got corrupted on rcn-ee.net.... So, I'm going to cheat and dist upgrade karmic and upload that.. ;)
<who_> ogra: that sounds sweet. I will try and do one for IGEPv2
<ogra> who_, sorry, i dont use qemu with any framebuffer so i cant tell much about that, i guess using an initramfs would help though, suspecting the input drivers you need are modules
<who_> ogra: ok, that's a good starting point for me to get googling on :) - I'm a little new to this level of things. Thanks
 * ogra commits todays tasksel tool for the rootstock GUI 
<rcn-ee> that would be cool..  main thing the beagle's need, is the /etc/e2fsck.conf tweak.. (no real time clock battery) well until util-linux considers that not an error..
<who_> final question before I go to bed: Does anyone else find they have a curious bug where, after some unspecified period of time, certain commands stop executing? It's happened to me with a rootfs on SD and one over nfs.
<who_> After some time (different amounts each time) things like ifconfig, sudo, synaptic stop executing, but things like dmesg, top, xterm, still start fine
<ogra> rcn-ee, i convinced the maintainer to look into it, we finally found an x86 box it occured on, that convinced him ;)
<ogra> so it might be fixed
<ogra> s/be/become/
<who_> the system is essentially useless though. If I am connected to a serial terminal I see messages about things being idle 120 seconds...
<rcn-ee> cool the musb port just passed my stress test..., cwillu_at_work, give http://rcn-ee.homeip.net:81/dl/linux-image-2.6.32.7-x7.1_1.0cross_armel.deb a try... (load the beagle at 100% and transfer many gigs..)  make sure "dmesg | grep fifo" returns 5...
<rcn-ee> sweet, thanks for that ogra.. i have a couple atmel boards at work that need the same tweak for debian.. ;)
<ogra> who_, i'D file a bug and attach dmesg etc to it, but note that with karmic only armv6 chips are supported, with lucid we even switched to v7 and thumb2
<who_> ogra: I'll get a dmesg log onto launchpad. This is an OMAP3, so shouldn't be troubled by the change to v7, as I understand it.. right?
<ogra> right
<rcn-ee> who_, are you still on the 2.6.28 kernel with your IGEPv2?
<who_> rcn-ee: yea, but I built their latest kernel tonight. Will try it out on the board when I get in tomorrow :)
 * ogra needs to go now
<who_> Thanks for the help, ogra :)
<rcn-ee> who_, if you boot lucid, make sure you enable CONFIG_ARM_ERRATA_430973
<who_> rcn-ee: thanks. there's no way I'd have got that on my own :)
<rcn-ee> who_, neither me... spent about 2 weeks with dave martin debuggin that one...
<who_> rcn-ee: is there any ubuntu-on-igep information around other than what's on the igep wiki?
<rcn-ee> well you can follow my beagleboard wiki on elinux... but the kernel is still external.. i don't have that board, but it should be pretty easy to integrate into the kernel builds i already do...
<who_> rcn-ee: the thing that struck me just now when I looked at the BeagleBoardUbuntu page was that there seems to be a better system for getting SGX video acceleration working on Ubuntu...
<rcn-ee> also you need CONFIG_DEVTMPFS, for lucid  ( i couldn't get the beagle to mount with out it..) however it didn't get added to mainline till 2.6.32...
<who_> rcn-ee: again. thanks :)
<ogra> it should mount thought
<ogra> just spill an error in initramfs
<ogra> there are several safety nets in initramfs's init to make sure it still mounts
<rcn-ee> I'll re-test it, but it errored but never recovered...  we still don't use an initramfs on the beagle..
<who_> and there's no initramfs for IGEPv2 either...
<ogra> you should start to ;)
<rcn-ee> i know.. ;)  on my list too...
<ogra> its just an update-initramfs away :)
<ogra> (and a mkimage indeed :) )
<ogra> anyway, really off now
<who_> bye
<rcn-ee> now that we've transitioned to u-boot.scr scripts it's easy to tweak too...
<who_> rcn-ee: can you tell me a tiny bit about the 'build_sgx_module.sh' script that you've got
<rcn-ee> sure i can, what question do you have..
<who_> (I'm looking at http://elinux.org/BeagleBoardUbuntu)
<rcn-ee> 2.6-stable.. branch i'm hoping..
<who_> rcn-ee: how does it differ from what I'd get if I followed the 'standard' instructions on the TI grpahics SDK?
<rcn-ee> who_, it's very similar now (specially with the current revision) but it isn't tied to a specific TI kernel.. which in the past has been a big problem..
<who_> rcn-ee: the reason for my questions is that I'd like to be able to have video acceleration on the IGEPv2 with Ubuntu. All of the docs from ISEE (the board manufacture) are about using it on their poky system with their kernel
<rcn-ee> who_, very similar, i actually used Angstrom's (poky is based off) instructions to originally write the script...
<who_> rcn-ee: okay, I'll take a look at it when I'm not about to go to bed and see if I can make enough sense of it to use it for my IGEP :)
<who_> rcn-ee: could you just explain this sentence a bit: "Use the "build_sgx_module.sh" script in 2.6-stable, module source is now in the *.bin " - does that mean "TI now provide the module source in their .bin file so we can build the modules with any kernel we like"?
<rcn-ee> Yeah, with the latest version TI moved the 'external' gpl modules into their SDK.. (they didn't take bug reports since it was external)  so now you need the SDK to build the kernel modules, before i actually build them on my chroots at the same time as the *.deb files...
<rcn-ee> it's kinda clugy for ubuntu/debian but users now have to build the kernel modules on their own...  (too many pages of license stuff and not enough time for me..)
<rcn-ee> but as long as you have the correct things enabled, you can build it on any 'dss2' enabled kernel...
<who_> rcn-ee: okay I think I understand. unless I'm using the exact kernel that ISEE used, I'm not likely to have much luck using the modules (binary) they are shipping, right? (they provide omaplfb.ko and pvrsrvkm.ko)
<rcn-ee> who_, that is correct...  and those two modules are pretty easy to generate once you have the sdk anyways...  just use the script as reference, and you'll get it...
<who_> but if I am using their kernel (and there aren;t many reasons I can see right now not too..) I should be able to skip the module compilation step and jump to http://elinux.org/BeagleBoardUbuntu#Startup_Script and follow from there?
<rcn-ee> yeap, you can just use theirs...
<rcn-ee> any chance did they have a version on them?
<who_> rcn-ee: any reason not to use 2.6.28-10?
<rcn-ee> musb bugs... on the beagle.. ;)  i think you guys have a good working ehci port correct?
<who_> rcn-ee: they specify that they're for use with 2.6.28-10 which is what they see as the kernal they are supporting
<who_> rcn-ee: yea, the usb is stable for us...
<rcn-ee> they had weird version numbers like : 1.3.13.1607
<who_> rcn-ee: what did?
<rcn-ee> the kernel modules...
<who_> rcn-ee: oh, okay. I don't know. they ship them in a folder called kernel-modules-sgx530_3.00.00.09-r0_igep0020b - but that would appear to be of no use ;)
<rcn-ee> okay 3.00.00.09 (1.3.13.1607 was for that) is safe for those directions on elinux... the much older 3.00.00.06 needed other tweaks..
<who_> rcn-ee: thanks again. will these modules do anything to accelerate video playback, or do I need to go to the dsp framework for that?
<rcn-ee> who_, by the way, since your using that one.. use this older revision, it gives you a bigger picture of what i did before i wrapped it all up in the script... http://elinux.org/index.php?title=BeagleBoardUbuntu&oldid=16127
<rcn-ee> who_, nope... just '3D'  i've been chewing on the dspbridge, and gst-dsp but haven't got the two to work together yet...
<rcn-ee> i sneak the /usr/bin /usr/lib files into hte modules package when you use the script to make it very easy for users to install...
<who_> sweet. that old revision is brilliant. thanks. As for DSP bridge, the IGEP wiki _looks_ to haveit documented well here http://wiki.myigep.com/trac/wiki/HowToSetupUseIGEPDSPFramework . I haven't tried it though - I need to start with the basics :P
<who_> rcn-ee: I have to go to bed now, which is a shame because I'm learning a lot!
<rcn-ee> there's always the next day too.. just keep messing around with it...
<who_> rcn-ee: thanks for the help... I'm sure I'll be back at some later date to ask some more things :)
<who_> rcn-ee: yea, I need to get on top of my toolchain so I can iterate things fast :) It's been a frustrating week with 1 dead PSU and the _weird_ bug I described above where the system just starts hanging. Hopefully next week will be full of productive joy :)
<rcn-ee> it pays to have lots of extra hardware.. ;)
<who_> rcn-ee: indeed! anyway, thanks very much for the help.
<rcn-ee> your welcome, later..
<Differentkindof> Super near stupid question
<Differentkindof> If a program is coded in c c++ and tcl and I'm running ubuntu arm and I know it has make is there anything super special (barring lib dependencies) to make a program build properly or am I good with the typical make commands to install on arm hardware
<suihkulokki> what happened to the ubuntu android runtime project?
<lool> The direction/research was abandonned
<suihkulokki> thats sad, being able to run android apps on generic linuxes would be highly useful
<alow> Wondering if someone can point me at a .deb for gdb?  There has to be one out there.
<cooloney> 4
<gregoiregentil> On beagleboard, I have amixer, alsamixer, aplay, arecord working but gnome-volume-control reports the "connection failed, reconnecting". Is it a problem with pulse?
<gregoiregentil> also, launching pulseaudio --start reports an error "Daemon startup failed". Has anyone experienced that?
<persia> gregoiregentil: Please file a bug about that: it should just work.
<persia> You might try parec and pacat to see if those help.
<gregoiregentil> but is it working for anybody? Note that I have a special 2.6.29 kernel and I'm wondering if that may be the problem
<persia> Aha.  We'll need someone with a non-special kernel to test :)
<GrueMaster> gregoiregentil: which distro are you running?
<gregoiregentil> Always Innovating Ubuntu: http://www.alwaysinnovating.com/wiki/index.php/Ubuntu
<GrueMaster> which release?
<GrueMaster> oh, nevermind.
<GrueMaster> Have you tried Lucid?
<gregoiregentil> No
<ogra> so its karmic ?
<gregoiregentil> correct
<gregoiregentil> let me reformulate my question: has anyone make work gnome-volume-control on ARM Karmic?
<GrueMaster> I'm running karmic at this moment on a dev board, and volume control works here.
<ogra> it would be nice if you submitted something like your changes as patches :) i'd have happily accepted your postprocess thingie (we now have a --script option that does the same in the latest upstream branch though)
<ogra> gnome-volume-control works fine for me on a babbage board under karmic
<ogra> i suspect your kernel might miss an option for something pulse tries to attach to
<gregoiregentil> ogra: OK interesting. Which kernel version is it?
<gregoiregentil> ogra: http://git.alwaysinnovating.com/cgit.cgi/ai.ubuntu/tree/
<ogra> the ubuntu archive kernel, 2.6.31
<gregoiregentil> OK. Yes, I should try to upgrade my kernel
<gregoiregentil> but I have so many patches...
 * ogra knows that feeling
<ogra> gregoiregentil, http://ports.ubuntu.com/pool/main/l/linux-fsl-imx51/ has the kerenl we use on the babbage (the -108 one is karmic), the config is shipped in the deb in /boot, probably you find something by comparing the alsa related configs
<lool> gregoiregentil: From the symptoms, it's very likely a missing config option in your kernel, not necessarily that it's too old
<lool> gregoiregentil: You could strace it to see what is actually failing
<ogra> lool, thanks for researching the versatile issue
 * ogra hugs lool 
<lool> That took me the whole day unfortunately   :-(
<ogra> andy said he'll upload before end of the sprint
<lool> Building kernels and tracking down config changes is really time consuming
<ogra> yeah
<lool> But the result should be a much more useful kernel   \o/
<ogra> yeah \o/
<ogra> rootstock already has the code to use it by default
<lool> It's still missing some stuff; notably the storage drivers are still modules
<lool> We should have SCSI + SD and some FSes in the kernel
<ogra> i'm pondering to drop all the other kernel specialities in rootstock and unify on the archive one
<lool> A nice bonus of the config fixes is that the fonts suck less too
<lool> ogra: I didn't understand why you have two kernels in there
<lool> Why don't you use the cortex-a8 one for all dists?
<ogra> i will
<ogra> as soon as i use the archive kernel i'll drop the others
<lool> I mean you can drop one of them right now already
 * lool &
<ogra> well, it works as is ... i will make the change if i have the archive kernel when i have to touch that code anyway
<cooloney> lool: thanks a lot for versatile things, i am also going to use it for some development
<cooloney> lool: if you need some help for versatile, just ping me
<lool> cooloney: Thanks
<tahsin> hello
<ogra> hey
<tahsin> so i recenly recompiled my image by root stock now  in the gui log in screen it wont show my user name
<tahsin> so i cant go anywhere after that
<tahsin> but console and everything works
<tahsin> and everything is uptodate since yesterday
<ogra> in console you can use the username ?
<tahsin> yes
<ogra> which version of the script did you use ?
<tahsin> the one from karmic repo and also from launchpad test2
<ogra> test2 ?
<tahsin> it is one of the lists there
<ogra> the karmic version should work properly (but does not support building lucid if you tried that)
<tahsin> well i actually tried every rootstock available from launchpad
<tahsin> i am  only building karmic
<tahsin> it only few days ago when updating kernel it started happening
<ogra> hmm that should work properly with the packaged version
<tahsin> i find it strange because i created a lot of images with  same version and never had a problem
<ogra> well, we dont have any beagleboard kernel in ubuntu, if thats kernel related you should talk to the maintainer of eh beagle kernel package
<tahsin> so it could be a kernel issue?
<ogra> he comes by here from time to time: rcn-ee
<ogra> well, if you say it worked until you had a kernel upgrade
<tahsin> ok
<tahsin> well this is complete new install, i do have a older install but i am afraid to break that
<tahsin> so do you anyway to refresh the gdm?
<tahsin> like see where the list is saved?
<ogra> it should just look it up from /etc/passwd
<tahsin> ok
 * persia runs into the dreaded "sudo: must be setuid root" issue
<ogra_> lool, bah, you broke qemu-arm-static
<ogra_> lool, you register the new qemu-arm handler but dont unregister the old arm handler
<persia> please fix :)
<ogra_> oh, it think its just a missing conflicts/replaces
<armin76> quick
<ogra_> hrm
<persia> ogra: Right now, ubuntu-dev-tools is recommending the transitional package (my mistake).  If you need to conflict, please also adjust this.
<lool> ogra: I do
<lool> ogra: Did you read my email about the bug I filed?
<ogra> i didnt know it makes it completely non-functional
<lool> Does it?
<ogra> ogra@osiris:/var/build$ sudo chroot lucid-test/
<ogra> chroot: cannot run command `/bin/bash': No such file or directory
<ogra> it doesnt exec at all anymore
<persia> Worked great for me, until my latest dist-upgrade.
<ogra> same here
<lool> Does it work after a reboot?
<lool> I know it's not unregistered properly, but the documentation says it should so I just filed #516274; I was counting on the fact that both entries point to the same binary interpreter
<ogra> no, doesnt work after reboot either
<ogra> ogra@osiris:/var/build$ ls /proc/sys/fs/binfmt_misc
<ogra> arm  cli  jar  python2.5  python2.6  python3.0  qemu-arm  register  status
<ogra> hrm
<ogra> i have uninstalled the qemu-arm-static package manually and rebooted, why is the arm handler still there
<ogra> ogra@osiris:/var/build$ ls /usr/share/binfmts
<ogra> cli  jar  python2.5  python2.6  python3.0  qemu-arm
<lool> Check in /var/lib/binfmt*
<ogra> why do i have it in /proc
<ogra> oh, there it is
<ogra> ogra@osiris:/var/build$ ls /proc/sys/fs/binfmt_misc/
<ogra> cli  jar  python2.5  python2.6  python3.0  qemu-arm  register  status
<ogra> ogra@osiris:/var/build$ sudo chroot lucid-test
<ogra> chroot: cannot run command `/bin/bash': No such file or directory
<ogra> hmm, still
<ogra> lool, does it work for you ?
<ogra> erm
<ogra> ogra@osiris:/var/build$ cat /proc/sys/fs/binfmt_misc/qemu-arm
<ogra> enabled
<ogra> interpreter /usr/share/binfmt-support/run-detectors
<ogra> whats that ?
<lool> it works after I rerun the postrm and the postinst
<lool> ie sudo update-binfmts --package qemu-arm-static --remove arm /usr/bin/qemu-arm-static
<lool> and sudo update-binfmts --import qemu-arm
<ogra> weird
<ogra> here too
<lool> I wonder whether it's because it's in the prerm
<ogra> did you add that ? i dont think it had a prerm before
<ogra> hmm, it did
<lool> I don't get why it didn't work from the maintainer script; I'm pretty sure it's the same bug than the one I filed, but I don't understand the issue
 * ogra neither
 * ogra reboots again to make sure it persists
 * cwillu_at_work starts playing with rcn's musb patched kernel
<kblin> cwillu_at_work: which one would that be? :)
<cwillu_at_work> kblin, the first one he linked me: http://rcn-ee.homeip.net:81/dl/linux-image-2.6.32.7-x7.1_1.0cross_armel.deb
<cwillu_at_work> kblin, I noticed there was also a 7.2 and 7.3
<cwillu_at_work> doesn't look like http://rcn-ee.net/deb/kernel/beagle/ has any with that patch yet
<cwillu_at_work> I usually build my own kernels from his git, and I haven't checked if they're there yet either
<kblin> cwillu_at_work: what problems are you seeing?
<cwillu_at_work> kblin, right now, doesn't look like any problems :)
<cwillu_at_work> kblin, but historically I have all sorts of fun with mixing 2.0 + 1.1 usb devices on the same hub, as well as general issues with the ehci port on omap3 boards (beagle or overo)
<cwillu_at_work> so at this point, I'm testing the general instability of the ehci port as well as the usb mixing
<cwillu_at_work> the concrete issue I had was some trouble at an installation last month, where their keyboard would lock up after 8 hours or so
<kblin> cwillu_at_work: for my B6, 2.6.31.5-x5.3 resolved my musb issues. for my C2, I still do get the occasional timeout from the network card over musb
<cwillu_at_work> no network access to the device, and only a limited amount of time I could stay on site on any given day
<cwillu_at_work> kblin, running c3 and c4
<kblin> and you still have stability issues with ehci? geez...
<cwillu_at_work> well, there's musb patches floating around that I didn't have; pointed them out to rcn and they seem to be helping
<cwillu_at_work> really, I do everything in my power to make stuff as unreliable as possible :p
<kblin> cwillu_at_work: I guess I'll have to try that new kernel for my c2, thanks for the heads up :)
<persia> lool: Still up?  Do you need a hand chasing the binfmt-misc stuff?
<cwillu_at_work> kblin, I believe http://rcn-ee.net/deb/kernel/beagle/  is preferable, at least once rcn has verified that the patches are in those kernels
<kblin> yeah, I'm not going to touch that stuff tonight, I'll wait until the kernels hit rcn-ee.net
<cwillu_at_work> might not be till monday :p
<cwillu_at_work> I sent him an email, if he respond then there's hope :p
<kblin> :)
<kblin> I'm in no hurry. I just need the c2 board stable enough so I can demo it on a conference in may :)
<persia> Should be no issue with that sort of latency :)
<kblin> persia: dunno, took about a year to get my b6 working
<kblin> with usb ethernet _and_ usb hdd, that is
<persia> Somehow I think that there's enough boards out there that kernels oughtn't take that long, and userspace is getting easier every day.
<cwillu_at_work> kblin, add a laser printer, and you'll have my test case :)
<cwillu_at_work> persia, i.e., I'm already running the kernel in question? :p
 * persia thought that was the case :)
<kblin> cwillu_at_work: nah, I'm going to demo a samba 4 AD DC, that doesn't do printing so far :)
<cwillu_at_work> kblin, you don't share printers on your networks? :p
<kblin> cwillu_at_work: I do with samba 3
<kblin> or rather lpd, no samba involved :)
<ogra> persia, http://rcn-ee.homeip.net:81/dl/rootstock/rootstock-201002041826.log ... so rcn was hit by the qemu issue yesterday already it seems
<ogra> "chroot: cannot run command `debootstrap/debootstrap': No such file or directory"
<persia> Right.
#ubuntu-arm 2010-02-06
<ogra> rcn-ee, hey
<ogra> rcn-ee, i found out what your issue with rootstock was
<rcn-ee> hi ogra, what's up..
<rcn-ee> after my message last night, i was thinking just probally an upload bug.. ;)
<ogra> rcn-ee, run: sudo update-binfmts --package qemu-arm-static --remove arm /usr/bin/qemu-arm-static &&  sudo update-binfmts --import qemu-arm
<ogra> its breakage that occured after lool changed the package naming of qemu-arm-static
<rcn-ee> ahh, will give that a try... probally should have mentioned i'm running lucid.. ;)
<ogra> if you see errors about debootstrap/deboostrap not being found its usually an issue with the binfmt wrapper of qemu
<rcn-ee> thanks alot..  i had a guy email me about that debootstrap/debootstrap error the other day too, probally same issue..
<ogra> well, the package change was uploaded 3 days ago
<ogra> so if it happened after that its very likely to be related
<rcn-ee> his email was over last weekend.. probally something else then..
<ogra> the change might require a reboot or restart of binfmt btw, not sure if it applies immediately
<rcn-ee> i'll give it a test run.. qemu-arm-static still remained.. (rebooted) but it looks like it runs 'qemu-arm' when called..
<ogra> yeah
<ogra> qemu-arm-static is only an empty transitional package now
<ojn> Interesting, so Google just dumped Ubuntu as base for ChromeOS? Bummer.
<rcn-ee> ogra, it looks good, although it looks like useradd tweaked their syntax... ;)
<ogra> are you running trunk atm ?
<ogra> i'm wildly fiddlin with the code there, might be that i broke something
<rcn-ee> yeah, trunk.. revision 42...
<ogra> and what error do you see ?
<rcn-ee> http://pastebin.com/mc8830d7
<rcn-ee> it didn't affect my daily test builder, that's running the version released with karmic...
<rcn-ee> (with lucid tweak)
<ogra> hmm, havent seen that yet and i build rootfses the whole day
<ogra> might be an issue with the code i added to use oem-config though, i havent created any users since yesterday
<ogra> (you can run rootstock without options now and get a first run dialog to set up user, timezone and language)
<ogra> instead of having to forcefuly create a user during build
<rcn-ee> sure i can do that....
<ogra> --fqdn is still needed though, i'll start generating soemthing random with the next commits ...
<rcn-ee> laughs... sometimes i need to stop tweaking my dev systems by running git trees... weired 'ctrl-c'=log out.. ;)
<ogra> currently i'm fixing the package caching for the offline mode though and tomorry i'll fly back to the EU
<ogra> so it might stay in a partially broken state over the weekend
<rcn-ee> that'll be a nice setting for users, then they don't have to learn how to setup a apt-cacher/etc setup..
<rcn-ee> it shouldn't be too bad, (i won't be around) but i've had a hard enough time to get beagle users off 9.04 and onto 9.10... ;) so it shouldn't affect to many people...
<ogra> ah, i see whats wrong with useradd
<ogra> PW=$(perl -e 'print crypt($ARGV[0], "qemuonarm")', $PASSWD) ....
<ogra> move that line above the place wheer USERADD_CMD is set
<ogra> (around line 730)
<ogra> that should fix it
<rcn-ee> you thinking, only when 'newuser' and 'passwd' is not set so i the if block?
<ogra> well, the point is that PW is empty at that point
<ogra> so USERADD_CMD doesnt get the proper syntax
<rcn-ee> ahh true..
<ogra> i'll comit a fix before closing down today
<ogra> the above should be the right fix
<rcn-ee> awesome, it should work, i'll run a quick smoke test...
 * ogra pushes and needs to tear down the dev room ... 
<rcn-ee> have good flight back ogra...
<ogra> thanks :)
<ogra> i'll be back on monday
<tomatoes7> will karmic run on armv7? i wondering cause its made more specifically for the armv6
<lool> persia: I think I know what the issue is now
<lool> It was actually a bug before the renaming, but the rename made it obvious
<kblin> tomatoes7: it should. it just won't work for armv5 and older
<lool> persia: Thanks for fixing the qemu-arm-static dep in ubuntu-dev-tools; I've also demoted it to Suggests since most people don't biuld for armel
<freestyle> hello
<freestyle> i need a cross compile
<freestyle> from x86 to arm v4
<freestyle> help me please!!
<xperia_> hello to all. i have a question ? does a arm package repo exist like for the normal ubuntu releases and if yes what is the url for this repo ?
<xperia> hello anybody online here ?
<ojn> xperia: yeah it does
<ojn> one sec
<ojn> deb http://ports.ubuntu.com/ubuntu-ports karmic main universe
<xperia> woow thanks ojn !
<ojn> np
<xperia> see you all next time bye !
#ubuntu-arm 2010-02-07
<persia> lool: I picked Recommends because I thought most people *should* builde for armel :)  Did you manage to fix the issue with the conflicting binfmt-misc handlers?
<lool> persia: I think so
<lool> persia: The issue was one present before the rename, but becoming serious after the rename
<persia> Aha.  I'm just installing the latest version, and will confirm then :)
<lool> persia: The handler was registered on postinst/configure and unregistered in prerm/remove instead of postinst/install prerm/remove or postinst/configure and prerm/upgrade
<lool> (Hope I'm making sense)
<persia> Right.  That would explain all sorts of things :)  Sometimes I wish maintainer scripts weren't quite so complex, because more people might get them right the first time :)
<lool> Sadly, I can't retrofix the qemu-arm-static packages, but I've added qemu-arm-static.postinst and qemu-kvm-extras-static.postinst configure snippets to remove the old name
<lool> I didn't really test an old qemu-arm-static -> new world full upgrade though; if you do that, I'd love to hear the results
<persia> I can't easily test the full upgrade, but I may be able to figure out a way.
<persia> I can test broken -> fixed.
<persia> Would a karmic -> lucid upgrade do it for the full upgrade case?
<lool> Yes
<lool> Or simply, removing everything, manually installing an old lucid qemu-arm-static and upgrading
<persia> That's fairly trivial to do then: I can just install the karmic qemu-arm-static in a lucid chroot and dist-upgrade.
<persia> Separately, I was thinking: would it make sense to use build-cross-chroot rather than build-arm-chroot, and then try to encourage enabling other architectures?
<persia> I hear qemu powerpc is getting there, although sparc and ia64 probably need some work.
<persia> My thought was that it would be nifty if developers could work on most architectures for most purposes from an amd64 install.
<lool> persia: Ack, I don't like "-arm-" in "build-arm-chroot"
<lool> I think qemu-debootstrap would be a better name for it
<persia> I'd be happy with that name.
<persia> Note that it's not currently command-line compatible with debootstrap.  Specifically, `debootstrap --arch armel` works, but `build-arm-chroot --arch armel` doesn't.
<persia> Both also work with "--arch=armel", but that's a separate case :)
<persia> I've just upgraded from a broken system, and I still get "sudo: must be setuid root".
<lool> or qemu-debootstrap-helper, but I would call it qemu-debootstrap and fix it to be compatible
<lool> persia: Oh sudo is unrelated
<persia> If you would, that would be great.
<persia> Um, sudo is the problem I had, which ogra convinced me was related to the binfmt issue.
<persia> What's the sudo issue?
<lool> If you try running sudo with binfmt, the kernel will run qemu-arm-static which doesn't have the SUID bit set
<lool> It can't work
<lool> persia: Check whether you have one and only one arm entry in /var/lib/binfmt* and /proc/sys/filesystems/binfmt*/
<lool> The entry should be qemu-arm
<lool> /var/lib/binfmts/qemu-arm and /proc/sys/fs/binfmt_misc/qemu-arm
<persia> I do only have one of those.
<lool> You have both and these are named qemu-arm though?
<lool> If you do, then your system is correctly configured
<persia> Right, but I still can't run sudo in my chroot, which was the original issue that brought the other to my attention.
<persia> Any ideas?
<lool> persia: I don't think that can work
<lool> persia: Just avoid using sudo
<lool> chroot as root and continue running stuff as root
<persia> Why can't it work?  Works for all my other chroots.
<lool> Because the kernel runs a single binary for all binaries you run
<lool> You could make qemu-arm-static suid root, but that would be a huge security hole
<persia> Ah, I get it.  I swear it worked on Tuesday, but maybe I did something else.
<persia> It's probably worth noting that in a README somewhere, so people don't file bugs.
<lool> persia: You might be able to run sudo as root
<persia> That's probably it.
<persia> my chroots were in a very primitive state on Tuesday.
<persia> Anyway, I have to head off for a bit.  Thanks a lot for explaining my issue.
<lool> np, do feel free to pass the info to ogra   :-)
<persia> ogra: ^^
 * ogra reads it ... i'm just in fuzzy jetlag state 
<lool> Ok, I give up trying to get virtio-pci to work under versatile
<lool> It seems versatile has a very specific IRQ handling which might mess this up anyway
<ogra> lool, did andy talk to you ? seems your patch didnt build at all
<ogra> for now i asked him to just change the two config options you mentioned in the bug
<lool> ogra: ?
<lool> ogra: I talked to apw on #ubuntu-kernel; the kernel certainly built for me, as well as the modules
<lool> I didn't build .debs though, so there might be some ABI issues
<ogra> he said it exploded in his face on the first modules it tried to build
<ogra> and said your patch changed more than just the two config options
<lool> ogra: Which patch?
<lool> Anyway, this is out of date, he merged my work AFAIK
<ogra> i think he said you gave him a git tree or something ?
<ogra> well, he said he didnt when we talked last night before i flew out
<ogra> since it failed to build
<lool> I attached a patch to the bug and the first commits of the git tree were to fix the lucid tree and then my patch
<lool> Followed by large config updates in a separate patch
<lool> That built for me, and he merged it
<ogra> weird, he said it didnt
<lool> He then decided to merge the updates in a single patch
<lool> Check the tree yourself
<lool> I certainly saw it merged
<ogra> intresting
<ogra> i only see the binutils.bin fix in the last upload
<lool> It's in the git tree, not in the source package
<ogra> right, because it made the package ftbfs according to him
<persia> lool: Maybe it's because I'm in a chroot, but installing karmic qemu-arm-static in my lucid chroot creates double entries for me in /proc/sys/fs/binfmt_misc/*.  dist-upgrading fixes it.
<lool> persia: Yes, if you have it in the host, you'll see the entry in the chroot
<lool> However if you add it in the chroot, it wont be visible in the host
<lool> Can't believe lucid kexec-tools doesn't allow armv7l...
<persia> Well, kinda.  That was my experience for /var/lib/bin... but I seem to have the same /proc in and out of the chroot.
<ogra> lool, huh ? we fixed that in jaunty ?
<persia> NCommander was saying that kexec() hung his hardware.
 * ogra clearly remembers he added a patch to kexec-tools
<ogra> hmm, but that might have been before the disastrous repackaging that lieb did
<persia> You might want to reinvestigate
<ogra> it wont apply anymore, the packaging lieb did isnt even remotely related to the debian packaging
<ogra> he just took the latest upstream source and ran dh-make on it
<persia> Can we just purge dh-make already?
<ogra> and then copied all patches into debian/patches in case someone wants to re-apply (which indeed wouldnt work at all)
<ogra> (IIRC)
<persia> Right.  That deserves an investigation to reclose n bugs.
<lool> kexec-tools 2.0.1 fixes it though
<ogra> did you reverse the mess ?
<lool> I'm just reading the source
<lool> lp:debian/kexec-tools and lp:ubuntu/kexec-tools don't relate at all, yeah
<lool> haha I'm the one who uploaded the kexec-tools patch in jaunty
<lool> actually I uploaded it to unstable
<lool> http://paste.ubuntu.com/371141/
<lool> I pushed the new upstream release
<ogra> great
<ogra> to sad kexec is still broken in all supported kernels
<ogra> (we tested it last week)
<lool> How did it run last week?
<ogra> quit good progress on the specs
<ogra> we actually managed to get the workitem tracker to show green under the trendline :)
 * ogra only has 4 items left in total and only tw in rootstock
<ogra> *two
<ogra> the marvell issue was kind of eating the first half of the week though
<lool> Let me reword my question: how could you test kexec last week since it doesn't run for utsname == armv7l?
<ogra> hmm, ask NCommander :P he did the tests on both arches
<ogra> i only saw it hanging when looking over his sholder
<ogra> i guess he has to retest then tomorrow
<ogra> thanks for pointing that out, i was expecting he had checked that before
<ogra> ah ...
 * ogra feels relief that jackd gets removed with the most recent upgrade
<ogra> and off to reboot ...
<ogra> hmm, my boot got slower http://people.canonical.com/~ogra/osiris-lucid-20100207-3.png
<persia> That's expected.  Remember that the target is 10 seconds, not 8.
<ogra> well, my system is usually a few seconds faster than the average HW
<lool> New kexec still doesn't take armv7l, odd
<lool> Bah I thought it was in 2.0.1 because Debian had 2.0.1 and had it, but it's not
<lool> (and upstream had it too)
<lool> it was committed after 2.0.1
<ogra> smells like another upload :)
<lool> Ok, at least the new kexec crashes instead of refusing to run
<lool> After the last fix, it does *something*
<lool> "Starting new kernel
<persia> That was the behaviour NCommander reported last week.  At which point it hung.
<lool> I see 100% CPU consumption from qemu
<persia> Matches the previous report :)
<lool> oddly, the versatile .deb build fails for me with /home/lool/qemu-versatile/linux-qemu/drivers/scsi/advansys.c:8352: error: implicit declaration of function 'dma_cache_sync'
<lool> But only the debian way
<lool> with the upstream make zImage and make modules, it builds
<lool> I guess it's just not fatal for the upstream build, hmm
<lool> I filed LP #518567 on the kexec issue
<ubot4> Launchpad bug 518567 in linux (Ubuntu) (and 1 other project) "armel/versatile: Can't kexec (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518567
<lool> Got further by using a serial console
<lool> Sent versatile fixes to kernel-team@ list
#ubuntu-arm 2011-01-31
<Kamondelious> what sort of voodoo do I have to do to allow a serial login for maverick on a beagleboard (rev C3)?
<Kamondelious> oh,remove "quiet splash"?  I've tried adding "console=ttyS2,115200n8 serialtty=ttyS2"
<persia> Kamondelious, You'll need to have some upstart job that generates a getty on ttyS2.  jasper-initramfs should generate one on first boot if you're using that sort of image, and passed the console= on first boot.  If not, you can probably get one with a quick copy&edit of e.g. /etc/init/tty5.conf
<Kamondelious> persia, ahhh ok thanks
<Kamondelious> and I'm in, awesome, thanks again persia
<persia> There may be a few other things you have to adjust in a similar vein: maverick is really focused on the desktop/laptop use case.  There's a few things in progress for Natty that ought make it simpler (like automatic provision of getty on serial consoles)
<Kamondelious> like how the kernel can't find the driver for my usb wifi dongle now?
<persia> No, that's likely a general problem.  I doubt the kernel has that driver for any environment/architecture.  Please file a bug with `ubuntu-bug linux` and report as much about the dongle as you can.
<Kamondelious> it's been working fine for the past couple weeks
<Kamondelious> =(
<persia> On an Ubuntu system?
<Kamondelious> yeah
<persia> Very odd.  That really oughtn't happen.  Did you recently get a kernel upgrade?
<Kamondelious> not unless it did it by itself
<persia> You would have at least been advised (needs your password).
<Kamondelious> I did an upgrade a few days ago, but the system's been rebooted a few times since then
<persia> It ought to have shown up the first time, if it was a regression.
<Kamondelious> indeed
<Kamondelious> kernel hasn't changed
<Kamondelious> hmm
<Kamondelious> now the wifi dongle doesn't even show up under lsusb
<Kamondelious> that's really odd
<Kamondelious> the other devices are there, maybe the wifi dongle died
<Kamondelious> that would suck
<persia> Maybe a power thing?  How is it attached?
<Kamondelious> powered usb hub
<Kamondelious> it's been working great for the last couple weeks
<persia> Does a plug/unplug show anything in syslog?
<Kamondelious> good question
<Kamondelious> but I can't test that tonight, it'll require too much dis-assembly
<persia> Well, if you get messages, you probably ended up with it hibernating unexpectedly.  If not, you may want to try in another environment, but I suspect it's gone.
<Kamondelious> indeed
<Kamondelious> thanks again for your help
<sveinse> What is consolekit? It seems its a system for managing permissions and such for logged in users. Am I right?
<sveinse> I'm building an embedded system which will run exclusively off daemons/services. Can I be without it? It seems to me that consolekit pops up everywhere...
<LetoThe2nd> sveinse: well i've got an embedded system without consolekit.. more than one even, i think. depends on what distribution you are running and what it's supposed to do.
<sveinse> LetoThe2nd: maverick
<LetoThe2nd> sveinse: mine don't even run ubuntu :P
<LetoThe2nd> calling a machine running ubuntu embedded feels rather strange to me anyway ;-)
<sveinse> My problem is pulseaudio ATM. Sound worked before the weekend, now I keep getting connection refused
<sveinse> LetoThe2nd: Well, that's the choice we made. We found it better to use maverick over OE, since it offers a system more similar to "ordinary"/host linux systems
<LetoThe2nd> sveinse: choose whatever you like, it's your project ;-) i just wanted to point out that i personally don't consider ubuntu being something worth calling embedded, for it brings all that stuff that i don't want to see there or that wouldn't fit into flash anyway (like all that funky gizmo-stuff that you are at the moment struggling with) :-)
<LetoThe2nd> sveinse: therefore - sorry, can't help you with that one.
 * hrw will seek for sponsor to get flash-kernel with efika support into archive
<hrw> writing patch and waiting for merge is just waste of time
<hrw> ogra_: flash-kernel is still somewhere on a list?
<ogra_> hrw, indeed
<ogra_> i'll try to get to it this week
<hrw> thx
<ogra_> i think i'll skip the merge and just apply the waiting patches though
<hrw> I have to dig patch from lp again...
<ogra_> there is nothing overly important in debian we need
<ogra_> i am subscribed to all the bugs
<hrw> I want to upgrade kernel on efika - flash-kernel started...
<ogra_> hrw, are you going to the emdebian sprint ?
<hrw> ogra_: yes, Cambridge, UK one
<ogra_> i'm looking for a hotel to stay
<ogra_> i dont see any options on the wiki
<hrw> holiday inn express
<ogra_> got a url or so ? i'll book through the travel agent
<hrw> http://mapy.google.pl/local_url?q=http://www.expresscambridge.co.uk/&dq=Holiday+Inn+Express&f=q&source=s_q&hl=pl&aq=3&sll=52.214128,0.144882&sspn=0.173124,0.260925&ie=UTF8&rq=1&ev=zi&split=1&z=12&jsv=310c&mpnum=1001&radius=6.64&vps=3&output=js&oi=miw&sa=X&ct=miw_link&cd=1&cad=homepage,cid:18353814746422007578&ei=lpdGTZilJpH6Oaav7O8E&s=ANYYN7k1RadTteoQeE8HTGY63MdSQHmyCQ
<hrw> auch
<hrw> ogra_: I booked thought agency
<ogra_> well, works :)
<ogra_> ah, cool
<ogra_> so they know it then, thanks
<hrw> no problem
<hrw> this hotel is nearest to ARM
<hrw> and its ~15-20minutes walk
<ogra_> good, thought far from downtown then i guess
<ogra_> i.e. dinner options are likely not great
<hrw> oops. google said 7 minutes even
<hrw> ogra_: it is near
<hrw> you just need to know shortcut ;D
<ogra_> heh, k
<ogra_> i'll ask you then
<hrw> ogra_: use satellite view
<hrw> ogra_: there is a bridge over railway
<hrw> and long sidewalk near the water
<ogra_> i guess i'll find my way around, first the booking :)
<hrw> ;)
<hrw> ogra_: so you go to represent ubuntu/arm and me same for linaro
<ogra_> likely
<ogra_> i'm replacing david
<hrw> ok
<hrw> I land at 11:40 in luton, then bus to cambridge
<hrw> on sunday
<hrw> back on saturday 11:20 from STN
<ogra_> hmm, i will likely just get a flight to heathrow
<hrw> longer trip you will have then
<hrw> STN has best connection to cambridge
<ogra_> yep
<hrw> direct train
<ogra_> but no good lufthansa connection to FRA
<hrw> use cheaper airline?
<ogra_> cheaper ?
<ogra_> LH flies me to LHR for 98â¬ roundtrip
<ogra_> even with train thats a cheapo
<hrw> ;)
<hrw> you have good local airport ;D
<hrw> ~curse me
<hrw> hotel -> arm is 30-35 minutes by walk. 7 by car :D
<hrw> anyway near enough
<ogra_> no, when i lived in cologne i had a good local airport
<ogra_> it's germanwings home base
<hrw> ok
<ogra_> they offer CGN->STN for 5â¬
<hrw> ogra_: http://wiki.openembedded.org/index.php/Oedem/2009#Travel will be useful for you
<hrw> @ is â¬?
<hrw> switch to de_DE.UTF-8 finally?
<ogra_> hmm, i thought i had utf-8 everywhere
<hrw> ;D
<ogra_> â¬
<ogra_> does it work now ?
<hrw> yes
<ogra_> AHA
<ogra_> oops
<ogra_> sorry, caps
<ogra_> dunno why there was IRC preset as charset by default
<NCommander> ogra: so I poked cjwatson, and thought it over. I agree that your right with a new target and not reusing base (which also lets us break out a new seed easily if we need it). I just think we should call it something else beside 'headless'
<ogra> we could extend it to headless-chicken ;)
<ogra> make a name suggestion, i'm fine with anything thats descriptive
<ogra> its janimo's spec he should make the final call
<NCommander> ogra: probably 'ubuntu-cli'. The reason I don't like headless is it could be confused with netboot or LTSP stuff
<ogra> i dont see where that would clash name widse
<ogra> *wise
<ogra> ltsp doesnt have any headless option or anything that would even sound remotely like headless
<ogra> i would probably call it ubuntu-minimal-server or so ... but that would clash even more than headless
<ogra> the name i'd like most would be ubuntu-core ... but that would clash with a product description mdz works on
<janimo> NCommander, any name is fine, headless is used by linaro for their current dev image though
<janimo> NCommander, I am wondering whether preinstalled should be in the name for further clarification
 * NCommander mutters something about the hardest part of implementing a spec is naming the name things
<janimo> as for cli wouldn't that be confused with Mono (CLI) centric build? No need to be overly tesre in naming these images
<janimo> NCommander, indeed, that is why I said I am fien with any names but want to get it done, and then polish (naming, etc)
<NCommander> personally, both ogra and I wantedto call preinstalled images 'oem', but we nuked that for obvious reasons
<janimo> indeed
<janimo> I thikn headless-preinstalled is pretty descriptive
 * rsalveti agrees
<ogra> adding preinstalled will add duplication, preinstalled is in the patch already
<ogra> *path
<rsalveti> hm, ok then
<ogra> damned finger memory
<janimo> well but in project names at least in debian-cd
<janimo> ubuntu-mid, toc, kubuntu-mobile , ubuntu-netbook are quite nondescriptive imo
<janimo> at least this would convey it is preinstalled and not cd and that it is cmd line only
<janimo> anyway I'll continue on it today after pathc piloting is over
<ogra> imho ubuntu-core would be great, but that would need signoff from mdz
<ogra> (since he refers to -core with product stuff)
<janimo> core is vague
<janimo> so it minimal and standard. headless is clearer imho as it actually says omething about a techincal characteristic - the other can be interpreded very differently
 * NCommander would actually would have liked to call it 'base' but that was already taken ...
<apw> rsalveti, yo ... how are your CDs ... the .38 kernel seems to be in the i386/amd64 kernel and they are looking good
<rsalveti> apw: our latest image is still from friday, so no images to test atm
<rsalveti> apw: but let me try the latest deb available
<rsalveti> Finished on 2011-01-29 (took 19 hours, 36 minutes, 38.4 seconds)
<rsalveti> wow
<apw> rsalveti, ?
<apw> what took 19 hours?
<rsalveti> the latest kernel for armel
<rsalveti> https://launchpad.net/ubuntu/+source/linux/2.6.38-1.28/+buildjob/2228976
<apw> rsalveti, oh yeah ... thats why we whine when you want new flavours
<ogra> rsalveti, thats why i wanted the linaro kernel ... got tired of the whining ;)
<rsalveti> :-)
<ogra> apw, we're waiting for mvo to fix update-manager before we can attempt a new image build
<ogra> he's on it though, should be fixed today
<rsalveti> and GrueMaster is also getting his new xm today probably
<apw> ogra, heh he is cutting it fine for the freeze :)
<ogra> well ...
<ogra> having images before the freeze really helps fixing issues :)
<apw> rsalveti, so i am assuming this kernel will be as good for you as the ones we hand made and tested late last week... in which case we are planning on this being the alpha-2 kernenl
<rsalveti> apw: yeah, should be fine
<lilstevi> is there a userspace usb ethernet gadget driver for armel? the kernel level driver for my platform is horribly broken
<rsalveti> apw: 2.6.38-1-omap seems to be working fine, the only annoying thing is the call trace for the erratum, that will probably be fixed later
<rsalveti> once upstream gets the changes
<apw> rsalveti, yeah, nothing major then good :)
<rsalveti> yup :-)
<GrueMaster> ogra: rsalveti:  alsa-1.0.24 was released today.  http://www.alsa-project.org/main/index.php/Changes_v1.0.23_v1.0.24
<GrueMaster> UCM is in.
<rsalveti> cool
<TheUni> GrueMaster: will that make Natty ?
<GrueMaster> TheUni: I am hoping it will get pulled in after A2 this week (too late for A2).
<TheUni> ok
<GrueMaster> I'll hunt down our alsa guy and see.
<TheUni> have they figured out a sane way for applications to detect available cards yet?
<TheUni> hmm, seems that what ucm is?
<GrueMaster> I think UCM is more for a sane way to configure the hardware than through the drivers directly.  For example, the Beagle & Panda boards have audio codecs that contain a lot more connections than are available to the user.  UCM allows you to map the correct ports for the board in userspace so apps (pulseaudio) will just work.
<TheUni> GrueMaster: seems there's a serious lack of information. Alsa has provided a changelog and that's all? I have to hope more is coming
<ogra> http://www.slimlogic.co.uk/?p=40
<ogra> TheUni, ^^^
<GrueMaster> It's mostly in alsa-lib.  UCM is mainly an API interface.  Very little is needed at the driver level.
<GrueMaster> There is also a utility in alsa-utils, but apps can interface directly with the ucm api in alsa-libs.
<sonny80> ubuntu maverick on beagleboard c4: the problem when opens webrowser the system is freezing... i've got  http://rcn-ee.net/deb/rootfs/maverick/ubuntu-10.10-r3-minimal-armel.tar.7z an then done  sudo apt-get install xfce4 gdm xubuntu-gdm-theme xubuntu-artwork xserver-xorg-video-omap3
<sonny80> canonical image hasn't that problem - browser is working well here
<rcn-ee_at_work> sonny80, anything in dmesg during the freeze? are you using swaP?
<sonny80> yes i add  swap
<rcn-ee_at_work> what web browser?
<sonny80> for ex. when watching google maps in firefiox or chrome
<rcn-ee_at_work> did you run the script "get_chrome.sh" in /boot/uboot/tools/ (for me it seem's faster then ubuntu's firefox/chrome in the repo's..)
<sonny80> i didnt ran this script
<sonny80> i think that problem not in the browser
<sonny80> cause canonical image working good
<rcn-ee_at_work> well, the only difference is the kernel.
<sonny80> yes... can you fix the problem? :)
<sonny80> that's why i roll back to angstrom
<rcn-ee_at_work> sonny80, no idea what the problem actually is, since your 'report' is too limited... i'd say use the "get_chrome.sh" script, compare with the builtin firefox/chrome..
<rcn-ee_at_work> then we can go from theire
<sonny80> midori had the same problem...
<sonny80> ok what step i need to do to help you with testing?
<rcn-ee_at_work> run the script... then go to engadget.com, is it smooth?
<rcn-ee_at_work> (on my bx/c4/xm running maverick it is..)
<sonny80> ok i need to reinstall ubuntu instead angstrom it will be tommorow
<rcn-ee_at_work> ah, figured you still had it installed..
<sonny80> on angstrom it is really smooth
<rcn-ee_at_work> next time you should keep the sd card as is, it's impossible to troubleshoot anything...
<rcn-ee_at_work> angstrom is much lighter embedded os.. ubuntu is getting there..
<sonny80> can i send you my SD image with troble?
<rcn-ee_at_work> why? it sounds like you were using my base maverick image with xfce installed..
<sonny80> yep
<sonny80> i also try lxde, icewm
<rcn-ee_at_work> i'm using the same image today, debugging dspbridge and sgx stuff..
<sonny80> the same difficulties
<rcn-ee_at_work> lxde pulles in too much gnome last i checked, that'll bog down the system too..
<sonny80> xfce is the best choice?
<rcn-ee_at_work> sofar in my exeperience yes.. keep it simple the less lib's the easier it is for the beagle..
<sonny80> ok... another question - is it possible to have 24 bit color depth on beagleboard c4 via DVI out?
<sonny80> 16 bit is looking not perfect
<rcn-ee_at_work> sure, but it'll take more cpu cycles...
<rcn-ee_at_work> the neon unit is currently doing the work..
<sonny80> ok... i heard that SGX cannot work with more than 16 bit is it true?
<rcn-ee_at_work> doesn't matter, for 2d graphics the SGX on the omap3 is actually slower then the neon..
<sonny80> hmm... interesting
<sonny80> ok tommorow i will give you detailed information of my problem
<rcn-ee_at_work> other thing to check, speed of sd card on the beagle.. "sudo hdparm -tT /dev/mmcblk0p2"
<sonny80> ok
<sonny80> wget http://rcn-ee.homeip.net:81/dl/updates/omap-image-builder/tools/setup_sdcard.sh is it neccesarry to run it?
<rcn-ee_at_work> are you building the image manually then?
<rcn-ee_at_work> (the script set's up the correct clock speed, in this case your c4 might only be running at 500Mhz vs 720..)
<sonny80> i repeat step by step instructions from http://elinux.org/BeagleBoardUbuntu
<rcn-ee_at_work> that's fine, the manual step by step is the same as the script..
<sonny80> thank you! tomorrow will be next questions
<GrueMaster> rsalveti: Does xloader/uboot for omap4 support the different sysboot modes on the panda?  Was wondering if I could configure a different boot mode for experimenting.
<rsalveti> GrueMaster: that depends on what you'd like to do
<rsalveti> and how are you planning to boot your panda
<GrueMaster> I was hoping that I could configure mode 1101 (UART/MMC1).  Right now it is configured for 101 (USB/MMC1).
<rsalveti> GrueMaster: you can, but then you need to write the x-loader and u-boot with uart
<GrueMaster> (would be easier if the board used 0ohm resistors).
<rsalveti> like we have for beagle
<rsalveti> I believe someone already did the work to boot from usb
<rsalveti> using micro usb
<GrueMaster> Ok, so not currently supported.  That's what I needed to know.
<rsalveti> well, probably need some dev to make it work
<rsalveti> but possible, for sure
<GrueMaster> I'll explore it later, after A2.
<rsalveti> and why uart? guess usb should also work fine for you
<GrueMaster> automation.
<nicofs> is anyone familiar with rootstock? i try to build a xubuntu rootfs but it always stalls setting up xulrunner...
<topfs2> nicofs: I have seen this also, not sure why it happens though
<rcn-ee_at_work> nicofs, on x86 right? it's qemu crashing..
<nicofs> rcn-ee_at_work, but why is it doing that to me?!?
<rcn-ee_at_work> it does it to everyone on x86 since lucid... run it on your target arm board and it'll work fine. .;)
<topfs2> rcn-ee_at_work: lol, and it will take 100 times longer most likely :D
<topfs2> I'm guessing it is of no diff on x64?
<rcn-ee_at_work> actually my igepv2 is faster then my quad 64bit on building rootstock.. ;)
<topfs2> haha
<rcn-ee_at_work> it's native armv7a vs emulated armv7a.. .;)
<topfs2> oh right
<rcn-ee_at_work> and with thumb stuff thrown in for extra fun.. ;)
<topfs2> I thought rootstock just downloaded and installed, didn't realize it had to actually do any arm stuff
<nicofs> rcn-ee_at_work, if my target arm board had any internet - no problem
<Amiga492> Hi guys, I followed the steps here exactly to boot Ubuntu on Panda; https://wiki.ubuntu.com/ARM/OMAPMaverickInstall, but when it boots, I get stuck at "Enabling additional executable binary formats binfmt-support" on serial terminal, nothing over DVI on monitor though.  Any ideas?
<Aureusz> Hi ! :) I'm on this page right now : https://wiki.ubuntu.com/ARM/DeviceSupport and wondering what you guy would recommend for an arm notebook. There was a lot of stuff presented in CES 2011 so perhaps there are some models you heard of that run ubuntu Flawlessly ? I'm always on the move and I'd like to be able to write code for hours without charging power :)
<persia> Aureusz, I've seen folk walking around with Ubuntu on the Sharp Netwalker, Genesi Efika MX, and Toshiba ac100.  For all of these, it seems some tweaking of kernels is required.
<Aureusz> I dont mind tweaking kernel, but honsetly, if theres a model that handles things perfectly with an arm ubuntu image... it's better ;p
<Amiga492> anyone know why I'd get stuck at "Enabling additional executable binary formats binfmt-support" on 10.10 boot on Panda?
<persia> Aureusz, There's talk about having some for Natty, but I haven't seen anyone commit to one yet.
<Aureusz> persia, thanks for you answers, I read also that some machines are coming. most would be tablets I think, interesting anyway :)  gn
<ka6sox> or bookreaders
<persia> ka6sox, What's the difference between a bookreader and a tablet?
<ka6sox> persia, what the manuf loads on them.
<persia> And if we consider that the goal is to ignore that, and install Ubuntu on everything?
<ka6sox> otherwise...from a hardware standpoint? (well at least the Nook)
<ka6sox> not a bit of difference
<ka6sox> persia, I"m moving my nook color from Android to Ubuntu....slowly because I'm so busy with the FOSS project I work on :(
<persia> I suppose one might make a bookreader that was a convertible or a wearable or some such, but yeah, my thought is that "tablet" is a device category and "bookreader" is an application.
<ka6sox> persia, right...
<persia> ka6sox, Your earlier work on that inspired me to go look up the specs, but it didn't seem to be quite enough, for me (but then, I'm generally not a tablet person)
<ka6sox> since I can probably get a kindle or nook app that runs on most things.
<ka6sox> persia, its CHEAP....and works well.
<ka6sox> its not a 10" device however.
<persia> ka6sox, Indeed, but it has to be *better* than my Netwalker to replace it in my pocket.
<ka6sox> true
<persia> And it's close, but not quite better (but lots cheaper, and better as a new purchase for folk who like tablets)
<ka6sox> for now I was looking @ how to do porting...especially of Android devices to Linux.
<persia> Well, the quick'n'dirty way is to just boot the Android kernel and an Ubuntu userspace.
<persia> But one usually finds one needs to tweak the kernel a bit afterwards.
<ka6sox> thats my first approximation...if I ever get time to make this stupid initramfs.
<persia> The ideal way is to add any necessary hardware support patches to the Ubuntu kernel, and then have a kernel flavour that can be used with Ubuntu on the device.
<ka6sox> not sure if the patches are mainline yet...and BN didn't separate out "patches" it was a source dump off a Windows Machine.
<persia> That's unfortunately common.  The monolithic patch is usually extracted by diffing against mainline for the reported version, and then one breaks down the components by inspection, and tries to port them to current trunk.
<ka6sox> persia, I'd LOVE to do that if we could figure out what they started with.
#ubuntu-arm 2011-02-01
<persia> ka6sox, It appears to be based of 2.6.29
<ka6sox> yes, but we haven't been able to determine which tree it came from.
<persia> so?
<persia> I suppose it reduces the porting effort, but I presume you could sensibly look at the diff against mainline 2.6.29, and try to determine which are porting patches.
<persia> All the SoC-specific stuff ought be mainline, so it's really just the platform stuff that is interesting.
<ka6sox> ya, its a question of time...but if I could ever get more time I'd have more fun.
<persia> Heh.
<persia> I don't know enough about kernel internals, but I suspect there's something on the order of 10-12 files that have any content that is Nook-specific, and isn't covered by the OMAP stuff.
<persia> And strongly suspect that the porting effort to bring those files to 2.6.38 is unlikely to be heroic.
<persia> (although I wouldn't expect the result to be as seamless as the current kernel: there's surely some extra hackery present, but those are fixable bugs: the above ought get one booting)
<lilstevie> I am having issues with framebuffer setup
<lilstevie> not getting any output on screen once GDM starts
<rsalveti> janimo: it's hard to have both gl and gles support at Qt
<rsalveti> even if we split in two packages, I don't think it'll be easier to maintain
<rsalveti> qt takes 1 day to build, and it's huge
<ogra> root@ac100:/# apt-get -f install
<ogra> Segmentation fault
<ogra> grrr
<rsalveti> haha :-)
<rsalveti> not good
<ogra> i guess i'll have to reboot
<ogra> nope, not good
<rsalveti> good luck
<ogra> natty chroot though
<rsalveti> oh, ok
<ogra> not my main rootfs
<janimo> rsalveti, yes, probably more weork than worth it with qt split
<berco> ogra: persia: fyi, alsa-lib v1.0.24 with UCM support is now out
<berco> still lacking the specific config files for OMAP4 boards
<ogra> berco, yeah, we hard that already, i guess luke waits with the upload until after the freeze
<ogra> *heard
<berco> ogra: let us know how it goes and if you face issues
<ogra> will do
<ogra> root@ac100:/# apt-get -f install
<ogra> Segmentation fault
<ogra> hmm, so reboot didnt help
<ogra> thats bad
<armin76> you broke it :D
<ogra> armin76, i wish i did
<ogra> then i would know whats wrong
 * ogra sighs
<ogra> is anyone running a maverick rootfs with natty chroots ?
<ogra> (both armel)
<rcn-ee_at_work> ogra, squeeze rootfs with natty chroot... or do you think it's a maverick->natty issue?
<rsalveti> GrueMaster: up already?
<ogra> rcn-ee_at_work, well, i think its a HW issue but i dont get such behavior with maverick->maverick-chroot
<GrueMaster> Been up for an hour.
<ogra> GrueMaster, really ?
<GrueMaster> Still working on coffee infusion.
<ogra> GrueMaster, the question is why :)
<GrueMaster> puppy walking on bladder - bad combo.
<GrueMaster> I'm getting a little miffed at the XM dev's.  No updated documentation since rev A2 available (A3 broke DVI for us), I have a Rev B and no idea what changes have been made, and they are talking about some change to USB on Rev C.
<ogra> GrueMaster, i thought rsalveti just added a fix for the broken DVI
<ogra> (or reworked a broken one from koen)
<rsalveti> GrueMaster: A3 should be the same as B
<rsalveti> only chip rev that changed
<GrueMaster> And this is documented...where?
<rsalveti> and our latest kernel deb should be fine with it
<ogra> ricardos head ;)
<rsalveti> beagle m-l probably
<ogra> just print a pdf from it ;)
<rsalveti> yeah :-)
<GrueMaster> ogra: The interface is broken.  :P
<ogra> file a bug
<rsalveti> :P
<GrueMaster> At any rate, it is frustrating when software doesn't work as documented, and you don't know the hardware changes that could have affected it.
<ogra> welcome to the world of developer hardware
<rsalveti> GrueMaster: http://beagleboard.org/hardware/design
<rsalveti> Only Rev B change is processor revision
<GrueMaster> Interesting.  I would not have found that link going through the main pages.
<rsalveti> beagleboard.org -> product details -> Design Materials
<GrueMaster> True, but the layout suggests that is for the original beagle only.  Clicking on beagleboard.org>hardware shows a separate link for the XM at the top of the page, which only leads to the old documentation.
<GrueMaster> But thanks for pointing that out.
<GrueMaster> Pad web page layout.
<GrueMaster> s/Pad/bad
<rsalveti> yeah, the layout is not that nice
<rcn-ee_at_work> there's a git tree for the beagleboard.org layout somewhere.  ;)
<rcn-ee_at_work> GrueMaster, under static.. ;) http://www.beagleboard.org/gitweb/?p=beagleboard.org.git;a=tree
<GrueMaster> Erm, yea.  I'm looking at this and thinking WTF.  Looks interesting and cool.  If/when I get time to learn yet another development environment, I might submit some changes.  In the meantime, is there a bug tracker to file bugs against the web page?  :P
<rcn-ee_at_work> GrueMaster, best to just pink jkridner he does a lot of the web changes..
<GrueMaster> ok
<sinclair> hi everyone
<sinclair> my erlang is segfaulting... and i don't know why =)
<Kamondelious> persia, turns out it was bad wiring on the connection between USB wifi dongle and the USB hub, the dongle works fine, just need to fix my wiring.
#ubuntu-arm 2011-02-02
<rsalveti> GrueMaster: were you able to test our 38 kernel with your beagle xm B rev?
<GrueMaster> yes
<GrueMaster> I had to install it from the beagle first.
<GrueMaster> rsalveti: Latest X segfaults on armel.  Looking into it.
<rsalveti> hm
<lag> ogra: Dude!
<ogra> lag, yo !
<lag> ogra: There you are
<lag> ogra: How do you build kernels for the images?
<ogra> whats up ?
<ogra> you mean rolling uimage out of vmlinuz ?
<lag> No, where is it built?
<lag> On LP?
<ogra> on the cdimage server
<ogra> using the debian-cd scripts
<lag> Okay, let me re-phase the question
<lag> I have created a PPA
<lag> Is there any point in putting a kernel image in it?
<lag> And u-boot image?
<lag> Or it is only used for userspace packages?
<ogra> i think there are possibilities to b uild from PPAs but i have never used them
<ogra> and i dont know if that would work for kernels at all or just userspace
<lag> 'cos your PPA is just userspace stuff isn't it?
<ogra> i know there is code in livecd-rootfs (the script that rolls the rootfses) to use PPAs
<ogra> but i dont know if debian-cd could use that
<lag> Okay
<lag> Thanks for your help
<ogra> ask cjwatson about that
<ogra> our images all have kernels in the archive usually
<ogra> if its urgent for you i'd write a script that just grabs the image and replaces the kernel
<ogra> on chinstrap or people.canonical.com
<lag> Great, cheers
<Homefix1> Using karmic build on my "HTC Evo" I am trying to get my login name's desktop to be loaded instead of roots's desktop. I have export USER=dad and HOME=/home/dad in my chroot script what am i missing (the reason all of roots folders are rdonly and when i install Darwin Streaming Server I get all these "socket errors" and permission errors. I have tried as root and as user dad to install, in
<Homefix1> different folders root and dad doesnt make a diff. any help would be appreciated
<ogra> ok, panda image looks good, installs and runs
<ogra> GrueMaster, could you start with XM so we have the set complete ?
 * ogra only has one microSD left and i dont want to overwrite that
<GrueMaster> Already on it.  Doing both side by side.
<ogra> ah, sweet
<rsalveti> GrueMaster: so the dvi output seems to be working for you with rev B
<GrueMaster> Yes, with the latest kernel.
<rsalveti> I could only test with my rev A
<rsalveti> good
<rsalveti> cool, so we have a working alpha 2 for both machines
<GrueMaster> Which means images prior to today will fail on A3.
<rsalveti> that's fine
<GrueMaster> XM A3 that is.
<GrueMaster> Yea, I'm not too concerned either.
<GrueMaster> Anyone know anything about the server images in  http://cdimage.ubuntu.com/ubuntu-server/daily ?  I pulled them for later examination and curiosity.
<GrueMaster> Not part of the release though.
<ogra> no idea
<ogra> i didnt build them
<ogra> and they wont work anyway
<GrueMaster> yea, I figured as much.
<ogra> ask persia, he has the list of flavours and who is responsible iirc
<sveinse> I get a handful of "note: the mangling of âva_listâ has changed in GCC 4.4" when cross compiling qt apps using the arm-linux-gnueabi-g++ compiler. And someone at #qt claims this to be a compiler bug. Anyone familiar with this?
<ogra> thats simply a note about code that hasnt been ported to new compiler behavior
<ogra> shouldnt cause any issue, its just to notify the devs to make the change at some point as i understand it
<sveinse> Well, our developers get like 500 of those when compiling the apps and cant find the real warnings within it
<ogra> grep va_list <path to code>
<ogra> ?
<sveinse> It's in Qt headers, and Qt points to armel qt bug....
<sveinse> i ment armel gcc bug
<ogra> well, talk to #linaro, they maintain the toolchain
<sveinse> thanks
<ogra> but since thats done mostly by codesourcery guys i cant really imagine its the compiler side being at fault here
<ogra> especially regarding the text of the message
<sveinse> I agree. In essence I'm looking for a way to supress the message. But that's OT here, so thanks anyways
<lool> ogra: https://code.launchpad.net/~lool/jasper-initramfs/mkimage-move is still marked as pending review, is this obsolete?
<lool> It would need to be updated ot use u-boot-tools nowadays
<lool> actually rejecting my own mp
<ogra> lool, yeah, its obsolete
<ogra> all mkimage stuff will move to flash-kernel-installer right after A2 and jasper will use that
<ogra> i just didnt get to it before A2 because of unity-2d
<lool> Hmm flash-kernel wasn't merged from Debian was it?
<ogra> lool, no, and i wont merge it i think, there is nothing in it apart from additional arches we dont care about
<ogra> lool, unless linaro has a strong interest in supporting kirkwood
<ogra> i have a bunch of pending patches on LP to merge, thats more intresting than the debian merge actually
<ogra> lool, and it looks like we need to rework the flash-kernel handling of initramfs-tools completely, upstream demands that the triggers are shipped by the linux packages
<ogra> i.e. we are not allowed to call flash-kernel in update-initramfs anymore
<lool> Will you work on that?
<ogra> for the ubuntu kernels, yes, linaro will have to adapt that
<ogra> in essence it should be similar to how grub is handled
<ogra> lool, do you have any strong interest in a debian merge of flash-kernel ?
<ogra> (if there is any demand i'm fine to do it ... but i wont do it just for doing it ;) )
<lool> ogra: I'm reviewing my lp inbox, and found https://code.launchpad.net/~sveinse/project-rootstock/apt-source-fix/+merge/47387 seems to be waiting for review
<lool> ogra: flash-kernel > I think we have accumulated a large delta in Ubuntu and we should try to merge support for these platforms in Debian; I personally suspect flash-kernel needs rearchitecturing to be a bit more versatile, and it would be best if Debian and Ubuntu were close to each other before that happens
<ogra> lool, yep, i think rsalveti has it on his radar
<ogra> (the rootstock fix)
<lool> I'm not so much interested in getting the latest Debian changes into Ubuntu as in shrinking the delta
<ogra> and sveinse talked to us here
<rsalveti> ogra: yup
<ogra> lool, i would prefer to shrink the delta by supplying our changes to debian first
<ogra> the upstream delta to what we have in ubuntu atm isnt big
<ogra> only our additions are
<ogra> i agree that flas-kernel needs redesign
<ogra> bug 702898
<ubot2> Launchpad bug 702898 in ubiquity "ubiquity crashed with TypeError in changed(): value is of wrong type for this column" [High,Fix released] https://launchpad.net/bugs/702898
<ogra> GrueMaster, is that the geoip bug ?
 * ogra is to lazy to open it :P
<GrueMaster> Yes.  My crash report has the exact same error information, so it's a match.  It is also fixed.  I just updated all the packages on my panda image between boots and ubiquity doesn't crash anymore.
<ogra> ah, thats why i didnt get it, i did a networked install
<GrueMaster> But I don't think it warrants an image respin.
<ogra> and we agreed that armel doesnt need a respin for it
<GrueMaster> I have a networked install as well, but through a nat firewall.
 * ogra discussed it this afternoon
<GrueMaster> Ah.  Must have missed it.
<ogra> in -release
<persia> ogra, My list isn't complete or official currently: there's another call for product managers just post Alpha 2.
<ogra> persia, well, do you have anyone for dove server images ?
<ogra> i think thats rather a mistake
<persia> No.  Nobody I talked to said they wanted to support dove.
<ogra> given that we dont support dove at all
<ogra> and the omap server images have no bootloader handling
<ogra> i'm all for selling janimo's headless image as server on omap rather than wasting space for non working images
<persia> I agree.
<persia> The only armel images I've heard about are Ubuntu Desktop/omap3 Ubuntu Netbook/omap4, Kubuntu Desktop/omap4, Kubuntu Desktop/imx51, Kubuntu Mobile/N900, Xubuntu Desktop/imx51, headless/omap3, headless/omap4
<persia> But for lots of those, there's no kernel in the archive, so it looks doubtful
<ogra> Ubuntu Desktop/omap3 ???
<ogra> what for would that be ?
<ogra> we ship Desktop on the image
<persia> Oh, right, Ubuntu Desktop/Ubuntu Netbook merged.
<ogra> not really either ;)
<ogra> the image is netbook
<ogra> but thanks to gdm requirements it ships gnome desktop
<persia> Oh, then maybe I'm confused.
<persia> I think Ubuntu Desktop/omap3 was as proof-of-concept for the better-subarch-detect spec.
<persia> I suppose that could be done with Ubuntu Server/omap3
<GrueMaster> Other than the normal netbook and now server images, I am not seeing anything for armel in weeks.
<ogra> persia, if you find a product manager for it
<persia> ogra, Indeed.  The purge didn't happen for Alpha 2, and when I started asking questions, I was told it couldn't happen until Alpha 3.
<persia> But I suspect the product manager for the PoC for better-subarch-detect will end up being the better-subarch-detect folk.
<ogra> well, its trivial for NCommander or me to stop them building
<ogra> though indeed i dont hack around on antimony during a milestone release ;)
<ogra> but i'll disable the server builds on friday, if someone needs it back he can ask for it
<persia> Go ahead, if there's resource issues.  I believe skaet will be sending out something Monday or Tuesday, and we'll end up trimming with the results of that later.
<ogra> there is always space issues
<ogra> i.e. for todays milestone images jaunty had to be removed
<persia> jaunty belongs on old-images anyway.
<ogra> indeed
<ogra> that was just to point out how short on space we are
<ogra> it wasnt removed because it belongs somewhere else but because the space was needed
<ogra> that it belonds to old-releases was just a sideefect
<GrueMaster> ogra: The ti-omap-extras is missing.  Is that known?
<ogra> GrueMaster, i havent seeded it yet
<GrueMaster> Ah, ok.
<ogra> since it went out of jasper
<GrueMaster> Thought I'd point it out.
<ogra> yep, thanks
<ogra> i'll care for that after alpha
<GrueMaster> Better to ask before filing a bug.  I'll add it to the comments.
<ogra> feel free to file a bug and assign it to me if you feel like
<GrueMaster> Looks like univers/multiverse are still not being added to sources.list.
<persia> That might have been a victim of the jasper re-write, sadly.  The code to do it is still in the original bug.
<ogra> well, i'll add it to jasper if needed
<GrueMaster> do you have the bug #
 * persia digs it up
<GrueMaster> (saves me having to search).
<ogra> i still need to generate .symbols files for all the unity-2d libs and then should be done with that
<ogra> so i can concentrate on jasper again after A2
<persia> bug #659754
<ubot2> Launchpad bug 659754 in ubuntu-netbook-efl-default-settings "Universe & multiverse are not enabled on OMAP4 preinstalled image" [Undecided,Invalid] https://launchpad.net/bugs/659754
<Homefix1> Using karmic build on my "HTC Evo" I am trying to get my login name's desktop to be loaded instead of roots's desktop. I have export USER=dad and HOME=/home/dad in my chroot script what am i missing (the reason all of roots folders are rdonly and when i install Darwin Streaming Server I get all these "socket errors" and permission errors. I have tried as root and as user dad to install, in
<Homefix1> different folders root and dad doesnt make a diff. any help would be appreciated
<Homefix1> In qemu i log in as user but in Evo it logs in as root
<Homefix1> is it because the chroot is in root, is there a remidy?
<GrueMaster> Homefix1: I'm a little confused.  Does the Evo support armv7?
<Homefix1> im sorry it does
<Homefix1> Grumaster: im sorry it does
<Homefix1> GrueMaster:My scripts are her in this tutorial i put together http://forum.xda-developers.com/showthread.php?p=10584098#post10584098
<Homefix1> scroll to mid-page bootubuntu.sh
<GrueMaster> Homefix1: My main question is why you would be using karmic as opposed to Lucid (LTS), Maverick (latest stable) or Natty (bleading edge).
<GrueMaster> Karmic is due to be EOL once Natty releases.
<GrueMaster> And it is only Armv6+vfp optimized.  Not armv7.
<Homefix1> Gru: everything is fine i just need a litttle assist. getting it to boot into my personal desktop rather than root.
<Homefix1> I have used lucid and mav. too
<Homefix1> I should have said lucid.
<Homefix1> I dont use Mav because i get seg fault in qemu
<GrueMaster> Ah.
<Homefix1> just like if i made lucid .img on lucid build i get seg faults
<GrueMaster> I won't be able to help as this is outside of my scope.  I just wanted to make sure you were actually using a supported distro.  Of course, most of us are currently focused on natty, so I don't know how much help you will get, but good luck.
<Homefix1> in qemu i can boot into my personal (user)desktop fine in my evo it boots into roots desktop no matter what i do
<Homefix1> and of corse it is read only
<hipaulshi> hi. does any one successfully install ubuntu server on beagleboard xm?
<rcn-ee> hipaulshi, i run my beagle's as server's... apache/etc.. are you looking at speicif meta package or what?
#ubuntu-arm 2011-02-03
<straszheim> have a docs bug
<straszheim> this page -> https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<straszheim> On Beagleboard xM rev A3 and B, the wgets are to the wrong directories
<straszheim> they're right, but reversed
<persia> straszheim, Would you mind correcting that?
<straszheim> np
<persia> Thanks!
<straszheim> after a solid week of trying to get things built for a gumstix I have to say that install was pretty awesome.
<persia> I heard of someone running on a gumstix before.  Did you have to do anything special to the image, or did it mostly just work?
<straszheim> ah, no, i mean the omap3/maverick install was awesome because it worked and took a few hours.  gumstix is unplugged, major fail
<persia> Which gumstix do you have?
<straszheim> verdex pro
<straszheim> armv5te iirrc
<persia> Indeed.  Debian ought be not too hard to get running on that.
<persia> I think the omap3 images work on the Overos, but I haven't seen enough confirmation to be sure: none of the regulars on this channel seems to use one with Ubuntu.
<straszheim> is there a recommended way to strip the gui stuff out of this install?  This thing is intended to run headless.  I'm considering just removing x11-common.
<straszheim> that'll take a ton of stuff with it
<jhobbs> check out tasksel
<straszheim> ah nice
<straszheim> thx
<persia> I'd recommend making sure ubuntu-standard and ubuntu-minimal are installed, and then removing ubuntu-netbook and all it's dependencies (avoiding removing -standard and -minimal)
<persia> From there you can build up again.
<straszheim> sounds good
<rsalveti> straszheim: I'm reverting your change
<rsalveti> the first sd card partition should have the uImage, not vmlinuz
<ogra> http://projects.goldelico.com/p/ombeagle/
<rsalveti> ogra: cool!
<ogra> yep
<ogra> waiting for the panda version :)
<janimo> rsalveti,  wrt https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update
<janimo> is that tool suipposed to do what flash-kernel currently does but for uboot binaries ?
<rsalveti> janimo: moving it for you
<rsalveti> kind of
<rsalveti> because u-boot and x-loader is not updated
<rsalveti> just the kernel
 * janimo wonders if code can be reused from flash-kernel at all
<rsalveti> janimo: yup, that's why you need to talk with NCommander later, to check the flash kernel and the sub arch detect code
<rsalveti> to see what can be shared
<janimo> ok
<ogra> rsalveti, we should just seed them and make sure they are on the image worst case ... then people can at least manually update
<rsalveti> ogra: but the idea is to have a tool to manually update the core boot files
<rsalveti> shouldn't be that hard
<ogra> indeed
<ogra> but if we dont manage, seeding should at least get us a step forward
<rsalveti> yup, true
<janimo> ogra, seeding all? For instance for omap3 image seed all the omap3 based xloader/uboot binaries?
<ogra> janimo, well, we cant be that distinctive in the seeds (seeds dont support subarches)
<ogra> so we would need to seed all
<janimo> ok
<ogra> the point is that apt-get update will get you the latest binaries on disk
<ogra> so even without the desired script we would have them available for manual tinkering
<janimo> I am thinking having them on the disk and then adding a post install hook like flash-kernel would solve this
<ogra> right
<ogra> that was the initial plan
<ogra> but if we dont have time for the flash-kernel bit, at least seeding should be done
<rsalveti> janimo: we don't want a post install hook
<rsalveti> we want the user to manually update the files
<rsalveti> avoid problems
<ogra> right
<rsalveti> and a lot easier to implement
<ogra> just a script
<janimo> rsalveti, so not the same ease and transparency s grub is installed with?
<janimo> ok
<rsalveti> yeah, we want a script that the user can trigger by hand
<janimo> or rather ease, but not automatic
<rsalveti> and we also want to notify the user about such update
<janimo> ack
<ogra> we dont update grub stage 1
<ogra> there is no such ease ;)
<lool> rsalveti: Hey, would you know whether USB storage is fully stable on xm now?
<ogra> lool, given that the buildds use it ...
<lool> We use xms as buildds now?
<ogra> you should know it :)
<ogra> they come from linaro afaik
<ogra> see https://launchpad.net/builders
<lool> ogra: how do I know they are xms?
<ogra> lamont
<lool> Ok, so https://launchpad.net/builders doesn't help much I guess
<ogra> the arm team helped him to bring them up
<ogra> well, it shows that there are 15 instead of 8 now
<ogra> indeed it doesnt show the arch
<GrueMaster> The *ceae systems are the new ones.
<ogra> right
<ogra> i was just looking for the naming convention
<ogra> had noted it somewhere
<ndec> ogra: lool: I didn't know the builders moved to XM!
<ogra> ndec, on *the builders*
<ogra> s/on/not
<lool> Well /builders is confusing
<ogra> ndec, linaro added 6 XM builders to the queue so their rebuilds dont impact the distro
<lool> ogra: they are shared though, right?
<ogra> ndec, we are still waiting for the panda cluster
<ogra> lool, yep
<ndec> lool: i was about that too.
<lool> ndec: we have two types of buildds
<ogra> lool, but can be used dedicated as i understood
<lool> ndec: some for packages and some for images
<lool> we can actually share them, but we usually don't
<lool> and offspring/linaro don't use these for image builds, but another separate pool -- let's call them offspring builders
<ogra> lool, so during archive rebuild tests they wont be shared
<ndec> lool: ok, and the one for the packages are split between archive and PPA?
<lool> ndec: Yes
<lool> ndec: That's only on ARM because these are non-virtual
<lool> on other arches, they are actually separate
<ogra> ndec, though your PPA builders are the two at the very bottom of the /builders page
<ogra> they are not in the normal builder pool
<GrueMaster> Actually, there are two dedicated ppa buildds, according to the link above.
<ndec> ogra: did they moved to XM too?
<ogra> ndec, nope
<GrueMaster> wait, nevermind.
<GrueMaster> eyes are blurry.  need more coffee.
<ogra> GrueMaster, the two are for private PPAs
<GrueMaster> Ah, there they are, at the bottom.  I had sorted by arch and thought I saw two, but then they disappeared.  Thought my eyes were bugging out.
<ogra> heh
<ogra> ndec, they will likely move to pandas once we have them
<lool> ndec: Sorry, I was confused, we're using separate PPA builders nowadays it seems
<ogra> lool, depends on the PPA
<lool> ogra: How so?
<ogra> see PM
<rsalveti> lool: it should be, the only issue atm is that the driver is allocating a lot of memory when you stress the ethernet or usb
<rsalveti> and some times you can see the traces, but not something that breaks
<rsalveti> same problem we have with panda, as it's the same driver
<lool> Ok thanks
<rsalveti> lool: but I'd say beagle in general is a lot more stable than panda
<rsalveti> and I think we didn't face any major issues with the builders
<rsalveti> I'm impressed by the amount of bug reports for unity-2d since it was released
<rsalveti> seems people are really using it
<slangasek> ogra: hey there, another question on historic qemu packaging.  You have another sysctl here for 'vm.vdso_enabled = 0' with the reason "else chroot execution fails" - how did it fail, how can I verify if this is still needed?
<ogra> slangasek, hmm, did i actually add that ?
<slangasek> ogra: in karmic, yes
<ogra> hmm, i think i had that from the maemo ML somewhere
<ogra> let me dig
<slangasek> ogra: thanks
<ogra> http://maemo.org/development/sdks/maemo5_alpha_installation/#sboxissue
<ogra> http://bugs.maemo.org/show_bug.cgi?id=3479
<ubot2> bugs.maemo.org bug 3479 in SDK "SDK does not work on Debian lenny system" [Major,Resolved: fixed]
<ogra> might not be needed anymore
<ogra> since it refers to intrepid
<ogra> slangasek, ^^^
<slangasek> ogra: so is this specific to scratchbox in some way?
<ogra> i had the same error in rootstock/qemu back then, else i wouldnt have added it
<slangasek> ok
<ogra> i would suggest a test on amd64
<ogra> i'm not sure its still valid
<slangasek> well, testing how?
<slangasek> and on amd64 we don't set this at all, the key doesn't exist in /proc/sys on amd64
<ogra> seems related to the glibc in side the VM
<slangasek> VM?
<slangasek> should be a chroot not a VM, yes?
<ogra> err, yes, sorry
<ogra> the bug seems to also rather suggest to set it to 2 instead of 0
<ogra> looking at the last comment
<ogra> i would actually drop it and look out for related bugs
<ogra> its natty after all ;)
#ubuntu-arm 2011-02-04
<rsalveti> morning
<ogra> yo
<rsalveti> janimo: can't the qt bug be also forwarded upstream?
<rsalveti> as it seems now that is not a compiler regression
<janimo> rsalveti, sure, I can do that
<janimo> I am surprised though it happens with gcc4.4 as well, I wouldn't have thought it is a Qt regression - smaller chances for that between 4.7.0 and 4.7.1 than between two toolchains
<ogra> janimo, rsalveti, shouldnt we wait until NCommander's full rebild finished to make sure its not any of the linked in bits ?
<rsalveti> could be, was just thinking in a way to put more people looking at this
<rsalveti> and it won't hurt to send it upstream
<persia> Better to give a good report to upstream.
<ogra> since janimo did only a partial build and NCommander was supposed to do a full one
<persia> And if it's a compiler issue, better to send to the other upstream :)
<ogra> well, currently it doesnt look like compiler
<ogra> but i'd like a full proof before pushing any upstream
<persia> I don't think it's known.  Inlines behave exceedingly oddly with partial builds.
<ogra> so imho we should wait until we can prove it by trying out NCommander's complete build
<persia> Indeed.
<ogra> given he started it last night (i hope) it should be done this evening at some point
<janimo> ogra, do you know what NCommander's current build tests for
<janimo> ?
<ogra> janimo, well, according to the call yesterday he was supposed to build the full source with gcc 4.4
<ogra> same thing you did but with the full package
<janimo> ok
<janimo> althoug he seemed to say it was redundant
<ogra> so we can exclude any issues that might be caused by a partial rebuild
<janimo> right
<ogra> sigh
<ogra> did he ?
<janimo> he surely had some build going but not sure for what
<ogra> hmpf
<ogra> k
<ogra> lets see when he gets up
<ogra> and ask him then
<sveinse> I need to write a udev rule for pulse audio. Anyone here knows how or an example of how to write a udev rule for the OMAP soc audio?
<ogra> a udev rule ?
<ogra> why ?
<sveinse> Yeah. Take a look in /lib/udev/rules.d/80-pulseaudio.rules
<sveinse> I need such a line for the soc in order to define a pulseaudio profile
<ogra> nope
<ogra> you need an alsa profile instead
<persia> I don't even have that file
<sveinse> (this was on maverick)
<ogra> i dont have that file on maverick
<persia> My maverick has a 90-pulseaudio.rules, but it only has stuff for some fairly exotic USB devices.
<ogra> right
<persia> Doing it in ALSA is the way to go.
<sveinse> do you then know how? Because I don't have audio on my board and the pulseaudio people sais I need to write a PA profile such as the exotic ones in 90-pulseaudio.rules
<sveinse> persia, so how do I do that then?
<persia> Which board ("FOO" if you can't say)?
<sveinse> FOO. It's our own custom board with custom audio devices.
<persia> Ah.  That will make this discussion a little trickier :)
<sveinse> So I know I'm on my own, but regardless, I need audio to work ;)
<persia> Does `aplay -l` give you any output?
<sveinse> Yes, no problem. And I'm able to playback with alsa players and alsamixer
<persia> Excellent!  That's a good start.
<sveinse> I also have pulseaudio if I load the modules manually. It's just the udev autodetection which doesn't. It refuses as it doesn't find a working profile.
<sveinse> And thus the udev rule where I can tell PA about its profile (which I need to write regardless)
<persia> Something like load-module module-alsa-sink ... (with lots of arguments)?
<sveinse> But I'm listening about other methods if you know about it
<sveinse> persia: Yes, *lots*. However you lose some capabilities that way (like HW volume control) due to limitations in the manual module load
<persia> Indeed.
<sveinse> Where can I find a ALSA profile?
<ogra> in /usr/share/alsa/init/
<persia> That only works if you get useful CARDINFO data though: you should be able to tell if you have acceptable data from the aplay output.
<ogra> right, you need a proper driver
<sveinse> Well, I wouldn't be surprised if I found bug in the driver. But this is one in our team, so I'll yank his chain if its not working. In all cases I need to actually prove that its the ALSA driver which doesnt work
<sveinse> Regardless, aplay reports:
<sveinse> card 0: mcbline [mcbline], device 0: AIC23 tlv320aic3105-0 []
<sveinse> card 1: mcb1681 [mcb1681], device 0: PCM1681_STREAM PCM1681-0 []
<sveinse> So, that's a good starting point
<persia> That ought be enough.  Try creating an ALSA profile against those strings, and see if it loads.
<sveinse> persia: How do I verify it?
<persia> Your sound will work :)
<sveinse> hahah lol
<sveinse> whooh.. googling for alsa profile docs...
<sveinse> hmm. What to put into my ALSA profile?...
<persia> Take a look at some of the other files there: you probably want to identify your controls, at the least.
<sveinse> Yes, I'm looking at the omap4
<sveinse> One thing though. In 00main it sais "CARDINFO{driver}=="OMAP4", INCLUDE="omap4", GOTO="init_end""
<sveinse> While it parses two CARDINFO's in omap4
<sveinse> Is there a way I can dump these ALSA variables (driver, name)?
<sveinse> The aplay -l doesnt tell which is which
<ogra> cat /proc/asound/cards
<persia> That doesn't tell which is which either
<sveinse> Obviously wrong:  Found hardware: "" "" "" "" ""
<persia> I would have expected something similar to the aplay -l output: that's a driver issue.
<sveinse> Yes. Reading from 00main it sais:
<sveinse> ERROR="Found hardware: \"$cardinfo{driver}\" \"$cardinfo{mixername}\" \"$cardinfo{components}\" \"$attr{subsystem_vendor}\" \"$attr{subsystem_device}\"\n"
<sveinse> Hence the cardinfo information is missing...
<sveinse> Strange as aplay -l does report them
<persia> Probably an incompletely filled structure: long names provided, but not short names (as they aren't exposed to the UI)
<sveinse> persia, do you know of a omap soc kernel driver which works good?
 * persia looks around the kernel tree
<sveinse> under sound/soc/omap
<persia> If I recall correctly, sdp4430 got a lot of attention a few months ago, and probably represents the best-tested example of what is known to work throughout the stack
<sveinse> thanks. If you run aplay -l on your device, how does the "card 0: ..." line look like?
<sveinse> My target sais: card 0: mcbline [mcbline], device 0: AIC23 tlv320aic3105-0 []
<sveinse> While my host sais: card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
<sveinse> Note the last [] missing the text
<persia> I don't currently have a running target with a recent Ubuntu kernel.
<persia> ogra_
<persia> ?
 * persia should upgrade something this weekend
<ogra> well, the panda operates on the stuff bhind the first colon in /proc/asound/cards
<persia> ogra, Do you happen to have the string handy?
<sveinse> Hmm. /proc/asound/cards:
<sveinse>  0 [mcbline        ]:  - mcbline
<sveinse>                       mcbline
<sveinse> While from host:
<sveinse>  0 [Intel          ]: HDA-Intel - HDA Intel
<ogra> ogra@panda:~$ cat /proc/asound/cards
<ogra>  0 [Panda          ]: OMAP4 - Panda
<ogra>                       TI OMAP4 Board
<sveinse>                       HDA Intel at 0xf6fdc000 irq 48
<persia> It's the bit before the '-' that seems to be the critical bit.
<persia> Same emptiness in several views.
<ogra> your driver misses proper naming
<sveinse> Aah. So the ]: OMAP4 <-- is the important stuff here
<persia> ogra, Thanks
 * sveinse wish he had a running panda board to compare against. Would be easier to find the missing struct member...
<persia> I seem to remember sound on the beagle getting fixed also, but without quite the same level of exhaustive detail of discussion.
<persia> You might check that (unless someone says I'm completely wrong)
<persia> (this assumes you have a beagle board to compare against)
<sveinse> persia: Unforunately not
<persia> You might try asking in #alsa-soc: they know heaps about the details of what needs to be present (although they do tend to work at a level of detail that may be confusing)
<sveinse> thanks. I could take a look at the omap4 soc driver to find the "OMAP4" string. However the driver doesn't seem to be present in my kernel sources
<persia> Grab the Ubuntu sources: the ti-omap4 branch from git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git
<sveinse> Excellent!
<sveinse> persia, I have been diffing our driver and the sdp4430.c from natty. I have a theory why it doesnt work: Our kernel people are running 2.6.38, and the members "driver_name" and "long_name" doesn't long exist in the struct snd_soc_card.
<sveinse> Which could indicate that userspace alsa needs upgrade for everything to work :(
<persia> sveinse, Which userspace alsa are you running?
<sveinse> persia, well I'm running off maverick, so its 1.0.23+dfsg-1ubuntu4 for alsa-base
<persia> That ought be fine.
<persia> natty is 1.0.23+dfsg-2ubuntu1b1, which roughly translates to some packaging changes and a rebuild.
<persia> I believe 1.0.24 is coming to natty soon, but I doubt aged userspace is the issue.
<sveinse> Yet, the kernel driver has no driver_name and long_name which it seems is the missing fields from /proc/asound/cards
<persia> And there is one for sdp4430?
<sveinse> Yes
<persia> Maybe look at a maverick sdp4430 (2.6.35-903.21 or so)
<persia> My understanding is that it works in maverick.
<persia> (if it's not in the ubuntu-natty.git tree, check ubuntu-maverick.git)
<sveinse> I'm cloning the ubuntu-maverick git as we speak
<sveinse> takes a while
<persia> I'll wish you luck: I'll be away for the next 30+ hours.
<sveinse> persia: Thanks
<ericb2> hello
<ericb2> I tested the netbook version with my Beagleboard xM rev2 (OMAP3 ) , and after "Uncompressing Linux ... done, booting the kernel"  I got nothing : stalled
<ericb2> I used: the image found here : https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<rsalveti> ericb2: that's normal, by default there are no output at the uart
<rsalveti> but you should see something at your dvi output
<ericb2> rsalveti: does xdmi work ?
<ericb2> rsalveti: I tested, and nothing so far, but maybe I did something wrong
<rsalveti> hdmi you mean?
<rsalveti> on xm just the connector is hdmi, but it's dvi-d
<rsalveti> you should see the resizing and then the installer
<ericb2> rsalveti: sorry, you're right  : xdmi
<ericb2> rsalveti: I'll retry ..
<rsalveti> https://wiki.ubuntu.com/ARM/BeagleEditBootscr if you want to enable the console
<rsalveti> check "Notes about the process" at the page you posted the link
<rsalveti> there are some useful information about the process there
<ericb2> rsalveti: thank you very much
<ericb2> rsalveti: I'll read carefully
<ericb2> rsalveti: btw, will you attend FOSDEM ?
<rsalveti> nops :-(
<ericb2> rsalveti: I'll attend on sunday
<rsalveti> maybe ogra will
<rsalveti> too far for me
<ericb2> rsalveti: ok. I'll probably take my beagleboard with me
<ericb2> rsalveti: how to know things are ok ? The hdmi does seems to no longer work. Can this be a resolution issue ?  I remember I had 1024x768@60 working or something close
<ogra> i wont make it to fosdem
<ogra> already on the road the last week of feb ... my GF would kill me if i also went to fosdem
<ogra> :)
<rsalveti> ericb2: rev 2 should just work
<rsalveti> could be
<rsalveti> depending on your monitor
<rsalveti> as our default resolution is higher than that
<rsalveti> try editing your bootsrc
<rsalveti> and putting a lower resolution
<ericb2> rsalveti: that's what I'm currently doing. If if works I'll tell you
<rsalveti> ok
<lilstevie> what does "port's parent platform driver is not whitelisted" mean
<ericb2> rsalveti: just curious:  it is possible to use (mean simply copy) a working boot.scr ?
<ericb2> s/boot.scr/bootsrc/
<ogra> sure
<ogra> but it will be overwritten by whatever is in /boot/boot.script during installation
<ogra> so you should make sure they match
<rsalveti> yup, once flash-kernel (on a kernel update) is called /boot/boot.script will overwrite your boot.scr
<ogra> bug 517300
<ubot2> Launchpad bug 517300 in likewise-open "[armel] likewise-open needs porting to ARM" [High,Confirmed] https://launchpad.net/bugs/517300
<sveinse> I have no idea how to get this alsa profile thing going, nor can I find anything wrong with the alsa driver
<sveinse> ogra, are you sure alsa profile is the way to do pulseaudio configuration? AFAICS its only PA which complains. Everything else done directly against alsa seems to like it should
<ogra> PA complains because it doesnt find the right thing to attach to
<ogra> fi you use a PA profile you cure the symptom but not the root cause
<sveinse> I found this: http://www.omappedia.org/wiki/Ubuntu_PA
<ogra> thats super broken
<ogra> and we fixed it properly for the panda
<ogra> by fixing the driver and alsa-libs
<ogra> in natty audio works out of the box that way
<sveinse> ogra, I agree. But when alasctl init doesn't get the correct descriptors and the kernel soc-audio interface has changed, I'm running out of ideas how to fix
<ogra> we will add PA profiles for special cases like automatically switching audio out to HDMI for example, but the basics work out of the box without PA tinkering
<ogra> and thats how it should be
<sveinse> I've checked both natty and maverick omap4 kernels, and both of them has the extra text fields (if that is what's wrong then)
<sveinse> But the latest 2.6.38 does have these fields
<ogra> right, make soure your driver has that too
<sveinse> no, the struct have changed
<ogra> then you can reate an alsa init file
<ndec> sveinse: hi. sorry to interrupt ;-) what exactly are you trying to do/
<ogra> that way will become the default soon with UCM
<ogra> ndec, getting a custom omap3 board to properly do sound
<ndec> ogra: argh.. .omap3 ;-)
<ogra> heh
<sveinse> ndec, My custom maverick omap3 board doesn't detect my alsa drivers
<ndec> UCM should help OMAP3. someone will just need to write the correct config files
<ndec> sveinse: you mean the kernel or Pulse does not detect it?
<ogra> the kernel doesnt even name the card
<sveinse> ndec, sorry a little too quick here: Yes, pulse doesn't detect it. alsamixer and aplay works
<sveinse> cat /proc/asound/cards
<sveinse>  0 [mcbline        ]:  - mcbline
<sveinse>                       mcbline
<sveinse>  1 [mcb1681        ]:  - mcb1681
<sveinse>                       mcb1681
<sveinse> so the guys at pulseaudio suggest writing a udev rule to point to a profile
<sveinse> yet, the nice people here suggest otherwise
<ndec> sveinse: which version of ubuntu are you targetting?
<sveinse> ndec, currently maverick. But we'll switch to natty when its a little more stable
<ndec> sveinse: as ogra said, ALSA UCM is coming into natty, we are planning to get basic UCM integration in pulseaudio as well.
<ogra> alpha2 came out yesterday
<ogra> its pretty smooth
<ndec> sveinse: that is clearly the cleanest solution, but that might take a little while until UCM is available in pulse.
<sveinse> is USM something which must be patched into the kernel?
<ndec> sveinse: no. it's alsa user space changes only.
<ndec> sveinse: it's new alsa API that makes it simpler to manage Use Case (hence the name)
<sveinse> It's good to know. However, it doesn't fix my current problems though
<ogra> well, i think your ASoC driver needs to at least support detection
<ogra> even for UCM
<ndec> sveinse: you have config files where you define your cards profile (headset, headphonem hdmi, ...), and you select which profile to use with this new alsa API.
<sveinse> Yes, agree. However theres so much I can do when the struct members change...
<ndec> sveinse: well you update the config files ;-)
<sveinse> I've read the kernel sources and the "driver_name" and "long_name" fields have been removed from the kernel headers
<sveinse> ndec, I have started on a alsactl script/profile
<sveinse> However alsactl init sais 'Found hardware: "" "" "" "" ""'
<ndec> sveinse: ok, that's what we had initially for panda before it got fixed properly by ogra
<ogra> that reflects your /proc/asound/cards
<ogra> i only fixed the userspace
<ogra> well, actually i only included fixes from others in the right places :)
<ogra> these fixes still relied on the proper driver namings
<sveinse> Yes, and I found this in sound/soc/omap/sdp4430.c
<sveinse> static struct snd_soc_card snd_soc_sdp4430 = {
<sveinse>          .driver_name = "OMAP4",
<sveinse>          .long_name = "TI OMAP4 Board",
<sveinse> But member .driver_name and .long_name is not present in struct snd_soc_card as of 2.6.38.  I think that's my problem
<ogra> MIGHT BE
<ogra> OOPS
<ogra> sorry for caps
<sveinse> that's ok (I hoped you weren't angry for repeating my questions :)
<sveinse> Let me rephrase: you are now aware of any struct/interface changes to recent kernels which would mandate changes in alsa clients?
<sveinse> s/now/not/
<ogra> no, i havent looked at the kernel in natty yet
<ogra> lrg might be able to answer whats needed for UCM in your driver though
<sveinse> I have cloned the ubuntu-natty kernel (for ti-omap4 branch)
<ogra> he is ASoC upstream (but not always around)
<sveinse> ubuntu-natty has the missing members
<sveinse> but that's 2.6.35-3
<ogra> yeah, dont look at that one ;)
<ogra> it is good for maverick ... for natty there will be a new one
<sveinse> In my search for a temporary solution: Do you know how a udev rule should be formatted for a soc alsa card?
<ogra> nope
<ogra> ask the guys that suggested that
<ogra> (which i suspect are fedora devs :P )
<NCommander> janimo: did you 4.4 build pass?
<ogra> NCommander, where is yours at
 * sveinse stuck between a hammer and a hard place :P
<ogra> his did
<ogra> we are looking for your comparison data from the full build
<NCommander> ogra: FTBFS, but due to user error during the night.
<ogra> gah
<NCommander> ogra: yeah
<ogra> stop sobbing on your panda while you sleep :P
<NCommander> ogra: but it makes those fun blue flashes when I do!
<ogra> lol
<ogra> well, monday than
<GrueMaster> More like drunken debauchery.
<ogra> *then
<ogra> GrueMaster, stop giving him beer !
<ogra> especially the strong self brewed one
<GrueMaster> Beer, pfft.  We has Vodka!
<NCommander> ogra: GrueBrew is the only flat beer I ever experienced :-(
<ogra> NCommander, i have other bad news for you to make your morning even prettier :)
<NCommander> ogra: -_-;;;
<NCommander> what?
<ogra> NCommander, zul asked for help with bug 517300
<ubot2> Launchpad bug 517300 in likewise-open "[armel] likewise-open needs porting to ARM" [High,Confirmed] https://launchpad.net/bugs/517300
<ogra> he handles upstream and the package went back to -server now
<NCommander> ogra: oh, thats straightforward (if a bit tedious)
<ogra> but he needs help so that the patch applies cleanly to new upstream
<ogra> i dont think its super urgent but having it sorted by release would be good
<ogra> please talk to zul about it
<NCommander> ogra: will do
<ogra> thanks :)
 * NCommander tries another qt4-x11 test build
<ogra> NCommander, so janimo's build with 4.4 exposed the same issues
<NCommander> ogra: I thought you said his 4.4 build worked
<ogra> thats why we need to have yours to verify its not something thats linked in from other files
<NCommander> hrm
 * NCommander checks somehitng
<ogra> no, i meant it built and showed (from his perspective) that its not 4.4
<ogra> or not 4.5
<ogra> however you want to put it
<NCommander> hrm
<ogra> so a full package build to prove that is needed
<ogra> then we can hassle upstream QT
 * NCommander has a theory ...
<NCommander> janimo: can you do a partial rebuild, but drop the kubuntu_22_thumb patch while I do a full rebuild, and try that?
<ogra> can we first follow the plan we worked out before we drop other patches ?
<ogra> i mean jani is done with his part he can surely move forward there but we need your package too
<NCommander> ogra: I am
<NCommander> ogra: but I just want to test that theory
<ogra> yep, understood
<ScottK> It's not going to build without the22_thumb patch I don't think.
<NCommander> ogra: since I broke the qt4-x11 build on maverick (gcc-4.4) with that patch
<NCommander> it might be causing a false-negative
<ogra> NCommander, well,, we first need proof for janis results
<ogra> one step at a time
<janimo> NCommander, isn't that patch the IT one?
<ScottK> It is
<janimo> ogra, I still have things to check. This bug bothers me so much I cannot let it rest
<ogra> janimo, i didnt say you should let it rest ;)
<NCommander> janimo: yeah, since when it was applied it caused explosions on Maverick
<ogra> janimo, but we need comparison data
<ogra> NCommander, when was it applied ? i run unity-2d just fine on maverick with the QT from -updates
<ScottK> That patch content doesn't exist in maverick
<ScottK> Maverick didn't need it due to implicit IT.
<ogra> how did it cause explosions then ?
 * ogra doesnt get it
<ScottK> Not sure.
<ScottK> IIRC there's a patch of the same name in Maverick, but with different content.
 * ScottK checks
<NCommander> ogra: I applied it ot a maverick build of qt-4.7.0 and it caused a segfault similar to the one we were seeing
<ogra> ah
<sveinse> ogra, where can I find a recent omap4 kernel for natty?
<ogra> sveinse, nowehere yet
<ogra> whats in natty is the most recent we have
<GrueMaster> sveinse: In natty, we are currently still on 2.6.35
<ogra> there is a linaro build from upstream but that wont work much and afaik doesnt have any sound stuff yet
<ogra> the .38 port is in the works but will still take a while
<sveinse> go figure
<GrueMaster> There is a .38 kernel for omap3 though.
<sveinse> GrueMaster: How does a omap3 .38 system look like in respect of /proc/asound/cards
<sveinse> Anyone running .38 here?
<sveinse> I curious to learn if there indeed are changes to the overall soc alsa system, or if the problems are related to our system only
<GrueMaster> sveinse: http://paste.ubuntu.com/562698
<sveinse> same thing as I'm seeing. That's somewhat comforting
<sveinse> you have pulseaudio running on this system?
<ogra> not if you know that audio is currently not working on omap3 in natty ;)
<GrueMaster> Yes, although pulse currently can't control the volume.  Had to do that manually in alsamixer.
<ogra> it also waits for UCM
<GrueMaster> playback is ok.
<sveinse> GrueMaster, that's *exactly* my problems as well
<ogra> please dont jusdge by the half done audio in omap3 in natty yet
<ogra> thats being worked out
<ogra> (by lrg)
<sveinse> no, but the symptoms are equal
<ogra> yes, but that doesnt help you in any way
<sveinse> GrueMaster, what happens if you run alsactl init on your system?
<ogra> UCM isnt ready yet and the driver needs adjustment
 * ogra sighs
<GrueMaster> sveinse: If you can get audio to at least work with alsamixer & aplay, pulse playback should work.
<GrueMaster> If not, there are sink issues.
<sveinse> ogra, true. And I'm considering the pulseaudio profile "fix" (to call it that) as a temporary workaround until UCM arrives
<ogra> might be your way to go if you cant fix the driver the same way we did in maverick
<sveinse> GrueMaster: Yes, but we need HW volume control. With SW volume control you lose resolution
<GrueMaster> sveinse: I understand.  Just saying that sometimes you need to take it one step at a time.  If you have pulse playback, that's half the battle.
<sveinse> GrueMaster: Agree, but not my boss. He needs full fledge audio with volume control
<sveinse> ogra, because we're on .38, it isn't that easy as the required driver fields are removed. Which GrueMater now confirms
<ogra> if you want to use natty, wait for UCM and possible additional fixes to ASoC, if you want to use maverick either fix the driver like we did for omap4 or go with your workaround
<ogra> i would expect these fields to return in some way or the other
<sveinse> release is still a year away, so we will have the opportunity to jump to natty and UCM
<ogra> or UCM to handle it without name
<GrueMaster> sveinse: You could get a jump on UCM by pulling the 1.0.24 tarballs from alsa-project.org.  Or waiting for them to show up here in a week or so.
<sveinse> ogra, I do too. It wouldn't surprise me to see that the alsa user tools need change for .38
<ogra> they did already
<ogra> they are just not in the archive yet
<sveinse> in a week or so... for natty then?
<GrueMaster> That's the plan as I understand it.
<GrueMaster> We had a soft freeze for Alpha 2 release.
<GrueMaster> And alsa 1.0.24 was just released late last week.
<sveinse> How natty doing? I'm eager to switch, however I can't break everyone's system. That would be expensive
<GrueMaster> Alpha 2 is very stable on beagle/xm, and panda.  But we will be switching the UI as soon as we can fix the QT issues.
 * ogra is afk now
<sveinse> Talking of Qt issues: what are those?  We are running qt on our system (but against qws though) and have had issues. perhaps I can contribute with something?
<rsalveti> what kind of issues are you having?
<GrueMaster> We are currently seeing a segfault in the core libraries on natty.  Works fine on Maverick.  Problem is the 25 hour build times.
<GrueMaster> Hard to narrow down the bug with long build times.
<rsalveti> sveinse: I believe yours could be more related with qws
<rsalveti> don't know if it's well tested and etc
<sveinse> ah, you build natively, right
<rsalveti> yup :-)
<GrueMaster> sveinse: Here's the bug we are tracking if you are interested.  Bug 705689
<ubot2> Launchpad bug 705689 in qt4-x11 "unity-2d-launcher crashes with segfault error on armel (natty only)" [High,Confirmed] https://launchpad.net/bugs/705689
<GrueMaster> And I should change the description to "QT Apps crash..." as we can reproduce it with other programs.
<sveinse> well, atm qt-qws is working ok (not perfect) for us. We still have opengl integration issues (thank you Imagem)
<sveinse> I just *love* the binary driver thingy
<sveinse> Some of the guys in our project told me they had problems compiling Qt properly with the ubuntu/linaro gcc, while the CSL works perfectly. It smells similar when reading the 705689 bug
<sveinse> sorry for not have more elaborate details, and I don't have any repeatable procedures to back up my claims
#ubuntu-arm 2011-02-05
<Sonny80> hello
<Sonny80> i have problem with ubuntu an beagleboard c4
<Sonny80> after executing minimal-xfce.sh i cannot switch from console to x session. Ctrl+Alt+F1 and Ctrl+Alt_F7 - the system starts from login screen and previous X session is lost
<ogra> what the heck is minimal-xfce.sh ?
<Sonny80> oh.. its script from /boot/uboot
<Sonny80> that installs xfce4 on minimal ubuntu
<ogra> surely not on any ubuntu images
<Sonny80> that is on rcn-ee image
<ogra> not sure what you got there, but that rather sounds like something hommemade and you should contact the author
<Sonny80> as i understant the author is rccn-ee?
<Sonny80> rcn-ee
<ogra> so contact him or wait until he is around here
<ogra> oh
 * ogra notices the topic is outdated
* 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 | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? http://42.pl/u/2u8U | Natty alpha 2 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-2/
<rcn-ee> Sonny80, the minima-xfce script just installs 'xfce4 gdm xubuntu-gdm-theme xubuntu-artwork xserver-xorg-video-omap3' so what's it not doing?
#ubuntu-arm 2011-02-06
<KC9SJQ> Howdy all, I wonder if I can get help with a question.
<KC9SJQ> I am running a pandaboard with ubuntu 10.10, and have just installed a new Samsung CLP-325 printer
<KC9SJQ> In printer and server settings, I turn on all sharing.
<KC9SJQ> On a second computer, an asus 1015 (intel atom 450) running ubuntu x86 10.4, I can see the shared printer when I "Find a network printer" and give the ip, but from the laptop, attempting to print the test page gives a "Printer Not connected" error
<KC9SJQ> Thoughts?
<KC9SJQ> Anything?
<persia> KC9SJQ, You might try #ubuntu : nothing should be different because you're on a pandaboard or even running ARM.  Be warned it's fairly crowded and busy there.
<KC9SJQ> Yeah, I've been there before
<KC9SJQ> I just wanted to make sure that there was nothing endian based in the cups protocol that could cause an issue.
<KC9SJQ> Thanks, persia
<persia> armel is the same endianness as i386 :)
<persia> That said, there *might* be an issue with miscompilation or similar, but that's a bit more unlikely.
<KC9SJQ> well, so much for that consern
<KC9SJQ> hehe, thanks.
<persia> The other option would be to upgrade the 10.04 system to 10.10 so you are working with the same software stacks, and then see if you can find a difference.
<persia> I don't know anything about the printer stack, so can't help you precisely, sorry.
<KC9SJQ> Well, I'll do so next time I'm in the office (faster internet, slow here, none at home) just to throw that out.
<KC9SJQ> Thanks for your advise
<persia> Good luck.
<sveinse> Do you guys know of a good book about the debian package system? The rest of my team would appreciate it...
<persia> sveinse, Is if being offline the important part?  What sort of material do you seek?
<sveinse> some text material for teaching the team of how the apt repo is constructed and how deb pkgs are created. A book would be nice, simply because it's easier to read for first timers than a reference sheet :D
<persia> I don't know of any good books on it, and I've been vaguely suspicious of the idea, as it is continually evolving.
<sveinse> I myself had great support from a debian book with a chapter about deb pakaging many years ago
<persia> http://www.debian.org/doc/maint-guide/ tends to be fairly up-to-date, and structured to read through.
<sveinse> I agree, and the picture isn't as clear as one would expect as there are many ways to rome in the dpkg world
<persia> Oh, indeed.
<persia> The concepts tend to remain the same though, at least for the basic changelog, control, copyright, and rules.
<persia> What goal do you see as the end-state for people having learned stuff?  Creating new packages?  Patching packages?
<sveinse> Well. Quickly explained we are creating a commercial (embedded) product, where we chose to use Ubuntu. One reason for Ubuntu was its target for armv7 and that it's using the well-developed deb/apt distribution which solves *a lot* in terms of after sales support and upgrade.
<sveinse> Now, today we have focused on getting the prototypes up and running, and thus all our code exists as compiled code outside of any debs. The next month, I need to transfer this code into deb packages. So the goal would be that our team can learn to make and buld deb pakages
<ogra> http://www.debian.org/doc/devel-manuals
<ogra> lots of pdfs
<persia> Oh, that's all?  For software for which you are the original developers?
<sveinse> There will be three categories of packages: ubuntu vanilla (unmodified), modified pacakges and our own custom.
<sveinse> The two first are easy. apt-get source and then modify it is the easy part
<persia> unmodified is trivial.  custom is incredibly easy.  modified is hard.
<persia> May you always select such benign packages to modify :)
<persia> But if it's your own code, it's easy, as follows:
<persia> 1) make a release tarball
<persia> 2) name it ${SOFTWARE}_${VERSION}.orig.tar.gz
<persia> 3) unpack it
<persia> 4) create a directory "debian"
<persia> 5) cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules
<persia> 6) create a debian/copyright file: http://dep.debian.net/deps/dep5/ is a reference but once you have one, the rest are likely to be copy & paste
<persia> 7) create a debian/control file: http://www.debian.org/doc/debian-policy/ch-controlfields.html lists all the useful fields.
<persia> 8) echo 7> debian/compat
<persia> 9) `dch --create` to create a debian/copyright file
<persia> 10) `debuild -S -us -uc` to create an unsigned source package.
<persia> There's some work ongoing to more aggressively automate generation of debian/copyright, but at this point it seems mostly to be talk about it: I've seen scripts, but nothing very formal yet.
<ogra> 9 is wrong :)
<ogra> you mean debian/changelog there ;)
<persia> There's been a lot more work to automate generation of debian/control, but everything I've seen has been implementation language specific.
<persia> ogra, Oh, heh.  Command is right, explanation is wrong.
<sveinse> persia, thanks. Then the more difficult parts (for me as some kind of sys.admin to this):
<persia> This is what I get for trying to type my 10-steps-to-package-anything instructions from memory when I ought to go to bed :)
<ogra> heh
<sveinse> 1) I need to copy the official debs to our own repo (since we have ultimate product responsibility). I'm working on a tool I've named "apt-fetch" to get and build a debian repository from a --get-selection list
<sveinse> 2) The steps above is for native building. The management wants us to use the build farm and not native compilation. Hence I'm planning on looking into xdeb & friends
<sveinse> 3) Setup our own build server for rebuilding & uploading the packages
<persia> I don't have any good solution for 1) .  For a while, there was a package called "falcon" in the archives that was a sensible small archive management suite, but it's gone.
<ogra> the above has notrhing to do with native/non-native
<ogra> its just to create a debian source packge
<persia> Regarding 2) the steps above are entirely about building a source package.  How you create the binary package is entirely up to you.
<sveinse> persia, 1) is actually not so hard. I'm considering publishing the tool to the community later on it there are any interest for it
<persia> I believe that you end up with a package that ought respond well to cross-compilation with those instructions (although I actively discourage the use of cross-compilation)
<persia> sveinse, There's regular interest in a small archive management suite, as dak or Soyuz or similar are painful, and there are too many variants of hackish scripts using apt-ftparchive and similar.
<persia> But the issue in the past has usually been that nobody who wasn't running a distro wanted to maintain it, and most of them don't scale to running a full distro.
<persia> For 3), debomatic is one of the easiest ways to set up an automated build environment: https://launchpad.net/debomatic
<sveinse> The tool I'm writing (in python) is taking a sources.list and a --get-selections list, and it downloads everything from the servers building exact same file structure as used on the servers (hence pool/ and dists/). Releases and Packages are however stripped for non-relevant packages.
<persia> It doesn't currently have built-in cross-compilation support, but there's some docs on how it might be implemented, and it's based on pbuilder, which has lots of hooks.
<persia> Are you aware of the apt-fetch on CPAN?  It does something entirely different, but has a similar name.  If you want to popularise your suite, I'd suggest a different name.
<sveinse> persia, no I don't. Thanks
<persia> Also, while that's useful in terms of creating a partial mirror, it will need some extension to be able to handle updates with new packages and resign, etc.
<sveinse> Yes, I plan to add that. We will pull updates from the ubuntu repos a regular intervals, so we need to handle that exact situation
<persia> Also for your customisations, etc.
<persia> I don't tend to follow them that much, but you might check with the gNewSense or Mint folk, as some of the more complex Ubuntu derivatives who maintain their own repositories: they may also have useful tools.
<sveinse> Regarding cross compilation of ubuntu, we actually were capable for putting together a working system for compiling apps
<sveinse> Basically we create a rootfs with rootstock and then unpack one on the host computer and installs everything needed for dev on it. The compiler's --sysroot handles that kind of building perfectly (for us).
<sveinse> However the new of --sysroot being a mistake in the cross compiler were a blow to me.
<sveinse> hrw has indicated I should use xdeb instead, but I havent gotten around experimenting with it yet
<persia> That's not a very safe way to build packages, because of build-dependency management.
<sveinse> Sure, we did that to SW not having any debian dependencies yet
<persia> The worry is that it will build against whatever headers or libraries you happen to have in the rootfs.
<persia> For Ubuntu, we try to build packages in a minimal environment, so as to reduce the chance of unexpected library linking, etc.
<persia> I suppose it depends how aggressive your precompilation configuration automation is: if you're using autotools to maximal advantage, it can end up making a lot of difference.  If you have a very basic Makefile, it matters less.
<persia> xdeb is definitely interesting, and worth looking at, but you may find that you want to bundle that inside pbuilder or sbuild or something to assure build repeatibility and clean builds.
<sveinse> all deps is manual as of today. I should mention we base the applications SW on Qt (w/qws) which we must build ourselves
<persia> Why must you build it yourselves?
<sveinse> I haven't decided if we should let the developers build the binary packages (manually) or I we need to invest in an automated source->binary build server
<persia> I strongly advise investing in an automated source -> binary build server.
<sveinse> Well, I haven't found qt in ubuntu without X11
<persia> The software side is easy (see debomatic above), and it avoids opportunities for an unbelievable array of potential mistakes.
<persia> Ah, if you don't want X, that's trickier.  Yeah, I'm not sure we do that.
<persia> We specifically don't intend to support embedded use (in the sense of small devices intended to be part of a larger system), but rather focus on devices expecting full interaction (phones, handhelds, tablets, laptops, desktops, servers, etc.)
<sveinse> So for the overall view of this, you'll all have to excuse me for asking a lot of question. There's a lot of things to take up on this (being ubuntu, non-native enviroment, build server, etc.)
<persia> Asking questions is fine.  That's why there is this channel.
<persia> Mind you, there's a price: we're expecting you to answer the same questions when someone else asks them later :)
<sveinse> that's fine! and likewise, being a commercial product, we intend to honour every obligation in respect of FOSS licenses.
<persia> Oh, excellent!  That's always lovely to hear.
<persia> Can you share the form-factor yet?
<sveinse> I can't tell much. Two devices, one deeply embedded (box with connectors) and one display unit with 5.7" display with capacitive touch. All based on omap3
<persia> Oh nifty.  When it gets announced, please share the URLs.
<sveinse> These are a system, and thus the customer will not know the presence of Linux nor ubuntu
<sveinse> Sure. Trust me, as an engineer on this, I'd love to share. But not yet
<persia> Indeed.  Sounds like something for factory automation or in-vehicle use, or similar (no, don't give me hints).
<persia> That said, if you're building an open platform, I'm sure we can find ways to repurpose it, if we like the shape :)
<sveinse> :D tivoization will always be an issue/opertunity (depending on which side of the table you're on)
<persia> If you're doing it that way, take extra care with the licenses: there's heaps of GPL3 code in Ubuntu that you'd want to work around.
<persia> But this has been a really long 5-minutes-check-backscroll-before-I-sleep, so I'll catch you another time.  Good luck with your training and setup of your build/distribution system.
<sveinse> persia, thanks a lot. It's been a pleasure
<ericb2> since some days, I'm testing the ubuntu pre-installed for omap3
<ericb2> the problem is the hdmi resolution
<ericb2> I'm not that rich, and my screen is 1024x768
<ericb2> the image tries to start using 1280x720 or something
<ericb2> so I folllowed this page: https://wiki.ubuntu.com/ARM/BeagleEditBootscr
<ericb2> everything went fine, I modified the boot.scr  (located in the vfat partition .. and so on
<ericb2> and the result is "resolution not accepted"
<ericb2> how can I change the resolution for true ?
<ericb2> I must add : both maverick and natty give the same issue
<ericb2> the card is beagleboard xM , perfectly working with Angstrom shipped with
<ericb2> xM v2 / A8 / no NAND / 512 MB RAM  , and so on
<ericb2> thanks in advance for any hint
<Baybal> omaps modesetting code sucks
<ericb2> Baybal: I followed ubuntu way, but maybe I did something wrongly ?
<Baybal> simply code is somehow weird
<Baybal> it needs rewriting
<Baybal> it's 5 minutes jib, yet nobody made it
<ericb2> Baybal: do you have links ?
<Baybal> no
<ericb2> Baybal: I'm trying to setup the BB, because I'd like to port a big software on ARM family, so I'm simply stuck at the preliminary steps
<ericb2> Baybal: but I can try to help  (if I got the skills)
<Baybal> you need to hack into omapfb
<ericb2> Baybal: ok
<Baybal> ideally it should be able to reinitialize the hardware and set sane video mode
<Baybal> preferably basing on data from ddc
<ericb2> Baybal: I'll start with adding the serial, per see what exactly happens. In fact, I'm not sure the bad resolution is the only issue
<ericb2> but this is a good candidate
<ericb2> imho
 * ericb2 just wondering why things work well with Angstrom, and not with Ubuntu 
#ubuntu-arm 2012-01-30
<Snark> plop
<Snark> doko, I would like to help on https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/713985
<ubot2`> Launchpad bug 713985 in eglibc "[armel] Function tgammal has precision issues in version 2.12.1-0ubuntu10.2 on ARM" [Undecided,Confirmed]
<Snark> doko, if you have a clue about the problem but no time to work on it, I'll take the clue and try to do something with it
<Snark> if you have no clue, I'll just try anyway :-p
<doko> Snark, I won't work on it. first thing might be to recheck with 2.13 and 2.15
<Snark> it's still there with 2.13
<Snark> where can I get 2.15 ?
<doko> in the ubuntu-toolchain-r/glibc ppa
<Snark> and there is an armel package too?
<Snark> aie
<Snark> found it
<Snark> hmmm... adding the ppa isn't enough :-/
<Snark> it basically wants to remove the rest of the system
<Snark> doko, the only place where I find lgammal mentioned in eglibc_2.13-20ubuntu5.diff.gz is in a patch for sysdeps/ia64/fpu/libm_error.c, so I guess the bug is upstream
<doko> you should debootstrap a precise chroot
<Snark> doko, I don't think I have enough room on this poor box :-/
<rbasak> How can I generate an installer uInitrd (as found at http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/uInitrd)? I'm trying to test different kernels with the installer.
<ogra_> rbasak, only by building the installer
<ogra_> which is highly complex
<ogra_> what exactly do you want to test ?
<rbasak> The current installer kernel panics on my panda sometimes. I've now automated a repeated test to find out if a given installer uImage/uInitrd is good or bad.
<ogra_> (if its only the booting of the installer you can just replace the uImage
<rbasak> ppisati asked me to test the latest kernel that is in the archive but not in the installer right now
<rbasak> and if it is I'll need to bisect
<ogra_> if its more than just booting it gets more complex since d-i uses the udeb packages your kernel build created during the package creation
<rbasak> Won't I need the modules in uInitrd though?
<rbasak> Yeah it panics some time in userspace after the kernel boots
<ogra_> ah, yeah, that would mean to roll d-i from scratch and make it use the newly created udebs
<rbasak> Surely there's a script somewhere that builds the installer? Or does that depend heavily on hitting the archive?
<ogra_> (and indeed that means creating the udebs, not sure that works in a cross way at all)
<ogra_> the "script" is a makefile in the installer source
<ogra_> in fact a ton of different scripts
<ogra_> that are used by that makefile
<rbasak> It hits the archive for the kernel I take it?
<ogra_> well... apt-get source debian-installer
<rbasak> I'll have a poke around, thanks
<ogra_> building it pulls in a lot of other packages, then takes the udebs (from the kernel and elsewhere) and generates the initrd from it
<rbasak> what I'd really like is an archive overlay system
<ogra_> there might be a way to pull in the udebs manually from tty4
<ogra_> as long as you manage to do the boot up to that point
<ogra_> (apt-install is the command to install udebs iirc, i havent touched the installer for a while)
<rbasak> Can I get to tty4 down ttyO2?
<ogra_> i dont think so, but on serial you can use the "back" option in the installer, that gets you to the menu where you can select the shell
<rbasak> ah ok, thanks
<rbasak> I wonder if I could just hack the uInitrd and insert the kernel modules manually
<ogra_> you could try indeed...
<rbasak> what can we do to get the installer updated to use the new kernel?
<kos_tom> hello
<kos_tom> is there a place with a known-working version of MLO+u-boot.bin+kernel+Ubuntu rootfs that works on BeagleBoard XM rev C, with USB and graphics?
<kos_tom> so far, we have something that boots, but no USB devices are detected (nothing in the kernel logs)
<Snark> doko, where are the file dependencies to be found in glibc's sources?! I don't know if my platform uses sysdeps/ieee754/ldbl-128/e_lgammal_r.c or sysdeps/ieee754/ldbl-96/e_lgammal_r.c...
<ppisati> GrueMaster: question, did you try to change eth0 mac address with latest omap3 kernel?
<GrueMaster> My latest omap3 kernel I tested had a serious bug with mmc.  Haven't tried anything later.
<GrueMaster> I'll check it shortly though.  What rev?
<GrueMaster> rbasak: Have you filed a bug against the kernel in the netinstaller for panda?
<rbasak> no
<rbasak> I was wondering whether to add a debian-installer task to the existing bug
<rbasak> I've been working on trying to test the latest kernel but that turns out to be quite complicated
<GrueMaster> Well, it appears to only affect armhf.  I just rebuilt a panda with armel no problem.  I'm checking my mirror now to make sure the two are in sync.
<GrueMaster> They appear to be.
<ogra_> would be hard fro them to be out of sync :)
<ogra_> (same source and d-i would ftbfs if they werent the same version)
<GrueMaster> you haven't seen my mirror.
<GrueMaster> It occasionally gets out of sync with ports.u.c.
<GrueMaster> Hmmm.  armel failed on the same platform as armhf, but one machine reimaged with armel just fine.  This may need further research.
<ppisati> any output?
<GrueMaster> ppisati: http://paste.ubuntu.com/822806/
<ppisati> GrueMaster: this is the 1404 kernel, and that bug was fixed in 1405
<GrueMaster> Right, just odd that it fails on some of my platforms but not others.  And it appears to be older ones only (EA1, A1).
<GrueMaster> rbasak: While you are waiting for an updated netinstall, I have found that using the newer kernel with the exisiting uInitrd works fine for installing.  Running here now w/o errors so far, and it is into the base system step.
<rbasak> GrueMaster: that's great, thanks! I was writing a script to inject the newer kernel modules into an older uInitrd, but I can leave that for now then :-)
<GrueMaster> Yea, I'm not sure what modules get loaded during netinstall, but obviously no critical modules.
<rbasak> GrueMaster: I'm getting occasional failures on armhf with a hand-built latest git tree kernel on armhf. But quite rare, and unhelpfully the error message is reported to be in syslog, which I can't get to over ttyO2.
<rbasak> GrueMaster: I'm running the install in a loop, I'll see tomorrow what the success/failure proportion is.
<GrueMaster> Try adding "earlyprintk=ttyO2,115200".
<GrueMaster> And make sure "quiet" is not in your boot.scr.
<rbasak> yes, i have those. It's a debootstrap failure
<rbasak> http://paste.ubuntu.com/823204/
<GrueMaster> Ah.  Well, there is a way to enable the web interface in the preseed so that you can monitor syslog from the web.
<rbasak> I've seen it twice now
<infinity> debootstrap failures are generally mirror/network issues.
<infinity> But you could skip doing this as an installer loop and just loop debootstrap a few dozen times.
<GrueMaster> I haven't seen this at all.  Can you past your preseed and I'll see if I can reproduce it here?
<rbasak> I'm running through a squid proxy, don't see any errors in the log though I might be missing it
<infinity> Squiq won't show errors, but the client system sure might.
<infinity> Stale caches can do horrible things to apt-like clients.
<infinity> (Not that debootstrap is apt, but it still verifies signatures and hashes, which means cache coherency (or no cache) is required)
<rbasak> preseed: http://paste.ubuntu.com/823207/ - it's got a proxy in there you might want to change
<rbasak> yeah but the previous and following installs work OK, so it can't be a stale cache problem
<infinity> Sure it can.
<infinity> If the timeouts are staggered enough, you'd have what appears to be a consistent mirror, followed by inconsistent, followed by consistent.
<GrueMaster> That is more than likely the issue.  I see issues occasionally here, and just rekick after my mirror update runs (every 2h).
<infinity> Assuming a mirror pulse in the middle, and getting one caches result and one fresh.
<infinity> s/caches/cached/
<rbasak> so we can't reliably run a netinst over a proxy cache? that sounds like an issue to me.
<rbasak> (I have Packages.gz etc. configured to be refreshed every time)
<infinity> And Release*?
<rbasak> refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz)$ 0 0% 0
<rbasak> refresh_pattern \/Release(|\.gpg)$ 0 0% 0
<infinity> On a stable release, it's much less of an issue, since we don't change the release pocket.
<infinity> But yeah, 99% of issues like this are usually a proxy's fault.
<infinity> The other 1% are actual broken mirrors.
<rbasak> thanks
<GrueMaster> I see it usually when installing at the same time my mirror is updating packages and hasn't finished updating all of the Packages.[gz|bz2] files.
<GrueMaster> So not as often.
#ubuntu-arm 2012-01-31
<nOStahl> hi guys
<nOStahl> hows it going
<StevenG50> New here,  Is the Panda board the only HW platform that you can purchase to expirement with ubuntu-arm?
<GrueMaster> No, we also support BeagleXM and Frescale Quickstart development boards.
<GrueMaster> You can also run any other armv7 (Cortex A8/9) compatible system if you have your own kernel.
<StevenG50> Any preferance as to which is the better board?  From a Performance, longetivity and/or ease of use point of view?
<GrueMaster> really depends on what you want to do.  BeagleXM is great for lightweight projects (Kiosk systems, cups server, etc).  Panda is a dual processor with HD Video capabilities, Frescale has SATA for better disk I/O.
<GrueMaster> All are fairly easy to use.
<StevenG50> That is the best information anyone has provided me yet.  Gets me something to think about.  Thank you!  I must admit my interest is morbid curiousity.  I dont know what I want to do with it, other than just something to expirement/test with.
<GrueMaster> Heh, I understand.  I have several of each for Ubuntu testing.
<twb> pfft disks, just push it out to the san ;-P
<twb> They all have gige right?
<GrueMaster> No, 100e,
<twb> lame
<GrueMaster> Can't ask too much for a cell phone proc.  :P
<twb> Oh I can ask
<twb> OTOH why would a cellphone need SATA
<GrueMaster> Last cycle, I had 7 panda's in a CEPH cluster.  Painful, but still cool.
<GrueMaster> And SATA is far faster than SDHC.
<twb> But why would a cellphone need that
<twb> That's your argument against adding other whizzo features, right? ;-)
<GrueMaster> using a SATA based SSD vs eMMC?  Speed.  Pure unadultrated speed.
<twb> Pft, just load everything into ram
<twb> You only need the SD at boot time and nobody turns their cells off
<GrueMaster> No arm system ships with more than 1G.
<twb> 1G should be enough to 100 users!
<twb> grumble grumble
<GrueMaster> SOC vendors ship to anyone that wants a proc.  It is easier to have features disabled, than non-existent.
<twb> They should ship a disabled gige controller then :-/
<GrueMaster> I can see the Freescale part competing with Marvell for the small NAS box market.
<twb> A $200 NAS appliance ought to do gige
<StevenG50> is the Freescale demo board the I.MX51?
<GrueMaster> I think the nic is part of the USB controller.  It is on omap3/4.
<GrueMaster> mx53.
<StevenG50> I would imagine if you use the mx53 board the easiset thing would be to output via a serial port in ssh/telnet and skimp on the video module.
<recur> Anyone using an MX53?
<recur> I built the entire BSP, but I can't find the GPU driver.   Someone said it was gpu.ko  but it's not there.  Bit mystified :)
<jvcleave> trying to figure out how to ssh into Beaglebone with it installed https://wiki.ubuntu.com/ARM/OMAP
<recur> also hellogl_es2 starts up but the gl widget is black
<Snark> plop
<Snark> doko, how can I know which files are compiled in glibc? Looking at the Makefiles, I have no clue... for example in sysdeps/ieee754, there are *four* e_lgammal_r.c !
<trelane> greetings, with regard to rootstock, it now claims to be replaced by live-build (Which seems to generate iso's).  Is there a HOWTO that I haven't found yet for using live-build to build a root tarball
<trelane> greetings, with regard to rootstock, it now claims to be replaced by live-build (Which seems to generate iso's).  Is there a HOWTO that I haven't found yet for using live-build to build a root tarball
<trelane> basically I just need something to copy onto an SD card
<rbasak> overnight: 39 success, 9 failures (looks like the same debootstrap proxy/skew problem)
<ogra_> trelane, if you just want a minimal rootfs, have a look at ubuntu-core (it is totally unconfigured though)
<trelane> ogra_: noted.  I don't need a lot of config, though that looks like it includes some things I don't need
<ogra_> ??
<ogra_> it is the most minimal ubuntu you can build
<trelane> pulse, gtk, etc
<ogra_> by definition just enough OS to run apt
<trelane> ok Base Core = Core
<trelane> got it
<ogra_> no
<trelane> trying to figure out what Ubuntu-Core is based on the flow chart on the core website
<ogra_> i'm talking about the ubuntu-core tarballs you can get on cdimage.ubuntu.com
<ogra_> it contains everything debooorstrap --minbase installs plus apt and its deps
<trelane> ok, yeah that's small
<ogra_> has no users or rootpw configured nor does it have a network setup, hostname etc
<ogra_> tarball is around 30M... unpacked it should be between 80 and 120M
<trelane> ok that's no big deal at all.  I can script that and do the construction in qemu :)
<trelane> thanks!
<ndec> trelane: you might find that useful http://omappedia.org/wiki/OMAP_Ubuntu_Core
<trelane> ndec: already found it on my own
<trelane> reading it now
<ndec> hey, google is cool ;-)
<trelane> ndec: I'm actually an idiot, I merely have lighting fast google skills and therefore can fool most people
<trelane> you guys might want to put a note on the rootstock page that ubuntu-core is now the preferred solution
<ndec> i will update it soon with a section about using mainline kernel and uboot instead of the prebuilt kernel from ubuntu. but basically if you checkout any recent mainline, and build you can use that with ubuntu-core just fine.
<ogra_> ndec, there is a typo btw
<ndec> where?
<ogra_>   sudo C_ALL=C chroot . /bin/bash
<ogra_> should be LC_ALL
<trelane> I'm usually a Funtoo (Gentoo fork) guy, and after a few hours of looking at the OE build system, how they attempted to emulate gentoo, FAILED TOTALLY, then stuck somethign vaguely debian like on top, I gave up
<ndec> ogra_: let me check
<trelane> I don't know how OE happened but if there wasn't enough alcohol involved to stun a team of oxen... I'd be shocked.
<ndec> ogra_: fixed
<ogra_> great :)
<ndec> trelane: this is probably not the right place to talk about OE, even for bashing against OE ...
<trelane> noted :)
<ppisati> rbasak: did you manage to test the new kernel with the installer?
<GrueMaster> ppisati: I just ran netinstall as part of my milestone testing.  Seems to have run just fine.  I'll check the logs for any unnoticed residue.
<Riddell> GrueMaster: where can I find a basic intro to installing ubuntu on a pandaboard?
<ppisati> GrueMaster: cool
<GrueMaster> Riddell: I think there is a link off http://wiki.ubuntu.com/ARM
<infinity> Also linked from the image download pages on cdimage.
<ndec> ogra_: hi. on our private PPA we have a msg like that "A recent upload has resulted in 5 pending builds. " do you know what that means?
<ogra_> nope
<ndec> or davidm if you're around...
<ndec> ogra_: argh, not sure if it looks good or not. who should i ask?
<ogra_> i would assume your packages sit in the queue or some such
<ndec> ogra_: another problem is that now that we start pushing kernel in PPA, we are reaching the size limit quickly.
<ogra_> that shouldnt be a prob, though likely needs davids approval first
<ogra_> you could ask in #launchpad if they can just bump the size, if they need any additional approval we can manage i guess
<ndec> ok.
 * ogra_ takes a look at the queue if there is anything from you in teher
<ndec> ogra_: i asked on #launchpad too
<ogra_> ah, k
<ogra_> ndec, i see an alsa-utils build that has -ti in the version at https://launchpad.net/builders
<ogra_> (the PPA builders are the bottom ones)
<ogra_> seems the builders are busy beyond that, so it could well be that your packages are qeued
<ogra_> ah, now it also has totem and tibtfm
<ogra_> and uboot
<infinity> ndec, ogra_ : buildd-manager was down, hence the queued builds going nowhere.  Got fixed just a while ago.
<ogra_> ah, k
<infinity> ndec: As for increasing PPA size, that doesn't need any management approval or anything, just present a case for it to launchpad folks.
<infinity> (Though, they may require a slightly less hand-wavy case for non-Canonical PPAs demanding size bumps, I doubt yours will be an issue)
 * ogra_ thought so ... though it wouldnt have been a prob to get such approval indeed :)
<GrueMaster> ppisati: Did you see my earlier message?  I may have experienced an irc net-split.
<ndec> infinity: ogra_: thx. looks like our builds are going on now.
<ogra_> :)
<ndec> about the size, I will request for more indeed. will ask you if i need support
<ogra_> dont hesitate :)
<ndec> why would i ;-)
<ppisati> GrueMaster: nope, which one?
<ogra_> <GrueMaster> ppisati: I just ran netinstall as part of my milestone testing.  Seems to have run just fine.  I'll check the logs for any unnoticed residue.
<GrueMaster> Re:  omap kernel mac address.
<ppisati> GrueMaster: what's that?
<GrueMaster> ogra_: That was a lot earlier.
<ogra_> GrueMaster, oh, then your other messages went unnoticed
<GrueMaster> ppisati: On the omap kernel, you mentioned something about a change for the mac address? Is it just enabling the "smsc95xx.macaddr=" parameter in the module or is it getting the mac from the soc die id?
<GrueMaster> There, reposted.
<ppisati> GrueMaster: the second one
<ppisati> GrueMaster: it seems i can't change the mac anymore
<GrueMaster> Cool, thanks.  I'll double check it here and let you know how well it works.
<ppisati> GrueMaster: sudo ifconfig eth0 hw ether 00:11:22:33:44:55
<GrueMaster> Nah, just reboot.  If it stays the same, my dhcp server will know immediately.
<ppisati> k
<GrueMaster> While you're here, on omap4, is there a camera module built into the kernel now?  oem-config is trying to take a picture but there is no camera so it only has a small section of the previous screen.
<ogra_> it shouldnt offer you to take the pic in the first place if there is no camere attached
<rbasak> ppisati: no random panics after 48 test installs overnight. I'm using a kernel I built from the git source tree yesterday - not sure what the installer kernel is at the moment. So it's looking good.
<GrueMaster> ogra_: Hence why I asked.  If ubiquity is detecting a camera module, it is activating that section.
<GrueMaster> It doesn't do it on omap or mx5.
<ogra_> i guess it looks for the actual device in /dev
<ogra_> GrueMaster, look for /dev/videoX
<GrueMaster> yep.  /dev/video0 exists.
<ogra_> that might be it
<GrueMaster> Found it in dmesg.  "Linux video capture interface: v2.00"
<ogra_> crap ... i wonder how ubiquity should find out if there is actually a camera attached
<ogra_>  /dev/video0 might as well come from your TV card or some such
<ogra_> so that bug can happen on such setups too
<GrueMaster> That might be...interesting.  Have it take a snapshot of a klingon or something.
<ogra_> heh
<GrueMaster> So, I should file a bug against ubiquity for this?
<ppisati> GrueMaster: yep, there's camera support in it but it should be broken
<ogra_> GrueMaster, yes
<ogra_> if there isnt one already
<GrueMaster> ok.
<ogra_> i can easily imagine there are a lot video capture cards out there where people see it too
 * GrueMaster notes this will be the 4th bug filed in 2 days on ubiquity/oem-config.
<ogra_> awesome
<ogra_> to sad we dont have an ubiquity maintainer atm
<GrueMaster> ???
<GrueMaster> Where's Evan or Colin?
<ogra_> ev doesnt do it this release
<GrueMaster> Ah.
<ogra_> colin and stgraber step in for him though
<GrueMaster> I was looking at that code yesterday, trying to figure out preseeding.  What a mess.
<ogra_> it all becomes clear with enough alcohol in your blood though
 * GrueMaster needs to make an emergency run to the liquor store.
<GrueMaster> This camera module, how is it supposed to report no camera detected?
<ogra_> dont forget to expense it !
<ndec> GrueMaster: ogra_: we did get some problems with 11.10 when using a kernel with v4l2 camera driver on panda...
<ndec> some of our panda don't have the actual camera plugged, but the kernel does not detect that... and ubiquity tries to make a picture...
<ogra_> ndec, yes, we had issues in 12.04 too, thats why it was disabled
<ogra_> but not completely it seems
<ndec> on panda?
<ogra_> yep
<ndec> we have a horrible hack in ubiquity to bypass the camera detection... so if you come up with a proper fix this is better ;-)
<ogra_> well, as i said above, i dont get how that works on systems with TV capture cards
<ogra_> they surely also have /dev/video
<ndec> yep, i am interested to understand how ubiquity understands there is a camera too... if you figure out...
<ogra_> well, tobin will file a bug, we will see :)
<ndec> please subscribe tiomap-dev on the bug
<ogra_> k
<GrueMaster> Done and done.
<GrueMaster> Bug 924419
<ubot2`> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Undecided,New] https://launchpad.net/bugs/924419
<ogra_> thx !
<GrueMaster> ogra_: Where are the debug symbol packages for arm?  ports or somewhere else?
<infinity> GrueMaster: Everything's on ddebs.ubuntu.com, but (and this is a big but), not everything is represented. :(
<infinity> GrueMaster: pitti keeps culling random old releases and non-primary arches as he runs out of space.
<infinity> GrueMaster: Though, we seem to have armel/armhf for precise, at least.
<GrueMaster> Ok.  ev wants me to run a backtrace on this ubiquity panel crash.
<GrueMaster> Since I can't just file it.
<ppisati> GrueMaster: did you reboot the beable?
<GrueMaster> Doing so now.  Got caught up in an installer bug on omap4.
<GrueMaster> Nope, it didn't have the same mac on reboot.
<GrueMaster> It was supposed to get it from the die id, right?
<ppisati> nope, you get a random one
<ppisati> but i thought you configured it to get a fixed one
<GrueMaster> How do I configure the system to get a fixed mac address?
<ppisati> via /etc/network/interfaces but i can't make it work anymore, that
<ppisati> s why i asked, because i thought you did
<GrueMaster> There is no way to automate that, especially during a netinstall.
<ppisati> k
<GrueMaster> I need either a die id (like omap4) or a kernel cmdline parameter.
<GrueMaster> Die id is preferred as then I don't need to modify the preinstalled images.
#ubuntu-arm 2012-02-01
<trelane> I have followed the instructions on http://www.freepbx.org/trac/wiki/UbuntuServer, and am booting a gumstix, I get the following output and then it hangs. http://pastebin.com/7u5CBQq3.
<trelane> I did, then did not copy the boot.scr (because the geometry is for a panda not a gumstix)
<trelane> http://pastebin.com/F07sMNN9
<trelane> is the output from ls -asl on the fat32 partition
<twb> trelane: "Loading u-boot.bin from mmc" is the last message?
<twb> Most obvious guess is the system is not configured to send boot-time console, and the login screen to the serial port
<trelane> yeah
<trelane> hrm
<trelane> could be
<trelane> in fact, not unlikely
<twb> Note that it's not always ttyS0 on embedded ARM
<twb> often it's ACM0 or some other fun thing, I dunno about your device
<trelane> ttyS2 on gumstix
<trelane> I didn't set it
<trelane> give me a few
<twb> You need to do it in two places: first, console=/dev/ttyS2 passed to the kernel, and second you need an /etc/init/ttyS2.conf that is similar to the ones for tty0.conf et al
<twb> I am speaking in general; I am not an expert re. arm
<trelane> noted
<twb> trelane: out of curiosity, where is the rootfs in your system?  In the MLO/ dir?
<trelane> second ext4 partition on the SD card
<trelane> partition 1 has MLO u-boot uImage boot.scr
<twb> Ah, righto
<trelane> partition 2 has the ubuntu-base
<trelane> extracted as an ext4 partition
<trelane> I'm playing with the boot.scr script
<trelane> even if I can't get IT to output to /dev/ttyS2, I _SHOULD_ be able to get the kernel or at least getty to do os
<trelane> really I'm not picky
<trelane> as long as I get a boot prompt
<twb> We'll see if you feel the same AFTER it stops working for some strange reason and you want to debug it ;-)
<IamTrying> Is there any latest release for Ubuntu? Last-time i had problem to keep Ubuntu inside the "Eee pad transformer" where i need to do manually boot else it does abnormal loop .
<twb> IamTrying: you have a TF101?
<shaola> twb: are you trent?
<twb> yes
<IamTrying> twb, exactly TF101
<shaola> hi, iker
<twb> shaola: I'm also going home in about five minutes, sorry
<shaola> i got working multitouch in debian armhf
<shaola> i was writting you an email
<twb> IamTrying: lilstevie has some pages and code on the xda web forum, which you can use to get oneiric working OK
<twb> shaola: cool
<IamTrying> twb, i think i did that and i end up with this: http://i.imgur.com/AGSzH.png
<twb> I get that sometimes when trying to shut down / reboot
<twb> Especially if I halt/reboot while the dock is connected
<twb> Or it may be a completely different koops to mine, I can't see there the actual error
<twb> IamTrying: you are using the OLiFE installer that has the interactive prompting menu stuff?
<IamTrying> Yes for the very first time i had a luck one time and after reboot / shutdown since then i am lost i can not use it anymore.
<twb> IamTrying: if so, you have to pick the first option (Android + Linux, default to Android) or it has misc bugs
<IamTrying> Always using OLiFE yes, thats they best one well done.
<IamTrying> There was a problem bug, like you can not auto mate it
<twb> OLiFE is made by lilstevie, who is here but probably away because he has a girlfriend
<IamTrying> You have to press button up or something to boot
<twb> IamTrying: right
<IamTrying> Yea sure.
<shaola> we are talking in #asus-transformer
<twb> You have to hit Power+VolDN during the early boot, and then it will prompt to press VolUp which if you do, will boot oneiric
<twb> shaola: ah, thanks
 * twb adds it to autojoin list
<IamTrying> The problem i there is no stable release with OLiFE for this? So that i can put one Ubuntu stable now like my Android tablet is "he is dead, useless"
<twb> IamTrying: this is all alpha-quality early days stuff, sorry
<lilstevie> there is no stable
<lilstevie> not yet
<IamTrying> We really need one :)
<twb> IamTrying: but it is (almost) impossible to brick it completely
<lilstevie> I am 1 person, who has very very little contributions back
<twb> IamTrying: even if you mess up the install you should be able to reinstall again with nvflash
<lilstevie> twb, the only way to brick is hardware damage
<lilstevie> :)
<twb> lilstevie: because you have a girlfriend to waste your time  :P
<lilstevie> APX is a bootrom mechanism
<lilstevie> twb, no I mean like nobody else contributes
<twb> Yeah because I'm a lazy bum
<lilstevie> the only *real* code contribution has been the network-manager patch for the bcm4329 driver
<IamTrying> Can we not put Tizen at-least so that we got some options if Ubuntu not then at-least Tizen or other Linux to survive without built-in Android.
<twb> And my old machine is still bricked so I can't mess with my TF easily :-(
<shaola> lilstevie: i am trying to do something, but i am not that good
<twb> shaola: even testing and reporting bugs is helpful IMO
<twb> And writing documentation
<shaola> yes, i know
<shaola> i try to do my best in debian
<shaola> reporting bugs, writing for people who knows less than me, i even mantain a simple package
<twb> Pub time, bye
<lilstevie> yes, even documenting and bug reports are useful
<lilstevie> but even that is lax on contributions
<shaola> lilstevie: are you DD?
<shaola> y know twb is DD
<lilstevie> DD?
<shaola> Debian Developer
<lilstevie> no
<lilstevie> I am unaffiliated
<shaola> ok
<shaola> so tell me
<shaola> what do you need?
<lilstevie> I am a school teacher :p
<shaola> congratulations for having the best and the worst profession in the same time
<lilstevie> yep :p
<lilstevie> anyway, what I need is people to take some of the load off me for supporting everything
<lilstevie> :p
<shaola> i am not good programming
<shaola> that's my problem
<lilstevie> aka; support for users, documentation, kernel patches
<shaola> i learned so many years ago with qbasic manual in my home when i was a kid
<shaola> but ,... basic is not programing
<shaola> anyway, i am kind of busy till mid february
<lilstevie> heh, I'm not the best programmer, but I have been getting better, well when I am not making stupid mistakes like sizeof(pointer)
<lilstevie> anyway, as two said before, I have a girlfriend, and she wants to go to the whops
<lilstevie> shops*
<lilstevie> later
<shaola> yeah, the first is the first
<shaola> i don't know if there is an english expresion like that
<shaola> maybe too literaly
<shaola> but i think you know what i mean
<shaola> so, go and enjoy (aghhhh) shopping
<shaola> :P
<Guest9392> slangasek: could you please have a look to this bug/patch https://bugs.launchpad.net/ubuntu/+source/multistrap/+bug/874505 TIA
<ubot2`> Launchpad bug 874505 in multistrap "Native Multistrap oneiric chroots have an error configuring base-files" [Undecided,Confirmed]
 * ogra_ twiddles thumbs watching an ac100 alpha2 testinstall
<ogra_> hmm, no slideshow on the ac100 installer
<lilstevie> heh
<Daviey> ogra_: What do you want, sparkly pony pictures?
<ogra_> just the std ubiquity slideshow :)
 * lilstevie totally thought Daviey said "sparkly porn pictures"
<ogra_> he meant to say that but typoed :P
<lilstevie> lol
<jayson_> Hi, has anyone got ubuntu working on a qualcomm board
<jayson_> I have a dragon board with me & its got android
<jayson_> I can flash android related images onto it using fastboot
<ogra_> jayson_, the guys in #linaro do afaik
<jayson_> but I want to wipe out fastboot & try to install uboot
<jayson_> thanks ogra_ - I'll give it a shot
<shadeslayer> lilstevie: dude, is there any hope of getting a native ubuntu boot on a device with SBKv2 ?
<shadeslayer> You mentioned last time that there might be a way ... haven't heard anything for the past 2 months or so
<ogra_> GrueMaster, did you get a kbd selection dialog in any of your install tests the last days ?
<GrueMaster> Yes, on omap/omap4/mx5.
<GrueMaster> I think.  I'm pulling the latest builds now, will test very soon.
<lilstevie> shadeslayer, yes, but I have been really busy the past month or so
<shadeslayer> lilstevie: understood, I'll patiently wait, let me know if there's anyway I can help :)
<shadeslayer> with testing and stuff
<lilstevie> ok
<lilstevie> well bed time
<shadeslayer> night :)
<GrueMaster> I'm wondering if bug 838200 is u-boot or kernel related.  It is highly annoying, whatever the root cause.
<ubot2`> Launchpad bug 838200 in u-boot-linaro "No network support on Beagle XM" [High,Confirmed] https://launchpad.net/bugs/838200
<GrueMaster> ogra_: keyboard selection comes up on omap4 desktop.  Could be the images don't like you.  :P
<ogra_> bah, ok
<ogra_> might be that something clashes with the new wlan step in ubiquity
<ogra_> i assume you dont get that on panda
<GrueMaster> I have all my systems wired.  I could try wireless during install (I usually wait until login to test it).
<GrueMaster> Sigh.  Analog audio is broken again on omap4.
<dioxin> Hi guys, I'm trying to force ubuntu to start with a terminal rather than gnome on a pandaboard, anyideas?
<GrueMaster> Use the preinstalled server image instead of preinstalled desktop.
<dioxin> ok, but going that route I wasnt able to get gnome running at all
<GrueMaster> Hmm.  There may be a way through one of the /etc/init conf files.  I just don't test that.
<infinity> When you say "a terminal", do you mean a text console, or a GUI session with a terminal application?
<dioxin> text console
<infinity> If the former, just disable lightdm.
<infinity> Or gdm, on older releases before we switched.
<dioxin> I've ssh'ed in, stopping lightdm doesnt bring the main display to a console
<infinity> What does it do?
<dioxin> it gives me a display of recently stopped processes, but doesnt give me commandline access
<infinity> Alt-F1
<dioxin> ok that worked
<infinity> dioxin: If you add "text" to your kernel command line, that should prohibit fancy graphical stuff from starting on boot.
<GrueMaster> dioxin: What happens when you move /etc/init/lightdm.conf to a different directory and reboot?
<infinity> (Alternately, yeah, you can mangle/remove lightdm's config)
<dioxin> where are the kernal command
<GrueMaster> ???
<dioxin> where are the kernal commands stored, i.e where do I edit them
<RoyK> hi all. any idea why lshw is dying on me on this pandaboard? http://paste.ubuntu.com/825549/
<GrueMaster> dioxin: I think you are referring to /boot/boot.script if you want to change the kernel boot parameters.  You will need to run "sudo flash-kernel" after editing this file.
<infinity> dioxin: sudo sed -i -e 's/splash/text/' /boot/boot.script && sudo flash-kernel
<GrueMaster> RoyK: What kernel/Ubuntu release?
<RoyK> GrueMaster: http://paste.ubuntu.com/825556/
<infinity> Yeahp, SIGBUS here too.  Wonder why no one's ever noticed that before. :P
<infinity> RoyK: Can you file a bug?
<RoyK> sure
<infinity> RoyK: To be fair, even if fixed, it won't be wildly informative on ARM.  You'll get USB, and that's it.
<infinity> RoyK: So, lsusb will work fine for you. :P
<infinity> RoyK: But it should still be fixed to not break.
<RoyK> hm... so where'll the wifi chipset be connected on this pandaboard? on usb?
<infinity> If only you were so lucky.
<infinity> No, there are a few devices connected on (usually SoC-specific) busses on all ARM devices, but they're not probable, and until either DeviceTree or ACPI get here, they's also not remarkably easily enumerated.
<infinity> Walking /sys after you already loaded all the drivers would work, but that's not how lshw traditionally works.
<RoyK> ok
<dioxin> hmm even if I remove splash and replace it with text , it still boots to a session manager
<infinity> dioxin: oneiric?
<dioxin> yes
<infinity> Huh.  That was fixed.  At least, it was here.
<GrueMaster> dioxin: move /etc/init/lightdm.conf to a different directory.  That works here.
<infinity>         for ARG in $(cat /proc/cmdline); do
<infinity>             if [ "$ARG" = "text" ]; then
<infinity>                 plymouth quit || :
<infinity>                 stop
<infinity>                 exit 0
<infinity>             fi
<infinity>         done
<infinity> dioxin: Did you change actually "take"?  Do you see a sane command line in /proc/cmdline?
<dioxin> seems so, cat of cmdline seems normal
<infinity> And by "normal", you mean "contains the word text"?
<dioxin> ro elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 root=UUID=4ad147d9-7e0b-4fb9-af24-940fe60ac01f fixrtc quiet text
<infinity> Hrm, kay.  Then lightdm starting is just plain wrong...
<dioxin> just moved lightdm.conf to lightdm.conf.bak
<dioxin> and I get a cmdline straight away
<infinity> As you should, sure.
<infinity> But text on the command line should have the same effect.
<infinity> Unless you don't have the above code in your lightdm.conf
<infinity> In which case, I question if you're actually running oneiric. :P
<infinity> (Note that that was fixed in November in oneiric-proposed, so if you haven't upgraded since the install, you wouldn't have it)
<RoyK> what's the reason for these custom buses?
<infinity> RoyK: Eh?
<GrueMaster> Custom busses?  They are actually fairly standard for embedded devices.
<infinity> RoyK: Every system has custom busses.
<infinity> RoyK: Even x86 systems.
<infinity> RoyK: The difference is that x86, powerpc, sparc, and a few others, enumerate said busses in a standard (OF/DT/ACPI) way.
<GrueMaster> Custom to me implies non-standard.
<infinity> RoyK: ARM hasn't, traditionally, but things are moving that direction.
<RoyK> ok
<infinity> GrueMaster: Yeah, I'm going to stick with "custom", even by your definition. ;)
<RoyK> for ARM to gain wide support, I guess that's a must
<infinity> GrueMaster: Stuff hanging right off the SoC isn't in a particularly standard formart.
<infinity> RoyK: You realise ARM CPUs are in more computers worldwide than any other architecture?
<infinity> RoyK: I'd say they have "wide support". ;)
<infinity> RoyK: But yes, we all want better device enumeration.
<RoyK> infinity: I know, i know...
<RoyK> infinity: but for ARM CPUs to be used in "traditional" computers, you really want device enumeration to work
<infinity> RoyK: *hand wavy*
<infinity> RoyK: The only place where it really matters is being able to ship a single kernel that boots all devices.
 * RoyK has read a bit about using ARM for HPC, but it seems memory buses on ARM are still slow...
<GrueMaster> Not that I have time to debate this, but nothing hangs right off the SOC.  The SOC has internal busses, same as Intel with an external south bridge (just in one convenient package).
<infinity> RoyK: Which is something Microsoft is pushing.  No Win8 logo without ACPI.
<infinity> GrueMaster: The SoC has internal bridges on the SoC, hence some things hang "right off it".
<infinity> GrueMaster: That's the definition of an SoC.
<infinity> GrueMaster: Many devices are right on the SoC, even.
<dioxin> infinity: apt-get upgrade 'ing now
<infinity> GrueMaster: And there's no standard way for how it's all put together, or how you discover what's there.
<RoyK> infinity: right on, as in "simply memory mapped..."?
<infinity> RoyK: Yeahp.
<infinity> RoyK: And nothing wrong with simple mmaped devices (it's the way sparc and powerpc have gotten by for decades), but you need a way to enumerate the devices in a system, since you can't probe that.
<infinity> sparc and powerpc use device trees, x86 uses ACPI, ARM now has both DT and ACPI implementations, and very few boards supporting either. :P
<RoyK> mhm
<infinity> RoyK: As for memory throughput, things have improved a lot lately.  And products that are "coming soon" are better still.
<infinity> RoyK: But it's certainly nowhere near the throughput of, say, AMD systems.
<infinity> RoyK: But hey, Intel can't beat AMD's memory throughput either. ;)
<RoyK> heh - we use AMD rather a lot for HPC :Ã¾
<RoyK> you really want a good memory bus for 16 cores on a cpu
<infinity> Yeah.  We tend to buy mirrored AMD and Intel systems, and pick and choose depending on workload.
<infinity> If throughput is king, go AMD, if math is where it's at, Intel.
<dioxin> and for portable?
<RoyK> is really Intel that much better than AMD on fp?
<RoyK> dioxin: portable HPC? ;)
<dioxin> RoyK: no reason why not ;)
<infinity> RoyK: Currently, Intel tends to beat AMD on most fp and int workloads.  But it's got to be pure number crunching and register flipping.  As soon as you start working with large datasets, AMD comes back strong.
<RoyK> infinity: the runs we have, usually have 1-4GB datasets per job
<RoyK> so I guess we can stay with AMD a while...
<GrueMaster> For portable, I'd have to push Intel.  I have seen recent models of both Intel & AMD, and the AMD runs a lot hotter.
<dioxin> GrueMaster: you were supposed to say ARM ;)
<RoyK> lol
<GrueMaster> Well for battery life and low heat, arm by far.  But until there is a current mass produced Arm netbook that supports Ubuntu, I have to stick with x86 hardware (AC100 doesn't count as it is discontinued and Asus Prime is not supported in our current releases).
<infinity> Yeah, I'm still waiting for a killer ARM netbook. :/
<infinity> And with next-gen ARM cores, we could see ARM "ultrabooks" too.
<infinity> (ie: fast and small)
<GrueMaster> yep.
<infinity> But I won't hold my breath until I actually see hardware.
<GrueMaster> sigh, why is it the platform I care the lease about has working audio ootb?
<infinity> Speaking of subarches, I should dig up a spare microSD, and get testing mx53 kernels...
<infinity> See if we can't get it bumped to 3.2 after the Alpha.
<GrueMaster> That would be nice.  The current kernel won't work on the newer rev boards.
<infinity> Oh, ick, really?
<GrueMaster> No usb.  It sits and reenumerates in a constant loop.
<infinity> That sounds special.
<GrueMaster> I'll log it and file a bug, but if the new kernel fixes it, this is moot.
 * infinity nods.
<infinity> Don't waste your time on it until we've upgraded.
<GrueMaster> Meh.  Typical hw mod.
<GrueMaster> I may need to file it for A2, so other users don't come whining.
<infinity> There's that, yeah.
<GrueMaster> Also, the system is horridly slow on SD.  beagleXM is easily 4x faster.
<infinity> Yeah, I use mine on SATA.
<infinity> Haven't tested a pure SD setup on the mx53 since a day or two after I got it...
<GrueMaster> [   57.856303] usb 1-1: device descriptor read/64, error -71
<GrueMaster> [   58.626361] usb 1-1: device not accepting address 8, error -71
<GrueMaster> [   59.286332] usb 1-1: device not accepting address 9, error -71
<GrueMaster> [   59.292248] hub 1-0:1.0: unable to enumerate USB device on port 1
<GrueMaster> From the new mx53 board.
<GrueMaster> (and of course we don't enable serial console on our desktop images, so I can't log in).
<dioxin> infinity: the boot is now fixed after the upgrade
<dioxin> takes long enough tho!
<GrueMaster> infinity: Here's an interesting (kind of) bug.  Bug 925035 only appears to affect armel.  Not seeing it on armhf images.
<ubot2`> Launchpad bug 925035 in unity-lens-applications "unity-applications-daemon crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/925035
 * RoyK looks at dioxin and wonders if he should renick himself as a pollutant too
<infinity> GrueMaster: Reliably reproducible?
 * dioxin shakes his head at RoyK ..... "pollutant indeed" he muses
<GrueMaster> Both bladner and I saw it on mx5, I saw it on omap & omap4.  All armel images.
<infinity> GrueMaster: That sounds fairly reliable.  Kay. :)
<GrueMaster> Not sure how reproducible it is.  I'd have to delete the crash report & retry.  Too busy with milestone testing atm.
<infinity> GrueMaster: Yeah, the anecdotal evidence that several people have seen it is enough for now.
<GrueMaster> Hmmm.  preinstalled-server fails to network via wifi on panda.  (could be my config though).
<dioxin> I seemed to get that working when I config'ed the wifi via the install process
<dioxin> (using PandaboardES
<GrueMaster> dioxin: server or desktop image?
<dioxin> server image
<GrueMaster> Hmmm.  Could also be this particular board.
<GrueMaster> (I have many).
<dioxin> lucky sod ;)
<GrueMaster> Lucky?  I bought most of them for testing.
<GrueMaster> The more I have, the more I can test (to a point).  For example, I can currently test every flavor of Ubuntu Precise on omap4 at one time.  But I only have one beaglexm, and 8 images to test on it, so it is slower.
<dioxin> I probably shouldnt complain... i have like 5 i5 systems floating around ;) plus others
<GrueMaster> I also have a lot of other systems.  My office has 5 monitors and 15 systems currently running (2 x86, rest are arm based).  Not counting laptops or systems in my rack cabinet.
<dioxin> arent they all company supplied?
<infinity> Some are, but he likes to go overboard. ;)
<dioxin> next system I'm likely to go overboard on is RaspberryPi, but only cos per unit they are cheap :D
<GrueMaster> I like having a home lab.  :P
<dioxin> I need the time to build mine, components are in every draw I can find!
<GrueMaster> dioxin: I would hold off.  I hear there is another platform in the works that is armv7 and almost as cheap.
<GrueMaster> We won't support raspberry pi.
<dioxin> I have money to burn on both ;)
<dioxin> 1 pandaboard is like 6 RaspberryPi's I think
<dioxin> I've heard wind of the armv7, but they arent even close to production yet
<RoyK> dioxin: isn't 7 the current and 8 the next?
<RoyK> with 8 supporting 64bit etc
<dioxin> I think for RaspberryPi its arm5 or 6
<GrueMaster> Sort of.  Armv7 is 32 bit, armv8 will be 64 bit.  There are some things in between that have been announced as well.
<GrueMaster> Raspberry is Armv6.
<GrueMaster> Key difference is Thumb2 support, which reduces the size of instructions (I think).
<dioxin> http://www.arm.com/products/processors/classic/arm11/arm1176.php
<dioxin> thats the R-Pi chip
<GrueMaster> Yea.
<GrueMaster> Arm versioning prior to v7 is a bit wonky.
<dioxin> single core only as well I think
<GrueMaster> Armv7 is the first to introduce SMP in the SOC.  I think some vendors have done it with armv6, but only at the instruction set level (i.e they have their own core design).
<RoyK> GrueMaster: *size* of instructions?
<GrueMaster> The Thumb (T32) instruction set provides a subset of the most commonly used 32-bit ARM instructions which have been compressed into 16-bit wide opcodes.
<GrueMaster> From http://www.arm.com/products/processors/technologies/instruction-set-architectures.php
<RoyK> k
<dioxin> will Ubuntu Server ARM fit onto 4GBs SD?
<GrueMaster> Yes.
<GrueMaster> All of our preinstalled images are designed for 4G SD or larger.
<dioxin> and is there an image for a minimal file system with either SSH or serial?
<GrueMaster> It won't give you much room to really go wild, but it is good for some things.
<GrueMaster> The server image is about as minimal for a bootable headless install as we can make.  It is configured via serial console.
<desrt> hello arm people
<desrt> i currently have the quickstart board with linux-linaro-lt-mx5 kernel installed
<desrt> i just upgraded to precise and it seems like the latest version of that kernel is 2.6.38
<desrt> is there a successor package, or is that the kernel i should be using?
<infinity> desrt: That's the current one still.  We're working on getting a 3.2 kernel into shape, but it's not in the archive yet.
<desrt> cool.  thanks for the info.
#ubuntu-arm 2012-02-02
<dioxin> grrr... I've just overwritten an image file trying to write to a SD card....
<dioxin> is it possible to install gnome-classic on Oneric?
<GrueMaster> On arm?  Not sure.  If it is in the pool, then yes.
<dioxin> Unity was first in 11.04? or 10.10?
<twb> 10.10 on netbooks
<twb> IIRC
<GrueMaster> 10.10 yes.
<krosswindz> I recently got a pandaboard
<krosswindz> when I am trying to use the usb serial adapter my screen is complete garbled
<krosswindz> I have the Prolific Technology pl2303 usb serial adapter
<krosswindz> I have set the minicom settings from pandaboard side
<krosswindz> I was wondering if anyone could help me fix this issue
<GrueMaster> krosswindz: I used to use those all the time (recently upgraded to an 8 port pci serial adapter for all my systems).  I use screen and it works fine.  "screen /dev/ttyUSB0 115200" should give you a serial console.
<twb> IME there are only one or two USB serial adapters in existence
<twb> Everything is just that rebranded
<twb> garbled might just indicate your baud rate is wrong
<krosswindz> GrueMaster: I was using minicom
<twb> baud rate needs to be the same on both sides
<krosswindz> GrueMaster: when I use screen I have the issue
<twb> minicom and sceren both work as client side; probably want getty on the server side
<krosswindz> twb: I am setting baudrate as 115200 which is what is mentioned in the ubuntu website
<twb> That should be fine
<krosswindz> When I use a different adapter it works fine for the same setting
<twb> Maybe that specific device is damaged
<krosswindz> you mean the pl2303 might be damaged
<twb> device = that adapter, I mean, no the pandaboard
<twb> Right
<krosswindz> thanks
<krosswindz> I will see if I can get it replaced
<twb> They cost like $4 so just replace it
<GrueMaster> krosswindz: Are you plugging the 9 pin plug directly to the panda or are you using a cable/adapter in between?
<twb> GrueMaster: if he doesn't have a nullmodem cable it should just fail, right?  i.e. not garbled
<krosswindz> the 9 pin directly to the pandaaboard
<krosswindz> when I using the tripplite keyspan usb serial adapter
<krosswindz> it was all fine
<krosswindz> i had borrowed that from my friend
<krosswindz> if i switch to that same settings for minicom it is fine
<GrueMaster> Another thing to try is on the desktop side, type "sudo setserial /dev/ttyUSB0 base_baud 115200".
<krosswindz> ok
<krosswindz> Invalid flag: base_baud
<GrueMaster> Oops.  baud_base (I had it reversed).
<krosswindz> Cannot set serial info: Invalid argument
<krosswindz> sudo setserial /dev/ttyUSB0 baud_base 115200
<krosswindz> thats the command I am using
<krosswindz> http://pastebin.pandaboard.org/index.php/view/63324435
<krosswindz> that is the output of setserial -a
<GrueMaster> "Baud_base: 460800".  That is the problem.
<krosswindz> I am unable to switch it to 115200
<GrueMaster> Try "sudo setserial /dev/ttyUSB0 port 0x0000 irq 0 uart 16654 baud_base 1152000"
<krosswindz> Cannot set serial info: Invalid argument
<GrueMaster> hmmm.
<GrueMaster> sudo setserial /dev/ttyUSB0 uart 16654 baud_base 1152000
<GrueMaster> sudo setserial /dev/ttyUSB0 uart 16654 baud_base 115200
<GrueMaster> (somehow my copy/paste added a zero)
<krosswindz> crap
<krosswindz> sorry
<krosswindz> i didnt see it
<krosswindz> no go
<krosswindz> same invalid argument error
<GrueMaster> You are running this on the host (usb) side, right?
<krosswindz> yes this on the host side
<krosswindz> my laptop
<krosswindz> google isnt being helpful either :(
<GrueMaster> Try unplugging and plugging the usb serial adapter back in, then run setserial -a /dev/ttyUSB0 to see what it says.
<krosswindz> its the same, http://pastebin.com/UCC17Ukx
<GrueMaster> Not sure why it is coming up with Baud_base: 460800
<GrueMaster> Very odd.
<krosswindz> I am leaning towards the fact that it could be a bad adapter/cable
<GrueMaster> Check dmesg to see what it says.
<GrueMaster> Also, when you plug it into the laptop, is it connected to the panda?  Try unplugging from the panda.
<GrueMaster> Very possible.
<krosswindz> http://pastebin.com/VkcUmEGP
<krosswindz> ok
<krosswindz> let me unplug from panda
<krosswindz> its the same
<krosswindz> i unplugged from panda, unplugged from laptop, then plugged to my laptop
<krosswindz> ran setserial -a /dev/ttyUSB0
<krosswindz> the result is the same
<GrueMaster> Sounding like a bad cable.  Nothing else I can suggest.
<krosswindz> I am inclined towards the same
<krosswindz> this sucks
<krosswindz> i need to go borrow the cable again
<krosswindz> thanks for your time GrueMaster
<GrueMaster> Sorry I couldn't help more.  Good luck.
<krosswindz> not a problem
<krosswindz> at least one other person things its a bad cable
<krosswindz> this was driving my nuts, I was thinking I was screwing up
<GrueMaster> Well, since it isn't directly in front of me, I can't actually diagnose that that isn't the problem.  :P
<krosswindz> I was wondering are there any documentation on setting up cross compile toolchain for arm on ubuntu
<krosswindz> I want to rebuild my kernel, I was hoping I dont have to do it on the pandaboard
<GrueMaster> I think there is somewhere.  Do a google search with " cross compile site:wiki.ubuntu.com".  I've done it, but not for a kernel.
<GrueMaster> Also, I think the kernel build only takes 20 minutes if you are using a usb drive to build on.
<krosswindz> I found the blueprint for it :p
<GrueMaster> http://manpages.ubuntu.com/manpages/hardy/man1/make-kpkg.1.html
<GrueMaster> Not sure if that will work, but worth a shot.  You will need the arm compiler installed.
<krosswindz> i will have to use it but only after I install the cross compile tool chain
<krosswindz> I am seeing kernel oops on poweroff
<krosswindz> http://pastebin.pandaboard.org/index.php/view/45552590
<krosswindz> thats the output from the serial console
<twb> Ouch
<mythos> hmm... i had that effect too... but my board is a ti alpha board
<twb> mythos: ti doesn't make alpha architecture ;-P
<mythos> twb, nice joke :o
<janimo> jcrigby, I'd like to test your mx5 new kernels. Can you provide me with the most up-to-date ppa and what exactly to test - apart from it booting?
<janimo> also a git repo would be helpful too in case I need to rebuild and change
<janimo> GrueMaster, infinity rsalveti which is the ppa and kernel version to test for mx5? armhf , 3.0 or combined testing?
<rsalveti> janimo: 1 sec
<rsalveti> janimo: https://launchpad.net/~linaro-maintainers/+archive/kernel
<rsalveti> argh, but it's just for oneiric there
<rsalveti> let me check the other ppa
<rsalveti> we moved the ppas around, let's wait jcrigby to answer that
<janimo> rsalveti, the link you sent has precise armel mx5
<janimo> 3.1.1-10
<rsalveti> janimo: true!
<rsalveti> janimo: that's probably best working one
<janimo> is there a 3.2 that needs testing? I can wait for that too
<rsalveti> janimo: 3.2 doesn't even boot
<rsalveti> something we'll check at connect with the freescale guys
<janimo> rsalveti, ok, I'll check that. jcrigby tested it I assume but you need another confirmation from Ubuntu-ARM?
<rsalveti> janimo: exactly
<janimo> ok.
<rsalveti> janimo: the src package comes from https://github.com/jcrigby/packaged-linux-linaro-3.1-ci/commits/lt-mx5
<rsalveti> which is a merge from the lt source tree + packaging patches
<rsalveti> and ubuntu sauce
<janimo> rsalveti, thanks
<GrueMaster> Yea, we will have to rebuild those.  No armhf kernels (which is the goal).
<janimo> Do we not have netboot for mx5?
<janimo> http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current/images/
<GrueMaster> No.
<janimo> :(
<janimo> ah because of univerese kernel
<janimo> or such
<ndec> ogra_: rsalveti: quick packaging questions... we have upgrade many packages in our PPA, but if we install the ubuntu-omap4-extras in a fresh install not all packages are installed at once, we need to make a dist-upgrade afterwards. is that normal?
<GrueMaster> Yea, something like that.
<janimo> I quite liked the netboot experience on panda was hoping for a similar quick thing on mx5
<rsalveti> ndec: that will only happen if your meta package is requiring an specific version of a package
<GrueMaster> Get us a 3.2 kernel and the kernel team might be more lenient towards that.
<rsalveti> as if it's just depending on the package name, it'll always grab the latest one available
<ndec> XavB: is that the case ^^
<ndec> rsalveti: i think we explicitely conflicts/replaces the default ubuntu kernel so that it gets removed in favor of our 3.1
<rsalveti> janimo: jcrigby should know more about netboot for mx5
<rsalveti> but I think it should be easy to support
<rsalveti> at least I know tftp should probably be working already
<GrueMaster> rsalveti: He was referring to netboot intstall.
<GrueMaster> (I call it netinstaller, but colin doesn't like that).
<infinity> rsalveti: It's not a kernel issue, it's that we don't build d-i against universe kernels.
<rsalveti> ndec: but as your kernel is newer anyway, all you need to do is to install your own kernel
<rsalveti> oh, ok
<rsalveti> ndec: guess the links will be in place after that, and flash-kernel will flash the latest installed one
<rsalveti> the older one will still be installed, but don't thinkg that would be a problem
<XavB> ndec: rsalveti: we are not requesting any specific version iirc, and if it was the case, the dist-upgrade would not work then.
<XavB> rsalveti: we want to prevent the case where an upgrade from your kernel will replace ours
<infinity> rsalveti: Hrm, looking at the haskell-src-exts build failure, I'm not sure this is a binutils issue (I need to test locally and see what processes are running to be sure, but there's no whining from ld)
<infinity> rsalveti: So, it may still be a kernel issue.
<XavB> rsalveti: as soon as you have two linux-image package version (2 abi versions) the last package installed is the winner
<ndec> rsalveti: as XavB said, if both kernel are installed, since they don't have the same pkg name and ABI, a kernel upgrade from main archive will be installed and flashed
<infinity> ndec: Perhaps a silly question, but is there any reason you can't work with ppisati to merge the bits you need into our kernel?
<rsalveti> ok, so it can be problematically
<infinity> ndec: Or are you building non-free stuff in?
<ndec> infinity: yes, we are moving to 3.1 in oneiric...
<rsalveti> but still, you just need to remove the kernel meta package
<infinity> ndec: Oh, this is for oneiric.  Kay.  Not an issue for precise, then?
<ndec> it's all free ;-)
<rsalveti> not exactly, because of the abi
<ndec> infinity: for P. we will move to 3.3 similarly.
<rsalveti> yeah, removing it entirely will probably be the best thing to do
<infinity> ndec: Are those kernels of yours supported with security updates and such?
<ndec> no
<infinity> So, enabling your PPA is effectively removing users' security support? :/
<ndec> but they have features that we can't backport with the resources we have, so instead of that we move forward.
<ndec> yes, this is correct. we have added a note about that (debconf) so that users know about it
<infinity> Why not just move forward with the development release instead, and leave the previous ones as they are?
<ndec> ?
<infinity> ie: Do what the rest of the distro does. :P
<infinity> Freeze features at feature freeze, and then start targetting new stuff to the next release.
<infinity> And that way, you can build on top of distro kernels instead of shipping your own.
<ndec> we have to match different schedules all together... Ubuntu release cycle as well as our internal release cycles for TI customers that consume Ubuntu release from us.
<ndec> it would be better to be aligned, but difficult
<ndec> we build on top of linaro kernel (which we contribute to).
<infinity> Sure, and we merge from the linaro tree as well, but we freeze at certain points.
<ndec> for P. we in fact decided to support 3.3 only for MM. since some of our drivers were pushed into 3.3 mainline.
<infinity> Which is a bit of a promise to the user, as well as people developing on the platform.
<infinity> I'm not going to say your PPA can't do that.  It's a PPA, it can do whatever you want.
<ndec> we will support basic functionalities and X11 driver in 3.2, but we've moved all our dev to 3.3
<infinity> But it certainly cements positions on earlier conversations we've had about why PPAs can't be presented as installer options to end users.
<ndec> agreed.
<infinity> Cause removing the distro kernel in favor of an unsupported (and version mismatched, compared to other platforms) kernel is a bit nasty.
<ndec> note that 3.2 from P. or 3.0 from O. just work without problems.
<ndec> we just provide more features shoulld you decide to enable our PPA.
<ndec> and i agree that this is the first time we push our kernel, but we really couldn't do without it this now.
<infinity> Yeah, I realise that the distro kernels work, I use them. ;)
<ndec> backporting all the PandaES support and power management to get 1.2Ghz from 3.1 to 3.0 was really waste of time on our end, especially because our internal TI releases were done on 3.1
<infinity> Just hoping your "NO SECURITY SUPPORT!!!111ELEVENTYONE" note is obvious enough to people.
<infinity> And, sure, not many Pandas are internet facing or multi-user, but people should still be aware.
<infinity> ndec: Sure, backporting isn't always the right answer.  But we have a 6 months release schedule for a reason, hence my "just develop for the development release" point.
<ndec> yeah, so it's either a nice media player with full HD playback *or* a very secure server with kernel security upgrades ;-)
<infinity> ndec: If your PPA was developing for the development release instead of playing cacth-up on the released one, it would sort of solve most of this.
<ndec> that brings another problem ;-)
<ndec> for 10.10 we did work on the development release and struggled too much to make our internal stable with a dev release of Ubuntu...
<ndec> so now we use the latest stable release instead of dev. i agree.
<infinity> Was that before we actually had a sanely-maintained opam4 kernel?
<infinity> Or was it fast-moving userspace changes that were killing you?
<GrueMaster> ndec: To be fair, the hardware wasn't stable either during 10.10 development.
<ndec> the problem was not kernel, but archives.
<ndec> the fact that archive was different everyday was painful since we couldn't make stable (reproducible) releases out of it.
<infinity> ndec: Well, sure, cutting released images from it is often a no-go.
<infinity> ndec: The general idea is to do feature development while we're doing the same, and then as it stabilises, ship.
<infinity> ndec: I guess if you have customer obligations to ship Feature X "right effin' now" on top of a stable distro, you don't have much choice but to do what you're doing right now.
<ndec> yeah... two contradicting goals ;-)
<infinity> ndec: But most people seem to figure out a way to communicate why that's insanity, and do it more sanely.  You could always try. ;)
<ndec> ok.. i wish we could continue the discussion,  but i need to go. will catch up later.
<infinity> ndec: Later. ;)
<janimo> infinity, my 1hr estimation was for the qtwebkit build. It is now 70 min into linking with 1.7G of virtmem used accordint to top. IIRC last time it was simply OOM-killed ld did not get around to complain either
<infinity> janimo: Yeah, my 10m may have been a bit generous.  I was always multitasking before when testing, not watching it. ;)
<infinity> janimo: 72m... So... Uhm... It's 10 minutes, if you ignore the extra hour!
<janimo> infinity, also some drugs are known to make time fly ;)
<janimo> hmm it did not yet finish here after 75 min, (debuild -us -uc -ns so some overhead above just the gcc invocation)
<infinity> real 72m21.672
<janimo> ok, should be finishing here up as well soon then
 * janimo wonders if some local proxy and url rewriting could convince netboot to work with kernels that are in universe only
<janimo> sounds boring though
<janimo> why does D-I not have an option off by default to allow using universe?
<infinity> How would that solve anything?
<infinity> This is on the buildds we're talking here, not in your home.
<infinity> As in, building d-i generates those images, and d-i (in main) doesn't build against universe.
<janimo> infinity, oh I mean only for devel use, if I wanted to have a netboot image on the board
<infinity> Doing it yourself isn't hard at all.
<janimo> is there a doc ?
<infinity> No. :P
<infinity> Documenting d-i would take about as long as rewriting it.  And reading the docs would take almost as long as reading all the source for all the components.
<infinity> So, uhm.  It's the ultimate "use the source" example.
<janimo> that the fact it is easy is not very  relevant :)
<janimo> after earing so many things about d-i, this advice make me uneasy
<janimo> hearing
<infinity> Most people who whine about d-i just like whining.
<infinity> So, erm.  Hrm.
<infinity> janimo / rsalveti: Maybe the 3/1 split thing isn't actually fixed.  Or, not completely.
<infinity> Sure, the simple testcase passes.
<infinity> And when watching swap usage, I see it go up to ~2G, which seems reasonable.
<infinity> But I sort of forgot my system was eating nearly 1G before g++ was run.
<infinity> So, ld's probably only using about 2G there.
<infinity> I need to monitor this more sanely.
<janimo> my build is still not over after 1h25m. I wonder is my swap is that much slower - external USB disk
<janimo> 1Ghz panda
<infinity> janimo: Are you sure you don't have some swap on SD too?
<infinity> janimo: If it's a default install, you have swap on SD, which it will hit before disk.
<infinity> cat /proc/swaps
<janimo> it is a netboot install directly to the USB disk, only uboot+kernel are (hopefully) on SD
<infinity> Oh, hrm.  Then I dunno.
<janimo> once ld lets me have a scheduler slice I'll check that
<infinity> Oh wait, but you said your build was a full debuild?
<infinity> I was just re-running the g++ call.
<janimo> debuild -nc reached that in less than a couple minutes I'd say. Now at 1.8G virtmem
<infinity> Well, it should die soon.
<janimo> debuild -nc is very useful, I only found out about it at last rally. from you incidentally
<infinity> And if it does die around ~2G, I now want to know why the testcase works.
<janimo> or I may have tried it earlier on a broken package and given up on hoping it does what it is meant to do
<janimo> infinity, is this related to the top-down MMAP bug thing or some other mmap issue?
<infinity> janimo: It's the same (the only?) mmap thing we've been talking about for the last six months.
<janimo> I was only aware of one - for which we last month did SRUs
<janimo> not being able to alloc past 2G or something
<infinity> Yeah, that one.
<janimo> ok
<infinity> And the testcase now passes.
<infinity> But perhaps the testcase is broken. :P
<GrueMaster> I have other tests that were broken prior to the fix that now work.
<GrueMaster> For the same reason.
<GrueMaster> So in my SRU testing, I am hitting this from multiple angles.
<infinity> Okay, for "passes", I mean "the testcase almost passes".
<infinity> It hits 2925MB (not 2999, as it does on x86), but close enough.
<GrueMaster> Almost?  didn't know there were multiple levels of passing.
<infinity> GrueMaster: From my POV, "close to 3G" beats "only 2G". ;)
<GrueMaster> Ah.
<infinity> (And it was passing on the SRU kernels, it's the precise kernel where it's only 2925)
<infinity> But in all cases, the qtwebkit-source build fails.
<GrueMaster> infinity: Do you want to try building that package on my server?  It has 4G physical memory, SATA (16G SSD), 1GE, and ipv6.
<GrueMaster> (and it is idle at the moment).
<infinity> GrueMaster: Erm.  How's that help me?
<GrueMaster> Speed.
<GrueMaster> (Faster to fail).
<infinity> GrueMaster: It's already failed here.  Countless times.
<janimo> GrueMaster, does that server have precise or a precise chroot?
<jcrigby> janimo: https://code.launchpad.net/~linaro-maintainers/+archive/kernel/+recipebuild/167772
<janimo> would be interesting to see how fast it fails there
<GrueMaster> preciseHF.
<jcrigby> janimo, that is the latest mx5 3.1 build
<jcrigby> but it is oneiric
<infinity> janimo: I'm on it already.
<janimo> infinity, ok
<infinity> janimo: qtwebkit, that is.
<janimo> yes
<infinity> janimo: jcrigby is all yours. :P
<jcrigby> janimo, but should be identical
<janimo> jcrigby, I understand the testing is for inclusion in precise, so I guess the precise/ppa should be a better choice? Unless they're exactly the same of course
<infinity> janimo: They won't be exactly the same, even if the source is, due to toolchain changes.
<infinity> We really do need to test precise kernels built on precise. :P
<janimo> so the PPA it is then
<jcrigby> infinity, janimo: if you want to try that out while I work on our source upload recipe issue  then go for it, otherwise I'll ping you when I have a precise version
<jcrigby> janimo, or actually let me look for an older precise armhf build
<janimo> Is this not ok ? https://launchpad.net/~linaro-maintainers/+archive/kernel/+packages?field.name_filter=&field.status_filter=published&field.series_filter=precise
<janimo> the one rsalveti mentioned above
<jcrigby> https://code.launchpad.net/~linaro-maintainers/+archive/kernel/+build/3126577
<janimo> I will test armel first
<janimo> kernel images should be the same for armel and armhf right?
<jcrigby> yes should be unless there is a bug in the toolchain
<infinity> janimo: They should bit-for-bit identical, even.
<jcrigby> because the kernel uses no floating point
<infinity> janimo: Except for the debian packae.
<jcrigby> janimo, the testing I did was just with a minimal linaro rootfs, booted
<jcrigby> and I also saw console on vga, did not test with hdmi adapter
<infinity> I don't own the HDMI adapter.
<infinity> GrueMaster does, though.
<GrueMaster> I think hdmi requires a u-boot parameter.  I have the adapter, but haven't had time to test it.
<infinity> Yeah, it requires changing the command line.
<infinity> It's super user-friendly.
<infinity> Unless either Freescale or Linaro have made the displays actually auto-detect and auto-switch in 3.x?
<GrueMaster> That would be sweet.
<GrueMaster> But would probably require the closed source bits.
<janimo> infinity, two 4G swap files in / (USB disk), still linking after 2:30h
<janimo> no idea where the difference can come from
<infinity> janimo: That's certainly odd.
<infinity> janimo: What's the memory usage at on your 2.5h link?
 * janimo goes checking
<janimo> oh it stopped
<janimo> last time it was 1.8G did not check after that
<janimo> infinity,  real    197m29.862s user    1m58.063s sys     1m30.719s
<janimo> Killed process 19240 (ld) total-vm:840480kB, anon-rss:838092kB, file-rss:48kB
<pbuckley> Under the current ubuntu 12.04 arm version i get this when trying to use alsa
<pbuckley> ALSA lib main.c:260:(execute_sequence) unable to open ctl device 'hw:Panda'
<pbuckley> though when i do listcards i see 0: Panda
<pbuckley> (this was working under 11.10)
<pbuckley> im guessing it has something to do with /usr/share/alsa/ucm/Panda/ the files there
<GrueMaster> pbuckley: Known.  See bug 925069
<ubot2`> Launchpad bug 925069 in linux-ti-omap4 "No analog audio on omap4 panda" [Undecided,New] https://launchpad.net/bugs/925069
<pbuckley> ah thanks
<GrueMaster> It might, haven't had a chance to really look into it.  Just discovered it yesterday with milestone testing.
<pbuckley> im also getting the same dmesg dump fyi thats in the bug
<pbuckley> also just want to say i can't believe the performance improvement in 12.04 over 11.10, its like an entirely new machine
<GrueMaster> pbuckley: Are you using armel or armhf build of 12.04?
<XavB> ogra_: rsalveti: I am trying to copy packages (without rebuild) from ppa ti-omap-private to release ppa and I am facing "timeout issue"... Error ID: OOPS-93333df9d8f15a5bfb041f2c181e8b10... Any idea?
<ubot2`> https://lp-oops.canonical.com/oops.py/?oopsid=93333df9d8f15a5bfb041f2c181e8b10
<orbarron> hello all -- got a quick ?? I need net_tstamp.h on 10.04. can I get this somewhere? or do I take what in kernel.org and drop in?
<pbuckley> armel, should i be using armhf?
<GrueMaster> orbarron: For armel?  What platform?
<GrueMaster> pbuckley: Yes, please.  We are trying to shift to armhf, and the more testing, the better.
<GrueMaster> It should also give a slight boost in performance.
<orbarron> well -- am working on 1588 on a DM8148 -- and testing this on a host + device platform.
<pbuckley> do i need to do a fresh install or can i just do sed -i 's/armel/armhf/g' /etc/apt/sources.list
<GrueMaster> pbuckley: I don't think that is recommended.  Fresh install would be better.
<pbuckley> ok
<GrueMaster> Kind of like s/i386/amd64 on intel HW.
<pbuckley> ah ok
<GrueMaster> Not recommended.
<pbuckley> neat
<GrueMaster> orbarron: Where is that file normally located?  Is it part of the kernel headers?
<orbarron> yes
<GrueMaster> And I assume you have a custom kernel.  I would recommend using it from your kernel source tree.
<orbarron> well -- I need this on my host.. but not sure if I could drop this in the proper location or if there was a package I could download -- problem is Im not sure what impact it might have on my existing headers....
<infinity> orbarron: It's in linux-libc-dev
<infinity> orbarron: Which you'd have installed if you install build-essential.
<orbarron> got that -- but no net_tstamp.h -- this might be based on a newer kernel -- Im on 2.6.32-38 and checking into this atm
<infinity> orbarron: Oh, it wasn't in linux-libc-dev in lucid, no.
<infinity> orbarron: Only newer releases.
<orbarron> ahh that is what I figured...
<orbarron> hmm -- can I pull in the newer headers or will this mess other things?
<infinity> If it's fairly self-contained, you can pull just that one header, but if it relies on other interfaces having changed, you're a bit out of luck.
<dioxin> does anyone know of any drivers available for usb wifi sticks?
<infinity> That's pretty non-specific.
<GrueMaster> Erm, most x86 drivers should also be on the arm images.
<infinity> But I can tell you that most any USB WiFi stick that works on x86 will also work on ARM.
<infinity> Our distro kernels build everything they can, unless it breaks.
<dioxin> kk
<dioxin> I've just plugged in a usb wifi stick and was expecting iwconfig to recognise it straight away
<GrueMaster> dioxin: Did the system load a module on plugin?  That's the first thing to check.
<dioxin> I'm just trying to figure stuff like that out
<orbarron> thanks infinity
<dioxin> Gruemaster: do I need to output dmesg to find that ?
<GrueMaster> yes.
<dioxin> what text would tell me a module is loaded, I dont see anything obvious
<rsalveti> XavB: this timout issue is very annoying
<rsalveti> XavB: happens from time to time
<rsalveti> XavB: try copying just one package at a time
<GrueMaster> dioxin: Does the device show up in lsusb?
<dioxin> yes
<GrueMaster> You should see a kernel message in dmesg showing the device being plugged in.
<dioxin> http://pastebin.com/6W4rcCGR
<dioxin> think I see that in there
<infinity> dioxin: Could just be some USB IDs missing from the correct atheros driver.
<dioxin> infinity: is there anyway to check if I have the driver isntalled?
<infinity> I see no messages there from a driver being loaded.
<infinity> Which means there was no ID->driver mapping found for that specific device.
<desrt> any updates on the prime?
<dioxin> infinity: I tried to find the module in modprobe but its not there
<GrueMaster> dioxin: First off, does the usb wifi device work on x86 Linux?
<dioxin> yes
<dioxin> ath9k is the driver
<infinity> And you're using the same version of Ubuntu on ARM?
<infinity> ath9k is definitely there on omap4 in precise.
<infinity> Not sure about past releases.
<dioxin> I'm on Onerioc on both
<dioxin> ubuntu on both
<GrueMaster> sigh.  # CONFIG_ATH9K is not set
<dioxin> is precise an additional tag like main restricted universe multiverse on the packages
<GrueMaster> File a kernel bug.
<infinity> GrueMaster: At least it's fixed in precise.
<GrueMaster> precise is 12.04 release.
<infinity> GrueMaster: Perhaps as a result of the hours I spent with Leanna and Andy.
<infinity> Leanne*
<infinity> dioxin: precise is the release after oneiric.
<infinity> dioxin: The one currently in development.
<GrueMaster> dioxin: This is on Panda, right?  Why don't you use the built-in wifi?
<dioxin> the more WiFi the better :D (but yes the built in works)
<GrueMaster> Best I can suggest is to file a bug and hope they fix it with the next SRU cycle in 3 weeks.
<GrueMaster> Or download the kernel source and build the module manually.
<dioxin> can I not do an apt-get upgrade to precise?
<XavB> rsalveti: you are right, copyying small group of packages (5 e.g.) works fine
<GrueMaster> dioxin: You can run "sudo do-release-upgrade -d" to upgrade to 12.04 Precise.
<dioxin> GruemMaster:
<dioxin> GrueMaster: Cheers
<pbuckley> GrueMaster: are there prebuilt armhf ubuntu images?
<GrueMaster> Yes.  We should be releasing Alpha 2 images today, and there are daily images on http://cdimage.ubuntu.com
<GrueMaster> What platform?
<pbuckley> pandaboard
<GrueMaster> Yes, we have those.  Freshly tested, and they work quite well (for alpha).
<pbuckley> http://cdimage.ubuntu.com/daily/current/ i dont see them here
<GrueMaster> http://cdimage.ubuntu.com/daily-preinstalled/current/
<pbuckley> brilliant, thank you
<pbuckley> just to be pedantic http://cdimage.ubuntu.com/daily-preinstalled/current/precise-preinstalled-desktop-armhf+omap4.img.gz
<pbuckley> this is the one i want?
<GrueMaster> yep.
<GrueMaster> Which game?  Who can stay in the house the longest w/o getting dressed?
<GrueMaster> Oop.  wrong window.
<pbuckley> lol
<pbuckley> GrueMaster: armhf loaded and running
<pbuckley> first thing i notice is there are no ti armhf packages
<GrueMaster> pbuckley: They should be showing up soon.
<pbuckley> yay! :)
<pbuckley> everything (minus sound) seems to be great
<pbuckley> super fast
<pbuckley> install went fine
<dioxin> Gruemaster: the precise build works for the ATHEROS wifi stick
<GrueMaster> cool
<dioxin> much appriecated
<GrueMaster> I would still recommend filing a bug.
<dioxin> is there an ARM specific place to log bugs?
<GrueMaster> No, just use apport-bug (or apport-cli if console only).  It will tag bugs accordingly.
<GrueMaster> So apport-bug linux-omap4 for the kernel bug.  Make sure you are on oneiric so it can gather the info it needs.
<GrueMaster> Then drop me a note here and I can triage it.
<pbuckley> are there supposed to be udev rules for the pandaboard? for setting things like audio/etc?
<pbuckley> unfortunately i dont have an 11.10 image to compare against
<GrueMaster> Yes.  They shouldn't have changed since 11.10
<pbuckley> ok.. i dont have any udev rules
<pbuckley> under 12.04
<GrueMaster> they should be in /lib/udev/rules.d
<pbuckley> theres only one file there
<pbuckley> and its empty
<pbuckley> what should be there?
<GrueMaster> I'll have to look.  I don't have an oneiric desktop image running atm.
<pbuckley> ok.. would be appreciated
<GrueMaster> pbuckley: The udev rule should be /lib/udev/rules.d/90-alsa-ucm.rules.  I see it here on a desktop image.  It is installed by alsa-utils.
<pbuckley> hrmm
<pbuckley> i didn't get it
<pbuckley> could you message me the contents?
<GrueMaster> Not easily.  Check to see if alsa-utils is installed.
<pbuckley> ii  alsa-utils            1.0.24.2-4ubuntu3     Utilities for configuring and using ALSA
<pbuckley> it is
<GrueMaster> And you don't see anything in "/lib/udev/rules.d" ?
<pbuckley> pbuckley@panda:/etc/udev/rules.d$ ls
<pbuckley> 70-persistent-cd.rules  README
<pbuckley> err
<pbuckley> ok
<pbuckley> under lib/udev i do
<pbuckley> and it has that file
<pbuckley> damn.. so much for that idea
<pbuckley> i wonder how cdev's are created
<pbuckley>                 cdev "hw:Panda"
<GrueMaster> You should have two devices, one for HDMI audio and one for analog audio.
#ubuntu-arm 2012-02-03
<krosswindz> I am having issues when trying to compile Ubuntu kernel in ARM cross chroot
<krosswindz> The error I am getting is http://pastebin.pandaboard.org/index.php/view/43458006
<krosswindz> I noticed a bug report for precise https://bugs.launchpad.net/ubuntu/+source/tree/+bug/904763
<ubot2`> Launchpad bug 904763 in tree "Unable to build tree for armel" [Undecided,New]
<krosswindz> I was wondering on how do I change the CFLAGS for the same
<person987> having trouble with initial boot of ubuntu on a pandaboard...
<person987> during the initial "resizing the filesystem" stage, it says "Errors were found while checking the disk drive for /."
<infinity> person987: If the resize is failing, the original write to the SD was bad.
<infinity> person987: Which could be either (A) because something went wrong, or (B) the card is dead/dying.
<infinity> person987: My bet's usually on B, but you can try rewriting and see if it likes you the second time.
<infinity> krosswindz: That bug looks bogus to me (or, rather, their "fix" for it).
<infinity> krosswindz: I suspect dropping optimisation would be enough to solve your problem.
<infinity> krosswindz: But, honestly, if you have to do such nasty things to cross-compile, you might want to rethink things and compile natively. :P
<person987> I have tried writing the image to this SD card twice or 3 times now.  Maybe you're right and the card is bad, I'll get another one tomorrow.
<person987> Has anyone had problems with hard-locks using ubuntu 11.10 on a pandaboard?
<infinity> Under seriously heavy load (ie: running as a buildd), we manage to lock them once in a while.
<infinity> But that's fairly rare, compared to the pain they're being put through.
<person987> I have another SD card which works but I have been getting regular hard-locks.  Probably once every half hour.  I was trying to build a new image on the new SD card to see if maybe I've gotten a bad driver or something like that (pretty new to Ubuntu/Panda)
<person987> I'm often running some OpenGL code which renders Kinect data when I'm using the pandaboard
<infinity> Well, I'd suggest installing to a real hard drive at some point to rule out bad media.
<infinity> But if you're doing intense OpenGL stuff, it may well be that.
<person987> My typical usage is to write some code, run for a bit, write some more code, maybe a couple web searches, etc.  It will lock up during any of the above, including just typing.
<infinity> Locking up during typing, on the other hand, definitely shouldn't be happening.
<infinity> We have machines with uptimes in the weeks and months around here.
<person987> I suspect the graphics driver/opengl stuff.  I tried to install the drivers to get opengl hardware acceleration and it didn't seem to fully work.  For example, I'd get one boot where the desktop was really high res, then the next would be back to 1024x768, the 3D performance is really bad too; only 20fps for a trivial rotating quad; so I don't think I've got the video stuff working correctly.
<person987> Good to know that you have not had lockups, I have a friend who said his pandaboard has never locked.  I tried my SD card on it and it eventually locked on me :-)
<infinity> Yeah.  May well be your software/driver setup.
<infinity> If you're having troubles with the TI binary drivers, I'd recommend poking ndec.
<infinity> I don't touch them.
<person987> what is ndec?
 * infinity points at ndec.
<infinity> He's a who, not a what.
<person987> hehe
<infinity> TI developer, packages the binary stuff.
<XorA> a who can become a what after application of numerous alcoholic drinks :-D
<person987> oh great!  well you have been a huge help.  I will get another card and re-install everything.
<janimo> jcrigby, rsalveti the 3.1 kernel for mx5 has been running all night. I have not tested it heavily but I'd say it is good to  upload to precise
<jcrigby> janimo, ok will do
<XavB> person987: we (TI) have made a major update few hours ago, let us know if you are still seeing bad perf. Note that you will boot with TI kernel with DVFS on-demand by default. Then we are having perf impact with metacity compositing on and with unity-launcher running. More improvements shall come.
<XavB> Note: I am working with ndec... ;)
<burli> Hi, is it possible to run Ubuntu on this tablet? http://www.zenithink.com/Eproducts_C71.php
<burli> It has an Amlogic 8726-M and 512MB RAM
<Ziomuschio> hi there
<Ziomuschio> may I ask some info about a problem with echi-omap when installing ubuntu-omap-extras in pandaboard?
<rsalveti> janimo: great, thanks
<krosswindz> infinity: It takes forever to compile on the board, the reason I setup an ARM cross chroot on my x86 laptop
<krosswindz> infinity: The fix might appear bogus, I will try to disable optimization and see if it builds
<krosswindz> infinity: there definitely is some issue as I am running into exactly the same problem
<krosswindz> I am seeing oops when I try to either halt or reboot the board using this kernel.
<krosswindz> The trace is available here http://pastebin.pandaboard.org/index.php/view/94450538
<person987> XavB: thanks, I'm sorry but I don't understand most of your comment (DVFS on-demand? metacity? unit-launcher?)  My background is graphics programming but I'm a complete noob to Ubuntu.  I'd love to take a look at your latest update.  It would be great to solve my "hard-lock" problems as well as get some improved 3d performance.  If I can help you in any way with logs or details on my system
<person987> config I would love to.  (you might have to give me detailed instructions tho! :-)  How exactly do I get your latest update?
<XavB> person987: ok, no pb. So first step would be to upgrade to last sw and let us know if it improves the situation.
<XavB> then there are several settings you can do to improve graphics performance
<XavB> 1- modify DVFS that will decide about CPU ussage strategy, it is by default set to ondemand into file /etc/init.d/ondemand
<XavB> If you comment the setting or force performance value, you might gain few fps.
<XavB> Then by default you will be using Unity2D so metacity. Metacity is using compositing so graphics performance are impacted, you can install gconf-editor, then go into apps->metacity and uncheck box compositing manager. You will gain few more fps.
<person987> I can try this right now, first step was to "upgrade to last sw", how?  (sorry I'm new!)
<XavB> Last point is about unity panels, they are having an impact on graphics, you can kill them to gain few more fps: "sudo killall unity-panel-service unity-2d-panel unity-2d-launcher" 2 times.
<XavB> person987: You have installed TI PPA already right?
<XavB> or "TI OMAP Addons"
<person987> In the "Ubuntu Software Center", I had a package named "ubuntu-omap4-extras".  About 1/2 hr ago I removed that and rebooted to see if the hard-locks would go away.  Is that what you're referring to?
<person987> in software sources, I have ppa.launchpad.net/tiomap-dev...
<XavB> person987: yes
<OlivierN1> person987: fine, then re-install this package, and run an upgrade
<XavB> So perform an "apt-get update" then install manaually "ubuntu-omap4-extras"; it will be fine.
<person987> Ok, installing, it gave a warning about future updates not including some other linux kernel stuff.
<XavB> person987: normal
<XavB> You will have a TI kernel
<person987> Ok great.  I'm not too concerned about perf, my requirements are not too high.  The only reason I mentioned it was that I wasn't sure if I had things installed correctly.  So this is helping greatly.  I will probably not kill the panels but I'll try out disabling compositing. Almost done installing.
<XavB> person987: of course you'll need to reboot at the end of install
<person987> XavB: That brings up another thing, it hasn't been shutting down cleanly.  I always eventually have to pull power because it just sits on the ubuntu screen with the dots that cycle.  Is that normal?
<XavB> person987: I can observe wrong reboot with canonical kernel, new one shall "reboot fine"
<XavB> after reboot "uname -a" shall return: Linux ubuntu-desktop 3.1.0-1282-omap4 #10 SMP PREEMPT Tue Jan 24 15:52:14 CET 2012 armv7l armv7l armv7l GNU/Linux
<XavB> person987: is your reboot ok? UI up etc...
<person987> XavB: actually the update was still going.  It failed: Not all updates can be installed - run a partial upgrade to install as many updates as possible.
<person987> XavB: I'm going to have to get to work but I'll build a new image this weekend and get back to this point.
<XavB> person987: if you do it in 2 steps (2 dist-upgrades) it shall work, no need to reboot between both
<lool> Hey folks
<lool> The web indices for e.g. http://uec-images.ubuntu.com/precise/20120203/ which I think are generated from cdimage code say "For ARMv5t processors and above"; it's because for "armel" images we say "For ARMv5t processors and above." -- which was true in jaunty; since we don't really have any official ARM images for anything older than lucid which is ARMv7t2, I propose that we change it to ARMv7; is that ok?  would you rather have a different wording?  a
<lool> infinity, ogra_: ^
 * ogra_ has no clue about uec images, nor why there would even be arm ones
<ogra_> better ask #ubuntu-server ?
<ogra_> we didnt enable that
<lool> ok
<morphis> heyho
<morphis> I am wondering wether it's possible to build currently for armhf with uploading packages to my ppa
<morphis> anyone knows if it's possible?
<infinity> morphis: We don't currently offer ARM PPAs to the public for security reasons (we don't have virtualised ARM builders)
<infinity> morphis: That's in the works, but not done yet.
<infinity> morphis: If you want armel and armhf builds, your only option right now is to build locally.
<morphis> infinity: ok, thats good to know as it's very hard to find details about building for armhf and ubuntu today
<morphis> infinity: is there a definitive way how to build packages and images?
<morphis> I saw there is support for pbuilder to build packages with qemu
<infinity> morphis: If you don't have native hardware, qemu is certainly the easiest way to go.
<morphis> infinity: ok
<morphis> infinity: can you tell me also which hardware is recommended for building? I read about debian is using some i.MX53 boards but whats with the panda boards?
<morphis> whats cannoncial using for the armhf bootstrapping?
<infinity> morphis: We support both the Panda and mx53.  Ubuntu's buildds are Pandas, Debian's are mx53.
<morphis> ok
<morphis> infinity: you work for cannonical?
<infinity> morphis: If you can get your hands on a Pandaboard ES, they're well supported in Precise, and probably the fastest generally-available hardware right now.
<infinity> morphis: I do, yes.
<infinity> morphis: I was the person who did the armhf bootstrap.
<morphis> infinity: ah :D
<morphis> infinity: I already though about the Pandaboard ES
<morphis> I have done a lot with OpenEmbedded in the past were everything is cross compiled
<infinity> Yeah, we don't treat any of our ports as "embedded" targets.  armel/armhf are still complete Ubuntu builds and self-hosting.
<infinity> So, it's no different than x86 in that regard.
<morphis> thats somethine I really like
<morphis> cross compilation is sometimes very hard
<infinity> Honestly, most "embedded" work these days isn't. :P
<infinity> It's general-purpose OSes.
<morphis> as you have to map all the different build systems against the cross compilation (automake/cmake/...)
<infinity> Yeah, I know.  I used to work in scratchbox a lot with Maemo.  It was vile.
<morphis> :)
<infinity> And there was no good reason for it, once maemo was targetting devices as fast as the N900.
<morphis> but OpenEmbedded adds a very easy to use abstraction layout on top of it
 * infinity rnus off to lunch.
<morphis> infinity: Bon appÃ©tit!
<GrueMaster> ogra_:  Can you think of any omap/omap4 specific boot parameters that should be kept during netboot install?  I have "console=", "mem=", and "fixrtc".
<infinity> vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 fixrtc
<infinity> ^-- Should do it.
<GrueMaster> I'm trying to avoid hardcoding as much as possible.  If they weren't on the netboot boot.scr, they won't get passed through, although I would also like to get the preseed "d-i debian-installer/add-kernel-opts" section.
<GrueMaster> Not sure how to get that info in f-k-i.
<infinity> I suppose f-k-i could grow preseed support (at least, for that one option)
<GrueMaster> Yea, I'm looking into it now.
<GrueMaster> I have other changes I will be pushing soon (expect a merge request before EOD).
<infinity> GrueMaster: Looks like user-params from debian-installer-utils may be what's needed.
<GrueMaster> grmbl.  Netboot is having some serious issues this morning.  It is failing to install packages and sometimes losing connection to my mirror.
<GrueMaster> Ok, I'll look at that.
<infinity> Oh, maybe not.
<infinity> That's the inverse.
<infinity> Or, rather, what it does doesn't seem to match the README...
<infinity> Ahh, no.  I misread.
<infinity> The README says it "doesn't include preseeded values", what it really means is it literally doesn't include pressed/command/syntax=foo stuff on the commandline it spits out, which is what you want.
<infinity> But it does include stuff that's been preseeded *from* add-kernel-opts.
<infinity> So, yeah.
<infinity> user-params is probably what we want to run in f-k-i to transfer the installer commandline to the final system.
<infinity> Looks like grub-installer uses it, so that's comforting.
<GrueMaster> I just ran it and it is missing a few params.  It only spews fixtrc, console=, and mem= lines.  Missing vram= and (in one case) smsc95xx.macaddr=
<GrueMaster> Oh, nevermind.  It pulls that from the preseed (duh).
<GrueMaster> (I didn't look at the preseed of my currently running system).
<niklasfi> hi, obviously my beagleboard is ooming with the syslog repeatedly statign "eth0 kevent 2 may have been dropped", when doing a lot of io. I have had this issue since i got my beagle board back in 2010 and noticed the same behaviour on debian. did someone else notice this?
<krosswindz> I have noticed that on the pandaboard that I got 2 weeks back
<niklasfi> krosswindz: ohh good. then you saved me from making a bad purchase
<niklasfi> i was hoping this would be resolved due to more throughput
<krosswindz> niklasfi: not sure what the issue is google isnt helpful on it
<niklasfi> krosswindz: well not really, but as you may have noticed there is a workaround
<krosswindz> niklasfi: yes I noticed the work around but no real solution
<niklasfi> krosswindz: what value did you have to pump min_free_kbytes up to?
<infinity> Well, I see it very very infrequently on the Panda, and it has no adverse effects.
<niklasfi> infinity: it totally locks up my machine to the point that i have to press the reset button
<krosswindz> niklasfi: I havent played with that yet
<krosswindz> niklasfi: I am still trying to get my kernel compiled for it
<infinity> But, really, heavy I/O on a system where almost everything is on the same USB bus (such as the Beagle and Panda) will occasionally hitch up.
<infinity> niklasfi: I never have to reset, though I suppose if I was impatient, I might.
<infinity> niklasfi: (As in, the machine might seem unresponsive for a bit, but it always comes back)
<niklasfi> infinity: is waiting for half an hour impatient?
<krosswindz> niklasfi: I havent had the panda lock up yet
<infinity> niklasfi: No, probably not.  Unless you're doing half an hour of long I/O. :P
<niklasfi> is there a way to disable syslog? i think writing thousands of syslog messages does not help the situation
<infinity> niklasfi: But I was referring to the behaviour being mostly harmless on Pandas.  I don't have a Beagle.
<infinity> What's writing thousands of syslog messages?
<infinity> syslog culls duplicates.
<niklasfi> infinity: when the system freezes, it does. and no it does not filter out the duplicates
<infinity> Weird.
<infinity> And if it's flushing buffers and writing logs, I'd hardly call that "frozen".
<infinity> Just "really busy".
<niklasfi> infinity: if you connect via serial port you just see thousands of messages, and if you use ssh, it does not respond
<niklasfi> ok. between 11:57 and 12:00 the system froze and generated 10000 lines of syslog. then again at 12:04 the system froze for another five minutes leaving another 10000 lines of syslog
<krosswindz> wow that is a lot
<krosswindz> what i/o load were you generating around then?
<niklasfi> just for today i have 69418 lines of syslog
<niklasfi> umm. i don't really know actually most of today was downloading stuff from the internetz so i guess maybe 800kB/s
<niklasfi> over a long period of time
<niklasfi> the system is capable of doing up to 4MB/s for short intervals, of maybe 1 or two minutes before locking up
<mythos> is canonical paid for to develop this SDK "http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/index_FDS.html" for TI?
<infinity> mythos: If they are, I don't know about it (and I'm "them").
<mythos> hmm... thx infinity. i only ask, because my boss said, that citrix said, that ti is paying canonical for this SDK...
<niklasfi> is there a board available that is more stable maybe even with (e-)sata support?
<infinity> mythos: That's a rather roundabout list of saids. ;)
<mythos> infinity, yeah, that's why i asked =)
<infinity> niklasfi: The i.MX53 QuickStart has SATA.
<GrueMaster> niklasfi: The Freescale Quickstart has SATA and we support it.
<infinity> For some value of "support".
<infinity> But we have images, and they work.
<niklasfi> infinity: can i boot from sata?
<mythos> so you are canonical's "arm-team", infinity? ^^"
<niklasfi> sadly it does not have gigabit ethernet :(
<niklasfi> is that possible though with current arm hardware?
<infinity> mythos: I'm one of them. :P
<infinity> niklasfi: It's not that it's not "possible", there are two primary reasons why it's not often done.
<niklasfi> infinity: what are they?
<infinity> niklasfi: 1) Most of these cheap dev boards like to hang all their devices off USB.  USB can't do GigE (well, it could, but not at full-speed, so why bother?)
<infinity> niklasfi: 2) GigE is wildly more expensive than 100baseT, and they're trying to keep the dev boards affordable.
<niklasfi> am I the only one who thinks these boards make perfect home servers?
<infinity> niklasfi: If you want something designed to be a server instead of a cell phone dev platform, you might want, say, a Trimslice.
<infinity> niklasfi: They're a tiny bit (not much) more expensive, but come with GigE and SATA options.  And actual cases.
<mythos> so, if i have a dev board with 2 gbit ports, i have a very expensive one? o.o
<infinity> mythos: From the POV of cost-cutting, yes. :P
<infinity> mythos: (Which board is that?)
<mythos> infinity, http://software-dl.ti.com/dsps/dsps_public_sw/ezsdk/latest/exports/DM814x_AM387x_EVM_Quick_start_guide.pdf
<mythos> there are some images in the pdf too
<mythos> rather nice. i boot it via sdcard and mount the rootfs via nfs
<infinity> mythos: Shiny.
 * infinity is trying to resist buying a Trimslice.
<mythos> re
<mythos> what was the last thing, i wrote here?
<infinity> 15:30 < mythos> rather nice. i boot it via sdcard and mount the rootfs via nfs
<mythos> oh, ok... thx
<niklasfi> infinity: are they that tempting?
<infinity> niklasfi: I like toys.
<niklasfi> infinity: but i don't know. i really can't trust these guys if they make their webpage that crappy
<infinity> And it would replace my mx53 as my archive mirror.
<infinity> Your trust is based on the quality of people's web design? :)
<infinity> It's actually not that bad for a small manufacturer.
<infinity> I've seen much worse sites. :P
<niklasfi> infinity: yes, it is very much in deed. if people can't set up a proper site using a markup language, how can i trust them with turing complete languages, or even hardware
<infinity> Hardware nerds don't tend to care much about pretty web sites, in my experience.
<infinity> So, really, what you're looking for is "did they hire a good web monkey", to which the answer appears to be "no".
<infinity> (Hint, Canonical employs web developers to work on the website, and they're not the same people who work on Ubuntu, so judging one by the other would, again, be silly, right?)
<niklasfi> infinity: i guess the problem is that i am no hardware nerd. I sometimes would very much like to understand what you guys do, but i haven't even gotten to learning all of the boot options i need to manually start my ubuntu from grub
<mythos> uboot is/was new to me too
<niklasfi> infinity: yes. but it gives me information about how much they care about their user base. if they are alright with making them suffer by showing them crappy web pages, they are probably alright with making them suffer by giving them bad support
<mythos> but with some time, you can learn everything
<infinity> niklasfi: Most of the support for the Trimslice is via their wiki.  Then again, that's not much worse than the situation with most dev boards. :)
<infinity> (To be clear, I have no affiliation with them, and I don't even own one, but they look neat and, like I said, I like toys)
<GrueMaster> infinity: On this f-k-i bootparm issue, I'm trying to figure how best to ensure some kernel parameters are passed from cmdline or enabled via preseed.  I need to make sure none are duplicated.  Suggestions?
<GrueMaster> I really don't like scripting in shell.  Especially busybox.
<infinity> GrueMaster: Well, I get the impression that user-params smooshes together both command line and preseed into one.
<infinity> GrueMaster: I didn't look closely, but I assume it removes dupes?  Dunno.  If not, it should.
<GrueMaster> Nope.  Just preseed from what I can tell.
<infinity> GrueMaster: No, not just preseed.  It starts by parsing cmdline.
<infinity> GrueMaster: Most of the script is about parsing and filtering cmdline, then it adds the preseed bits at the end.
<infinity> GrueMaster: Although, I think it only parses and collects options after the "--" (ie: user-added options)
<GrueMaster> Possible.  I'm looking at it now.
<infinity> GrueMaster: Which makes sense, since f-k-i or grub-installer, etc, should be what's responsible for making sure platform-specific options are in place.
<GrueMaster> So the mem= lines should be on by default for omap4.  makes sense.  I can do that.
<infinity> GrueMaster: Anyhow.  Avoiding duplicates is easy enough, we can just loop through our options in f-k-i.
<GrueMaster> What I don't see though is things like module parameters, or console parameters.  Not that either are critical for first boot afaict.
<infinity> GrueMaster: Well, if you were to add module params manually, they'd land after the -- ... Or they should.
<infinity> So, user-params would pick them up.
<GrueMaster> Ok.  The kernel shouldn't care I guess.
<GrueMaster> d-i sucks in so many ways.  http://paste.ubuntu.com/828261/
<infinity> GrueMaster: I don't see anything sucking there.
<infinity> GrueMaster: Everything's listed the same number of times it's provided.  We can easily make them unique later.
<GrueMaster> Only that user-params is spewing both /proc/cmdline and preseed.
<infinity> GrueMaster: It's supposed to.
<infinity> GrueMaster: Like I said, everything after the -- on cmdline, plus preseed.  That's intentional.
#ubuntu-arm 2012-02-04
<GrueMaster> I thought it would be more intelligent than that.  Now I have to add intelligence to f-k-i.
<infinity> I can do the shell bits in f-k-i.
<infinity> I know how you love shell. ;)
<GrueMaster> If it was perl, I'd be all over it.
<GrueMaster> But seeing how everyone around here loves perl....
<infinity> I have nothing against perl.
<infinity> Plenty against pulling another interpreter into d-i, though.
<GrueMaster> If you can fix it, great.  Be sure to tag bug 848782 and bug 921137.
<ubot2`> Launchpad bug 848782 in flash-kernel "Serial console not enabled for passphrase prompt when using LUKS" [Medium,In progress] https://launchpad.net/bugs/848782
<ubot2`> Launchpad bug 921137 in flash-kernel "Flash-kernel-installer doesn't support d-i debian-installer/add-kernel-opts in preseed " [Undecided,Confirmed] https://launchpad.net/bugs/921137
<rcn-ee> GrueMaster, if flash-kernel is going to read kernel-opts, how about a nice "stop, don't run flash-installer" option, for those of use with custom kernel's. ;)
<GrueMaster> rcn-ee: This is for netboot install only.  If you are doing a custom kernel install with netboot, there are other settings you can add to the preseed for that.
<rcn-ee> there is? guess i haven't looked thru the d-i preseed options enough.. ( just let flash-installer run, and then cleanup with a script before rebooting..)
<GrueMaster> "d-i base-installer/kernel/skip-install boolean true" will skip the normal kernel install.  Then you can add a package repo and install a kernel in a later section.  I have that for a dev platform where the kernel is only on my local server (not in the pool).
<rcn-ee> cool GrueMaster, thanks for that tip.. (your doing pretty much what i was doing..)  I'll give that option a run over the weekend..
<GrueMaster> Now this is getting ridiculous.  I have been trying to reimage all day and keep hitting this:  in-target:   Temporary failure resolving 'mirror.gruenet'
<GrueMaster> Only happens when installing the kernel.
<infinity> GrueMaster: Yeah, I'll take both those bugs and upload later tonight.
<infinity> GrueMaster: In the process of doing a migration on my co-lo machine right now, and I have the KVM for a limited time, so that forced me to take a break. :P
<GrueMaster> Ah
<GrueMaster> No rush.  Just had the code in front of me and thought I'd give it a go.
<GrueMaster> Ran out of steam.
<infinity> Does LVM really require a /boot outside the VG, or is partman being overly cautious?
<infinity> I thought grub could peer into LVM volumes.
<GrueMaster> Grub can.  u-boot can't.
<infinity> Sure, but this co-lo machine is x86. :P
<infinity> And d-i's telling me it wants a small ext2 /boot outside the VG.
<GrueMaster> And I don't think grub can peer into an encrypted filesystem.
<infinity> Trying to decide if that's necessary, or a bug.
<infinity> Yeah, not doing encrypted.
<GrueMaster> Oh.
<GrueMaster> exit
<GrueMaster> sigh.  Sometimes two monitors can be a pita.
<scientes> what is the best way to install ubuntu-arm in qemu?
<scientes> link with virt-manager
<shaola> qemu-usr-static and debootsrtap?
#ubuntu-arm 2012-02-05
<Person987> Hi all, I'm trying to install the omap4 extras from TI on my Pandaboard.  I have reached a screen which wants me to agree to the "TI TSPA Object cod Software License Agreement".  It looks like a dialog box made with text graphics and has an <OK> at the bottom.  I can't figure out how to click "OK"  :-)
<mythos> tab and enter?
<Person987> Lol that works!
<mythos> np
<pnphi> joined
<pnphi> excuse me
<pnphi> excuse me
<krosswindz> I am trying to build ubuntu oneiric kernel in a armel cross chroot
<krosswindz> I am unable to build because of the following error: scripts/kconfig/zconf.tab.c:2505:0: internal compiler error: in insert_vi_for_tree, at tree-ssa-structalias.c:2740
<krosswindz> I was wondering if anyone has seen this
<mythos> hmm... wouldn't it be easier to cross-compile it outside the qemu-environment with CROSS_COMPILE=arm-linux-gnueabi-?
<krosswindz> mythos: I thought using a cross chroot I can leave my host environment unmodified
<mythos> qemu does have some issues if a process needs to much memory (in my experience)
<krosswindz> hmm
<mythos> and you can set up a cross-compile-environment inside the chroot ;-)
<krosswindz> ;)
<mythos> but in fact, that was my my first shot/try also... it works, but has it's limits
<krosswindz> ok
<krosswindz> I tried removing -O2 from KBUILD_CFLAGS still no luck :)
<krosswindz> s/)/(/
<mythos> yeah, that's the first hit google gives you, if you run in such problems ;-)
<mythos> i was lucky and it worked with python2.4...
<mythos> so, you should really try a cross-compilation or a native build
<krosswindz> I tried a native build
<krosswindz> I am seeing segfaults
<krosswindz> I already have the 768MB work around
<krosswindz> http://pastebin.com/pmSbm4pd
<mythos> oh, than your last shot is cross-compilation
<mythos> *then
<krosswindz> I am trying to avoid it if possible
<krosswindz> probably setup a chroot and cross build inside that
<krosswindz> wonder how the kernels are built in ports
<krosswindz> are they cross built or in cross chroot :p
<mythos> if you are idling long enough, one from canonical's arm-team will surely answer your question
<mythos> but, i'think, they said that they use panda-boards to compile their packages
<krosswindz> that would take forever
<krosswindz> compiling on the pandaboard is so slow
<mythos> look at the topic...
<krosswindz> interesting if they are building everything on pandaboards
<mythos> yeah... i have to consider this too...
<mythos> if they use native builds for everything, maybe i should that too for my projects
<krosswindz> probably some of the devs could answer this
<mythos> krosswindz, maybe out of context, but that's what i found in the channel history http://pastebin.com/DEcZvhj9
<krosswindz> mythos: guess they are using pandaboards as buildd
<mythos> i guess so too
<krosswindz> guess I might switch precise and see if that solves my build issues
<mythos> go for it =)
<krosswindz> will try armhf if it doesnt work I can always revert back to oneiric
<krosswindz> should get a couple of more sd cards :p
<mythos> if possible, i would use a nfs configuration
<mythos> my board is able to load linux via tftp and rootfs via nfs
<mythos> but it is a uncommon ti board. i don't have a panda or anything else
<mythos> maybe all u-boots can do this...
<krosswindz> uboots can do it
<krosswindz> the x-loader has an option on the pandaboard to boot using tftp
<krosswindz> I havent tried it though
<mythos> it is a really neat feature =)
<scientes_> where can i get debian-installer images for qemu?
<mythos> scientes_, i think, you are looking for this http://wiki.debian.org/ArmEabiHowto
<scientes_> no, found what i needed: https://wiki.ubuntu.com/Core
<scientes_> (if there are arm versions...)
<scientes_> i am trying to install ubuntu arm in qemu
<scientes_> to test some software that fails in debian arm and x86_64, but works in ubuntu x86_64
<scientes_> *debian armel, when compiled from source
<mythos> "Installing armel to qemu with d-i" <-- but if you found what you are looking for, that's also awesome =)
<scientes_> hmmmm, actually, emulated compiling is probably too slow
<scientes_> mythos, yes, but where is the d-i for UBUNTU
<scientes_> i.e. alternate installer in ubuntu-land
<scientes_> I guess i will need to use a chroot or something on my arm device
<mythos> that was not what you asked for ;-)
<scientes_> well, this is #ubuntu-arm
<infinity> mythos: Sure it is.
<scientes_> i thought it was implied
<infinity> mythos: debian-installer implies the software, not the distro.
<scientes_> infinity, precisely
<infinity> scientes_: http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current/images/linaro-vexpress/netboot/
<mythos> infinity, hmm... i'm not sure, if i understood that? so debian-installer ist capable to install ubuntu?
<infinity> scientes_: Unfortunately, we don't provide vexpress netboot images for armhf yet.  I should put that on my TODO before I forget again.
<infinity> mythos: debian-installer is the underlying technology for all our installers.
<scientes_> infinity, which one would be faster for emulation?
<scientes_> infinity, except liveCD IIRC
<infinity> scientes_: ubiquity uses d-i components to do all the "real work".
<infinity> scientes_: (ubiquity being the GUI livecd installer)
<scientes_> infinity, ahh, now i know
<scientes_> i though it just copied the image
<infinity> Copying is the easy part. ;)
<infinity> (ish)
<scientes_> the squashfs image, with cp -a or something
<infinity> It copies the squashfs, and then runs all the d-i bits inside the target.
<scientes_> instead of installing every deb seperately
<mythos> infinity, i don't want to argue against it. so i apologize
<scientes_> fedora is differn't, cause their livecd doesn't support anything but ext4
<infinity> mythos: I suppose you could argue if you wanted. ;)
<scientes_> as a limitation of the way they are doing it IIRC
<mythos> infinity, sure... ;-)
<scientes_> but on a differn't note: is compiling in qemu going to be horribly slow?
<infinity> scientes_: Yes.
<scientes_> and will i have better luck with a chroot on a real, but slow, arm device
<infinity> scientes_: On the fastest hardware we can get our hands on, qemu barely beats out a pandaboard.
<infinity> scientes_: And you probably don't have that hardware.
<scientes_> I have a sheevaplug
<scientes_> but it has debian wheezy on it
<infinity> Oh, well, the sheeva's not exactly speedy either.
<krosswindz> infinity: do you have any suggestion for size of the sd card for building things natively on the pandaboard
<scientes_> pandaboard at least supports VFP
<infinity> Wait, you can't even run Ubuntu on a sheeva, can you?
<infinity> Isn't in ARMv5?
<scientes_> infinity, so which should I try, chroot on sheeva, or qemu?
<scientes_> oh, your right
<infinity> s/in/it/
<scientes_> only old version
<scientes_> it actually ships with some version of ubuntu
<scientes_> (don't remember cause i replaced it very quickly with debian)
<infinity> krosswindz: I recommend a tiny SD card, a netboot image, and installing to a nice external USB drive.
<infinity> krosswindz: Honestly, while running from SD makes for cute demos, it's slow, and it kills SD cards.
<krosswindz> infinity: true
<scientes_> infinity, ahhh, its bad to run embedded from SD?
<infinity> scientes_: Yeah, we used to support v5 for a while, then v6 for a while, but we've been v7-only for ages.
<scientes_> with or without VFP?
<infinity> v7 implies vfp.
<scientes_> so basically armhg
<scientes_> *armhf
<krosswindz> infinity: if I install on to the usb drive I should be able to use the normal USB port right  and not the OTG
<infinity> Out armel port uses softfp calling conventions (but still uses the vfp unit), and armhf uses hardfp calling conventions.
<infinity> krosswindz: Yeah, either of the two normal USB ports.
<scientes_> why? if armv7 implies VFP?
<scientes_> you would get 40% better performance on some hardware (armhf info page)
<infinity> scientes_: Hence the armhf port.
<krosswindz> nice I think thats what I will do then
<krosswindz> I should have an old 80G sata drive lying around some where
<scientes_> seems like you should drop the soft float conventions all together
<infinity> scientes_: armel uses the softfp ABI because that's just the way things were done for compatibility (and sanity) reasons.  Porting everything to the hardfp ABI was some effort.
<infinity> scientes_: The armel port will likely become unsupported this cycle.
<scientes_> gotcha
<infinity> scientes_: We're trying to move the world to armhf.  I've put a lot of work into this. :P
<infinity> krosswindz: http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/
<infinity> krosswindz: If you just write out one of those images (boot.img-serial or boot.img-fb) to an SD and boot, you should be able to install to an external drive and save a lot of pain.
<krosswindz> infinity: thanks for the link
<scientes_> eek, it seems like testing this software will be a PITA
<krosswindz> infinity:  thanks
<krosswindz> once I am done installing I dont need the sd card to boot or would I need it still
<scientes_> maybe i can use the packages i built in debian
<infinity> krosswindz: It'll still need an SD card around to flash a bootloader to, so you don't get to go completely SD free (the Panda has no firmware), but reading a bootloader on boot is a heck of a lot better than running your whole OS from the card)
<krosswindz> agreed
<krosswindz> I can build natively on the pandaboard
<scientes_> whats the package for qemu-arm?
<scientes_> krosswindz, thx, its opencpn.org
<infinity> scientes_: qemu
<scientes_> infinity, that just installs qemu-kvm now
<mythos> apt-file search qemu-arm
<infinity> scientes_: Or, if you want to do binfmt-misc emulation (which is much less annoying), qemu-user-static
<infinity> scientes_: Yeah, qemu-kvm should include qemu-system-arm, does it not?
<scientes_> don't know i was trying to use virt-manager
<infinity> Oh, those may have been split off into qemu-system
<infinity> Anyhow, qemu system emulation is almost never what you want, unless you're debugging bootloaders.
<infinity> qemu binfmt emulation is much less annoying.
<krosswindz> infinity: are there md5sums for the files around some where
<infinity> http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/MD5SUMS
<krosswindz> thans
<krosswindz> thanks*
<scientes_> poof!, my computer randomly rebooted
<infinity> scientes_: Welcome back.
<scientes_> wierd
<infinity> scientes_: So, as I was saying. ;)
<scientes_> anyways, no infinity qemu-kvm only has qemu-system-i386 and -x86-64
<mythos> <mythos> apt-file search qemu-arm
<infinity> scientes_: Yeah, the others were broken out into qemu-system
<scientes_> exactly
<scientes_> installing now....
<infinity> scientes_: However, you almost certainly don't want an actual qemu-system, unless you're debugging bootloaders.
<scientes_> oh ok
<scientes_> oh yes, there is multiarch !!!!! :):):)
<infinity> scientes_: If you install qemu-user-static, then you can work with ARM binaries as if they were native.
<scientes_> I don't see -static, just qemu-user
<scientes_> but that is OK
<mythos> search for qemu-arm-static
<scientes_> krosswindz, should i just use what i built on my sheevaplug in debian wheezy, or do you want to build opencpn ( opencpn.org ) ?
<krosswindz> scientes_: I am sorry I guess you there was some miscommunication
<infinity> scientes_: qemu-user-static definitely exists (and is the required one in this case), I just installed it.
<scientes_> ahh it does, what is the difference?
<scientes_> oh, i read the desc, nvm
<scientes_> wait, no I don't know why
<scientes_> dpkg --add-architecture armel ? now
<infinity> scientes_: http://paste.ubuntu.com/829726/ <-- witness the magic.
<infinity> scientes_: You could do multiarch too, but that gets messy.  Do you really do your builds in your base system, not in chroots?
<scientes_> oh gotcha, that looks much cleaner
<scientes_> krosswindz, oh, gotcha
<scientes_> OK, all this talk about SD cards----so if I launch an embedded device, it is smart to not use a SD root?
<infinity> scientes_: If you're building an actual embedded device, hopefully that assumes you're taking great pains to make sure you're not doing things like logging to filesystems, etc.
<infinity> scientes_: If you never write to the card except to update software, SD's a fine choice.
<scientes_> ok, so all the problems with SD are going to be the same with NAND flash?
<infinity> scientes_: If you run a general purpose OS on it, and call it "embedded" without making sure you neuter that sort of behaviour, you're going to kill a lot of flash.
<scientes_> not the FTL?
<scientes_> *do any come from the FTL?
<infinity> scientes_: Hrm?
<infinity> I'm not sure I understand what you're asking.
<scientes_> flash translation layer---why SD is a block device, not a mtd
<infinity> Yes... But I'm not sure what you're asking about FTLs.
<scientes_> well is that the source of SD problems?
<scientes_> or are their problems shared with raw NAND flash?
<infinity> No, the source of problems is rewriting flash, full stop.
<scientes_> ok, that is what i was asking
<infinity> And raw flash is usually worse than something with a decent FTL implementation, cause at least decent FTLs (like those found on SSD disks) do proper wear-leveling.
<infinity> But, at the end of the day, excessive writes kill flash, even SSD disks.
<scientes_> infinity, ubifs does wear-leveling just great
<infinity> SD cards tend to die much faster than SSDs, though. :P
<infinity> (I've killed a lot of SD cards working on ARM porting...)
<scientes_> ahh, very heavy usage
<scientes_> would you recommend logging to tmpfs?
<infinity> Logging to a tmpfs is reasonable, sure.  Means you don't get permanence, but it's enough for spot disagnostics.
<scientes_> is it just the number of writes, or maybe to fast, etc?
<infinity> Most embedded projects really don't need logs, though.
<infinity> Or, really shouldn't?
<mythos> i think, a minimal logging into ram is fine. for the rest a log-server should be used
<infinity> Cause once you sell it to a customer, do you really expect them to be mailing you lofs? ;)
<infinity> logs*
<mythos> yes i do
<infinity> scientes_: Speed doesn't really matter, it's just the number of writes, period.  And yeah, logs are the worst culprit right after atime (but sane people always disable atime on flash)
<infinity> mythos: If every set top box, phone, and smart TV in my parents' house expected them to be "informed and educated" users who filed bug reports with logs, I suspect they'd just stop buying these computers disguised as appliances.
<scientes_> infinity, what about relatime?
<scientes_> (mainly for completeness)
<mythos> infinity, i have to care about thinclients, so... ;-)
<infinity> scientes_: I've never seen the point in relatime.
<infinity> scientes_: But it would fall in betweenish, I suppose.  Much less likely to update, but it's still unnecessary writes for a flash device.
<scientes_> yeah, go with atime
<scientes_> i mean noatime
<scientes_> seems like btrfs might be smarter for a flash device---ugh
<scientes_> i still hate that ugly FTL
<scientes_> and would rather just put ubifs on it
<infinity> mythos: Well, I tend to view thinclients more like "really crappy computers" than appliances, in the enviroments where most people use them.  That said, it would be much nicer if they were appliances.
<mythos> i don't like them either
<mythos> but what shall i say... somehow i have to earn money
<infinity> And back in the days when you could buy X terminals off the shelf from IBM and Wyse, and thin clients were much less fat than they are today, they were very appliancy.
<mythos> ;___; i'm sorry
<infinity> Oddly enough, I think we've almost come full circle.  The full-features "appliance" IBM thin clients I used to work with that did seamless desktop convergence between X11 and WinNT/Metaframe were, if I recall, running StrongARM CPUs.
<infinity> Really, really slow ones. :P
<scientes_> infinity, do you use udev in your chroots, or bind mount /dev ?
<infinity> scientes_: Neither, I just mount devpts.  But if you actually need all the nodes, bindmounting /dev is the sane option, yes.
<infinity> Oh, no.  Wikipedia has educated me.  Those were PPC (first gen) and Pentium (second gen).
<scientes_> how do i see what breaks a package without installing aptitude?
<scientes_> nvm, it just printed it out
<mythos> infinity, as far as i know is arm rather new for thinclients.... i know a hp armv3-device, but that's it
<scientes_> mythos, even if it is new, it seems like it would be the way to go in the long run, considering the power consumption
<infinity> mythos: Yeah, I'm trying to think of why I got confused about that one.  Well, other than the part where it was 15 years ago and I'm old. :P
<mythos> *g
<mythos> scientes_, yes, you are right
<mythos> it is the new hot stuff for citrix and vmware... (lot of work for me... that's why i'm here)
<scientes_> infinity, oh your right, multiarch wouldn't work because it doesn't include binaries
<scientes_> *executables
<infinity> http://www.ebay.com/itm/IBM-07L8402-Network-Station-1000-/320556566601?pt=LH_DefaultDomain_0&hash=item4aa2a90849
<infinity> ^-- Memories.
<infinity> And 95 bucks for nostalgia is tempting.
<scientes_> is there a multiarch way to have the binaries put in a special place, and then you just set your $PATH approiately
<scientes_> and have binfmtmisc with qemu do the rest?\
<infinity> scientes_: No.
<infinity> scientes_: Multiarch pretty much assumes that you don't want the same binary twice. (which is a fair assumption, generally)
<mythos> infinity, i have to support the emulator for this device ;-)
<scientes_> that way you could still use all your installed utilies in the not-chroot, like git, etc
<infinity> scientes_: Of course, for development, this isn't a big deal, as you usually only need the foreign-arch libraries, not binaries.
<infinity> scientes_: Still, chroots are much cleaner.
<scientes_> instead of having to have two terminals open for the chroot :)
<krosswindz> infinity: is there a US mirror for ports
<scientes_> yes, two terminals at once isn't that big of a deal
<krosswindz> infinity: netboot gives the otion of only UK
<infinity> krosswindz: There may be one or two, but I don't know of any.
<krosswindz> option*
<krosswindz> infinity: thanks
<infinity> krosswindz: The only official ports mirror is ports.ubuntu.com
<krosswindz> infinity: ok
<infinity> scientes_: Yeah, I guess I don't notice how or why it bugs people, because I've always done all my development in chroots, long before I could also do fancy emulated chroots. :)
<infinity> scientes_: My laptop has pretty much nothing installed in the base system, and each bit of software I work on gets a new clean chroot.
<infinity> (waste of space, maybe, but it helps maintain sanity)
<scientes_> http://paste.ubuntu.com/829746/
<infinity> scientes_: sed -i -e 's/main/main universe restricted multiverse/' /etc/apt/sources.list && apt-get update
<scientes_> hmm, why don't you use vserver with vhashify then?
<scientes_> so that all the duplicate files get hardlinked together in a sane way
<scientes_> which reduces both disk AND ram consumption
<scientes_> along with security which doesn't exist with chroots
<infinity> Security's a non-issue.
<infinity> For my use-case.
<scientes_> but what about vhashify?
<infinity> This is just about not having junk in my base system, and not polluting package builds.
<infinity> The de-duping might be neat, but *shrug*... Don't care? ;)
<infinity> I build and delete chroots several times a day, it's not like they live long.
<scientes_> are you at least running the ram consolidation thingy designed primarily for KVM?
<infinity> My workflow comes from more than a decade of buildd maintenance, it's not "sane" to most people, but it works for me.
<scientes_> it just scans ram and loops for things that are the same
<mythos> sooo... chroot is a "good enough"-solution :o
<infinity> RAM consolodation doesn't matter, I'm not running long-running processes in these chroots.
<infinity> Build, compile, wipe.
<scientes_> http://paste.ubuntu.com/829746/ <----help
<infinity> scientes_: sed -i -e 's/main/main universe multiverse/' /etc/apt/sources.list && apt-get update
<infinity> ^-- I did.
<scientes_> infinity, ahh, yes universe needs to be on, thx
<scientes_> no multiverse thxuverymuch however
<infinity> ;)
<infinity> You shouldn't need restricted either, but you have it on.
<infinity> (If you're trying to avoid non-free software sneaking up and biting you in your sleep)
<scientes_> that was just the default for the ubuntu core tar.gz
<infinity> Yeah.  I should revisit that.
<infinity> I picked "main restricted" pretty arbitrarily when I first put core together, just based on the fact that it used to be our default in, like, dapper?
<scientes_> what is the default now?
<infinity> I sometimes live in the past.
<infinity> The default now is, I believe, all 4 components enabled after install.  But I'm not positive of that either, I'd have to install a fresh Ubuntu. :P
<scientes_> definitely not
<scientes_> it just feels like that the way software-center works by default
<infinity> Yeah, maybe.
<infinity> Perhaps the default is still "main restricted", or possibly just "main".
<infinity> I'm too lazy to dig through code right now.
<infinity> Plus, "default" depends on how you install.  Keeping those things in sync is annoying.
<scientes_> infinity, I think you should just enable main
<scientes_> oh wait, its not just armel
<infinity> It's all arches.
<scientes_> i was thinking that the hardware that gets restricted put on default is not present with arm
<infinity> But, that said, people shouldn't need fancy binary opengl drivers in a minimal chroot.
<infinity> And if they do, they can edit sources.list. :P
<scientes_> ^^ precisely
<scientes_> so just put it main, and be done with it
<infinity> Well, I was tossing around the idea of going the other way too.
<infinity> Since people constantly say "I tried to install $foo and it's not found, is ubuntu-core crap somehow?"
<infinity> Or "is this built on ARM?!"
<scientes_> i havn't looked for a while but it seemed like ubuntu was shipping some pretty schetchy stuff in multiverse
<infinity> When the answer is, invariably, "enable universe".
<scientes_> compared to debian's non-free being pretty reasonable when i looked at it
<infinity> scientes_: Well, multiverse is just the non-free component of universe.  So, sure.  I guess that's sketchy on top of sketchy. :)
<infinity> But it's not like enabling it forces people to install things from it.
<scientes_> infinity, but it was bigger than debian's non-free
<krosswindz> infinity: I am installing precise on an usb hard drive, I dont need a separate boot partition on it since that will come from the SD card right?
<infinity> And we don't allow dependencies from main to universe or from universe to multiverse, so...
<infinity> krosswindz: Right.
<scientes_> debian was like: nasa worldwind (open source, but bad license), xtides-data-nonfree (asshole govmnts), and hardware support
<infinity> scientes_: Debian has, historically, been kinder to their mirrors with regard to non-free.
<infinity> scientes_: If something was widely non-redistributable in, say, several EU countries, or the US, or whatever, they wouldn't carry it.
<infinity> scientes_: multiverse, we just say "look, it's hosted in the UK, mirrors don't have to mirror it, if they do, we assume they've read the licenses, HTH, HAND".
<scientes_> it drives me nuts how governments, that need good map data in order to do taxes, etc, double charge their citizens
<scientes_> the US is like the only sane country in this regard
<infinity> scientes_: Yeah, well.  The US and software sanity is a sore topic for Debian too.  It took us FOREVER to get rid of the stupid "non-US" split for crypto. :(
<scientes_> the NSA managed to hold back encryption for 10 years with that stupid shit
<StevenK> And even then it involved something like 850 pages being sent to the US government.
<StevenK> By hand.
<scientes_> also: software patents
<infinity> StevenK: Yeah, it was tons of special.
<infinity> StevenK: I haven't kept up, do you know if Debian's finally managed to obtain a blanket waiver, or if ftpmaster is still automating an e-mail to the US govt for every NEW package?
<StevenK> I think its the latter.
<infinity> Ridiculous. ;)
<scientes_> infinity, what percentage of packages correctly cross-compile?
<infinity> scientes_: Like xdeb, cross-build the package style?  Probably a much lower number than  you'd like.
<infinity> scientes_: Building natively (or "natively" under emulation) is still the way to go.
<scientes_> yeah, i just assumed that I should default to natively
<infinity> We've been working on improving the numbers for cross support for specific dependency chains.
<scientes_> sure the kernel can do it, but not much else
<scientes_> are there any list of what chains work?
<infinity> But, personally, I think it's wasted effort.  ARM hardware is getting faster every day and, while I appreciate that people are spoiled and all, if I can build the entire armhf archive in ~15 days, it's not "slow".
<scientes_> it supposedly fixes alot of bugs to get cross-compile working
<infinity> scientes_: Not sure how far that's gone.  It was mostly being done by Linaro folks, IIRC.  I'll be at Linaro Connect in, like, 2 days though, and I think we have a catch-up session on it. :P
<infinity> scientes_: Err, what?  How would cross-compiling fix bugs?
<infinity> scientes_: That sounds a whole like like misinformation.
<infinity> s/a whole/a whole lot/
<scientes_> probably is, only read it once
<scientes_> some random comment on lwn or something
<infinity> At best, cross-compiling will provide you with binary-identical output, at worst, the cross version will be horribly broken compared to the native.
<infinity> I can think of any scenario where it would be better. :)
<scientes_> I built the linux kernel with distcc on x86_64 and arm at the same time, and it booted!
<infinity> s/can/can't/
<infinity> In general, cross should get you binary-identical output these days.  GCC and binutils are much saner than they used to be.
<infinity> But.
<infinity> There's always a but.
<infinity> And the buts never favour the cross environment.
<krosswindz> infinity: what about cross chroot using qemu
<infinity> krosswindz: That's essentially "native", for the purpose of this discussion.
<scientes_> yes
<krosswindz> ok
<scientes_> cross-compiling is much faster
<scientes_> emulation is not
<scientes_> but I was definitely impressed with i could use distcc with arm and x86_64 cross at the same time, and boot what came out
<scientes_> infinity, oh geeze, you should have put no-install-recommend in the core.....
<scientes_> oh wait, i guess it did that
<scientes_> just alot of stuff
<infinity> scientes_: You can specify it on the command line.
<scientes_> i know that, i thought it was installing a bunch of worthless stuff, but i scrolled up, and it listed the recommends sep, which IIRC means it didn't install them
<infinity> I type "apt-get --no-install-recommends --purge install $foo" so often that it's muscle memory. :P
<infinity> scientes_: No, it lists them even if they're also in the install list.  If you didn't specify it, you got recommends.  It's our default.
<scientes_> ahh ok, tons of worthless stuff
<scientes_> as i suspenected
<scientes_> it was alrady installing when i was like O shi... i forgot
<infinity> Heh.  Oh well, not world-ending. :P
<infinity> The only place where we actually have no-install-recommends in the apt config is our buildd chroots.
<infinity> For obvious reasons.
<scientes_> i have added it to apt.conf.d so many times.....
<scientes_> I also forgot to use my apt-cacher-ng.....
<krosswindz> infinity: I was trying to install using net boot to USB drive
<krosswindz> kernel fails to install
<krosswindz> any way to check the log over serial console?
<infinity> krosswindz: Weird.  It definitely shouldn't.
<infinity> krosswindz: It logs to syslog.
<infinity> krosswindz: But I'm about to head out.  You might try poking GrueMaster tomorrow about it, he netinstalls all day, every day.
<krosswindz> lol k
<krosswindz> if I want to check syslog
<krosswindz> is there any way over serial console
<krosswindz> I would have to quit installer right?
<infinity> If you're still in d-i, you can hit any "go back" button, and then scroll down to "start a terminal"
<infinity> Or "spawn a shell" or something like that.  I forget the exact wording.
<scientes_> or just switch to another virtual console with ctrl-shift...(if not on serial console)
<krosswindz> ok
<krosswindz> let me check that
<infinity> Anyhow.  I'm heading out.  Good luck.
<scientes_> ctrl-shift-f1, f2
<infinity> scientes_: Yeah, he's on serial.
<krosswindz> infinity: thanks for the help
<infinity> krosswindz: It could just be something as simple as the d-i images being out of sync with the archive or something.  We're all back to work on Monday, if you find actual bugs we should fix. :P
<krosswindz> scientes_: I am on serial console so no virtual terminals
<infinity> krosswindz: But I suspect GrueMaster can help you tomorrow.  He's often around and bored.
<krosswindz> infinity: I will pick on him tomorrow if he is around when I am on
<scientes_> krosswindz, you can see i realized that above
<krosswindz> scientes_: sorry tryin to multi task  between my laptop and the serial console :p
<scientes_> krosswindz, what device is this?
<krosswindz> scientes_: pandaboard
<krosswindz> scientes_: got it like 2 weeks back
<krosswindz> scientes_: had to wait till this week because my serial cable wasnt working
<scientes_> exciting!
<krosswindz> scientes_: yeah
<scientes_> I'm looking at getting a cubox/d2plug---just ordered a mino 720 USB-*only* touchscreen for my sheevaplug
<krosswindz> nice
<scientes_> you should check out the rasperry pi
<scientes_> $25/ $35
<krosswindz> scientes_: yeah I have looked at it
<scientes_> wont run ubuntu however, only debian armel
<krosswindz> scientes_: I wish it had an otg port
<scientes_> what is otg?
<krosswindz> scientes_: I got the panda because I wanted a USB otg port
<krosswindz> USB port that can behave either like usb slave or usb host
<scientes_> hmm, reading the wikipedia page is a bit overwhelming
<scientes_> the cubox/d2plug has a cdc enabled hdmi port
<scientes_> so that the remote of a cdc hdmi TV can control the computer
<scientes_> and visa-versa
<krosswindz> scientes_: cool
<krosswindz> scientes_: you can use it as media player then
<scientes_> IIRC they can even power on each-other
<gildean> didn't newest hdmi-version include stuff like ethernet in there too?
<gildean> the standard that is, not the devices you're talking about
<scientes_> display port is suppose to supplant hdmi......
<krosswindz> gildean: scientes_ display port doesnt have cec
<scientes_> gildean, I really don't know, but i am sure it would be on the wikipedia page
<krosswindz> gildean: yeah hdmi 1.4 also has ethernet
<scientes_> dang
<scientes_> hdmi is everything
<scientes_> including evil DRM
<scientes_> HEC Data+ (Optional, HDMI 1.4+ with Ethernet)
<scientes_> geeze, compressed and decompressed
<krosswindz> weird I am getting host unresolved for ports.ubuntu.com when the rest of the packages are downloaded from it
<krosswindz> completely weird
<scientes_> krosswindz, its downloading those packages in the chroot
<scientes_> of /target
<krosswindz> scientes_: yeah
<scientes_> so its a differn't resolv.conf
<krosswindz> hmm
<krosswindz> probably the netboot installer is broken
<krosswindz> let me try an older version of the netboot installer
<scientes_> just the kernel install?
<scientes_> well, i don't have that hardware, on the sheevaplug, i have to-date managed the kernel seperately
<krosswindz> yeah just the kernel install
<scientes_> even though there is (now, not when i first installed) a linux-image-kirkwood package
<scientes_> oh wait, its cause I wanted to install to the NAND flash, rather than a SD card
<scientes_> how many writes do you get on flash before it peels over?
<krosswindz> not sure
<krosswindz> typically these days 100K write cycles
<krosswindz> not sure
<krosswindz> 100K is for flash media
<krosswindz> may be nand has significantly less
<scientes_> it seems that turning of compression in logrotate really isn't supported
<scientes_> i get syslog, syslog.1, syslog.1.gz, syslog.2, syslog2.gz
<scientes_> its a mess
<scientes_> cause ubifs already has zlib compression so it is pointless
<scientes_> especially cause it cause another write, cause it changes the file rather than just rename it
<scientes_> http://paste.ubuntu.com/829783/
<scientes_> ^^^^gcc error
<scientes_> gcc claims it has a bug
<scientes_> /home/build/opencpn/plugins/grib_pi/src/grib.cpp:2193:1: internal compiler error: Segmentation fault
<krosswindz> is this on native
<krosswindz> or cross build
<krosswindz> calling it quits for tonight
<scientes_> this is on qemu
<scientes_> the next line after ctrl-c was "The bug is not reproducible, so it is likely a hardware or OS problem.
<scientes_> "
<scientes_> so i posted it to #qemu on irc.oftc
<scientes_> neways good night
<scientes_> hmm, didn't put that out a second time---could just be cause the place where i ctrl-c'ed
<morphis> infinity: ping
<lilstevie> krosswindz, given NAND is usually what SDCards are made of it should be the same
<Person987> Two questions: I'm a noob to pandaboard and I have ubuntu working nicely on an 8gig SD card now.  Is there a way I can duplicate this SD card so I have a backup of the entire "system"
<Person987> Second, can I copy it to a USB thumb drive and run off of that?
<mythos> Person987, dd if=<sdcard-device> | gzip > backup.gz
<mythos> restore the card: zcat backup.gz > <sdcard-device>
<mythos> <sdcard-device> is something like /dev/mmc...
<mythos> search for it with fdisk -l
<pr_oc> i have been fighting with ubuntu on my gumstix/overo earth for a few days now, so any help is appreciated.  Currently i'm stuck on getting any USB wifi card to work.  I keep running into walls trying to build the manufacturer drivers, and am almost out of space on my 2gb SD card.  what kernel should i be running?
<dioxin__> pr_oc: I made progress when I used the 12.04 dev build
<pr_oc> how did you build your initial root filesystem?
<pr_oc> i've found a bunch of different procedures
<pr_oc> chances are i choose poorly, because i'm missing just about every troubleshooting utility.  i'm now running out of space because of all the apt-gets i've done :-)
<dioxin__> I'm using a Pandaboard with 8 or 16Gb SD cards
<dioxin__> so I'm hitting a space issue
<dioxin__> I'm NOT*
<pr_oc> yeah just saw those boards
<pr_oc> makes me wish i could swap this gumstix setup for that
<dioxin__> I'm building my initial fs system using the images off the Pandaboard wiki
<dioxin__> if you have a 2nd system, maybe you could download the vmlinuz and initrg.img + the modules directory and just copy them onto the gumtix SD card
<dioxin__> (its kinda what I've done to get round an issue I had
<pr_oc> i might end up doing that
<pr_oc> i'm so close to my goal that i'd hate to start over
<carli2> hi
<carli2> I have a omap3 beagleboard
<carli2> with the 11.10 release, usb mouse and keyboard did not work
<carli2> is that issue known?
<krosswindz> GrueMaster: are you around?
<GrueMaster> maybe...
<krosswindz> GrueMaster: infinity asked me to pick your brain
<krosswindz> GrueMaster: I am having trouble with the netboot image
<krosswindz> GrueMaster: I am trying to install precise on an external usb drive
<GrueMaster> Yea, there is a bug, we think in resolfconf
<GrueMaster> resolvconf.
<krosswindz> GrueMaster: when it goes to install the kernel I get an error at that time only for the kernel unable to resolve
<krosswindz> GrueMaster: any work around
<krosswindz> GrueMaster: does the oneiric netboot work?
<GrueMaster> The only workaround I have is to pull up the install log, and look for the apt-get install  line just before the failure.  It will be a "can't resolv <mirror>" error.
<GrueMaster> Then you can chroot target /bin/bash and atp-get install the packages manually.
<krosswindz> GrueMaster: yes ports.ubuntu.com
<GrueMaster> Oneiric should still work.
<krosswindz> GrueMaster: Oneiric would be armel, would there be any way I can upgrade from Oneiric armel to Precise armhf then
<GrueMaster> Not that I know of.
<krosswindz> GrueMaster: you suggest I use the fb image then and not serial console
<GrueMaster> The preinstalled images should still work, but they are more of a challenge to get installed on usb.  It is doable, just difficult.
<krosswindz> GrueMaster: netboot would be easier using fb image then
<krosswindz> GrueMaster: after I chroot and install the kernel I can continue with the installers next step right?
<GrueMaster> That would be irrelevant.  resolvconf isbroken during install.
<GrueMaster> yes, but you will still need to bounce back into the chroot to manually pull packages.
<krosswindz> ok
<GrueMaster> It is doable.  I did it.  It just  takes a while.
<krosswindz> does the external usb install use any special uboot image
<krosswindz> I was wondering if I could install on the sd card then copy over the root filesystem and modify the boot.script and change it to boot from USB
<GrueMaster> That's what I did prior to netboot support.
<krosswindz> that should work then
<GrueMaster> I "may" have a temporary solution.  Trying it now.  Give me a few minutes.
<krosswindz> ok
<krosswindz> sweet
<krosswindz> I will be around
<GrueMaster> YEA!   Success!
<GrueMaster> Ok,here's the steps:
<krosswindz> aweomse, can I try it :p
<GrueMaster> select "execute shell"
<GrueMaster> chroot target /bin/bash
<krosswindz> ok
<GrueMaster> dpkg --force-all --remove resolvconf # ignore errors
<GrueMaster> apt-get install resolvconf # ignore errors
<GrueMaster> exit back to menu
<GrueMaster> run select software (default selection from where it left off).
<krosswindz> ok
<krosswindz> thats its?
<krosswindz> it*
<krosswindz> I just fired the netboot again
<krosswindz> will report back in a bit
<dioxin> With the Ubuntu Server images (11.10) what is the effect of the various Live CD options from the install options?
<GrueMaster> dioxin: ???
<GrueMaster> We only have preinstalled images for arm.
<dioxin> GrueMaster: I've done the 11.10 server image, and I'm at the "Choose software to install" stage
<dioxin> I get options for different live CD's
<GrueMaster> Oh, that.  I don't know what the live cd selections are.
<dioxin> ok, well here goes nothing ;)
<krosswindz> GrueMaster: does precise also need the 72 MiB fat32 partition that is not mounted but has the boot flag on?
<GrueMaster> That is on SD, right?  That is where u-boot boots from.  Keep it.
<krosswindz> GrueMaster: on the USB drive
<GrueMaster> Interesting.  I've never seen that on Panda.
<GrueMaster> But then I use a preseed.
<krosswindz> dioxin: I remember seeing that as well it is before the actual install starts
<krosswindz> dioxin: I think I chose the first option which was to install a base system I dont remember
<dioxin> previously I've chosen Base-Server-Install and OpenSSH and its worked
<dioxin> I'm now trying lubuntu live cd option as well
<krosswindz> I am not sure what it does
<krosswindz> GrueMaster: the size of fat32 partition on SD card is 32M, I think thats what is the size in netboot image
<krosswindz> GrueMaster: should I resize it once the install is done?
<GrueMaster> Nah, that sould be enough.
<GrueMaster> It only needs to hold MLO, u-boot.bin, and backups of uImage, uInitrd, and boot.scr
<krosswindz> GrueMaster: thanks
<krosswindz> GrueMaster: its installing the base system now, my net connection is slow atm because its sunday and everyone in my apt complex is at home
<GrueMaster> Heh.  Understand.
<GrueMaster> That's why I have my own mirror at home.
<dioxin> how big is the repository? it is feasible to mirror it at home?
<GrueMaster> Not too big if you only pull armhf.  I have all of arm (no sources) and it is ~350G (I think, haven'tchecked my server lately).
<GrueMaster> That is all of arm (armel, armhf) and also contains all pools (main, restricted, multiverse, universe).
<dioxin> including 10.10 through to 12.04?
<GrueMaster> Yes.  Actually, it appears to be 255G on my mirror.
<GrueMaster> (I also have all images since UDS - that's why I thought it was more).
<dioxin> I've got a spare ATOM box with a 1 TB drive attached... hmmm ;)
<dioxin> (and luckily I've a 100 meg internet connection ;)
<dioxin> does Ubuntu Support Beagle Bone as well?
<GrueMaster> I use ubumirror to do the mirroring.  Ubuports (the script that mirrors ports.ubuntu.com) runs every 2 hours.
<GrueMaster> I think so.  I don't have one to try.
<dioxin> I get one Tuesday I think
<GrueMaster> cool.
<GrueMaster> If it boots the same as the beagexm, it will just work.
<krosswindz> moment of truth
<krosswindz> GrueMaster: its redoing the basesystem install
<dioxin> I might have to pick your brains in a couple of days on how to do the repo mirror
<GrueMaster> krosswindz: that is normal.
<krosswindz> dioxin: check apt-mirror
<GrueMaster> dioxin: I'll pastebin my ubumirror.conf when you are ready.
<krosswindz> GrueMaster: awesome its asking me to chose the kernel this time
<dioxin> I need to reinstall the ATOM as well along with recieve the board and other toys :D
<krosswindz> i select linux-omap4
<GrueMaster> krosswindz: apt-mirror doesn't get the udebs and other stuff needed for netboot.
<krosswindz> GrueMaster: aah ok
<krosswindz> GrueMaster: It installed the kernel, thanks for the help :p
<GrueMaster> krosswindz: The kernel questions are a good sign.
<krosswindz> GrueMaster: its configuring apt now
<dioxin> GrueMaster: is it possible to build the entire ubuntu from source?
<GrueMaster> excellent
<krosswindz> GrueMaster: does precise kernel still have the 1G issue where compiler segfaults?
<GrueMaster> yes, but it takes a long time.
<krosswindz> GrueMaster: I want to build stuff natively
<GrueMaster> krosswindz: No, that was fixed.
<dioxin> is compiling i/o or computation intensive?
<GrueMaster> We are in the process of rebuilding the pool.  I think it will take a week or two with a pool of pandas.
<krosswindz> dioxin: both
<GrueMaster> dioxin: Both.  The Panda is the fastest we currently have, but IO is slow.
<dioxin> how many Panda in the pool?
<GrueMaster> We hope to get some 4 core arm servers soon, but they probably won't be building until well into 12.10.
<GrueMaster> Not sure.  16 I think.
<GrueMaster> It takes something like 12 hours to build libreOffice.
<krosswindz> wow on the pool of pandas or just one?
<krosswindz> quad core arms are they omaps or tegra?
<GrueMaster> Just one.   We don't use distcc
<GrueMaster> Tegra 3 is 5 core, but they are limited availability.
<GrueMaster> Not sure what omap5 will be or when it comes out.
<GrueMaster> Calxeda is the exiting one. Check out their announcement.
<krosswindz> I read omap5 would be quad core
<krosswindz> with like 2GHz core
<GrueMaster> that will be cool.
<krosswindz> let me try to find that article
<krosswindz> http://www.fudzilla.com/processors/item/21777-omap-5-is-quad-core-28nm-in-2012
<krosswindz> cortex a15
<krosswindz> GrueMaster: installation complete rebooting now
<GrueMaster> Double cool.  A15 will support kvm.
<GrueMaster> krosswindz: Excellent!
<krosswindz> GrueMaster: I have login prompt over serial console
<krosswindz> GrueMaster: thanks a lot for your help
<GrueMaster> glad I could help.  Hopefully this willbe fixed next week.
<krosswindz> GrueMaster: I can for now get rid of all the archive.ubuntu.com entries from sources.list right
<krosswindz> and security.ubuntu.com as well?
<GrueMaster> Yes, unless you want to install a source package.
<krosswindz> I will install linux source for recompiling it
<GrueMaster> security.ubuntu.com is a bug.  All updates are on ports.ubuntu.com
<krosswindz> ok
<GrueMaster> I have to run.  Need to get ready for superbowl.
<krosswindz> GrueMaster: you around?
<krosswindz> aah now I see you are off to watch superbowl
#ubuntu-arm 2013-01-28
<tripelb> Someone should make a note about this channel and put it in the welcome text in #ubuntu I have a nexus 7 and was alone... Heh
<tripelb> The nexus channel is dark and empty.
<tripelb> That's all for now. I'll be returning after rooting,.
<dholbach> good morning
<vipzrx> dholbach:  moring
<dholbach> hi vipzrx
<darkfader> good morning all
<darkfader> i'm new, didn't notice there's a channel until yesterday
<vipzrx> welcome
<vipzrx> i am in chinaï¼now is afternoon in our country
<darkfader> i'm gonna make a few nagios-server on your datacenter-entrace showcases with a nexus7 and see how it's going
<darkfader> I have one running for 2 months now or so and except browser memleaks it's doing a great job
<darkfader> some questions... does one of you have the GPS working in ubuntu? I have stabbed at it last year but no success
<darkfader> i don't wanna get the position, just the GPS time for NTP
<darkfader> i have a non-3g model, if that matters
<randomblame> can someone tell me what the best way to compile ubuntu for armv7 on x86 is?
<randomblame> rootstock is depricated and the qemu kernel panics during the process
<randomblame> and correct me if I'm wrong but I don't think live-build can't cross compile
<Riddell> about how long should it take to "fastboot flash boot" an ubuntu image to a nexus 7?  mine has taken about 20 minutes
<Riddell> ogra_: is today's image too big? http://paste.kde.org/658604/
<ogra_> Riddell, wrong image to wrong partition
<Riddell> mm?
<ogra_> img goes to userdata
<ogra_> bootimg goes to boot
<ogra_> the "boot" partition is only 8M big
<Riddell> ogra_: where do I get the bootimg?
<Riddell> oh I see it
<Riddell> ok I'll see if I can make that clearer in the install instructions, thanks ogra_
<randomblame> anyone have any advice for getting rootstock to work?
<Rjs> darkfader: I'd also like to get a working GPS (and compass) for the nexus7... I tried but didn't get very far, though I found some parts of the solution:
<Rjs> a) linux/arch/arm/mach-tegra/board-grouper-pinmux.c has a comment /* UART B : GPS */ and I think (from trying to understand the code in that directory) that UART B should be connected to /dev/ttyHS1
<Rjs> b) apparently the GPS chip uses a proprietary protocol, but some Replicant folks have been able to reverse-engineer some of it in another device: https://gitorious.org/replicant/crespo-gps-utils
<Rjs> c) the compass chip seems to be supported by the kernel: it has a directory under /sys already; but I guess a light bridge from this to gpsd would still be needed (at least I think compass chips should also be connected via gpsd to make them work in the normal navigation software)
<Rjs> ... I tried to use screen to connect to /dev/ttyHS1 using various baud rates, but couldn't get it to write anything back... I'm not sure if I did something wrong (e.g., there is a cryptic termios.c_cflag in b)) or whether the GPS chip should be powered on by something else before trying to connect (the code in b) does some power-up specific to the device it was written for, not nexus7)
<Rjs> or maybe the comment in a) is wrong and the GPS isn't connected via UART at all: some random googling found that a Nokia phone from around 2010 had the same GPS chip apparently connected via I2C, so I presume it supports both
<Rjs> (are any specifications available for the chip itself? I didn't find any, and I presume not, if the Replicant folks had to reverse-engineer it, I think by running a closed-source Android app and capturing traffic to the GPS chip... :( )
<darkfader> Rjs: i also couldn't connect to i think tty<something>2 which should have been the GPS line
<darkfader> but seems you've been deeper into it. i can just verify it didn't work as it's apparently supposed to
#ubuntu-arm 2013-01-29
<zhongwei> Hi, folks, Does any know how many kinds of arm assembly language standard exist? I'm very confused by the difference between different arm assembly standard.
<zhongwei> Say the UAL(Unified Assembly Language) and GNU as are different. Is any more standard about arm assembly lanuage?
<IamTrying> Where is the boot.img file? http://lilstevie.geek.nz/downloads
<IamTrying> It always goes to black screen
<IamTrying> Downloaded: http://lilstevie.geek.nz/downloads/OLiFE-Prime-Edition.tar.gz_1.2a_TF101_767779ccfa200e5e00b2f1e33a3d73a9
<IamTrying> Downloaded: http://lilstevie.geek.nz/downloads/OLiFE.tar.gz_1.2a_TF101_c30263fd8271a23bb211fd9fdd69fa45
<dholbach> good morning
<fabo> ikepanhc: ping
<fabo> ikepanhc: I replied on the bug
<ikepanhc> fabo: thanks for the quick reply. /me is checking
<ikepanhc> fabo: execuse me, which bug you mentioned?
<fabo> ikepanhc: bug 1078356
<ubot2> Launchpad bug 1078356 in Arndale "usb 3.0 support" [Medium,Fix released] https://launchpad.net/bugs/1078356
<ikepanhc> fabo: thanks I see it
<ikepanhc> fabo: one more question, can you point me where I can clone the git tree for the binary?
<fabo> ikepanhc: http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git linux-linaro branch
<ikepanhc> thanks a lot
<fabo> ikepanhc: all the details are available in the changelog (including config fragments)
<ikepanhc> fabo: the kernel oops at s5p_usb_phy_init+0x56/0x1a8, is that possible that we might have different hardware?
 * ikepanhc is posting the full log on bug
<fabo> ikepanhc: I'm not that different hardware are available. I guess we have the same.
<fabo> ikepanhc: I experienced kernel oops too, reported in a separate bug (seems related to toolchain)
<fabo> ikepanhc: do you have something connected on usb when you boot?
<ikepanhc> fabo: yes, a usb2ethernet
<fabo> could remove it and see if you still get the oops?
<fabo> +you
<ikepanhc> hmm, a little bit hard, its far away from me and I need someone do that for me
<ikepanhc> I will try to ask. thanks for the suggestion
<fabo> ikepanhc: I observed strange behavior depending on the peripherals connected
<fabo> ikepanhc: I don't know the root cause but it could be hardware
<ikepanhc> fabo: including oops of ohci_irq?
<fabo> ikepanhc: yes, I have random oops if I plug something on ethernet or usb, both are connected on the same bus
<ikepanhc> fabo: I see that too, the value of regs in ohci_irq() is NULL and the funciton using it
<ikepanhc> fabo: probably the first interrupt comes before everything initial, this is my guess
<ikepanhc> fabo: this is the dirty workaround I have http://kernel.ubuntu.com/git?p=hwe/ubuntu-quantal-arndale.git;a=blobdiff;f=drivers/usb/host/ohci-hcd.c;h=88678526688de06d6ddb142f22fe40ec1596dd9e;hp=4a1d64d92338e7653035b054decf6e714909a41f;hb=d206e0141339b25724445ba79cfb7ec7b57bc5c1;hpb=08ff89b94bc54d91df7fcb8800c8aeb6a1fff072
<fabo> ikepanhc: it worths a try. it could be the same root cause as my oops with ethernet/sata
<fabo> I'll apply and test
<ikepanhc> glad I can help
<fabo> ikepanhc: according to tushar, plugging an usb device might be just avoiding that ATM (probing, enumeration might be taking some time)
 * ikepanhc nods. but I can only remove access to the hardware, ethernet is critical to me :(
<ikepanhc> s/remove/remote
<Riddell> ogra_: I'm playing with ubuntu on this nexus 7, any ideas how to get another shell up?  I've installed plasma-active but I can't seem to persuade lightdm to launch it as the autologin session
<ogra_> i think it should respect ~/.dmrc, not sure
<Riddell> nope, it just changes that back to ubuntu when I change it
<ogra_> Riddell, hmm, i guess thats a question for the desktop team then, i dont see any way to change the session in lightdm here
<ogra_> looks like they dropped the UI element for that
<ogra_> there should be a config file for lightdm though, where you should be able to force the default
<Riddell> I did find that somehow but then there's no way to type in a password
<ogra_>  /etc/lightdm/lightdm.conf has user-session=
<ogra_> you need to enable the keyboard in the panel
<ogra_> (we default to autologin, so the greeter didnt see much love yet)
<ogra_> there should be an a11y icon
<Riddell> ogra_: whee I got it running
<Riddell> alas the touchscreen seems not to be working
<Riddell> I wonder what enabled that to function
<lool> ogra_: Hmm I have installed today's raring image for nexus 7, I get graphical corruption in the background of OEM config and then I'm stuck on "Who are you?" after configuring the wifi; are these known issues and is there a workaround?
<ogra_> lool, a reboot fixes the focus error
<ogra_> lool, wallpaper issue is known and filed as well, just ignore it :)
<lool> Ok; hard-resetting then
<lool> ogra_: is there a bug for the focus issue?
<ogra_> yep, but i'm not at a machine where i can look it up quickly, i'll give you the number later
<ogra_> lool, xnox is working on that afaik
 * xnox is going to add g-s-d hacks to paint background such that everyone stops bugging me about it.
<xnox> but that will not fix background for Xubuntu/Lubuntu/Studio/Mythbuntu
<xnox> =((((
<lool> Shouldn't it be at least black?
<lool> that seems like a driver bug somewhere
<ogra_> yes, thats another issue that has several incarnations
<ogra_> the driver doesnt properly clean up if you shut down X ... booting without splash you actuallly see the content of the desktop on last shutdown for a second when lightdm starts
<ogra_> iirc that was communicated to nvidia
<Tassadar> probably because Android does not use framebuffer directly, I kinda wonder how do they draw to screen Oo
<ogra_> we dont use any android bits :)
<ogra_> there is an actual xorg driver in use
<ogra_> which has the bug
<Tassadar> not only that, everything which writes directly to framebuffer has that bug
<Tassadar> fb's content is not erased after reboot
<Rjs> hmm, would the fix be simply to erase the contents of the framebuffer before enabling the display (in-kernel, I guess)? (can you do anything else if, say, the kernel crashes or gets stuck and is later rebooted?)
<Rjs> (I've seen very similar things on regular desktop computers with some X drivers as well, so I think it's been quite common at least in the past - e.g., kill an X server and go back to a text console, then restart X, and it was quite common in the past that the previous screen contents were briefly visible before X cleared the display)
<Tassadar> I just set the whole framebuffer to "black" before I do first update.
<Tassadar> on ubuntu's kernel, it was more visible because of the console text/graphic mode switch, maybe it is needed to "erase" fb even before that happens (?)
<lool> ogra_: Seems the daily-preinstalled images for nexus 7 / raring have stopped building since the 24th; can't find more recent logs; any idea why?
<ogra_> lool, DC breakage
<lool> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/raring/ stops at the 24th
<lool> ogra_: :-/
<ogra_> lool, todays build should be running right now, they managed to fix it today
<ogra_> the livefs builder broke and we have no fallback ... and there was nobody to go physically to the board to bring it up again
<ogra_> (it isnt in the mandabox)
<lool> ok
<ogra_> there is hope we'll get a fallback builder soon
<ogra_> its quite hard with one livefs builder for all arm images and flavours
<hrw> infinity: aarch64 porting meeting?
<ogra_> janimo, hey ... should i drop the matrix stuff from acceld now ?
<infinity> hrw: The one that's in Finnish? :)
<hrw> yes
<janimo> ogra_, no, far from it
<janimo> the g-s-d change is just  a small part of the picture
<ogra_> ah, ok, your changelog entry sounded hopeful
<janimo> I still need the kernel/udev rules in place
<infinity> hrw: Was it a G+ hangout?  Link me.
<janimo> well,some of g-s-d rotations are fixed
<janimo> but orientation detection relies on kernel support which we do not have yet
<infinity> hrw: (Sorry, a bit scatterbrained today, tag-team debugging initramfs-tools with a user)
<janimo> but it's next on my todo
<hrw> infinity: https://plus.google.com/hangouts/_/da41dcc2462a4ed93ec4e603dcfff109b6004142
<ogra_> ah
<janimo> ogra_, this was a change to the gsd xrandr plugin, the other part is the orientation plugin
<ogra_> janimo, also add a joystick device so we can use games by accelerometer ;)
<plars> ogra_: the serial stuff is working great for login on n7, but is there a way to make the kernel messages and early boot stuff when it unpacks the rootfs go there also? Specifying it as one of the console= doesn't seems to be sufficient.
<ogra_> while you fix the kernel
<janimo> ogra_, what could be done but I don't think it's worth the trouble is using dbus-send to ask gsd to rotate instead of manually calling xrandr and xinput
<janimo> but no real gain
<janimo> ogra_, yes, it actually needs to be exposed as a joystick in order for gsd to talk to it :)
<ogra_> plars, nope, the serial bit comes from a USB driver, it can only start once that is loaded, cant log anything before
<janimo> but only axis and no shoot button
<plars> ogra_: ok
<ogra_> janimo, pfft, users can buy a bluetooth button for that :P
<janimo> or play non-violent games where you just cruise in a spaceship but don't shoot anything
<ogra_> haha
<janimo> plars, thanks for reminding me serial login exists. I have annoying lags and lockups via wifi/ssh
<ogra_> well, sadly serial login also eats our battery
<plars> ogra_: oh, really?
<ogra_> there seems to be a bug in either the g_serial driver or in getty, yeah
<ogra_> which causes a ton of wakeups per second currently ... check with htop, you will see ttyGS0 in the top CPU consumers
<janimo> well, while you're on serial you're also plugged in no?
<ogra_> heh, yeah, you should
<plars> janimo: well, yes but I can easily drain more battery than I'm charging
<plars> janimo: and considering we'd like to do some power testing in an automated way, this could complicate things a bit
<ogra_> it definitely causes a lot of CPU load atm
<ogra_> i know cking will look at it though
<ogra_> but he seems to be off today
<plars> ogra_, janimo: we may end up having to test install differently and just keep a system upgrading, still not having much luck with the preseeding. Does the kernel upgrade properly now? I seem to recall that being an issue at some point
<ogra_> kernel is fine
<plars> awesome
<ogra_> upgrades from quantal to raring have issues
<ogra_> nobody plans to fix that though
<plars> ogra_: yeah, don't need that
<ogra_> wow, the settings i just uploaded actually bring the system load to a sane value on the nx7
<ogra_> !!
<ogra_> finally a default load below 1
<janimo> ogra_, what changed?
<ogra_> janimo, i just added an upstart job that applies the same settings as in init.grouper.rc for the cpufreq governor
<ogra_> we switched to the interactive governor a while ago, which already improved over ondemand but never used the options android uses for it
<janimo> ogra_, nice
<ogra_> yeah, i'm quite impressed what such a small change does
<ogra_> having an idle load below 0.10 if you had it above 1 all the time is quite great
<mosasaur> I'm currently running this on my galaxy note: http://forum.xda-developers.com/showthread.php?t=1845631
<mosasaur> however it's ubuntu 10.10 and it seems the deb files for an update have all length 0
<ogra_> better talk to the creator of that chroot then
<Tassadar> well, it is two and a half years old, repositories are probably down already
<mosasaur> is there a more recent arm image for v7 that I can use as a drop in replacement?
<ogra_> oh, right
<Tassadar> I suppose you can use nexus 7's images when it is just chroot
<mosasaur> thanks Tassadar, is there a link for that?
<ogra_> well, depends how many hacks that chroot has :)
<Tassadar> yeah, gimme a while, I'm reading the thread
<ogra_> theoretically do-release-update should just DTRT and set the sources.list to old-releases.ubuntu.com
<ogra_> and upgrade you
<mosasaur> I guess a release upgrade should work, however the image is rather small
<Tassadar> yeah, 1.6gb?
<mosasaur> compressed, if installed it leaves about 1 gig free
<Tassadar> what is total size of the .img file?
<mosasaur> about 3G
<LisaNori> Wow, I just did "apt-get update; apt-get upgrade" and now my ubuntu installation on my nexus7 reads the X mouse location along the Y axis and vis versa!  It's really weird!  You can start apps (listed along the left side) by touching along the top of the screen.  You can get to top screen menus by touching along the right side!  Some fix since yesterday (when I did the last upgrade) has really screwed up mouse positions!
<ogra_> LisaNori, use the serial shell and upgrade again, there was a small window where kernel and userspace were out of sync today
<Tassadar> mosasaur: I guess that is not enough to do the upgrade
<ogra_> just another upgrade should fix it
<mosasaur> Tassadar: yeah that's why I'd like some torrent with a more recent image
<LisaNori> I did the upgrade just a few minutes ago.  I don't have a way to attach a USB keyboard.  I'll see if i can ssh in.
<ogra_> weird, if it was a few mins ago all should be fine
<mosasaur> LisaNori: I suppose you're not talking about just a chroot?
<LisaNori> nope
<ogra_> the nexus7 is nbative
<ogra_> *native
<ogra_> LisaNori, was that a raring install or did you upgrade from a quantal demo image ?
<Tassadar> I'd say there isn't one you can _just_ drop in, but you could make one from the nexus 7's I suppose, the chroot seems pretty much okay
<ogra_> LisaNori, (the original installation i mean)
<LisaNori> It was a raring install (using the dual boot capability).  Worked fine yesterday.  Worked fine when I turned it on today.  Screwed after I did upgrade and rebooted.
<ogra_> oh, dual boot, hmm
<Tassadar> let me try ti
<Tassadar> it
<mosasaur> is the nexus 7 already at 12.04 or something like that?
<ogra_> if you can ssh in, check the kernel version
<ogra_> mosasaur, 13.04
<mosasaur> OK :-)
 * Tassadar is rebooting to ubuntu on his n7 to try update
<ogra_> smells like the kernel wasnt updated
<ogra_> we are at 3.1.10-9-nexus7
<LisaNori> apparently ssh isn't enabled and the onscreen keyboard is useless now.  I'll try using "adb shell".
<ogra_> uname -r should tell
<Tassadar> won't work, if you are on linux, just plug it in and type "screen /dev/ttyACM0 115200"
<ogra_> we run a serial login on the USB port in the default ubuntu image (no idea if that applies to the dual boot image)
<Tassadar> (and then your username and enter, even if it does not show anything in terminal)
<ogra_> right, follow Tassadar
<LisaNori> Cool!  That worked fine!  I'm in.
<ogra_> well, uname -r
<LisaNori> 3.1.10-8-nexus7
<ogra_> aha
<ogra_> there is your prob
<LisaNori> :)  ?
<ogra_> your kernel wasnt upgraded, no idea why, i only work with the official image
<ogra_> but i guess Tassadar can help you :)
<Tassadar> LisaNori: tell me what "ls -l /boot | grep vmlinuz" shows you
<LisaNori> lrwxrwxrwx 1 root root      23 Jan 24 17:40 vmlinuz -> vmlinuz-3.1.10-8-nexus7
<LisaNori> -rw-r--r-- 1 root root 4523920 Jan 24 13:35 vmlinuz-3.1.10-8-nexus7
<Tassadar> Oo
<Tassadar> okay, just wait until I update my installation
<ogra_> sudo apt-get install linux-nexus7
<ogra_> try that
<ogra_> the kernel wont be upgraded is the metapackage isnt installed
<ogra_> seems thats missing from your setup
<ogra_> s/is/if/
<LisaNori> running now...
<ogra_> it should pull in 3.1.10-9-nexus7 alongside
<Tassadar> does it install also flash-kernel
<Tassadar> ?
<ogra_> i dont think so
<Tassadar> I wonder how could "linux-nexus7" be missing
<Tassadar> *can/whatever-the-correct-english-is
<ogra_> no idea
<LisaNori> in order to install using multirom, I followed the instructions here:  http://forum.xda-developers.com/showthread.php?t=2011403
<LisaNori> Ok, so, now I do "apt-get update ; apt-get upgrade" and reboot?
<ogra_> just reboot should be fine if you see 3.1.10-9-nexus7 in /boot/
<Tassadar> LisaNori: when did you install ubuntu, like from which that was the image you installed via recovery?
<Tassadar> at least roughly
<LisaNori> Following the instructions on the page I mentioned above, I followed the link "here" in step 2 under "Adding ROMs".  That's the image I loaded.
<LisaNori> http://api.viglink.com/api/click?format=go&drKey=1359&loc=http%3A%2F%2Fforum.xda-developers.com%2Fshowthread.php%3Ft%3D2011403&v=1&libid=1359481624518&out=http%3A%2F%2Fcdimage.ubuntu.com%2Fdaily-preinstalled%2Fcurrent%2F&title=%5BWiFi%263G%5D%20MultiROM%20v6%20-%20xda-developers&txt=here&jsonp=vglnk_jsonp_13594818010172
<Tassadar> those images are built daily, every day there is different image,  I wanna know when did you download it
<LisaNori> Of course, I followed those instructions about a week or two ago, so it would have been a different image there at the time.
<ogra_> cat /var/log/installer/media-info
<LisaNori> Let me see if I still have the image I loaded around somewhere.
<ogra_> that should tell from when the installation is
<ogra_> if it uses our tarballs as a source at least
<LisaNori> root@rajnexus7:/boot# cat /var/log/installer/media-info
<LisaNori> cat: /var/log/installer/media-info: No such file or directory
<Tassadar> It should not matter, I just want to know to be sure it is not like some acient image or something like that
<Tassadar> and if it was week or two then it is enough, you don't have to look for the file
<ogra_> hmm, so its not our tarball or the install pre-dates the addition of build stamps
<LisaNori> Ok, the image I downloaded is dated Jan 23, 17:48
<Tassadar> yeah, I don't use the installer
<ogra_> not at all ?
<Tassadar> no, it just extracts the image
<ogra_> i mean the graphical part for user setup etc
<ogra_> it does some kind of important configuration bits
<Tassadar> I thought that the installer which extracts tar.gz archive creates that file...
<ogra_> oh, right, it copies it from the initial initrd
<ogra_> we ship it originally in the initrd
 * ogra_ forgot about that step, sorry
<ogra_> so it cant be in the tarball indeed
<LisaNori> I rebooted and it works fine now.  Thanks a lot!
<ogra_> unless your re-packaging scripts copy it :)
<Tassadar> looks like mine also did not update to newest kernel Oo
<ogra_> well, i'm pretty sure linux-nexus7 is in the tarball :)
<Tassadar> aah, yeah, that's why
<Tassadar> flash-kernel is tied to linux-nexus7
<Tassadar> and I do "apt-get -y purge ac100-tarball-installer flash-kernel"
<Tassadar> because I really don't want to have flash-kernel when dual bootin
<Tassadar> g
<Tassadar> chmm
<ogra_> you could try an evil hack and export FLASH_KERNEL_SKIP=1 in 7etc7environment or so
<ogra_> then f-k becomes a no-op
<ogra_> or at least it should, if you find a place where it doesnt thats a bug
<ogra_> */etc/environment
<Tassadar> LisaNori: you probably won't be able to boot into android now
<Tassadar> try to do "apt-get purge flash-kernel" and before you confirm it, tell me what packages will it remove
<Tassadar> or, better yet, "dpkg --remove flash-kernel" should remove only that package
<Tassadar> ogra_: is that right?
<LisaNori> Here's the output from "apt-get purge flash-kernel":
<LisaNori> Reading package lists... Done
<LisaNori> Building dependency tree
<LisaNori> Reading state information... Done
<LisaNori> The following packages were automatically installed and are no longer required:
<LisaNori>   abootimg apt-clone archdetect-deb dmraid dpkg-repack gir1.2-json-1.0
<LisaNori>   gir1.2-timezonemap-1.0 gir1.2-xkl-1.0 kpartx kpartx-boot libdebconfclient0
<LisaNori>   libdebian-installer4 libdevmapper-event1.02.1 libdmraid1.0.0.rc16 lvm2
<LisaNori>   os-prober python3-pyicu rdate thunderbird-locale-en thunderbird-locale-en-gb
<LisaNori>   thunderbird-locale-en-us uboot-envtools uboot-mkimage
<LisaNori> Use 'apt-get autoremove' to remove them.
<LisaNori> The following packages will be REMOVED:
<LisaNori>   flash-kernel*
<LisaNori> 0 upgraded, 0 newly installed, 1 to remove and 11 not upgraded.
<LisaNori> After this operation, 135 kB disk space will be freed.
<LisaNori> Do you want to continue [Y/n]? n
<Tassadar> yeah, you can proceed, just press y, it will remove only that package
<Tassadar> and then "echo "flash-kernel hold" | sudo dpkg --set-selections", to be sure it will never install again
<LisaNori> what is this accomplishing, exactly?
<Tassadar> flash-kernel flashes ubuntu kernel to main boot partition, replacing android
<Tassadar> you don't want that when dual-booting
<LisaNori> Yep, that makes sense.
<Tassadar> you will probably have to restore boot.img from backup or something, that apt-get install linux-nexus7 probably already flashed ubuntu's kernel :/
<LisaNori> Ok.  Done.
<LisaNori> I just finished shutting down linux and booting android just fine, then rebooted to linux.
<Tassadar> well...then it's all good, but if there was any update to that kernel, it would flash it
<Tassadar> ...and I have to fix the recovery not to remove linux-nexus7 package, and I don't have any idea why does it do that in the first place
<LisaNori> Just rebooted into android again just fine, so I guess everything's ok.  I tend to leave it running ubuntu most of the time though.  :)
<Tassadar> hmm
<Tassadar> you did not do "dist-upgrade", did you?
<Tassadar> like you were always doing "apt-get update; apt-get upgrade", right?
<LisaNori> no, I always go "apt-get update ; apt-get upgrade".
<Tassadar> I think that linux-nexus7 was there, but normal upgrade did not update it because it would require installing new packages
<Tassadar> at least dpkg.log says so
<Tassadar> anyway, I should entirely disable that package when installing ubuntu, we _really_ don't want it
<Tassadar> I mean flash-kernel
<ogra_> Tassadar, ah, yeah, that could be, you indeed always want to dist-upgrade
<ogra_> especially in development releases where dependencies can change around
<Tassadar> hm, the older kernel was not removed
<ogra_> nope
<ogra_> no ubuntu does that
<infinity> apt-get --purge autoremove
<infinity> But we keep two by default.
<Tassadar> at least initrd.img symlink is okay now
<ogra_> ogra@anubis:~$ ls -l /boot/vmlinuz-3.2.0-*|wc -l
<ogra_> 11
<ogra_> thats my x86 desktop
<Tassadar> dammit, just 10 on my debian)
<ogra_> but yeah, the autoremove would clean them up
<Tassadar> I'm just thinking of a way to choose correct initrd now)
<ogra_> except that i cant use it because it would remove packages i still want around
<ogra_> Tassadar, ?
<ogra_> it is always /boot/initrd.img
<ogra_> which is always a symlink to the latest
<Tassadar> yeah, problem is it was not, before this update initrd.img was some rubbish 23 bytes long file
<ogra_> why is that ?
<Tassadar> and I haven't realized that there can be more than one kernel, so I searched for "initrd-*"
<Tassadar> I dunno, you're the guy)
<Tassadar> it is like that in the image
<ogra_> well, indeed it is, the installer cares for creating a proper initrd that matches the HW diuring install
<Tassadar> the graphical part?
<ogra_> the part after it
<Tassadar> ooh, nice)
<Tassadar> then it's no problem and I can just use the symlink
<ogra_> the part that removes the installer (which you definitely dont want on an installed system)
<ogra_> in the end it runs update-initramfs
<ogra_> though note that there is an existing initrd already from the unpacking stage
<Tassadar> yeah...in the image there should always be just one initrd, right?
<ogra_> i'm not sure how all these steps behave if there isnt a file at all or a broken symlink or whatever is 23byte big there
<ogra_> since thats not a usecase that could happen in a normal install
<ogra_> anyway, i'll call it a day now
 * ogra_ is off 
<ogra_> bug #1109197
<ubot2> Launchpad bug 1109197 in ac100-tarball-installer (Ubuntu) "fails to preserve mtimes" [Undecided,New] https://launchpad.net/bugs/1109197
<sim590> anyone knows how to disable touchpad on the tf101? I've tried "xinput --set-prop "Virtual core XTEST pointer" "Device Enabled" 0" but it doesn't work.. It even made X crash.. :(
<sim590> I got it! you can turn off gondor's alarm fire lights!
<nils__> today I installed ubuntu on my nexus7. later i managed to set up everything to compile the kernel but I miss some information how to install the kernel image.
<xnox> it's funny. somehow one should generate boot.img and then you can flash it with fastboot
<xnox> checkout scripts in the ubuntu-nexus7 project branches.
<XorA> sudo apt-get install abootimg (or something like that)
<xnox> unless there is userspace way to do it.
<xnox> XorA: ah, didn't know that abootimg works on nexus7.
<XorA> xnox: biit.img is AFAIk a standard format
<XorA> boot.img
 * XorA does not have nexus 7 to break
<xnox> XorA: ah, ok. Cause like on panda & ac100 there is flashkernel as well which can update kernel in the correct partitions while running ubuntu on device. Such that one doesn't need to use external machine / boot into flashing mode.
<XorA> although I do remember the Android SDK version having some extra options which were essential for booting some boards
<nils__> i have seen abootimg. it somhow packs together the kernel with some other files.
<infinity> flash-kernel works perfectly fine on the nexus7 too.
<nils__> can i simply take the other files from the existing img?
<infinity> (It does, indeed, leverage abootimg along the way)
<infinity> If you're building your kernels via the ubuntu kernel source and, thus, making shiny .deb packages, just installing the package will take care of the rest.
<ogra_> if you use the ubuntu kernel source package, just install the package the buiuld produces with dpkg -i
<ogra_> *snap*
<ogra_> :)
<infinity> If you're doing the whole mess by hand, you'll want to generate an initramf, then run flash-kernel against your version.
<infinity> s/initramf/initramfs/
<ogra_> not even i do that by hand
 * ogra_ uses dpkg -i and then dd's /dev/mmcblk0p2 to an img file
<ogra_> all steps inbetween are automatic that way
<nils__> i wanted to try out if i can make usbnet work. would be fine if i could use usb to transfer files to the nexus7
<ogra_> you surely can, but will have to disable the g_serial setup then
<ogra_> (including the upstart job that runs getty on the werial line)
<ogra_> *serial
<ogra_> by default the usb port is set up as usb serial console
<nils__> if i can have usbnet i should be able to use ssh and dont need the serial any more
<ogra_> well, true indeed
<ogra_> dont you have a wlan ?
<nils__> yes till now i connected via wlan. it worked but i had to use an additional old fritzbox due to lack of any other wlan devices
<ogra_> ah, yeah, thats bad
<nils__> i thought usb is a neater solution. i was wondering why i hadnt found anything regarding usbnet on nexus7 yet
<ogra_> well, while usb is a neater solution, the kernel recieves regular fixes so you likelz have to recompile a lot if you want to keep track
<scientes> nils__, there is an android package for reverse teathering over usb
<nils__> any idea where the right place for further details about hacking nexus7 is - maybe except of this chat.
<nils__> scientes but i am running ubuntu
<scientes> yeah i relize that now
<ogra_> well, here and in #ubuntu-devel and #ubuntu-desktop i'd say
<nils__> thanks for your thoughts. much appreciated.
<ogra_> nils__, i was pondering to actually try the g_composite driver instead of g_serial but havent gotten around to test it yet
<ogra_> composite should actually be able to provide both
<Tassadar> s
<nils__> thanks ogra, I will try to install my kernel tomorrow. actually  just at the beginning. great device. my first mobile gadget with linux.
<ogra_> :)
<XorA> nils__: its a bit fancier than my first mobile linux device :_D
<ogra_> haha, yeah
<ogra_> when i had my first B/W ipaq the nexus7 would have been a supercomputer
<ogra_> or at least a very powerful server
<nils__> ogra, I see you also blog about the Nexus7 status.
<ogra_> well, only the meeting announcements but yeah
<ogra_> others definitely have blogged more and more intresting stuff :)
<nils__> so there's another source where I can gather some infos.
<nils__> nice. thanks a lot. cheers.
<ogra_> most of the blogs that are related to ubuntu on the nexus7 are aggregated on planet.ubuntu.com
 * XorA should stick OZ on nexus for old times sake!
<ogra_> it should fly
<XorA> be interesting compared to plasma desktop
<ogra_> heh
<ogra_> or unity
<XorA> GPE -> Unity and Opie -> Modern QT :-D
<ogra_> heh
<XorA> thats the approx equivs
<ogra_> i actually like unity ... just has to go on a little diet
 * XorA is not a fan
<ogra_> (which it currently is in the middle of)
#ubuntu-arm 2013-01-30
<wookey> infinity: trying to MA crossbuild eglibc2.17 falls over quickly with:
<wookey> configure: error: --enable-multi-arch support requires assembler and linker support
<wookey> which is dull
<doko__> you should forward-port the patches from the -cross-toolchain packages, or wait until infinity does do so
<wookey> ah. OK.
<mrspinx> Hi
<mrspinx> Is ubuntu going to run on the nexus 4 phone, I have been googling I have not really seen any news
<lud> I have an M960 android tablet , its posibble to boot an image?
<nils__> I have installed my Nexus7 fresh from here http://cdimage.ubuntu.com/daily-preinstalled/current/ then connected to my wifi access point but cannot ssh to a second machine has anybody had this behaviour before?
<dholbach> good morning
<nils__> good morning
<nils__> ssh from a different machine connected via wifi works.
<nils__> same problem the other way round. Before the new fresh installation I had installed ssh server via apt-get install ssh and I also couldn't connect from the other machine to the Nexus7
<dholbach> ogra_, I have /etc/initramfs/post-update.d//flash-kernel failing - what do I do?
<Rjs> nils__: (about what you spoke about 10 hours ago) I've been using the usb gadget ethernet on nexus7 for a while, and it was very easy to setup and has worked well (just like on my openmoko gta02)
<Rjs> nils__: I simply compiled the kernel with USB_CDC_COMPOSITE instead of USB_G_SERIAL (composite is ethernet + serial so I didn't have to touch any serial port settings at all), added a few lines to /etc/network/interfaces to configure a static IP, and installed openssh-server
<infinity> ogra_: ^
<infinity> ogra_: Sounds like switching from USB_G_SERIAL to USB_CDC_COMPOSITE should Just Work.  We probably should.
<raster> Rjs: USB_CDC_COMPOSITE???? THATS the config i was looking for!
<raster> yargh!
<raster> thanks muchly!
<kulve> why not g_multi while at it..
<infinity> And Rjs is suddenly the most popular man in the channel for the next 5 minutes. :P
<Rjs> I had no use for a usb-storage gadget so I didn't use g_multi to save myself the trouble of finding out how it should be configured :)
<raster> who needs it
<raster> when u have usbnet
<raster> and can just use nfs
<raster> :)
<raster> or sshfs
<raster> :)
 * raster makes a happy dance
<suihkulokki> usb storage standard need to die
<raster> well for anything less dumb th an a piece of flash media
<raster> (ie sd card at most)
<raster> mtp isnt amazingly better
<raster> tho its an improvement
<ogra_> infinity, when you moved abopotimg into livecd-rootfs, did you remove the code that marks it as manually installed from ac100-tarball-installer ? or do we do it twice now ?
<Rjs> one thing I'm not sure about is how the usb network would look like in network manager if I hadn't configured a static IP in /etc/network/interfaces (I think it's just a normal "wired" interface, but I'm not sure if it has plugged-in detection or not, so NM might think that it's always there and try DHCP or something even if it isn't plugged in)
<infinity> ogra_: There was code marking it manually installed?  Why didn't you close the bug that said it wasn't, then? :P
<suihkulokki> while usb-storage was convinient, it also a) effectively mandates FAT b) makes it impossible to use the media on the device itself while it is being exported over usb storage
<Rjs> but I guess that would be easy to try... for me, setting a static IP was much easier than playing around with DHCP (then I'd also need a DHCP server on the machine I connect the nexus7 to)
<infinity> ogra_: Ahh, I see it.  No, I didn't remove that.  Will do now.
<suihkulokki> b meaning you can't export your root partition, and thus people have to split partitions to support usb storage, leading to inefficient use
<infinity> ogra_: (Also, that call would have been a lot less painful if you'd used apt-mark instead of apt-get, for the next time you have to perpetrate such a hack)
<raster> Rjs:  what device does it come up as?
<suihkulokki> a meaning you suffer from a redmond-based patent troll
<raster> eth0?
<ogra_> infinity, thx, it wont help with bug #1041290 though (unless we rebuild the images for precise/quantal)
<ubot2> Launchpad bug 1041290 in livecd-rootfs (Ubuntu) "apt-get autoremove wants to remove abootimg" [Undecided,Fix released] https://launchpad.net/bugs/1041290
<ogra_> infinity, will do
<ogra_> anyway, daily vet visit now ...
<Rjs> raster: I think it was eth0 on the nexus7 and usb0 on the host computer (though that might depend on the kernel version)
 * ogra_ is back in ~1h
<infinity> ogra_: No, won't fix the past, no, but such is life.
<raster> Rjs: cool
<raster> pc-side i'm good
<raster> just wanted to know so i can pre-configture iot while the kernel builds
<raster> and when i boot just magically have it work (tm) :)
<raster> as i already have all the client-side usbnet scripts around
<Rjs> another tip for static IP configuration: I simply didn't specify any default route through the usb net, because it's easier that way and enough for ssh - if I did setup the default route, then I'd need something to switch defaultroute between wifi and usbnet (probably just have NetworkManager manage the usbnet interface as well)
<nils__> Rjs: Great to hear. Thx.
<raster> Rjs:  i just want usbnet for development
<raster> so i can ssh in
<raster> when at home i do it via wifi
<raster> but if u travel... thats not so useful
<raster> eg.. u're on a plane
<raster> :)
<raster> or in an airport
<raster> or hotel
<raster> or cafe...
<raster> or fosdem...
<raster> :)
<infinity> Also nice to turn off the wifi and still have network access without sucking your battery dry.
<infinity> (bonus points for network access and charging at the same time, oooo)
<nils__> btw. this is a great communication channel. I feel honored to be able to talk to people who are working already quite some time hard on making things work better.
<Rjs> a static IP on a private network without a default route is something you can easily keep always on and it doesn't affect any other network use (except if you happen to use the same IP address for something else by accident)... I guess the downside is that if you want to access the internet through it then you need to go through hoops (i.e., set the default route or use a http proxy as I sometimes do)
<Rjs> yes, I'm finding this channel quite useful as well :)
<dholbach> ogra_, hum, not sure you saw my message, but maybe let's just talk later
<infinity> dholbach: Oh, I saw it, but viciously ignored you becasue I was watching TV.
<infinity> dholbach: How's flash-kernel failing?  "it no workie" isn't helpful. :)
<dholbach> flash-kernel: installing version 3.1.10-9-nexus7
<dholbach> Couldn't find Android boot partition on /dev/mmcblk0
<dholbach> run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
<infinity> Huh.
<infinity> You did naughty things to your partition table?
<Rjs> (hmm, now that I think of it, I might also want to configure sshd to listen only on the usbnet interface for a bit of added security, since I don't think I'll be needing ssh through wlan)
<raster> meh
<raster> if someone can attack my sshd.. go at it.. its just a tablet
<raster> :)
<raster> does vsync work with gl now?
<raster> or is it still tear-heaven?
<raster> (n7)
<raster> i havent updated my gl drivers in fear of them turning into a steaming pile of non-workingness
<raster> also... anyone noticed how video/audio decode is skip-city?  gst is using the hw codec it seems for mp3's .. but its skiporama land...
<infinity> raster: Hey, to be fair to NVIDIA (which I'm not often accused of), the tegra2/3 Linux drivers have nowhere to go but up. :P
<infinity> raster: If you think they're a steaming pile now, you should have seen them a year or two ago.
<raster> hahahahaha
<raster> well ... the 13.04 image when i tried ub for n7.. was all corrupted texel tile heaven
<raster> and garbage land
<raster> i stick to 12.10 because it worked
<raster> :)
<infinity> Heh.
<infinity> I can't quite sort out why it's not just the same dudes doing all their drivers on a common codebase.
<raster> so i already saw them take a toe and dip them in the steaming-pile pot :)
<raster> dunno either
<infinity> Or maybe it is, and they just have zero QA on the tegra side.
<raster> i was hoping there would be at least a few hanign here making sure they work awesome pants ++
<raster> :)
<raster> so wondering who i should direct my angst and anger
<raster> i know its not canonical/community :)
<kulve> is there a launchpad bug about that?
<raster> dunno
<raster> i though i searched but didnt find anything
<raster> but it could have been nvidias new "Soak up my cpu with vsycn swaps on desktop" fun instead
<raster> and i go direct to nvidia for those babies
<raster> :)
<kulve> could you briefly explain to me how the whole vsync stuff should work with gl apps with composited window manager on top of X11?
<raster> but even if there is a launchpad bug... its almost certainly an upstream binary blob issue... which means it just gets passed on anyway - so may as well go direct
<raster> ummm
<raster> i want it for my COMPOSITOR
<raster> for apps... that's a whole different bundle of joy
<raster> as such the regular logical way is that all apps also vsync to the blank interrupt so they effectively throttle to the refresh no matter what they try and do
<raster> if windows are borderless the driver can drop to front/back buffer exchanges for composited gl appo windows
<raster> and such exchanges are/can be atomic
<raster> tho any such exchanges need to be blocked while any gpu pipeline exists anywhere with pending commands that indicate the target swap texture as a source
<raster> to avoid mid-draw exchanges
<raster> :)
<raster> then u get seamless rendering
<raster> requires windows be borderless tho (Client-side rendered frames will do - or u are in a mobile/touch ui with no frames)
<suihkulokki> a
<ogra_> xnox, hmm, we offer home encryption in oem-config, but until we manage to get plymouth into the initrd (which becomes more and more unlikely due to size issues) it wont work ... should we probably hide the option in the UI ?
<xnox> true.
<xnox> no, why?
<xnox> home encryption in oem-config is pure ecryptfs which doesn't need plymouth or anything like that.
<xnox> home encryption != LUKS aka full disk encryption
<xnox> home encryption should just work =)
<ogra_> oh, indeed, lightdm does the decrypting, silly me
<ogra_> sorry for the noise :)
 * xnox thought it's pam, not lightdm. but close enough =) it's way past initrds and stuff =)
<ogra_> right
<ogra_> well, UI wise its lightdm :) indeed there is pam
<ogra_> hmm, so i see various uploads of upower but my nexus didnt upgrade upower since yesterday
<kulve> anybody here used nexus7 in host-usb mode? Do I need some special cable or should I be able to use normal micro USB cable with some female-female adapter to plug in e.g. a keyboard?
<ogra_> you neerd an adapter cable, but then it shoudl just work
<ogra_> (a so called OTG cable)
<ogra_> hmm
<ogra_> while the interactive governor helps massively with powersaving, my dmesg explodes every time that thing is loaded, i wonder if one can quieten that a bit to make dmesg readable again
<kulve> ogra_: thanks. Looks like this so called OTG cables have standard wiring so nothing special there. Unlike with OMAPs you needed to use mini-A (or was is mini-B?) cables that had pin 4 grounded and those cables were hard to obtain originally..
<ogra_> yeah
<ogra_> i also onyl knew OTG as the OMAP cables with the shortened grounding before
<ogra_> and i still have a hard time calling these normal "adapters" OTG :)
<nils__> just wanted to express my gratitude. Yesterday i had installed my ubuntu today I managed to set up a new kernel with usbnet. Great support from here! Thank you!
<ogra_> did you by chance try with the composite gadget driver ?
<ogra_> (if that works and someone tested it we should be able to provide both, serial and usbnet)
<kulve> ogra_: do you need the serial login, if you have usbnet..?
<ogra_> i would like to have the choice
<nils__> i changed the configuration manually switched on USB_CDC_COMPOSITE and removed USB_G_SERIAL
<ogra_> and eventually we will have to provide usbnet anyway for file transfers etc
<ogra_> nils__, you rock, thats what i hoped
<ogra_> (for getting some data about g_composite)
<kulve> ogra_: I'm using g_multi with my Mer based rootfs
<nils__> I can connect via "sudo screen /dev/ttyACM0 115200"
<nils__> And with lsusb I can see this output "Bus 002 Device 050: ID 0525:a4aa Netchip Technology, Inc. Linux-USB CDC Composite Gadge (Ethernet and ACM)"
<ogra_> and you can set up a usbnet connetion too ?
<nils__> ifconfig shows usb0
<ogra_> great !
<nils__> but till now I haven't managed to set up the networking. But this is clearly because I have no clue yet how to do it. ;-) I am just starting.
<hrw> kulve: OTG cable is normal USB cable with ID pin grounded
<nils__> so I guess I will have to set up a little bit neworking stuff like ip adress, etc.
<kulve> hrw: so it is a special cable and I can't use the cable that came with the device and a basic female-female -adapter?
<hrw> kulve: if you have a way to configure device to switch to OTG in software you can
<hrw> on nokia 770/n810 it was easy
<kulve> ok. I thought that the devices could communicate with each other enough to realise who's the boss and who's the slave
<kulve> without that ID pin
<hrw> nope
<hrw> usb is pull not push
<hrw> host pulls slaves
<janimo> ogra_, will we have onboard for 13.04 ?
<janimo> it has so many bugs apparently
<ogra_> i saw a workitem for Laney to get maliit into debian and ubuntu and to test it
<ogra_> but maliit has poor layout and no modifier keys
<Laney> I'm not doing that with the intent of it replacing onboard
<Laney> at least not yet
<ogra_> it might be less resource hungry but you pay with missing fuunctionality
<ogra_> Laney, well, for comparison reasons :)
<Laney> indeed
<ogra_> and its no secret that we inspect maliit as alternative :)
<ogra_> came up at UDS already
<plars> ogra_: I wasn't able to get far with the oem-preseeding still, but I'm doing upgrade and run tests now, and have things like baseline smem and mem testing to help do comparisons between n7 and amd64
<plars> ogra_: the baseline wakeups/sec from eventstat are *really* high by comparison on n7
<ogra_> well, make sure to upgrade to the very latest, there qwere several fixes yesterday and tonight
<ogra_> especially for wakeups
 * janimo installs eventstat
<plars>   Evnt/s PID   Task            Init Function             Callback
<plars>   207.97     0 [kern sched]    Load balancing tick       tick_sched_timer
<janimo> ogra_, so we have no xrotate calls or xorg rotation settings anymore by default ?
<ogra_> janimo, only from acceld
<plars> ogra_: I'll run again this morning
<plars> these were from yesterday
<janimo> ogra_, ok, I have the equivalent of acceld in g-s-d, I'll probably upload soon
<ogra_> plars, i uploaded a bunch of cpufreq configurations today ... and a fix for getty waking up 100 times per second when used with ttyGS0
<ogra_> that should sanitize it a bit
<janimo> I was just wondering what messed up colin's lightdm setup (he filed a bug 20 min ago)
<ubot2> Launchpad bug 20 in Launchpad itself "Sort translatable packages by popcon popularity and nearness to completion" [Low,Invalid] https://launchpad.net/bugs/20
<ogra_> janimo, well, cjwatson upgraded from quantal ...
<plars> ogra_: cool, we'll hopefully have graphs of this soon too, so that we can monitor over time
<ogra_> janimo, probably some leftover from some hack from the demo image
<ogra_> for me lightdm works fine
<janimo> same here
<janimo> always portrait btw
<ogra_> he already had issues with the kernel upgrade ...
<ogra_> yeah, lightdm just uses what xorg gives it as default
<ogra_> which now is always portrait
 * janimo checks if acceld rotated lightdm as well
<janimo> cause g-s-d does not
<ogra_> acceld doesnt either
<cjwatson> I didn't really have issues with the kernel upgrade
<janimo> ok, so this is a bug
<cjwatson> I just needed to know to do it
<ogra_> you would have to add acceld or g-s-d's rotation plugin  to the  lightdm session
<ogra_> cjwatson, vs "everyone else gets it automatically" :)
<cjwatson> Well, sure, but that was just at the apt level; I've cleaned all that up now
<cjwatson> (I'd deliberately pinned to the PPA back when raring didn't quite work right)
<ogra_> is your ubuntu-defaults-nexus7 at least at 0.44 ?
<cjwatson> 0.47
<cjwatson> All my packages are current raring now
<ogra_> (that ships the xorg.conf.d snippets)
<ogra_> weird
<cjwatson> Are the xorg.conf.d snippets read dynamically, or are they built somehow?
<plars> ogra_: I'm not using serial console, so that shouldn't be causing a problem for me, but I'm getting ~450 wakups/sec it seems on the test I just ran
<janimo> cjwatson, we have an installed snippet at /usr/share/X11/xorg.conf.d/21-nexus7-rotation.conf
<ogra_> cjwatson, just plain files, no generation
<cjwatson> Yeah, I have that file
<janimo> ogra_, do you have other uploads queued for u-d-nexus7 ?
<ogra_> janimo, well, i need some way to shut down usb0 on boot, i was just starting to work on an upstart job, nothing queued directly, no
<janimo> after the g-s-d patch is landed and working we need to disable acceld and add a new udev rule. And as minor cleanups disable Z axis reading and everything rotation related in the xorgs snippet
<janimo> ogra_, ok I'll paste you the changes so I don't step on your upload
<ogra_> well, just upload away
<janimo> with proposed gating I need to remember to use pull-lp-source not apt-get source as the latter can get older versions
<ogra_> i have meetings starting in an hour and am probably not getting to the usb0 stuff until they are done
<achiang> janimo: why did you mark this as invalid? https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/1031449
<ubot2> Ubuntu bug 1031449 in rhythmbox (Ubuntu Quantal) "rhythmbox leaking memory" [Undecided,Confirmed]
<janimo> achiang, let me check I don't recall
<janimo> ah, invalid on the nexus product, reasoning we cannot add affects nexus7 to any bug that happens to occur there as well.
<janimo> Or was this spotted on nexus7 only, in which case my bad?
<janimo> I tried cleaning up some bugs at one point and there were completely unrelated issues affecting nexus7, even bugs of rarely used universe  packages
<janimo> I am not sure that is how the project's tracker needs to be used.
<janimo> I know the rb-ubuntuone plugin was mstly nexus
<janimo> but that was a different bug
<ogra_> and was fixed early this cycle
<ogra_> we never had the issue on the raring images
<ogra_> (the -ubuntuone one)
<janimo> ogra_, right, just mentioning an example where I thought adding affects ubuntu-nexus7 makes sense
<janimo> I thought it is mostly an umbrella for bugs that either span multiplenexus related packages or are otherwise occuring mostly on this hw
 * ogra_ doesnt care as long as one task stays open so someone works on  it at some point
<janimo> I only care because filtering nexus bugs is easier if all bugs are specific to this image
<janimo> not generic app bugs and not even ARM specific issues
<ogra_> yah, makes sense
<achiang> janimo: maybe my blog on memory leaks asked people to file bugs in nexus7 so we could find them easily. :)
<achiang> janimo: it was kinda relevant due to the "optimize mobile" effort
<janimo> achiang, I agree it is ok to get people file bugs on memeory leaks.
<janimo> I just thought having a memleak or somesuch tag (I think we even had one initially) would be more appropriate
<achiang> janimo: fair enough. :)
<janimo> cause then people without nexus can join in without thinking they need specific hw to test and fixc
<janimo> fix
<angs> I have beagleboard that runs ubuntu-server (12.04). while it uncompress the kernel, it takes too long to wait on Starting configure network device step each time. how can I configure it to skip that step if there is no network connection on the device?
<angs> it takes more than 2 min to wait on that step on each boot
<Neko> do you have entries in /etc/network/interfaces besides lo ?
<angs> yes
<Neko> because removing any that say "dhcp" will fix it, or giving a fake static IP.. but what might be better is install network-manager and let it automatically handle everything for you
<ogra_> on a server ?
<Neko> network-manager has a command line :)
<Neko> besides this isn't really a "server" if we're talking about a beagleboard with usb ethernet
<Neko> the other alternative is write some nifty udev rule
<Neko> network-manager just solves the problem immediately though without introducing any behavior nobody can reproduce ;)
<ogra_> it is nontheless a bug if a server install behaves like that after installation
<ogra_> stgraber, i though that was fixed in an SRU ?
<angs> I have this version: Linux user 3.2.0-23-omap #36-Ubuntu Tue Apr 10 20:24:21 UTC 2012 armv7l armv7l armv7l GNU/Linux
<Neko> not really. if I disconnect my virtual ethernet from a VMware server instance, it does the same thing on every distro I've ever used... it's partially because the networking script hangs around waiting for the device to be probed isn't it?
<stgraber> ogra_: what bug?
<ogra_> angs, are you fully upgraded to the latest packages ?
<Neko> networking could be "starting" long before modules are probed, especially if dealing with drivers that do probe deferral
<ogra_> stgraber,  60sec timeout on boot to bring up networking
<angs> can't I skip that step without installing network-manager. I am told that network-manager has many bugs etc.
<angs> ogra_: I havenot updated it for months. I will do that now
<ogra_> network-manager is fine, the point is that it should work without it
<stgraber> ogra_: if you install a non-desktop version of Ubuntu and d-i writes an entry for eth0 in /etc/network/interfaces. If that interface doesn't exist at boot time, you need to wait 90s before the system hits the fallback and boots
<ogra_> ergh
<ogra_> any workaround ?
<angs> I have only lo and wlan on /etc/network/interfaces, I don't have eth interface written on that file
<ogra_> and you actually use eth and not wlan ?
<angs> yes, a cable is connected to the eth
<angs> is it the reason of my problem?
<ogra_> if you dont use the wlan i would indeed wipe it from /etc/network/interfaces ... did you use it at install time ?
<angs> I unplugged the ethernet cable and am rebooting the device now.
<angs> I wrote wlan0 info on that file long ago, but I am planning to use a wifi dongle soon
<angs> btw, it still waits long even ethernet cable is unplugged, it shows Waiting up to 60 more seconds for network configuration... and before
<Rjs> angs: maybe it waits for dhcp from the wlan? do you have "auto wlan0" or "allow-hotplug wlan0" in the interfaces file? (if you do, you can take it out and "ifup wlan0" will still work, then it's just not done automatically)
<ogra_> thats why i suggested commenting or removing the wlan entry
<Rjs> you can keep the entry ("iface wlan0" etc.) if you want: if you remove auto and allow-hotplug, the entry should never be used unless you run "ifup wlan0" manually (or at least that's how it works on debian without any network-managers; I don't know if ubuntu has something special there)
<Rjs> by the way, I just tested the usbnet gadget in nexus7 without having anything related to it in /etc/network/interfaces, and it does correctly detect whether it is plugged in:
<Rjs> I specified a static IP in the GUI ("Manual" IPv4 setting in the "Edit Connections" dialog, remembering to turn default route off in the Routes sub-dialog) and it seems to work: I get a notification about the "Wired connection" when I plug in the usb cable, and another when I plug it out
<ogra_> yeaah
<Rjs> so it appears to work just as it should (just like a normal wired Ethernet device)... except maybe that I noticed that the usb0 interface is always UP according to ifconfig, but only has an IP when plugged in (so I think NM sets and removes the static IP), but I don't think it matters
<ogra_> thanks for testing
<ogra_> yeah, we discussed NM behavior before in #ubuntu-devel
<ogra_> it will get fixed to not annoy you with autoconnect attempts
<Rjs> ok :) (though I don't think it annoys you with anything after you've set a static private IP, then it just thinks that it is connected whenever plugged in? and if the interface has no default route, nothing should send any packets there unless the private IP network is used?)
<ogra_> well, would your mom want to do that ?
<ogra_> if you plug the device in it should just be accessible but not pop up messages all the time :)
<Rjs> hmm, ok :) so you're somehow setting networkmanager's default so that it doesn't bring up the interface at all unless configured by the user first?
<Rjs> (I don't really know what would be a good overall default; my first idea was to automatically set a randomized static private IP, but then there's the problem of communicating the IP to the user when he wants to set it up; then I thought of setting up only the IPv6 link-level address and nothing else, but probably many users would have trouble with anything ipv6 even if on a private link)
<Rjs> but maybe it's ok to leave it completely up to the user (if (s)he wants to use the usbnet at all), though maybe it would be good to point out somewhere (in a "Tips" page in the wiki perhaps) that if you control both ends, a static IP may be much easier to configure than setting up a DHCP server on the host computer just for this
<Rjs> (of course, none of this is nexus7-specific but common to any device that runs ubuntu and works as an usb gadget, so it's good to have a solution that is as general-purpose as possible - but I guess you know that already)
<ogra_> yup
<scientes> i cant figure out why my watchpoint isn't working
<scientes> i have a memory address that usually has a valid value in it
<scientes> but sometimes it has null which causes a null pointer dereference
<scientes> i did "watch 0x<fooaddr>", which is the same address as x <fooaddr> which returns a value sometime and othertimes null
<scientes> but the hardware watchpoint never breaks
<scientes>  i also tried watch *(int *) <address>
#ubuntu-arm 2013-01-31
<tripelb> Can I root with no PC? just the N7 Alon?
<tripelb> Can I root with no PC? just the N7 alone.
<scientes> tripelb...not here
<scientes> i have the answer...
<dholbach> good morning
<janimo> ogra_, do we still have freezes and image respins occasionally? Why are there .1 and .2 updates to yesterday's image?
<infinity> janimo: Because some people (I was one of them) spun nexus7 by hand.
<janimo> infinity, I was more intrigued by the reason actually :) Is this Thursday some sort of alpha or why the urgency?
<infinity> janimo: Because the image builder was down for 6 days, and I was testing things when it came back.
<janimo> just fixing image build bugs is a good reason
<infinity> janimo: Nothing release-related at all.
<janimo> infinity, ok
<ogra_> janimo, hmm, i dist-upgraded yesterday and have all your changes installed, butu seems acceld is still running and if i stop it i have no rotation
<janimo> ogra_, so you have u-d-n-0.49 and gsd -ubuntu3 ?
<ogra_> janimo, do we need to do anything for the device permissions perhaps ?
<janimo> ogra_, sudo udevadm info --query=property --name=iio:device
<janimo> does this show ID_INPUT_ACCELEROMETER=1 among others?
<ogra_> i have both packages, yeah
<janimo> acceld is started in the X session hook (which I thought I had deleted)
<janimo> I planned on installing a fresh image but will wait the first image with these packages in it - yesterday's last does not yet
<ogra_> didnt you remove the upstart job for acceld ? the Xsession script checks if it is enabled iirc
 * ogra_ checks his code
<ogra_> yeah
<ogra_> it looks for /sys/bus/iio/devices/iio:device0/buffer/enable
<ogra_> janimo, if you are actually sure it works, just wipe acceld completely, it wasnt meant to stay :)
<janimo> ogra_, I thought it is only started from the X session hook
<janimo> kept the upstart bits as they initialize sysfs attributes with root privileges
<ogra_> ah, indeed, you use them too
<ogra_> err, no
<ogra_> you at least dont read them dircetly, do they affect the /dev behavior ?
<janimo> we do not read anything from /dev actually, just from sysfs
<janimo> I thought I'd keep acceld along if someone wants to still debug rotation in the near future if g-s-d has issues
<ogra_> janimo, you pointed out binary firmware for the accelerometer, where is that ?
<ogra_> (or how is it called)
<janimo> there exists on android (inside executables) not as a separate file
<ogra_> ah, k
<apw> ogra_, the driver claims to provide polled interfaces when it has firmware loaded
<ogra_> apw, ^^^
<janimo> it's a few Kb of microcode only
<janimo> apw, it does, but the firmware is not only not free but it is unavailable
<janimo> seems to have been partially (?) reverse engineered by the libi2cdev project
<apw> well that sucks
<pitti> janimo, ogra_: hello
<janimo> apw, the dirver indeed even provides orientation as a sysfs attribute when enabled
<janimo> pitti, hello
<ogra_> hey pitti
<apw> janimo, it was the 'poll' able interface i was interested in, but that doesn't work without
<janimo> apw, right, my understanding also
<apw> so we don't have to poll, sigh
<janimo> we may get it to work but it seemed nonobvious techinically and murky license-wise
<apw> yeah
<janimo> still I plan on looking into it, as this particular sensor is going to be in many other devices
<pitti> janimo: do you happen to know if we can use the triggers feature instead of having to poll all the time?
<janimo> it is in the galaxy nexus and the transformer at least
<janimo> variations of the MPU
<ogra_> pitti, i guess only with binary firmware
<janimo> pitti, no idea, but I plan on looking at the kernel side to check this
<janimo> to see if we can without firmware that is
<ogra_> though it shouldnt be to hard to move the acceld logic into the driver, would it ?
<janimo> btw android on the nexus7 seems to read the raw data from sysfs, and has no fw loaded
<apw> janimo, i've just been reading the driver and all the event driven stuff is dependant on dmp being enabled, and that is dependant on the firmware
<janimo> maybe it uses some cleverer approach that eluded me as I did not look much into the kernel
<apw> ogra_, to make the kernel poll for you ?
<janimo> waking up every 1 s is suboptimal I agree
<ogra_> apw, well, the kernel processes these numbers anyway at some point, no ?
<apw> ogra_, only on read
<janimo> apw, a middle road would be to have a kernel timer, have it do the calculations and only fire a kevent if it detects orientation chaneg
<ogra_> hmpf, ok, i thought you could just run them through a filter that sends a trigger
<apw> janimo, and that would be better how
<janimo> so less process wakeups but policy and hacks in the kernel driver
<apw> how would there be less process wakeups, a kernel thread is a process too
<janimo> apw, ok, I plead ignorance then. I thought kernel timeouts would be more lightweight somewhat
<apw> not really, it would look pretty much the same as a userspace process doing it
<apw> the most efficient way would be to find something which is already polling
<apw> and poll in that same process
<janimo> and piggyback on that?
<apw> so you have one wakeup
 * pitti cannot think of something else on the desktop which is polling regularly
<janimo> I was hoping g-s-d already does that and our poll would just tail on an existing one, but other timeouts in g-s-d are usually largert
<pitti> no, g-s-d's orientation/media keys plugins mostly listens to XF86Rotate input events and similar, they don't poll
<pitti> so I guess we could at least put luxd and acceld into one C process which does the polling for both
<janimo> pitti, I mean other plugins, if they are in the same process (g-s-d) couldn't glibs timeout code wake them up at the same time?
<janimo> I was hoping g_timeout_add_second wakes up at second boundaries for this reason
<pitti> janimo: that's what I said, there are no polling plugins right now
<apw> pitti, cirtainly wherever they go, we should poll them based on one timeout
<pitti> we need to introduce one
<janimo> pitti, ok. I grepped the source for g_timeout_add and there were a few, but they may not be enabled then
<janimo> screensaver and powermanager come to mind
<apw> ogra_, when you read those values from sysfs the kernel gets the value 'now' from the actual h/w registers by the looks of it
<pitti> janimo: yeah, those use long timeouts, not subsecond polling
<apw> so it isn't polling internally
<janimo> we'll need similar polling for the light sensor (but I need to check, that may provide some trigger)
<janimo> apw, from the buffer which we set the length to 200 at the moment
<pitti> janimo: I profiled g-s-d in a running desktop session, it got about 20 wakeups a minute; i. e. it doesn't currently poll devices, but it's as good a place as any to do that
<pitti> janimo: e. g. g-s-d's orientation plugin would be ideal in the sense that you can immediately hook into the "action" parts
<janimo> we can still tweak the accel to only use low power mode, and use 1.25HZ frequency
<janimo> but that only helps with its internal power savings, not the process wakeups
<ogra_> pitti, btw, do you know if we already have a list of g-s-d modules we want to disable ?
<ogra_> (or who is reviewing it)
<pitti> ogra_: yes, http://pad.ubuntu.com/nexus7-desktop-profiling
<pitti> ogra_: I came up with three which are definitively "out", and a handful which I'm uncertain about whether we need these features; but as they only add a negligible overhead my feeling is that we should leave them on for now
<janimo> pitti, 20 wakeups a minute sound ok. Does the desktop still have frequent waker-uppers? (1/s or more frequent) ?
<pitti> janimo: actually, compiz does
<pitti> janimo: that wakes up 60 times a second for vsync wakeup etc.
<pitti> janimo: (or the unity plugin)
<ogra_> pitti, oh, right, i even commented already
<pitti> janimo: that's pretty much the only process which wakes up that often
<pitti> janimo: it might not actually be bad to put that polling into the unity plugin? it's "our" code anyway so we don't need to maintain huge patches against g-s-d, and can piggyback on the wakeups?
<pitti> janimo: oh, the second is firefox when you have JS pages open; but I guess we can safely discard that :)
<janimo> pitti, g-s-d was the most straightforward place as it dealt with accel and rotation already
<ogra_> janimo, oh, btw, i was wondering if we couldnt "DPMS blank" and unblank the screen before and after rotating ... to hide the screen corruption
<janimo> no idea about how it would fit in unity but I am open to the idea
<janimo> pitti, or a g-s-d unity plugin?
 * janimo has no idea whether such a thing even exists
<pitti> janimo: I think g-s-d's orientation plugin is the most obvious one, but will require hard-to-maintain patches and additional wakeups; unity's is the most efficient in terms of wakeups, but might be harder to change
<janimo> pitti, this particular patch is small btw, not sure what else we may need in term of orientation
<pitti> janimo: g-s-d unity plugin> not right now
<janimo> I mostly considered this code as a stop-gap proof of concept until we figure out a better way possibly post 13.04 when we run into more types of accel sensors and have a better idea what may work across them
<janimo> pitti, is the etherpad above only about nexus7 g-s-d modules, will we have nexus specific module blacklist?
<ogra_> well, i would call it tablet specific
<pitti> janimo: no, these three plugins are not really n7 specific; I think we should disable them for all mobile devices
<pitti> wacom and color apply even less to phones than to tablets
<janimo> pitti, great, I hope we have as little divergence between n7 and the rest as possible
<ogra_> actually i think the unity formfactor gsetting needs to be enhanced ... and g-s-d should enable/disable them based on this
<pitti> janimo: we can disable those in the -defaults package
<ogra_> (it currenly only has "netbook", "desktop" and "automatic" options)
<ogra_> pitti, but thats very nexus7 specific, long term g-s-d should detect the right thing
<ogra_> (for 13.04 the settings package will surely do though)
<pitti> ogra_: we can disable the updates plugin globally even; that's the one which is really useless on ubuntu
<pitti> as for color and wacom, that's more like a matter of choice; wacom is actually quite harmless (again, only triggered when you actually have such a device), but color is quite costly because of activating colord
<ogra_> which doesnt even work on our LCD
<Rjs> ogra_: dpms blank and unblank at rotation sounds like it is working around a bug in the X.org driver (i.e., if the nvidia driver was free software, you'd probably try to fix the screen corruption there?)
<Rjs> ... so maybe the right place for a workaround would be in the X server, as some sort of wrapper for rotate requests before they get passed to the nvidia driver? or would that be too intrusive?
<Rjs> hmm, or actually, does it use kms or something similar to rotate? if it does, you could possibly work around or even fix the corruption in the kernel driver, which is free software? (also, I've seen lots of display-related patches lately while browsing the linux-tegra list, but I don't know enough of the hardware to know if they have any relevance to the nexus7...)
<ogra_> i fear that might be to intrusive since it would also affect sanely working drivers
<ogra_> effectively nvidia needs to fix it
<ogra_> but there is also compiz or nux that is redrawing really slow, i havent tested on lxde, but i bet the corruption will be a lot less there
<janimo> hrw, have you considered uploading a chromebook kernel to ubuntu?
<janimo> or some sort of exynos kernel
<ogra_> ++
<ogra_> janimo, btw udevadm info --query=property --name=iio:device doesnt exist iio:device0 and 1 do though, 0 has the ID_INPUT_ACCELEROMETER=1 property but also 0600 permissions and is root owned (no udev-acl in place)
<janimo> ah yes the 0 dropped off in the paste
<janimo> ogra_, I don't remember doing anything with udev-acl or permissions
<janimo> root owned is ok as we do not read from it
<ogra_> well, doesnt the user need read access at least ?
<janimo> sysfs is user readable
<ogra_> ah, k
<ogra_> i thought you read from the device
<janimo> no, we coudl read from there too but sysfs seemed simpler
<janimo> well doing exactly as the go/dash scripts did, read form sysfs files
<janimo> no idea why acceld is still running there though
<janimo> and why g-s-d does nothing
<janimo> ogra_, ah you mentioned screen blanking above. I guess we could do something to cover the ugly rotation effects
<janimo> not sure how blanking would look
<janimo> unfortunately we cannot do animated rotation as android does :)
<ogra_> hopefully just like "flash to black and back"
<ogra_> (WW) TEGRA(0): LVDS-1: Error querying display modes: No such device.
<ogra_> i'd really like to know which device it talks about :/
<janimo> right, weird xorg.log spa,
<janimo> spam
<ogra_> well, xrandr prints that too
<janimo> you can strace and see what it checks for
<janimo> maybe we have some etc permissions wrong?
<janimo> I mean /dev permissions
<ogra_> i dont think so
<ogra_> all tegra* devices are handled by ACLs
<ogra_> all nv* devices too
<ogra_> oh !
<ogra_> i never noticed /dev/lightsensor before
<ogra_>  /dev/fb0 and 1 are ACL handled as well
<janimo> ogra_, lightsensor is only used for debugging from what I saw
<ogra_> ah, k +
<ogra_> how sad
<janimo> to ioctl on it and toggle printks
<ogra_> hmm there is a knvmap
<ogra_> nvmap is ACL'ed but not knvmap ... i wonder what that does
<ogra_> oh, i tried gpsd for laughs ... seems it connects and initialized the device fine (according to xgps) but it never starts connecting
<janimo> ogra_, when are the daily nexus7 images built?
<ogra_> 14:something UTC
<hrw> janimo: after fosdem I will have kernel which I consider uploadable
<suihkulokki> hrw, janimo, I think it should be quite possible to have a single exynos5 kernel supporting arndale/chromebook/nexus10
<hrw> suihkulokki: arndale uses 3.8, nexus10 uses 3.4(?), chromebook uses 3.4
<hrw> suihkulokki: if someone wants to work on 3.8 for chromebook then I can test from time to time. But prefer something "stable" for each day use
<janimo> suihkulokki, that would be great indeed
<janimo> hrw, do you know about these? I was pointed to by fabo http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/using-an-upstream-kernel-on-snow
 * janimo has no chromebook or any exynos btw, just thinks that having the kernel in 13.04 is a good idea
<hrw> janimo: I know
<hrw> janimo: note that it also says "text console only for now"
<hrw> no x11, no usb, no keyboard, no charging
<janimo> hrw, ok I wasn't aware of the status of that effort
<janimo> or the uptodatedness of the page
<hrw> works: serial (if you have debugboard == work for google), i2c (except one with keyboard and pmic), power button/lid switch, emmc/sd
<hrw> not work: x11, usb, i2c4 (keyboard, pmic), display, hdmi, wifi, rtc, trackpad, audio
<hrw> but it is good that they list status
<hrw> and its 2 months old now so maybe got better
<cjwatson> ogra_: bug 1110408 - I may have been a bit confused, as I didn't realise that we'd deliberately switched to portrait mode by default, so it was mostly just an upgrade surprise.  I guess the main bug was that touch was miscalibrated, then, and that no longer seems to be true.  Should I just close it?
<ubot2> Launchpad bug 1110408 in ubuntu-defaults-nexus7 (Ubuntu) "Log out â lightdm comes back in portrait mode" [Undecided,New] https://launchpad.net/bugs/1110408
<cjwatson> I probably
<cjwatson> just hadn't rebooted since some relevant bit of the upgrade, or something
<hrw> janimo: new chromebook kernel requires also new opengles driver for which I need to write new packaging with license stuff etc
<janimo> cjwatson, that lightdm does not rotate is a bug though, it has some overlap with your experience
<janimo> seb128 knows about that too so it's targeted
<janimo> hrw, is that package that you needed the license stuff for yesterday?
<hrw> yes
<cjwatson> janimo: well, ok, but lightdm does now seem to work properly in portrait mode for me ...
<cjwatson> as in I can actually touch "Log In"
<hrw> I have first version but it complains about debconf not being interactive even when debconf is dialog or readline
<janimo> right, so that bug as you said is not valid. It's just that it would show up in portrait when you log out of an otherwise landscape session
<janimo> I found this out only yesterday after seeing your report
<hrw> janimo: btw - what do I have to check before pushing chromebook kernel to archive?
<janimo> hrw, if the packaging (naming, structure) is more or less like other kernels' and there are no ambiguously licensed bits in it it should be ok
<hrw> janimo: I used linaro kernel packaging which is based on ubuntu one
<janimo> it won't go into the archive unless an archive admin reviews it (infinity most likely) anyway
<hrw> sure
<janimo> the ac100 and nexus7 kernels are based on linaro packaging too
<janimo> and infinity thinks having exynos in archive is a good idea - I asked you because I remembered him saying it :)
<hrw> ;)
<cjwatson> janimo: OK, so, do you want my bug open or closed?
<janimo> hrw, do you know if the SoC on chromebook and nexus10 is the same?
<hrw> janimo: iirc same
<janimo> cjwatson, closed or renamed to 'no rotation in lightdm' I'd say
<hrw> exynos5250
<janimo> hrw, great, but likely much different peripherals
<hrw> janimo: indeed
<janimo> hrw, btw are there inertial sensors on the chromebook?
<janimo> accel/gyro/compass like on a mobile
<hrw> janimo: no idea really
<hrw> git-buildpackage sometimes is nasty but in general roxx
<janimo> hrw, doesn't look like from a quick search. Probably not much value in them
<jibel> Xorg on my Nexus 7 died with the error http://paste.ubuntu.com/1593004/ while running these tests https://wiki.ubuntu.com/Nexus7/BrowsingSimulation , is it a known issue?
<hrw> I need to buy usb3 hub and usb3 case for 3.5" hdd
<janimo> jibel, not that  I know of. Do you know if it fails on other similarly specced ARM hw?
<hrw> my 320GB hdd is wasting bandwith of exynos5 usb...
<ogra_> cjwatson, right close it ... (sorry was afk)
<jibel> janimo, no idea, I just have tested on this device
<jibel> and didn't find anything interesting on the web yet
<janimo> jibel, feel free to file it under the ubuntu-nexus7 project then
<jibel> janimo, k
<janimo> it will get reproduced and kept track of. thanks
<cjwatson> ok, closing, thanks
<apw> ogra_, -9.25 in the can and building
<ogra_> apw, yep, saw it, thanks
<hrw> E: linux-chromebook-3.4 source: build-depends-indep-without-arch-indep
<hrw> thats only what left from lintian ;)
<janimo> hrw, so your package probably is the cleanest ubuntu kernel package then :)
 * janimo wishes we had an uptodate git kernel-package repo which all kernel package sync up with from time to time
<hrw> janimo: https://github.com/hrw/chromebook-linux
<janimo> it's too much gratuitous divergence in packaging
<hrw> janimo: we have such one at Linaro
<janimo> hrw, I'd name the package linux-exynos5 or something. There may be a new chromebook or two in the future
<hrw> same with exynos5 hardware
<hrw> but I understand
<hrw> x86 chromebooks for example should be ~fine with default ubuntu kernel
<ogra_> janimo, i noticed that my desktop now comes up in portrait by default and you need to rotate it once to activate rotation at all ... did you set the default orientation to "right" in g-s-d ?
<ogra_> (should be "normal" in protrait)
<ogra_> jibel, hmm, that uses chromium ... afaik out package is pretty outdated and it crashes for me after a while when using it
<ogra_> (it breaks all font rendering here, likely due to an incompatible cairo version thats shipped in the chromium package)
<janimo> ogra_, yes I noticed that too, I need to see what the issue is :) Maybe the same bug as I ad in acceld
<ogra_> yeah
<janimo> ogra_, I wonder if we should test all X related bugs in lubuntu as well to rule out compiz/unity/3d
<ogra_> would make some sense i guess
<ogra_> not that i'm eager to install lxde though :P
<jibel> ogra_, it shouldn't make X crash, does it?
<ogra_> chromium ? no it just breaks font rendering
<ogra_> but the testsuite might break sue to it, no idea
<ogra_> *due
<janimo> hrw, for the final upload the skipabi and skipmodule bits need to be removed, so these tests get performed
<janimo> annoying as they are
<hrw> ok, thanks
<hrw> did some tweaks and sent package to pbuilder now
<ogra_> bug 951827
<ubot2> Launchpad bug 951827 in gnome-power-manager (Ubuntu) "Power Statistics window blank" [High,Fix released] https://launchpad.net/bugs/951827
<angs> I need to compile wpa_supplicant for a ubuntu-server image for beagleboard. Linux ubuntu2 3.2.0-23-omap #36-Ubuntu Tue Apr 10 20:24:21 UTC 2012 armv7l armv7l armv7l GNU/Linux. can anyone tell me how I can do it?
<ogra_> geez, my N4 was just sent ! i only ordered today !
<ogra_> angs, whats wrong with the wpa-supplicant package we have in ubuntu ?
<angs> I am trying to predefine the cell ID for an ad-hoc wlan and using " bssid=92:4B:23:9D:30:DA " on wpa_Supplicant for it. however it never gets that cell id. on #linux-wireless I am told that the current wpa_supplicant that I am using is too old (0.7.3) and I need a newest one
<angs> the latest one is 2.0
<angs> is there any instruction how I can compile a package for ubuntu-arm?
<ogra_> just compiling it on the board is the easiest
<angs> what do I need to do after I download the package on the board? Is there any instruction for that?
<ogra_> are you sure about 1.0 ?
<ogra_> the latest releas in debian and ubuntu is 1.0
<ogra_> err about 2.0 indeed
<angs> yeah it is 2.0
<ogra_> well, the general triplet of commands should do (configre/make/make install) if you use an upstream source
<ogra_> you probably might need some build dependencies installed, i would look at the build deps from the ubuntu package and just make sure you have these
<angs> thanks for your help ogra_
<cj5> I'm having trouble booting Ubuntu 12.04. After a few tweak to the boot.scr I got to get to the UI, once to the language selection window, otherwise I get the Ubuntu background for a while then it reboots.
<cj5> Pandaboard ES
<cj5> Wondering what logs files I can look to to diagnose the problem
<cj5> actually just found this in the syslog right before reboot - Unable to determine the model from DMI
<hrw> janimo: ok, source package renamed to linux-exynos5-3.4 but is binary package linux-image-VER-ABI-chromebook fine?
<janimo> hrw, a moment
<hrw> ok
<ogra_> hrw, thats what we use for ac100 and nexus7, should be good
<hrw> cool
<hrw> they should give devices some names ;)
<Laney> I've got some pretty bad graphical corruption after flashing the current N7 daily. The background isn't rendered properly and half the screen is shifted over (and oem-config is off the side and is unusable). Anyone seen this?
<janimo> hrw, should 3.4 be in the source package name? I don't think we have that elsewhere
<hrw> can kill
<Jef91> Has anyone gotten hardware accelerated video decoding working on the Nexus 7 under Ubuntu?
<Laney> https://picasaweb.google.com/lh/photo/25VNEPdfiynNV9ZIrFj15dMTjNZETYmyPJy0liipFm0?feat=directlink
<Laney> like that
<Jef91> looks painful Laney
<janimo> hrw, I'd also say the binary package image should be the same as the source's. I'd suggest using the same scheme as ac100 and nexus
<janimo> as they are in the archive and noone complained about their naming :)
<janimo> although they are named after the product not the soc
<hrw> janimo: they had product names
<janimo> I was just thinking the exynos kernel may be used by other devices using that SoC
<hrw> if I make linux-daisy or linux-snow + linux-image-3.4.0-5-daisy or linux-image-3.4.0-5-snow who will know what it is?
<janimo> hrw, I'd consult infinity on this issue as well
<hrw> next week then
<janimo> maybe exynos indeed would be too generous if it only worked with chromebook and contained chromebook specific code
<hrw> I plan to go to sleep in ~2h
<hrw> 04:00 trip to fosdem starts
<janimo> hrw, have a good trip and conference!
<hrw> thanks
<mosasaur> Can I install a version of ubuntu on a galaxy note GT-N7000? I mean native.
<mosasaur> https://wiki.ubuntu.com/ARM/DeviceSupport
<mosasaur> I suppose that it's not easy
<gmulak1> I went to Ubuntu site but cannot find the ARM version to download - help please
<Jef91> gmulak1 installing on ARM devices is very different than installing on X86
<Jef91> it isn't "one download fits all"
<Jef91> Generally installing is different on every device.
#ubuntu-arm 2013-02-01
<wbf> how would I fix a broken /lib/modules/(kernel version)/build
<wbf> link?
<daurnimator> '/wc
<dholbach> good morning
<kulve> anybody thinking of getting ouya as small ubuntu-based "desktop computer"? Surely it's low-end compared to actual PCs but it might be enough for some basic stuff, emails, www, video playback
<kulve> and ubuntu's current UIs would suit that use case probably better than e.g. nexus 7
<ogra> yipiie, my n4 arrived
<ogra> i wish i had a micro sim already
<gildean> ogra: you can cut your normal sim to fit the micro-slot
<gildean> i've done it a couple of times, just make sure you don't cut too much and you're fine
<gildean> there're a bunch of guides on how to do it like this one: http://www.solutios.com/simcutting/
<vanhoof> ogra: how is it?
<Laney> I just took my SIM to the shop and they did it for free with a punching device
<Laney> didn't trust myself to cut it
<ogra> vanhoof, cool piece of HW
<ogra> i ordered a new SIM already but that wont arrive before tomorrow
<infinity> ogra: You've joined the hordes of proper smart phone owners?  I thought you made fun of all of us.
<ogra> haha
<ogra> well, i have an S2
<ogra> HW wise thats actually proper i'd say ...
<vanhoof> ogra: after I got into this situation w/ my S2, I decided the nexus line is for me :) http://ubuntuone.com/1VhMjTNOGS1p7epWyVSUtt
<ogra> lol
<wendar> I'm getting install failures in the OMAP4 daily images raring-server-armhf+omap4.img
<wendar> (repeating from ubuntu-server channel, just in case)
<ogra> wendar, hmm, i dont think these have been tested a lot lately, except by the auto-testing (since dropping the milestones nobody tests much anymore)
<ogra> how does that manifest ?
<wendar> ogra: yeah, I'm just refreshing my PandaBoard dev environment to do some armhf work on universe FTBFS
<wendar> ogra: it makes it through the partitioning step
<wendar> ogra: but, when it tries to run the tasksel for Open SSH Server, it gives a generic "Installation step failed" message
<wendar> I tried several variations on that, with the same error
<ogra> definitely worth a bug
<wendar> which ticket queue should I stick it in?
<wendar> and, do you want any special arm tags?
<ogra> well, start with filing it against debian-installer
<ogra> attach syslog and partman.log
<ogra> armhf and raring tags should be fine (but not mandatory)
<wendar> will do. I may not have much success fetching the log files off the pandaboard, but I'll try
<wendar> ogra: and thanks :)
<ogra> welcome, thanks for reporting  :)
<infinity> ogra / wendar: I'm pretty tempted to drop the omap4 server images entirely, rather than fix bugs in them (assuming the bug is specific to that image, and not some larger systemic problem).
<wendar> infinity: how are the desktop images? are they getting daily testing?
<wendar> (omap4, that is)
<wendar> infinity: it is pretty handing for development to have working omap4 images, kind of silly to do a full desktop install on a pandaboard for low-level library packaging work
<wendar> infinity: where "silly" == hogs resources that are useful for package building
<ptl> hey, just want to thank the canonical team for the awesome progress on Ubuntu on ARM this week, I've seen the weekly summary for today and I am really amazed, you guys are doing a great job
<wendar> infinity: but, they could easily go back to being preinstalled images run off an SD card, rather than running debian-installer
<infinity> wendar: I just use the netboot images to install my Panda, rather than downloading a big server image.
<wendar> infinity: ENODOCS
<wendar> I think I might have been the last person to update https://wiki.ubuntu.com/ARM/OMAP
<wendar> infinity: I'm totally cool with altering the recommended practice for raring
<infinity> The netboot section could definitely do with a bit more verbosity.
<infinity> And, ideally, the whole wiki page could not suffer from living in the past.
<infinity> Like the references to natty netbook images...
<wendar> infinity: it's supposed to be updated with each release
<infinity> Well, ideally, we shouldn't need platform-specific install pages at all.  This is how things get out of date.
<wendar> infinity: except that OMAP has always been an unique little snowflake
<infinity> Little bit, yeah.
<wendar> infinity: with need of more information
<wendar> infinity: I volunteer my time to help, whatever needs to be done
<wendar> infinity: if it's dropping the armhf ubuntu-server images and updating the docs to match, that's cool
<infinity> wendar: Anyhow, boot.img-serial.gz (or boot.img-fb.gz, if you like monitors and keyboards) from ports/dists/$dist/main/installer-armhf/current/images/$platform should do the trick.
<infinity> Well, dropping the server images is orthoganal to documenting netboot a little bit better.
<infinity> I suspect most people would be so wildly excited to discover that they only need to download a 9MB image to install, mind you...
<infinity> Given that server is basically full CD sized, and full of things most people don't need.
<infinity> But I'm also an old skool UNIX type who thinks everything should boot/install via bootp/tftp, so my opinion may not be the norm.
<infinity> This all gets more interesting when we finally have a generic kernel (getting there), and I pretty much refuse to build a full desktop and server image for each one just to include a different bootloader.
<infinity> But spinning d-i netboot images for each subarch is simple, and quite doable.
<ogra> slangasek, as i said in the meeting, i see it at such a level as well right after boot (using htop to measure) but it drops then to about 360M
<ogra> (wrt the nexus7 ram usage)
<slangasek> ogra: how do you measure this?  Mine is consistently at 600M+ with the latest raring
<ogra> htop
<slangasek> oh, interestingly I just checked it again and now it's at 550M ;)
<ogra> i have it running via ssh
<ogra> right, it takes a bit but will go further down
<slangasek> why htop?
<ogra> dunno, i like the ease of use
<slangasek> 'free' shows me 553996 as 'used, -buffers'
<ogra> well, i like to have the processlist and htop is way more userfriendly than top
<slangasek> fair enough
<ogra> (and is usable by mouse and touch in a terminal)
<slangasek> I prefer to use the tools that are available in a stock install, provided they do the job :)
<slangasek> (which 'top' does not, it doesn't properly report "memory used for things that aren't disk cache")
<ogra> i'm happy to know hpow to use them if needed but i'm spoiled by bling and desktops :)
<ogra> colorful terminal apps are a good compromise ;)
<slangasek> ,
<slangasek> heh, what's 'luxd'?
<ogra> a shortcut from the ambient lightsensor to the lcd brightness
<ogra> jani works on implementing it in gnome-settings-daemon
<slangasek> ok
<ogra> so we can drop the script
<slangasek> does inotify work on /sys? :)
<ogra> acceld is going away too, g-s-d is nearly there
<slangasek> nice
<ogra> well
<ogra> its the same thing just in C ... still polling every sec
<slangasek> how about brcm_scaryhotpatch_daemon? :)
<slangasek> ah... less nice, then ;)
<ogra> i dont think inotify works on virtual fs@es
<slangasek> well, no reason that it would apply to all virtual fses, but I just checked and yeah, doesn't appear to work on /sys
<ogra> there were attempts to implement brcm_patchram in the kernel driver to load the firmware ... but i think they were turned down
<ogra> mathieu just packaged it and sanitized my upstart job ... it still needs some fixing (doesnt survive suspend)
<ogra> its a compromise, but makes the HW work
<slangasek> ok
#ubuntu-arm 2013-02-02
<ashes> hello
<ashes> i don't know ubuntu internals well. i'm running a custom kernel, to get samba support, on my trimslice. i want to blacklist kernel updates from apt-get upgrade, and i'll maintain it myself
<janimo> slangasek, since many sys values are only created on demand, inotify does not make sense on most part of sysfs
<janimo> as for /proc  I think
<Ethernin> ?
<virnik> hello, can I ask for help here? I run cheap ChipBox A10 laptop, 1GHz singlecore. I was searching any systemy which will be able to flash via installer to NAND. Now I have mele distro flashed... the problem is, it is headles, I have no lcd support. So is there any SD-bootable img of ubuntu around, able to flash itself to nand via installer, and set correct resolution?
<virnik> itÂ´s product name was SoftwinerEvbV13
<virnik> and there was Android ICS 4.0.3 installed
<ptl> I am sort of "collecting" ARm devices to play with. I already have Nexux 7 with Ubuntu, two CuBoxes, one UG802, one ODROID X2, one Minix Neo X5. Should I buy a Pandaboard or its time has passed?
<virnik> I think mine is Pandoraboard based...but I am new to Arm linux, except for android...but I am well oriented in linux on pc.
<virnik> is there any arm ubuntu NAND distro except for mele? mele works, but it does not lid screen on. I have cheap A10 Boxchip (SoftwinerEvbV13) laptop. Mele ubuntu distro is fine, it works even from NAND, but I can't find any other ubuntu image which will boot and install itself to NAND
<virnik> anyone?
<virnik> because with mele version of ubuntu, I have no screen
<virnik> anyone?
<ashes> i'm trying to upgrade xbmc from ppa:team-xbmc/ppa, and it's not happening. have any of you done this?
<ashes> i have dependency conflicts
#ubuntu-arm 2013-02-03
<ashes> i have a request for anonymous. root nvidia. publish source code
<XorA|FOSDEM> not much point in that :-D
<XorA|FOSDEM> Im going to bet nvidia drivers source looks like a bad perl program :-D
<infinity> Publishing the source would just open us all to lawsuits if anything even remotely looking like their code ends up in a free driver.  You don't want that.
<XorA|FOSDEM> infinity: good point
<XorA|FOSDEM> also the complete source of Windows was stolen by hackers and released and it made zero difference to projects like wine who couldnt touch the source
<infinity> For exactly the above reason.
<infinity> Right now, nouveau probably has some code that looks suspiciously like nvidia, only because there's sometimes only one obvious way to do something.
<infinity> But it's better not to know.
#ubuntu-arm 2014-01-29
<grant___> I'm getting USB buffer underruns on 3.4 which I have to stick with due to the old binary video drivers available for the Pandaboard. The buffer underruns disappear if the system is under load such as when compiling a kernel. I have CONFIG_CPU_FREQ=n, CONFIG_CPU_IDLE=n, and acpi=off. Where else should I look to fix this?
<lilstevie> grant___, do you get a stack trace or anything?
<grant___> lilstevie: I just get these: "ehci-omap.0: detected DataBufferErr"
<grant___> and audible gaps in music streaming via jackd over the ethernet interface which goes over USB
<lilstevie> grant___, I would probably file a bug against the kernel package :)
<grant___> it's fixed in newer kernels but I have to stick with the old one for video
<lilstevie> you could backport the fix
<grant___> lilstevie: how could I figure out where the fix is?
#ubuntu-arm 2014-01-31
<hvn> I have a question about debuild on Ubuntu 12.04 armhf....can someone tell me if there is a problem with dh_installdirs ?
<hvn> more info on my question: I'm using an ARMv7
#ubuntu-arm 2015-01-27
<Mr_Roboto> Hello everyone. I'm trying to install ubuntu Trusty on Beaglebone Black using the instructions on http://elinux.org/BeagleBoardUbuntu , but I can't figure out if I should use a demo image or a raw microSD image. What's the difference between the two?
<Mr_Roboto> No one?
#ubuntu-arm 2015-01-28
<suihkulokki> ogra_: since you fixed same bug on armhf, I take you fix it on arm64 too: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1415481 ;)
<ogra_> heh, yeah, makes sense
<infinity> suihkulokki: Fix uploaded to vivid.
<infinity> suihkulokki: Will do utopic and trusty after I wake up.
<suihkulokki> infinity: thanks
<suihkulokki> infinity: have a great cup of coffee :)
 * genii puts a fresh batch on
<infinity> It's going to take more than a pot of coffee.
 * genii sprinkles some irish whisky into it
#ubuntu-arm 2015-01-29
<infinity> suihkulokki: Guessing you're not still around?
<suihkulokki> infinity: indeed, but back up again
<at1as> hello all
#ubuntu-arm 2015-01-31
<suihkulokki> https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1416210 <- I take this is invalid as procps doesn't ship any of the mentioned initfiles?
<sabotender> greetings!
<sabotender> moo ð®
<sabotender> I am having issues with receiving a display when I connect to micro hdmi. Here is a link to my kern.log: http://paste.scsys.co.uk/461529
<sabotender> I was hoping that you would give me a few ideas of troubleshooting steps that I could try
#ubuntu-arm 2016-02-02
<odo2063> Hi folks!
#ubuntu-arm 2016-02-04
<caden> Hey, I need help setting up WiFi on Ubuntu MATE on a Raspberry Pi 2B.
<caden> Heloooooo anybody? I need somebody to help me!
<blahdeblah> Hi all.  Any Canonicalers see my mailing list thread about getting vanilla trusty or xenial running on a BeagleBone Black?
<blahdeblah> I've been looking through online doc and am finding it a bit confusing trying to work out the boot process and how I can get Ubuntu to boot from the onboard eMMC on the BBB.
<blahdeblah> Any tips?
<davmor2> blahdeblah: isn't there a snappy build for it?
<blahdeblah> davmor2: I want a full package archive at my disposal, hence standard Ubuntu Server is my preference.
<blahdeblah> Plus the only snappy image I could find is vivid, which is out of support shortly.
<davmor2> blahdeblah: snappy has a classic mode now that enables access to the archive
<blahdeblah> The recommendation on the mailing list was not to use that for general server use.
<blahdeblah> "While true, classic mode on snappy is not meant to be used in this manner. For example, if you install apache and reboot, it won't be started on boot. classic mode is currently only meant to give people a more comfortable environment in which to develop snaps."
<blahdeblah> ^ the exact recommendation
<davmor2> blahdeblah: out of my hands then I'm afraid not seen anything on the mailing list though
<blahdeblah> Anyway, the cloud archive was recommended for finding the images, I'm just trying to work out what I need to do to get it onto the eMMC to test.
<davmor2> but I'm not sure which mailing list you used either
<blahdeblah> canonical-tech
<blahdeblah> Is there a better one to ask on?
<ogra_> blahdeblah, just grab a an ubuntu-core tarball (not snappy, the original ubuntu-core)
<ogra_> https://wiki.ubuntu.com/Core
<blahdeblah> ogra_: That seems like a good choice in this case; any idea about what boot loader is required for beaglebone black?
#ubuntu-arm 2016-02-05
<ogra_> blahdeblah, theer should be debian based images for the beaglebone black ... grab one, write it to SD, fish /lib/modules and /lib/firmware out of the rootfs, format the rootfs partiton, unpack ubuntu core into it and copy the two dirs in place .... that should be enough to get you started
<blahdeblah> ogra_: Thanks - any idea about kernel?  Ubuntu core doesn't seem to come with one.
<ogra_> just use the debian one, that should be fine
<ogra_> (you can indeed also use an ubuntu kernel or even upgrade to one later, but setting up bootloader and kernel is much more complex than just replacing the rootfs)
#ubuntu-arm 2016-02-06
<tra_dax> hey guys, i made ubuntu 14.04 for my device, its  actually a .img file but when i run it i get the error as "chroot: can't be executed /bin/bash". can someone tell me how to sokve it??
<tra_dax> i have formatted ext2 sys
<zzarr> hello!
<zzarr> I have a asus chromebook flip and I have ubuntu on a sd card, it have a rk3288 soc, is there any instrucktions how I install the wifi device and drivers?
#ubuntu-arm 2017-01-31
<ernstp> are there any good instruction for using ubuntu arm with custom boards?
<ernstp> basically using Ubuntu instead of Yocto
<ernstp> and what happened to the Freescale part in this announcement, is that available anywhere? https://insights.ubuntu.com/2016/05/16/ubuntu-core-sees-the-light-on-nxpfreescale-i-mx-6-and-hikey/
<ernstp> multistrap?
#ubuntu-arm 2017-02-01
<hrw> elo
<wilsonfisk> Hello; quick question: does anyone know if hostapd supports the rt2800usb drivers in raspbian? Google says yes; but I'm getting 'Unrecognized/unsupported driver: rt2800usb', while lsusb and lsmod both display it. Any clues would be appreciated. Thanks :)  PS: the chipset is 'Ralink RT5572'.
#ubuntu-arm 2017-02-02
<ernstp> are there any good instruction for using ubuntu arm with custom boards?
<ernstp> basically using Ubuntu instead of Yocto
#ubuntu-arm 2020-01-28
<nlpqda> hello guys, anyone aware of ubuntu desktop for arm?
<nlpqda> please leave me an offline message if you have an answer .. thanks in advance
