#ubuntu-arm 2009-09-28
<lool> doko__: d-shlibs > are you sure ld-linux3-dev is the right thing to do?
<lool> doko__: Is it normal that all our binaries start getting linked to ld-linux when they didn't use to?
<lool> doko__: If you check jaunty, they weren't linked in this way
<ogra> sigh, d-i is missing a dep on parted for teh merged netboot image to work ... what made me assume its there by default ...
<ogra> i guess redboot-install should actually depend on it
<ogra> lool, btw, i'm sure you'll find improvements ... http://bazaar.launchpad.net/~ubuntu-mobile/redboot-tools/ubuntu/annotate/head%3A/redboot-cmdline/redboot-cmdline :)
<lool> I would have encoded the FIS directory offset instead of the config offset
<ogra> well, i want to have it detect the offset at some point
<ogra> but for a start using the default we use in our images seemed fine to me
<lool> We hardcode the config offset in our images?
<ogra> its just a start and does the job
<lool> Oh but we create it from scratch
<ogra> right
<ogra> redboot-install uses the same offset
<ogra> so as long as you use one of ouor images or used redboot-install, the default is fine ... if not you can use -o
<ogra> we'll needs something to change the cmdline once we switch debian-cd
<ogra> *need
<lool> I'd match on exec .* "" instead of ""
<ogra> because at the point wheer redboot-install will run the second partition wont exist, so wee dont have the UUID
<lool> No set -e?
<ogra> bah, you always catch me on that :P
<lool> ogra: otherwise it looks good
<ogra> set -e added
<ogra> i'll upload it post beta ...
<ogra> together with the missing dep on parted ... sigh ...
<ogra> yay, casper with my serialtty option was just uploaded :)
<lool> ogra: BTW I did an install of Debian Lenny on my Thecus and it did setup a serial TTY
<lool> I think we should make sure we do that for imx51, dove, beagle etc.
<ogra> with d-i over serial ?
<ogra> i know d-i automatically does that if you used a serial tty initially
<ogra> but only then
<ogra> it doesnt do that if your install ran from tty0
<lool> ogra: Ah that might be
<lool> ogra: Well that kind of makes sense
<lool> We should check that works with our platforms too then
<lool> And we could reuse this logic in casper too I guess
<ogra> we do :)
<ogra> hmm, though ... well
<ogra> my current change sets up the device file in /etc/init in the live session only
<ogra> that needs additional stuff in ubiquity
 * ogra notes on whiteboard under the post beta items
<ogra> lool, hmm, though it might be a bit pointless to have such a feature in casper/ubiquity ... you wont be able to actually run ubiquity over serial
<ogra> the casper feature only helps for debugging from the livefs
<lool> ogra: Yes, but the test would be nice
<lool> Not needing any serialtty bit
<ogra> what kind of test ? if you set serialtty in casper *and* do a normal install ?
<ogra> i.e. have a working X session to run ubiquity
<lool> ogra: My understanding is that d-i checks cmdline or /dev/console for a serial tty; if we can copy that bit to setup a getty on serial console during casper, that would be nice
<lool> Would avoid needing any cmdline arg
<ogra> i'll look what d-i uses for that though i fear the logic to actually match all known serial tty devices might become quite complex
<ogra> casper would have to copy that
<ogra> i always fear to slow down casper through adding any additional checks
<ogra> lool, hmm, the serial console detection in rootskel (which i think is what d-i uses) is quite complex, involving .c tools to actually detect the console type
<ogra> it actually seems to use http://paste.ubuntu.com/280299/
<ogra> oh, there is an easier way i gues
<ogra> s
<ogra> heh, i see other code that definately wont work with imx51
<ogra> using "readlink /proc/self/fd/0"
<ogra> ha ...
<ogra> case $(readlink /proc/self/fd/0) in
<ogra>     /dev/console|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*)
<ogra>     ...
<ogra>     ;;
<ogra> esac
<ogra> that works
<ogra> lool, so the above is what d-i seems to use ^^^ should i switch the casper code to it ?
<ogra> ogra@babbage2:~$ readlink /proc/self/fd/0
<ogra> /dev/ttymxc0
<ogra> my issue with it is that it will be run every time if there is no cmdline option while my current code just skips if /proc/cmdline doesnt contain serialtty=
<ogra> i.e. it'll slow down all arches
<lool> ogra: the above code needs patching
<lool> To allow ttymxc0
<lool> ogra: I think your code is just as expensive to run as the above
<ogra> ogra@babbage2:~$ case $(readlink /proc/self/fd/0) in
<ogra> >     /dev/console|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*)
<ogra> > TERM_TYPE=serial
<ogra> >     ;;
<ogra> > esac
<ogra> ogra@babbage2:~$ echo $TERM_TYPE
<ogra> serial
<ogra> no patching needed
<lool> Is it /dev/console?
<ogra> i dont get why though, i thought the same until i tested
<ogra> nope
<ogra> <ogra> ogra@babbage2:~$ readlink /proc/self/fd/0
<ogra> <ogra> /dev/ttymxc0
<ogra> its weird that it matches
<lool> Odd, I was sure it was case sensitive
<ogra> yes
<ogra> me too
<lool> case FOO in foo) echo yes ;; esac doesn't match
<ogra> http://paste.ubuntu.com/280321/
<ogra> thats the full code
<lool> case /dev/ttymxc0 in /dev/console|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*) echo yes;; esac => nothing
<ogra> using it on my babbage serial console clearly sets TERM_TYPE=serial
<lool> I dont have a serial console hooked up right now
<ogra> ogra@babbage2:~$ TERM_TYPE=""
<ogra> ogra@babbage2:~$ if [ -z "$TERM_TYPE" ]; then
<ogra> >     case $(readlink /proc/self/fd/0) in
<ogra> >         /dev/console|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*)
<ogra> >         TERM_TYPE=serial
<ogra> >         ;;
<ogra> >         /dev/tty*)
<ogra> >         TERM_TYPE=virtual
<ogra> >         TERM_FRAMEBUFFER_TRY=yes
<ogra> >         ;;
<ogra> >         /dev/pts/*)
<ogra> >         TERM_TYPE=pts
<ogra> >         ;;
<ogra> >     esac
<ogra> > fi
<ogra> ogra@babbage2:~$ echo $TERM_TYPE
<ogra> serial
<doko__> lool: d-devshlibs is only used to check for missing build dependencies. we know that the dynamic linker is in libc6-dev, so I assume it's safe to remove that. Didn't dig up why it shows up in the first place
<lool> doko__: Yes, that's the basic question I have
<ogra> should we push that to debian ?
<lool> doko__: I agree with you about the change to workaround the effects of our binutils though
<ogra> given that mojo had the same prob ages ago
<doko__> i filed a bug report
 * ogra suspects it makes sense to have it upstream
<ogra> cool
<doko__> lool: hmm, I don't see the connection yet (binutils/d-shlibs)
<lool> doko__: binaries from jaunty didn't have this odd NEEDED entry
<lool> doko__: Which is only present on armel since karmic
<lool> doko__: So it seems suspicious
<doko__> lool: is there a bug report about this?
<lool> I don't remember
<lool> ogra: Do you remember?
 * lool greps ogs
<lool> logs
<lool> doko__: http://paste.ubuntu.com/280331/
<lool> doko__: Conclusion was to consult you   :-)
<lool> doko__: http://paste.ubuntu.com/280333/
<ogra> lool, i dont think there was a bug
<ogra> (sorry was at lunch )
<lool> ogra: You dont think there was a bug where?
<ogra> anywhere :)
<ogra> i didnt file one
<lool> ogra: So why isn't it a bug?
<ogra> ??
<ogra> i dont say its not a bug
<lool> ogra: Sorry misunderstood you
<ogra> :)
<NCommander> lool, ogra, just a note: my change to d-i fixes alternate images on armel in general (we weren't including fat-modules so no alternate CDs are working. I also know theres an optoin that has to be set on the kernel command line to get debian_installer/try-usb set so d-i will work, would either of you know off the top of your head which option that is?
<lool> NCommander: I know, I added the fat-modules to imx51 but they were not built at all in dove
<NCommander> lool, oh, strange, I didn't see it when I pulled the branch the other day. I must have just missed your commit :-/
<ogra> probably fat is in the kernel there ?
<ogra> did anyone check ?
<NCommander> ogra, its all modules on dove, I didn't check imx51
<lool> NCommander: http://bugs.launchpad.net/bugs/431945
<ubot4> Launchpad bug 431945 in linux-mvl-dove "Lacks a bunch of modules for d-i support" [Undecided,Fix released]
<lool> NCommander: You didn't see build/pkg-lists/cdrom/armel/imx51.cfg?
<lool> ogra: I checked yes
<lool> NCommander: You also want keyboard modules if any
<NCommander> lool, no, i added mine to the generic arm.cfg file. I didn't even see the imx51.cfg one :-/
<ogra> NCommander, err
<ogra> NCommander, you are aware that our arch isnt arm, right ?
<NCommander> ogra, arm is symlink to armel
<NCommander> (in d-i for the pkg-lists)
<lool> ogra: haha second time you're hit by this
<ogra> heh
<lool> ogra, NCommander: Anything you need in d-i before I upload it?
<NCommander> lool, just fat-modules/input-modules for d-i on armel. I can't think of any other changes I need off the top of my head (or that I had to make to get d-i do something :-))
<ogra> a redboot-imx51-babbage dep would be nice
<lool> bdep?
<ogra> yep
 * NCommander needs to get out of his apartment
<ogra> redboot-install doesnt find reboot and fconfig.bin otherwise
<ogra> hmm
<lool> ogra: So the build fails because of that?
<ogra> now i'm pondering a redboot-tools upload
<lool> ogra: Can you please fix it in bzr then?
<ogra> nope
<ogra> redboot-install exists but doesnt make the build fail
<lool> ogra: I personally think it makes more sense for redboot-tools to not depend on it; if it's the default you could add a Recommends though
<ogra> on what ?
<lool> We have the case on antimony that we dont want to install redboot-imx
<lool> But we want the tools
<lool> ogra: s/exists/exits/?
<ogra> redboot-tools doesnt depend on redboot-imx
<ogra> and will never do
<ogra> but d-i needs to
<ogra> for the merged sd netboot image
<ogra> exits, yes
<lool> ogra: Did you add the image yet?
<ogra> d-i needs to b-d on it so redboot-install finds the bianry during its armel build
<ogra> yes, but its empty
<ogra> due to redboot-install a) not having parted available (missing dep in redboot-tools i added today, but after redboot-cmdline which is why i considered to keep the upload until after beta) and b) not having the redboot binary file
<ogra> b) should be solved by the build dep
<ogra> (of d-i on redboot-imx51-babbage)
<ogra> (on [armel])
<lool> Is redboot-tools uploaded with the parted dep?
<ogra> no, thats what i said above
<lool> ogra: Feel free to commit the relevant bdeps to d-i right now
<lool> I'll pull the changes
<ogra> it would bring in redboot-cmdline too and i didnt want to upload new code before beta
<lool> ogra: Well then that needs to happen now or we need to disable your netboot image
<ogra> hrm, ok, then i'll do an upload
<ogra> i thought the release managers are busy enough
<lool> ogra: Well either do an upload of redboot-tools or disable the netboot image
<lool> ogra: I can do the later if you like
<ogra> nope, i'll upload redboot-tools
<ogra> gimme a sec for the di push
<ogra> do you prefer a versioned dep here too ?
<ogra> (you wanted me to do one for redboot-tools)
<lool> Yes
<ogra> lool, ok, i didnt add a changelog entry, change pushed though
<ogra> err, yes ?
<ogra> meh
<ogra> could you add that ?
<ogra> 200933-0ubuntu1 is the current redboot version
<ogra> awew, CIA bot is evil, it reacts to local commits even if i didnt push
<lool> ogra: I would have preferred for you to upload redboot-tools then update d-i but well
<ogra> r-t is up
 * NCommander is back
<lool> NCommander: Can you please revert the flash-kernel bits to use flash-kernel for UUID instead of the initramfs hook?
<lool> NCommander: cjwatson commented last week that this was probably not very stable to use
<lool> NCommander: I thought you got these bits from #ubuntu-installer
<lool> NCommander: (sorry if you missed them   :-/)
<NCommander> lool, oh, I see
<NCommander> lool, sure, let me fix that
<armin76> NCommander: fix gcc
<NCommander> armin76, on SPARC?
<NCommander> armin76, or ARM?
<NCommander> (and how is it broken on ARM if thats the case)
<armin76> NCommander: arm
<NCommander> armin76, how is it broken?
<armin76> http://bugs.gentoo.org/show_bug.cgi?id=286251
<ubot4> bugs.gentoo.org bug 286251 in Core system "sys-devel/gcc-4.4.1 fails to rebuild itself on ARM" [Normal,New]
<armin76> nice bot
<armin76> NCommander: probably you aren't going to hit it, its probably due to our make line
<NCommander> armin76, I don't really have the time to look at Gentoo bugs :-/
<armin76> make LDFLAGS=-Wl,-O1 STAGE1_CFLAGS=-O LIBPATH=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.1 'BOOT_CFLAGS= -march=armv5te -pipe -O2' bootstrap-lean
<armin76> NCommander: heh, it was just fyi
 * NCommander feels like eyes burn
<armin76> NCommander: do you have a babbage as well, right?
<NCommander> armin76, just a Babbage 1, my imx 2.0 is in London  ATM
<armin76> NCommander: gimme!
<NCommander> armin76, I don't think you want a B1 :-P
<armin76> why not?
<NCommander> armin76, USB isn't very stable on it which means your more or less limited to SD cards
<armin76> SDHC?
<NCommander> armin76, nope
<NCommander> (or at least, no SDHC card that I had worked, it was very picky)
<armin76> gimme!
<armin76> nfs++
<NCommander> lool, I'm SO lost on what you want me to do with respect to the UUID its not funny (I just read the logs). Do you want me to keep the current behavior with the UUID then?
<lool> NCommander: Sorry, let me send you the relevant logs
<lool> ogra: pushed d-i
<lool> NCommander: I only included input-modules (+fat on cdrom)
<lool> NCommander: I didn't test the z0 stuff; not sure it's picked up -- likely not
<lool> But then I don't think we will care much longer about it
 * NCommander nods
<lool> NCommander: http://paste.ubuntu.com/280589/
<lool> NCommander: I did try to ping you on it; I guess I should have updated the bug
<lool> NCommander: That was on #ubuntu-installer on 20090924 BTW
<NCommander> lool, I probably missed it since my IRC proxy machine had to be restarted and I forgot to dump logs into my client before restarting it
<NCommander> ok, so old behavior it is
<lool> NCommander: I uploaded d-i now; I will consider updating your flash-kernel tomorrow along d-i and ubiquity if cjwatson is ok with that
 * NCommander has the branch ready as soon as I test it
<Martyn> Re
<Martyn> UEFI is ... neat.
<Martyn> A bit full of fail at the moment, but that's because it's seriously alpha on ARM
<lool> Martyn: Which UEFI impl are you looking at?
<Martyn> apples
<Martyn> We have the source and are working on getting it working and compiling.
<Martyn> We also hired a new person whose only job is to work on the bootloader now.
<Martyn> So, I have high expectations :)
<lool> Martyn: Is Apple's open?
<Martyn> it is
<lool> Martyn: Interesting; URL?
<Martyn> They open sourced it two weeks ago (well, it's been open source, but they released it)
<Martyn> lool : no idea.  We got it via sneakernet
<Martyn> on nothing less than a usb key
<lool> What's sneakernet?
<Martyn> lool : Put on a pair of sneakers .. then walk?
<Martyn> lool : Yep, this is something that I think Ubuntu is moving to.
<Martyn> lool : I'll be putting together a blueprint, and getting something ready to present at the ubuntu meetup @Dallas
<Martyn> url is edk2.tianocore.org
<lool> Martyn: excellent
<neonfreon> speak up if you make any progress with it! =)
<NCommander> OOOOOOOOH
 * NCommander can't believe Apple opened their EFI core
<NCommander> its based off Intel's EFI reference implementation but with a ****ton of tweaks for OS X
<NCommander> (like FAT binary support and Mach-O support)
<NCommander> Martyn, what SoC are you working against?
<Martyn> Hey al.
<Martyn> lool : awake?
#ubuntu-arm 2009-09-29
<ogra> lool, so d-i on vfat wont work ... :(
<ogra> unless we add some hack ...
<ogra> lool, d-i relies on the link /cdrom/dists/stable pointing to /cdrom/dists/karmic .... vfat doesnt support symlinks so we end up without "stable" in that dir ...
<ogra> cd'ing to /cdrom/dists and mv karmic stable makes it work though
<ogra> amitk_, the NIC driver still doesnt work (at least in d-i) while i have eth0 it cant get any IP data via dhcp, setting the IP manually doesnt work either it seems
<ogra> hrm, k, now it fails in debootstrap "failed to determine the codename of the release" i guess thats additional fallout of the vfat symlink prob
<ogra> lool, i think we should consider ext2/3 for the alternate images
<ogra> NCommander, ^^^
<ogra> you will likely run into the same issue on dove
<amitk_> ogra: we did apt-get dist-upgrade with the nic at the sprint
<ogra> well, i dont get any data through it
<amitk_> ogra: the driver is compiled-in. So I am not sure why it doesn't work in d-i
<ogra> behaves the same as with the FEC2 driver
<amitk_> where are you seeing FEC2? I removed that...
<rabeeh> NCommander: ping
<ogra> amitk_, i see FEC1, i say it behaves identically to how FEC2 did
<ogra> driver is loaded, no data gets through
<amitk_> what kernel are you using?
<ogra> amitk_, -102
<amitk_> ogra: could you try if -101.9 works?
<amitk_> https://edge.launchpad.net/ubuntu/+source/linux-fsl-imx51/2.6.31-101.9/+build/1258067
<ogra> no, i would have to rebuild d-i
<ogra> i'll see if it works with the live image, probably something is missing
<lool> ogra: Well we could keep the vfat for uboot and move the d-i stuff to a new part
<ogra> uboot ?
<ogra> oh, on dove, yes, indeed
 * ogra is testing imx51
 * lool tries to recall why we have a fat on imx51
<lool> Probably because that's the only non-ISO format we supported in cdimage/debian-cd
<ogra> yeah
<ogra> sigh, usplash without progress is bitter with casper on arm
<ogra> they could at least have kept the bouncing bar
<ogra> amitk_, FEC doesnt work in the live session either
<ogra> i see eth0 but NM doesnt
<amitk_> ogra: 'ifconfig eth0 <ip> up' works?
<amitk_> besides, screw NM
<ogra> ifconfig eth0 up && dhclient eth0 works
<ogra> so at least the driver does it ...
<ogra> but still, NM has to work
<amitk_> ogra: ok. So we need to figure out what NM needs
<ogra> it doesnt see the interface at all it seems
<ogra> and the interface doesnt come up on its own either
<ogra> ifconfig eth0 up shouldnt be needed
<ogra> lool, oo.o bug still persists
<ogra> :(((((
<lool> ogra: crap
<lool> doko_: ^
<ogra> heh, it still builds
<ogra> ignore me
<lool> ogra: tss
<lool> doko_: cancel ping :)
<lool> LoÃ¯c Minier would like to recall the message "doko_: ^"
<ogra> Started 2009-09-27
<ogra> hmm, should soon be done though
<doko_> ogra: be patient ...
<amitk_> ogra: ofcourse ifconfig eth0 up should be needed. Otherwise the chip will consume power unecessaryily. But it could be that the driver isn't sending the right udev events, or N-M isn't reading them
<amitk_> *unnecessarily
<ogra> babbage live install succeeded
<ogra> amitk_, so can we make FEC spit out a "DRIVER" udev property ?
<ogra> ogra@babbage2:~$ udevadm info --query=all --path=/devices/virtual/net/eth0
<ogra> P: /devices/virtual/net/eth0
<ogra> E: UDEV_LOG=3
<ogra> E: DEVPATH=/devices/virtual/net/eth0
<ogra> E: INTERFACE=eth0
<ogra> E: IFINDEX=2
<ogra> E: SUBSYSTEM=net
<ogra> NM looks for DRIVER here
<amitk_> ogra: I guess we can, can I have a bug please to submit the fix against?
<ogra> sure, still collecting my issues here :)
<amitk_> heh
<ogra> amitk_, one other thing i'd like to see is that we quieten down the kernel a bit on imx51
<ogra> i have a lot of noise when it inits devices on startup
<amitk_> ok
<ogra> mainly fb devices
<ogra> but also some others
<amitk_> must be debug statements in the driver...
<amitk_> although, do we care when usplash works?
<ogra> not sure we will decide to use it
<ogra> so i want the kernel to be as quiet as the others
<ogra> amitk_, http://paste.ubuntu.com/281234/
<ogra> thats the parts i'd like to vanish
<amitk_> hmm..ok
<lool> amitk_, ogra: Perhaps this should be tracked in a bug report
<ogra> lool, as i said above, still collecting my issues here
<ogra> i'll file a bunch of bugs soon
<amitk_> lool: yeah. I'm not touching anything w/o bugs anymore. release manager will grab my neck otherwise.
<lool> ogra: You could start with filing a bug for the output you pasted?
 * ogra sighs
<lool> ogra: Please don't file a bunch of bugs for each line though, unless that's what amitk_ wants
<ogra> can i finish first please
<lool> ogra: Well I thought you were done since you said 13:58 < ogra> thats the parts i'd like to vanish
<lool> ogra: Sure, finish your research if you like
<lool> .c
<amitk_> lool: I'll leave it to ogra's discretion
<ogra> i'm just starting with .1
<ogra> no ttys :/
<ogra> sigh, so many bugs
<ogra> why is LP so slow
<amitk_> ogra: what a silly question?
<ogra> heh
 * amitk_ wonders if apt-get dist-upgrade works on the babbage
<ogra> use update-manager :)
<amitk_> no UI, only serial port
<amitk_> what fixes does update-manager add?
<ogra> it cares for handling config files, package removals and replacements etc
<ogra> dist-upgrade might leave you with a different system than u-m
<amitk_> ubuntu@karmic-arm:~$ apt-cache policy linux-image-imx51
<amitk_> linux-image-imx51: Installed: (none) Candidate: 2.6.31.101.2
<ogra> it should work though but you might have to handle some fallout
<amitk_> does the kernel upgrade work too?
<amitk_> since there doesn't seem to be a kernel package installed here...
<ogra> it did for 100 to 101 for me
<ogra> for 102 i already did a reinstall since i need to test images
<ogra> apt-get install linux-imx51 :)
<amitk_> do you know why apt-cache policy says I don't have that package installed?
<ogra> does dpkg -l agree ?
<amitk_> No packages found matching...
<ogra> well, you used redboot-install and rootstock i assume
<ogra> rootstock explicitly omits kernel installation
<amitk_> aah
<ogra> if you install it, make sure you have a flash-kernel.conf and kernel-img.conf file
<ogra> and install flash-kernel and redboot-tools
<amitk_> ogra: sample flash-kernel.conf and kernel-img.conf files?
<ogra> amitk_, https://wiki.ubuntu.com/ARM/BabbageImageFromScratch
<ogra> lool, my serialtty hack does nothing :(
 * ogra will try the rootskel code post beta for it
<ogra> what bothers me is that it doesnt even get into the case statement apparently
<lool> ogra: You forgot +x
<lool> ogra: pushed
<ogra> lool, i forgot more
 * ogra bangs some nails into the wall with his forehead
<ogra> GOD !
<ogra> lool, its not installed :P
<daniel_ki> the one situation where a hammer would have been the right tool :)
<ogra> nope :)
<ogra> i deserve the pain :)
<ogra> (and i dont even need the nails :) )
<daniel_ki> it depends on whether you are masochistic, because if you are, you do not deserve it :)
<ogra> hmm, i dont get why it isnt installed though
<ogra> there is no reason its missing
<ogra> hmm, buildlog says it should be there too ...
<ogra> -rw-r--r-- root/root       568 2009-09-28 10:45 ./usr/share/initramfs-tools/scripts/casper-bottom/22serialtty
 * ogra doesnt get it
<lool> ogra: 16:19 < lool> ogra: You forgot +x
<ogra> lool, yes, i was a bit stupid not finding it on disk
<ogra> /usr/share/initramfs-tools/scripts/casper-bottom/<tab><tab> != ls /usr/share/initramfs-tools/scripts/casper-bottom/
<ogra> :P
 * ogra should retire
<amitk_> ogra: are you the one that broke my serial console on dist-upgrade?
<ogra> nope
<ogra> that was very likely Keybuk
 * amitk_ puts back the stick
<ogra> the casper hack above should actually give you a serial tty in a live session if you set it
<ogra> doesnt touch installed systems
<lool> amitk_: jaunty -> karmic?
<amitk_> lool: no, karmic rootstock image and then dist-upgrade
#ubuntu-arm 2009-09-30
<tlee> I keep getting these error in the latest karmic release for arm: gconftool-2: relocation error: /lib/libglib-2.0.so.0: symbol __abort_msg, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
<tlee> Has anyone else seen this?
<rabeeh> tlee: i already reported similar issue the team. did this happen after 'apt-get upgrade' ?
<rabeeh> oh just noticed tony already left :)
<ogra> yeah
<lool> rabeeh: You have a bug for it?
<lool> rabeeh: We really dont know how that's possible and would appreciate a bug for it
<lool> rabeeh: ubuntu-bug /usr/bin/gconftool-2
<lool> rabeeh: explain in the report how you're reproducing step by step
#ubuntu-arm 2009-10-01
<ogra> lool, do we know which packages would have to be recompiled ?
<ogra> "Then
<ogra>  we would like to look at rebuilding affected binaries.
<ogra> "
<ogra> not a very detailed list :)
<ogra> lool, imho we shouldnt tinker with something like that this late in the cycle
<ogra> we have a workaround for oo.o and i dont think we saw other fallout yet
<NCommander> ogra, I dunno, I've seen quite a bit of instability in karmic verus jaunty. gnome and firefox especially
<ogra> i dont
<lool> ogra: As I note, I'm working on building the list
<ogra> yes
<NCommander> ogra, its possible its dove related
<ogra> i wasnt following #mobile since you asked to have all conversation here :P
<ogra> amitk_, poke
<ogra> amitk_, in drivers/video/mxc/mxc_ipuv3_fb.c there is a line "static unsigned long default_bpp = 16;", can you change that to 24 with the next upload ?
 * amitk_ pokes ogra with a spear
<ogra> ouch
 * ogra tapes the hole in his belly
<amitk_> ogra: colors not looking good?
<lool> Yup
<ogra> amitk_, well, depends ... http://launchpadlibrarian.net/32366612/dsc_3982.jpg
<lool> ogra: Do we have a bug for this?
<lool> ogra: The xsplash bug would be fine
<ogra> not for the driver
<lool> Add a task with linux-fsl-imx51
<ogra> no it wouldnt
<ogra> i'll add a new one
<lool> Ok your call, please file a new bug then
<ogra> the xsplash bug affects other arches apparently
<ogra> ah, and you said 32, i see the driver actually has a 32bpp stting
<ogra> no idea why it isnt picked up from cmdline ... i guess it needs a special format once again
<amitk_> ogra: that is default_bpp. Can't the Xserver request another bpp?
 * ogra sighs about that driver
<ogra> amitk_, the xserver is fbdev :)
<ogra> we dont have a real xserver yet
<ogra> and the fbdev only uses the settings it has on kernel startup
<amitk_> right, can't you request it on cmdline?
<ogra> so we either re-add the video option to alkl default cmdlines which we dont want or just make the driver do the right thing
<amitk_> ogra: just curious why you don't want it in the cmdline? Since it has the same effect - of imposing 24bpp policy on the users
<amitk_> and that (policy) is better handled outside the kernel
<Martyn> ogra : OOoo... looks pretty
<Martyn> not anything like it's supposed to .. but very pretty :)
<ogra> amitk_, because that means to use a hack
<Martyn> ogra : Is there not a 16 bit version of the xsplash?
<ogra> amitk_, if the driver doesnt dtrt i'm not really hot on hacking around that in ten different places
<amitk_> yeah, I kinda like the 16bpp look ;)
<ogra> ah, thats why you dont want to change it
<amitk_> ogra: ok, fire a bug at me and thou shall have it. (And you get to pick up the broken pieces if it explodes after the change) :)
<ogra> i'll do a testbuild over night :P
<amitk_> I still think it should be on the cmdline so that we can fix it easily incase other stuff blows up
<ogra> then a lot of scripts need to be changed
<Martyn> speaking of broken testbuilds ... I'm going to need some guidance on the right way to make the PBX-A9 PPA
<ogra> if anything blows up because your monitor doesnt do 32bpp, you can change your cmdline as easily
<lool> NCommander: I get a shitload of output when booting an installed dove y1; could you open a bug to get the kernel printks and other bits quieten down to info messages instead of warnings or something?
<lool> NCommander: there's a bug for this on imx51 already
#ubuntu-arm 2009-10-04
<kblin> hm, durn. it would've been too easy to expect that blog post on building kernels to just work
<hamannp> Build a rootfs from scratch
<hamannp> ??
<Martyn> yep
<Martyn> you need help?
<hamannp> Yeah. I get a bunch of nasty errors.  I can't get networking.
<Martyn> Ick
<Martyn> there are some better ways to get a rootfs now
<Martyn> you can strip one out of the dove or i.mx51 image
<hamannp> Ok.  Leta dmit something: I don't know what I'm doing.  Can I explain what I want to do?
<hamannp> hello?
<armin76> lol
<armin76> explain, explain :)
<hamannp> Ok.
<hamannp> I have a sheeva plug kit. I put it on my network, and put a full app stack on it. I have the same app arch scaled horizontally on Ubuntu amd64 VMs.  I thought to myself, it would be cool to emulate some arm vms, and reproduce the horizontal architecture on Arm.  Follow me?
<armin76> hrm...
<armin76> emulate arm on arm?
<hamannp> Nope.  I'll keep explaining.  So I have a home Lan network. It has a bunch of old Pcs, this Sheeva kit, and a bunch of VMs.  It's behind a router from my Cable provider.   The VMs connect to this lan through a static bridge network on a Host.  br0.  I want to emulate 6 or 7 arms on qemu so that I can try out a deployment arch that I already have on amd64 vms.  Make sense?
<armin76> so you want to emulate arm :D
<hamannp> Yes! And use my existing static br0 with multiple emulated arms with static ips.
<hamannp> I'm stuck getting even one built cleanly.  I also can't get it on my bridge NW, even when I copy over configs from my exisitng amd64 vms.
<armin76> can't help on that, sorry
<hamannp> How bout a tut on getting even one built?  I tried the main wiki, and I get nasty errors.  I can pro'lly figure out the networking.  I think the problem is that I can't build it without errors.
<hamannp> BTW, the wiki links to an old kernel.  The bug report says that some of the errors I got have been fixed.  IS there a magic vault of up to date ARM kernels and img's somewhere?
<armin76> no clue, you should ask ogra or lool
<hamannp> ok thanks!
<Martyn> armin76:  To whom should I address the request to have a smooth-stone PPA for karmic?
<Martyn> I have a working dist now for our in-house work
<Martyn> it runs on the pbx-a9
<armin76> woot
<armin76> Martyn: why you ask me? :P i don't have anything to do with ubuntu :)
<armin76> but same answer as hamannp :D
<Martyn> LOL
<Martyn> because you hang here, and just might have picked up the info
<Martyn> <-- not canonical either, right :)
<Martyn> armin76 : You're an amazing font of information sometimes
<armin76> :D
<NCommander> Martyn, I had talked with lool earlier today on how we could do "universal" armel images for SoCs that used u-boot as a bootloader
<NCommander> (basically, an extension of the boot.scr functionality I created)
<NCommander> Martyn, but I need a per-soc identifier to make it work, and the MACH_ID is probably the best way to it (with a way for us to override it if necessary ;-))
<Martyn> I think so too
<NCommander> Martyn, hence why I'm talking to wdenk on this
<Martyn> yep yep
<Martyn> I don't know why there is this huge push against non devtree solutions
<NCommander> Martyn, I'll be first to admit our universal image idea is a hack, but its better than the alternative
<Martyn> yes
<Martyn> I really, REALLY want a universal UEFI loader
<NCommander> Martyn, because most people look at i386, and see how braindead it is
<NCommander> Martyn, +1.
<Martyn> for more reasons that one, but I'll -take- a u-boot loaders that works
<NCommander> Martyn, but even if it exists, there will be a ton of inheta before its standard, and we still have legacy stuff to deal with
<Martyn> NCommander : New topic for a second
<Martyn> I have a fullly working image for 9.10 beta on PBX-a9 now
<NCommander> Martyn, I dunno if I should be happy or scared
<Martyn> what and to whom do I need to propose something to in order to get an install img for the platform?
<Martyn> like the dove, and the i.mx51 have now
<NCommander> Martyn, what bootloader?
<Martyn> u-boot
<Martyn> + ARM monitor
<Martyn> well, other way around
<Martyn> ARM monitor + u-boot
<lool> NCommander: To be fair the boot.scr concept comes from beagleboard
<lool> That's where I got the idea and told you about it
<NCommander> lool, true, although boot.scr is quite a bit more advanced than the beagle boot system
<lool> It uses loops but it's the same concept
<lool> anyway
<kblin> crap
<kblin> I think my sheevaplug just died
<kblin> so much for that piece of hardware
<hamannp> Ok.  I've been trying for days to get a working ARM image with networking based on the tutorial.  My last idea is to burn it to cd and boot from that.  Anyone know where I can get an .iso version?
<ali1234> hamannp: what tutorial? what hardware are you using?
<hamannp> I've got an amd64 desktop with 4GB of RAM.  I want to emulate a couple of ARM machines on my desktop.  Here's the basic tut https://wiki.ubuntu.com/ARM/RootfsFromScratch
<ali1234> so qemu then...
<hamannp> Yes, sorry.
<ali1234> ok, so at what point does it deviate from what you expect?
<hamannp> When I boot up, I get at least 4 errors.  I about "file system Fusectl not supported" and another about /lib/modules not existing.  I get another about  this bug : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/346378
<ubot4> Launchpad bug 346378 in linux "net.ipv4.tcp_syncookies is a unknown key (CONFIG_SYN_COOKIES=y missing in ARMEL build config)" [Low,Fix released]
<ali1234> ok, well those shouldn't be fatal
<hamannp> That's good to know.  I'm trying to add them to my existing bridge network.  br0.  When I copy the settings from my amd64 VMs that use that network, I still don't get networking.  I thought may be I should fix the boot erros first.
<ali1234> well you can fix those by recompiling the kernel with support for those things it is complaining about
<hamannp> I have been able to log in.  May be the machines are working, and the networking problem is something else.
<ali1234> i had some problems with networking btw
<ali1234> something to do with dns - it just wouldn't work. but specifying ips did
<hamannp> I'm using ips
<hamannp> Would any of those problems effect networking?
<ali1234> i don't think so
<ali1234> they didn't for me, but i'm using real hardware
<hamannp> Ok.  Then I wonder to what to check next. Like I said, I copied over settings from other VMs that use the network fine.
<ali1234> qemu VMs?
<hamannp> I built them using the python.vmbuilder
<hamannp> FWIW, I have on Sheeva dev kit on my network with the same settings as my other VMs
<ali1234> i don't really know what you mean by that
<hamannp> Sorry kvm.
<ali1234> i think you have to configure the bridge on the host machine too
<ali1234> the vmbuilder probably does that for you
<ali1234> but i don't know because i don't use qemu/kvm
<hamannp> I've had the host bridge working for 6 months.  I have it setup for kvm to automatically add a static ip and configuration for the  host bridge network. The hoist side is good.
<ali1234> kvm isn't the same thing as qemu-arm
<ali1234> so do you see the interfaces on the brctl?
<hamannp> Yes.  Shouldn't it use the same unix networking?  Is there something different?
<hamannp> I don't fully follow you.  I setup br0 for static ips in my /etc/network/interfaces file and bring it up automatically.  If I do an ifconfig on the host, it shows up.
<ali1234> brctl show
<ali1234> that will list the interfaces that are part of the bridge
<hamannp> yes, it shows eth0, which is right.
<hamannp> it also shows vnet0, not sure what that is. May be default network for kvm????
<ali1234> probably
<hamannp> Huh.  I'm stumped.
<ali1234> each virtual machine has it's virtual nic, which has endpoints on both the guest and the host
<hamannp> Yes.
<ali1234> on the host you have to bridge them all together, and with the real eth0
<ali1234> you say you have kvm doing this for you
<ali1234> but qemu-arm does not use kvm
<hamannp> I edited each guest /etc/network/interfaces.  Although I've now got it setup so that when I run the build script, it edits them automagically.
<ali1234> sure. you you have to configure it in the host too
<hamannp> I edited the qemu /etc/network/interfaces file manually to have the same settings as the kvm VMs that use the bridge.
<ali1234> great
<ali1234> that's correct
<ali1234> so, which vms are currently running right now on your host?
<hamannp> I've got a couple of kvm vms running using br0 just fine.  I've got a qemu ARM with the same settings, which isn't able to reach the network
<ali1234> and all are up and running?
<ali1234> what interfaces do you see on ifconfig -a
<hamannp> Hold on.  I'll check.
<ali1234> look for tun0 or tap0 or similar
<hamannp> I don't see tun0 tap0.
<hamannp> I just see see eth0, vnet0, and br0 on the host
<ali1234> how did you launch qemu?
<hamannp> Hold on.  I'll paste the command line.
<hamannp> qemu-system-arm -M versatilepb -kernel ./vmlinuz-2.6.28-11-versatile -hda qemu-armel-200910011752.img -m 256 -append "root=/dev/sda mem=256M ro" -net nic,macaddr=00:16:3e:00:00:01 -net tap
<hamannp> May be I see the problem
<hamannp> Should I have ended it with -net br0?
<ali1234> hmm i don't think so
<hamannp> Ok. stumped again ;)
<ali1234> hmm try modprobe tun
<ali1234> and then relaunch qemu
<hamannp> ok
<ali1234> this time you should get a tap0 or tun0 to add to br0, and then it should work i think
<hamannp> ok. It's booting the machine.
<hamannp> I get a tap0
<ali1234> the if should be up already
<hamannp> sorry?
<ali1234> the interface should get created as soon as qemu starts, i mean
<ali1234> the tap0 that is
<hamannp> ok
<hamannp> It's there
<ali1234> so, now brctl addif br0 tap0
<hamannp> ok
<ali1234> now it should work :)
<hamannp> Ok.  I'll test here in just a second.
<hamannp> Btw, qemu boots sloooooooooow
<ali1234> well yeah, it's basically an emulator
<ali1234> unlike kvm which uses virtualization
<hamannp> Gotcha.
<hamannp> I might need to head to my local electronics store (Fry's) and pick up a dozen dev kits.
<ali1234> meh. cross compilers and what not...
<ali1234> qemu can still be faster than the real hardware sometimes
<hamannp> I've got the one Sheeva plug dev kit.  A little flakey, but fun to play with.
<ali1234> no such luck here, i'm hacking on my mobile phone :)
<hamannp> Have you seen the dual-core Marvell 1.2ghz?
<ali1234> i've heard about that stuff but never seen it
<hamannp> They can take 1GB ram/core
<hamannp> It works!  You're the man!  How do I get it to work next time?
<ali1234> um..... hang on
<ali1234> edit /etc/modules
<hamannp> host machine?
<ali1234> add a line with just tun on it, as per the instructions in the comments
<ali1234> yeah, on the host. assuming you use ubuntu
<hamannp> Of course I use Ubuntu!!!!!!!!!!!!!! All the time ;)
<ali1234> and you need to make a script to add the interface to the bridge like it shows on the tutorial
<hamannp> I think I can do that.
<hamannp> I should have it from this chat log.
<hamannp> Thank you!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<ali1234> the /etc/qemu-ifup thing
<ali1234> not sure how that works though
<hamannp> I can do it manually until I figure it our.
<hamannp> Thanks alot!  I'm gonna grab a beer and jump in the hot tub.  Literally.  You've made my day!
#ubuntu-arm 2010-10-04
<hrw> morning
<lag> robclark: Morning
<robclark> gm lag
<lag> Hey buddy, how are you?
<robclark> still a bit bleary eyed..  but coffee is starting to do it's job ;-)
<lag> Because it's Monday, or did you go out last night?
<robclark> no.. just a bit early still.. sun is only just starting to come up
<lag> Ah, okay
<lag> robclark: You're in Texas aren't you?
<robclark> yup
<lag> Is Bryan there with you?
<robclark> no one is here with me yet.. but I think some will be here later in the morning (although not sure who all)
<lag> I'm assuming he'll have access to IRC when he arrives?
<robclark> Hmm.. I assume we can work something out..
<lag> Excellent :)
<ogra_ac> lag, bryan is here already we'll meet in 40min for breakfast
<robclark> gm ogra_ac
<ogra_ac> hey rob :)
<lag> ogra_ac: Good stuff
<lag> Do you know the current state of the sound issue?
 * ogra_ac is up since 3h ... damned jetlag
<robclark> doh
<lag> Yeah, I have jet-lag from Thailand
<ogra_ac> lag, only that there was much progress on the kernel side and that we still need userspace fixes
<robclark> lag: sound seems much better w/ audio patches from L24.10 backported
<robclark> one small default.pa change.. since hdmi is now device 0,7 (IIRC)..
<ogra_ac> and that time is getting short to get the userspace sorted (2 days left for uploads)
<lag> Does the card now report itself to Sound Preferences?
<ogra_ac> it does report itself to alsa
<ogra_ac> i think PA still needs the devices in the config
<lag> Excellent
<lag> Is there anything I need to do?
<ogra_ac> not sure, i'll ask bryan later
<lag> Or is kernel sound done for the release
<lag> That's what I'm waiting for ... :)
<ogra_ac> mpoirier dod much of the testing, i think we need him around too
<robclark> ogra_ac, lag:  is the kernel you are using already having the big stack of audio patches that are here: http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=shortlog;h=refs/heads/for-ubuntu-2.6.35
<robclark> fyi, on another topic.. updated geexbox packages (enna, libnfo, libplayer, etc) are created for debian: http://www.geexbox.org/sympa/arc/devel/2010-10/msg00009.html
<robclark> would be nice to get these in maverick
<lag> It doesn't look like it, no
<robclark> I've got a few more things to do in libplayer, but now it is starting to work well with hw accel codecs (and opengles)
<lag> sebjan: --^
<sebjan> lag: hi! the L24.10 audio patches are not pushed yet to the official kernel branch. They are still under test. cooloney did build an image for testing including these patches.
<robclark> sebjan: after I figured out that the HDMI device changed, the L24.10 patches seemed a big improvement
<lag> sebjan: Then I need to catch up with Bryan (after he's had his breakfast) :)
<lag> ogra_ac: Is mpoirer there with you too?
<ogra_ac> no
<lag> k
<ogra_ac> only bryan, tobin, ricardo and me
<sebjan> lag: please have look at bug 637947
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/637947
<lag> sebjan: I have - it's my bug :)
<sebjan> lag: Bryan did provide the location of the image he built with audio, + some updates from berco
<sebjan> lag: ok, :) These are the latest updates I have regarding audio. Berco did test it sucessfully and we are happy with these patches also.
<lag> sebjan: They're no good to me - sound doesn't work on my board due to a hardware fault
<lag> I'm interested to know if the card is reported to Sound Preferences without the script and configuration hacks?
<sebjan> berco1: ^  (I think this is still the open issue right now, even with these updates)
<lag> Userspace?
<dmart> ogra_ac: hey there... do I guess correctly from your nick that you got http://ac100.gudinna.com/ working?  Any good?
<ogra_ac> dmart, fsvo good, it runs
<ogra_ac> dmart, http://forums.computers.toshiba-europe.com/forums//thread.jspa?threadID=56355&start=75&tstart=0
<ogra_ac> seems it generated some interest at toshiba at least
<dmart> ogra_ac: if would be great if toshiba could be persuaded to help with the effort :)
 * dmart still tempted
<ogra_ac> dmart, well, they seem to look for community support
<ogra_ac> and that post above sounds like they are willing to help to some extend
<dmart> sounds positive, overall
<dmart> can I have a look @ UDS?
<ogra_ac> sure
<dmart> thanks :)
<ogra_ac> seems someone just made alsa work :D
 * ogra_ac just got a tarball with modules
<dmart> $ aplay fanfare.raw
<ogra_ac> dmart, well, not that far yet
<ogra_ac> ogra@ac100:/lib/modules/2.6.29-arm2-svn1996/kernel/drivers$ cat /proc/asound/cards
<ogra_ac>  0 [tegra          ]: tegra-generic-cotegra - tegra
<ogra_ac>                       tegra (tegra-generic-codec)
<ogra_ac> even the string is mangled
<ogra_ac> but the modules load
<dmart> hmmm, well it sounds like progress anyhow
<ogra_ac> ogra@ac100:/lib/modules/2.6.29-arm2-svn1996/kernel/drivers$ ls /dev/snd/
<ogra_ac> controlC0  pcmC0D0c   pcmC0D0p   timer
<ogra_ac> no mixer though
<ogra_ac> will still need hacking
<dmart> Does aplay "work" (even if no sound output)
<ogra_ac> no
<ogra_ac> it will need tinkering
<ogra_ac> i guess as long as the mixer isnt there alsa will fail
<dmart> I don't believe aplay touches the mixer (?)
<ogra_ac> but it needs to know what the card is
<dmart> Does something like aplay -Dhw:0,0 not work?
<ogra_ac> http://paste.ubuntu.com/505743/
<ogra_ac> seems android blocks access to the socket
<dmart> No socket is used for alsa audio, but aplay tries to route via pulseaudio which may be what's happening.  strace might be informative there
<ogra_ac> ha !
<dmart> I did write a hack to play audio through a device node directly, bypassing the alsa userspace stuff... but with no mixer node, I guess you may not be able to unmute anyway...
<ogra_ac> there is a special android daemon i have to run
<ogra_ac> works now
<dmart> ugh
<ogra_ac> binary nvidia stuff :(
<ogra_ac> no sources
<dmart> maybe this is down to the android-ised nature of the drivers
<ogra_ac> sadly that toool also enables userspace cpufreq
<ogra_ac> which makes the whole system really slow
<dmart> hmmm, that ought to affect android too, not just ubuntu?
<rsalveti> morning
<rsalveti> ogra_ac: hey, didn't sleep?
<rsalveti> :-)
<ogra_ac> rsalveti, got up at 5:30 :(
<rsalveti> lag: we'll try to follow up the audio issues today, will keep you posted in case you can help us :-)
<ogra_ac> rsalveti, we're sitting downstairs
<rsalveti> basically we have 2 issues now, one is that alsa is not loading the mixer settings file, and the other is that pulse is not getting the correct default routing
<rsalveti> ogra_ac: cool, had your breakfast already?
 * rsalveti going down in a minute
<ogra_ac> dmart, no, it dynamically en/disables the second cpu based on load ... not a biggie in android wheer you dont really have multitasking
<ogra_ac> but noticeable in ubuntu
<dmart> ah
<ogra_ac> shitty userspace power management
<rsalveti> ogra_ac: ouch, would be even harder for brian I'd say
<dmart> can running the same magic daemon enable that to work, or is it more tricky than that?
<ogra_ac> i run it on ubuntu atm
<ogra_ac> prob is that it has all the paths of the helper apps hardcoded
<ogra_ac> so i need to do weird stuff to my filesystem
<dmart> meh
<ogra_ac> (cteating /system/bin and fiddling with LD_LIBRARY_PATH)
 * ogra_ac reboots
<mpoirier> GrueMaster: good morning
<lag> sebjan: Does the OTG port work on the Panda?
<hrw> lag: wasn't it working on ES1 versions as only usb port?
<lag> It was
<lag> How about ES2.0/1
<hrw> no idea - waiting for hw
<rsalveti> yeeh, we're back on-line
<rsalveti> sharing a 3g connection :-)
<rsalveti> cooloney: ogra_ac: hey!
<rsalveti> it seems to work!
<cooloney> rsalveti: good, man, thx
<rsalveti> np :-)
<ogra_ac> yay
<ogra_ac> my lag meter goes mad in xchat though
<cooloney> mpoirier: hey, man.
<mpoirier> cooloney: hello bryan,
<cooloney> mpoirier: i've rebased the audio fix patches here
<cooloney> http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
<cooloney> and kernel http://people.canonical.com/~roc/kernel/audio/
<mpoirier> cool, just haven't seen any confirmation - was wondering if you had time.
<cooloney> mpoirier: we are working on that, wanna make the sound work.
<mpoirier> ya... are you working with Irg and friends ?
<mpoirier> in any case, I'm available for testing
<mpoirier> if you want me to investigate something that you don't have time with, just poke me.
<cooloney> mpoirier: great, man. i'm working with ogra, rsalveti and GrueMaster here
<cooloney> lag: did you get any progress on the sound issue of es2.0?
<mpoirier> cooloney: have you ever built the linaro tree ?
<cooloney> mpoirier: oh, no, never tried that
<directhex> I swear I'm not smoking crack here... does Firefox on ARM really define its plugin ABI as Linux_unknownABI?
#ubuntu-arm 2010-10-05
<III> has anyone used/tried displaylink on 10.10?
<hrw> morning
<sebjan> lag: panda OTG port: yes it does work, but not as OTG, it is configured as device in the kernel config
<lag> sebjan: So what do you make of bug 645420
<ubot2> Launchpad bug 645420 in linux-ti-omap4 (Ubuntu) "OTG port not enabled for OMAP4 (affects: 2) (heat: 324)" [Low,Confirmed] https://launchpad.net/bugs/645420
<sebjan> lag: well, I already commented on this bug: our driver is not OTG capable at the moment, this is why it is statically configured as device. It is working fine as device.
<sebjan> lag: this will not change for 10.10. I think we shall have the driver fixed to support OTG in 11.04.
<lag> sebjan: So you did
<lag> sebjan: I've just read your comment on the audio bug
<cooloney> lag: me2
<cooloney> heh
<cooloney> sebjan: ogra_ac and i think the default.pa is the same as ogra_ac posted in the launchpad.
<davidm> cooloney, how did things go yesterday?
<ogra_ac> well, at least the one you pasted before
<ogra_ac> davidm, well, network is still super slow
<davidm> did uboot and xloader get changed?
<ogra_ac> rsalveti has a package ready i think
<ogra_ac> uboot doesnt need changes
<ogra_ac> and i think i worked out a proper solution of the mixer settings
<sebjan> cooloney, ogra_ac: ok, I did not check that, I retrieved the default.pa delivered from our dev team, and saw it was different from the one installed by default in the daily images, so updated it
<ogra_ac> (which at least solves 50% of the audio prob)
<rsalveti> yup
<rsalveti> let's test soon :-)
<ogra_ac> sebjan, we cant change default.pa
<lag> I'm still unsure what progress has been made on the audio since I worked on it
<ogra_ac> using that file would break audio for everyone but panda users
<lag> ALSA has always worked with only the amixer settings
<ogra_ac> sebjan, but i have an idea for the mixer which i'll test today
<sebjan> ogra_ac: yep, this was just to check the drivers are able to generate some sound. This is not the final solution.
<lag> Pulse has never worked
<lag> The card is only reported when the other config file is used
<ogra_ac> lag, alsa has never worked without modifying the default volumes
<lag> What's new? What's different?
<lag> Correct
<lag> So what's new?
<cooloney> sebjan: yeah, we think sound driver works, but maybe the route setting has some issue
<ogra_ac> thast what the mixer settings are for :P
<ogra_ac> lag, that we needed a proper way to set them
<lag> I've heard lots of people talk about it being better and there are patches and improvements have been made, but I see no difference to 2 weeks ago
<sebjan> cooloney: yes, that shall be the purpose of SDP4430.conf file to setup the proper routings
<ogra_ac> which i think i found (need to test later today, its early here)
<lag> ogra_ac: What are the proper way?
<ogra_ac> sebjan, why cant we fix the routings in the driver
<lag> I can probably do it in the kernel
<lag> (which is what I'v been looking at)
<ogra_ac> lag, i doubt that since it needs to be modifyable per device
<lag> ogra_ac: How do you mean?
<ogra_ac> lag, /usr/share/alsa/init/hda is a good example
<ogra_ac> lag, blaze and panda need different volume adjustments (and later devices probably too)
<lag> ogra_ac: Okay
<ogra_ac> lag, the more important part is the routing
<sebjan> ogra_ac: don't know, I did not follow up on this topic, I repeat what I understood from berco :)
<ogra_ac> whioch is wrong in kernel
<ogra_ac> cooloney worked on a fix for that
<ogra_ac> but we havent tested
<ogra_ac> (in the driver)
<lag> What's the fix?
<ogra_ac> switching the routing of device 0
<lag> THIS is why I needed to speak to cooloney yesterday!
<rsalveti> if we had a proper network :-)
<cooloney> we can play sound over device 7 via speaker-test after some alsamixer setting
<ogra_ac> btw, ES2.1 boots fine
<cooloney> but pluseaudio will open device 0, which will fail
<lag> ogra_ac managed - rsalveti managed
<cooloney> and PA never runs
<ogra_ac> lag, managed ?
<lag> I even saw cooloney log on, only to log off again 15 mins later
<lag> To get online
<ogra_ac> lag, well, FSVO online
<lag> comradekingu: What's device 7 currently?
<ogra_ac> the network at TI is really bad
<lag> FSVO?
<ogra_ac> for some value of
<lag> How do they manage?
<ogra_ac> (you know, you use these abbreviations to not have to type so much :P)
<ogra_ac> lag, i was on through 3G
<lag> YMTUY
<rsalveti> shared 3g, the only one that worked
<lag> That sucks!
<cooloney> lag: oh, from the my post in the launchpad, it is here http://pastebin.ubuntu.com/503799/
<cooloney> lag: sorry, it should be device 9
<lag> We've been able to play sound via HDMI from the beginning
<cooloney> and sebjan i believe your alsamixer.sh can setup the right value of all the mixer
<cooloney> then we can play our sound over device 9
<ogra_ac> right, we just need to translate it into an alsa init file
<sebjan> right, I think so
<cooloney> but device 0, there is no-codec-associated
<cooloney> pa try to open this default device 0, but failed
<ogra_ac> so re-mapping the codec in the driver should fix that
<cooloney> ogra_ac: yeah, we need to talk with audio expert from TI, this sdp4430.c ASoC driver is from their
<ogra_ac> right
<cooloney> sebjan: for your testing with modification of default.pa, you got sound from hdmi or headset?
<sebjan> cooloney: I only tested headset
<cooloney> sebjan: ok, got it. i will test it soon. we try to find a fix today.
<cooloney> sebjan: i am going to push out the audio fixing patches today, since we are closed to 10.10 release
<cooloney> sebjan: is there any other audio new fixings?
<davidm> ogra_ac, if we only need xloader changes I'd like to see the patch diff between ES2.0 and ES2.1 silicon so I can get a feel of what is being done
<sebjan> cooloney: ok. I received a 1 line patch update for audio that is supposed to help for the audio record. I'll send it to you right now. However I have not been able to make audio record even with it - we are still missing something here (maybe also a routing issue?)
<cooloney> sebjan: oh, we never try recording i think, before we fix the playback.
<ogra_ac> davidm, robclark is doing last tests
<cooloney> sebjan: ok, please post me the audio patch
<ogra_ac> davidm, if we get his ok (which i expect durign the day) we are good to go
<ogra_ac> davidm, and we're all actively working on the sound issues
<ogra_ac> davidm, for which we need a libalsa0 upload
<ogra_ac> and possibly a kernel
<ogra_ac> thats the three packages we'll need today
<davidm> ogra_ac, I want to understand the "amount" of change between ES2.0 and ES2.1 so I can get a feel for the level of risk with releasing on 10.10
<ogra_ac> davidm, about 30-40 lines in x-loader to handle the different ram speed
<sebjan> cooloney: I just sent the audio patch
<cooloney> sebjan: cool, thx
<rsalveti> davidm: ogra_ac: yep, just different timmings to support ddr@400mhz
<rsalveti> so it should work without breaking other stuff
<rsalveti> but rob is giving some more tests
<mpoirier> cooloney: moving the elements in the list of DAIs could fix the missing codec on the default device.
<kornel`> hey
<mpoirier> TI sound people would have to be consulted.
<kornel`> does anyone know a board that has an arm processor and an ethernet interface? nothing else is needed, though its not a problem, but i need this to be as small as possible.
<kornel`> and of course has the capability to run ubuntu oni t
<GrueMaster> kornel`: Try beagleXM or Gumstix.
<cooloney> mpoirier: cool. could you post me a patch?
<mpoirier> cooloney: I don't have a patch for that...
<cooloney> mpoirier: we are leaving from hotel to TI office
<mpoirier> cooloney: ok hookup with me when you get on again
<mopdenacker> ogra_ac:  Hi! We need to modify the pre-installed images to have custom boot.scr scripts for our internal releases. How would you do this, please?
<ogra_ac> by a script
<ogra_ac> mopdenacker, we need to head over to the office, lets talk in a few mins
<mopdenacker> ogra_ac: we could also modify the script that creates the boot.scr file for the second boot... This way users wouldn't have to make any manual change...
<mopdenacker> ogra_ac: no problemo. Thanks for your answer!
<kornel`> thnx
<sebjan> ogra_ac, cooloney: though the kernel was changed to allow 1GB usage without crash issues, the boot.scr cmd lines still restricts to 460 + 256M
<cooloney> sebjan, yeah, good point,
<ogra_ac> sebjan, yeah, i'll change that today
<cooloney> ogra_ac, cool
<mopdenacker> ogra_ac: back to my question... Our need is to modify the script that generates boot.scr after expanding the SD card partition. What file should we modify? That's only for our internal releases.
<lag> ogra_ac: Can I close my half of bug 628029?
<ubot2> Launchpad bug 628029 in linux-ti-omap4 (Ubuntu Maverick) (and 2 other projects) "[maverick] panda omap4 does not suspend (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/628029
<lag> mopdenacker: If I'm not mistaken, I think you're looking for: /usr/share/initramfs-tools/scripts/local-bottom/jasper_setup
<mopdenacker> lag: thanks a lot! I will take a look.
<lag> mopdenacker: Any time :)
<lag> sakoman: Good morning
<sakoman> gm lag
<lag> sakoman: Have you managed to find the time to push this upstream yet?
<lag> sakoman: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commit;h=9f40ee61034576e8abdb8201c9526204680e70d5
<sakoman> lag, no not yet
<lag> sakoman: Any view to?
<sakoman> lag: I'll be working on a patch series over the next couple of weeks.  I'll try to add it as part of that
<lag> sakoman: Sounds good - thanks :)
<kornel`> bye
<sbambrough> https://wiki.canonical.com/UbuntuPlatform/ARM/LinaroCoordinationCallMinutes
<berco1> is there a mean to install a specific version of a package? Using one omap4 cdimage, I have alsa-utils=1.0.23-2ubuntu1 and in a more recent img I have alsa-utils=1.0.23-2ubuntu3...
<berco1> I want to be able to revert as I suspect an issue with latest version
<berco1> apt-get install cannot find the alsa-utils-1.0.23-2ubuntu1 version...
<berco1> are the old packages removed from cannonical archive?
<cooloney> berco1, ogra_ac might can help to answer that.
<cooloney> berco1, i am working on the audio issue in kernel side
<berco1> cooloney: I think I found out myself  :)
<berco1> cooloney: I found one on Launchpad https://launchpad.net/ubuntu/+source/alsa-utils/1.0.23-2ubuntu1/+build/1879590/+files/alsa-utils_1.0.23-2ubuntu1_armel.deb
<cooloney> berco1, cool
<berco1> cooloney: I have one image that has audio working with that famous SDP4430.conf file
<berco1> cooloney: however, taking today's cdimage and putting the SDP4430.conf in it doesn't enable sound
<cooloney> berco1, from the code in sound/soc/omap/sdp4430.c, the frondend dai-links are no codec associated, right?
<berco1> cooloney: I found that alsa-utils, alsa-base and pulseaudio have been upgraded
<cooloney> berco1, so from my side, the PulseAudio will fail due to failing to open the pcm0 device which is MultiMedia of SDP4430
<berco1> cooloney: I need to check with audio dev team for your question
<berco1> is that holding you?
<cooloney> berco1, do you need to modify the default.pa to make the sound work?
<berco1> cooloney: have you tried running the amixer.sh file?
<berco1> cooloney: in my working setup, no default.pa change, I just use the default file
<cooloney> berco1, yeah, i tried that. amixer.sh will set the right value
<cooloney> berco1, cool. since modification of default.pa is not acceptable, that might make other omap4 based board sound broken
<cooloney> berco1, sorry, need to have luch
<berco1> cooloney: yes. Nevertheless, I still need to understand if it is one of the s/w upgrade that breaks my setup
<cooloney> lunch, siya
<berco1> see ya
<mpoirier> cooloney: get in touch with me when you get back - we'll talk about your pmc0 device.
<cooloney> mpoirier, hey, man. I am back from lunch
<mpoirier> ok good.
<mpoirier> you are correct, the default front end in the list doesn't have a codec.
<mpoirier> actually it is set to the null-codec.
<cooloney> mpoirier, right, that's why pulseaudio will fail to open the device.
<mpoirier> if you were to put DAI entry pertaining to the headset at the very top of DAI list, I think that devices would become your default device.
<mpoirier> that is, in theory, great...
<mpoirier> but that DAI still wouldn't have any backend associated to it, resulting in a failure to open pcm0.
<mpoirier> that's what lies at the heart of the problem.
<cooloney> mpoirier, right. we are thinking in the same way
<mpoirier> this is a config that is left to userspace, on purpose.
<cooloney> mpoirier, i just fixed the first frontend dai-link
<cooloney> built the kernel and will test soon
<mpoirier> you prept it up in the list ?
<ogra_ac> yay
<ogra_ac> mixer defaults solved
<cooloney> mpoirier, i found we need to debug the alsa and asoc code for a while
<cooloney> maybe it is right that pcm0 doesn't have the codec driver associated
<cooloney> it will be connected to a backend when we open it for operation at runtime
<cooloney> but we failed to find one.
<cooloney> so i am looking at this
<rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/maverick/boot/es21/MLO
<mpoirier> cooloney: I'm back from lunch.
<mpoirier> I have done a lot of tracing in the soc area...
<mpoirier> hold on a sec...
<mpoirier> did you see the latest addition from ogra ?
<mpoirier> cooloney: did you see the latest finding from ogra ?
<mpoirier> cooloney: about /usr/share/alsa/init/00main ?
<cooloney> mpoirier, yeah, but that's for alsamixer. pulseaudio need to open it in the right way
<mpoirier> cooloney: indeed, there are multiple part of the puzzle.
<mpoirier> cooloney: take a look at this: http://omappedia.org/images/c/c9/OMAP4_Audio_Phoenix.jpg
<mpoirier> cooloney: on the right hand side you have the famous DAIs.
<mpoirier> cooloney: on the left side, second square, are the "interface".
<mpoirier> cooloney: the famous PDMs. UL0, UL1, DL0...DL4
<mpoirier> running the script omap4_amixer_config.sh will link the DAIs to the PDMs.
<mpoirier> cooloney: it is only when that relashion is established that opening pcm0 can succeed.
<mpoirier> cooloney: I spent a lot of time in there.
<mpoirier> To the best of my knowledge, SDP4030.conf under /usr/share/alsa/cards/ is supposed to do that
<mpoirier> sorry, SDP4430.conf.
<mpoirier> TI guys are all very fluent with those concepts.
<sguiriec> mpoirier:cooloney: I can support on this if you have trouble. Berco is still working on the finalization of SDP4430.conf file
<mpoirier> sguiriec: the above is a recollection of 2 weeks of soul searching in the soc subsystem.
<mpoirier> feel free to rectify anything that would not be accurate.
<mpoirier> sguiriec: am I correct when saying that PDMs and DAIs are linked in file SDP4430.conf ?
<sguiriec> mpoirier:You statement is ok. Final solution will be with SDP4430.conf file. With this file we should get ride of omap4_amixer_config.sh.
<mpoirier> cooloney: hence no changes should be required to the kernel.
<mpoirier> cooloney: at least that's the conclusion I came up with.
<mpoirier> cooloney: all the ingredient in the kernel are there and working.  The scheme was meant to be generic.
<sguiriec> mpoirier: Inside OMAP4 McPDM port include part of Sigma delta. This is why code is a little bit different form standard CODEC interface
<mpoirier> sguiriec: the famous McPDMs... I'm still having a lot of fun with those.
<cooloney> sguiriec, and mpoirier let me to report my findings here
<mpoirier> cooloney: everybody should be on the same page on your side....
<cooloney> speaker-test -D plughw:0,3 -t sine -c 2
<cooloney> will generate sound
<mpoirier> We've all talked about it in great lenght
<sguiriec> mpoirier: Liam has work to get correct board name in order to have ALSA utils to be able to load SDP4430.conf file. Now we are finalizing the content of this file in order to set correctly the audio path after board boot.
<cooloney> also 0,7
<cooloney> the dynamically run time binding, looks right
<cooloney> but device 0,0 doesn't generate any sound
<sguiriec> mpoirier:cooloney: 0
<cooloney> i can open it, the dmesg from driver tells me it binds to the right codec and backend
<rsalveti> ogra: https://code.edge.launchpad.net/~rsalveti/ubuntu/maverick/x-loader-omap4/es21/
<mpoirier> cooloney:  yes indeed, but your path to the PDM probably doesn't exist.
<cooloney> mpoirier, so we need to check the bug in this binding thing
<sguiriec> mpoirier:cooleney: can you check amixer controls for DL1 Media Playback Volume?
<mpoirier> sguiriec: I'll have to fire up my board - what are you after ?
<sguiriec> mpoirier:Inside ABE you have SW volume. Just want to check that volume is well set.
<cooloney> sguiriec, let me check this.
<mpoirier> cooloney: please, I don't have the very latest patch.
<cooloney> sguiriec, my bad, i need to run the amixer.sh from sebjan and becor,
<cooloney> sguiriec, i got sound from device 0,0
<mpoirier> sguiriec: what state do you want the system to be in ?
<mpoirier> sguiriec: just after booting ?
<cooloney> sguiriec, i will try ogra's latest alsa config method to get alsamixer works firstly
<cooloney> sguiriec, but we need to make the pulseaudio also working
<sguiriec> mpoirier: cooloney:Until we finalise the SDP4430.conf file it is beter to run amixer.sh file (or omap4_amixer_setup). amixer.sh -a should reconfigure the audio path. Until it is not fix you will have no sound after boot
<mpoirier> sguiriec: that is well understood on my side.
<mpoirier> sguiriec: do you still want us to check DL1 Media playback ?
<ogra> thats nothng we can do in the image
 * ogra can only repeat that every time this comes up
<ogra> uploas deadline for maverick is in a few hours
<sguiriec> mpoirier: Yes if you have no audio on plughw:0,0 and audio on plughw:0,3 it should be linked to this control.
<mpoirier> sguiriec: I'm here to provide you data - my board is powered up.
<mpoirier> I haven't done anything to it so far, aka defautl value.
<mpoirier> do yo want the value of DL1 now or after running amixer.sh ?
<sguiriec> mpoirier: In case you have no audio it will be good to have it now and the to set up in the middle of the play
<mpoirier> sguiriec: I definitely don't have audio right now.
<sguiriec> mpoirier: Normally audio should come back if you run amixer.sh -a
<mpoirier> sguiriec: indeed.
<mpoirier> sguiriec: I'll run the script, hang on.
<cooloney> sguiriec, amixer.sh is not a final solution for our release, i think ogra has make all the setting in his alsa init file.
<ogra> which isnt proper either
<ogra> SDP4430.conf is actually the right way to go
<sguiriec> mpoirier:cooloney:Inline with this statement. berco is working on it. Seem to have trouble with Pulse and alsa versions.
<mpoirier> sguiriec: indeed, berco was asking about older versions earlier today.  Is the newer stuff broken ?
<sguiriec> mpoirier:cooloney: generation of asound.state file was not always inline with SDP4430.conf file. Newer stuff has broken it. This is why berco is asking older version
<sguiriec> mpoirier:cooloney: I was just with him before coming back to home. Now need to understand what is borken and to see if it is inside pulse or alsa.
<mpoirier> speaker-test -D plughw:0,3 -t sine -c 2
<mpoirier> speaker-test -D plughw:0,7 -t sine -c 2
<mpoirier> sorry, wrong console, please ignore
<mpoirier> sguiriec: numid=3,iface=MIXER,name='DL1 Voice Playback Volume'
<mpoirier>   ; type=INTEGER,access=rw---R--,values=1,min=0,max=149,step=0
<mpoirier>   : values=110
<mpoirier>   | dBscale-min=-120.00dB,step=1.00dB,mute=1
<mpoirier> sguiriec: that is after running amixer.sh
<mpoirier> sguiriec: speaker-test -D plughw:0,3 -t sine -c 2 works properly.
<sguiriec> mpoirier: this control is for voice so plughw:0,2. DL1 Media Playback Volume should be numid=1
<sguiriec> mpoirier: this control is for Voice port (plughw:0,2). For multimedia it should be numid=1 name='DL1 Media Playback Volume'
<mpoirier> sguiriec: ok, one sec.
<mpoirier> numid=1,iface=MIXER,name='DL1 Media Playback Volume'
<mpoirier>   ; type=INTEGER,access=rw---R--,values=1,min=0,max=149,step=0
<mpoirier>   : values=110
<mpoirier>   | dBscale-min=-120.00dB,step=1.00dB,mute=1
<mpoirier> sguiriec: ^^^^^^^^
<sguiriec> mpoirier: Ok 110 looks ok. it means -10 dB. Can you check also numid=18? Should be the next gain in the ABE chain before headset. I will recommend to set it to 120 (0 dB).
<mpoirier> sguiriec: numid=18,iface=MIXER,name='SDT DL Volume'
<mpoirier>   ; type=INTEGER,access=rw---R--,values=1,min=0,max=149,step=0
<mpoirier>   : values=120
<mpoirier>   | dBscale-min=-120.00dB,step=1.00dB,mute=1
<mpoirier> it is indeed set to 120.
<sguiriec> mpoirier: And still not sound on headset
<mpoirier> sguiriec: speaker-test -D plughw:0,3 -t sine -c 2 did work
<mpoirier> sguiriec: so does speaker-test -D plughw:0,2 -t sine -c 2
<sguiriec> mpoirier:depend on the controls.
<mpoirier> sguiriec: we may be out of sync here...
<cooloney> sguiriec and mpoirier, let me sync with you guys
<cooloney> kernel driver looks ok, it uses the front end and back end for dynamically run time binding
<cooloney> for alsamixer, we need SDP4430.conf and the script file to set it in right volumn
<cooloney> moreover, we need to modify the default.pa of pulseaudio to make the sound works finally
<sguiriec> mpoirier:cooloney: Yes you need to have a valid root between FE and BE. SPD4430.conf should do it after the boot
<mpoirier> sguiriec: would you like me to run other tests ?
<sguiriec> mpoirrier:cooloney: for pulse I am not the good guy to comment. May be in the comming weeks.
<cooloney> but unfortunately, ogra said, we cannot modify the default.pa, since that will break other boards with different audio configuration
<cooloney> anyway, guys, i am going to send out the audio patches
<mpoirier> cooloney: I did not investigate the pulse front.
<sguiriec> mpoirier: Just try on plughw:0,0. Normally you should have some sound
<mpoirier> cooloney: too busy getting grey hair with PDMs and DAIs.
<mpoirier> sguiriec: ok, one sec.
<ndec> ogra: mpoirier: cooloney: hi!
<ndec> so it looks better on the audio front...
<sguiriec> mpoirier:cooloney: Just thinking that for pulse a patch has been already pull in 10.10 in order to set custom configuration on top of default.pa file.
<ndec> sguiriec: no this was not pulled on time for 10.10
<ndec> mpoirier: cooloney: ogra: so what do we need exactly on top of the current image to get audio out of the box? are you using SDP4430.conf file or not?
<mpoirier> SDP4430.conf is not ready yet.
<mpoirier> berco is working on it.
<sguiriec> ndec: thanks nico for the info
<ndec> mpoirier: i saw ogra comments on the bug, with the omap4 config file. what is this file? where is it supposed to come from, e.g. which package?
<cooloney> ndec, firstly, we need merge those audio patches
<mpoirier> ndec: I saw the comment to but havent' had time to try.
<ndec> cooloney: agreed, on this. stability and sound quality is much better with those patches.
<ndec> mpoirier: ok.. i thought you guys were talking about this in fact.
<mpoirier> ndec: no, I'm doing test for sguiriec - he's helping us.
<ndec> so we need ogra to explain why/how he did this change.
<ndec> mpoirier: ok. which tests?
<cooloney> ndec, for the SDP4430.conf or alsamixer configs, ogra will update that
<ogra> ndec, that file apparently only works if you call alsactl init and requires a one line change to libasound0
<ogra> (the omap4 file)
<mpoirier> ndec: sguiriec needed information, I'm providing it.
<mpoirier> sguiriec: plughw:0,0 also works.
<sguiriec> ndec: With berco we have some trouble with latest Asla/Pulse release compare to his previous FS.
<sguiriec> mpoirier: Good to see that port is working after good setting.
<mpoirier> sguiriec: educate me here a little...
<mpoirier> when doing aplay -l,
<sguiriec> sguiriec: Just here for help
<mpoirier> device 9, 11, 13, and 14 are associated with twl6040 codec.
<mpoirier> how did you do the mapping with plughw:0,0 , plughw:0,3 and plughw:0,4 ?
<mpoirier> sguiriec: 'cause those devices are not associtated with twl6040...
<sguiriec> mpoirirer: These devices are here for BE ports or to bypass ABE. Diirect access to McPDM.
<sguiriec> mpoirier: Here I think we need to update the wiki. plughw:0,0 is Multimedia port (FE port). This port can be sent on different BE ports (Headset/Handsfree)
<mpoirier> sguiriec: here's another way of asking the same question: is the output of aplay -l related to plughw:0,x ?
<sguiriec> mpoirier: mixer controls setting will enable the different paths.
<sguiriec> mpoirier: Normaly when we are using ABE we should use plughw;0.x with x up to 8.
<mpoirier> sguiriec: the ABE are accessed directly with the plughw:0,x ?
<sguiriec> mpoirier: After we should used amixer controls in order to set the path between FE to BE ports.
<mpoirier> sguiriec: let me summarise what I just learned...
<sguiriec> mpoirirer: ALSA is accessed to ABE directly with a sDMA channel to ABE.
<mpoirier> ABEs are access directly via plughw:0,x . But for this to work the path between FE and BE must be set.  Correct ?
<sguiriec> mporirier: Yes otherwise ALSA will return an error
<mpoirier> sguiriec: here's another question then:
<mpoirier> sguiriec: is the path between ABEs and BEs always the same ?
<sguiriec> mpoirier: No it can be changed accoridng to the use case.
<mpoirier> sguiriec: the following has become my bedside reading: http://omappedia.org/images/c/c9/OMAP4_Audio_Phoenix.jpg
<mpoirier> sguiriec: in this case, plughw:0,0 is related to which PDM ? (UL0...DL4)
<mpoirier> sguiriec: if that question makes sense at all...
<sguiriec> mpoirier: Here you are missing the ABE part. McPDM port is a kind of TDM port manages by ABE.
<sguiriec> mpoirier: Until you do not have ABE picture your questions are normal.
<mpoirier> sguiriec: the only time I saw a ABE was in the omap4 technical reference manual.
<mpoirier> sguiriec: unless you have a better picture...
<sguiriec> mpoirier: ABE graph is making the link beetween FE port and BE port. Typicaly McPDM is a BE port. McBSP is also a other BE port used for BT or MODEM call.
<mpoirier> sguiriec: ya, I read about the McBSP but aren't much of interest in this case - correct ?
<sguiriec> mpoirier: will check if I can provide you better picture tomorrow. Normally should be ok
<sguiriec> mpoirier: For standard audio with Phoenix Audio McBSP is no interest for our use case
<mpoirier> sguiriec: ok that is the conclusion I came up with.
<mpoirier> sguiriec: i've known from the start i was missing information - anything you can get will  help.
<sguiriec> mpoirier:of course. Will sync with ndec in order to help you on the topic. Quite new compare to OMAP3.
<mpoirier> sguiriec: thanks.  your time and insight are well appreciated.
<sguiriec> mpoirier: I hope we will reach to good SDP4430.conf file with berco. Will try to provide ABE/Phoenix audio picture for audio system understanting
<mpoirier> ok
 * ogra_ac still doesnt get why device 0,0 cant just properly connect to the working default codec in the driver 
<ogra_ac> that would solve all our issues
<mpoirier> ogra_ac: even if it would, the FE - BE path would not be established.
<rsalveti> vincent-laptop: robclark: http://paste.ubuntu.com/506797/ an oops while restarting X11
<sguiriec> orga_ac: SDP4430.conf should solve our problem by setting up the graph between FE and BE ports after the boot.
<rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/maverick/boot/es21/MLO-sdp
<ogra_ac> sguiriec, yeah
 * ogra_ac just commented on the bug
<sguiriec> ogra_ac: Do you have any glue on potential recent update on ALSA or pulse that can explain different behavior in the reading of .conf audio file?
<ogra_ac> no, sorry, i dont, do you know between which versions it changed ?
<sguiriec> orga_ac: Can check tomorrow with berco? Do not have it from home.
 * ogra_ac goes to check changelogs on launchpad
<ogra_ac> sguiriec, but you are use it was a version in maverick ?
<ogra_ac> s/use/sure/
<sguiriec> orga_ac:thanks, I will check the chanelogs. berco has two FS. One is working and the one is not. There are based on maverick but version are not exactly the same. changelogs should help us
<ogra_ac> yep, i'm just looking
<ogra_ac> one prob is though that there camein a completely new upstream version at some point
<rsalveti> robclark: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commits/omap4_panda_es2.1
<rsalveti> vincent-laptop: robclark http://people.canonical.com/~rsalveti/maverick/boot/es21/MLO-lowvoltage
<rsalveti> with                 *(volatile int*)(0x4A307BA0) = 0x3A5512;
<devilhorns> grrr, really wish xvidcap would work so I could show you guys the unity-efl stuff
#ubuntu-arm 2010-10-06
<rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/maverick/boot/es21/u-boot-4430sdp.bin
<devilhorns> ogra_ac, around ?
<III> hey all... got a quick ??? --> if I create a custom xorg.conf in /etc/X11/ will it be used as the default? or do I need to create a new one in /usr/share/X11/xorg.conf.d?
<devilhorns> GrueMaster, ping ?
<devilhorns> ogra_ac, ping ?
<tmzt_> III: the new directories are basically for devices configureation
<III> thanks tmzt_
<robclark> ogra_ac, rsalveti: I just logged in to my board over ssh... still going strong w/ latest x-loader
<rsalveti> robclark: awesome
<robclark> :-)
<ogra_ac> wohooo
<ogra_ac> !!
<ogra_ac> rsalveti, did you set your board up already ?
<rsalveti> ogra_ac: doing atm
 * ogra_ac is looking for a /var/log/udev output
<rsalveti> hold some minutes and I can help you
<ogra_ac> yeah, i thought so :)
<robclark> ogra_ac: I can send you my /var/log/udev if you want
<ogra_ac> that would be great so i cant figure out a udev rule for the sound stuff
<robclark> ok, hang on
<rsalveti> ogra_ac: should it depend on the kernel you're running?
<rsalveti> because I believe robclark is running his own kernel version
<ogra_ac> as long as its a devtmpfs enabled kernel all is fine
<ogra_ac> *and as long as it has the SDP4430 stuff compiled in
<robclark> my own kernel, but no audio related changes (other than what is already on d.oz.o kernel-ubuntu tree
<robclark> ogra_ac: http://paste.ubuntu.com/506977/
<GrueMaster> devilhorns: Sup?
<ogra_ac> robclark, merci >(
<ogra_ac> err
<ogra_ac> :)
<devilhorns> GrueMaster, hey ! :)
<devilhorns> got something exciting for ya
<devilhorns> and for ogra_ac
<devilhorns> http://home.comcast.net/~devilhorns/unity-efl.html
<GrueMaster> Dove is fail for poweron.  Boss doesn't know the diff between AT & atx PS.
<rsalveti> devilhorns: cool
<ogra_ac> devilhorns, awesome, the video will have to wait until tomorrow though ... will trash the hotel network
<GrueMaster> devilhorns: The info looks good, video d/l is a bit slow on the hotel network.  Will watchin ~14 minutes.
<devilhorns> ogra_ac, no worries :) just wanted to show ya some progress
<rsalveti> yeah, huge
<devilhorns> yea, is a rather big video :( but needed to be
<GrueMaster> Youtube?
<GrueMaster> (suggestion, not a question).
<ogra_ac> GrueMaster, bah
<devilhorns> don't think it would work. had to make it with 'recordmydesktop' instead of xvidcap (cause xvidcap was giving me garbage output), and recordmydesktop records in .ogv
<ogra_ac> that would lock me out with my arm netbook :P
<devilhorns> don't think youtube can display ogv files
 * ogra_ac likes ogv ... there are compression methods though
<GrueMaster> ogra_ac: There is a flash app for android.  :P
<rsalveti> ogra_ac: booting my board, still need the output?
<ogra_ac> GrueMaster, that would mean i would have to run android !
<ogra_ac> rsalveti, nope, got it from robclark already
<GrueMaster> and?
<rsalveti> ogra_ac: ok, if you need I'm running latest kernel with latest audio patches
<ogra_ac> rsalveti, nope, i'm fine now
<rsalveti> ogra_ac: cool, less work for me then :-)
<ogra_ac> rsalveti, i dont think any of the udev initialization changed
<rsalveti> ogra_ac: name of the board?
<rsalveti> maybe
<ogra_ac> well, paste it i'll compare
<devilhorns> rsalveti, thanks :)
<devilhorns> making progress :)
<GrueMaster> ogra_ac: I won't be able to test dove at all, unless chris hasa spare powersupply, or I make a trip to acomp store tomorrow.
<rsalveti> GrueMaster: doesn't work with davidm one?
<rsalveti> ogra_ac: http://paste.ubuntu.com/506982/
<rsalveti> pastebinit rocks :-)
<rsalveti> robclark: ^
<ogra_ac> GrueMaster, well, i suppose chris can get you one
<GrueMaster> He may not have one.
<GrueMaster> rsalveti: no.  AT, not ATX.  No way to easily power on.
<rsalveti> GrueMaster: oh, AT
<rsalveti> old stuff
<GrueMaster> yes.
<ogra_ac> GrueMaster, well, then buy one, but first ask chris
<GrueMaster> already handled.  See my previous post.
<GrueMaster> I sent chris a SMS earlier.  He will look for one.
<ogra_ac> great
<rsalveti> robclark: the last email you sent, with the link to the latest patch, did you reply the on-going thread?
<rsalveti> because I didn't get any new email from you :-)
<robclark> rsalveti: I thought I did..
<rsalveti> robclark: or someone just replied the email before you included me
<robclark> rsalveti: oh, could be
<rsalveti> np, just wanted to make sure the email was sent, so we can have comments on it tomorrow
<robclark> yeah, email was sent..
<rsalveti> robclark: so we're fine :-)
<robclark> oh, it was a new email thread started
<rsalveti> we everything works and we don't get any reply saying we shouldn't do that, we're more than fine :-)
<rsalveti> *if
<robclark> vp8 neon stress test still running
<rsalveti> nice
<rsalveti> and the kernel build just started
<lag> Morning sebjan
<sebjan> morning lag
<lag> sebjan: Hey
<lag> sebjan: I've just started taking a look at Natty
<lag> sebjan: Are you going to have a separate tree for 2.6.36?
<sebjan> lag: yes we will have a separate tree, but it's not available yet
<lag> sebjan: That's no problem at all
<lag> sebjan: Do you have a rough time-frame?
<sebjan> lag: hum, nothing official. I would guess at best in early November, but it could be later as well
<lag> sebjan: Okay, cheers :)
<hrw> morning
<lool> ndec: Poke!  are you in your office or travelling?
<rsalveti> robclark: ogra_ac: nice, board still up and running
<robclark> rsalveti: yup, mine too
<rsalveti> and we got patches from sebjan to help fixing the underflow issue
<robclark> oh cool
<cal-broadcom> hey guys, how long does rootstock usually take? I'm on a 15Mbps internet connection
<berco> persia: are you here?
<ndec> lool: in office
<berco> Anyone familiar enough with alsa to tell me what the (-22) failure in that log means: http://pastebin.ubuntu.com/507222/
<berco> ogra_ac: just saw your comment on alsactl in bug #637947
<ubot2> Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 2) (dups: 1) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/637947
<berco> ogra_ac: can we run alsactl command manually for testing?
<ukleinek> ericm|ubuntu: did you see the patch series "ARM: Dynamic IRQ demux support" by Magnus Damm?
<ericm|ubuntu> ukleinek, nope
<ukleinek> i didn't check yet, but the description suggests that it allows different irq demuxer in a single kernel
<ericm|ubuntu> ukleinek, I'll take a look
<ericm|ubuntu> ukleinek, I had a patch for that month ago, didn't go into last cycle
<ukleinek> Message-id: 20101006071731.28048.89938.sendpatchset@t400s
<davidm> rsalveti, ogra_ac how is progress on board?
<mpoirier> cooloney: good morning
<rsalveti> davidm: we just saw that it seems we got a stable panda again, with latest x-loader patches we did yesterday
<rsalveti> we still need to push a new version, we'll do it soon
<cpearson> rsalveti: I'm on my way in. how did the tests go last night?
<rsalveti> cpearson: all fine :-)
<cooloney> mpoirier, morning man
<mpoirier> cooloney: are you on site or still at the hotel ?
<ogra_ac> berco, sure, you can test it
<cpearson> rsalveti: great news. This calls for beer! wait it's not even 9am yet... Bloody Marys instead.
<cpearson> persia:I found your next phone --  http://www.engadget.com/2010/10/05/fujitsu-dual-touchscreen-concept-phone-hands-on/
<ogra_ac> berco, it works just fine here on our test boxes, the only thing thats missing is the selection for hdmi in the pulse UI
<berco> ogra_ac: so you hack alsa init files
<berco> ogra_ac: I have one setup here that works with SDP4430.conf but don't what triggered the fact that this file is used
<berco> ogra_ac: whenever I change a value in SDP4430.conf, restart PA, I can read back the correct value with amixer...
<ogra_ac> berco, well, see the comment on the bug
<ogra_ac> it seems that alsactl init was called until a week ago by default
<berco> ogra_ac: I reverted alsa and PA back to same version that is working on my other file system and still no audio
<ogra_ac> see if you get it working by calling alsactl init
<berco> I tried it
<cooloney> mpoirier, i am onsite now. heh
<ogra_ac> apparently its expected that pulse doe the initialization now
<ogra_ac> berco, alsactl init with only your .conf file ?
<ogra_ac> or with my init file ?
<mpoirier> cooloney: what's on your agenda today ?  What do you want to tackle ?
<ogra_ac> with my init file it definitely works if i put alsactl init into rc.loacl
<berco> ogra_ac: see my log here, I don't know who can help figure out (-22) failure in that log: http://pastebin.ubuntu.com/507222/
<ogra_ac> *local
<berco> ogra_ac: alsactl init with only my .conf
<rsalveti> cpearson: oh yeah :-)
<cooloney> mpoirier, oh, i got another urgent patch from sebjan for a displayfixing. will built kernel and test it.
<ogra_ac> cpearson, while its great news, we just got another patch for x-loader from Nice .... will require additional testing
<cooloney> mpoirier, rsalveti will help to build a x-loader for that testing
<rsalveti> doing right now
<mpoirier> cooloney: call me in if you'd like me to test images or investigate something
<cooloney> mpoirier, np, man, you're quite helpful these days
<mpoirier> cooloney: on my side, sguiric is supposed to get back to me with info on the ABE-BE-FE path, I'm eager to see it.
<mpoirier> cooloney: won't help us at this very moment but will surely come handy (I suspect) soon.
<cooloney> mpoirier, great, actually the ABE-BE-FE thing is quite new and only omap4 is using it.
<mpoirier> cooloney: yes, and were bound to stumble on it again in the future.
<cooloney> mpoirier, yeah, it's good for us working on
<cooloney> sebjan, for the display patch, could you please help me to file a bug on launchpad?
<cooloney> sebjan, since we are in SRU, I need to send out this patch with a bug associated.
<sebjan> cooloney: yes sure, I'll do that right now
<cooloney> sebjan, thanks a lot. man. I guess there is no more critical patch for kernel today, right?
<cooloney> sebjan, we are going to upload once before our 10.10 release.
<ogra_ac> ndec, hey
<sebjan> cooloney: :) I just got a link to 2 display patches, for better edid handling from our dev team (mythripk). You may want to look at them directly rather than waiting for me to integrate / test and pass to you?
<cooloney> sebjan, is that critical, or does it also need change of x-loader?
<cooloney> otherwise, we can do SRU after 10.10 release
<sebjan> cooloney: no x-loader impact expected, but I did not test it yet
<cooloney> sebjan, since the patch you just sent out needs change of x-loader, we have to make sure x-loader right before release
<rsalveti> yeah
<cooloney> so i think the kernel patch associated with x-loader is critical
<rsalveti> sebjan: but I believe the 2 other patches are not critical for release
<rsalveti> just the ones you sent us already by email
<rsalveti> for x-loader and kernel
<cooloney> for other kernel patches, we can go through SRU
<davidm> ogra_ac, cooloney rsalveti when will we know that x-loader is stable for upload?
<rsalveti> with that we plan to have a *final* x-loader and kernel
<cooloney> rsalveti, yeah, man
<rsalveti> davidm: in a couple of minutes, after testing the latest change
<davidm> rsalveti, OK thanks
<rsalveti> I'm just building it now and cooloney is building the kernel
<cooloney> davidm, we are working on that.
 * cooloney cross compiling the kernel on his old macbook pro
<rsalveti> vincent-laptop: robclark: cooloney: http://people.canonical.com/~rsalveti/maverick/boot/es21/MLO-fix-underflow
<rsalveti> with latest patch from sebjan
<rsalveti> including the changes we did yesterday
<rsalveti> but seems we need also a new kernel
<rsalveti> sebjan: cool, we just built kernel and mlo and tested on 2 boards, seems to be running fine
<rsalveti> at least we got a working environment, and display
<sebjan> rsalveti: ok, cool. I am preparing the launchpad bug atm
<rsalveti> nice
<sebjan> rsalveti: you also want a bug on the x-loader package?
<rsalveti> sebjan: nops, don't need it, thanks
<sebjan> rsalveti, cooloney: here is the kernel bug 655746
<ubot2> Launchpad bug 655746 in linux-ti-omap4 (Ubuntu) "SYNC_LOST_DIGIT errors are reported with some screens (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/655746
<rsalveti> sebjan: we'll upload a new version anyway
<sebjan> ok
<rsalveti> will push your patch to my x-loader repo
<cooloney> sebjan, awesome, i will send out patch soon
<ogra_ac> berco, so talking to our audion kernel guy, he proposes to use my fix, what we would have to come up with later in an SRU is an SDP4430.conf that additional links the hdmi interface
<ogra_ac> *audio kernel guy
<lag> cooloney: Do you want me to deal with bug 655746?
<ubot2> Launchpad bug 655746 in linux-ti-omap4 (Ubuntu) "SYNC_LOST_DIGIT errors are reported with some screens (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/655746
<rsalveti> lag: we got the fix already, and we're just testing it
<rsalveti> lag: then we need to push it together with the other fixes cooloney send yesterday
<rsalveti> mostly audio fixes
<lag> np
<lag> Enjoy :)
<rsalveti> if we can get a new update today, we're more than fine
<berco> ogra_ac: I agree, proper fix should come with this SDP4430.conf file
<lag> I'll keep my fingers crossed
<berco> thanks
<cooloney> lag, i am just going to send out the patch, thanks man
<lag> Good stuff
<ogra_ac> berco, right, most important for me is to find a way for the release, we can fix every remaining piece in an update
<mpoirier> sebjan: is bug 655746 the same as bug 653002 ?
<ubot2> Launchpad bug 655746 in linux-ti-omap4 (Ubuntu) "SYNC_LOST_DIGIT errors are reported with some screens (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/655746
<ubot2> Launchpad bug 653002 in linux-ti-omap4 (Ubuntu) "omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/653002
<sebjan> mpoirier: no, they are 2 different problems
<mpoirier> sebjan: ok good.
<lag> mpoirier: You need to speak with robclark regarding the second bug
<mpoirier> lag: I saw your comment in the bug - thanks.
<mpoirier> lag: I would have closed mine had it been a duplication.
<lag> mpoirier: Unlucky ;)
<mpoirier> lag: my hopes got crushed...
<lag> ;)
<rsalveti> cooloney: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commit/71d0d1faf3c40a2c394c73869fc6030ca56b3d12
<rsalveti> ogra: ogra_ac: https://code.launchpad.net/~rsalveti/ubuntu/maverick/x-loader-omap4/es21-fix-voltage/
<ajay> hi all, i have installed ubuntu in Arm board how to compile a deb package for arm enviornment in x86 based system
<ajay> i mean normally if we run dpkg-buildpackage it gets compile and build for x86 so how to do cross compilation and building of package
<hrw> ajay: "xdeb -a armel --apt-source PKGNAME" usually
<hrw> ajay: or "xdeb -a armel --apt-source --only-explicit PKGNAME" even as this builds less components on a way
<mpoirier> lag: have you ever organised a pull request with the linaro tree ?
<lag> I haven't
<rsalveti> davidm: ok, seems we have a good x-loader an kernel now, ogra just uploaded the x-loader and the kernel is on it's way
<lag> I haven't
<lag> But why would it be any different from pulling from any other tree?
<davidm> rsalveti, the kernel patch does not effect user space does it?
<rsalveti> davidm: no, and it should fix the sync lost issue
<mpoirier> lag: it should indeed be simple - but there is no entry on zinc for the linaro tree under /srv/kernel.ubuntu.com/git/ubuntu/
<rsalveti> the only "problem" is that we lost 6 layers support
<rsalveti> but the good thing is that we just don't care :-)
<ajay> hrw thanks , will it take source from local system or repository?
<lag> rsalveti: I care :(
<lag> rsalveti: I have one of those
<lag> ;)
<rsalveti> lag: well, you'll probably get a new one soon ;-)
<davidm> rsalveti, OK, how many lines in the kernel patch ?
<hrw> ajay: one which you have in apt sources
<davidm> I need to understand what the size of the change is
<rsalveti> davidm: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commitdiff;h=b5485d193f8a422901fe7e401542950970121860;hp=c51a91176a94d1035bc8b8891ee0167b98160023
<rsalveti> davidm: some, but the important one is just on-line
<ajay> hrw, no but i am looking something a source what i customized locally want to recompile for arm environment
<hrw> ajay: first xdeb - this will install all deps. then dpkg-buildpackage -b -aarmel
<ajay> hrw, thanks but apt-cache search xdeb doesnot show any package
<ajay> which package needs to be install for getting xdeb command
<hrw> ajay: xdeb is maverick/universe
<ogra_ac> davidm, the size is enough to get us releasable on 10.10.10 and its accepted by kernel and release teams
<ogra_ac> davidm, i'm close to get the sound issue solved too
<rsalveti> vincent-laptop: robclark: sebjan: ouch, got a sync lost :-(
<sebjan> rsalveti: according to mythripk, the patch reduces the occurence of these errors, but we probably still have some issues to fix.
<robclark> sebjan: I wonder about DISPC_GLOBAL_BUFFER... to assign WB pipe buffers to gfx
<ian_brasil_> wow..jorge took an axe to the UDS track names
<rsalveti> GrueMaster: http://people.canonical.com/~rsalveti/maverick/boot/es21/MLO-fix-underflow
<rsalveti> vincent-laptop: https://edge.launchpad.net/~asac/+archive/armel1
 * asac happy to see unity spreading ;)
<ogra_ac> asac, you should see it working here :)
<ogra_ac> looks awesome (the few times it renders fonts instead of blocks at least)
<devilhorns> lol
<mpoirier> rsalveti: I ask sebjan this morning about bug 655746.
<ubot2> Launchpad bug 655746 in linux-ti-omap4 (Ubuntu) "SYNC_LOST_DIGIT errors are reported with some screens (dup-of: 653002)" [Medium,Fix committed] https://launchpad.net/bugs/655746
<ubot2> Launchpad bug 653002 in linux-ti-omap4 (Ubuntu) "omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX (affects: 2) (dups: 1) (heat: 18)" [High,Confirmed] https://launchpad.net/bugs/653002
<mpoirier> mpoirier: here is under the opinion that it is not the same as bug 653002.
<mpoirier> rsalveti: you may have information I haven't seen though...
<rsalveti> mpoirier: well, at least I always get both errors at the same time
<rsalveti> and should be related
<rsalveti> as the problem should be more related with the underflow
<rsalveti> for me it's the same bug
<mpoirier> rsalveti: I saw that your comment on the MLO and xloader.  does an update of both fixes the problem ?
<rsalveti> mpoirier: doesn't fix it, but reduces it
<rsalveti> I'm still getting it while running with sgx
<rsalveti> but normally you should not face it as before
<mpoirier> rsalveti: if you don't run sgx, do you get the condition ?
<rsalveti> mpoirier: well, at least we didn't in our current tests
<rsalveti> even with video playback
<mpoirier> rsalveti: that's good news
<rsalveti> vincent-laptop: you should install clutk, clutter-1.0 and mutter from the ppa
<asac> ogra_ac: haha
<asac> rsalveti: the es20 clutter i hope
<rsalveti> asac: yup
<ogra_ac> cpearson, hey
<ogra_ac> cpearson, could you come over a sec ?
<cpearson> ogra_ac: gimme 5, on the phone
<ogra_ac> ok
<cpearson> good news, bad news, or beer time ?
<GrueMaster> yes
<ogra_ac> cpearson, more of some questions
<ogra_ac> cpearson, i got the tablet at the user creation screen though, but the guys vanished and i dont know where to find them
<cpearson> muwha wha wha
<ogra_ac> and nobody around me does either
 * rsalveti out
#ubuntu-arm 2010-10-07
 * freeflying 
<prpplague> ho ho hum
<prpplague> anyone know what defconfig the canonical folks are using for their kernel?
<eroick> hello, if i'm running 10.10 how can i use rootstock to build a rootfs of 10.04
<rsalveti> prpplague: which kernel, omap4?
<ogra_ac> hrm
<Lellow> hello, i made a rootfs for arm using rootstock and I'm trying to run it in QEMU
<Lellow> it boots but never gives me a console
<Lellow> just stops after starting sshd and ntpd
<rsalveti> sebjan: do you know if we have a working x-loader for blaze es2.1?
<rsalveti> I'm basically using the same tree as panda, but compiled for sdp
<rsalveti> for some reason it just reboots while starting the kernel boot
<rsalveti> if I use the old x-loader vincent gave me (probably es1) it'll be even worse, rebooting at the time it tries to boot the kernel
<rsalveti> without giving any message, even with earlyprintk
<rsalveti> u-boot should be fine, I'm using linaro's one that's based upstream
<rsalveti> it could be that we need a fix in the kernel, but I don't even know now if the x-loader is correct
<sebjan> rsalveti: hi!
<sebjan> rsalveti: for blaze bootloaders: I have some, but they are based on different baselines than yours.
<sebjan> rsalveti: regarding u-boot, this may be the biggest issue: blaze is not supported by Linaro u-boot, and the pinmux is made into the Linaro u-boot...
<hrw> morning
<hrw> JamieBen1ett: hi, did you got touchpad working under maverick?
<JamieBen1ett> hrw: no, its on my list of things to do today. Seems after an apt-get upgrade my wifi has stopped working so now I need to use a wired connection :(
<hrw> JamieBennett: impressive list of failures
<JamieBennett> hrw: right, I'm tempted at a full reinstall as others have reported it working
<JamieBennett> hrw: don't have a lot of time to be investigating it ATM
<hrw> heh... I love that m$ way of thinking..
<JamieBennett> hrw: heh true
<hrw> my Debian rootfs had 6-7 years when I did reinstall just due to x86 ->x86-64 change
<JamieBennett> hrw: impressive
<hrw> on 6 Nov 2006 I moved to amd64 so Debian rootfs will have 4 years soon
<hrw> but I do not use it since @canonical
<rsalveti> sebjan: cool, thanks for the email, just replied
<sebjan> rsalveti: I am preparing a detailed answer, will be ready soon!
<mopdenacker> f**k, Maverick's Initrd's are compressed by lzma on ARM. I didn't expect this. Is this the same on x86?
<ogra_ac> mopdenacker, yes, everywhere
<mopdenacker> It took me a while to figure out. Had to read the magic number to find this.
<ogra_ac> lzcat <initrd_file | gzip > initrd_new
<ogra_ac> easily converted
 * ogra_ac haeds over to the office
<mopdenacker> Hi ogra_ac ! Thanks! LZMA is much slower to decompress... doesn't it slow down the boot process for machines with fast I/O? On OMAP, I can imagine you boot faster because of the slower I/O (MMC for example)
<mopdenacker> Here are the commands to extract the contents of a uInitrd file: dd if=uInitrd of=initrd.cpio.lzma skip=64 bs=1; lzcat initrd.cpio.lzma | cpio -id
<rsalveti> sebjan: cool, thanks
<rsalveti> sebjan: oh, huge capacitor
<rsalveti> we're just removing it
<ndec> ogra_ac: hi! how's dallas!
<ogra_ac> warm :)
<ndec> ogra_ac: question: when is the boot.scr file generated after the partition resize on first boot? is it done in initrd or in real FS?
<GrueMaster> ndec: It is done by jasper in intrd after resize.  After that, it comes from /boot/boot.script and is copied to the boot partition by flash-kernel.
<rsalveti> sebjan: do you know any other difference between sdp and blaze?
<ndec> rsalveti: blaze looks nicer...
<rsalveti> haha, for sure
<ndec> GrueMaster: thx.
<ndec> GrueMaster: by the way, in the daily image the initrd image is not installed in /boot. is that normal?
<ndec> GrueMaster: does the initial initrd (e.g. the one in the image) have any differences from the next initrd images that are generated upon kernel upgrade?
<rsalveti> ndec: sebjan: mopdenacker: hey, blaze es2.1 up and running
<rsalveti> after we removed the capacitor it just boots fine
<sebjan> rsalveti: cool! :)
<rsalveti> with linaro's u-boot and x-loader from my tree
<sebjan> wow
<rsalveti> and our kernel, without any other change
<GrueMaster> ndec: Not sure what you are seeing, but on my system with 20101006 + latest kernel, I have /boot/initrd.img -> initrd.img-2.6.35-903-omap4
<mopdenacker> rsalveti: Yesssss!
<rsalveti> robclark: 864x480
<robclark> yup, that sounds right
<mopdenacker> GrueMaster: One question related to ndec's question. On Blaze, boot.scr gets created with the wrong 'root=' setting. It seems that the 'root' variable if still set to /dev/mmcblk0p2 in the initramfs (scripts/local-bottom/jasper_setup)
<mopdenacker> GrueMaster: do you know where this root variable is defined? Is supposed to have the same value as the 'root' kernel parameter?
<GrueMaster> Is this a fresh image?  jasper is supposed to change it to match the uuid of the boot partition, whis won't matter what drive type or location.
<GrueMaster> which
<ndec> GrueMaster: but do you have the file initrd.img-2.6.35-903-omap4? i am seeing a broken link, not actual file
<GrueMaster> Yes
<GrueMaster> Have you run oem-config successfully?  One of the last steps is that it runs some of the kernel post-install scripts (one of which generates the initrd.img file).
<GrueMaster> It does this so that it can remove jasper.
<ndec> oh. i see... i was looking at FS before doing the install
<GrueMaster> There are a lot of things that get done on first boot that help to keep the image small for downloading.  Normal images wouldn't have these issues, but preinstalled images are a different animal.
<mopdenacker> GrueMaster: I was talking about the initial uInitrd found in preinstalled images (downloaded a fresh one this morning).
<GrueMaster> That is built during image build time and is not part of the image.
<GrueMaster> At least the initrd.img isn't.
<mopdenacker> GrueMaster: do you know where jasper sets this 'root' variable?
<GrueMaster> I'd have to look at the jasper source.  Give me  a moment.
<GrueMaster> Looking at the source, it pulls this from /proc/cmdline
<GrueMaster> So the initial boot.scr (created during image creation) is where it is initially set.  After jasper resizes the rootfs, it uses the UUID.
<mopdenacker> GrueMaster: ahah, very interesting!
<mopdenacker> GrueMaster: So, on the Blaze, even if we don't use the boot.scr file, it is still used as input.
<mopdenacker> That's something we can fix then.
<mopdenacker> GrueMaster: would you be so kind to tell me in which file you've read this, please?
<GrueMaster> What do you need to fix?  We have blaze working here with an updated MLO and u-boot.bin on the standard image.
<GrueMaster> Using our boot.scr
<ndec> GrueMaster: ? you at least had to manually change the initial boot.scr to set mmcblk1p2, no?
<ndec> GrueMaster: on blaze the SD card is on mmcblk1, not mmcblk0.
<GrueMaster> Oh.  yes.  THe image that we booted had already run jasper.
<ndec> GrueMaster: ok. so we are trying to run the image before jasper. e.g.  do the resize and install on blaze.
<ndec> so we change the initial boot.scr with /dev/mmcblk1p2, install goes fine. but at the end the new boot.scr is generated with wrong label.
<GrueMaster> According to rsalveti, all you need to do is change the MLO, u-boot.bin, and modify the root= line in the boot.scr.
<mopdenacker> ndec: I didn't touch boot.src
<mopdenacker> ndec: I just booted "manually", typing the commands in boot.scr, but didn't touch this file.
<mopdenacker> ndec: let me check that this works.
<ndec> mopdenacker: ok. but what is your value for root?
<ndec> mopdenacker: settings bootargs or reading the boot.scr is the same, if you use the same values. the boot.scr is not read by jasper.
<ndec> GrueMaster: i agree with this. but mopdenacker tried and it didn't work... but given what's just ^^^ that might be an issue on our end..
<mopdenacker> ndec: root=/dev/mmcblk1p2 in the bootargs, but I left boot.scr with "root=/dev/mmcblk0p2" (didn't touch this file, since it wasn't used)
<mopdenacker> Or so I thought
<ndec> GrueMaster: rsalveti: i have to go now... but I will come back later in the evening. in the mean time if you could try to run the install on blaze and check the partition label, and verify flash-kernel.conf, that would be nice.
<GrueMaster> I'll check it as soon as Ican pry it away from rsalveti.  :P
 * rsalveti reading
<rsalveti> yep, will try now :-)
<rsalveti> yee, second blaze display working!
<rsalveti> with help from vincent-laptop :-)
<mopdenacker> rsalveti: nice to be working at the same place. I hope you will have opportunities to come to TI in Nice :-)
<rsalveti> mopdenacker: yeah, that'd be cool :-)
<mopdenacker> GrueMaster: nah, didn't work. Even with a correct boot.src and root= boot parameter (/dev/mmcblk1p2), I still end up with root=LABEL=emmcroot in boot.scr after reboot.
<orbarron> hey all --> how do I switch form netbook version to desktop version? (not from GUI)
<mopdenacker> It took the label from /dev/mmcblk0p2, instead of using the one from /dev/mmcblk1p2 (the SD card). There's a bug somewhere, though I don't see where...
<GrueMaster> mopdenacker: checking...
<rsalveti> mopdenacker: I'm trying right now with a new image
<mopdenacker> GrueMaster: rsalveti : thanks! Gotta go. Good luck! Keep us posted!
<rsalveti> mopdenacker: sure, see ya
<robclark> orbarron: /etc/gdm/custom.conf
<robclark> (or do it from gui)
<robclark> or if you disable automatic login, you can choose on each login which session you want
<orbarron> ahh thanks robclark
<dhiry2k> getting error in installing xfce4 or lxde as no such package
<dhiry2k> apt-get update working fine
<dhiry2k> apt-cache search also not showing package entry
<dhiry2k> what repository need to be add for marvick arm
<dhiry2k> to get these packages
<dhiry2k> any one can help me to get install lxde in arm
<rsalveti> jo-erlend_igep: you're luck, both network and display patches got applied
<ogra> mopdenacker, so here is the code snippet caring for setting the UUID http://paste.ubuntu.com/508141/
<ogra> mopdenacker, i dont see how it could possibly be worng
<devilhorns> ogra, while your here, quick question ... is zeitgeist a "must have" ? or can I implement the searching in a different way ?
<ogra> devilhorns, i think ts a requirement , how else would you implement it ?
<devilhorns> ogra, not sure yet :) but I noticed that zeitgeist is python based, so I want to implement searching in a different way so it isn't slow
<ogra> (teh zeitgeist packages are properly maintained already, if another solution adds extra maintenance work we wont be able to use it)
<devilhorns> ogra, I haven't really thought much about a replacement yet, but was just curious if I "can" replace it :)
<cooloney> mpoirier, hey man
<cooloney> mpoirier, i saw your git pull request about ftrace, that's good, why not for ti-omap4 tree or master only linaro?
<ogra> devilhorns, with something thats maintained by the ubuntu-desktop team and that offers the same functionallity you can
<devilhorns> ogra, gotcha
<devilhorns> thanks
<ogra> (i doubt you will find such a thing, good luck :))
<devilhorns> hehehe
<mpoirier> cooloney: sorry I missed you post - I stepped out for lunch.
<cooloney> mpoirier, np, man. i saw your ftrace git pull request
<mpoirier> cooloney: Tim ask me to check it in to linaro first.  Also, I haven't tested for omap4 - it should work but I won't submit something I haven't tested.
<cooloney> mpoirier, ok, gotcha
<cooloney> mpoirier, i will try to rebase you patch on our current omap4 tree
<mpoirier> cooloney:  fantastic but make sure you test - again, I haven't tried on omap4.
<mopdenacker> ogra: thanks! That's the code we've been looking at too. The only thing that could be wrong is the value of the 'root' variable.
<cooloney> mpoirier, yeah, sure. i will test. so how did you test it?
<cooloney> on omap3?
<mpoirier> omap3 yes.
<ogra> mopdenacker, right and thats handed over by the kernel to the environemnt
<mpoirier> I simply enabled the feature and tested a function.
<cooloney> mpoirier, good, understand
<mpoirier> there is another set of patches to enable graph testing but that will be harder to put in.
<mpoirier> the patches don't apply properly *and* it is deep in assembler macros and obscure symbols...
<cooloney> mpoirier, yeah, i tried that before.
<cooloney> mpoirier, painful
<mpoirier> the graph tracing patch set ?
<rsalveti> mopdenacker: I'm just debugging it, doesn't work here because for some weird reason root must be wrong and then we hang at grep
<rsalveti> and I can't run the first boot
<mopdenacker> ogra: interesting. I didn't know that the kernel was passing environment variables to the init process (did I get it right?)
<cooloney> mpoirier, not try to test, but just apply with dynamic ftrace together
<cooloney> many conflict
<cooloney> but maybe it changes
<mopdenacker> rsalveti: weird indeed.... Good luck!
<mpoirier> cooloney: your are right, the first patch set for dynamic tracer weren't applying properly.
<mpoirier> cooloney: I was able to apply the first patch set after a lot of work.
<cooloney> mpoirier, yeah, ftrace is quite important. thx for your work
<mpoirier> but the final submission by Rabin (the author) applied seamlessly.
<cooloney> mpoirier, so how about the upstream status of this dynamic ftrace patchset
<cooloney> mpoirier, cool
<ogra> mopdenacker, well, the kernel is *supposed* to hand over the whole cmdline to init ... probably it doesnt
<mpoirier> cooloney: it has been accepted.
<cooloney> mpoirier, it's in rmk's upstream or mainline?
<mpoirier> cooloney: now I have to get graph tracing in.  I'll need help from the implementor - I have to hunt him down.
<cooloney> mpoirier, great, author always helped a lot
<mopdenacker> ogra: so each kernel parameter becomes an environment variable?
<mpoirier> cooloney: http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=shortlog;h=80be7a7f642719bf99fc49692fc77d6333f51a73
<ogra> mopdenacker, each one that has an equal sign
<mopdenacker> mopdenacker: very very cool! :-)
<ogra> bug 586386
<ubot2> Launchpad bug 586386 in linux (Ubuntu Maverick) (and 1 other project) "omap3 kernel should hand over all comdline args to the init environment (affects: 1) (heat: 27)" [Medium,Fix released] https://launchpad.net/bugs/586386
<ogra> gah
<GrueMaster> rsalveti: dd if=uInitrd of=initrd.cpio.lzma skip=64 bs=1; lzcat initrd.cpio.lzma | cpio -id
<cooloney> robclark, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
<ndec> GrueMaster: rsalveti: ogra: hi. i am back. did you try booting the pre installed image on blaze?
<GrueMaster> Working on it now.  Looks like a kernel bug.
<ndec> GrueMaster: root is not propagated in init properly?
<GrueMaster> Just found out it is a kernel config option that was missed.
<ogra> ndec, right, as GrueMaster aid
<ogra> *said
<ndec> GrueMaster: which one?
<ndec> this is a bummer...
<ogra> ndec, seems on a rebase the fix for bug 586386 got lost
<ubot2> Launchpad bug 586386 in linux (Ubuntu Maverick) (and 1 other project) "omap3 kernel should hand over all comdline args to the init environment (affects: 1) (heat: 27)" [Medium,Fix released] https://launchpad.net/bugs/586386
<ogra> ndec, its not as bad as it looks though, we'll just offer a fixed uImage to put in place on first boot
<ogra> we're just testing the fix
<ndec> we can't upload the fix?
<ogra> we can, but only as SRU
<ogra> bad timing to find it
<ndec> ogra: yep. sorry about that.
<ogra> ndec, ??
<ndec> ogra: i wish we found this earlier ;-(
<ogra> ndec, our kernel team screwed it up
<ogra> its good that yo found it at all, there are other bits relying on the feature
<cooloney> that option was enabled in our master branch to support this feature for omap3
<cooloney> need to carry it to our ti-omap4 as well
<rsalveti> cooloney: still building the kernel?
<rsalveti> mopdenacker: I found one bug here, so we're going to also need a new uImage together with MLO and u-boot
<rsalveti> but then we can successfully boot blaze
<rsalveti> and the installer should just work fine :-)
<ndec> rsalveti: and new boot.scr, since it needs to have mmcblk1p2
<rsalveti> ndec: yeah, right
<rsalveti> ndec: vincent-laptop: and about wifi and bt modules, should it work the same way as panda?
<ndec> rsalveti: well... no!
<rsalveti> sorry, don't know much about blaze hardware
<ndec> blaze has a different wlan chip (1283) instead of 1271
<ndec> we don't have an up-to-date driver for 1283. but we are trying to get it.
<rsalveti> ndec: ok then, less things to check :-)
<ndec> rsalveti: well you can play with xorg.conf and create 2 desktops ;-) we tried this already!
<rsalveti> ndec: yeah, just enabled the second framebuffer, but didn't change X to use both screens
<ndec> there is an accelerometer and proximity sensor on blaze. i think drivers should be there. never tested.
<rsalveti> had to check the installer problem
<rsalveti> ndec: do you have the xorg.conf already around?
<ndec> what would be nice is virtual desktop supporting both screens so that we can move windows from top to bottom screen... and also support for multiple touchscreen
<ndec> yes, let me find it
<rsalveti> yeah
<ndec> rsalveti: http://paste.ubuntu.com/508281/
<rsalveti> ndec: cool, thanks a lot
<rsalveti> will try in a bit
<prpplague> cooloney: hey you got that card ready?
<ndec> rsalveti: since we are talking about blaze and x11... blaze has a custom keypad. we probably need to create a new kbd layout for it. for now we have a quick hack and we create /etc/X11/Xmodmap. but that breaks panda ;-)
<ndec> rsalveti: what do you recommend to handle the blaze keypad?
<cooloney> prpplague, got some issue after upgrading, please wait for a while. sorry
<prpplague> cooloney: doh
<prpplague> cooloney: runnign out of time for today
<cooloney> prpplague, i tried to dd out my 4G rootfs to a image file, and dd to your card. but cannot boot my panda
<prpplague> cooloney: don't have a tar ball of the rootfs i can use?
<cooloney> prpplague, so i am copying over our daily image to your SD card, and have to install it on the board.
<ndec> rsalveti: GrueMaster: ogra: I am trying to create pre installed image where our package (which are in OMAP PPA) are also pre installed. So basically we download cdimage, chroot in rootFS and install all our stuff. but do you think we can install new kernel as well? I am not sure if that should/would break the installer.
<rsalveti> ndec: don't know the right answer now, but probably creating a new key layout for it
<rsalveti> then we can identify if we're running blaze and load the correct kbd layout
<ndec> ogra: ^^^^ about the blaze keypad, in case you have an idea.
<ogra> ndec, you should be able to do it chrooted in the SD, it gets tricky if you loop mount
<ogra> (replacing the kernel)
<ndec> rsalveti: if you boot on blaze, and look at the X11 log, you will see that the keypad is detected (omap4-keypad). so it's probably just missing a config to load the proper keymap, right?
<cooloney> prpplague, i don't have the tar rootfs. and if is the ubuntu minimal rootfs from rootstock, we need to install extra applications.
<cooloney> prpplague, so if got the daily image installed properly, please keep the SD for development and testing
<rsalveti> ndec: probably
<ndec> ogra: in fact I had to loop mount the ext3 and fat32 as well. I created a fake flash-kernel.conf so that flash kernel would flash inside the .img. it seemed to work.. but I wanted to hear from you what you think.
<rsalveti> ndec: you can update the kernel, but just make sure you also generate a new uinitrd
<rsalveti> because of the proper kernel modules, if you're changing versions
<cooloney> prpplague, actually i tried to tar out the rootfs tar ball, it is quite slow for me
<ndec> yes, otherwise modules aren't found in initrd. we had this the first time ;-)
<ndec> in fact it seems we were able to even flash the new uImage and uInitrd in the .img using flash-kernel ;-)
<rsalveti> ndec: yep
<rsalveti> the problem you can easily find on the pre-installed image is lack of inodes and space
<rsalveti> because you still didn't run the resize
<rsalveti> so you're kind of limited in what you can install and edit before running the first boot
<prpplague> rsalveti: guys i'm dying here, has _anyone_ got an ubuntu file system i can use?
<rsalveti> prpplague: sure, I have a valid sd card here for panda
<cooloney> prpplague, i'm installing the daily image on your SD, just a minutes
<ndec> rsalveti: well... i forgot to mention that we resize it first... well in fact everything is here: http://omappedia.org/wiki/Add_Packages_To_Ubuntu_Preinstalled_Images
<prpplague> cooloney: ahh ok
<rsalveti> ndec: oh, ok
<rsalveti> ndec: so you're fine
<ogra> ndec, with fake flash-kernel i see no prob
<ogra> just make sure to remove it again ;)
<ndec> ogra: well, we forgot the first time ;-)
<rsalveti> cooloney: OK, I can confirm that jasper works with this kernel fix
<cooloney> rsalveti, thx, man
<ndec> rsalveti: cool! is it cross compiled or native?
<cooloney> ndec, my testing kernel is cross compiled
<ndec> given that it only took a few minutes I think I know the answer
<cooloney> rsalveti, just tested that
<ndec> cooloney: can you post a native kernel somewhere later in the day?
<cooloney> native building kernel?
<cooloney> i will try to build it in our schroot environment
<rsalveti> ndec: I'm just publishing all the needed files for blaze to work
<rsalveti> with the pre-installed image
<rsalveti> so GrueMaster can actually test it
<rsalveti> hold a sec
<rsalveti> ndec: GrueMaster: http://people.canonical.com/~rsalveti/maverick/blaze/
<ndec> rsalveti: cool! will test tomorrow... no blaze at home ;-)
<rsalveti> that should be enough to get blaze up and running with the installer
<ndec> uboot is based of linaro uboot, right? not mainline, nor TI uboot?
<rsalveti> ndec: based on linaro, but very very close with upstream
<rsalveti> the only missing part now is the new mmc driver
<rsalveti> but doesn't affect us
<ndec> rsalveti: can you send your patch to me and sebjan?
<rsalveti> ndec: what patch?
<rsalveti> :-)
<ndec> rsalveti: what? uboot linaro works out of the box?
<rsalveti> the x-loader is my tree on gitorious and linaro is basically from git.linaro.com
<rsalveti> ndec: yup
<rsalveti> I just had to build it for omap4430sdp
<ndec> rsalveti: well this is a surprise... so sometimes things work out of the box ...
<rsalveti> will fill a bug for this on launchpad soon
<rsalveti> ndec: it's basically because it's quite simliar with upstream
<rsalveti> so it shouldn't be an issue
<ndec> i am sure ogra which tablet would work out of the box too ;-)
<rsalveti> but it'd be good if we could check the padmux setting
<rsalveti> because I know sakoman did change the padmux for panda and not for blaze
<rsalveti> don't where he got the values for blaze
<rsalveti> ndec: probably, would be good to test
<ogra> ndec, well, i cant even build the kernel ... the display driver seems to dep on some headers i miss
<ndec> rsalveti: you might know this already, but our TI uboot based on upstream too is here: http://dev.omapzoom.org/?p=bootloader/u-boot.git;a=shortlog;h=refs/heads/omap_upstream
<ndec> ogra: hehe I had told you ;-)
<ogra> it builds if i disable all omap2 dss drivers thogh
<ogra> not sure how useful that still is :)
<sakoman> ndec: I don't recommend using that omapzoom u-boot branch
<sakoman> it is already obsolete
<rsalveti> yeah
<ndec> ogra: it's useful for blaze. even though it's called omap2, it means everything after omap2.
<rsalveti> sakoman: did you also review the sdp pad mux?
<ndec> sakoman: euh? isn't that the tree TI uses for its release?
<ogra> ndec, yeah, i guessed so much
<sakoman> ndec, perhaps it is, but that doesn't mean it is the latest and best ;-)
<ndec> sakoman: in fact it probably means, it's not !
<rsalveti> ndec: sebjan said TI tested blaze with upstream u-boot
<sakoman> rsalveti: I'll take a look at the sdp pinmux and see if anything needs to be changed
<rsalveti> sakoman: cool, thanks a LOT :-)
<rsalveti> need to buy you some beers
<sakoman> rsalveti: last time I checked it was ok, but perhaps new issues have been found
<rsalveti> because then we can just use upstream (and linaro) for all omap4 boards
<rsalveti> even omap3
<ndec> sakoman: the problem is that TI developers will continue to push into dev.omapzoom.org...
<sakoman> rsalveti: I am working hard to make that possible
<rsalveti> yeah, I know :-)
<ndec> sakoman: you looking at tablet too?
<sakoman> rsalveti: I will have relocation patches for mainline panda and sdp in a day or two
<sakoman> ndec: I only work on hardware that I have :-)
<rsalveti> sakoman: cool
<sakoman> rsalveti: panda works fine, but sdp still has issues
<ndec> sakoman: that's safer
<rsalveti> sakoman: what issues are you currently having at sdp?
<sakoman> the version with relocation takes a fault after printing the ram size
<rsalveti> oh, ok
<sakoman> in the middle of tracking down the problem
<rsalveti> sakoman: but do you know any issue with current tree?
<sakoman> no issues with the released v2010.09 as far as I know
<sakoman> only with top of tree post the forced change to relocation
<rsalveti> awesome, maybe still some wrong pad mux setting, but here it seems to be running fine
<sakoman> but then pretty much all arm boards other than beagle and overo are broken :-)
<rsalveti> but didn't test bt and wlan
<rsalveti> lack of drivers
<rsalveti> :-)
<sakoman> and soon panda and sdp4430
<sakoman> the current version of the patch is in my omap4-exp branch
<sakoman> about a dozen or so of those patches should hit mainline in the next week
<rsalveti> nice, too bad I don't have a blaze to test :-(
<rsalveti> I just got one here because I'm currently at TI
<sakoman> my blaze has ES1.0 processor :-(
<sakoman> and my panda an already obsolete ES2.0
<ndec> rsalveti: you can get a blaze: http://svtronics.com/market_omap ;-)
<GrueMaster> sakoman: ES2.0 8L should still work with the release image.
<rsalveti> ndec: hahaha :-)
<rsalveti> wayyy too expensive
<sakoman> GrueMaster: that doesn't help me doing x-load and u-boot patches for ES2.1 changes :-)
<GrueMaster> No, but you can build them on your 2.0.  :P
<ogra> lool, do you know why i cant find any vfp stuff in the -dumpspecs gcc comand ?
<ogra> i though we enabled it by default ages ago
<ndec> ogra: sometimes when installing a package, it triggers a 'system restart required' event. how can i make a package that does this?
<ogra> you dump something into a dir (i have to check the exact path)
<ogra> ndec, touch /var/run/reboot-required i think
<ndec> ogra; well it worked on my laptop... so I just need to do this in postinst script.
<cooloney> ndec, the patched native built kernel is here http://people.canonical.com/~roc/kernel/pass_init/linux-image-2.6.35-903-omap4_2.6.35-903.14_armel.deb
<cooloney> ndec, http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
<ndec> cooloney: thx. how do you build native kernel? qemu or on real hw?
<cooloney> ndec, also i pushed the patch in my branch.
<ndec> cooloney: i saw your SRU email too
<cooloney> ndec, we setup schroot environment in our built server
<cooloney> so i schroot to maverick-armel to do native building
<ndec> but on hw, not qemu?
<cooloney> oh, it is on a x86 server's schroot environment.
<cooloney> ndec, it looks like it doesn't use qemu to me
<lool> ogra: arm-linux-gnueabi-gcc -v 2>&1|grep vfp
#ubuntu-arm 2010-10-08
 * ogra hugs lool ... awesome, thanks !
<lool> ogra: how is it going for you guys?  is the latest hardware pleasing?  :-)
<ogra> its wonderfully fast
<ogra> we have 400MHz RAM now
<ogra> still enough small issues with 1080p video processing and sound though
<ogra> but release looks really good for panda, blaze and oma4 tablet :)
<ogra> *omap4
<sakoman> rsalveti: is the ability to saveenv to sd cards something of interest (on panda and beagle xM)?
<sakoman> (would require a raw partition to be added to the sd card)
<rsalveti> sakoman: probably, but from the distro pov
<rsalveti> *not
<ogra> sakoman, could it just create boot.scr right away ?
<sakoman> ogra: no, file systems in u-boot are read only
<ogra> ah, sad
<sakoman> indeed
<ogra> that would be the most elegant solution
<ogra> read boot-scr as input and write it again on saveenv
<cooloney> sakoman, so we modify u-boot to support this feature, heh -:)
<sakoman> on the other hand, with a bit of work one might be abble to eliminate the FAT partition and put MLO and u-boot in the raw partition
 * ogra is not a big fan of raw partitions from an image creator POV
<sakoman> cooloney: I suspect that would be difficult to get upstream
<ogra> painful to create in a sane way (you need to wrap a non data partition around it) ...
<sakoman> ogra: understood, it would require 3 carefully crafted dd commands
<ogra> and a lot of math for parted (which we use on the image builders)
<cooloney> sakoman, it looks like no other choice to me, since we need to update boot.scr which is in SD partition.
<sakoman> OK, just wanted to ask
<ogra> cooloney, well, we have ubootenvtools which can read/write the environment from/to NAND already
<cooloney> ogra, or is that possible for us to store boot.scr on the board instead of SD
<ogra> *uboot-envtools
<sakoman> it is a technique used in phones that run from emmc
<cooloney> ogra, cool, man
<cooloney> ogra, that's what i wanna ask
<lool> sakoman: One thing which I found hard the last time I looked at this kind of stuff is creating an environment from userspace
<lool> sakoman: The current tools allow manipulating it, but not creating one from scratch
<sakoman> lool: understood, I'll take a look at that.  may not be a big deal
<lool> sakoman: I worked on a set of patches a while ago to transform the tools in the u-boot tree to work on files as well as MTDs, but for some reason I had an error in the checksum part of things, and never took the time to track it down
<lool> I didn't like the result though, I had tons of ifdefs; I should have refactored the code to have backend specific read/write instead of ifdefing all the read/writes
<sakoman> lool: want to send me the patches?
<lool> if I manage to find them
 * lool scratches head
<lool> oh I actually found the perl script I had started to do it in perl instead
 * sakoman has been known to user perl on occasion
<lool> sakoman: Hmm did not find it; I found files from after and before, so either it's on my previous laptop now powered off, or it was rm-rfed in a kill-this-old-stuff fury
<sakoman> lool: no problem
<lool> If I come across them, I'll post them your way
<devilhorns> man, the docs for zeitgeist are just horrible :(
<hrw> nirnung
<lag> nirnung hrw
<berco> I heard there's a magic launchpad ppa where I can find debug versions of packages... where is that? Looking for libasound2-dbg package
<persia> It's not a ppa.
 * persia verifies that armel ddebs are present
<persia> Yeo.  Just add "deb http://ddebs.ubuntu.com/" to your sources.list
<persia> After that, `apt-get install libasound2-dbgsym` ought work.
<berco> persia: thanks, I'm going to try that, sounds good
<persia> http://ddebs.ubuntu.com/pool/main/a/alsa-lib/libasound2-dbgsym_1.0.23-1ubuntu2_armel.ddeb is the file you want, if you want it for some other reason
<hrw> persia: how libasound2-dbgsym differ from libasound2-dbg?
<persia> hrw, It's a matter of packaging.
<hrw> ok
<persia> If pkg-create-dbgsyms is installed on the buildd, when dh_strip runs, it creates the -dbgsym ddeb automatically.
<persia> If the packager chooses to override dh_strip to create a -dbg package, it doesn't do this, and the -dbg packages sits in the normal archives.
<persia> Personally, I prefer that folks do not create -dbg packages, as it clutters mirrors for a rare use case.
<persia> Mind you, I felt the other way before pkg-create-dbgsym existed, and I'm still undecided which is the best approach in Debian, but for Ubuntu, not creating it is cleaner.
<berco> persia: thanks a lot for the detailed explanation :)
<persia> berco, No problem.  I'm always happy to answer questions in arbitrary detail where I know the answer.
<hrw> persia: thx
<cwillu> has rcn been seen lately?
<hrw> ~seen marcos
<cwillu> hrw, is there an implication I'm to infer from that? :)
 * cwillu checks his log
<cwillu> wow, I've managed to miss him... every day for the last 2 weeks
<hrw> cwillu: no, I just have a question to markos
<cwillu> okay
<hrw> davidm: hi
<davidm> Hello
<hrw> davidm: you are at London now?
<jo-erlend> does anyone know the power consumption of OMAP4 compared with OMAP3?
<cwillu_at_work> jo-erlend, might have more luck in #beagle, I know there's some ti guys that hang around there (not sure if they're here too)
<davidm> hrw, Yes I'm in London now
<hrw> jo-erlend: #beagle and #pandaboard in ~6h from now - ask TI people
<hrw> jo-erlend: timezone differences kill
 * hrw bootstraps armelhf toolchain
<jo-erlend> thanks for the advise. On the release party for Maverick in Oslo, we'll focus on Green IT, and in that context I'll present the igepv2. Thought it'd be nice to talk a little about the future as well.
<hrw> jo-erlend: pandaboard for sure is nicer desktop replacement then igep. and both should take <20W fully equipped
<amitk> jo-erlend: power work is still WIP for OMAP4 and I don't think any public numbers are shared with comparisons between omap 3 & 4
<hrw> where fully equipped for me means: board, keyboard, mouse, some networking (ethernet/wifi), some storage
<rsalveti> mopdenacker: nice, good to know if also worked fine for you :-)
<rsalveti> ndec: mopdenacker: are we going to have the usual call?
<mopdenacker> hi rsalveti ! No, I believe that the call is cancelled this week...
<ndec> rsalveti: no. i tried to cancel the meeting... but I think something got messed up with TI exchange server ;-) did you receive the cancellation?
<rsalveti> ndec: not yet, but my network here sucks
<rsalveti> cool, just to know :-)
<ndec> rsalveti: ok... so please pass the message around in case some did not get it
<rsalveti> ndec: sure, thanks
<ndec> rsalveti: ogra: the customization of pre installation worked like a charm! even with kernel upgrade. so we have pre installed image with all TI packages! and wifi work right after install
<rsalveti> ndec: awesome :-)
<mopdenacker> That's very cool. Now we know how to do all this with other boards (in private projects, don't worry, there are no new OMAP4 boards to support) ;-)
<ogra_ac> ndec, wohoo !!!
<ndec> ogra: next step is flash the .img in eMMC and boot without SD card ;-0
<ogra_ac> thats for natty though :)
<ogra_ac> but we'll solve it
<ndec> well.. we have to do it for maverick... all our releases need to work from emmc
<ndec> so we will do something short term, until a better solution is there.
<ogra_ac> ndec, well, create a little script that tars up the rootfs while running from it (make sure to exclude all tmpfs mounts), fire up a partitioning tool, partition, untar ...
<rsalveti> yeah, same thing if you want to use with external usb
<ndec> ogra_ac: we could do this in initrd at first boot before resizing, right?
<ogra_ac> ndec, hmm, that would work but would be slow
<ndec> then we would resize the emmc or any other external drive, and continue installation
<ogra_ac> yep
<ogra_ac> will require some hacks to jasper
<ndec> why would that be slower than what you proposed?
<ndec> you could have an extra param in boot.scr such as relocateroot=/dev/xxx
<ogra_ac> ndec, not slower just more annoying :) what i proposed would run from a running system so the user couls play solitaire while it copies :)
<ndec> ogra: let's fire solitaire in ascii from initrd then...
<ogra_ac> haha
<ogra_ac> ndec, well, seriously i dont think it matters where you run the copying so jasper seems to be a good place
<ndec> ogra: when you resize the partition to you erase partitions that might exist, or do you just use free space?
<davidm> ogra_ac, is the TI call happening today?
<rsalveti> davidm: nops, canceled
<ogra_ac> ndec, when the resizing runs the mbr and partition table were already overwritten by your zcat/dd
<davidm> OK thanks
<ndec> well, but for emmc, if I have /dev/mmclk0p1 and /dev/mmcblk0p2 on emmc. and I try to relocate to one of them, will jasper remove the other partition?
<ogra_ac> ndec, so there are no partitions i need to care about in the SD case ... for eMMC you need to come up with something ... a question or some such
<ogra_ac> jasper wont remove anything
<ogra_ac> hmm
<ndec> davidm: sorry.. tried to cancel the meeting request.. but ubuntu/thunderbird does not like our exchange server... or maybe the other way around.
<ogra_ac> though probably it would
<ogra_ac> since we forcefully create the new partition table
<davidm> ndec, NP
<lag> "Thank you for holding. Please wait for the chair person to join" Arrrrrrrrrrrrrrrrrrrrrrrrr
<ogra_ac> ndec, i got "AnnulÃ©: Ubuntu / OMAP working group weekly" in my inbox
<ogra_ac> so it partially worked at least
<ndec> lag: no call today ;-)
<lag> Thanks for the email ;)
<ndec> ogra: yes. for someone that knows a little of French at least!
<ogra> rsalveti, http://paste.ubuntu.com/508854/
<lrg> ogra: do you have an ES2.0 panda ?
<prpplague> lrg: yea they have a couple
<prpplague> lrg: greetings vtw
<prpplague> btw
<lrg> prpplague: greetings
<lrg> prpplague: I now have some time in my schedule for Panda config
<lrg> prpplague: although, I'm having some issues even geting it to boot atm :(
<lrg> prpplague: I have USB keyboard/mouse + ethernet plugged in and when I boot it keeps on detecting new keyboards/mice/ethernet until I physically remove the connectors
<lrg> I had 35 keyboards
<prpplague> lrg: uh never seen that before
<lrg> are you ES2.0 ?
<prpplague> yea and es2.1
<lrg> ok
<lrg> can you send me a link to your image ?
<prpplague> http://omapedia.org/wiki/OMAP_Minimal_Linux_Main
<prpplague> lrg: validation images are there
<lrg> prpplague: thanks !
<prpplague> brb
 * prpplague needs hot brown liquid
<hrw> prpplague: filled with holy IT fuel?
<prpplague> hrw: 1,3,7-trimethyl-1H-purine-2,6(3H,7H)-dione
<ogra_ac> lrg, 2.0 and 2.1
<ogra_ac> lrg, i though you talked with rama all day yesterday about it
<lrg> ogra: yeah - I just now have a cable to connect it to my monitor :)
<ogra_ac> ah :)
<lrg> ogra: did you see my previous remark on the multiple keyboards etc
<lrg> seems weird
<lrg> unless I have the wrong image ?
<lrg> but Rama sent me the link
<ogra_ac> lrg, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
<lrg> ogra: yep, that's the link I used
<ogra_ac> great
<lrg> ogra: ok, so I may have some flakey hardware here
<ogra_ac> lrg, just zcat it to the SD
<lrg> yeah - did all that
<lrg> hmm
 * ogra_ac didnt see your remark about kbd, whats wrong ?
<lrg> prpplague: I now have some time in my schedule for Panda config
<lrg> <lrg> prpplague: although, I'm having some issues even geting it to boot atm :(
<lrg> <lrg> prpplague: I have USB keyboard/mouse + ethernet plugged in and when I boot it keeps on detecting new keyboards/mice/ethernet until I physically remove the connectors
<lrg> <lrg> I had 35 keyboards
<ogra_ac> wow
<ogra_ac> thats odd
<lrg> ogra: I cant get past the welcome screen due to this
<lrg> yeah, seems very odd
 * ogra_ac has never seen such behavior
<lrg> afaik, I'm the only one with this behaviour
<ogra_ac> are you sure its a 2.0 ?
<ogra_ac> we dropped support for 1.0
<lrg> yeah, green board - Rama confirmed
<lrg> got it last week
<ogra_ac> k
<ogra_ac> well, there are several 1.0 that are green too
<ogra_ac> does it have a wlan chip ?
<ogra_ac> (1.0 didnt)
<lrg> yes
<ogra_ac> k
<ogra_ac> then its definitely 2.0
<lrg> everything failing is on the LAN/USB connector
<ogra_ac> and green means 8 layer ... that should just work
<ogra_ac> we tested here for the whole week
<lrg> ok, it's looking more like hw
<ogra_ac> any hub involved ?
<lrg> no
<ogra_ac> and did you try another kbd
<lrg> no, not yet - but the ethernet also is detected 36 times
<lrg> with different MAC addresses
<prpplague> wow i've never seen that before
 * ogra_ac neither
<prpplague> lrg: do you have anything plugged into the OTG port?
<lrg> I wonder if the USB/LAN connector is needing reflowed
<lrg> prpplague: no
<lrg> prpplague, ogra: ok, let me try todays image
<armin76> nice, 36 ethernets!
<armin76> hope you do a trunking with them!
<lrg> hehe
<dhiry2k> hi all i have installed 10.10 in my board after gdm login input given it just shows blank
<dhiry2k> i mean it is stopping in between after login input given
<cwillu_at_work> rcn-ee, poke poek
<rcn-ee> hey cwillu what's up
<cwillu_at_work> still in the kernel business?
<cwillu_at_work> incidently, if anyone is talking about btrfs on sd, 2.6.37 is going to improve some matters
<rcn-ee> yeah..  well not today, pulling the 302 out of my mustang. ;) do they have anything different from mainline btrfs?
<cwillu_at_work> which, .37, or the mustang?
<cwillu_at_work> I have an ecu from a '90 miata sitting on my desk, if that counts for anything
<rcn-ee> yeah, i have the mainline 2.6.36-rc7 built..  was there more for btrfs that you were looking at.. ;)
<cwillu_at_work> actually, that's not a bad version
<rcn-ee> it's only a couple days old too. ;)
<cwillu_at_work> 2.6.37 should have raid5/6, and also shared block allocations for small devices such that enospc issues are gone
<cwillu_at_work> yep;  .37rc6 has a noisy dmesg in btrfs :p
#ubuntu-arm 2010-10-09
<t154793> yeah
<dhiry2k> hi us ubuntu 10.10 ready for armel?
<dhiry2k> is  ubuntu 10.10 ready for release ?
<dhiry2k> packages downloaded while doing rootstock command where get stored in system?
<dhiry2k> does it download each time while rerunning rootstock command
<ogra_ac> yes, use a package proxy like approx or apt-proxy
<robclark> rsalveti: I picked up a USB drive on sale this morning
<robclark> I'm just copying over my rootfs now
<robclark> you just need to change boot.script to boot with rootfs on USB?
<rsalveti> robclark_: yeah, and remove hdparm it seems
<rsalveti> bug 652873
<ubot2> Launchpad bug 652873 in hdparm (Ubuntu) "after installing hdparm, panda board fails to boot (affects: 1) (heat: 500)" [Undecided,New] https://launchpad.net/bugs/652873
<robclark_> rsalveti: hmm.. I didn't even remove hdparm.. and it booted once so far..
<rsalveti> robclark_: cool then :-)
<ogra_ac> must be a 6 layer issue
<ogra_ac> or flaky HW
<robclark_> could be hd dependent?
<ogra_ac> probably, but i think the other build machines use the same disks
<robclark_> hmm, ok
<ogra_ac> robclark, http://share.grandou.net/ac100/ in case you want to inspect some of the tegra source for the toshiba
<robclark> ogra_ac: cool..  are the pics of the internals posted anywhere?
<ogra_ac> robbiew, http://wiki.gudinna.com/ac100
<ogra_ac> oops
<ogra_ac> err robclark ^^^
<ogra_ac> (sorry robbie)
<robclark> ogra_ac: thx
#ubuntu-arm 2010-10-10
<voipster3> Hi
<voipster3> I am new here and have just downloaded the maverick for arm
<voipster3> I have made the image to the SD card and booted on the beagleboard C3
<voipster3> but there is not display can anyone help?
<voipster3> the sd led lights are blinking so it is reading from the card and atm this computer I cannot connect it to a serial port
<voipster3> so i cannot actually see whats going on
<dhiry2k> hi all, i have installed ubuntu armel 101.10 xfce4 but it looks like red in color
<dhiry2k> may be need any setting
<dhiry2k> ?
<persia> Um, from where/how did you install that?
<persia> Also, please confirm that you're talking about 10.10, rather than having run into an accident related to the prior-state backup facility in the 2101 fall release.
<dhiry2k> persia, yes i have installed 10.10  http://ports.ubuntu.com/ubuntu-ports/ maverick/main
<persia> So just `apt-get install xfce4` ?
<dhiry2k> persia, yes
<dhiry2k> persia, i have created rootfilesystem using rootstock
<persia> Ah, yeah, that gets the raw, unfiltered, base configuration, which may not be ideally integrated.
<dhiry2k> in which i have given option as  xfce4
<dhiry2k> persia, so i need to do ?
<persia> There's been no reported testing, but I'd strongly suggest installation of "xubuntu-desktop" to get an XFCE-based integrated desktop experience.
<dhiry2k> persia, which is best light wdesktop environment
<persia> That should pull all the right extra libraries, themes, settings packages, etc.
<dhiry2k> lxde or xfce4
<persia> I disbelieve that "best" means anything in this context.
<persia> Personally, I tend to use a GNOME-based environment (with a few bits removed).  I know several people who swear by XFCE and Enlightenment, and there's lots of folk who seem to believe LXDE is even better.
<dhiry2k> persia, if i install xuduntu-desktop then it actually installs many packages which i dont need
<persia> dhiry2k, Try `apt-get --no-install-recommends install xubuntu-desktop`
<dhiry2k> persia, if i have a debian source what will be the way to recompile this for arm
<persia> But yeah, it probably installs more than you need: it's supposed to install a fully integrated environment (although I don't think any of the Xubuntu guys use armel).
<dhiry2k> persia, for armel which desktop environment normally prefereed in ubuntu
<persia> Trivial recompile: `apt-get --compile source ${PACKAGE}` with deb-src lines pointing at Debian.
<voipster3> hi
<dhiry2k> package is locally available not at debian or ubuntu repo
<persia> There are three tested images: Ubuntu Netbook 2D (GNOME/EFL), Kubuntu Desktop (Qt), and Kubuntu Mobile (Qt).
<dhiry2k> i mean source is at local system
<persia> Oh, for a local package, I tend to prefer to use pbuilder or sbuild.  Some folk just dpkg-source -x the package and debuild -b it.
<voipster3> I have a beagleboard C3
<persia> Using pbuilder/sbuild is much cleaner, but requires some setup.
<dhiry2k> but it may need to setup cross toolchain
<persia> voipster3, Hey.  Saw your message from earlier.  how is the display connected?
<voipster3> HDMI
<persia> dhiry2k, Why a cross toolchain?  Just compile natively.  All the packages in Ubuntu are compiled natively.
<voipster3> It seems that the omapfb is not starting
<persia> Does even the text in the beginning when jasper does the resize not show?
<dhiry2k> persia, but i need to install it in armel i.e arm board os
<persia> dhiry2k, OK.  So, build it on an ARM board.
<dhiry2k> voipster3,dmesg can tell much regarding error of omapfb
<dhiry2k> persia, you mean do chroot and build
<persia> dhiry2k, Hard to use with no serial console and no display :)
<persia> dhiry2k, pbuilder and sbuild use chroot, but you can also just build in an installed environment, if you aren't concerned about repeatibility.
<persia> voipster3, You might try mounting the SD somewhere else, and looking at the logs.  I suspect /var/log/Xorg.0.log would contain some hints.
<dhiry2k> persia, is .net application works fine with mono in armel
<dhiry2k> may be some games which is created using .net
<persia> Mono is ported.  There are some bugs.  The Mono team always appreciates help.
<voipster3> dhiry2k I can't type anything in there it is stuck
<dhiry2k> voipster3, do you have minicom setup?
<voipster3> not at this computer
<voipster3> From what I saw the other day it just booted but no display
<dhiry2k> voipster3,what actually it shows on LCD
<voipster3> nothing
<dhiry2k> white screen?
<voipster3> no
<voipster3> no signal
<persia> voipster3, Turn it off, extract the card, mount it somewhere else, and examine the logs.  With no display and no console, you'll have a very hard time getting useful information out of the booted system.
<voipster3> if i remove the sd card
<voipster3> the beagle dog show
<voipster3> ok i will look at the log
<dhiry2k> voipster3, its better to debug using minicom
<voipster3> also tks for the tips greatly appreciate it
<dhiry2k> probably uboot environment is wrong
<persia> dhiry2k, We don't enable the serial console by default, which makes that tricky :)
<voipster3> yes i know just this computer dont have a serial port
<voipster3> the uboot environmoent for booting is ok
<voipster3> jsut that the display driver is not activating
<voipster3> the read write leds blink fast
<dhiry2k> voipster3, printenv bootcmd
<voipster3> after a minute of blinking only read led is blinking
<persia> voipster3, This is with a published image, or a custom image?
<voipster3> published
<persia> Which image?
<dhiry2k> ompafb.mode=?
<voipster3> didnt set any of those
<persia> dhiry2k, jasper should be setting that automatically.
<voipster3> it just booted
<dhiry2k> but sometime it may go wrong
<dhiry2k> better add manually
<voipster3> from minicom? or is there a config i can edit?
<persia> True, although I tend to examine logs, hating to do anything manually when there is automation available/
<dhiry2k> voipster3, its better to have minicom
<dhiry2k> if not then try different value omapfb.mode=dvi:1280x720MR-16@60
<persia> Much better to select a value based on one's actual connected display, rather than based on a guess.
<dhiry2k> if you have HDMI port for LCD then omapfb.mode=dvi:hd720-24@60
<voipster3> can i send you the log file?
<dhiry2k> persia, correct
<persia> I think I heard a rumour once that the HDMI port only provided DVI-D signals, although I may be mistaken.
<dhiry2k> voipster3, yes
<persia> !paste | voipster3
<ubot2> voipster3: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<persia> voipster3, Use a pastebin rather than sending, in case someone lurking has an idea.
<voipster3> ok you got to excuse me since i am not an avid irc user
<dhiry2k> persia, while installing packages in chroot environment getting error as omapfb.mode=dvi:1280x720MR-16@60
<dhiry2k> sorry
<dhiry2k> error as Unsupported ioctl: cmd=0xc020660b
<persia> Then use a chroot on an armel device, rather than a qemu-chroot :)
<persia> Otherwise ignore them: most of them don't matter, although you may have issues with some.
<voipster3> http://paste.ubuntu.com/509963/
<voipster3> this is for the X log
<voipster3> Jan  1 00:00:13 acorn kernel: [    2.059570] omapfb omapfb: failed to allocate framebuffer
<voipster3> Jan  1 00:00:13 acorn kernel: [    2.065063] omapfb omapfb: failed to allocate fbmem
<voipster3> Jan  1 00:00:13 acorn kernel: [    2.070007] omapfb omapfb: failed to setup omapfb
<voipster3> Jan  1 00:00:13 acorn kernel: [    2.074798] omapfb: probe of omapfb failed with error -12
<voipster3> This is from the kern.log
<voipster3> dhiry2k need to see dmesg file too?
 * persia suspects some missing "MEM" or "VMEM" or somesuch setting and hunts docs
<voipster3> http://paste.ubuntu.com/509966/
<voipster3> this is the dmesg file
<persia> I think jasper didn't run correctly: you ought have a "VRAM=12M" argument set, which should prevent the "omapfb: failed to allocate fbmem" bit.
<persia> I've never seen "omapfb.vram=1:4M,2:4M" passed previously.
<voipster3> so i need to manually type it at boot each time or is there a way to permanently change it?
<persia> I think you'd permanently change it in uboot settings
<voipster3> so i need to do it from minicom?
<persia> And I suspect the "omapfb.vram" parameter is hitting my attempt to prevent stomping on user-supplied values, and causing vmem=12M not to be set.
<persia> No.
<persia> You can change the settings in the uboot configuration on an SD, and boot using the uboot on SD.
<voipster3> ok
<voipster3> so i just directly edit the file?
<persia> May as well try.  Just make a backup first.  You're unlikely to damage anything playing with kernel command line parameters.
<voipster3> atm i dont have minicom here can i just use a desktop to edit the file?
<voipster3> the answer is now :P
<voipster3> no
<persia> Of course you can.  it's just a text file.
<voipster3> umean the u-boot.bin file?
<persia> Isn't there something like a boot.scr or similar?
<voipster3> yes
<persia> I think that's it.
<voipster3> but it says its a binary file
<voipster3> ok i'll try from cli
<persia> Hmm.  You might want someone else to advise you then.
<persia> I tend to just complain until someone makes a bootloader work, and then stick to userspace.
<voipster3> hehe understand
<voipster3> tks for the time though
<voipster3> the boot.scr has the setting of vram=12M
<voipster3> fatload mmc 0:1 0x81600000 uInitrd
<voipster3>     setenv bootargs vram=12M omapfb.mode=dvi:1280x720MR-16@60    root=/dev/mmcb$
<voipster3>     bootm 0x80000000 0x81600000
<persia> Dunno then.  That's the bit on my C4 that makes it not have issues with memory for the framebuffer.
<voipster3> it seems the bootm address maybe wrong
 * persia grumbles about cannot-redistribute clauses, and retailers who remove all such software when selling devices, even though that makes them useless :(
<ogra_ac> dont buy such hw then :P
<persia> But it cost half the price of the Dynabook AZ, and amitk might have a working kernel for it...
<persia> (plus the Dynabook AZ has *even more* unredistributable software)
<ogra_ac> the dynabook has a working kernel too :P
<persia> 2.6.36?
<persia> Anyway, it's not that hard to download the recovery image, and reinstall from the vendor (although I kinda wish the instructions didn't expect you had a working device to use to build the recovery image to recover the non-working device, but ...)
<ogra_ac> no, 2.6.29 but sources are public
<persia> I've public working Ubuntuised 2.6.29 sources, plus a known tree that is targeting 2.6.36 that *should* work.  Mind you, I still end up with unredistributable firmware for the WiFi, but...
<persia> Hrm.  This might be going back to the shop tomorrow.  Full reinstall from the vendor site, and still no working WiFi :(
<ogra_ac> sad
<ogra_ac> got a link with specs and pics ?
<ogra_ac> oh !
<persia> To the PC-Z1?
<persia> There's heaps of them.
 * ogra_ac just found a flashlite that might run on the ac100
<persia> Nifty.
<ogra_ac> extracted from the netwalker apparently :)
<persia> This is (theoretically) the same device I dropped in my sink in April, except this one doesn't work :(
<ogra_ac> ah
<persia> Strange.  The Netwalker doesn't ship with Flash: it's a bonus for registering for use.  Someone broke terms of service.
<ogra_ac> http://www2.jkkmobile.com/FlashLite3.1_Firefox_plugin.tar.gz
<persia> Be warned that it will be an ARMv5 binary.  Ought work, but may not have the optimisations you'd prefer.
<ogra_ac> http://carrypad.com/2010/10/02/coming-to-you-from-ubuntu-on-the-arm-based-ac100-its-working-well/
<ogra_ac> from the comments there
<persia> Oh, yeah, that there site often seems to ignore redistribution provisions of licenses.  handy in many ways.
<ogra_ac> i havent tried it yet but got the tarball on disk
<ogra_ac> all help is in japanese :P
<ogra_ac> even the script comments in the install script are
<persia> Of course.  Why would anyone want anything less concise?
<ogra_ac> haha
<persia> I can recommend some books to learn how to read, if you like ... :p
<ogra_ac> nah, looking at the code most stuff is easy to figure out
<persia> See, Japanese is intuitive, like all good iconographic languages.
<persia> Plus, you're already used to verb-at-the-end-of-the-sentence-placing grammer :p
<armin76> ogra_ac: can't you use gnash or swfdec?
<ogra_ac> armin76, you might, havent tried it yet
 * ogra_ac isnt after flash so much i just dont say no if i find it :)
<persia> ogra_ac, So, for all my whining earlier, the solution turned out to be me discovering that Fn+1 turns on and off WiFi :)
<ogra_ac> lol
<ogra_ac> arent HW keys fun
<persia> I guess.  If nothing else I've verified the OS restore procedure, enabled support for my USB ethernet, and practiced reading (even learned some new grammar to understand a post on a gentoo forum having the same issue)
<lag> ogra_ac: Are you still in Tx?
<ogra_ac> lag, nope
<ogra_ac> home again
<lag> How did everything go?
<persia> lag!  You'd know.  If I have a git tree, how do I get a kernel .deb?
<lag> Compile and package it :)
<persia> In that order?
<persia> I was kinda hoping there was some wiki doc that let me add some base debian/ to the results of git clone...
<lag> Which tree are you trying to complile?
<lag> compile*
<lag> And which arch?
<persia> http://git.linaro.org/gitweb?p=people/amitk/linux-2.6.git for armel
<lag> fakeroot debian/rules clean
<lag> fakeroot debian/rules binary-omap
<persia> There's no debian/ directory...
<lag> Then you can use make-kpkg
<persia> Is it safe to just copy a random kernel debian/ directory, and then fight with the ABI checker ?
<persia> Heh.  OK.  I remember how to do that.  I just thought there might be some Ubuntu way (and haven't built my own kernel since moving from sarge-in-process to warty)
<lag> The Ubuntu way is to build our own kernels, which do have a debian directory :)
<ogra_ac> lag, well, we have a release on time ... so it went well i'd say
<ogra_ac> lag, we still have to do an SRU for fixing the sudio issue though
<persia> lag, Doesn't support my hardware.  I'd be happy to use your kernels, if you want to build for my HW.
<lag> https://wiki.ubuntu.com/Kernel/Dev
<ogra_ac> persia, the upstream kernel has a script for rolling debs
<ogra_ac> make deb-pkg should be sufficient
 * ogra_ac plans to use that for the ac100 kernel
 * persia has an inbuilt distrust of all upstream methods of making .debs, regardless of upstream, and with full irrationality enabled
<ogra_ac> yeah, it wont be great
<ogra_ac> but give you a deb
<ogra_ac> with the files in the right places at least
<ogra_ac> i dont think it includes any maintainer scripts
<persia> Indeed.
<persia> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild looks *almost* like the right bit.
<lag> Yep
<lag> The one in our repos is broken though
<lag> You need the latest version
<lag> You can get it from the Debian repos
<persia> What?
<persia> Why didn't that get updated?
<lag> *shrugs*
<lag> Ask userspace
<ogra_ac> because nobody encourages custom kernel builds ?
<persia> Yeah, I know.  Part of why I switched to Ubuntu was a blog comment about never compiling one's own kernels.
<persia> (and now I'm at it again anyway)
<ogra_ac> bad HW choice :)
<armin76> rofl
<lag> I'm off for something to eat
<lag> Enjoy
<persia> ogra_ac, At least it ships with Ubuntu, unlike what you're currently using :p
 * persia is careful to not so denigrate ogra or ogra_cmpc
<ogra_ac> heh
 * ogra_ac just built an androidless kernel
<ogra_ac> will test that after dinner
 * persia will finish building kernels in the morning, having a great desire to hide from the side-effects of having just edited wiki.ubuntu.com/ 
<ogra_ac> heh
<marvin24_DT> anyone with a tegra harmony board here?
<marvin24_DT> I'm just wondering if the u-boot code at git.chromium.org/u-boot.git actually boots
<armin76> marvin24_DT: i have, didn't work for me
<armin76> marvin24_DT: ojn is one of the ppl doing the work
<marvin24_DT> armin76: when did you tried it?
<armin76> one/two weeks ago
<marvin24_DT> the i2c and keyboard driver was added just a few (4-5) days ago
<marvin24_DT> seems that seaboard was tested and worked
<armin76> yeah, saw that
<armin76> marvin24: also there's no doc about setting it up, so...
<armin76> marvin24_DT: i tested it right now, ojn told me passing the uboot binary as kernel should do it, but nothing shows up
<marvin24_DT> I though it should be loaded as a bootloader
<marvin24_DT> nvflash --bl
<armin76> you sure that wouldn't brick it?
<marvin24_DT> the --bl command does not flash anything, it loads into the memory
<marvin24_DT> like nvflash -w --bl uboot.bin --go
<marvin24_DT> I do this on an other board every day
<armin76> downloading bootloader -- load address: 0x108000 entry point: 0x108000
<armin76> sending file: /tmp/ye.bin
<armin76> - 791694/791694 bytes sent
<armin76> /tmp/ye.bin sent successfully
<armin76> waiting for bootloader to initialize
<armin76> it stays there
<marvin24_DT> nothing on the console?
<armin76> nope
<marvin24_DT> mmh
<marvin24_DT> ok, thanks!
<armin76> yw
<armin76> marvin24_DT: what is a seaboard?
<marvin24_DT> armin76: seems that there are many (>5) development boards made by nvidia
<marvin24_DT> there is no official list of it I know of
<armin76> ah
<armin76> k, thanks
<marvin24_DT> looks like harmony is one of the first production boards
<marvin24_DT> and seaboard is newer
<armin76> yep
<armin76> there's also whistle
<marvin24_DT> and e116x (from u-boot tree)
#ubuntu-arm 2011-10-03
<xranby> diwic: the contextgetstate.patch worked fine..    and solved the exception bug on arm
<diwic> xranby, \o/
<diwic> xranby, was it enough to bring up the hajpa hajpa?
<xranby> yeah at least for one of the two jvm's
<xranby> the other jvm had its own classloader bug..
<diwic> xranby, but that was maybe unrelated to pulseaudio?
<xranby> diwic: correct the pulse-audio java layer looks bugfixed now   , thanks!     the only thing that can break it now are if the java virtual machine have missed to implement some part of the jvm specification
<diwic> ok
<xranby> diwic: and for arm we are in the situation that oracle do not provide an opensource reference implementation like on x86 :/ so it takes time to get everything super polished
<diwic> xranby, ok so a lot of that reference implementation is written in platform dependent language (e g assembly?)
<diwic> xranby, vaguely remember you tried to explain some of that stuff at latest UDS
<xranby> diwic: yes highly platform dependent,  and optimized java virtual machine port contains about 80000 lines of platformspecific code
<diwic> ouch
<TheSeven> hm, is the ARM cross compiler toolchain for x86 currently broken?
<TheSeven> (in oneiric)
<TheSeven> apparently the libgcc1-armel-cross package is missing
<xranby> diwic: it turned out that the reverence implementation did not strictly implement the jni spec :) http://icedtea.classpath.org/hg/icedtea6/rev/23b9bb41de6d
<xranby> now \o/ hajpa hajpa work on arm
<diwic> hajpa hajpa!
<janimo> infinity, ac100-tarball-installer in moderation queue
<GrueMaster> ppisati: Can you look at Bug 865479?  Thanks.
<ubot2> Launchpad bug 865479 in linux-ti-omap4 "wl1271: ERROR ELP wakeup timeout" [Undecided,New] https://launchpad.net/bugs/865479
<GrueMaster> Not sure that it is critical, just that it exists.
<GrueMaster> infinity: I'm still consistently getting oem-config to respawn.  Looking at the log files, I believe this may be the problem:   Oct  3 08:12:05 localhost ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
<GrueMaster> Hard to tell, as that message is almost a minute before the respawn message, but it is the only negative message before the next instance of oem-config respawn in syslog.
<brandini> I tried to get mongodb working over teh weekend but didn't make it very far
<infinity> GrueMaster: I can't get this respawn thing happening at all. :/
<infinity> GrueMaster: I can get the installer to explode in general based on cron.daily eating the system alive.  That's about it.
<infinity> (And I plan to hack around that with a kludge today)
<GrueMaster> Pfft.  Figures.  Most of the bugs I find are easily reproducible here, but no where else.
<GrueMaster> I wonder if the cron.daily stuff is blocking me.  Maybe it is doing an apt-get update at the same time?
<GrueMaster> That could explain why I see it and others don't.  Timing.
<GrueMaster> Oh, and the slideshow works again.  :)
<brandini> what steps are involved in bringing support for a new chip like the Cortex A9 to an OS
<infinity> The A9 is new?
<infinity> GrueMaster: The cron.daily thing can just explode in general due to system load.  I think the debconf DB thing might be a red herring, though.  Let me check the log on a successful install run.
<infinity> GrueMaster: Yeah, I have that same debconf locking spew on a successful install.
<infinity> GrueMaster: So, while it's likely a bug somewhere, it's probably not causing an issue either.
<brandini> infinity: new to that os :)
<GrueMaster> I just had ubiquity fall apart when I tried to run without any networking.  Really bad.
<infinity> brandini: Well, things like A8->A9 are really just about building support into toolchains and kernels for shiny new features you might care about, and building support into bootloaders to bring them up.
<GrueMaster> Hmm.  Something caused the filesystem to remount read-only.
<infinity> brandini: But since all your binaries already run (yay backward compat), it's not much effort.
<brandini> ok
<infinity> GrueMaster: Read-only filesystems usually point to hardware hating you, with a 5% chance of kernel bug...
<infinity> (Well, less than 5%, since we tightly control our target platforms here, and we aren't all seeing ro filesystems)
<GrueMaster> infinity: I'm the guy that nails that 5%.
<infinity> Or your hardware hates you. ;)
<infinity> I hate to beat the same dead horse, but when working on SD, I'd tend to blame cards for a filesystem going tits-up before anything else.
<infinity> And I really think we should do most of our test installs on hard drives.
<GrueMaster> Multiple SD cards and multiple Panda's?  I highly doubt I can be having a complete failure here.  The odds are against it being my HW.
<infinity> Except hitting a card once in a while to make sure the code paths still do what we think they do. :P
<infinity> GrueMaster: The odds for hardware are still higher than the idea that a deterministic automated installer only fails in one person's house.
<GrueMaster> infinity: Can't test on hard drives.  The preinstalled images are designed around SD.  It would be equivalent to testing in a VM.
<infinity> GrueMaster: And you've been beating on the same SD cards for a while, I'd guess.
<GrueMaster> Some are almost brand new since A2.
<infinity> GrueMaster: Preinstalled would work on an HDD just fine.
<infinity> (Just need to write it differently)
<infinity> But yeah.  I know the situation we're stuck in.  I just dislike it. :P
<infinity> I have 5 cards in front of me, and I only trust one of them.
<infinity> And that trust won't last forever.
<GrueMaster> I have ~2 different cards per board at my disposal.  Varying sizes, speeds, an brands.  To see these issues across multiple SD cards on Panda A1, A2, and A3 systems is extremely rare.
<infinity> Well, wait, which issues?  The ro filesystem above sounded like a one-off.
<GrueMaster> Remember, I have almost 10 years in hardware validation.  I know very well how to triage hardware failures.
<GrueMaster> That was the first time I saw it, but also the first time I booted w/o networking.
<infinity> Correlation and causation not being the same thing. :P
<GrueMaster> And ubiquity crashed with a UBI failure of some sort.  Just getting ready to look at the log.
<infinity> But it's possible 'fixrtc' stopped working or some such, which could lead to network->badtime->fsbreak.
<infinity> But that should break early.
<infinity> The log will be useless if the filesystem is ro.  Unless you're really lucky.
<infinity> dmesg is more likely to be useful.
<GrueMaster> fixrtc only runs during boot in initrd I thought.
<infinity> Well, it's an at-boot thing.  To fix the clock...
<infinity> We don't then break the clock later. :P
<GrueMaster> Since these images don't have any way to get a terminal session without first modifying the image prior to boot, there is no way to debug a live session.
<infinity> So, if it's not working, then without ntpdate, your clock will be a sad panda.
<infinity> Yeah, that's so obviously an ARM preinstalled bug.  I noticed it with the last week of debugging. :/
<infinity> Since a real live system has the "ubnutu" user, and a real oem-config system has an oem user.
<infinity> But we fail to have either.
<infinity> Not fixing that before release, though.
<infinity> Worth having on the TODO if jasper survives.
<GrueMaster> Log files are a bust.  complete corruption prior to any ubiquity info.  Interesting to see network manager completely freak out though.
<GrueMaster> and I have asked for debug hooks of some sort since we started doing preinstalled images.
<infinity> GrueMaster: When does the loop happen?
<infinity> GrueMaster: I'm going to sit here and try to reproduce this...
<GrueMaster> Right around the time it says that it is copying log files.
<infinity> GrueMaster: Does everything complete (including the removal)?
<GrueMaster> Does not start the removal.
<infinity> Hrm.
<infinity> I also might not be able to fix the anacron issue this cycle, the more I think about it.
<infinity> The fix needs to be in ubiquity, and might be regression-inducing.
<infinity> I realised I can't hack around it in jasper, because we don't actually have a sane clock yet.
<GrueMaster> Nothing (other than what I previously stated about the config.dat) indicates an issue in any log files I have.
<GrueMaster> Hmm.  Doesn't appear to like me hacking in an additional debug user prior to oem-config running.  It has been sitting on "Creating User" for a while now.
<GrueMaster> Grrr,  Doesn't appear to like my shadow entry.
<infinity> GrueMaster: *poke*
<infinity> GrueMaster: Can you do some test runs on your problematic systems with 's/update-apt-xapian-index -q/update-apt-xapian-index -q -u/' in /etc/cron.daily/apt ?
<infinity> GrueMaster: Seems to have made mine slightly less grumpy.
<GrueMaster> infinity: On it now.
<GrueMaster> (took an extended lunch break).
<infinity> GrueMaster: All good.  Food sounds like a stellar plan to me too.
<GrueMaster> Starting the test now on a freshly zero'd & flashed drive.  Even if this solves the oem-config respawn, we still have another issue where ubiquity crashes when no network available.
<infinity> GrueMaster: Do you have logs for the no-network thing?  That one couldn't have been silent... I hope.
<infinity> GrueMaster: Or even an apport-filed bug would be nice.
<GrueMaster> Well, that was part of the problem.  ubiquity crashed saying it would spawn a desktop session for debugging, but that failed to materialize.  And nothing was captured in the logs as the system had gone read-only.
<GrueMaster> I'll try to reproduce it as well.  I would really like to have an image that I can get to a login for testing though.  Otherwise I am just spinning my wheels on useless stuff.
<infinity> Oh, that was the read-only one, right.
<infinity> I suspect that one might not be reproducible, but if it is, great.
<infinity> If the FS isn't readonly, ubiquity crashes will spawn apport, which is good enough for filing bugs with logs, at any rate.
<infinity> If jasper survives another cycle, we should remember to add the oem user, though.
<GrueMaster> I'll prep another SD to test that, but for desktop, I am kind of limited to single tasking (1 monitor & keyboard for Pandas).
<infinity> Oh, wait.  No.  There shouldn't be one, it's deleted by oem-config-prepare before rebooting.
<infinity> So, oem-config in general just has no way to debug it.  Hrm.
<GrueMaster> Not that I have found useful.
<infinity> I've been testing on my ac100 too.  Which picks up slightly different bugs just due to the timing of having faster storage.
<infinity> Panda and ac100 together seem to get most everything.. Except your respawn issue. :/
<GrueMaster> And fail.  The cron.daily fix is bust.
<infinity> Well, it does address *a* problem.  Just not yours, apparently.
<infinity> And I honestly can't get ubiquity to crash/respawn at all (or finish/respawn, or any combination thereof), so I'm kinda stumped.
<infinity> A full set of logs (heck, just /var/log tarred up) from the SD might be enlightening.
<GrueMaster> Unfortunately, it isn't as enlightening as one would expect.  I have yet to find a significant entry in any logs under /var/log.
<GrueMaster> The best I had was the debconf config.dat file (which you said wasn't significant).
<GrueMaster> Sigh.  I hate the automount "feature".  It really annoys me.  And what's with the AC100 showing (and mounting) all of the SERVICEV001 partitions?
<infinity> GrueMaster: It doesn't?
<infinity> GrueMaster: At least, it doesn't here.
<infinity> GrueMaster: You sure that's not a freshly-flashed card?
<GrueMaster> Could be because I upgraded from Natty.
<infinity> (It's only SERVICEV001 after it's booted)
<GrueMaster> I'm talking about the eMMC.
<infinity> Oh.  yeah, I get no weirdness here.
<infinity> You might want to try the recent images. :)
<infinity> They actually work better than OMAP.
<infinity> Which is a bit sad.
<infinity> But yay for faster storage.
<GrueMaster> As I said, if there is >.01% chance of weirdness, I will hit it.
<infinity> Anyhow.  Going to take a late lunch.
<infinity> Back later to keep banging on things.
<infinity> On the looping installer thing, if you can just let it settle a bit after it loops, so it's sure to have flushed some buffers, yank the card, and give me /var/log in a tarball, maybe I'll spot something that doesn't add up compared to one here.
<GrueMaster> I usually wait until it comes up, then switch to text console and 3-finger reset so everything shuts down cleanly.
<infinity> You could just alt-sysrq-s to force a sync, wait for the SD light to go out, and yank it.  That has the advantage of basically being a snapshot of the problem area without reboot fluff afterward.
<GrueMaster> reboot fluff is minimal (and tarball is in my people.c.c dir (firtname)/20111003-oem-fail-logs.tgz
<infinity> Great, I'll look at it after lunch.
<infinity> That's the re-spawn one?
<GrueMaster> starting on the network-less run.
<GrueMaster> Yes.
<infinity> Kay.
<GrueMaster> W/o network crashes much more ugly before it even gets that far.\
<GrueMaster> Grr.  Network crash didn't happen this time around, but oem-config respan did.
#ubuntu-arm 2011-10-04
<ogra_> infinity, hmm, instead of the mkdir you added to jasper we should instead add a dep on app-install-data which creates that dir
<infinity> ogra_: No, you should instead be using the ti-omap4-software-channel package you created and forgot about. :P
<ogra_> heh
<infinity> ogra_: But at this point, what's in jasper works, and I don't want to touch it.
<ogra_> well, emmet wanted to work on it back a release
<infinity> ogra_: The mkdir wasn't a fix anyway, it was just paranoia.  Never copy without a destination.
<infinity> ogra_: The fix was the last line in the function.
<ogra_> sure
<ogra_> yep, saw that
<ogra_> and thanks !
<infinity> Landing an apt fix today to make update-apt-xapian-index less vicous on ARM.
<ogra_> wohoo
<infinity> And after that, unless I can reproduce some Tobin-only issues, I think we're running out of things we can reasonably fix in this cycle.
<ogra_> banshee :)
<ogra_> we could stare at it as a team :)
<ogra_> watching it die ...
<xranby> ogra_: who does it die?  somebody know?
<xranby> im observing it dying as well
<ogra_> xranby, no, we dont know yet, suspicion is that its a mono SMP issue, NCommander has some experience with that and looks into it, i'm sure he would appreciate some help
<xranby> ogra_: kind of odd since it works fine on i386 smp systems
<xranby> it do throw a nice exception on arm
<xranby> NCommander: this are what i see when i startup banshee http://paste.ubuntu.com/702190/    have you filed a bugreport for this to work on  ?
<ogra_> yes
<ppisati> why my panda is aking me for the "ubuntu" user password?
<ogra_> ppisati, bug i guess
<ppisati> "Failed to summon the GConf demon; exiting.  Failed to activate configuration server: Failed to execute program /usr/lib/i386-linux-gnu/libgconf2-4/gconfd-2: Success"
<ppisati> ?!?!?
<ogra_> sounds like a readonly FS or full disk
<ppisati> /dev/sda1             459G   14G  422G   4% /
<ppisati> nope :)
<ogra_> well, asking for a ubuntu user and pw doesnt look like you used one of our images, we definitely never create such a user anywhere
<ppisati> that's a... natty? installation upgraded recently to O
<ppisati> anyway, let's see...
<ogra_> NCommander, how are you progressing on banshee ? any insight yet ? (we need to make a decision by thu about what we ship=
<ogra_> )
<GrueMaster> ogra_: I did some extensive testing with rhythmbox and it worked ok, making it a viable alternative.  The only issue is Ubuntu One integration (doesn't exist that I am aware of).
<ogra_> yeah, which is bad
<ogra_> i would really prefer to have a plan for banshee instead
<GrueMaster> Well, better than crashing but...
<ogra_> doesnt need to be fixed before release, but we need to know we *can* fix it (i.e. without having to update the whole mono stack etc)
<ogra_> if we see no perspective we need to switch indeed, but that should only be last resort
<GrueMaster> sigh, no daily for today.  grmbl.
<ogra_> heh
<ogra_> you expected miracles ?
<GrueMaster> No, just to be able to work.  Silly me.  :P
<ogra_> well, try banshee on a system booted with nosmp :)
<GrueMaster> I haven't had a desktop image get past oem-config since last week.
<ogra_> try the ac100 ;)
<ogra_> to have some successfull install
<GrueMaster> I have.  Fail.  It fails the same way on beagleXM and MX53.
<ogra_> huh ?
<GrueMaster> I have my AC100 updated now from Natty.
<ogra_> not for all the people in #ac100
<ogra_> neither for me
<GrueMaster> Banshee?
<ogra_> (though i personally didnt do much testing post-beta)
<GrueMaster> Or oem-config?
<ogra_> GrueMaster, the installer
<ogra_> and oem-config
<ogra_> banshee fails the same way everywhere i tested it ... but i havent tested without smp yet
<GrueMaster> I haven't been testing AC100 much.  Too much focus on why oem-config crashes on omap4.
<ogra_> yeah, i was just suggesting it to get y successfull install to get your mood up :)
<GrueMaster> banshee fails on my UP systems the same way, so it isn't an SMP issue.
<ogra_> ah, thanks !
<ogra_> can you put that info in the bug ?
<GrueMaster> I thought I already did?
 * ogra_ didnt see it but that doesnt mean much
<GrueMaster> bug #?
<ogra_> bug 857299
<ubot2> Launchpad bug 857299 in banshee "banshee window remain white on startup on pandaboard" [Undecided,New] https://launchpad.net/bugs/857299
<ogra_> not even triaged yet (sorry i should have done that)
<GrueMaster> Doing it now.
<GrueMaster> Ok, triaged and added some comments.  Also assigned to NCommander, but may want janimo to look at if he has time.  More eyes is better.
<ogra_> yeah, even you, me and infinity should look
<ogra_> the more the better since its our worst bug we have left
<GrueMaster> I plan on looking from a different angle.  I will test other mono apps (f-spot, etc).
<ogra_> GrueMaster, btw, when did we stop to subscribe u-arm ? i'm noticing that i miss a lot of bugs and bugmail
<GrueMaster> Oops.  Need to add that.
<ogra_> added already
<GrueMaster> We have only stopped because I haven't had time to go bug triaging.
<ogra_> but i noticed it on several bugs recently
<ogra_> ah
<ogra_> well, your work is noticeable then :) be happy :)
<ogra_> at least it is when itss not done ;)
<brandini> hello ogra_
<GrueMaster> I seriously was swamped with all of the server work items.  That's why desktop is in such shambles, and none of our bugs are triaged.
<ogra_> yeah, we need to make a fallback plan for the next time that happens
<ogra_> the team needs to take more duties off you in such situations
<GrueMaster> Well, I had put out an alert before Beta 1.
<ogra_> while everyone else was busy too
<ogra_> what i want is an emergency plan so you can just raise your hand and plan b applies for the teasm
<ogra_> *team
<GrueMaster> I understand.  I also put out the call to the community.
<ogra_> and to be honest it was clear to all of us from the beginning that desktop would suffer under your workload, i wish we had worked on such a plan back last UDS
<GrueMaster> At least during the Rally.
<ogra_> right
<ogra_> well, next UDS next chance :)
<brandini> big release happening?
<GrueMaster> brandini: This week is RC.  Next week is Final.  So...yes.
<brandini> very cool
<brandini> I've been testing
<brandini> I do dist-upgrade daily and run my Go webapps :)
<brandini> This page is being served up from my pandaboard running the latest daily http://eutonian.ath.cx
<ogra_> nice
<GrueMaster> brandini: I take it you are running the daily server image?
<brandini> ogra_: I got my arduino programmed to monitor my barometer and humidity, calculate dewpoint and other things and dump that data to my pandaboard
<brandini> GrueMaster: I am
<ogra_> cool !
<brandini> Yes, there is still a bug in the lcd library that keeps me from being able to use the lcd at teh same time the data dumps to the serial console
<brandini> but I watched the barometric pressure rise yesterday and sure enough... sunshine today!
<robclark> is it normal that I have no /lib/udev/rules.d/50-firmware.rules ? (natty filesystem..)
<robclark> oh, hmm, /lib/udev/rules.d/...
<jayabharath> davidm: ping
<davidm> Hi jayabharath
<GrueMaster> infinity: I managed to get past oem-config on 20111003, but not gracefully.  I enabled trim support for ext4.  Makes the initial install a little slower (but not by much).  And oem-config didn't respawn, but it also failed to uninstall.
<GrueMaster> Hey, a crash dump from oem-config-remove-gtk.
<GrueMaster> And audio is worse.  Is that even possible?
<GrueMaster> No devices, not even HDMI Audio.
<GrueMaster> Ok, removing trim fixed audio.  How odd.
<GrueMaster> ogra_: Any reason we removed libreoffice from the desktop image?  There are no office suites installed now.
<robclark> hmm, does anyone else actually use udev for firmware loading on arm?
<robclark> udev appears to (from what I see on kernel side) to abort the fw load
<robclark> (for no particular reason that I can see)
<GrueMaster> f-spot appears to be working ok.  Slow on SD, but ok.  So I don't think the problem is mono, just banshee.
<ogra_> GrueMaster, we havent shipped libreoffice since 3 releases now
<GrueMaster> ok.  Didn't know.
<NCommander> GrueMaster: great, lovely. At least that makes it easier to narrow down, might be one of the bindings is broken
<NCommander> oh, weird. SO when run over X11 forwarding, banshee semi-draws
<GrueMaster> I noticed libwaland0 is installed only on armel images (not on x86).
<GrueMaster> Could be a function call difference?
<GrueMaster> NCommander: ^^^
<NCommander> possibly
<NCommander> I thnk its more an issue with Gtk#
<NCommander> gtk-sharp was uploaded Published on 2011-07-12
<NCommander> it throws an exception which is uncaught
#ubuntu-arm 2011-10-05
<NCommander> so rebuilding gtk-sharp causes the GUI to appear but it doesn't actually wokr
<NCommander> grumble
<NCommander> GrueMaster: try testing with the debs in my panda homefolder 192.168.0.60
<NCommander> ubuntu:ubuntu
<twb> NCommander: you know that's a private address, right? ;-)
<NCommander> twb: I live with GrueMaster :-P
<twb> You poor man
<NCommander> twb: him or me :-P
<brandini> yes
<twb> +1 brandini
<NCommander> GrueMaster: https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/853539
<ubot2> Launchpad bug 853539 in banshee "Banshee wont start" [Undecided,Triaged]
<GrueMaster> NCommander: Wrong arch.  Read the bug details.  May be similar, but since it works on x86, I'm doubting it.  Also, this is for 2.1.4.  We are on 2.2.0
<NCommander> ugh
<GrueMaster> following the gconftool-2 instructions has no effect.
<GrueMaster> And the bug you want to follow is Bug #857299
<ubot2> Launchpad bug 857299 in banshee "banshee window remain white on startup on pandaboard" [High,Confirmed] https://launchpad.net/bugs/857299
<NCommander> so the code that throws the exception only throws it if something is <0
<NCommander> I'm blocking ATM on how to debug this
<NCommander> but it is breaking in Banshee (Hyena.Gui)
<GrueMaster> I'm still loading build dependencies.  Seems apt-get build-dep doesn't get all of them (gmcs, boo so far).
<GrueMaster> Interesting.  I may have found the issue.  http://banshee-media-player.2283330.n4.nabble.com/Banshee-crashes-after-updating-compiled-version-tp3862966p3862966.html appears to say that banshee 2.2 requires mono-addins 0.6.2,  We have 0.6.1.
<GrueMaster> Nope.  Not it (apparently).
<GrueMaster> sigh.
<twb> Banshee needs mono now?  Sheesh.
<GrueMaster> Its a mono app.  Always has been.
<twb> Rassum frassum
<GrueMaster> Personally, I don't like either of the two gnome music apps (Banshee, Rhythmbox).  But that's just me.
<twb> Last time I looked at rhythmbox (8.04) it looks OK for what it was
<GrueMaster> Yes, but apparently it won't work with ubuntuone (or at lease ubuntuone won't work with it).  Don't ask me why.
<GrueMaster> But we may revert to that for this release.  Will know more Thursday.
<twb> I expect canonical cares about that, but I don't :P
<GrueMaster> Well, at least Pithos runs well on armel.  Pandora on Panda rocks.
<twb> Oh lame
<twb> I thought you meant like the pandora game handheld
<GrueMaster> May need to move my normal pandora setup to this system.  Chumby is getting a little long in the tooth.
<GrueMaster> No, online music.  Beats my local collection.
<twb> "We are deeply, deeply sorry to say that due to licensing constraints, we can no longer allow access to Pandora for listeners located outside of the U.S."
<twb> There's a couple of CC-flavoured ones that I would use if I could be arsed.  IIRC recent versions of rhythmbox know about them OOTB
<GrueMaster> Yea, blame the industry, not Pandora.  Freaking RIAA and ASCAP.
<GrueMaster> Both fight for licensing rights, neither really care about the artists.
<GrueMaster> I used to work in a lounge that featured live bands.  During the day, they would play cds from the local bands that would play Friday & Saturday, until ASCAP came and told us to stop or pay.  We even had one of the artists there, while his music was playing.
<GrueMaster> At any rate, that is a long rant from 16 years ago ('95).
<GrueMaster> Well, I've put in my 14 hours.  Time to go veg on the tube.
<NCommander> GrueMaster: no love updating mono-addins (hadto take a brick to it to get it installed but no comparable difference :-/)
<NCommander> in banshee
<plasmasolutions_> Hi guys, I've read every thread I could find on google groups but didn't find a new answer: Is hd video acceleration possible with natty on the pandaboard nowadays? I'm using the TI ppa with ubuntu-omap4-extras installed
<ogra_> no
<plasmasolutions_> And as a second question: Is there no performance governor anymore with natty? I don't find it anymore in the usual place
<ogra_> wait for oneiric or use maverick
<ogra_> Ti did no work on the natty port of the omx bits
<plasmasolutions_> ogra_: Wow fast answer...even if it's not what I hoped for ;)
<ogra_> (lets hope that makes the oneiric one twice as good :) )
<plasmasolutions_> ogra_: I'm experienced with beta versions, is there already support for it in the current dev version of oneiric?
<plasmasolutions_> I would test it then and give feedback...
<ogra_> plasmasolutions_, i dont think TI has uploaded to the PPA yet, ndec1 might be able to giev an ETA (i would gueyy by release its there though)
<ogra_> *guess even
<ndec1> plasmasolutions_: short answer: not available now. long answer: http://groups.google.com/group/pandaboard/browse_thread/thread/2aa25aab6635fb02
<plasmasolutions_> ogra_: ndec1: Thank you for your help...I'm reading your post now...
<plasmasolutions_> ndec1: Wow, this post was needed... why is it so difficult to find?! Should be linked on the ubuntu wiki...
<plasmasolutions_> ndec1: So ist's more than likely that we'll get the packages once oneiric is ready...that's goog news!
<plasmasolutions_> goog = good :)
<ndec1> plasmasolutions_: this is the last message in the pandaboard group...
<plasmasolutions_> ndec1: I'm now a member of this group...so important news will not pass away again :)
<plasmasolutions_> ndec1: So thank you very much..I have to leave now. But I will try maverick and oneiric once it's ready! Looking really forward to this release...bye
<janimo> ndec1, what is the difference between gst-ducati and gst-openmax?
<janimo> I read the mail you lined to above and it mentions this change in the PPA
<ndec1> janimo: they do the same thing, in the sense that they decode/encode using h/w acceleration. but they use different low level APIs to do it
<ndec1> gst-openmax uses OMX, gst-ducati uses DCE
<janimo> ndec1, are they competing or is one replacing the other?
<janimo> is DCE a TI-only technology?
<ndec1> yes.
<ndec1> Distributed Codec Engine.
<ndec1> codec engine is TI API for codecs
<ndec1> OMX uses CE API, and DCE uses the same API.
<ndec1> janimo: http://groups.google.com/group/pandaboard/browse_thread/thread/2aa25aab6635fb02
<ndec1> oops... wrong copy paste... here is it: http://bloggingthemonkey.blogspot.com/2010/11/announcing-libdce-and-gst-ducati.html
<janimo> ndec1, thanks. Still not clear from it whether it is preferred to openmax. Probably not if portability is in mind. Is TI also updating gst-openmax though?
<ogra_> janimo, the point is that whatever android chooses as default should be used, else you add extra workload
<ogra_> and i think android moves away from omx
<janimo> ok, but android moves to something that is not in classic linux
<janimo> but I see your point
<ogra_> its not in classic lunix, but the kernel side implementation will be the same
<ogra_> *linux indeed :)
<ndec1> ogra_: no android is not moving away from OMX.
<ogra_> oh, i thought they do
<ndec1> we are moving away from what we do in android ;-)
<ogra_> i stand corrected then :)
<ndec1> ogra_: if you read that somewhere, please share the link
<ogra_> i didnt :)
<janimo> ogra_, Andoid moves from OpenCore to StageFright maybe that's what you (and I) mixed up with moving from OMX?
<ogra_> yeah, i just knew everything is moving right now :)
<janimo> lots of multimedia related codenames around
<ogra_> wohoo, another sprint in budapest \o/
 * ogra_ guesses infinity will like that :)
<janimo> where is it announced?
<ogra_> check your mails :)
<janimo> I checked right aft6er you said it. But I rmember my inbox is lagging a bit. So will get it in 20 minutes :)
<ogra_> are ysou using uucp ? *g*
<janimo> homing pigeons
<ogra_> heh
<janimo> unladen though. For maximum speed
<ogra_> flying forwards or backwards ?
<ogra_> (or belly up ?)
<janimo> show out of a cannon, wings tied to the body
<janimo> s/show/shot/
<ogra_> heh, yeah, that should be pretty fast
<jondo> Hi everybody
<brandini> morning
<jondo> I have got a BeagleBoard-xM and wonder  which Ubuntu release to use.
<ogra_> depends on the board revision ... the newer the more likely it is that your revision isnt supported out of the box in an older release
<jondo> According to u-boot it is "Rev C". (That's probably also the meaning of the "C" sticker on the board.)
<ogra_> then i would suggest oneiric
<ogra_> latest daily, shouldnt change much until tomorrow (when we build the Release Candidate images)
<jondo> This would be http://cdimage.ubuntu.com/daily-preinstalled/current/oneiric-preinstalled-desktop-armel+omap.img.gz then?
<ogra_> yep
<jondo> Great! Because I have already tested Maverick in order to avoid Natty's https://launchpad.net/bugs/771537, and could not get it to boot.
<ubot2> Launchpad bug 771537 in linux "Beagle XM lacks proper 1Ghz support" [Medium,In progress]
<ogra_> right,. oneiric should fix that
<jondo> Thanks. I'll report back when I continue testing tomorrow.
<ogra_> great, feedback is really appreciated since we are testing for release
<BlInK311> will the new oneiric not work with the older Beaglebaord xM Rev.A3?
<ogra_> it should work with all beagle XMs that are currently available
<BlInK311> ok thanks
<ogra_> the older ones dont since the boards showed up after or around release time
<ogra_> we offer updated bootloader and kernel files you can replace on the older images, oneiric includes all these bits
<BlInK311> ok, I have an Rev A3 and a Rev B, im gonna play with both of them by the end of the week.  glad to hear they will both work with oneiric
<ogra_> if you find issues, please tell us
<BlInK311> will do
<BlInK311> downloading image from link above
<ogra_> ndec1, yo ! i just got an oder acknowledgement for a 4460 :)
<ndec1> ogra_: ?
<ogra_> from TI
<ogra_> seems there is a 4460 in shipment to me
<GrueMaster> I got one Saturday.  Still no box though.
<ndec1> ogra_: cool! do you have the ID ?
<ogra_> hmm, there are a bunch of numbers, which is the ID ? :)
 * ogra_ thinks what he just got from the postman is just a bill ... has the usual $0.00
<GrueMaster> ndec1: The Order Ack # for mine is 143064217.  Is that the number you are looking for?
<ndec1> do you have a RQST number? or the model number?
<GrueMaster> OMAP4460UEVMES11GP12GHZTIWI-BLE or UEVM4460G-02-01-00.  Those are the only other numbers on my copy.
<ogra_> same here
<brandini> I wish it was friday and I could hack on my pandaboard
<ndec1> ogra_: GrueMaster: ok. that looks good!
<GrueMaster> ndec1: Any info on the new boards?  Same/similar to panda?  Same power?  I'd like to get mine online as soon as it arrives so that I can say it works for Oneiric.
<brandini> If you get an 4460 then *I* should get a 4460 too!
<brandini> You just plug that into your pandaboard and voila eh? ;)
<brandini> wonder if I could get a job doing dev for these SoC things
<prpplague> brandini: plenty of job openings for skilled developers
<brandini> I don't have any experience doing it, but I do have good skills and a great ability to learn
<ndec1> brandini: as prpplague said, yes, we are always open to great people ;-)
<brandini> we == ubuntu?
<prpplague> brandini: and others
<brandini> wonder if there are any in NE ohio
<ndec1> brandini: i work for  TI ;-)
<xranby> nice sound on the panda board!
<xranby> tested todays daily image  20111005 and can confirm that the fix from 1003 fixed
<brandini> w00t!
<brandini> Linux localhost 3.0.0-1205-omap4 #10-Ubuntu SMP PREEMPT Thu Sep 29 03:57:24 UTC 2011 armv7l armv7l armv7l GNU/Linux
<brandini> armv7l x3
<GrueMaster> xranby: Excellent.
<brandini> ndec1: any openings near NE ohio?
<xranby> GrueMaster: when testing  i noted that the soundscard did not get detected while running the oem-setup      but the soundcard got found when the lightdm login screen got displayed
<xranby> so the first thing i heard was the login sound..   excellent
<GrueMaster> xranby: That could be a pulseaudio thing.  Not sure.
<GrueMaster> Right now, I am fighting to get through oem-config without respawning.  Seems I am the only one experiencing this (although I can do it reliably on multiple boards with different SD cards).
<ndec1> xranby: GrueMaster: i am also seing that the soundcard is detected only after loging in
<ndec1> aplay -l does not return the same thing before and after login
<ndec1> you know where it's coming from?
<GrueMaster> It could be that pulseaudio is having issues running as root during oem-config.  On firstboot, there is no default user and no user environment established.  pulseaudio runs as a user app.
<ndec1> even after installation, i get this. if you open a console before logging into lightdm (ssh or serial), aplay doesn't return anything
<GrueMaster> Very odd.  On my server images, I see both Panda & PandaHDMI in /proc/asound/cards.  May need more alsa tweeks.
<infinity> You're supposed to see both.
<GrueMaster> Yes, but you should also be able to use both.
<GrueMaster> It appears we are missing a mixer device when logged in through the console (testing on ubuntu-server).
<GrueMaster> ogra_: On today's image, clicking on the ti icon and telling software center to use this source causes software center to crash.
<GrueMaster> I'd file a bug, but I am getting an "Unexpected Form Data error from lp.  sigh.
<ogra_> GrueMaster, ouch
<infinity> GrueMaster: Did you have an open bug for the "no swap" thing?
<infinity> GrueMaster: Going to slide that in right now.
<GrueMaster> I'll look
<infinity> ogra_: Did you have any urge to have swap on ac100?  ac100-tarball-installer doesn't currently look for and enable it.
<infinity> ogra_: (Right now, I'm just enabling it for jasper-using images)
<GrueMaster> infinity: I could have sworn I had a bug filed on that, but I'm not turning up anything.  Will try google.
<infinity> I see nothing filed by you...
<GrueMaster> I don't even see where it was removed in jasper.
<GrueMaster> Wait, Revno 119 removed it from jasper and added it to livecd-rootfs.
<GrueMaster> And I guess it was never enabled in the new image build tool.
<infinity> Right, which is what I'm fixing.
<infinity> Well, what I've fixed.  Was just curious if you had a bug to reference in the changelog. :P
<infinity> Which would be nice.
 * infinity goes to find a drink and see if a Tobinish bug appears while he's gone. :)
<GrueMaster> Should I create one?
<GrueMaster> ok
<GrueMaster> Bug #868662  for you to play with.
<ubot2> Launchpad bug 868662 in live-build "Switching to live-build dropped swap file creation on preinstalled images" [High,Confirmed] https://launchpad.net/bugs/868662
<infinity> GrueMaster: Thanks, fix uploaded.
<infinity> I find myself wondering if your oem-config* issues are just bad timing with the fact that (ana)cron is still running during the install.
<infinity> I'd hoped to fix that in ubiquity, but I might be running out of time.
<GrueMaster> very possible.
<infinity> Still annoying that I can't reproduce.  Could just be because I have faster SD cards, so the timing is different.
<GrueMaster> Define "faster".  I have everything from class 4 to class 10, 4G-16G.
<GrueMaster> Different brands even.
<infinity> My testing is mostly on a 32G Lexar class 10, which actually seems to perform faster than the box should suggest.
<infinity> But s/faster/different/ is all it takes for timing issues, really.
<GrueMaster> Ah, well I don't have any of the extremely big ones.  Cost too much still.
<GrueMaster> I actually think it may be more of a kernel issue than an actual SD card issue.  Same cards work fine on beagle.  I even have tried the microSD cards in an adapter.
<prpplague> sebjan: ping
<utlemming> skaet: for tomorrow's RC and Cloud Images....did we want to promote a daily build or not?
<skaet> utlemming,  yes we'll want to promote the daily builds to the iso tester.
<brandini> is there any word on getting mongodb to work properly on here?
<brandini> I built it by hand but it's got bugs and won't start up
<janimo> brandini, which version?
<janimo> the one in oneiric?
<janimo> do you have a bug link in LP?
<janimo> brandini, if not, please file one with details and add tag arm-porting-queue to it
<infinity> Erm, haven't we talked about it before?
<stephen_> hi#
<infinity> mongodb needs serious upstream love to support anything !x86.
<stephen_> hi
<stephen_> Trying to get HDMI working with my pandaboard on my HDMI tv. It doesnt seem to autodetect the edid and set the sscreen correctly
<stephen_> anyone have any suggestions on what I could do?
<GrueMaster> stephen_: Which Ubuntu release?
<infinity> brandini / janimo:
<infinity>   The mongodb server depends on both little-endianness and unaligned memory
<infinity>   access, which I believe means it can only work on i386 and amd64. We believe
<infinity>   that the mongodb will be useful even it is not available for all Debian
<infinity>   supported platforms.
<stephen_> Im running natty 11.04
<stephen_> (pandaboard precompiled image)
<infinity> stephen_: Is the TV pluggged in when you boot?  Hot-plugging HDMI seems to be a bit iffy here.
<GrueMaster> I just hit an oddity.  Switched my keyboard/mouse to a different system, and it reported caps-lock opposite of the keyboard LED.
<stephen_> all plugged in on boot yeh
<stephen_> my TV is slightly older, only supports 720p
<stephen_> (I need HDMI mode 16 I believe, 1280x720@50Hz)
<GrueMaster> stephen_: You might try the latest daily for Oneiric.  A lot of changes have been made to the edid code.  http://cdimage.ubuntu.com/daily-preinstalled/current
<stephen_> ah I wasnt aware one of those was avilable yet :) I'll certainly give that a shot. If not, where is a good resource for bootargs
<stephen_> I was having a look around, but the wiki I saw was a bit light
<GrueMaster> I'll have to look for the bootargs, but I think they are on omappedia.org
<stephen_> for bootargs, when I create a boot.scr would I just need the opne arg, or are there other trimmings requred?
<infinity> You shouldn't need any args at all, unless autodetection still fails us.
<GrueMaster> infinity: On some sets it may.  Hence why I suggested using Oneiric as a test first.
<stephen_> I will be giving oneric a shot as soon as I can. After that Ill pop back if I don't have any luck
<stephen_> Im expecting that it wont work, as my TV is probably a bit useless.
<stephen_> I just had a look at boot.script in my /boot directory
<AustereGrim> Ok, so I think I'm going to start putting my abilities to getting ubuntu arm on the android toshiba thrive...
<stephen_> is it just a plain text file, or will I be needing to use the boot.scr way (I forgot the exact commands)
<GrueMaster> AustereGrim: Cool.  Good luck.  If you succeed maybe we can add it to our community images next cycle.
<AustereGrim> GrueMaster I hope, it's more of a hopeful endeavour, I just don't see me needing to make another android image that someone else is already doing the same thing...
<GrueMaster> stephen_: The link you want for the display parameters is http://omappedia.org/wiki/Bootargs_for_enabling_display
<stephen_> ah i see
<stephen_> omapfb.mode=1280x720MR-24@50
<stephen_> is that what I would likely want?
<GrueMaster> Possibly.  Not sure about your system.
<MrCurious> got a second grue?
<stephen_> for HDMI is it more likely that sort of thing, or setting omapfb.hdmimode
<GrueMaster> MrCurious: Barely, what's up?
<GrueMaster> stephen_: I think the omapfb.mode is what you want, but I'm not really sure.
<MrCurious> was thinking about reinstalling pandaboard ubuntu and was wondering if the usb speed fix has made it into the distro's yet and if you knew
<stephen_> thanks anyway :)
<stephen_> ill try oneric, then experiment :)
<GrueMaster> MrCurious: It is in Maverick-updates and Oneiric.  I have to test Natty-proposed as soon as it comes up (this week I hope).
<MrCurious> awesome
<MrCurious> so i just have to be a little more patient :)
<infinity> MrCurious: Or just install oneiric and help test. ;)
<MrCurious> is Oneiric a 11.10 variant?
<GrueMaster> One and the same.
<MrCurious> then i definitely need to give it a test run (in a week when the fix i hang on is in)
<infinity> MrCurious: Hrm?
<infinity> MrCurious: What fix is that?
<MrCurious> usb speed
<infinity> MrCurious: It's in.
<MrCurious> hard disk/camera
<GrueMaster> Maverick=10.10, Natty=11.04, Oneiric=11.10, and as of today, Precise=12.04.
<infinity> MrCurious: It's only natty where the fix is lagging.  It's been in oneiric for ages.
<GrueMaster> MrCurious: It is in on the Oneiric builds for a few weeks now.
<MrCurious> then i have something for this weekend. locating its download spot now :)
<GrueMaster> MrCurious: http://cdimage.ubuntu.com/daily-preinstalled/current.
<GrueMaster> Even has working audio.
<MrCurious> even better, but i was only about 2 clicks away from there, and i lost the race :(
<MrCurious> thanks, will cry and complain once i get it installed :P
<MrCurious> that was funnier before i typed it
<infinity> I'll go put on my ignoring IRC pants.
<MrCurious> guess i wont be quitting that day job any time soon
<GrueMaster> heh
<zul> hey how do you get into single user mode on the pandaboard?
<GrueMaster> Single user mode?  I would guess it is the same on any Ubuntu platform (not that I know what that is).
<GrueMaster> MrCurious: If you ask any silly questions, I will be forced to make you listen to http://www.youtube.com/watch?v=TIPWGAzEZlA
<GrueMaster> :P
<AustereGrim> I was reading about that... in the creation of a live cd.
<AustereGrim> https://help.ubuntu.com/community/LiveCDCustomization if it helps
<AustereGrim> uhm single user mode...
<AustereGrim> "Removing the (Casper) Autologin" ?
<AustereGrim> or reverse of that?
<zul> GrueMaster: with uboot?
<AustereGrim> or is that something different than what you're looking for zul?
<zul> something different i changed a permission on a file that i shouldnt have and now i cant login i need a way to init=/bin/sh with ubuntu
<zul> s/ubuntu/uboot/g
<AustereGrim> ah... i get you... sorry.
<janimo> infinity, thanks, had no idea they were so non-portable. I wonder if it was a consciously made trade-off or it just happened
<janimo> maybe in order to dealwith their bson format they do byte level manipulation or it is too slow
<GrueMaster> zul: SD or USB drive?  OYu can just mount the device on a pc (running linux) and reedit the file.
<zul> GrueMaster: sd card i dont have an sd reader handy
<GrueMaster> Ah.
<infinity> janimo: I imagine it could be ported (but perhaps with non-portable DB formats, which is fairly common for that sort of thing), but I also suspect it would be some Serious Effort.
<janimo> infinity, their focus is probably speed (that's what  I keep hearing about mongo) so they do not even consider ARM for the moment
<brandini> janimo: thanks for the reply
<brandini> I'm running daily
<infinity> janimo: ARM likes speed!
<infinity> janimo: But yeah.  I don't think it's a "throw a few hours at the problem" deal, I think it's a "get deeply involved upstream and seriously think it through" thing.
<janimo> brandini, see what infinity said, that is likely more helpful than what I said. Still a bug in LP as a reminder/tracker would not hurt, maybe even linked to an upstram bug if it exists
<janimo> infinity, well fox likes grapes too
<infinity> janimo: Is that a Romanian saying?
<brandini> janimo: they have a bug filed in their tracker
<brandini> they being mongodb
<janimo> infinity, hmm, I think it is from one of Aesoph's fables
<janimo> fox saying grapes wee sour after it could not reach them
<janimo> but regardless, probably a bad analogy
<brandini> are there alternative nosql DB's that run on arm?
<janimo> as in ARM likes speed, but cannot attain it at the level x86 does these days
<janimo> brandini, couchdb does
<brandini> excellent
<infinity> brandini: By "nosql", you mean not SQL, or not an RDBMS server?
<janimo> casandra and other java based ones are affected by java itself being slow and buggy on ARM
<janimo> open source java that is
<AustereGrim> java, slow? buggy? nooo... that can't be... .
<infinity> (And it also depends on how you want to access it... If via libraries and bindings is cool, the options are endless...)
<infinity> BDB and SQLite being the two usual choices, though.
<brandini> ugh, an apache project :)
<brandini> how well does couchdb run on the pandaboard?
<brandini> I can give it an SSD to store its data on :)
<MrCurious> grue: little fluffy clouds rocks
<MrCurious> perhaps the worse version of the song, but at the same time intriguing
<MrCurious> wow! even a surprise ending
<MrCurious> sounded a bit jordi to me
#ubuntu-arm 2011-10-06
<jcrigby> infinity, ping?
<infinity> jcrigby: Sup?
<jcrigby> infinity, I had a question really stupid question google did not help
<jcrigby> but I figured it out
<infinity> Now I'm curious. :)
<jcrigby> to target -proposed in an upload you just put the -proposed in the changelong
<jcrigby> duh
<jcrigby> oneiric-proposed
<jcrigby> I didn't know that
<infinity> This is me not laughing.
<jcrigby> now I am
<jcrigby> it finally occured to me when I saw some -proposed names listed with other release names and then I realized its just a different release sorta
<dash> hmm. trying to set up my new mx53 with oneiric but all of these instructions seem to assume you're flashing stuff onto the microsd card instead of installing from, like, the same machine.
<dash> is this possible at all? :)
<dash> or do I need to get a second computer with an sd reader involved
<infinity> dash: If you have a micro->regular SD adaptor, you can write to the SD from the same machine. :P
<jcrigby> dash, quick start has two card slots
<infinity> dash: But our installer is meant to install from microSD, yes.
<infinity> jcrigby: You can only boot from micro.
<dash> sorry, I mean: it's booted from the microsd card
<dash> i don't see how to install a new kernel from there, though.
<dash> the postinst script for the kernel package fails
<infinity> Installing a new kernel on the Freescale-provided image is non-trivial.
<dash> aaah.
<infinity> It's sitting in raw unpartitioned space.
<dash> okay that makes sense.
<infinity> You're better off using our image, which is much more sane. :P
<dash> so i shouild reflash it with a linaro image and then do things.
<dash> great, now i get it. :D
<infinity> s/linaro/ubuntu/
<dash> infinity: oh. OK cool
 * infinity notes the channel name.
<infinity> http://cdimage.ubuntu.com/daily-preinstalled/current/oneiric-preinstalled-desktop-armel+mx5.img.gz
<dash> infinity: nice
<infinity> Or if you wanted server....
<infinity> Oh.  We don't do mx5 for server.
<infinity> So, don't want that.
<infinity> Enjoy the desktop image! ;)
<dash> hee
<dash> won't be the first desktop image I have deinstalled stuff from. :)
<dash> thanks!
<MrCurious_> 11.10 looks pretty. painfully slow on SD
<MrCurious_> so far though, its working nice
<MrCurious_> sound service went belly up
<MrCurious_> sending a report ... slowly
<MrCurious_> obsolite package installed libodio
<MrCurious_> upgrade it and re-try
<MrCurious_> wonder if its easy to turn off video out on panda board to save some power
<infinity> jcrigby: Any reason that u-boot went to -proposed?
<infinity> jcrigby: If we want those 4460 fixes on images, we want them in the release pocket.  Or did you figure it's too risky?
<MrCurious_> 11.10 is giving me troubles. refusing to install omap4 add ons
<MrCurious_> got it installed installing the omap4 meta package from a shell
<infinity> Not that there's anything in the PPA for oneiric yet.
<infinity> OH.  That reminds me, we still point at the natty PPA.
<infinity> Must fix.
<infinity> Almost forgot.
<MrCurious_> that did not end well
<infinity> rsalveti: I'm changing the default ti-omap4-ppa entry to point to oneiric.  Would be really nice if there was a metapackage there to install.  Hint, hint.
<MrCurious_> reboot and now i am console only
<MrCurious_> yeah
<MrCurious_> you mean in teh gui, the meta package that it cant find
<infinity> MrCurious_: The ti-omap4-extras may have been a bad idea.
<MrCurious_> may may not be the right word
<MrCurious_> wanted to test usb speed
<infinity> Just uninstall the packages and reboot.
<MrCurious_> but installing the omap addons borked it all
<infinity> USB speed has nothing to do with the ti-omap stuff.
<MrCurious_> but gui speed does
<infinity> Little bit.
<MrCurious_> they really want to both be there for my usb cam speed test
<infinity> But such is life, until we get oneiric-compatible packages.
<infinity> Which better be soon.
<MrCurious_> now i wonder if 10.04 has the usb fix
<infinity> Not that I know of.
<MrCurious_> i think 10.04 does
<MrCurious_> but last i tried it, it had its own issues
<MrCurious_> anyone here know how to disable video out on pandaboard? i can champion this platform at work if it can go under 2 watts on average
<infinity> No idea.
<MrCurious_> wonder how close the omap4 add ons are to being compatable
<infinity> I'm going to go with "not very".
<infinity> But we've been promised (repeatedly) that all that binary mess would be available for oneiric.
<twb> "disable video" -- cut the pins :P
<infinity> I need to chase that up in the next week before release.
 * janimo goes to bed, infinity is awake. janimo gets out of bed, infinity is awake
<infinity> janimo: You missed the Canonical conference where I was given sleeping pills as a gag gift, clearly.
<janimo> for sure I did
<twb> infinity: did they work?
<infinity> twb: Dunno, didn't try 'em.
<infinity> jcrigby: While I'm pinging you with overnight questions, linux-meta-linaro is horribly out of date, and even if it wasn't, it'll not be vaguely broken because two linaro sources (s5pv310 and u8500) haven't been updated to 3.0.0-1007.9
<infinity> jcrigby: Can we either drop things you're no longer supporting, up upload new versions of those? :P
<twb> Are those packages the linaro kernel, built with stock ubuntu GCC? or built with linaro gcc?
<infinity> Ubuntu GCC is Linaro GCC, more or less.
<infinity> We pull from them.
<twb> What, even for non-arm people?
<infinity> I'd have to look again, but I imagine doko has a massive from_linaro patch in the sources that's only applied on ARM builds. :P
<twb> So if I'm sitting on an amd64 lucid host, that *won't* include linaro code when I just run "cc foo", right?
<doko> infinity, no, applied everywhere
<infinity> Checking that suspicion right now.
<infinity> doko: Thanks.
<infinity> twb: I was wrong. :0
<infinity> :)
<twb> doko: is that just ubuntu, or is that also debian?
<doko> ubuntu only
<twb> OK.
<twb> I have been building u-boot images with Debian armhf and armel chroots, and they don't do anything when I flash them, so my next step is to try linaro gcc
<twb> I guess I can do that from an ubuntu chroot instead, which will be much easier than having to download some cross-compiler tarball blob from linaro
<doko> Debian armel is armv4, so there might be differences. armhf has the same configury
<twb> doko: I don't understand.  Are you saying that if Debian armhf gcc generates a broken u-boot.bin, then Ubuntu armel gcc is likely to also generate a broken u-boot.bin?
<doko> twb, I say that the configure command line is the same, ubuntu still has hardening enabled. I didn't check for anything else
<twb> OK
<twb> But the linaro patches might contain some workarounds for some funky errata on my tegra system, so I should still try it?
<doko> I didn't follow the start of the discussion. sure, you can try it. or you could rebuild the gcc-4.6 debian package, enabling the linaro changes
<twb> OK, thanks
<twb> (You missed the start of the discussion because that happened a week ago :-)
<doko> rsalveti, is qt4-x11 still built for armv6? see bug 791256
<ubot2> Launchpad bug 791256 in binutils "qt4-x11 version 4:4.7.3-1ubuntu1 failed to build on armel: assertion fail ../../bfd/elf32-arm.c:12008" [High,Incomplete] https://launchpad.net/bugs/791256
<ogra_> infinity, no swap on ac100 ... i dont want to trash peoples MMCs as they are non replaceable
<ogra_> NCommander, still around ? i need input on banshee pretty much now and there is no info on the bug about the status
<ogra_> infinity, ARGH ! thanks for the PPA fix, how could i miss that
<fourlastor> hello everyone, where i can find the repository list for ubuntu-arm? :)
<ogra_> oh, he's gone already
<htr> anyone knows where can I buy a devboard ?
<ogra_> try pandaboard.org
<htr> tyvm :)
<huge_> I can't get DVI output ... some help?
<xranby> huge_: which board?
<huge_> Panda
<huge_> Omap4 image
<infinity> Are you using the right output?
<xranby> huge_: for me i get dvi out on the hdmi port
<xranby> huge_: are you trying to use two monitors at once?
<infinity> Only on the right port.  The left one is HDMI-only.
<huge_> i need to connect 2 displays ... HDMI display (HDMI port) DVI display DVI-P port
<huge_> DVI-D
<infinity> Not positive it supports driving both at once.
<infinity> But it might.
<infinity> Never tried.
<ogra_> i dont think it does atm
<huge_> if i'd like to have only DVI Monitor?
<huge_> it does not work too
<huge_> so Can i connect only once monitor at once?
<huge_> and only in HDMI output?
<huge_> and also wich version are u using?
<xranby> i tested the daily  imx5 image on a imx53 quickstart board yesterday.   some premissons are probably set wrong on that image , oem-setup completed sucessfully   but  what i observed was the following : 1. users cant run dmesg     2. dhclient cant set the routing table thus all networking was broken
<xranby> ogra_: GrueMaster: do you test the imx5 image regulary?
<ogra_> xranby, janimo does, not sure how regular though
<xranby> ok i will retest with todays image as well..
<janimo> xranby, I tested an image after beta2 but not regularly
<janimo> I saw the same issues - I thought dmesg permission was a new ubuntu default so did not pay attention
<janimo> IIRC there were discussions about turning it off. But I did not see it on other boards so likely a bug then
<xranby> janimo: for me gui was.. dead slow..   possibly related to sdcard performance
<janimo> and also I saw no network on first boot/install
<janimo> xranby, both GrueMaster and I found it very very slow
<xranby> janimo: for me the netfork information tool in the upper corner listed all obtained dhcp settings  but  it failed to actually setup the system wide global routing table and default gw
<janimo> our kernel may be buggy, linaro has more than one mx53 flavoured kernel, we may have picked one that has been less tested. I think they are at 3.0 now with mx5
<xranby> after i entered the routing table manually network worked flawlessly
<xranby> janimo: dot he board need some driver pack to enhance gui?
<xranby> i think the lucid image that got shipped with the board was quite quick
<xranby> and snappy
<xranby> for gui stuff
<janimo> xranby, indeed, that factory image is impressively fast
<janimo> unfortunately freescale does not distribute their closed source graphics stack
<xranby> oh.. :( how sad
<janimo> so one cannot freely use it
<janimo> indeed
<xranby> i thought they did
<janimo> only for commercial partners I think and without right to redistribution
<janimo> I know there were various downloads on their sites but they may be incomplete
<ppisati> ogra_: can you reming me where alsa* settings where?
 * xranby starts dig round on http://imxcommunity.org
<ppisati> ogra_: dist-upgraded this morning and the audio fix it _seems_ it's not there
<ogra_> ppisati, you mean which package or which path ?
<ppisati> ogra_: the path where the settings where stored
<ogra_> in /usr/share/alsa/ucm
<ppisati> ok
<ppisati> uhm, no
<ppisati> it was a different one last time
<ppisati> let me see if i can find it
<ppisati> /var/lib/alsa/asound.state that's it
<xranby> ppisati: oh so i can somehow use this if i messed up the mixer settings on the ac100 ?
<ppisati> xranby: remeber to axe it in single user mode
<ppisati> xranby: it's regenerated during shutdown
<xranby> ppisati: sos boot to the rescue.. will try axe it and see what happens
<xranby> ppisati: \o/ i hear sound again!   thanks axing that file fixed
<xranby> i somehow messed up when testing to use xfce4-mixer
<xranby> im quite impressed that runescape.com actually runs on the ac100  using software rendering  ..  but it could need some opengl-es acceleration
<doko> xranby, using JamVM?
<xranby> doko: yes
<xranby> using jamvm
<xranby> on my ac100
<doko> nice
<xranby> doko: i start to suspect tghat the panda kernel have stability issues under heavy load
<xranby> thins start to lock up on the panda when i try the same
<xranby> like gnome-system-monitor can lock up
<doko> is swap enabled?
<xranby> doko: no
<doko> my panda is up for 30 days, running openjdk/gcc builds & tests, and some other builds. so it looks stable for me
<xranby> doko: great
<xranby> doko: do you have any usb gadget attached?
<doko> is a disk a gadget?
<xranby> doko: if you have running it for 30 days please tell me your kernel version
<xranby> yes
<xranby> a disk are a gadeget
<doko> wait, it now only 10 days after the last kernel update. 2.6.38-1208-omap4
<doko> ahh, the natty kernel ...
<doko> sorry
<xranby> doko: thank you for reporting that it runs stable using the natty kernel :)
<xranby> im having issues with the oneiric kernel :/
<doko> ogra_, ^^
<ogra_> hmm, file a bug, i know tobin tests daily if possible, though i dont think he tests compiling or other heavy load bits
<xranby> ogra_: i will
<xranby> this probably are related the bug that jamespage filed for arm server https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/845158
<ubot2> Launchpad bug 845158 in openjdk-6 "Frequent java task hang on ARM server" [Undecided,Confirmed]
<BlInK311> hey guys, I was having a problem with oneiric on the pandaboard last night.  after it went through the system configuration it just looped back to system config.  any ideas?
<ogra_> BlInK311, talk to GrueMaster (once he is up (~2h i guess)) he seems to see that as well, nobody else can reproduce it though
<ogra_> would be good to know if you guys use the same Sd cards or some such
<BlInK311> i used a sandisk 4gb class 6 card.  I think it was an extreme 3 or something.  Ill can double check it if you need
<ogra_> yesm double check with GrueMaster
<BlInK311> will do
<BlInK311> i also loaded it onto a uSD card for my beagle xm but didnt get a chance to boot it up last night
<ogra_> heh, hrw are you worried the best-buy offer wont persist until you are in orlando ?
<ogra_> i guess you could just buy them there
<hrw> ogra_: last time, when hp touchpads went to 99$, they were out in 2-3 days if not less
<ogra_> hrw, there are likely more flyers thna touchpads in the world ... but i get what you mean
<hrw> after hannspad disaster I prefer to not spend too much on unknown tablets
<ogra_> heh
<ogra_> apart from the annoying sharp metal edges and frame i can really recommend the transformer btw
<hrw> too expensive
<xranby> ogra_: can you use the ac100 kernel on the transformer?
<ogra_> no idea, mine runs android
<ogra_> :)
<hrw> ogra_: you? android?
<ogra_> but i know there is a transformer kernel somewhere
<ogra_> hrw, gingerbread isnt badd
<hrw> ogra_: you mean honeycomb?
<ogra_> err, yes
<ogra_> sill ynames
<hrw> ogra_: 3.2 maybe. I played with 3.0 and was not so impressed
<hrw> ogra_: ubuntu also has silly names ;d
<ogra_> ubuntu has cool names :)
<ogra_> well, i'm running 3.2 here
<hrw> ogra_: matter of view
<ogra_> 3.2.1 actually
<ogra_> with a new update pending apparently
<ogra_> (asus is really fast wrt android updates)
<xranby> doko: i have reverted back to the natty kernel on my panda and now runescape loads past 20%updates   ... looks stable  *touch wood*
<xranby> its a quite intence cpu stress benchmark.. both cores running at 100% + disk io
<xranby> (loading runescape throtthes both cores up to 80%     starting gnome-system-monitor chart view makes both cpu's go up to 100
<rsalveti> infinity: why are you pinging me about the metapackage? :-)
<rsalveti> infinity: ndec should be your man for that
<ogra_> and ndec is aware :)
<rsalveti> doko: let me check
<jcrigby> infinity, on the 4460 stuff we thought it was too late to get into image so thats why it is in proposed
<jcrigby> infinity, on the meta the unsupported platforms are out in the linaro ppa versions
<jcrigby> but it has not been uploaded to ubuntu forever
<xranby> ogra_: GrueMaster: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/869190
<ubot2> Launchpad bug 869190 in linux-ti-omap4 "panda-oneiric 3.0.0-1205-omap4 runescape crash running under heavy load" [Undecided,New]
<ogra_> thanks !
<BlInK311> GrueMaster. you on?
<GrueMaster> I am.  Coffee isn't.
<BlInK311> last night I had an issue with oneiric looping through the initial system config on the pandaboard.  i heard you were the only other one who had this issue
<BlInK311> did you figure out what caused this?
<GrueMaster> No, I haven't.  I can reproduce it on several systems with several different SD cards though.  The only thing I have found that seems to get around it a little is to edit /etc/fstab on the rootfs and add "discard" to the options for mounting /
<GrueMaster> It slows down execution a bit, and you need to remove it after oem-config is finished.
<BlInK311> hmm... i was using a sandisk extreme 3 4gb class 6 card.  dont know if you had this on this card
<ogra_> GrueMaster, slows down ?
<ogra_> it definitely should speed up :)
<GrueMaster> Not that particular card, but on several others from 4G-16G, class 4, 6, and 10.
<ogra_> TRIM (disacard) limits the amount fof needed writes
<ogra_> though your HW (the card) needs to support it
<GrueMaster> ogra_: Yes.  it slows down a little.  Not sure why.
<ogra_> else its a noop
<ogra_> blame the kernel :)
<GrueMaster> That may be it.
<ogra_> we had massive probs with TRIM on sandisk with the ac100
<Martyn> How did we miss getting openmpi 1.5.3(or 4) into the repositories?
<ogra_> fi our kernel misses a patch on omap4 then you might get issues
<Martyn> openmpi 1.4 is broken on ARM, and only 1.5.3 works
<ogra_> Martyn, ask debian and the person who didnt file a bug about the breakage :)
<Neko> ogra_, is there any way to find out if the card supports discard?
<ogra_> dunno
 * GrueMaster forages for coffee.
<ogra_> the probs we had was with an eMMC for that it was easy to find ourt
<Neko> maybe I just try BLKDISCARD and see if the ioctl fails miserably?
<BlInK311> ill give the "discard" a try tonigh and see if it affects it
<ogra_> NCommander, did you see my ping above
<NCommander> ogra_: no, I just got up
<ogra_> would really help if you regulary updated the bug in times where others rely on your info
<NCommander> ogra_: if I had many ANY progress I would denote it
<ogra_> NCommander, i needed to know about it this morning
<ogra_> even noting down the no progress would hgave been a valuable info ;)
<NCommander> ogra_: you could pick up your phone and call me
<NCommander> :-P
<ogra_> NCommander, luckily there are issues so we dont roll RCs yet
<ogra_> NCommander, well, after i told you several times that i need to know it on thu, i was somewhat expecting it had stuck in your head :P
<AustereGrim> ogra_ i'm looking to start working on getting ubuntu-arm on the toshiba thrive tablet. do you have any tips on where to start?
<GrueMaster> ogra_: Both NCommander and I have been working hard on figuring out Banshee.  I finally found the point of exception, but not the calling function.
<ogra_> AustereGrim, for the rootfs i would start with ubuntu-core
<AustereGrim> ok
<GrueMaster> At this point, I think it would be best to dump banshee as I don't think we can get a fix anytime soon (today).
<ogra_> GrueMaster, lets talk about tech stuff in the meeting, the point was that deadline for RC (and the possible switch to RB) was this morning EU time
<GrueMaster> I was never given a deadline beyond Thursday.
<GrueMaster> No time.
<AustereGrim> are you guys currently working with Oneiric for arm builds? (to replace android systems)
<AustereGrim> or should I attempt work with a previous release?
<infinity> AustereGrim: Is the Thrive using a kernel and bootloader similar to ac100?
<AustereGrim> I'm not sure, I haven't touched the ac100
 * ogra_ doubts that 
<ogra_> even the transformer needs its own kernel, despite the fact that they are the same SoC
<AustereGrim> I doubt it too... but I do have the release of the source from toshiba
<ogra_> well, start with ubuntu-core for a rootfs and make your kernel and bootloader work with it
<AustereGrim> ok... sounds like a found starting point. I'm new to this game, so it's not going to be natural to me.
<ogra_> well, all you need is kernel and bootloader ... and the kernel buiult with options ubuntu userspace understands
<AustereGrim> ok
<AustereGrim> So I've downloaded the oneiric core daily build, is this where I should start with?
<ogra_> thats your userspacce
<AustereGrim> ok I get that... and need to build a kernel that boots to this userspace
<ogra_> right
<AustereGrim> and that would be based on the linux kernel that toshiba has provided
<ogra_> right
<AustereGrim> ok, I think I see where I need to go. =)
<AustereGrim> Thanks ogra_ I might be starting some work on this this weekend. I know I'm going to need you advice along the way here.
<ogra_> well, i'm not much around on weekends, but during the week ...
<ogra_> there are 132 people in this channel though
<ogra_> ;)
<AustereGrim> =) I work on the week days... where I'm on irc at work
<AustereGrim> but weekends I'll have time to work on this project
<ogra_> well, you are currently standing in my office (and GrueMaster's, infinity's, janimo's and NCommander's) ;)
<ogra_> (and the office of amyn more here i guess)
<ogra_> 'many
<AustereGrim> understood, and I appreciate your hospitality. ;-)
<rsalveti> jcrigby: hey, infinity seems ok to push your latest u-boot-linaro upload for the release
<rsalveti> instead of proposed
<rsalveti> as there's still time for the release, and it sounds critical enough
<infinity> ( I rejected it from proposed and mentioned this already )
<jcrigby> so I just just repush to vanilla oneiric?
<jcrigby> ok
<infinity> jcrigby: Pretty please, yes.
<infinity> jcrigby: And let's talk kernels in a sec.
<jcrigby> ok
<GrueMaster> ogra_: I was following.  Not sure what I could have said during the meeting on the BP stuff.
<infinity> jcrigby: So...
<ogra_> GrueMaster, indeed, and i dont think you should have that many specs the next cycle anyway :)
<jcrigby> infinity, yes
<infinity> jcrigby: Two things.  Why don't linux-linaro-s5pv310 and linux-linaro-u8500 match vexpress, omap, and mx51?
<GrueMaster> The main one I need to look at writing up is the bare metal automation testing.  Not sure what to categorize it under, as it affects more than just arm.
<infinity> jcrigby: And if and when they do, we need meta-linaro updated.
<infinity> jcrigby: (If you have no intention of keeping all 5 sources in ABI lockstep, then the meta needs to be split out)
<jcrigby> infinity, I added them way back and they were never used for anything so finally removed them from source
<infinity> jcrigby: Oh, if those flavours are dead, you could always inform us and have them removed from the archive.
<infinity> jcrigby: Happy to purge them with fire.
<jcrigby> that would be great
<infinity> jcrigby: Then we'd just need a meta upload that drops those, and bumps the ABI for the other 3.
<infinity> (Pretty please)
<jcrigby> will do that right now
<infinity> \o/
 * infinity needs to eat breakfast for once... Stomach is rebelling.
<LPhas> http://imageshack.us/photo/my-images/338/screenshothzu.png/ coming soon XD
<AustereGrim> LPhas I don't understand what I'm looking at. :-P
<LPhas> AustereGrim, you are looking at this https://github.com/utz/SYNEplayer
<LPhas> i made a small application that let you play several videos in synchrony
<AustereGrim> i see
<LPhas> over TCP/IP network, not only on the same machine like the screenshoots suggests
<AustereGrim> ah
<AustereGrim> oh
<AustereGrim> using multicast? or direct connection?
<LPhas> UDP direct connection
<LPhas> "connection"
<LPhas> well basically it uses Network Clocks that are an already available feature of gstreamer
<AustereGrim> hrm...
<AustereGrim> I'm trying to think of it's use in something..
<AustereGrim> but my requirement for it has been depreciated
<LPhas> well it'll be used for a sort of "fake acquarium" on a cruise liner
<AustereGrim> Yeah, no I see it's use in digital signage
<LPhas> AustereGrim, "digital signage"?
<AustereGrim> uh...
<AustereGrim> like displays that all show the same thing
<LPhas> oh
<AustereGrim> either a video or just text
<AustereGrim> mainly a public display that shows information about a topic (area, company, product)
<LPhas> AustereGrim, oh, teah well, of course this is an application
<LPhas> i wish i'd have a client for this XD
<LPhas> would be the quickest job of my life XD
<AustereGrim> if it works well in low bandwidth environments, and doesn't rely on broadcast (packets) then there is a use for it. but our need for it has been depreciated like I said . =(
<LPhas> too bad :(
<infinity> jcrigby: Thanks for the uploads.
<LPhas> it doens't rely on broadcast, i didn't tested the bandwith requirements
<LPhas> i think that bandwidth can be low but latency shold be low also
<LPhas> not more that 1/fps i think
<LPhas> but i have no clue
<AustereGrim> low bandwidth, as in wireless speeds... 54mb and less..
<LPhas> well, i'll be suprised if it can't work in such enviroment
<LPhas> but the real syncronization code is not made by me
<LPhas> so i've no clue
<AustereGrim> well good work and good luck
<LPhas> heh thx for the "good luck"
<LPhas> they should approve another project based on this
<LPhas> with 10 pandaboards and 10 hdtv
<LPhas> this would be fun
<AustereGrim> LPhas that's kind of what we've been working with, but it's been depreciated from streaming video, to small boxes behind hdtvs displaying a webpage/slideshow
<AustereGrim> less bandwitdh if it's just displaying a webpage... than pushing video stream to each client box
<LPhas> well, in my design at the moment every box will have his video
<LPhas> because the video is static and this solution is way simpler
<AustereGrim> bbiaf
<LPhas> so no streaming at all
<infinity> GrueMaster: https://bugs.launchpad.net/ubuntu/+source/geoclue seems to have a whole lot of dupes of your geoclue crash. :P
<infinity> Oh, most of which might be private due to stacktraces being attached.
<infinity> But I see 19 dupes.
<ogra_> infinity, and someone in -devel bringing up the same bugs once an hour
 * infinity wonders what team he's in that's letting him see all the bugs...
<GrueMaster> bug-control team
<brandini> Just did a dist-upgrade
<LPhas> lol i so was on the wrong channel
<LPhas> i tought i was on #gstreamer when i posted my app XD
<GrueMaster> LPhas: But does it run on arm?
<LPhas> GrueMaster, well not tested but should be
<LPhas> i mean, gstreamer usually works on a pandaboard
<LPhas> should work just fine or so i hope since i will need to use that on the panda
<AustereGrim> lol @ LPhas I was wondering why you posted here... kind of off topic.
<GrueMaster> AustereGrim: If it runs on ubuntu arm images, than it is PDC info.  (Pretty Damn Cool).  :P
<MrCurious_> gruemaster: tried the 11.10 last night, and it went cripled as soon as i added omap4 add ons
<GrueMaster> ok.  have you filed a bug yet?
<GrueMaster> I'm currently tracking down banshee issues.
<MrCurious_> i dodnt want to have to lissen to grey clouds again
<GrueMaster> heh
<MrCurious_> i need to wake up more before i try to spell/type
<MrCurious_> since i got the time, lets try todays fresh-hot-one
 * GrueMaster wonders if the banshee failure is related to no 3D (and no clutter) support.
<ogra_> GrueMaster, hmm, might be, though its should fall back to SW rendering
<GrueMaster> Red herring.  debian/rules shows --disable-clutter
<ogra_> good
<ogra_> clutter will bite us badly next release
<ogra_> no this one though :)
<GrueMaster> Interesting.  The packages builds with --enable-meego, then deletes the meego related files.
<ogra_> heh
<LPhas> AustereGrim, eheh, found some audience btw XD
<MrCurious_> gruemaster: my camera is getting 102FPS, up from < 29FPS  major improvement. suspect only thing keeping it from 125fps is not having omap4 video drivers...
<GrueMaster> Cool.
<MrCurious_> yes, very!
<MrCurious_> his will come together nicely soon
<Guest83239> Just trying to install ubuntu-omap4-extras to my pandaboard on oneric
<Guest83239> <Guest83239> Ive added the PPA, but that meta package doesnt exist
<Guest83239> <Guest83239> any ideas?
<MrCurious_> i think omap4 add ons arent yet ready for 11.10
<GrueMaster> Guest83239: They haven't been pushed yet from upstream.  Word is "soon".
<Guest83239> any way to get them 'in development'
<Guest83239> or are they not event close to ready and would make system very unstable?
<GrueMaster> Not that I know of.  I'm not upstream.
<GrueMaster> This banshee bug is frustrating.  It feels like there is a missing config or something, but I have scanned the manifests and come up short.  The failure occurs because a value lt 0 is passed to a size function, but I have no idea where this comes from.
<Guest83239> My screen is now detected (using 11.10) so I get a display (thanks Grue for yesterday)
<Guest83239> However, the picture misses a border around the sides
<GrueMaster> Guest83239: Excellent.
<GrueMaster> picture?
<Guest83239> the desktop
<Guest83239> like its zoomed on the centre leaving some offscreen
<Guest83239> (top bar, sides, bottom)
<GrueMaster> Ah, overscan.
<Guest83239> thats the one, easy fix?
<Guest83239> :)
<Guest83239> (thanks in advance)
<GrueMaster> Not sure.
<GrueMaster> I don't have a 720p screen to test on.
<Guest83239> ah nevermind :) ill find a solution with some digging (I hope). My other issue is audio, in the sound menu it says im using 'dummy audio' which emans I cant get any sound (over HDMI or 3.5mm). My luck
<Guest83239> :p
<gildean> Guest83239: if you're using an external display, did you try to use the "auto" screen positioning option on it?
<Guest83239> auto screen positioning?
<gildean> yes, on a normal external lcd display there is an option for that
<Guest83239> oh i see what you mean, ill check. its a tv
<Guest83239> on HDMI
<gildean> make sure that it's not on "wide" mode or anything, there should be a option for "exact scan" or something like that
<ogra_> Guest83239, look for a setting called overscan on your tv
<Guest83239> will do, thanks
<AustereGrim> Guest83239 or "just scan"
<AustereGrim> I know I'm 10 minutes late... but yeah
<Guest83239> hi again, whats the best video player for pandaboard? It seems to do OK with bigbuckbunny  so there must be HD support. yet with nornmal SD videos they have a poor framerate (worse when maximised)
<GrueMaster> Wow, that didn't take long.  rhythmbox is now part of the dist-upgrade.  Yea for more testing.
<gildean> GrueMaster: banshee still not running?
<GrueMaster> No, but I am deep diving now.  The hope is to have a solution prior to next week release, but rhythmbox is a stable alternate.
<GrueMaster> sigh.  Today's (20111006) image for mx5 is now respawning oem-config.  grmbl.
<GrueMaster> infinity: Why are we still seeding aptitude when x86 is not?  (BTW, I am comparing manifests to see if I can figure out the banshee issues - more questions will come up).
<infinity> GrueMaster: We're not?
<infinity> GrueMaster: Which images are you comparing?
<GrueMaster> 20111006 .
<GrueMaster> i386 vs omap4.
<infinity> I meant which flavour(s).
<GrueMaster> Nevermind.  It is pulled in by tasksel.
<GrueMaster> desktop.
<infinity> Yes, it is.  But do we have tasksel on desktop?
<GrueMaster> yes
<infinity> Accidentally getting oem-config-debconf on desktop still?
<infinity> I should sort that.
<infinity> But it's not a big deal.
<GrueMaster> There is actually a lot of packages that are missing (not just one-off due to pool spew).
<GrueMaster> Not sure.  At lib* now.
<infinity> Oh, comparing those manifests is useless. :/
<infinity> You need the manifest-desktop that's actually on the image itself, or on the buildd machines.
<infinity> The full manifest for x86 is final system + live.
<infinity> And live is a lot.
<infinity> (Our manifest is also that, but our "live" is tiny, just jasper and oem-config, plus deps)
<GrueMaster> Nah.  I filter out the cruft (casper, unity, etc).
<infinity> And filesystem tools...
<GrueMaster> I'm looking mainly for something that may affect banshee.
<infinity> Well, here's the extent of our desktop seed differences:
<infinity> desktop: * (banshee) [!armel]
<infinity> desktop: * (banshee-extension-ubuntuonemusicstore) [!armel]
<infinity> desktop: * (rhythmbox) [armel]
<infinity> Anything beyond that would be stuff that doesn't exist in the archive for us (thus isn't picked up by germinate).
<GrueMaster> Well, something has to be different for banshee to fail like it does.  Not sure why.  may be a dependency thing.
<GrueMaster> That is why I am looking.
<infinity> My assumption is on "broken code".
<GrueMaster> I'm not getting that vibe.  At least not with banshee directly.
<GrueMaster> I've done this before, in Lucid (and had the same arguments then).  Just doing a diff on seeds doesn't mean we aren't missing important bits.  We are also missing all of the *-de language packs.
<infinity> GrueMaster: Those are in live.  They get removed.
<GrueMaster> right, after installation, all unused langpacks are removed.  But during installation, they are there.  I was only giving that as an example.
<GrueMaster> Here's an odd one for you, libwayland0.  It is required by unity-2d, but only on armel (I am running x86 in a VM with unity-2d - no libwayland0).
<rawsted> anyone have a seagate dockstar in here?
<infinity> GrueMaster: libgl1-mesa depends on it.
<infinity> GrueMaster: And I suspect we pull that in for lack of DRI.
<GrueMaster> Ah.
<brandini> are there still no omap extras for the daily?
<infinity> ndec: *poke*
<infinity> ndec: What's the status of ti-omap-extras on oneiric?
#ubuntu-arm 2011-10-07
<MrCurious_> gruemaster you said sound was working.. it seems to be crashing on me every boot
<GrueMaster> MrCurious_: ???  Sound is working here on the latest daily.  Changes went in a couple of days ago.
<GrueMaster> What is crashing?
<MrCurious_> after a fresh install and first boot, it tries to send a crash report. have gotten it twice. first time it said it was sound related.
<MrCurious_> second time i couldnt work out the coause
<MrCurious_> gruemaster: i would place what i just said in the unreliable dept, as i dont remember it letter flr letter
<GrueMaster> You may have multiple crashes.  Look in /var/crash.
<MrCurious_> gruemaster yes, 3, and none are sound (jockey, oem config remove, software center)
<MrCurious_> is it ok?
<MrCurious_> whoops
<infinity> Well, none of that's "okay", per se, but none of it's sound.
<infinity> Does the oem-config-remove one have a backtrace about a D-Bus timeout?
<MrCurious_> "is it ok" was to my wife about my cooking :D
<MrCurious_> and it was...
<infinity> After I spin dailies tonight, that should be worked around.  I'd say "fixed", but the fix won't land for oneiric.  But it shouldn't happen, I hope. :/
<MrCurious_> it had a timeout at the end somethign didnt respond
<infinity> Yah, that's cause another process is running at the same time and eating your system alive.
<MrCurious_> sounds like something to avoid
<infinity> Needs a deeper fix to make the timeout actually retry or not happen, but tonight's images should at least avoid the eating alive bit.
<MrCurious_> this was last nights
<infinity> Yeah.  I mean "the ones that will be building over the next 8-12 hours"
<MrCurious_> interesting.  if you set screen blanking to off or none it blanks in 1 or 2 minutes
<twb> xset dpms force on ?
<MrCurious_> i am sure there are workarounds, i was just noting it was a case of what you say isnt what you get
<brokencodes> Any wakey wakes in here?
<brokencodes> Fresh *buntu Natty install, all updates...
<brokencodes> installed qemu-user-static...
<brokencodes> ran "sudo debootstrap --arch=armel natty eabi-chroot"
<brokencodes> Finishes with error... W: Failure trying to run: chroot /home/XXXXX/eabi-chroot mount -t proc proc /proc
<brokencodes> wtf?
<ndec> infinity: hi
<ndec> gfx packages should work. we have GST and video playback working now. and we need to finalize the packaging steps and push
<infinity> ndec: Kay.  And I assume we'll get the metapackage back?
<infinity> ndec: Since we have a shiny desktop icon to install it and everything. :)
<ogra_> infinity, there should also be a special case of libreoffice in the seeds, not only banshee
<ogra_> (it has no negated subarch entry, instead it specifies the subarches to install on (which is a bit silly i think)
<ogra_> i wonder if we should actually make that [!armel] instead, just for consistency
<ndec> infinity: yes of course! we are putting the real packages first to test them. then we will push the meta pkgs
<ogra_> ndec, well, the earlier the better, we're in RC now and havent had a chance to test if the PPA enablich actually works
<ogra_> even a meat without deps would help testing atm
<ogra_> *meta
<ogra_> heh
<ndec> ogra_: let me do that now
<ogra_> thanks :)
<ndec> ogra_: pushed. shouldn't take too long to build ;-)
<ndec> let me know how it goes
<infinity> ndec: \o/
<ndec> this is not the most difficult package we have to manage ;-0
 * ogra_ hugs ndec 
<infinity> ndec: Nope, but while you can fix your PPA post-release, we can't fix our images, so we need to make sure that installing the meta works vaguely as expected.
<ogra_> i'll test after the call today
<infinity> ndec: So, thanks. :)
<infinity> ogra_: Images won't be done building for another hour or two.
<ndec> absolutely
<ogra_> infinity, thats fine, 10:46 here :) call is in the afternoon
 * infinity glances at the clock.
<ogra_> :)
<ogra_> bde time, eh ?
<infinity> I think I need to go find some niccotine to calm my nerves and have a nap.
<ogra_> *bed even
<ogra_> have some valerian with the ciggy
<ogra_> ;)
<infinity> I have none.
<infinity> Not sure the gas station sells it.
<infinity> Almost positive they don't.
<infinity> But gin will work, right?
<infinity> It's basically the same thing.
<ogra_> sure, but wont macke your cats happy :)
<ogra_> *make
<infinity> My cats don't need any more happy.  If you ask me, they need some disappointment in their lives.
<ogra_> lol
<infinity> Tails always up, always expecting the best from life.  Spoiled brats.
<ogra_> then probably go for melatonin instead of valerian
<infinity> Time to take them back to the dealer and trade them in for kittens anyway.
<infinity> Who wants 3-year-old used cats?
<ndec> infinity: where are you based?
<infinity> ndec: Calgary, AB, Canada.
<ogra_> heh
<ndec> ouch...
<ogra_> why ouch ?
<ndec> it's like 3AM?
<infinity> Yup.
<ogra_> (apart from the weather)
<infinity> It's early!
<infinity> I only slept about 3 hours last night.
<ogra_> good morning then :)
<infinity> Tonight's going to be at least 4!
<infinity> Progress.
<ogra_> so stop talking about sleeping now, DO IT !
<infinity> I should start making soap and beating myself up.
<infinity> Unfortunately, Helena Bonham Carter doesn't return my phone calls.
<ogra_> geez, evil !
<infinity> Yeah, she's a bit cruel.
<ogra_> did she promise to ?
<infinity> Not in so many words.
<infinity> But I saw the look in her eye as they dragged me away.
<infinity> It was love.
<ogra_> tell her you will start dating scarlett johanssen if she doesnt answer
<ogra_> envy is a good motivator ;)
 * infinity goes shopping.
<infinity> ndec: Thanks again.  You gave me something to test tomorrow.
<infinity> (And potentially cry over when software-center crashes trying to do something simple)
<ogra_> well, we'll corner mvo if it doesnt work
<jeremiah_> Hmm. Helena won't return my calls either. And she keeps changing her number. :-/
<SysTom> Get the hint.
<jondo> Hi to all. I am currently trying to boot my  BeagleBoard-xM rev C with yesterday's daily oneiric-preinstalled-desktop-armel+omap.img.gz
<jondo> and now I am stuck at the language selection dialog and neither USB keyboard nor mouse do work.
<jondo> Also, there is no LAN LED activity. Can it be that my power supply is too weak? I am currently switchable power supply that says '12 VA', set to 5 V.
<jondo> ... currently using a ...
<jondo> ogra_?
<ogra_> oh !
<ogra_> its a "Precise Pangolin" we'll have for the next 6 months
<twb> What's my sources.list supposed to look like?
<twb> deb http://ports.ubuntu.com/ ubuntu main universe <-- doesn't like me
<ogra_> http://ports.ubuntu.com/ubuntu-ports
<ogra_> you miss the dir
<twb> Ah, silly me
<twb> Well, that's working, just sucky-ass speed for some reason
<festhead> hi. I'm trying to get the dsp of omap4430 working. i use css5 to create an executable (*.out), copy it to my pandaboard and try to execute it, but it gives the error: " -bash: ./hello.out: cannot execute binary file"
<twb> 89% [4 Packages 4816 kB/5610 kB 85%] 24.1 kB/s 32s
<jondo> ogra_, have you got my recent mail about my BeagleBoard problems?
<ogra_> jondo, did you try to start over ?
<ogra_> (just reboot wiht the SD inserted)
<jondo> Not yet. I just powered it off. I'm gonna try this now. You mean ctrl-alt-del?
<ogra_> as you like
<ogra_> you can just pull the power otherwise
<jondo> I'm in the language dialog again, and ctrl-alt-del does not work. Powering off and on also does not help: the language dialog reappears, and neither mouse nor keyboard work.
<ogra_> very strange, since it does for everyone else
<ogra_> sounds a bit like your USB isnt initialized or failing due to not enough power
<ogra_> do you by chnace have a powered hub you could try ?
<xranby> jondo: when i used the beagle i allways had to attach keyboard and mouse to a selfpowered usb hub
<jondo> I am currently using a 5V / 2A power supply. I'll search the office for a hub. And I have also got a second Beagleboard, that is not unwrapped yet.
<ogra_> well, 2A should *theoretically* be sufficient
<ogra_> (i use a 4A here though)
<brandini> morning
<jondo> With a powered USB hub, still no keyboard and mouse :(
<jondo> But how can there be not enough power with Ubuntu, when keyboard, mouse and LAN work fine with Angstrom Linux?
<jondo> (As noted in the mail, the green and yellow LAN socket LEDs do not light up with Ubuntu.)
<brandini> then your usb is not being attached properly
<brandini> LAN socket it over usb
<brandini> look at your dmesg for "not configured" or some such
<jondo> Ok, I'll look at dmesg. You mean, the LAN socket is connected over usb?
<brandini> yes
<brandini> the lan device is usb->ethernet
<jondo> BTW, my second BeagleBoard shows the same symptoms.
<jondo> I'll continue testing on Monday. Bye!
<brandini> sounds like software IMO
<rOxx> Hello, iÂ´m using socketcan on my beagleboard xm and i have problems with flooding logfiles. the time stamp of the entries are <1ms and the logfiles are fast bigger than 1gb and the disk going full. i^m using mcp2515 can controller and kernel 3.0.0-x of robertcnelson repository. can someone help me or have an idear what i can do ?
<rOxx> the entries look like this:
<rOxx> Oct  7 15:23:37 gtrtbb kernel: [ 5813.138458] omap2_mcspi omap2_mcspi.4: rpm_suspend flags 0x0
<rOxx> Oct  7 15:23:37 gtrtbb kernel: [ 5813.138580] omap2_mcspi omap2_mcspi.4: rpm_resume returns 0
<rOxx> and
<rOxx> Oct  7 15:23:37 gtrtbb kernel: [ 5813.138458] omap2_mcspi omap2_mcspi.4: rpm_suspend flags 0x0
<rOxx> Oct  7 15:23:37 gtrtbb kernel: [ 5813.138580] omap2_mcspi omap2_mcspi.4: rpm_resume returns 0
<rOxx> Oct  7 15:24:00 gtrtbb kernel: [ 5836.953948] smsc95xx 1-2.1:1.0: rpm_resume flags 0x5
<rOxx> Oct  7 15:24:00 gtrtbb kernel: [ 5836.783325] smsc95xx 1-2.1:1.0: rpm_resume returns 1
<brandini> so still no omap4-extras for daily?
<ogra_> brandini, should be there, testing would be appreciated
<brandini> how are we supposed to know what bugs are in daily without that stuff?
<brandini> ok, I'm running server and I'm not sure how to add the extras repo?
<ogra_> heh, yeah, that doesnt get us the test result we look for
<brandini> :)
<ogra_> there is a graphics subpage onm the omap wikipage
<ogra_> that explains how to enable the ppa manually
<brandini> k
<brandini> oh look, linero
<brandini> err linaro
<brandini> from here ogra_? http://www.omappedia.org/wiki/Get_started_with_ubuntu_on_omap4
<ogra_> brandini, no!
<ogra_> wiki.ubuntu.com/ARM/OMAP
<brandini> I think I tried that, but here I go again!
<xranby> janimo: GrueMaster: the daily 111007 imx5 image works like a charm for me now...   network routes work during oem-config and gui feels more responsive!     still some waiting between that the oem-setup window dissapears to and the gui restarts to show lightdm login. aptd are it are still doing some configuration during the wait...
<ogra_> lightdm is a snail
<ogra_> (and i suspect it doesnt actually match its name ... i think its far from being actually light)
<brandini> ogra_: thanks, great tip :)
<ogra_> :)
<xranby> ogra_: indeed.. everything went snail after lightdm login
<xranby> on the imx53
<xranby> ogra_: workaround by installing gdm?
<ogra_> nah
<xranby> i will check if using gdm changes anything
<ogra_> i doubt that, gdm might not have light in its name, but its not lighter :)
<ogra_> i would also assume its rather soemthing like metacitys composite that draws the power
<xranby> ogra_: the snail feeling are really.. odd   i mean the pointer flies and updates so fast like its on fire... while any event you send to the gui takes about 7sec to be recieved
<ogra_> ouch
<xranby> andwhen the 7 seconds pass a blimp of snappyness occours  gui gets instantly updated and then it takes some seconds for next event to get processed
<ogra_> the image is a tech preview so, while thats not nice, i dont think we will change anything on it for oneiric
<xranby> ok
<ogra_> not sure how mature the kernel is yet etc
<xranby> so to sum it up.. everything looks fast on the paper but the user experience are bleeding
<xranby> network traffic ok
<xranby> io traffic ok
<xranby> etc
<xranby> console works ok
<ogra_> well, i would blame the framebuffer driver then
<xranby> kind of odd since it felt reasonable fast during oem-config
<xranby> oh well
<xranby> at least it work
<xranby> for hosting buildd's
<xranby> and arm server testing
<janimo> xranby, good to know, probably the swap enablement fixed it. Thanks for the feedback!
<brandini> so now that I've got omap4-extras I dunno what to do with them
<GrueMaster> Um, test them?  Just a suggestion.  :P
<brandini> :)
<brandini> well the one thing I was most concerned about that worked on 10.10 was the go/src/pkg/time test that is still failing :(
<xranby> janimo: the main observation that i do on the imx53 are that redrawing the gui eats cpu time.. with unity2d idle running gnome-system-monitor   then  gnome-system-monitor eats 30-80% of cpu time when it are updating the gui
<xranby> ogra_: so yeah ^ might be some work needed on the framebuffer driver
<xranby> someone know how to check how fast the Xorg screen redraw itself?
<ogra_> probably the guys in #ubuntu-x
<xranby> i have now flooded their channel
<xranby> unfortunally noone seems around
<xranby> or awake
<saliak> anyone had luck with the preinstalled image for Natty on the beagleBoardXM?  I installed it and it boots,etc but doesn't find the /dev/usb0 NIC
<saliak> I can boot the test angstrom image and everything works fine.  not sure what else I need to do in ubuntu, any ideas?
<GrueMaster> saliak: Which rev beagleXM?
<GrueMaster> And what does ifconfig report?
<saliak> rev C
<saliak> ifconfig only reports lo
<saliak> it seems like something is missing,which is weird since it's the prebuilt headless image
<five> hi
<five> need help regarding dual display on pandaboard with ubuntu 11.04
<five> any suggestion
<five> i am not able to get this done from couple of days
<five> any one with any suggestions
<GrueMaster> saliak: Sorry, I was called away for a bit.  Can you try the latest daily Oneiric?  http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current
<saliak> np, yeah, i'll check that out now
<GrueMaster> five: I haven't tested this out (yet).  I think it requires the closed drivers for video, but they were not available for Natty.
<saliak> is there a patch for revC like there was for natty?
<GrueMaster> saliak: It "should" just work.
<GrueMaster> The natty patch was due to hw release after Natty freeze.
<five> can u please tell me which OS on pandaboard will support dual monitors
<GrueMaster> five: We only deal with Ubuntu-arm here.  You could try our latest, which is due to release next week.  Get it at http://cdimage.ubuntu.com/daily-preinstalled/current.  Also, You may want to ask in #pandaboard.
<five> thanks GrueMaster
<saliak> GrueMaster: will those images run headless?
<GrueMaster> The server image is essentially the headless image with additional packages, yes.
<saliak> GrueMaster : just to make sure i'm not making a stupid mistake, beagle board is omap3, right?
<GrueMaster> saliak: Yes.
<GrueMaster> So pull the oneiric-preinstalled-server-armel+omap.img.gz file
<GrueMaster> Erm, oops.  Ubiquity Slideshow has a slide on Banshee, which we replaced at the last minute because it fails on arm.  Doh!
<GrueMaster> infinity: ^^^
<infinity> Not much we can do about that.  We're not forking the slideshow. :/
<GrueMaster> I know.  Just found it kind of amusing.
<infinity> Won't disagree with that. :)
<GrueMaster> I'll refrain from filing a bug.
<GrueMaster> Will add it to the arm release notes wiki though.
<Daviey> GrueMaster: Do you have a seperate release notes regarding ARM page?
<GrueMaster> I do for previous releases.  Haven't started an Oneiric one.  But it usually is for stuff specific to the arm images.  Any i386/amd64 issues are usually mirrored on arm so I consider them redundant.
<Daviey> GrueMaster: sure.. when you have it, i'd like to see arm server things. Can you ping me pls?
<GrueMaster> sigh.  oem-config-remove appears to have crashed on mx5.
<GrueMaster> Daviey: sure thing, although the release notes will be specific to iso testing.  Everything else isn't really automated yet.
<Daviey> GrueMaster: After next week, I want to kick of a discussion regarding testing - i need you to be a key part of it :)
<Daviey> (all flavours, shared methodology)
<GrueMaster> Sure.  I will also be attending the testing BoF at UDS.
<GrueMaster> infinity: any ideas on how to get some info on why oem-config is respawning on mx5?  It hasn't happened (yet) on any other platform.  Still need to test beaglexm.
<Daviey> GrueMaster: I want to brainstorm before UDS TBH
<infinity> GrueMaster: Other than pulling the card for logs, I don't have any remote debugging ideas right now.
<GrueMaster> Daviey: No problem.
<infinity> GrueMaster: But I suspect the whole thing is just a bit racy, and hardware speed (and dumb luck) triggers the problems. :/
<R_Nev> oem-config, that's the thing that asks for language and such?
<infinity> And username and stuff, yes.
<GrueMaster> infinity: It appears that it is crashing when launching oem-config-remove-gtk.  No other explaination.  I do have an odd error in oem-config.log, but that is related to keymaps.
<infinity> Something, somewhere, must say something. :/
<R_Nev> cool, thought it was only me; stopped after the fourth one last night
<GrueMaster> But that appears on startup.
<GrueMaster> Need to smack the installer team into adding meaningful log messages on fail.
<infinity> Unless oem-config-wrapper doesn't log anywhere...
<infinity> Balls.
<infinity> And it really doesn't.
<GrueMaster> As I said...
<GrueMaster> excellent.
<infinity> Maybe /var/log/installer/dm ?
<infinity> But I'm not sure if output from oem-config-wrapper will actually get caught by the DM.
<infinity> Probably not.
<GrueMaster> No, dm looks (almost) like an Xorg log.
<GrueMaster> I have scoured /var/log for any semblence of sanity.  None found.
<GrueMaster> I can release note it.  It will be a big annoyance, but what else can you do?
<infinity> I suspect with enough tries and the right moon phase, it'll work.
<saliak> GrueMaster: so I used the Oneiric image and have the same issue.  there's no /dev/usb0
<saliak> GrueMaster: if i boot off the test sd card with the Angstrom image, the network hardware works fine
<GrueMaster> R_Nev: The workaround (for now) is to go to a text console when oem-config respawns, log in and run "sudo oem-config-remove" then reboot.
<GrueMaster> saliak: Try unplugging the network cable, then plugging it back in.  I have been seeing this issue for a while and reported it upstream.
<GrueMaster> Thought it was just my hardware.
<infinity> The screen just blanked on my Panda in the middle of the install...
<GrueMaster> saliak: Wait a few seconds before plugging back in.
<GrueMaster> infinity: Try switching to console 1 then back.
<infinity> Nada.
<infinity> This is disconcerting.
 * infinity re-flashes the card and goes for another try.
<saliak> GrueMaster: nada here as well.
<GrueMaster> infinity: I was going to ask if you still had blinken lights.
 * GrueMaster can see a lot of release note editing in his future.
<infinity> Yeahp.
<infinity> There seemed to be plenty of SD activity.
<infinity> And the heartbeat.
<saliak> GrueMaster: i did everything over the serial port.  any chance it needs a keyboard/monitor during some setup stage for something that has to do with the network?
<GrueMaster> saliak: Not on the headless.  Do you have link lights on the port?
<saliak> GrueMaster : no link lights.  that's the weird thing, it's like the hardware is disabled
<saliak> GrueMaster : hrm, during boot it says "unbable to enumerage usb device on port 2"
<saliak> GrueMaster : I wonder if that's the NIC..
<infinity> lsusb?
<GrueMaster> saliak: unplug the network cable, wait a few seconds and plug it in.  That seems to make mine work again.
<saliak> GrueMaster: shoot, need to run.  will be back on later to continue.. thanks for everyone's help
<GrueMaster> How in the he!! can I have obsolete packages?  I thought the pool was frozen?  And why would libpciaccess0 matter for reporting a bug on plymouthd?
<GrueMaster> on a platform without PCI?
<infinity> GrueMaster: Because, thanks to the plymouth/drm nonsense that I didn't have time to try to fix, libpciaccess0 is actually a plymouth dep. :/
<GrueMaster> Grrrr.
<GrueMaster> infinity: I am showing 30 upgraded packages in oneiric, with -security and -updates disabled.  Tell me this isn't the final image.
<infinity> GrueMaster: No, it's not.
<infinity> GrueMaster: It's the image we want some testing against before we build real RCs Sunday night.
<GrueMaster> ok.
<infinity> (And with any luck, those will be final, but like that ever happens)
<GrueMaster> I'll look at the plymouthd crash data and see if it is anything to be concerned about.
<infinity> NCommander: software-center traceback and failure to find the package perfectly reproducible on amd64, BTW.  Just cp jasper-initramfs/ppa/ti-omap4* /usr/share/app-install/channels/ and then xdg-open jasper-initramfs/ppa/ti-omap4-ppa.desktop
<infinity> NCommander: I'll look into it later, but if you get to it before me, yay.
 * infinity finishes getting dressed and leaves.
#ubuntu-arm 2011-10-08
<16SAA0FCX> lilstevie: I built u-boot.bin from an oneiric armel chroot, using ubuntu's gcc-4.4 and it *still* didn't display anything on screen
<16SAA0FCX> Hmm, WTF happened to my nick
<GrueMaster> infinity: So the plan is to have both Rhythmbox & Banshee on the final image?
<twb> lilstevie: also the case for ubuntu armel gcc-4.6.
<twb> Presumably I don't need to try with the linaro gcc because doko said those should have the linaro patches applied
<saliak> is anyone using a beagle board xm rev c?  if so, can you tell me what you see when you do lsusb?
<GrueMaster> saliak: Give me a sec, I'm currently flashing a new SD card.
<saliak> GrueMaster : sure
<GrueMaster> btw, which image are you using?  Natty or Oneiric?
<saliak> Oneiric
<saliak> I tried natty before and had the exact same results
<GrueMaster> How are you powering your board?  DC adapter or OTG port?
<saliak> OTG port
<saliak> So it's so wierd, when i boot the angstrom image it works
<saliak> during boot it finds usb0
<saliak> and the port lights up
<GrueMaster> If you can, try an AC adapter.  I am reading the SRM, and on Rev C they enabled SW power detection and a few other GPIO changes that may affect the USB controller.  We may not have the required changes in our kernel.
<saliak> and lsusb returns 4 devices (2 hubs, and 2 more).  vs, when i boot the ubuntu image, there are only 2 root hubs
<saliak> ok, lemme grab a PS and try
<GrueMaster> Right.  Sounds like our kernel is broken.
<saliak> I setill get the "unable to enumerate usb device on port 2 error
<saliak> and no network lights
<saliak> even with an external power supply
<GrueMaster> interesting.
<GrueMaster> here's my lsusb btw:  http://paste.ubuntu.com/704285/
<GrueMaster> The last two are a 4 port usb switch I use as a poor-man's KVM, followed by an external sata drive.
<GrueMaster> I have a rev B board though.  I think someone botched the usb hub driver in the kernel though when they tried to incorporate the Rev B > Rev C changes.
<saliak> yeah
<saliak> on my angstrom boot i see the first 4
<saliak> on my ubuntu boot, just the first two
<saliak> I'm not the first person to see this, right?
<saliak> GrueMaster: wouldn't those have been incorporated in the revC patch on Natty?
<GrueMaster> sadly, I think so.  I don't have that board rev.
<saliak> didn't someone have that board rev?  which is how they realized there needed to be a patch?
<GrueMaster> I think the Natty patch was to just get the board ID into u-boot iirc.
<GrueMaster> Unfortunately it isn't unusual for an SOC board to change and see the public before we know about the changes.
<GrueMaster> And most of our focus is on omap4 this last cycle.
<saliak> Ah, I see.  That sucks.  So what's my best bet at this stage?
<GrueMaster> File a bug with details.  Also, if you can add to the testing info on http://iso.qa.ubuntu.com/ that would greatly be appreciated (not required though).
<GrueMaster> Best I can do is push our kernel guy to get hot on it and spin a test kernel, maybe Monday.  It would have to go through the proposed stage for testing and be added to the updates though.
<GrueMaster> brb
<infinity> GrueMaster: No, the plan is just rhythmbox, unless we can identify the banshee issue, then just banshee.
<GrueMaster> infinity: Leave both.  We can release note it and SRU if we can fix it.  It isn't getting fixed by Sunday thought.
<GrueMaster> though
<infinity> GrueMaster: Not sure how the indicator UI will look with both installed.
<infinity> I guess it just shows both.  Pretty ugly, since one won't work.
<infinity> I'm not sure I'm comfy with that unless we're sure we can fix it.
<GrueMaster> It only shows banshee until you launch rhythmbox.
<GrueMaster> I'm trying various things here, but I am also swamped with image testing.
<GrueMaster> infinity: I also reopened the alsa-utils portion of bug 820466.  No audio input.  I commented on the bug as such.  I think it is just a matter of mucking with the ucm files.
<ubot2> Launchpad bug 820466 in alsa-utils "No sound on omap4 pandaboard" [Low,Confirmed] https://launchpad.net/bugs/820466
<GrueMaster> Definitely an SRU candidate.
<infinity> I need to find a microphone to test that...
<infinity> Or an 1/8th to 1/8th cable.
<GrueMaster> No, you need to plug into your cell phone or something powered.  It is an unpowered jack.
<GrueMaster> line-in only.
<infinity> Well, I have no 1/8th to 1/8th cable. :P
<infinity> I'll dig through boxes of bits later.
<infinity> Are we sure it worked before?
<GrueMaster> Again, not critical.
<infinity> Cause the profiles should be identical now.
<GrueMaster> yes, it worked in Natty.
<GrueMaster> The kernel driver changed.  I need to look at it more.
<infinity> Ahh, but not necessarily in oneiric-before-the-rename.
<infinity> Anyhow, yeah, not critical.
<GrueMaster> Sigh, alsa is one area I do have experience in.
<infinity> Trying to nail a few software-center bugs right now.
<infinity> I'm so glad we keep reinventing these wheels.
<GrueMaster> yep.
<GrueMaster> Wow.  Beaglexm looks much better when I change the default 1280x720-16 to 1280x1024-24 on my 19" LCD monitor.
<GrueMaster> Wish edid worked.
 * cooloney hands a beer to GrueMaster 
 * GrueMaster is already drinking a bottle of Moose Drool, but doesn't mind double fisting the beer.
<cooloney> GrueMaster: hey, man, what's the holiday in US next Monday?
<GrueMaster> We have a holiday?
 * GrueMaster looks
<GrueMaster> Oh, Columbus day.  The day we celebrate some European who thinks he discovered a new land (oddly full of people standing on the beach and staring wildly at the crazy white man in the boat).
<GrueMaster> Hmm.  I already signed it off as a holiday and had it approved.  Isn't that...special.
<cooloney> GrueMaster: good holiday, 10/10 is my marriage anniversory
<GrueMaster> Cool.
<GrueMaster> Time for the Angry Dragon?
<cooloney> GrueMaster: last year a week before 10/10, we were in Texas. thanks for taking me around in Frys
<cooloney> GrueMaster: oh, what's Angry Dragon?
<GrueMaster> I remember.  I also remember Budhapest.
<GrueMaster> Heh heh.  You'll have to look it up.  Same area as Donkey Punch.
<GrueMaster> (remember?)
<GrueMaster> But seriously, I hope you and your wife have a great 1st anniversary.
<cooloney> GrueMaster: OMG, i like the English lesson
 * GrueMaster has been debugging banshee all week and is feeling a bit rummy.
<cooloney> GrueMaster: Thanks a lot, man
<GrueMaster> Heh.
<GrueMaster> No problem.  Thats why I'm here.  :P
<cooloney> GrueMaster: i assume you are working on ARM server image instead of Banshee
<GrueMaster> No, I spent most of the cycle pipe cleaning server loads.  Now with release next week I need to test desktop heavily and other images.
<MrCurious_> does the latest 11.10 have issues with loopign on install?
<MrCurious_> i am on my 3rd time through :(
<GrueMaster> MrCurious_: I have a workaround.  Go to a text console (<ctrl><alt><F1>) and type "sudo oem-config-remove; sudo reboot".
<MrCurious_> ty, trying
<GrueMaster> For some reason, oem-config-remove is not getting launched and the config restarts.
<infinity> I sure would love to be able to reproduce that here.
<infinity> *sigh*
<GrueMaster> We haven't been able to figure it out yet, but we believe it is a timing issue.  I "sometimes" get it, depending on the SD card I use and the platform I am running on.
<infinity> I have a feeling I'll just have a Panda looping the install over and over in London until I can get it to fail.
<infinity> Maybe I can borrow differing SDs from other people.
<MrCurious_> race conditions suck
<infinity> GrueMaster: If you can sort of reliably fix it, maybe editing oem-config-firstboot to redirect output from oem-config-wrapper to a logfile would prove enlightening.
<infinity> s/fix/reproduce/
<infinity> Brain fried.  Turkey coma.
<GrueMaster> I'll give it a whirl.
<GrueMaster> Kind of fried here myself though.
<infinity> Don't blame you.
<infinity> And, honestly, if this desktop release isn't our shiniest and most wonderful, I'm not sure it's a huge deal.  Still sucks that we were all so focussed on other things until, uhm, last week. :/
<MrCurious_> any idea if the omap addons metapackage plays nice?
<infinity> MrCurious_: It's completely empty right now.
<infinity> (The one for oneiric)
<infinity> So, yeah, it plays well. )
<MrCurious_> that would be a no :)
<infinity> It'll be updated "soon".
<GrueMaster> You asked if it plays well, not if it works well.
<GrueMaster> :P
<infinity> ^
<infinity> Well, it works perfectly too, for an empty package...
<infinity> Does everything I'd expect an empty package to do.
<MrCurious_> :)
<infinity> software-center, on the other hand, is making me want to kick puppies.
<infinity> And I don't mean a little nudge, I mean propping them up on the noses and kicking them through the uprights.
<infinity> s/on the/on their/
<lilstevie> twb: sorry I was at a developer workshop
<lilstevie> twb: hmm, well idk what is causing your issues
<infinity> GrueMaster: Oh, feh.  The reason banshee stayed on the desktop is cause other stuff recommends it (like unity-lens-music, for instance)
<brandini> AHA! With today's dist-update Go's time test finally passes!
<saliak> GrueMaster : for what it's worth, i was finally able to boot ubuntu with the custom kernel from http://elinux.org/BeagleBoardUbuntu#Demo_Image
<saliak> GrueMaster : with network support working
<robclark> GrueMaster, is it just me, or does oneirick ubuntu-core img miss something to start a login console on ttyO2?
<ogra_> robclark, the ourpose of -core is to be just enough OS to run apt-get, nothing more
<ogra_> *purpose
<ogra_> its thought as a base for people wanting to create rootfses
<robclark> how can I run apt-get without a login console ;-)
<ogra_> (read: its up to you to put something like that in place)
<robclark> where do I read?
<ogra_> though i agree that its a bug that upstart doesnt ship a job for serial consoles by default
<robclark> anyways, it seems like it would be a lot more useful to folks who just want a bare img if a serial console came up :-)
<ogra_> https://help.ubuntu.com/community/SerialConsoleHowto
<robclark> gotcha, thx
<ogra_> well, its for example the base of IVI images where you dont have any login at all
<robclark> hmm
<ogra_> (it think the most people currently use it as a cheap debootstrap replacement to quickly get a chroot)
 * robclark is just looking for something to easily get baseport/kernel folks off of ancient busybox fs of unknown origin..
<ogra_> ah, yeah, seems to be the right thing (after you created a ttyO0.conf indeed)
<ogra_> or O2 :)
<robclark> maybe I'll just tar up after I have ttyO2.conf and give that to other folks internally..
<robclark> easier to just explain "tar xzf ..." than other steps
<robclark> ogra_, btw, do firmware files (ie /lib/firmware/...) usually get packaged in uInitrd?
<robclark> I've been playing w/ syslink3 stuff, and seems like linux firmware loading infrastructure doesn't play nice w/ uInitrd..
<robclark> fails to find firmware file
 * robclark is wondering if rpmsg driver should have some mechanism to try again later to find the firmware, after real rootfs is loaded
<infinity> robclark: By default, it packs up any firmware referred to by a module.
<robclark> hmm, ok.. so then the firmware really needs to be packaged w/ the kernel, and can't come separately?
<infinity> robclark: See manual_add_modules() in /usr/share/initramfs-tools/hook-functions
<robclark> ok
<infinity> No, we package ours seperately.
<infinity> But see that function for how it's detected, might give you hints about the driver doing something wrong.
<robclark> well, I'm not trying to package yet.. I was just manually copying /lib/firmware/ducati-m3.bin and scratching my head for a while about why it wasn't getting found..
<robclark> until I realized it worked if I bypassed uInitrd
<robclark> so I guess uInitrd must get regenerated when firmware is installed?
<infinity> robclark: Yeah, we re-run update-initramfs when we install new kernels, drivers, or firmware.
<infinity> (Or anything in the initrd, for that matter)
<robclark> ok, that works
<GrueMaster> ogra_: Are you testing the AC100 image?
<GrueMaster> I know we really want to make jasper die a fiery death, but it would be nice if it could at least put a serial console config file on the desktop images.  Make testing a little easier for me.
<GrueMaster> That or openssh-server.
<infinity> GrueMaster: jasper automatically copies serial.conf into the root if you have console=tty* on the command line.
#ubuntu-arm 2011-10-09
<GrueMaster> ogra_: Nevermind.  I swiped NCommander's AC100 and am nuking it now.
<R_Nev> the red color output is at max on my beagleboard xm when running ubuntu; does anyone else have this issue?
<MrCurious_> must say ubuntu keeps looking better and better
<brandini> dudes
<stephen_> hi all, whats the best media player for getting a good framerate (running pandaboard with ti 1080p addon_)
#ubuntu-arm 2012-10-01
<ogra_> infinity, help !
<infinity> ogra_: ?
<ogra_> infinity, i have a linker issue and wasted my whole day on it already :(
 * ogra_ is super frustrated 
<ppisati> squashfs?
<ogra_> nah
<ogra_> tegra driver
<ppisati> quantal-server-armhf+omap.squashfs
<ppisati> i just noticed it
<ogra_> 10 min update ... 6h hunting  the linker
<ppisati> i feel sorry for you :)
<ogra_> infinity, so libGLESv2.so isnt versioned ... the package installes it to /usr/lib/nvidia-tegra and sets an ld.so.conf.d option ot use that path
<ogra_> during package build i create a proper symlink libGLESv2.so.2
<ndec_> ogra_: well... you should just ditch your tegra...
<ogra_> using ldconfig in quantal i get libGLESv2.so -> libGLESv2.so.2
<ppisati> ndec_: besides, any news on the omap5 panda side?
<ogra_> now running es2_info i get a lib not found error
<infinity> ogra_: If it's not versioned, I'm not sure what you think the symlink will accomplish.
<infinity> ogra_: If the ELF header doesn't have the versioned SONAME in it, you're fighting a losing battle there.
<ogra_> infinity, if i set LD_LIBRARY_PATH it works, if i copy the whole set of libs to /usr/lib or /lib ir works too
<ndec_> ppisati: any news?
<ogra_> and it worked with the same packaging in precise
<ndec_> it's coming soon.
<ogra_> infinity, so why do /usr/lib and /lib as well as setting the var just work then ?
<ogra_> (and why did it just work in precise as is)
<infinity> ogra_: Dunno.  Don't we use update-alternatives for GL/GLES in all the other packages?
<ogra_> i could make the package just install to /usr/lib indeed but i would like to know why that works if a subdir doesnt
<ogra_> infinity, we do ... doesnt help if ldconfig is so stict though
<infinity> ogra_: And I can't say for sure why yours doesn't work without seeing the package.
<ogra_> apt-get source nvidia-tegra
<infinity> (ldconfig hasn't changed at all since precise, so you're barking up the wrong blame tree there)
<ogra_> is there any way to get something readable out of objdump so that i can check what ldconfig actually sees ?
<alex-ac100> Hello All
<alex-ac100> janimo: Are you available&
<alex-ac100> ?
<janimo> alex-ac100, yes
<janimo> alex-ac100, I was just told by fly-away about the issue
<alex-ac100> Sorry for bother you, but just would like to let you know that last linux-meta-ac100 build is not correct
<alex-ac100> Ah OK, no issues
<alex-ac100> janimo: I was not awaire that have to talk with you on THIS channel, looking for you on #ac100 since yesterday evening
<janimo> ogra_, if you run ldd /usr/bin/es2_info do you get the paths that should be found?
<janimo> alex-ac100, best use the mailing list I guess. I am not on #ac100. I mostly do a kernel update from time to time since noone else does it, but do not use the ac100 otherwise
<ogra_> janimo, yes, and ?
<janimo> ogra_, are the libGLES ones missing?
<ogra_> janimo, its not about the app, its about the lib
<ogra_> the app asks ld and gets the wrong info ... unless the lib lives in /lib, /usr/lib or i gave the proper path with LD_LIBRARY_PATH
<janimo> alex-ac100, ah wait the meta build? fly-away told me about NV_SOMETHING option needing turned off or hw accel does not work
<janimo> is this a different issue?
<ogra_> in these three cases it works fine
<janimo> ogra_, is the rel16 tarball putting the files in the same place as rel15?
<ogra_> yes
<ogra_> its exactly identical, just other binaries and a few changes to udev rules and the xorg.conf snippet
<infinity> ogra_: What do you mean "not about the app, it's about the lib"?  What does "ldd /usr/bin/es2_info" say?
<alex-ac100> janimo: looks like in kernel from linux-metaac100 has CONFIG_TEGRA_NVAVP=y in config. This is totally wrong, as this is for Tegra3 only, while ac100 is Tegra2 based
<janimo> ogra_, I know the order of the lines ld.so scripts created/appended to by the postint mattered
<janimo> I know I hated those parts of the package too
<janimo> but I hoped they should all work from now on if we do not touch them anymore
<alex-ac100> janimo: For this reason video playback is broken with this kernel build
<rsalveti> ogra_: do you know if the libs are providing a valid SONAME?
<janimo> alex-ac100, right. So you mean the new kernel package not the meta?
<janimo> the latter just says which is the actual kernel image deb and does not have any config settings
<ogra_> rsalveti, how do i find out ?
<alex-ac100> janimo: I mean this one https://lists.ubuntu.com/archives/quantal-changes/2012-September/010128.html
<ogra_> rsalveti, i definitely see the wrong name being used in ldconfig
<ogra_> rsalveti, but that didnt change vs precise ... thats my issue
<rsalveti> ogra_: objdump -x lib | grep SONAME
<janimo> alex-ac100, ok, the config issue. I was just confused by you mentioning meta (the namings are confusing for newcomers too so no problem)
<ogra_> the lib is the same way broken as in the former version
<rsalveti> ogra_: were you using update alternatives at the previous version?
<ogra_> yes
<ogra_> its the same package, i only replaced the binary blobs
<alex-ac100> janimo: Sorry, I'm not familar with terminology, so my mistake
<janimo> alex-ac100, yes, no prob, as I said confusing package names :)
<rsalveti> ogra_: by default the gl applications will look for the .so.xx libs, but I suppose you already got the links in place, right?
<ogra_> rsalveti, yep
<rsalveti> just because I saw a few gles libs just providing the .so one in the past
<rsalveti> and that caused run time issues
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ objdump -x usr/lib/libGLESv2.so |grep SONAME
<ogra_>   SONAME               libGLESv2.so
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0
<rsalveti> the problem with the lack of sonames is more if you decide to build something with it
<rsalveti> yup, no version there
<ogra_> wait
<ogra_> gets better
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ objdump -x usr/lib/libGLESv2.so |grep SONAME
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$
<infinity> The lack of proper SOVER will confuse the crap out of ld.so
<rsalveti> infinity: even at runtime?
<ogra_> so apparently ld works fine if there is no SONAME at all
<infinity> rsalveti: Yes, cause ld won't map the symbols correctly.
<rsalveti> hm, it might be the case that having SONAME but without version might be causing issues there
<ogra_> ye, it does
<ogra_> but why is just the link used if there is no SONAME ?
<ogra_> the lib lives in the same taret place in both packages
<ogra_> *target
<ogra_> with the same linakge
<rsalveti> infinity: could be, but I believe it'd probably work in this case
<ogra_> *linkage
<rsalveti> the libs are supposed to be fully compatible :-)
<infinity> ogra_: ldconfig sets up links based on SOVER.
<ogra_> also why does it work in  /usr/lib ?
<infinity> ogra_: Working in /usr/lib is probably a red herring, but let me look at this in a bit.
<rsalveti> ogra_: at the pvr-omap4 one I also had to remove the rpath from the libs
<rsalveti> to get it to work properly
<infinity> Oh, if it has an RPATH, that would explain the /usr/lib thing.
<ogra_> well, i think i would break the license if i touched the binary
<rsalveti> ogra_: can you list the rpath available at your library?
<rsalveti> not necessarily
<infinity> ogra_: chrpath -l lib.so
<rsalveti> I think at the pvr-omap4 case it had /usr/lib in it
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ chrpath -l usr/lib/libGLESv2.so
<ogra_> `usr/lib/libGLESv2.so' probably isn't a 64-bit LSB-first ELF file.
<ogra_> elf_open: Exec format error
<infinity> (And yes, that probably violates the letter of the license to change/remove the rpath but, hey, I used to hex edit GL libraries in linux-restricted-modules) :P
<ogra_> GRRR
<ogra_> one sec
<janimo> alex-ac100, btw are you sure this is for tegra3 only? The kernel  config system should not allow it to be set in that case
<rsalveti> ogra_: please try 'find usr/lib -maxdepth 1 -iname "*.so*" -type f -exec chrpath -d {} +'
<rsalveti> and see if it works better
<rsalveti> infinity: well, we're just removing stuff from the library :P
<rsalveti> not adding anything hehe
<ogra_> ogra@sabre:~/nvidia-graphics-drivers-tegra-16.0$ chrpath -l usr/lib/libGLESv2.so
<ogra_> usr/lib/libGLESv2.so: no rpath or runpath tag found.
<rsalveti> ogra_: for all libs?
<rsalveti> check the libEGL one
<infinity> rsalveti: Removing things is still altering them (but yes, I don't much care either, and back when I used to hex edit the bejesus out of nvidia and ATI's libGL, both upstreams told me they didn't care)
<infinity> That said, the nvidia upstream for the x86 drivers is a completely different group than for the ARM ones.
<infinity> For reasons I'll never understand.
<ogra_> rsalveti, yes, for all libs
<rsalveti> infinity: hehe, true
<ogra_> so now the 1mio $ question ... is there a way ro wipe the SONAME ?
<ogra_> *to
<rsalveti> the interesting thing is that it's working on the /usr/lib and /lib paths
<ogra_> right
<alex-ac100> janimo: well  not 100%, but when this nvavp option is activated, kernel tried to looad some firmware file
<alex-ac100> load
<rsalveti> ogra_: I think there might be a way to wipe it out
<janimo> alex-ac100, then maybe we just need to package that firmware file too?
<lilstevie> it should be fwiw
<alex-ac100> This firmware is not include in R16 package
<janimo> alex-ac100, at least this does not sound scary from the description:
<janimo> http://paste.ubuntu.com/1254125/
<alex-ac100> janimo: and this firmware in not necessary
<ogra_> alex-ac100, that will likely be in the codecs package
<janimo> ogra_, should we package those too?
<rsalveti> ogra_: what is the issue specifically, you're not able to find it at runtime?
<ogra_> janimo, i would like to :)
<janimo> put them in linux-firmware?
<rsalveti> ogra_: even when forcing the ld path?
<ogra_> rsalveti, right
<alex-ac100> janimo: ogra_ no, I tested with some custome kernel build without this config settings
<ogra_> as said above it works with LD:LIBRARY_PATH (which likely just overrides ld here and uses the links)
<alex-ac100> Hardware Video playback worked fine on that build
<ogra_> k
<alex-ac100> WITHOUT that file
<alex-ac100> Also one guy tried to provide such firmware file, it was included in some nvidia codec pack, not sure which platform. System hanged after loadin it
<alex-ac100> loading
<stuw> janimo, marvin removed nvavp from paz00_defconfig (https://gitorious.org/~marvin24/ac100/marvin24s-kernel/commit/925a5b3d7ab784fc50b4d1edc4a78fa064e7eb0e). nvavp doesn't work for us (checked on android and linux).
<janimo> stuw, ok I will remove it from the next upload
<stuw> janimo, thx
<infinity> ogra_: I'm stuck tethering this morning, but I'm downloading things as fast as I can to have a quick poke around. :P
<ogra_> infinity, i'll push the r16 package somewhere too for comparison
<infinity> ogra_: Oh, yes, please do.
 * ogra_ wants a chsoname tool :P
<infinity> That may not be the issue.  Especially if, as you claim, it works with different paths.
<infinity> But I want to look at it all first.
<infinity> (Well, it may not be the only issue... It *is* an issue that the library has a broken SONAME, but...)
<ogra_> well, the former oversion doesnt have a SONAME at all and works :)
<rsalveti> ogra_: did you try running with LD_DEBUG to see if that would help?
<ogra_> ah, no, not yet
<ogra_> what should i run that way ? ldconfig or es2_info
<rsalveti> es2_info
<ogra_> k
<rsalveti> LD_DEBUG=files
<rsalveti> LD_DEBUG=init
<rsalveti> and others as well
<infinity> I still kinda want to know what the output of ldd is/was.
<infinity> But meh.  Give me packages, and I can debug myself.
<ogra_> infinity, http://people.canonical.com/~ogra/tegra/nvidia-graphics-drivers-tegra*
<ogra_> so with ÃD_LIBRARY_PATH set i see direct_opencount=1 for libGLES
<ogra_> without the var set it properly tells me it cant find the lib
<infinity> Can't find the lib is a bit odd, since mesa installs one.
<infinity> So, something's gone horribly wrong.
<infinity> Also, installing the 15.1.0-0ubuntu1 version in my chroot just failed...
<ogra_> err, no, we have overriden the mesa install path from ld with an alternative
<infinity> update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/tegra_drv.so.dpkg-tmp': No such file or directory
<infinity> update-alternatives: error: error creating symbolic link `/usr/lib/xorg/modules/drivers/tegra_drv.so.dpkg-tmp': No such file or directory
<infinity> Brilliant.
<infinity> Also, double-paste.  Bleh.
<ogra_>  http://paste.ubuntu.com/1254162/ http://paste.ubuntu.com/1254166/
<ogra_> first is without, second with LD_LIBRARY_PATH set
<ogra_> (ldd output)
<infinity> ogra_: So, uhm.  This package is missing a dependency...
<ogra_> infinity, werid, no idea wheer that comes from
<ogra_> oh ?
<infinity> ogra_: Likely on xorg-video-abi-13.
<ogra_> the r16 package has it
<ogra_> 15 didnt, right
<infinity> Ahh, kay.  So, fixed in future. :P
<ogra_> yeah :)
<infinity> Let me install an xserver and try again.
<ogra_> precise didnt complain about that ...
<ogra_> (lintian didnt)
<ogra_> iirc now it does
<infinity> No, but installing in a bare chroot sure complains.
<infinity> (See above)
<ogra_> yeah
<infinity> Oh, still broken.
<infinity> Your package should probably also ship the /usr/lib/xorg/modules/drivers/ directory...
<infinity> Otherwise, the postinst only works if one has other X drivers installed. :P
<infinity> Which is a bit silly.
<ogra_> btw http://paste.ubuntu.com/1254177/
<ogra_> ldd with the lib in /usr/lib
<ogra_> infinity, hmm, the tarball does, weird i thought the package would just use that ... i'll add it to .dirs
<infinity> ogra_: Also, while I'm nitpicking, arm-linux-gnueabi_EGL.conf should be gnueabihf_EGL
<ogra_> infinity, r16 ;)
<ogra_> already fixed
<infinity> That could be where your problem lies.
<ogra_> no, i'm installin on a virgin ac100
<infinity> Since eabihf_EGL is an alternative shared by mesa.
<infinity> The other one wasn't.
<ogra_> eabi_EGL was until precise
<ogra_> but only on armel :)
<ogra_> for which we dont build
<infinity> (quantal-armhf)root@cthulhu:/etc/ld.so.conf.d# ls
<infinity> arm-linux-gnueabi_EGL.conf  arm-linux-gnueabihf.conf  arm-linux-gnueabihf_EGL.conf  libc.conf
<infinity> Yes, well.
<infinity> My point is that in the above scenario, we get arm-linux-gnueabi_EGL.conf parsed first (which has what you want in it).
<infinity> Once you set up the correct alternatives, it may be doing something you didn't expect.
<ogra_> right, but that file is gone in r16
<infinity> But I'll find out once I build your binaries.
<infinity> ogra_: I know the file should be gone in r16, I'm saying that might be your problem. :P
<ogra_> oh. i can push my binary for you as well ...
<infinity> ogra_: Too late, sbuild's finished installing build-deps. :P
<infinity> I assume the build itself is a few seconds.
<ogra_> yep
<ogra_> pretty niosy about the symbols :)
<ogra_> just for completion, there is no arm-linux-gnueabi_* file in my /etc/ld.so.conf.d (and never was on this install)
<ogra_> (helps to have three ac100's :) )
<ogra_> marvin24, ohhh, intrestin, with the plain kernel video driver i always need to switch to console and back after DPMS, using the tegra driver it just wakes up fine
 * ogra_ glares at http://paste.ubuntu.com/1254177/
<ogra_> intresting that it loads all the other libs from /usr/lib/nvidia-tegra ... just not EGL and GLES
<alex-ac100> ogra_: yes, wake up works better with tegra drivers
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-15~beta1$ for file in $(ls usr/lib/*.so);do  objdump -x $file|grep SONAME;done|grep .so |wc -l
<ogra_> objdump: usr/lib/libnvrm_impl.so: File format not recognized
<ogra_> 0
<ogra_> ...
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ for file in $(ls usr/lib/*.so);do  objdump -x $file|grep SONAME;done|grep .so |wc -l
<ogra_> 57
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$
<ogra_> so it seems nvidia tried to be nice and added SONAMEs all over the place ...
<ogra_> just that they didnt add any versioning ...
<ogra_> ogra@anubis:~/Devel/packages/nvidia-graphics-drivers-tegra-16.0$ for file in $(ls usr/lib/*.so);do  objdump -x $file|grep SONAME;done|grep .so. |wc -l
<ogra_> 0
 * ogra_ thinks he should just install libEGL.so and libGLESv2.so (and their links) to /usr/bin and be done
<ogra_> or link them there or so
<ogra_> the mesa ones wont be used because we override the alternative
<ogra_> infinity, ^^^ do you think that could cause any havoc ?
 * ogra_ goes to find some coffee
<rsalveti> ogra_: would probably cause issues with any gles software you might build there
<rsalveti> remember that once you built with a wrong SONAME, things get messy
<ogra_> i would be fine with that and a release note for ac100 ... and the possibility that nvidia fixes it in 3 months or so to SRU it
<ogra_> it wont make the release if i dont get it in somehow
<ogra_> and that would be a shame ... took 2 years to get nvidia to a point where they are on the same ABI and have a working driver released in time for us
<ogra_> rsalveti, also wouldnt builds use mesa anyway ?
<infinity> ogra_: Uhm, your alternatives still seem broken here.
<ogra_> infinity, in what way ?
<infinity> ogra_: In that I still have a arm-linux-gnueabi_EGL.conf with the r16 package.
<rsalveti> the broken soname would affect us even with the right and multi-arch compatible path
<ogra_> http://paste.ubuntu.com/1254227/
<ogra_> thats how it looks for me
<rsalveti> so I don't think there's any easy way out here
<ogra_> did you uninstall r15 ?
<infinity> ogra_: I just built and installed from your sources.
<rsalveti> we should probably just try to get this working with multi-arch and update-alternatives and get it to the archive
<ogra_> rsalveti, but how without hacking the SONAME ?
<rsalveti> we first need to understand if that's really the issue
<rsalveti> we currently don't know what is happening :-)
<ogra_> well, its the obvious difference between r15 and r16
<infinity> (quantal-armhf)root@cthulhu:/etc/ld.so.conf.d# update-alternatives --list arm-linux-gnueabihf_egl_conf
<infinity> /usr/lib/arm-linux-gnueabihf/mesa-egl/ld.so.conf
<ogra_> r15 no SONAME, apps follow the links ... r16 SONAME but wrong, ldconfig caches the wrong soname, apps fall over because the wrong SONAME is provided
<infinity> Before we faff about SONAMEs, let's address this business. :P
<infinity> ogra_: Are your local sources different from the ones you pointed me at?
<ogra_> just checking that
<ogra_>  --install /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf arm-linux-gnueabihf_egl_conf /usr/lib/nvidia-tegra/ld.so.conf 9000
<ogra_> thats in my current postinst
<infinity> Yeah, that's not what I have here.
<ogra_> ah, super sorry
<infinity> Also, your prerm will need to both remove the old and new ones, but maybe it does in your version.
<ogra_> not yet, but i'm aware
<infinity> Let me do this by hand and see where it lands me.
<infinity> Alright, that gets me to your breakage now.
<infinity> Hrm.
<infinity> ln -s /usr/lib/nvidia-tegra/libGLESv2.so.2 /usr/lib/
<infinity> ^-- That really shouldn't work.
<infinity> But it does. Grr.
<infinity> And LD_DEBUG=all just shows that it's not using /usr/lib/nvidia-tegra in the search path at all.
<infinity> So, not necessarily the SONAME to blame here.
<ogra_> werid, because ldconfig -v just lists the libs fine
<ogra_> i get: libGLESv2.so -> libGLESv2.so.2
<ogra_> (note the wrong order due to the SONAME)
<infinity> I don't...
<infinity> I don't get it listed at all.
<infinity> Or, I can't type.
<ogra_> well, i do, probably your alternatives are still wonky ?
<infinity> The thing is, linking it in /lib doesn't change the wonkiness of that so -> so.2 thing.
<infinity> It just starts showing up in searched.
<ogra_> with LD_DEBUG i see that libGLESv2.so.2 gets directly loaded when in /usr/lib
<infinity> seaches*
<ogra_> right
<ogra_> it will make binaries work :)
<infinity> Yeah, but.  That doesn't tell me anything about what's wrong.
 * infinity compares a chroot with r15 to one with r16 to sort this out.
<ogra_> nothin is worng (apart probably from being able to force loading of a lib if i put it in /usr/lib)
<ogra_> ld does the right thing
<infinity> Which right thing is that?
<ogra_> using the SONAME and caching the lib info with it
<ogra_> its not ld's fault that the SONAME has no version number
<infinity> Well, yes, that's the right thing, but that shouldn't relate to search paths.
<ogra_> oh, still taht
<ogra_> sorry, thought you solved that bit yet
<infinity> No, if it was searching the path, it would work.
<infinity> That's how it finds it when it's in /lib
<ogra_> oh, inbtresting ... ldconfig -v with the lib in both places shows me the SONAME issue for both even
<infinity> ogra_: Yeah, I said that earlier.
<ogra_> ah
<infinity> Okay, so looks like two bugs.
<infinity> One is the library having the wrong SONAME, which means it won't land in the cache.
<ogra_> right
<infinity> The other is that ld.so doesn't search the extended path, only ldconfig.
<ogra_> oh
<ogra_> and that changed since precise ?
<infinity> So, ldconfig will search the path and add "correct" libraries to the cache.  But our library is broken, so it doesn't get cached.
<infinity> Later, ld.so searches the cache, finds nothing, and then walks the built-in directories it knows about.
<infinity> No, it didn't change.
<infinity> The r15 library gets cached.
<infinity> And found from the cache.
<infinity> So no walking required.
<ogra_> it doesnt have a SONAME
<infinity> Yes, which is apparently better than having an incorrect one. :P
<ogra_> lol
<ogra_> yeah
<ogra_> obviously
<ogra_> so do you know any trick to wipe the SONAME field (or ven fix it)
<ogra_> *even
<infinity> If there's padding in the ELF header, you could fix it.
<infinity> Check with a hex editor.
<ogra_> padding would be zeros ?
<infinity> Yeah.
<ogra_> hexedit doesnt really show anything usable on the right ...
<ogra_> and there seem to be no zeros at the start of the file
<ogra_> GCC: (crosstool-NG hg_unknown@20110628.165246) 4.5.3
<ogra_> heh
<ogra_> 4.5
<infinity> Boom, easily fixed.
<ogra_> ??
<infinity> There's a bunch of nulls after GLIBC_2.4
<ogra_> yep, i see them
<ogra_> e_match.__cxa_call_unexpected.libGLESv2.so.GLIBC_2.4................
<infinity> So, you replace libGLESv2.so\0GLIBC_2.4\0\0 with libGLESv2.so.2\0GLIBC_2.4
<infinity> And it all magically works.
<infinity> The same needs to be done for libEGL.so.1 as well.  And who knows what else.
<infinity> A quick binary patching script to fix it up in the build wouldn't be much effort.
<ogra_> only the two to make binaries work at least
<infinity> And would be the more "correct" fix anyway.
<infinity> As annoying as it is.
<ogra_> >/me has never done somethin like this, do you know odf an example ?
<ogra_> (i manage editing with hexedit indeed, but have no idea how i would have to script that)
<infinity> sed -i -e 's/libEGL.so\x00GLIBC_2.4\x00\x00/libEGL.so.1\x00GLIBC_2.4/' /usr/lib/nvidia-tegra/libEGL.so
<ogra_> you can sed that ?!?!?!
<ogra_> geez
<infinity> ^-- That seemed to DTRT for my libEGL, cook as appropriate for others.
<infinity> ogra_: Requires GNU sed (\x00 is a GNU extention), but we don't ship any other POSIX seds anyway, so whatever.
 * ogra_ wouldnt have thought of sed ... probably some dd and cat weirdnesses, but not sed :)
<infinity> Hrm, that might not have worked actually.  sed may have broken it.
<infinity> Was good enough for ldconfig, not good enough for ld.so. :P
<infinity> (While hand-editing was good enough for both...)
<infinity> There was a nice C-based binary patches in LRM, back when LRM still existed.
<ogra_> yeah, i'm still poking bytes here
<infinity> I can try to dig it up in a bit.
<infinity> Oh wait.  Hahaha.
<infinity> No, it's not that sed broke it.
<ogra_> well, worst case i change it while repackaging the updatream tarball
<ogra_> *upstream
<infinity> It's that other libraries are linked to libEGL.so, which doesn't exist once I've done that.
<ogra_> i have to do that anyway to match the format of the package
<infinity> So braindead.
<ogra_> oh, indeed, all libs use the broken sonames :)
 * infinity head -> desk.
<infinity> So, monkey-patching the SONAMEs won't work, since while that fixes all OUR binaries, it breaks all of THEIRS.
<infinity> Brilliant.
<ogra_> btw, is there any particular reason that ld doesnt search additional dirs ?
<infinity> Other than it being painfully slow to make ld.so parse a conf.d directory for run-time configs, no.
<infinity> It's meant to trust the cache.
<ogra_> k
<infinity> Which would work, if the cache was caching libraries that weren't insane.
<ogra_> heh
<infinity> Do you have a good enough rapport with upstream to just get them to fix their SONAMEs?
<infinity> Cause this is going to end up on our end with either a mess of incorrect symlinks, or monkeypatching and a few incorrect symlinks.
<infinity> Neither is pretty.
<ogra_> not in time
<infinity> And neither is correct.
<infinity> Cause you're going to have to ship "dev" symlinks (/usr/lib/*.so) to make this work, even after patching the binaries to be unbroken.
<infinity> Well, maybe you could patch the NEEDED section in everything too...
<ogra_> well, as i said in the beginning, i would just install EGL and GLES to /usr/lib
<infinity> Yeah, or that.  Still broken. :/
<ogra_> all others arent versioned at all and are only used by these two
<ogra_> yes, but once there is a fix i wont have to fiddle with symlinks ...
<ogra_> the files would just move to lib/nvidia-tegra and ldconfig woudl pick up the change
<infinity> I'd still like to talk to upstream about doing it right.
<ogra_> i'll surely poke srwarren about it but he's despite being my contact not the maintainer
<mjrosenb> do you guys have plans for firefox-18?
<infinity> mjrosenb: When it's the current version, sre.
<infinity> s/sre/sure/
<ogra_> damned, now how do i save a file in hexedit ...
<mjrosenb> infinity: that turns on ionmonkey, which is not armhf friendly
<ogra_> pressing a key tells me F1 for help ...
<ogra_> F1 indeed gives me the gnome terminal help :P
<infinity> ogra_: I dunno, I use ghex, which appears to have sane menus.
<infinity> ogra_: That said, sed was doing the right thing for me.  It was just the NEEDED sections in OTHER libs that were still broken.
<infinity> (As in, some of the little support libs are linked against "libEGL.so")
<infinity> mjrosenb: I've not looked into it or heard much about it.  How not friendly is it?
<ogra_> ah, ctrl-x
<mjrosenb> infinity: it should need minimal modifications, but I'm considering leaving that up to a student/contributor, which means it may never get done
<infinity> rsalveti: ^-- Something for your team to poke at?
<infinity> janimo: You around?
<janimo> infinity, yes
 * janimo wonders what he broke now
<infinity> janimo: precise armadaxp.  It's an ABI bump, but no meta.
<janimo> ah, the SRU right?
<infinity> janimo: Also, don't set promote-to-proposed tasks to Fix Released if you do the copy yourself.  Cause, well.  It's in the queue, and not done. :P
<infinity> janimo: Yes.
<janimo> ok, I usually waited to see the package building before uploading the meta
<infinity> janimo: (Really, no need to do the copy yourself anyway, I notice when they need to be done, and I need to babysit them anyway)
<infinity> janimo: Erm, "see it building"?  You already copied it to the archive!
<janimo> infinity, ok. I think when I did the first SRUs at the beginnning of Q I was told I should copy them
<janimo> or they'd languish there
<infinity> Yeah, you were lied to. ;)
<infinity> (You can copy if you like, but it just ends up in the queue and someone needs to manually do overrides anyway, I prefer to do it all when I know what's going on)
<janimo> ok, I will not copy from now on, not sure why I was asked too
<infinity> janimo: Anyhow, copying yourself or not, please never do the copy until after all support packages (only meta in your case) are also done, so they can all copy together.
<janimo> infinity, ok. I always thought it's ok to have the linux-image package there without meta
<infinity> janimo: Since promote-to-proposed assumes the whole thing as a block (lbm/linux/meta/etc)
<janimo> as it does not get  upgraded to anyway until meta is there no?
<janimo> ah, I had no idea about that promote contract
<janimo> it makes sense, just I did not encounter it so far
<infinity> janimo: Even in devel releases, I prefer if it happens this way, but for SRUs, we have a pretty strict way of doing things.
<infinity> janimo: For devel releases, I'd still rather see kernel/meta go to proposed together, instead of this "we have two kernels in the archive, and one's NBS" thing.
<infinity> janimo: Anyhow.  meta the PPA up for me, if you please.  I'm going to reject the current copy for the sake of my own sanity and reset the task, and I'll do the whole thing together later.
<janimo> infinity, ok, will do
<infinity> Oh, feh.  I can't reset the task.
<infinity> I'll just reassign it to me and remember to do it later. :P
<ogra_> hmm, so i manage to empty the SONAME field, but i cant make it vanish
<ogra_> oh, and an empty SONAME really makes ld dizzy :)
<ogra_> infinity, <srwarren> We do have a bug to add (correct) sonames to the libraries, and it's also possible we half-implemented it but with bogus values. anyway, I'll track down the bug and put comments there indicating the problem.
<ogra_> (from #ac100)
<janimo> infinity, meta built in ppa
<infinity> janimo: I noticed, thanks.
<ogra_> <woglinde> swarren no chance to use cmake or autotools with libtool?
<ogra_> <srwarren> woglinde, no, we build the libraries with the same tools for Android, Linux etc.
<ogra_> <srwarren> and hence someone developed custom makefiles for it all.
<ogra_> now thats lovely
<infinity> Meh, if they figured out how to put some sort of SONAME in there, they can figure out how to make it right. :P
<infinity> Not rocket science.
<ogra_> heh, indeed
 * janimo is tempted to save the backlog of the past hours of conversation on this list for future historians who may be interested in the ways people at the beginningof 21st century struggled to convey straightforward things  due to error prone and inexpressive tools at their disposal
<janimo> to computers
<ogra_> infinity, well, i told him if he manages to get me a rebuild til thu it will make it in (given there are no other bugs)
<ogra_> lets see
<ogra_> he is very concerned
<ogra_> (srwarren is a good guy ... he's also active on cross-distro )
<ogra_> infinity, given that the driver works just fine and only the libs are affected i'm pondering to upload as is ... while GLES doesnt work then, HDMI works and xorg only uses 1/10h of ram
<ogra_> *1/10th
<ogra_> that should also make SRUing an upstream fix easy
 * ogra_ will put the current package on the shelf for thu ... if nvidia manages i can still update the tegra_bins tarball quickly
<alex-ac100> janimo: I'm afraid, but this ac100 3.1.10-5-ac100 #8 kernel build is not correct again
<janimo> alex-ac100, what is missing?
<alex-ac100> janimo: TEGRA_AVP_KERNEL_ON_MMU=y
<janimo> alex-ac100, can you clone the git tree and build the package yourself?
<janimo> did you build marvin's ?
<ogra_> TEGRA_AVP_KERNEL_ON_MMU=y is correct, no ?
<janimo> no idea
<alex-ac100> it is, but not set in last build
<ogra_> well, afaik it is
<janimo> they have  many cryptic config names which I do not know what they stand for
<ogra_> ah
<alex-ac100> same here
<ogra_> well, fly-away isnt here, he fiddled with all that multimedia playback stuff
<ogra_> (he is in #ac100 though)
<rsalveti> ogra_: infinity: I don't think sed would work there
<rsalveti> because the size is different
<rsalveti> and the elf headers stack size would probably change
<rsalveti> breaking some other stuff
<rsalveti> so I believe the easiest way to handle that is to handle the pain of having the libs at the standard locations
<rsalveti> such as /usr/lib, and get that bug opened for nvidia to handle later
<infinity> rsalveti: The sed I gave him didn't change the size.
<infinity> rsalveti: But there's breakage in their other libs havng the unversioned .so in NEEDED, so yeah.  It's all pretty FUBAR. ;)
<rsalveti> infinity: oh, true, luckly there was \0\0
<rsalveti> yeah, that's expected as well
<rsalveti> in android nobody cares about sonames
<rsalveti> actually, nobody cares about anything that's vendor/hardware specific :-)
<rsalveti> the problem is that then the vendor ends up using the same solution everywhere else :-)
<infinity> rsalveti: I'm fairly confident they'll fix it for Oli, the question is if they'll do it in a timely fashion. ;)
 * infinity thinks he should take an afternoon nap and sleep off this cold/flu/whatever.
<rsalveti> yeah, not for quantal, for sure
#ubuntu-arm 2012-10-02
<ppisati> for anyone with a real beaglexm: can you try today's daily quantal image?
<ppisati> http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-armhf+omap.img
<ppisati> thanks
<bizulk> ppisati: have you updated kernel config with tidspbridge support ?
<ppisati> bizulk: nope, busy dpoing other things
<ppisati> bizulk: which kernel version are you running?
<ppisati> bizulk: 3.2 or 3.5?
<bizulk> ppisati: 3.2.30
<ppisati> bizulk: uhm ok
<ppisati> willing to test quantal?
<ppisati> bizulk: beagle right?
<ppisati> http://cdimage.ubuntu.com/ubuntu-server/daily/current/quantal-server-armhf+omap.img
<bizulk> ppisati: is quantal 12.10 ?
<ppisati> bizulk: yep
<bizulk> ppisati: yes if the tidspbridge is installed. Cause that would be the only reason I would be a"allowed" to.
<bizulk> ppisati: I am also experiencing some network init issue on the 12.04 : nm-applet does not apply configured profile
<ppisati> bizulk: well, nm is userspace
<ppisati> bizulk: if ifconfig shows the interface, we are good
<ppisati> bizulk: actually i was looking for someone willing to do some testing on real hw
<ppisati> bizulk: since we are facing a problem with usb
<bizulk> ppisati: I have a BB xM. But as I am in the office I 'can' only work on the dspbridge stuff, u know
<bizulk> ppisati: what's your PB with USB ? it seemed to work well (using a powered usb hub in my case)
<ppisati> bizulk: ack
<ppisati> bizulk: it's broken since 3.5
<ppisati> bizulk: still broken in 3.6
<ppisati> but i wanted someone else to double check it
<ppisati> actually booting a precise 3.2 kernel everthing is ok
<ppisati> so...
<ppisati> bizulk: anyway, remind me your lp bug
<ppisati> bizulk: i'll do the config changes now
<bizulk> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1058022
<ubot2> Launchpad bug 1058022 in linux "no tidspbridge support in kernel." [Medium,Triaged]
<bizulk> ppisati: I experience USB pb on standalone 3.6 kernels, but I thoughed It was because of my power supply (usb always restarting, until the CPU itstelf resets)
<ppisati> bizulk: does it generate a /dev entry? which one?
<bizulk> /dev/DspBridge
<bizulk> ppisati: crw-rw-rw- 1 1000 1000 251, 0 2011-08-31 13:24 rootfs/dev/DspBridge
<marvin24> janimo: is the "tegra hw video decoder config bug" already fixed in some ac100 kernel image?
<marvin24> ah, just saw http://kernel.ubuntu.com/git?p=jani/ubuntu-ac100.git;a=shortlog;h=refs/heads/packaging-3.1
<marvin24> sorry
<marvin24> but still kinda wrong - did this even compile?
<janimo> marvin24, I think the deb built fine
<janimo> marvin24, I was told later that this change is not enough
<marvin24> mmh, I think we also need CONFIG_TEGRA_AVP_KERNEL_ON_MMU
<marvin24> ok
<marvin24> I tested a kernel with both options enabled only
<janimo> can someone build the package and provide the right config option changes?
<marvin24> I will ...
<marvin24> just a few secs ;-)
<janimo> cloning the repo, fdr clean, fdr editconfigs, debuild
<janimo> where fdr is fakeroot debian/rules and debuild the cross-build line
 * ogra_ would if it wouldnt take ages to pull the source package on my loaded line
<marvin24> or use a script I wrote some time ago ;-)
<janimo> ogra_, that is why you should keep the git tree checked out and updated frequently :)
<janimo> you have a beefy machine, no excuse for not building kernels anymore
<ogra_> pfft, i still stay away from git if i can
<janimo> ogra_, in this case you only need git clone, if you just want to check new stuff or do custom builds
<ogra_> and i have a local mirror ... so i can just use source packages usually ... but not for univers
<ogra_> e
<ogra_> if marc has a local branch he will surely be faster
<marvin24> ogra_: I have one
<marvin24> but building without ccache is hell
<marvin24> janimo: did you found out how to enable it?
<ogra_> what are you building on ?
<marvin24> x86_64
<ogra_> well, same here
<janimo> marvin24, I have a not-too fast core duo, which builds in maybe 30 minutes
<marvin24> same here :-(
<ogra_> i use to do heavy builds in ramdisks though, that speeds up things a lot
<janimo> not sure if that qualifies as 'hell' for you though :)
<marvin24> with ccache it takes less than 2 minutes
<ogra_> without ccache it takes around 10 for me ...
<janimo> marvin24, I believe you. Not sure why I never looked at why ccache did not work
<marvin24> must have something to do with fakeroot
<xnox> ogra_: picking up AC100 tomorrow 112GBP (139 EUR)
<ogra_> hah, cool !
<marvin24> ogra_: did akon reached you regarding the library name problem?
<ogra_> marvin24, nope, i was one at 1:30 when he pinged me
<marvin24> (sorry I'm just catching up with the backlog because of short time holidays)
<ogra_> waiting for him to re-appear thugh
<ogra_> you took a long weekend ?
<ogra_> infinity, mind helping to explain the nvidia ld issue to srwarren (from nvidia) ?
<srwarren> infinity, could you detail the technical issues that the incorrect soname in the NVIDIA Tegra R16 libs?
<ogra_> i fear i'm not as accurate as you can be :)
<srwarren> I know the names are wrong and what needs to be changed; I'm just trying to understand the exact implication of the current incorrect names
<ogra_> it boils down to "that it currently works if you put the libs into /usr/lib is sheer luck)
<marvin24> ogra_: yep, I measured the circumference of the Edersee
<ogra_> if you put the libs into any different path thatrs not hardcoded in ld only ld.so.cache will be used ... in which we have the wrong SONAME
<srwarren> For ldconfig, I think what will happen is that if libfoo.so's soname is libfoo.so, presumably ldconfig would simply not create any symlink since the file is already present under the expected name and move on
<infinity> srwarren: The libraries end up being uncacheable by ldconfig because the filenames and SONAMEs can't match.
<ogra_> if they live in /lib or /usr/lib ld falls back to walk the path and actually look at the links too
<infinity> srwarren: This is a problem given that ld.so uses the cache to find libraries.
<marvin24> janimo: kernel without CONFIG_TEGRA_AVP_KERNEL_ON_MMU crashed hard on video decode here
<infinity> srwarren: And yes, if things are in the "built-in" paths, then they get found the slow (cache-missed) way.
<infinity> srwarren: So, the best way to look at it is that it's a performance hit.  The worst way to look at it is that all the SONAMEs are wrong, and that's just plain, well, wrong. ;)
<marvin24> janimo: it is also enabled in tegra_defconfig and I want to stay as close as possible to downstream
<srwarren> With the current sonames, don't the filenames and sonames always match? Oh, I guess you're renaming the files in the Ubuntu package so that apps with DT_NEEDED=libfoo.so.1 can actually find the library?
<infinity> srwarren: Yeah, everything with a NEEDED it looking for the correct SONAME, which isn't in the library.
<infinity> srwarren: So, we get a cache miss, then start walking the filesystem.
<ogra_> srwarren, no, we put the libs into /usr/lib/nvidia-tegra and the SONAMEs end up in the cache ...  i.e. libEGL.so ... GLES apps are built to look for libEGL.so.1
<infinity> srwarren: It's not about us renaming them.  It's about the fact that they need to exist by those names. :P
<srwarren> OK, so the entries in /etc/ld.so.conf.d (or whatever the file is) only get used to build the cache, and not as part of the fallback searching
<ogra_> right
<infinity> srwarren: Right, because parsing a conf.d directory when loading every single binary on your system would be, well, dumb.
<ogra_> srwarren, but even if that wouldnt be an issue ... the first GLES app you would build on a system with the drivers installed would have completely broken linking
<srwarren> right, that's the part I already understood
<infinity> srwarren: Anyhow, I'm trying to decide which bit you're asking me to explain.  If you want to know why the SONAMEs are wrong, or why attempts to work around it suck?
<ogra_> afaik for libEGL.so as well as for libGLESv2.so the sonames are actually standadized
<ogra_> rsalveti, might know :)
<srwarren> I know exactly why the SONAMEs are wrong; I was trying to understand what practical impact that had. I'd only deduced the application-compilation issue so far, not the searching issue
<infinity> Ahh, yes.
<infinity> So, yeah.  If we ship everything in /usr/lib, is kinda works due to the cache-miss->directory-walk thing.
<srwarren> infinity, so when the files aren't found in the cache, and ld.so falls back to searching e.g. /usr/lib, how does it find the files even then, if they still have the wrong soname and filename?
<janimo> marvin24, I agree with staying close to defconfig downstream. Just that I not always sync up with defconfig in the package, at least some bits are not needed or incorrect in ubuntu (lzo) so I tend to drop more
<ogra_> srwarren, it doesnt :)
<infinity> srwarren: Because we symlink the correct SONAME to them.
<infinity> srwarren: And then it find them by filename.
<srwarren> ok, that makes sense - there's a workaround to make it work
<infinity> ogra_: Don't ask me to explain things and then jump in with contradictory statements. ;)
<ogra_> oh, i misread
<ogra_> lol, sorry
<ogra_> didnt mean to, i just read something completely different
<infinity> srwarren: Yes, our workaround for now is to symlink stuff from /usr/lib (or something else on the path)
<ogra_> but thats nothing we can do in a package
<infinity> srwarren: But that's still pretty wildly less than ideal, if you guys can actually fix the SONAMEs.
<infinity> ogra_: Well, we *can*... We really shouldn't.
<ogra_> yes
<infinity> (And I probably won't accept it in the archive...)
<infinity> But, y'know.  You can upload it.
<marvin24> janimo: that's fine, but you can check my paz00_defconfig against the latest you used for the last package
<srwarren> I guess this is because the multi-driver co-existence stuff is based on putting entries into the ld.so cache-building path list, rather than using the alternatives system on the .so filenames themselves
<marvin24> janimo: that should be a pretty short diff
<infinity> srwarren: Using alternatives on .so doesn't make much sense, since we don't install .so files except with -dev packages...
<srwarren> Well, *.so.1
<stuw> marvin24, janimo - https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/1059866
<ubot2> Launchpad bug 1059866 in linux-ac100 "video hw acceleration still dont work" [Undecided,Confirmed]
<infinity> srwarren: And yeah, we use alternatives on the ld.so.conf instead of on the files.  Correct.
<infinity> srwarren: Which is actually much more manageable.  If all the libraries work. ;)
<srwarren> yes, I can see that scales a lot better with multiple libs
<infinity> Just a lot less error-prone, really.
<infinity> Adding and removing alternatives and slaves for a ton of stuff makes people go cross-eyes, no matter how awesome the syntax-hilighting.
<infinity> s/cross-eyes/cross-eyed/
<bizulk> ppisati: hi. I saw my bug update. As soon as possible I take a look at this
<janimo> marvin24, stuw ok I'll have a look. It's just that yesterday's suggestion was a one line diff as well but was not enough
<janimo> it's just that I do not use the ac100 and have testcases to check various features so I will mostly blindly do whatever I am asked by others who actually use the machine :)
<janimo> ideally those people would take care of kernel packaging too but I am asking too much (hint hint)
<janimo> ;)
<ogra_> janimo, well, it was discussed on and off in #ac100 what options need to be on :) you could have fished it out of your backlog
<stuw> janimo, http://paste.ubuntu.com/1256243/ - .config after make ARCH=arm paz00_defconfig
<janimo> ogra_, I haven't logged in ac100 in many months, also as a cosequence of it mostly being low signal to noise for what I was interested in back then
<ogra_> well, that changed
<ogra_> there is still a lot of noise but currently thats all ac100 noise
<marvin24> ogra_: not noice, hifi sound!
<marvin24> *noise
<ogra_> oh, yeah, compared to the last 6 months this current hype is hifi
<infinity> Hahaha.
 * marvin24 still wonders why people are still interested in 2 years old machines
<infinity> Likely due to the lack of decent ARM netbooks.
<ogra_> yeah
<infinity> I just want a reasonably speedy one with a non-Android en_US keyboard.  Some day...
<ogra_> you can still buy it and its still cheap
<lilstevie> I like my transformer for that reason, running ubuntu it makes a nice ARM netbook
<ogra_> and with the 1280x720 display and the internal UDB disk its now gotten really uasble
<ogra_> *USB
<infinity> lilstevie: Yeah, but the transformer keyboard makes me die a little inside.
<ogra_> oh yeah
<ogra_> not just a little
<lilstevie> infinity, why?
<infinity> lilstevie: Well, (a) Android layout, and (b) it's just not a nice keyboard to type on.
 * ogra_ also doesnt like the shape ... since i have my zatab i use that more than my transformer 
<ogra_> less sharp corners on the case etc
<ogra_> even though the zatab is classes slower
<lilstevie> infinity, old style or new though, android layout is a pity, but I don't really look at the keys, and I have altered the keymap
<ogra_> (these A10's are really not made for multitasking)
<lilstevie> typing though I find it a bit better than my macs bt keyboard
<lilstevie> the tf101 keyboard was nowhere near as nice though
 * ogra_ really likes the ac100 kbd
<ogra_> the low resolution bothered me for actual work, but i fixed that :)
<lilstevie> I wish the tf201 was a bit higher resolution
<lilstevie> 1280*800 is nice, but it could be better
<ppisati> bizulk: fix was committed, when the next kernel is but i'll be in
 * ogra_ is happy with 1280x720
<infinity> I'd probably pay the Thinkpad brand premium for an ARM netbook with a Lenovo keyboard.
<ppisati> bizulk: *kernel is cut
<bizulk> ppisati: sorry you mean "next kernel is built I keep you informed" ?
<lilstevie> infinity, I wonder whatever happened to that Lenovo transformer like T3 tablet
<ppisati> bizulk: no, it means next Precise kernel upload will contain the fix
<bizulk> ppisati: How can I know when it's done ?
<ppisati> bizulk: sudo apt-get update upgrade
<bizulk> opps sorry
<bizulk> with update-alternative cmd I can select the kernel release I want (including the unofficial one) ?
<infinity> kernels don't use alternatives, no.
<ogra_> janimo, do you actually look over the linux-ac100 buglist sometimes ?
<ogra_> bug 961302 seems valuable if you dont want to upload for a single config change :)
<ubot2> Launchpad bug 961302 in linux-ac100 "[AC100] Request HID Waltop kernel module for Waltop tablet" [Undecided,New] https://launchpad.net/bugs/961302
<janimo> ogra_, no I did not look at the buglist recently
<janimo> I'll look into them
<janimo> I added some more modules in a recent upload but still far from what stock ubuntu kernel has
<janimo> ogra_, git has a bright future
<janimo> just sayin ;)
<marvin24> janimo: I fixed the fuse cannot be loaded bug
<marvin24> https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/1060050
<ubot2> Launchpad bug 1060050 in linux-ac100 "Can't mount ntfs volume" [Undecided,New]
<marvin24> you may pull my tree again
<ogra_> \o/
<janimo> marvin24, ok
<ogra_> such a wondeful bug
<ogra_> really deserves a printout and a frame :)
<ogra_> (not the LP bug, the code issue indeed)
<marvin24> in fact, renaming arch/arm/mach-tegra/fuse.c fixed it
<ogra_> haha
<marvin24> if a kernel parameter is created
<marvin24> a file in /sys/module/<filename>/parameters/... is created
<marvin24> where filename is "fuse" in this case
<marvin24> so the filesystem fuse driver cannot register anymore, because the sysfs entry is used already
<marvin24> took some time to find this ...
<ogra_> yeah, great catch
<atc3030> could someone aid me in porting ubuntu to the tf700
<VarmVaffel> anyone used linux target image builder here?
<VarmVaffel> or LTIB as it's called
<VarmVaffel> I'm wondering how I can set the --build parameter there
<VarmVaffel> or mach type
<VarmVaffel> on the make
 * ogra_ never heard of it
<VarmVaffel> Freescale uses it for their CPUs
#ubuntu-arm 2012-10-03
<lilstevie> so what was the result of the whole discussion with srwarren? are the r16 libs getting fixed?
<marvin24> lilstevie: it will be fixed, but maybe not in time
<bizulk> just a question about makefile : I export a CFLAGS variable for a target that configure gstreamer. The configure step is passes but when compiling I get a bunch of errors. What I found is that at the compile step the CFLAGS have been passed with the "..." so that compiler (libtool) that this as a file. When I call the configure the same way in the shell everything is ok. So how do we avoid such export error in makefile ?
<bizulk> infinity: but kernel installation are not overriden, right ? So after updating the new kernel will be selected. If I want to fallback I'll just have to update the symlink to uImage (BB xM)
<dmart> bizulk: for your makefile question, do you have a log you can share?
<bizulk> dmart: Yes give 2 minutes to make a pastbin
<lilstevie> marvin24, hm ok
<lilstevie> marvin24, is there a package that works with precise though?
<bizulk> dmart: http://pastebin.com/GS5W1sCZ
<bizulk> dmart: I tried $() ${} , always getting error at compile time
<dmart> bizulk: Hmmm, I'm not sure exactly why that ends up quoted
<dmart> bizulk: What happens if you put the flags in the environment instead of on the configure command line
<dmart> bizulk: i.e.
<bizulk> well I'll try it now
<dmart> bizulk: hang on, forget that for a moment -- do you have the Makefile?  I'm wondering whether it adds inappropriate quoting to the make variables corresponding to GSTREAMER_CFLAGS and GSTREAMER_LDFLAGS
<bizulk> well it does not work
<bizulk> You mean the gstreamer Makefile ?
<dmart> bizulk: yes... or were the lines at the top of your log part of the Makefile?  I had assumed they were shell commands issues before typing make
<bizulk> I'll post the whole makefile
<bizulk> http://pastebin.com/KaKeasVU
<bizulk> maybe I am messing the configure step with my GLIB custom makefile. I trying to make a diff
<dmart> bizulk: Normally people do not put quotes directly in Makefile variable assignments, because Make doesn't need them and they become part of the variable
<bizulk> dmart: you mean when I export ? I thought I needed them because of space
<ogra_> lilstevie, i think i'll upload a package with the broken libs, the direver works fine without them and we can then SRU the fixed libs
<dmart> bizulk: Make generally doesn't use quotes at all
<bizulk> dmart: you're right I've just been inspecting the gstreamer generated Makefile
<dmart> bizulk: but rule commands may need them because those are executed by the shell
<dmart> Maybe something like this:
<dmart> http://pastebin.ubuntu.com/1257570/
<lilstevie> ogra_, ok cool, I do find I care more about the driver than the libs anyway
<ogra_> yeah, not many gles apps around yet and unity is broken with the nvidia driver anyway
<bizulk> dmart: right. I got it working now but I don't know why. So I'll use your models
<lilstevie> ogra_, even with r16?
<ogra_> infinity, would you let the tegar package in even with broken libs (to make SRUing the fix easier) ?
<ogra_> lilstevie, apparently, though the reports i had were from precise ... with luck quantal unity works better (though i doubt it)
<lilstevie> shame
<bizulk> dmart: ok it seems to be compiling. Variable assignement rule is using the whole line after ' = ' and not quote then.
<ogra_> the patches should be largely the same in both, just that they are upstream in quantal
<dmart> yes
<lilstevie> you would have thought they would have fixed it though, seeing as their test env is now a 12.04 armhf image
<ogra_> which still falls back to unity2d
<ogra_> when i asked them last they were convinced unity works ... turned out in the end that they looked at 2d :)
<lilstevie> yeah, but it doesn't fall back with the tegra driver (although it might with broken libs)
<ogra_> yeah. not anymore
<lilstevie> hm
<bizulk> dmart: Thanks for help
<lilstevie> I'm not quite satisfied with our r16 kernel anyway
<dmart> bizulk: no problem
<ogra_> janimo, !
<ogra_> janimo, could it be that you changed the config wrt usb-storage in the last kernel ?
<ogra_> people arent finding the USB key during install anymore
<janimo> ogra_, you mean the very  last kernel which was supposed to be the NVAVP change?
<ogra_> janimo, dunno, is that in already (meta ?) whartever is on todays image doesnt find a /dev/sda1 anymore in the installer initrd
<ogra_> USB plug events are seen
<ogra_> that smells like usb-storage moved from =y to =m
<ogra_> (the initrd is built without any modules due to size issues if you remember)
<janimo> sure. I do not remember touching usb-storage though
<janimo> I'll check
<ogra_> yeah, might be marvin24 changed it
<ogra_> that would break everyone who runs rootfs on USB though
<janimo> I do not use defconfig so not sure how marvi could have affected this though
<ogra_> ah, k
<janimo> but yes, thatwas it. storage is modular :(
<ogra_> heh
<janimo> part of the first r16 kernel upload
<janimo> where I actually did merge with defconfig
<janimo> I hate this crap (kernel packaging)
<ogra_> funny, i thought that made it onto beta2
<ogra_> you wanted it :)
<janimo> I was young and stupid
<ogra_> i wuld have kept it (and maintained it in tarballs) ... now its in git .... else i'd take it back :P
<janimo> I think it is better for it to be in git, as it is - in theory at least - easier to team-maintain
<janimo> right now the lack of interest not of git is the blocker
<janimo> ogra_, but really git is winning , sooner or later you will have to use it
<janimo> so why not now ;)
<ogra_> enough other stuff on my plate :)
<ogra_> i'm happy if i can git pull, the rest i stay away from
<marvin24> janimo, ogra_, sorry folks that I broke it
<janimo> well it has an annoying hurdle at the beginning of the learning curve, but it pays off later
<janimo> marvin24, np, this is error-prone and boring  stuff
<marvin24> pc distros prefer all modules
<marvin24> and load them in the initrd stage
<marvin24> I wonder why this doesn't work on ARM
<ogra_> it does
<ogra_> just fine
<janimo> it's not ARM but our ac100 initrd
<ogra_> its just that there are no modules to load
<ogra_> since we dont include any in the initrd on ac100
<ogra_> else it would get to big
<suihkulokki> people are just too lazy in ARM world to do things in the generic way and just take vendor trees and build everything in the kernel
<ogra_> suihkulokki, its not that :)
<suihkulokki> it is :P
<ogra_> its a constraing of the dveices bootloader we have to obey to
<suihkulokki> but it is changing with the unified kernels and device trees etc
<ogra_> your initrd cant be bigger than 2.5M or so
<ogra_> or even 2M ... i dont remember the exact value
<ogra_> if i want to use a standard ubuntu initrd i have to cut down size massively due to setting other defaults for initramfs-tools
<ogra_> ogra@panda:~$ ls -lh /boot/initrd.img-*
<ogra_> -rw-r--r-- 1 root root 4.6M Sep 26 17:37 /boot/initrd.img-3.5.0-211-omap4
<ogra_> ogra@panda:~$
<ogra_> that would be the normal size
<ogra_> no way to fit that into the ac100
<ogra_> s7due to/through/
<ogra_> janimo, oh, you are not in #arm anymore on the other server :(
<janimo> ogra_, oh that's because that channel used to say 'closing. move along' or similar half a year ago
<janimo> and it was inactive
<janimo> did I miss something lately?
<ogra_> well, the channel has still 35 residents :)
<janimo> ogra_, but are they alive?
<ogra_> and we occasionally talk there
<ogra_> rarely :)
<ogra_> i just didnt want to talk in #canonical ... and you arent in#distro either
<janimo> ogra_, well, I thought those too were kind of quiet
<marvin24> janimo: it seems you were right a few weeks ago ...
<marvin24> there is significant work towards multi arch kernel on arm
<marvin24> or better multi cpu
<marvin24> I wonder how they will solve the errata problem
<ogra_> devicetree needs to learn about them
<janimo> marvin24, tegra in 3.7 seems quite nice (from a codebase point of view, not sure how it actually works)
<janimo> ogra_, but still checking for them incurs runtime overhead even for unaffected hw
<marvin24> yes, seems tegra is the first platform to kill board files
<janimo> unless some live patching is done at bootup, which may not be that hard on ARM as it is on x86. No idea
<ogra_> janimo, you dont check for anything thats not in your DT database for the HW you run on
<ogra_> thats the purpose of DT
<janimo> ogra_, I mean errata code is inside #ifdef
<janimo> and not built unless selected for the particular target in config
<ogra_> that needs changing indeed
<janimo> so if you want to support all boards you make the checks at runtime
<janimo> so some overhwead
<ogra_> which would be a part of "devicetree needs to learn about them"
<janimo> or decree you go one stepo further and ARM kernels will not only not accept machines that are not DTbaserd, but not accept machines that have hardware bugs
<janimo> would make arm kernel maintenance so much easier
<bizulk> I am compiling glibc against arm2009q1 (code sourcery), and gstreamer, for BB xM. But when calling for gst-inspect I have this error : "/lib/libglib-2.0.so.0: /lib/libc.so.6: version `GLIBC_2.9' not found (required by /lib/libglib-2.0.so.0)". I can't understand as I did install the libc from the toolchain dir.
<bizulk> How can glib ask for a glibc version later than the one it has been compiled with (what a headache !)
<ogra_> ugh, why do you use such an outdated toolchain
<bizulk> I was using the last one but because I could have tidspbridge support (still not sure about the reason) I fallback to the one my colleagues are actually using
<bizulk> Actually the glib version is "glib-2.24.1"
<bizulk> why did I choose this one ? Maybe because I wanted to use same gstreamer version as the gst-dsp project and that it is compiled with this version og glib
<bizulk> I'll cry if I have to recompile the whole stuff (BSP and userspace) with another toolchain
<ogra_> bizulk, you recompiled ubuntu ?
<ogra_> note that the whole ubuntu userspace is compiled with gcc 4.7
<ogra_> i_m not even sure that old toolchain you use has proper armhf support
<bizulk> no that standalone stuff (I have to) , I am using ubuntu as "witness test". I'm wondering If I can generate minimal FS with ubuntu
<ogra_> use debootstrap
<ogra_> or qemu-debootstrap for cross building a chroot/rootfs
<ogra_> (note that this will be compelertly unconfigured though)
<TerrorCon> can anyone help me with Qt's audio classes under ubuntu for pandaboard
<bizulk> ogra_: I'll take an eye one it. infortunately I have to be base on the one I receive and populate it with the builds I make
<bizulk> ok I recompile with a more recent kernel arm-2012.03-57-lite
<ogra_> s/kernel/compiler/ ?
<bizulk> I hope one day we'll adopt OE/Ubuntu u
<bizulk> compiler
<ogra_> urgs
<ogra_> thats like saying for the desktop you want a merge of gentoo and ubuntu
<ogra_> ubuntu isnt an embedded OS ... dont use it as one
<bizulk> so why port on a omap ?
<ogra_> we needed to start somewhere
<ogra_> ompa support is a legacy we only carry on because we get it for free from te mainline kernel
<ogra_> *omap
<ogra_> focus in on cortex-a9 and beyond
<ogra_> which are systems that are capable of running a general purpose desktop distro
<ogra_> bug 1028905
<ubot2> Launchpad bug 1028905 in debian-installer-utils "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Fix released] https://launchpad.net/bugs/1028905
<ogra_> janimo, did you include the fuse fix as well in your ac100 upload (changelog doesnt talk about it )
<janimo> ogra_, I rebased on marvin's branch so it should be there
<ogra_> good
<janimo> I have a LP buglink which should point to that
<ogra_> just wanted to make sure
<janimo> but indeed, forgot to mention it otherwise
<janimo> I am not sure of anything now, so let's see who yells when it builds :)
<ogra_> hopefully thats the last upload :)
<ogra_> yeah
<ogra_> theoretically it should be good now
<infinity> Can I just yell for the sake of yelling?
 * ogra_ plugs his ears 
<janimo> infinity, always
<ogra_> GO ON !
<ogra_> :)
<infinity> Well, that's no fun.
<infinity> dannf: Around?
<dannf> infinity: yeah
<infinity> dannf: Can you re-do your qemu-linaro SRU with the patch headers actually being sane? :P
<infinity> dannf: They include ufilled boilerplate, a reference to an unrelated bug, etc.
 * dannf looks
<infinity> dannf: Err, oh, I see the problem.  There's a debian-changes patch in there.
<infinity> dannf: So, yeah.  Fix that, please. :P
<infinity> dannf: That debian-changes patch looks like maybe a mistake while fiddling?  Can't see why you'd want to remove the stdint.h include.
<infinity> dannf: http://launchpadlibrarian.net/117670218/qemu-linaro_1.0.50-2012.03-0ubuntu2_1.0.50-2012.03-0ubuntu2.1.diff.gz
<infinity> dannf: (Always pays to debdiff and cruft-check before upload)
<ogra_> debdiff ++
<infinity> dannf: Rejecting that one, give me something gooder.
<dannf> infinity: ok - i don't see those changes in my branch.. did i post this debdiff?
<infinity> dannf: That's the diff generated in the queue from the package you uploaded...
<dannf> i didn't upload a package
<infinity> Oh.  Did someone else sponsor that?
<dannf> except to my ppa (i don't have ubuntu upload rights)
<dannf> here's my changes: https://code.launchpad.net/~dannf/qemu-linaro/highbank
 * dannf remembers hallyn poking me last week while i was travelling about qemu-linaro - i'd forgotten about that & never got back to him
<infinity> dannf: Check, I'm chastising the wrong person.  I didn't check the signature to see who sponsored it. :P
<dannf> infinity: np - thanks for working on this
<infinity> Looks like it was mvo who broke it.  That's surprising.
<infinity> I so wanted it to be you.
<infinity> *sniff*
<infinity> I'll re-do this and upload.
<dannf> heh - sometimes i wonder if i should try and get upload rights.. then i remember the blame that comes w/ privilege :)
<infinity> Oh, curious, mvo's debian-changes patch unapplied Colin's FTBFS fix.
<infinity> Weird.
<infinity> Aaaanyhow.  Reuploading a less broken version.
<infinity> dannf: Alright, fixed version uploaded, double-checked that the diffs are now clean, and accepted into -proposed.
<dannf> yay!
 * xnox is playing with ac100 android install before reinstalling it with ubuntu
 * xnox ac100 no tarball found hm =/
<GrueMaster> xnox: Why would you reinstall that piece of vile vomit back on the AC100?  It isn't even true Android, but a hackified version (similar to the nook, only not as nice).
<fly-away> lolwhat
<GrueMaster> fly-away: The Toshiba AC100 came preloaded with a heavily modified version of Android (2.3 iirc).  Very ugly and not as easy to use as true Android.
<GrueMaster> The system could have been very good if it had more memory and a real OS out of the box.
<fly-away> that preinstalled Android pretty close to original
<fly-away> one annoying thing - android is for touchscreens now
<fly-away> keyboard really unusable
<GrueMaster> It felt a lot different than the android I worked with on other systems.  At any rate, there was a lot missing from that system, both hardware and software.
<prpplague> well that version of android is pretty old and had "hacks" for keyboard/mouse support
<GrueMaster> true.
<fly-away> in that android video plays with subtitles very smoothly
<fly-away> if you remember)
#ubuntu-arm 2012-10-04
<bizulk> Hello World !
<bizulk> Question about gstreamer : when gst-inspect return that some plugins are blacklisted, it means that they won't be loaded with playbin, right ?
<ogra_> xnox, there was a usb bug in the ac100 kernel, either try again once thats in, install from an SD card or go with the beta and upgrade
<xnox> ogra_: hmm.... i am running quantal.
<ogra_> yes, i was referring to quantal
<xnox> ogra_: what was my question? I lost context....
<ogra_> * xnox is playing with ac100 android install before reinstalling it with ubuntu
<ogra_> * xnox ac100 no tarball found hm =/
<ogra_> i was referring to the last one
<xnox> ogra_: ah. I did manage to install with sdcard =)
<ogra_> ah, great
<ogra_> well, usb should work too now
<xnox> ogra_: i was like, what the heck let's try the sdcard. Cause i was suspecting that my usb thumb drive was "tempremental"
<ogra_> heh
<xnox> ogra_: media keyboard buttons. Do they work?
<ogra_> dont blame it ... the kernel was missing usb-storage
<ogra_> no, they are F-keys
<ogra_> you can re-assign some of them, i.e. i use the volume and mute keys remapped
<xnox> =(
<ogra_> the touchpad toggle key (F9) is sadly hardwired to touchpap power
<xnox> ogra_:  what about bug 1061430 ?
<ubot2> Launchpad bug 1061430 in libmtp "[ac100] libmtp-runtime is not pre-installed" [Medium,New] https://launchpad.net/bugs/1061430
<ogra_> if your touchpad doesnt work once, first try with that key :)
<ogra_> oh, yeah i noticed the noise on boot
<ogra_> ac100 doesnt differ from other images (same seeds, no arch specific bits)
<ogra_> so i really wonder why its not showing on other systems
<ogra_> This package provides the udev rules file and the FreeDesktop.org Device
<ogra_>  Information Files file (used by HAL).
<ogra_> hal ... hmm
<xnox> ogra_: I disagree with you.
<xnox> ogra_: http://paste.ubuntu.com/1259609/
<xnox> ogra_: notice how runtime is seeded everywhere where common is, but in the pre-installed case.
<ogra_> heck, why is it seeded at such a high level ?
<ogra_> thats like seeding alsa-libs in desktop
<xnox> ogra_: i suspect it's not hal specific anymore. it's the thing that should tell what is an iPod / iPad / photo camera / video camera / mp3 player / etc.
<ogra_> yeah
 * xnox made lubuntu look ~ unity-like
<ogra_> that should at least be in desktop-common
<ogra_> ogra@anubis:~/Devel/seeds/ubuntu.quantal$ grep -r mtp *
<ogra_> ogra@anubis:~/Devel/seeds/ubuntu.quantal$
 * ogra_ scratches head
<ogra_> not in platform either
<xnox> ogra_: due to reverse-recommends from libmtp9 runtime is installed because of: amarok, rhythbox-plugins, banshee or audacious-plugins (all default music players?!)
<ogra_> ah
<ogra_> i dont see any of them in the binary rdepends
<xnox> ogra_: so check the diff between lubuntu daily-live and daily-preinstalled manifests?
<xnox> ogra_: reverse-depends libmtp-runtime -> libmtp9 (reverse-recommends) -> music players (reverse depends)
 * ogra_ doesnt even know where the lubuntu seeds live :)
<ogra_> ah. recommends
<xnox> ogra_: well. diff the manifests on cdimage.u.c =)))) and it should be in the ubuntu-seeds project as  a branch?!
<ogra_> lubuntu ships gmplayer or gnome-mplayer
<ogra_> yeah, something like that
<xnox> ogra_: then why did it get libmtp-common?
<ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$ apt-cache show libmtp-common|grep lubuntu|wc -l
<ogra_> 2
<ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$ apt-cache show libmtp-runtime|grep lubuntu|wc -l
<ogra_> 0
<ogra_> ogra@anubis:~/Devel/seeds/platform.quantal$
<ogra_> seems something explicitly seeds it
<ogra_>   * Move all recommends to depends, to be consistent with the
<ogra_>     no-follow-recommends feature of the seed.
<ogra_> hmm, intresting changelog entry in lubuntu-meta
<ogra_> i suspect that might explain it
<ogra_> ok, got it
<ogra_> lubuntu seeds audacious ... that depends on libmtp9 .... which doesnt depend on its own runtime buut only libmtp-common
<ogra_> so its a dependency error in libmtp9
<ogra_> xnox, fixed lubuntu-desktop uploaded :)
<xnox> ogra_: cool.
<xnox> ogra_: seeded-in-ubuntu transmission looks odd. why depend on a metapackage instead of selecting gtk frontend like the rest of seeds.....?
<janimo`> hrw, hi, is there any catch in using ccache with the cross gcc for building kernels
<janimo`> hrw, nevermind, found it :)
<janimo`> marvin24, CROSS_COMPILE="ccache arm-linux-gnueabihf-" passed in the make or debuild line
<janimo`> maybe the kernel build system ignores the PATH somehow
<janimo`> since for a simple Makefile in another project arm gcc works via ccache if the symlinks are set
<marvin24> janimo`: ok, thanks - will try out
<bizulk> just in case my story does interest somebody : I did pass the configure step with --disable-modular-tests option
<marvin24> janimo`: yup, that worked - easy enough
<marvin24> thanks!
<janimo`> marvin24, yes, quite faster here as well :)
<janimo`> thanks for reminding me that ccache does not work, I somehow kept ignoring it and sufferint longer build times than needed
<marvin24> janimo`: I guess that won't balance the time I stole you already ;-)
<janimo`> marvin24, nah, the time it took was not longer than the delta between a regular and a ccached build so it is already gained back :)
<janimo`> unless you mean ALL THE TIME YOU STOLE by starting the ac100 kernel and all it lead to ;)
<marvin24> ^^^ yes, that's what I meant
<hrw> guys: when #ubuntu-arm64? :D
<infinity> hrw: Won't be a new channel, but I'm sure more arm64 talk will happen here soonish.
<ogra_> hrw, as soon as we have #ubuntu-amd64
<hrw> so far I crosscompiled only 634 packages
<hrw> but with OE
<infinity> hrw: Which libc are you using?  Our 2.15+libc-alpha patches, or master+alpha?
<hrw> infinity: 2.16+svn+aarch64-public
<hrw> its 2.16+svn20393 iirc in last build
<infinity> So, vaguely master+libc-alpha.
<hrw> yes
 * infinity needs to spend some time in the next week or two to dump something vaguely workable into Debian/experimental and prep for R.
<infinity> Not that R will be building arm64, due to lack of anything to use as a buildd, but I want R to be able to cross-build it without pain.
<hrw> infinity: wookey works on it already too
<infinity> wookey: We should talk. ;)
<ogra_> why oh why that arch name
<infinity> ogra_: Which one?  arm64 or aarch64?
<ogra_> arm64 and amd64 are way to close for my taste
<infinity> Heh.
<infinity> Get less dyslexic. ;)
<ogra_> aargh64 at least allows a funny typo :)
<xnox> arrrr64 whould be awesome though
<ogra_> pirates !
<xnox> aka *our arch does not exist*
<hrw> bye
<wookey> ogra_: it's true that amd64 and arm64 are easy to confuse - I've been doing that quite a lot already
<wookey> infinity: talk away
<infinity> wookey: Oh just about glibc and how your cross-building adventures are going.  Perhaps I should have suffixed "we should talk" with "soon", or maybe even a date.
<infinity> wookey: How's your tomorrow look?
<wookey> tomorrow I foresee more fighting with eglibc2.16 and toolchain bootstrap :-)
<wookey> so yes, anytime
<wookey> tomorrow evg I'm out. But presumably you are thinking of my morning, your evg?
<infinity> wookey: I was thinking my morning, your afternoon, but well before your evening.
<wookey> no probs. I was miffed today to find tha the bug you get from trying to build eglibc2.15 with gcc4.7 gives zero google hits
<wookey> So moving to 2.16 seems like likely path of least resistance (and matches aarch64 patches much better too)
<infinity> wookey: Bring that up with me tomorrow too. ;)
<infinity> wookey: Well, we're moving to 2.16 for Ubuntu-R and Debian/experimental, I just need to get to it.
<infinity> wookey: If the current libc-alpha aarch64 patches apply cleanly to 2.16, I may not need much input from you, but I just want to pick your brain about your experiences so far.
<wookey> OK. aurel told me the packaging was done, so I'm just assembling all the right parts to see if it builds
<infinity> wookey: Yeah, aurel's done a lot of the heavy lifting already, I need to do a bit more though.
<wookey> I'll have a patch for that within the hour I think
<infinity> wookey: Oh, spiffy.  In that case, you can provide me with useful patches tomorrow. :)
<wookey> no idea if it'll actually work...
<infinity> wookey: And I'll get it all committed and we can work from there.
<wookey> it's a bit wierd the way the debian packaging doesn;t match upstream layout
<wookey> But I think I have groked what goes where
<infinity> Hysterical raisins.
<wookey> so I gathered
<infinity> Going back to when it was three different upstream branches that had to be merged.
<infinity> I'll mangle all of that when I move Debian to git.
<infinity> But that won't happen until we're also ready to move Debian back to glibc.
<wookey> I was confused for a while though...
<infinity> Heh.
<infinity> It's not ideal.
<infinity> We'll fix it in the next 6-12mo, I hope.
<infinity> As soon as we verify that glibc has all the eglibc patches we care about (or most of them), and switch back.
<infinity> Some serious round tuits required for that audit.
<[7]> hey
<[7]> I've just tried to install quantal on my pandaboard (omap 4430)
<[7]> sd card works well with oneiric/precise
<[7]> however with the xloader from http://ports.ubuntu.com/ubuntu-ports/dists/quantal/main/installer-armhf/current/images/omap4/netboot/MLO it freaks out with this:
<[7]> OMAP SD/MMC: 0\nmmc_send_cmd : timeout: No status update\nCard did not respond to voltage select!\nspl: mmc init failed: err - -17\n### ERROR ### Please RESET the board ###
<[7]> so... is that a broken MLO, or a weird card that somehow happened to work right with an older one
<[7]> if the former, where do I get a working MLO that works with quantal (12.10)?
<[7]> if the latter, what kind of trouble is to be expected if I just use an older MLO, e.g. from oneiric or precise?
<GrueMaster> Try one from Precise, just in case.  The MLO shouldn't have changed, afaik.
<infinity> It's been rebuilt, even if the code didn't change.  That said, it works in our pre-built images.
<infinity> (I'll admit I haven't built an SD by-hand with the one we publish, but it's identical to what's in the boot images sitting next to it)
<[7]> GrueMaster: precise is 33K in size, quantal is 26K
<[7]> swapping it results in this: http://pastie.org/4910961
<[7]> infinity: those boot images fail to boot on my board/card
<[7]> does this output mean that I might have to swap uboot as well? or did it actually fail to load uboot?
<[7]> (that output loops over and over again)
<infinity> [7]: Which "those images"?  boot.img-serial.gz?
<[7]> yes, that one
<infinity> Same voltage select error?
<infinity> It could be the card, unsure.
<[7]> haven't observed serial output of that, but it resulted in no LED activity as well
<infinity> As for the error when you swap around MLO, it may well be that MLO and u-boot need to match.
<GrueMaster> [7]: Just download either boot.img-fb or boot.img-serial and then "gunzip <boot.img.*|sudo dd of=/dev/mmcblk0 bs=4M"
<[7]> infinity: so you say a precise uboot is likely to work with quantal?
<GrueMaster> You don't need the other files unless you are manually creating a boot image.
<infinity> [7]: Should do.
<[7]> hm, now that card acts weird in my laptop as well: http://pastie.org/4910997
<[7]> hm, replugged it, works again
<infinity> This fits nicely with my "blame the card" mantra.
<[7]> ok, swapping uboot as well seemed to help
<[7]> booted a kernel at least
<[7]> "ALERT!  /dev/disk/by-uuid/root does not exist.  Dropping to a shell!"
<[7]> now why on earth does it look for a label in by-uuid?
<infinity> Booting a non-standard kernel?
<GrueMaster> what exactly are you trying to do?
<[7]> or rather why does the installer set up a root=uuid=<label> bootarg if I specify a partition label during installation
<GrueMaster> What does your boot.scr contain?
<[7]> "root=uuid=root"
<[7]> the interesting question is how that ended up in there
<GrueMaster> Back to my earlier question, what are you trying to do?  Netboot installation?
<[7]> GrueMaster: yes
<[7]> and it worked for the most part, only problems were that MLO/uboot thing, and that wrong root device
<GrueMaster> If you are doing a netboot install, just download the boot.img-fb or boot.img-serial and flash it to your SD card.  Don't worry about anything else.
 * GrueMaster wishes he could log into the home network from work to verify the images are indeed ok.
<[7]> GrueMaster: well, that didn't work with this card at least, which worked on oneiric just fine, for more than a year
<[7]> hm, now it froze :/
<[7]> no heartbeat anymore
<[7]> no console output either
<GrueMaster> Har!  Found a way into my home network.  Now testing the quatnal netboot install on my panda farm.
<GrueMaster> Seems to be working for me just fine.  Panda4 rebooted and is running my preseed install (which is a symlink to my Precise preseed - i.e. unchanged).
<GrueMaster> [7]: Just fyi:  I automated  SRU Kernel testing when I was doing Ubuntu ARM QA.  I am no longer doing that work, but my systems are still operational as is my local mirror.  Everyhting still appears to be working fine.
<[7]> so we apparently have an incompatibility between this sd card and newer uboots?
<GrueMaster> The automation process downloads the boot.img-serial.gz to the local panda and reflashes the SD.  It then reboots, and the preseed installes the designated release on a USB Sata drive.
<GrueMaster> As to your SD, I don't know.  Try seroing it out and reimaging it.  I've had to do that on occasion when I was doing daily testing.
<GrueMaster> *zeroing
<[7]> hm, maybe I'm gonna try another card with that boot image to see if that works
<[7]> but this card seems to be working just fine
<[7]> (after swapping out xloader and uboot)
<GrueMaster> Try reflashing the boot.img to the sd card.  You shouldn't have to do anything else.
<GrueMaster> Are you on a Panda or PandaES?
<[7]> the old (4430) one
<GrueMaster> Ok.  That is what I am testing on.  (not sure if my ES is still plugged in)
<[7]> and it did try that image on this card earlier, and it didn't work
<[7]> now that I've installed everything I'm not sure I'll wipe it again
<GrueMaster> heh
<infinity> Are you positive you tried the .gz images, and not the -fat?
<infinity> The latter is a red herring.  And we really need to stop publishing it.
<[7]> no, i tried the gz
<infinity> Kay.
<[7]> both dd'ed directly to the sd card (superfloppy) or as a properly sized partition
<infinity> Then I'm all for either blaming the card entirely, or doing a low-level zeroing of it before rewriting it.
<infinity> Err, what?
<GrueMaster> [7]: Did you gunzip before flashing it?
<[7]> sure
<infinity> The .gz contains a partition table, no superfloppiness about it.
<[7]> hm? lemme check again
<infinity> If what you have there doesn't have a partition table, it's not the right image.
<[7]> hm, indeed it does
 * [7] tries to remember what he did
<GrueMaster> The proper way to flash (well, what I use anyway) is "gunzip <boot.img-serial.gz|sudo dd bs=4M of=/dev/mmcblk0"
<infinity> I tend to just zcat as root, since the image is small enough that bumping the block size doesn't buy much.
<GrueMaster> You could also use /dev/sdb (or whatever your PC designates as the SD drive).
<infinity> But yeah, GrueMaster's command is best practice.
<[7]> anyway, I'm sure I dd'ed that onto the sd card
<GrueMaster> infinity: It isn't about size.  I discovered early on (Karmic timefram iirc) that using BS actually changes the write order a bit.
<[7]> and only tried partitioning when that didn't work
<GrueMaster> On some devices.
<GrueMaster> [7]: Yea, no need to partition.  The img is a disk image that contains a small fat partition preloaded with good stuff.
<[7]> hm, odd... anyway, I always checked that it was mountable
 * GrueMaster wishes he had ipv6 access to the home instead tunneling around through putty.
<GrueMaster> Hmm.  Fail.  infinity:  Did openjdk-6-jre-headless get removed this cycle?
<GrueMaster>  same with python-software-properties apparently.
<[7]> has someone seen aptitude crash like this before? Uncaught exception: ../../src/generic/problemresolver/choice.h:328: const version& generic_choice<PackageUniverse>::get_ver() const [with PackageUniverse = aptitude_universe; generic_choice<PackageUniverse>::version = aptitude_resolver_version]: Assertion "tp == install_version" failed.
<[7]> seems to happen when it tries to resolve dependencies of broken packages
<[7]> hm, apparently aptitude's pkgstates got corrupted during that crash
#ubuntu-arm 2012-10-05
<wookey> infinity: OK. I have an initial eglibc2.16 aarch64 support patch. What do you want me to do with it? File a bug and attach?
<infinity> GrueMaster: Replaced by openjdk-7-jre-headless and python3-software-properties, I'd assume.
<wookey> btw it still requires gcc-4.6 - is that right?
<wookey> that's a problem for aarch64 cross-build - as there is no such thing
<infinity> wookey: Hang on to it until we chat tomorrow? :)
<wookey> OK
<infinity> wookey: And we'll figure out how to make it work with 4.7, or die trying.
<wookey> heh
<GrueMaster> infinity: Thanks.  Guess I should fix my preseed.
<highvoltage> http://paritynews.com/software/item/394-linux-37-kernel-to-support-multiple-arm-platforms
<ogra_> infinity, i'm just uploading tegra and tegra3 drivers with the broken libs, please have a look (i added a changelog note about the libs and documented a manual workaround in the bug)
<stulluk> Hi
<stulluk> I have an ARM based hardware, with CPU ARM 926 EJS @216Mhz
<stulluk> Flash is 32Mbyte NOR
<stulluk> DRAM is 256Mbyte DDR2
<stulluk> Is it possible to use ubuntu arm on this platform?
<XavB> ogra_: rsalveti: ndec: I can see that trunk PPA is almost full: 2.7 GiB (89.99%) of 3.0 GiB. Is it possible to increase the size to prevent problems?
<ndec> oops...
<ogra_> iirc you can ask in #launchpad for that, yeah
<lilstevie> stulluk, no, the ARM-926 is ARMv5T from the small bit of googling I just did. support was dropped for that quite a while ago. you might have some luck with debian though
<XavB> ogra_: who shall I ask to  on #launchpad?
<ogra_> XavB, hmm, no idea, i would just assk into the room what it takes to raise the limit
<VarmVaffel> how do I go by making the linux kernel boot in a verbose mode?
<VarmVaffel> do I have to recompile it with some setting, or can I add some arguments to e.g. the bootloader?
<ogra_> put earlyprintk on the kernel cmdline and drop quiet
<VarmVaffel> I see, thanks
<VarmVaffel> Do I have to have the earlyprintk print to another UART, or can I point both the console and it to the same?
<ogra_> it will always print to the console you have set
<ogra_> if oyu have more than one console= option, the first one is for kernel, the second is for userspace
<VarmVaffel> ah right think I understand
<ogra_> if you have only one it will be used for both
<VarmVaffel> I was looking at some u-boot examples here and it specifiesa another uart every time
<VarmVaffel> a separate one from the console
<ogra_> if you have none, the default will be used (usually console=tty1)
<VarmVaffel> right ok
<VarmVaffel> bah it was already at max verbosity I think
<VarmVaffel> :[
<plars> ogra_: heya, around?
<ogra_> plars, yes, but in meetings for eth rest of the day (atrting in 5 min)
<ogra_> *starting
<ogra_> whats up ?
<plars> ogra_: just wanted to catch up on a couple of things I'm seeing on panda, ping me if you have one finish early and have a few minutes?
<ogra_> plars, shoot
<plars> ogra_: couple of minor but annoying oddities that I'm curious if they're specific to something I have, or if you see them too
<plars> ogra_: 1. on desktop image, when I first boot, sometimes the keyboard doesn't work unless I disconnect/reconnect
<plars> reconnect the keyboard thatis
<ogra_> hmm, havent had that here ... sounds like a race in udev
<ogra_> everything being on USB surely causes some high traffic
<plars> not sure if it's specific to this keyboard, I don't have another I can easily use at the moment but if it's something others are seeing, then maybe it's not just this keyboar
<ogra_> (disc, NIC, input devices)
<plars> yeah
<ogra_> i havent heard from others about this yet
<ogra_> file a bug though, i think its bugworthy
<plars> ogra_: suggestions on where it would go though? udev?
<ogra_> or kernel
<plars> ok
<ogra_> start with udev though
<plars> sounds good
<plars> 2. audio
<ogra_> ppisati is busy enough :)
<plars> I get popping noises sometimes on jack audio, but not over hdmi
<ogra_> hedphones should work OOTB
<plars> ogra_: right, that's the default
<ogra_> ah, hdmi works (i have no monitor with speakers)
<plars> I do :)
<ogra_> great
<plars> it doesn't work automatically, you have to switch it by hand
<ogra_> well, popping means that the amp isnt murted during power up/down
<ogra_> yeah, it would work if we had pulseaudio profiles
<ogra_> iirc we have support for them but nobody added any
<plars> ok, so that's pulseaudio related you think?
<ogra_> no
<ogra_> the popping is the driver
<ogra_> no auto switching to hdmi is pulse
<plars> ok
<ogra_> might probably make a good wishlist bug
<plars> yeah
<plars> ogra_: those were the main things at the moment, I saw that the usb keyboard issue on server installs was fixed, so I'll retry that today too and actually try to do the server on the console rather than over serial
<plars> thanks ogra_
<ogra_> plars, i'm not sure ppisati fixed it on panda, i know he looked into begale for the kbd stuff
<plars> ogra_: ok, all the more reason to check it today :)
<ogra_> :)
<ppisati> the usb problem was just panda related
<ogra_> ah
<ppisati> ATM omap3 is really screwed (at least on my hw)
<ogra_> i thought you looked into beagle
<ppisati> i'm looking into beagle now
<ogra_> ppisati, well, its unsupported anyway
<ppisati> ogra_: beagle?
<ogra_> yes
<ppisati> ah
<ogra_> we only carry it through because its "for free"
<ppisati> upstream + one patch and usb is quite ok
<ogra_> fixing bugs there is best effort
<ppisati> with our kernel, for some obscrure config screw, the usb hub is ENTIRELY dead
<ogra_> but not mandatory
<ogra_> wow
<ppisati> i;ve been bisecting the hell out of my BEEP for the last 3 days
<ppisati> still didn't found what's so different from our kernel and upstream
<plars> ogra_, ppisati: just hit a problem with pvr-omap when running dist-upgrade after installing todays -desktop image
<ogra_> tell me
<plars> waiting on the update to finish
<ppisati> plars: i'm not pvr-omap maintainer
<ogra_> and rsalveti is traveling
<ogra_> (and busy in other projects)
<plars> ppisati: it was the kernel update that was happening when I hit the dkms issue
<ogra_> oh, dkms
<plars> run-parts: executing /etc/kernel/header_postinst.d/dkms 3.5.0-17-omap /boot/vmlinuz-3.5.0-17-omap
<plars> Error! Bad return status for module build on kernel: 3.5.0-17-omap (armv7l)
<ogra_> hmpf
<ogra_> plars, i think there should be a dkms build log somewhere
<plars> ogra_: yes, looking at it now
<plars> looks like it was missing omap_priv.h?
<plars> Also there's an error...
<ogra_> so kernel header issue ....
<plars> #error "A preemptible Linux kernel is required when using workqueues"
<ogra_> hmm, priv was gone i thought
<ogra_> our kernel is preemt, no ?
<ogra_> *preempt
<plars> yes, it would seem to be
<ogra_> weird
<ogra_> dkms is such black magic
<plars> just checked that CONFIG_PREEMPT=y in config
<plars> snap, I forgot to sacrifice the chicken and pour the blood on my laptop before compiling
<plars> :)
<ogra_> heh
<GrueMaster> Sigh, plars, how many times must I show you how to incite the satanic rituals of dkms installs?  :P
<GrueMaster> iirc, the chicken is used to dust off the monitor (wax on, wax off), while dancing to Gangnam Style.
<ogra_> nekkid
<GrueMaster> With two strips of bacon on each shoulder.
 * plars makes a note to never accept a google hangout invite from GrueMaster or ogra_ 
<ogra_> lol
<lilstevie> lol
<rsalveti> plars: can you paste the logs?
<rsalveti> I know there might be an issue when installing the headers package
<plars> rsalveti: yes, working on it, but desktop on panda is crazy-slow
<rsalveti> which can accidentally pull the omap 3 headers as well
<plars> my browser finally came up
<plars> but my mouse isn't showing up at the moment...
<rsalveti> oh
<rsalveti> that's weird
<rsalveti> plars: the headers/links are kind of messy at this point
<rsalveti> for the dkms packages
<plars> yeah, I don't think it should be this bad
<plars> there's a fair chance it's hung, but I'll give it a minute. ctrl-alt-f1 isn't getting me to a console
<ogra_> rsalveti, not only for dkms
<ogra_> kernel headers in arm are a massive mess in general
<ogra_> dues to no subarch support in dpkg and friends
<rsalveti> exactly
<rsalveti> afaik infinity is working on that
<plars> finally
<plars> bug #1062407
<ubot2> Launchpad bug 1062407 in pvr-omap4 "pvr-omap4 1.9.0.5.1.1-0ubuntu4: pvr-omap4 kernel module failed to build" [Undecided,New] https://launchpad.net/bugs/1062407
<ogra_> you need faster usb keys
<plars> ogra_, rsalveti ^
 * ogra_ really doesnt get that preempt stuff
<plars> ogra_: yeah, I do.  It's such a gamble buying these things though.  I bought 2 of these pny sticks that I'm using now because 2 other people I talked to said they worked great.  They are barely usable for arm rootfs, and they are useless for other installs from usb because they can't be booted from
<ogra_> supertalen ones are pretty great
<ogra_> but also pretty expensive
<ogra_> ther have a real SSD attached in the backend
<ogra_> *supertalent
<ogra_> "for kernel 3.5.0-17-omap"
<ogra_> yeah
<ogra_> plars, ^^^ from your log
<plars> ogra_: yes, but the one I'm on is 3.5.0-212-omap4 after the update
<ogra_> omap vs omap4
<ogra_> it uses the totally wrong headers
<plars> ogra_: so this is related to the kernel header mess you previously mentioned
<ogra_> yes
<rsalveti> /usr/src/linux-headers-3.5.0-17-omap :-)
<rsalveti> yeah
<ogra_> these shouldnt be installed
<rsalveti> plars: just remove the omap3 headers package
<plars> rsalveti: how did those get introduced though? The install I started from was today's omap4 image
<rsalveti> guess they might be installed as a dependency from dkms
<rsalveti> the headers-generic or such
<ogra_> either that or there is some seed mess
 * ogra_ takes a look 
<ogra_> could be that they are seeded for build-essential
<rsalveti>  linux-headers-generic-pae | linux-headers-686-pae | linux-headers-amd64 | linux-headers-generic | linux-headers,
<ogra_> ogra@anubis:~/Devel/seeds/ubuntu.quantal$ grep omap *
<ogra_> desktop: * (linux-headers-omap4) [armhf armel]
<rsalveti> we should just remove them from recommends
<ogra_> hmm, no
<ogra_> yeah
<rsalveti> ogra_: plars: bug 960770
<ubot2> Launchpad bug 960770 in dkms "Packages requiring dkms at Pandaboard (omap 4) will also pull linux-headers-generic because current dkms dependencies" [Medium,Confirmed] https://launchpad.net/bugs/960770
<ogra_> great, duplicate then
<rsalveti> I believe we had a thread at the kernel ml about that
 * rsalveti searching
<plars> ah
<rsalveti> plars: so while annoying, it should not break anything at your side
<plars> rsalveti: yeah, gotcha
<plars> ogra_, rsalveti: either of you been insane enough to try launching libreoffice on panda recently? seems to be crashing on startup for me
<infinity> wookey: I might have to postpone that glibc talk with you until next week, my day's getting busier than expected.
<rsalveti> infinity: wookey is gone already anyway
<infinity> rsalveti: I figured, since he said he had plans this evening. :)
<rsalveti> infinity: :-)
<ogra_> plars, argh, no i havent
<GrueMaster> plars: That is usually done by QA.  Oh, wait....
<plars> ogra_: trying to see if I can get someone to reproduce it. I tried all of the lo apps and they all crash on startup for me
<ogra_> infinity, not sure if you saw that in yur backlog: i'm just uploading tegra and tegra3 drivers with the broken libs, please have a look (i added a changelog note about the libs and documented a manual workaround in the bug)
<infinity> ogra_: Fun. :/
<ogra_> infinity, its identical to tegra2, just different binaries and versions
<infinity> ogra_: Do you have a firm promise from srwarren to get it fixed so you can SRU?
<ogra_> i have a promise from the actual dev :) but no ETA
<infinity> Mmkay.
<ogra_> plars, if its reproducable i guess we should unseed libO again
<ogra_> damned
 * ogra_ goes back to friday evening stuff
<wookey> infinity: main glibc issue http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763 seems to be fixed today
<ubot2> gcc.gnu.org bug 33763 in c "[4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining" [Normal,New: ]
<wookey> but now it's barfing with check_fds.c:64:1: error: 'AT_FDCWD' undeclared
<ztjord> Hey guys - I'm trying to get QEMU to work in Ubuntu Precise Pangolin and emulate an ARM system running Precise Pangolin or Lucid Lynx.  Has anyone here successfully done this?
#ubuntu-arm 2012-10-06
<robclark> does anyone know anything about this error from lightdm:
<robclark> WARNING: Error using VT_ACTIVATE 7 on /dev/console: Invalid argument
<ogra_> not really, try #ubuntu-desktop (specifically robert_ancell, he is upstream)
<robclark> fwiw, I don't see this on my laptop.. I do see on panda, and when I google for that I turn up a bunch of other panda or other arm-ish looking setups..
<robclark> ogra_, or anyone else that has a panda setup with working lightdm, could you check quickly if you see the same error in /var/log/lightdm/lightdm.log?
<ogra_> i wonder if thats a vesa function
<robclark> well, looks like normal VT switch stuff, which I would *expect* to work..
<robclark> of course, might be some funny dependency on vga-switcharoo or some vesa stuff
<ogra_> [+66.25s] DEBUG: Greeter connected, display is ready
<ogra_> [+66.25s] DEBUG: New display ready, switching to it
<ogra_> [+66.25s] DEBUG: Activating VT 7
<ogra_> nothing else wrt VT
<ogra_> so it seems to be fine for me
<robclark> ok.. then I guess that I am on the right track about my lightdm issues..
<ogra_> did you compare your kernel config to ours ?
<robclark> ogra_, well, that is just w/ TI ppa kernel..  my dev filesystem w/ self-built kernel is fine
<robclark> I guess I can grab /proc/config.gz
<robclark> I'm not sure what config you have in main repo's..  or if ours differs.. but I guess somehow lightdm works for at least some other people..
<ogra_> not sure we ship that enabled but /boot has the config
<robclark> got a config handy that I could diff against?
<ogra_> one sec
<ogra_> robclark, http://paste.ubuntu.com/1264305/
<robclark> urrg.. way does paste.ubuntu.com make me login to download as plain text..  wget doesn't like that much :-/
<ogra_> yeah, its odd
<ogra_> the alternative would be a capcha i guess
<ogra_> IS doesnt wont to run it fully open
<robclark> well, I guess wget couldn't deal w/ a captcha either :-P
<ogra_> yeah
<robclark> ogra_, hmm, we have CONFIG_VT_HW_CONSOLE_BINDING=y, but you do not..
<robclark> there are a bunch of other diff's but I guess they are unrelated (I guess this is from 3.5 kernel in your case?)
#ubuntu-arm 2012-10-07
<ogra_> infinity, any news about the tegra3 package ?
<VarmVaffel> I'm having some problems with booting a custom ubifs-image, if anyone would care to look at my kernel bootlog and see if they can spot anything then I would be very grateful
<VarmVaffel> http://pastebin.com/j0swhBdE
<VarmVaffel> the rootfs image is stored on a 512MB NAND chip
<VarmVaffel> all information should be in that log really
<VarmVaffel> wait fuck, that's not the complete log, sorry
<VarmVaffel> http://pastebin.com/ADSJTFKD there it is, the ubifs fails to boot rootfs on the bottom
<ogra_> infinity, any news about the tegra3 package ?
<infinity> ogra_: Haven't had a chance to review it yet.  Long weekend being devoured by Panda buildds being crap.
<ogra_> yeah i found a bug as well
<ogra_> so probably reject it and let me re-upload ... its only a 1 char change anyway
<infinity> ogra_: Re-upload whenever, I don't need to reject for you to do that.  The queue doesn't care about version clashes, only the archive.
<infinity> (But I'll reject now anyway, now that you've told me)
<ogra_> thx
<ogra_> infinity, fixed tegra3 uploaded ... for later review ... whenever it's convenient
#ubuntu-arm 2013-10-01
<jaakkos> what spawns login on ttyO2 on Pandaboard Ubuntu? doesn't seem to be upstart...
<jaakkos> i'd like to run commands at startup and have them print to the serial console. i could do this with upstart using /etc/init/ttyO2.conf but then 2 login processes are using the same serial console.
<jaakkos> i have ttyO2 in kernel parameters but this shouldn't automatically spawn login on that console?
<ogra_> which image is that ?
<ogra_> (server ? desktop ?=
<ogra_> )
<jaakkos> should be server
<jaakkos> 12.04 LTS
<ogra_> and you used the serial install ?
<ogra_> there should be an upstart job for ttyO2 then
<jaakkos> this is a dd'd image, wait a sec.
<jaakkos> downloaded from http://cdimage.ubuntu.com/releases/12.04/release/
<jaakkos> ogra_: and indeed, grep -R ttyO2 /etc doesn't yield anything (unless i write ttyO2.conf myself)
<jaakkos> and writing it myself spawns 2 logins.
<jaakkos> well, i think i'll resort to a never-ending init script
<jaakkos> though it would be really nice to know what is spawning it...
<jaakkos> ah i think it's /etc/init/serial.conf
<jaakkos> it greps console= from /proc/cmdline and starts getty on it :P
#ubuntu-arm 2013-10-02
<ogra_> bug 1233281
<ubot2> Launchpad bug 1233281 in ureadahead (Ubuntu) "crashes on Ubuntu Touch due to /var/lib/ureadahead/ being read-only" [High,New] https://launchpad.net/bugs/1233281
#ubuntu-arm 2013-10-03
<jj1234> anyone know why dpkg-architecture -aarmhf would return: sh: 1: arm-linux-gnueabihf-: not found ???
#ubuntu-arm 2013-10-05
<dezine> Hey everyone. I have a Samsung Chromebook, with Ubuntu installed on it. I'm just wondering if there's anyway to install Chrome on it, since it's an ARM processor I can't just use the i386 one. Thanks.
<infinity> dezine: apt-get install chromium-browser
<dezine> man, lol. Thanks.
<dezine> I was trying just chromium
<dezine> Then I found a deb and it said I didn't have dependencies so O
<dezine> I was doing random stuff
<infinity> dezine: 'apt-cache search chromium' might have helped.
<dezine> good to go tho
<dezine> ah that's the comman
<dezine> couldn't rememner
<dezine> thanks again
#ubuntu-arm 2014-09-30
<Valduare> hows it going guys
#ubuntu-arm 2014-10-01
<Valduare> no one communicates in this channel ever! :P
#ubuntu-arm 2014-10-02
<jeremybrown82> does any one know of a good tut for putting ubuntu on a tegra k1?
<jeremybrown82> this one in particularly this one http://www.amazon.com/Acer-Chromebook-CB5-311-T1UU-13-3-inch-NVIDIA/dp/B00MHX6TIA/ref=sr_1_14?ie=UTF8&qid=1412254344&sr=8-14&keywords=chromebook#productDetails
<Valduare> hows it going guys
<VeiledSpectre> Excuse me everyone - I have some quuestions - I'd like to get into some ARM development.  can anyone tell me what the difference between the gcc-arm-linux-gnueabi and the gcc-arm-linux-gnueabihf packages are?  In addition, does installing the packages also install the pre-requiste c-library headers and runtimes?  Or is it assumed that such things are taken care of by your kernel image configuration on the target board?  ?
<VeiledSpectre> Im looking for a cross-compiler toolchain from an x86 linux build to an arm linux build, and Ideally im also looking for gdb support for debugging my arm programs
<VeiledSpectre> I know that gcc can be built without c-library support and runtime and without specific linux headers but this is not what im looking for
<genii> VeiledSpectre: Now to wait :)
 * genii makes more coffee
<VeiledSpectre> Haha - hello again - thanks for the direction - I dont mind waiting - it gives me time to read to see if theres anymore illumination out there.  I'm just really trying to avoid cross compiling all of gcc and binutils and glib and gdb myself... Even following instructions I am running into isssues
<infinity> VeiledSpectre: If all you want to build is kernels, which compiler you use is irrelevant.  And yes, either of those will depend on the right headers.  You could have tested easily enough. :)
<infinity> VeiledSpectre: The difference is which ABI (soft float or hard float) the compiler defaults to.
<VeiledSpectre> Thank you infinity : If they depend on the linux headers and they arent included themselves, where would someone get the headers for cross compilation?  ie.  My host machine is x86.  it has x86 headers.  I installed the gcc-arm-linux-gnueabi package.  I want to use it to develop arm.  Where does one get the necessary arm-linux headers?   Additionally, do the packages include the architecture specific clibrary and runtime hook
#ubuntu-arm 2014-10-04
<Umeaboy> Hi!
<Umeaboy> Anyone expert in the commandline here?
<Umeaboy> Ihave this issue during before make -j4 hybris-hal: awk: fatal: cannot open file `sdk/files/tools_source.properties' for reading (No such file or directory)
<Umeaboy> I think that file or that dir is important.
<Umeaboy> I'm building my own version of Sailfish OS using the chroot-env mentioned in the HADK displayed here: http://bit.ly/hadk-doc-rev2
<Umeaboy> It's an Ubuntu chroot env.
<Umeaboy> So that's why I'm asking.
<Umeaboy> Chapter 5.
<Umeaboy> That's page 7.
#ubuntu-arm 2015-09-28
<Martyn> This is the way we port PCI-Express, port PCI-Express, port PCI-Express....
<Martyn> arm 64 bit chips, whacky fun with bodged-together IP
<Martyn> I swear I will get this @#$!@ nvidia thing working
<mijk> Hi
<mijk> Anyone running Ubuntu on a chromebook?
<mijk> I dont knwo if i should get a arm chromebook or a intel chromebook
#ubuntu-arm 2015-09-30
<fear> I have ubuntu mate running on my raspberry pi ( version 2 model b) using an arm processor, and it only sees 4gb of the 32gb on the micro sd card, why is this?
<lautriv_> hey there ;) anyone using a rockchip rk3188 with *buntu ?
<k1l_> wasnt rockchip the ones that dont provide any sources?
<lautriv_> k1l_, there are sources, there are also certain linux-images but made for a specific board useless for mine .
<lautriv_> i found some sites talking about picuntu but appears that site is down.
<k1l_> lautriv_: yeah, on ARM you need specific images for the boards. not a universal iso like on the pcs.
<lautriv_> k1l_, i'm aware of the difference, working on a SoC under NDA. But the main difference for rockchips is the bootloader b/c init of memory.
<k1l_> yeah, best is to look out for your specific board.
<lautriv_> hardware is already present.
#ubuntu-arm 2015-10-01
<lautriv_> does anyone know what happend to picuntu ?
#ubuntu-arm 2015-10-02
<in1t3r> guys anyone experienced with making a debootstrap on debian or ubuntu for compiling armel or armhf?
<in1t3r> I have a problem with setting up debootstrap for compiling armel on debian amd64
<in1t3r> I get an error for mount chroot: failed to run command 'mount': No such file or directory
<in1t3r> http://dpaste.com/0SDRCDG
<in1t3r> basically is this a debootstrap script issue?
<in1t3r> It looks like that to me I'll try to edit it
#ubuntu-arm 2015-10-03
<cadenr> hello, how can i resize my root partition?
<cadenr> anyone here?
<cadenr> uhhh goodbye
<bpadalino> 2 minutes .. patience is a virtue
#ubuntu-arm 2015-10-04
<cadenr> hello again
#ubuntu-arm 2017-10-04
<NullGl1tch>  /part
<web_dev> hi folks
<web_dev> why if i update my dev board OS
<web_dev> the OS won't boot next time?
<web_dev> maybe i need to update u-boot?
