#ubuntu-arm 2009-02-03
<rc55> As rediculous as it may seem, I think the fact that you guys are working on an ARM port rocks!
<ogra> nothing ridiculous on that :)
<Stskeeps> kozak: good news :)
<kozak> Thats mer on beagle???
<Stskeeps> yup
<Stskeeps> it was pretty easy
<Stskeeps> you have a usb hub and such and keyboard? i don't
<kozak> Cool
<kozak> I dont either :(
<kozak> not yet...
<Stskeeps> k
<kozak> I am having a difficult time working on Android with this set up
<ScriptRipper> hi guys.
<Stskeeps> evenin'
<ScriptRipper> how are you?
<Stskeeps> good. i booted ubuntu jaunty on a pocket loox 720 earlier today :>
<ScriptRipper> hopefully, i get tomorrow a first look at the beagleboard with 256 MB RAM... not sure though if i get one ....
<ScriptRipper> will check how well 9.04 works on it :D
<Stskeeps> hehe
<Stskeeps> base system is fine with 128mb, it's the GNOME stuff that hurts :)
<ScriptRipper> i know ....
<ScriptRipper> but the fun begins with 256, when firefox and the like wants to run ...
<ScriptRipper> i want to see it with my own eyes...
<Stskeeps> hehe
<ScriptRipper> i ll tell you if its worth ...
<Stskeeps> mm, i have two beagleboards in my office
<ScriptRipper> the 128 MB or 256 MB version?
<Stskeeps> 128
<ScriptRipper> aha. 2x beagleboard has also 256 MB RAM :)
<ScriptRipper> dual core
<ScriptRipper> i ll ask when the 256 MB versions will be distributed...
<ScriptRipper> any questions from you for the TI guys?
<Stskeeps> not personally :P
<ScriptRipper> nothing not already asked at beagleboard already I guess
#ubuntu-arm 2009-02-04
<Stskeeps> http://www.daimi.au.dk/~cvm/mer-pocketloox720.jpg <- ubuntu userland + maemo platform stuff on top, on a pocket loox 720 :>
<ScriptRipper> hi all
<ScriptRipper> back from my TI meeting :)
<Stskeeps> how did it go?
#ubuntu-arm 2009-02-05
<ScriptRipper> hi guys.
<ScriptRipper> got a beagleboard now with 256 MB RAM
<ScriptRipper> did any of you try that already out?
<Stskeeps> hehe, no, sadly ;)
<ScriptRipper> ok, after configuring u-boot correctly, got it working now.
<ScriptRipper> Who knows why all this gnome stuff is running when I run xfce?
<ScriptRipper> Even 256 MB get eaten away fast
#ubuntu-arm 2009-02-08
<jldugger> Processor	: ARM926EJ-Sid(wb) rev 0 (v5l)
<jldugger> im assuming that's too old for ubuntu
<Stskeeps> nah, it's armv5te
<Stskeeps> which works with ubuntu
<jldugger> interesting
<jldugger> unfortunately, ive got 64 megs of RAM on it
<Stskeeps> can probably run the base system :P which device is it?
<jldugger> D-Link DNS 323
<Stskeeps> well 64 mb can probably take the base system, definately :P
<jldugger> theres a gig of swap
<Stskeeps> we have a ubuntu base system on nokia 770's, which are 64mb ram so
<jldugger> for the moment i'll stick with ipkg and see how that goes
<jldugger> there's two guides out there for running debian on this thing; one is chroot and the other is not
<ogra> hmm
<ogra> i wonder how debian does that ... htop on the nslug actually reports only 6M of 30 being used
<ogra> on an idling system
<suihkulokki> ogra: no UI, no memory problems ;)
<ogra> suihkulokki, well, i havent seen an ubuntu kernel running with 6M yet
<ogra> we even had probs booting 32M x86 systems in ltsp 48M was the bare minimum to unpack and execute the initramfs, its pretty impressing to see a 30M system booting and then running with only 6M userspace being used
<ogra> and i really wonder how to achieve that whithout trashing the ubuntu defaults to much
<ogra> hmm, so running an ubuntu userspace on the nslu2 immediately kicks me out after showing motd :(
<suihkulokki> ogra: I guess this extra ubuntu stuff is installed after debootstrap ?
<ogra> suihkulokki, https://wiki.ubuntu.com/ARM/RootfsFromScratch ... calls debootstrap, switches to qemu, does the second stage, sets up a user, locales and timezone and install the set of packages you give it ... (in this case only ubuntu-minimal)
<ogra> and yes, its a bunch more stuff being started than in the d-i lenny slug install
<ogra> but not enough to prevent a login, i think there shoud still be enough spare ram to run bash
<suihkulokki> because I was under the impression that debootstrap for ubuntu and debian are almost identical
<ogra> right
<suihkulokki> so I guess the bloat is in ubuntu-minimal
<ogra> well, the seond stage simply installs the ubuntu-minimal metapackage in ubuntu
<ogra> i wouldnt call it bloat :)
<ogra> its console-setup, klogd and some other essential settings
<ogra> the fun is that i actually see motd ... but then get bunped to login again
<ogra> *bumped
<ogra> http://paste.ubuntu.com/115708/
<ogra> thats the ubuntu boot after leaving initramfs
<ogra> not actually a lot more than the debian boot .... and no MTA
<suihkulokki> indeed
<suihkulokki> perhaps there is some too funky bash config there
<suihkulokki> ie. try changing the user shell to dash
<ogra> yeah, i'll do that
<ogra> though it works fine on all other arms i tried it on yet ....
<suihkulokki> slug is a bit stretch on what makes sense for running a general purpose distro
<ogra> heh, yeah, 30M is something i havent seen in quite some time
<ogra> nope, dash doesnt help ...
 * ogra kills the startup links for syslog and klogd
<ogra> aha, an error message
<ogra> init: ttyS0 main process ended, respawning
 * ogra checks his serial console setup again
<ogra> heh
<ogra> ok, its just me having been silly setting up the proper upstart stuff
<ogra> putting -L into the getty line somewhat helps :P
<ogra> hrm, but still doesnt let me in
<ogra> sigh ... apex doesnt let me set init=/bin/bash ? pfft
<ogra> grrr, what a crappy HW
<ogra> oh
<ogra> readonly fs ... hmm
 * ogra adss lots of swap to exclude ram issues
<ogra> GRRRRR
<ogra> no go :(
<Stskeeps> how much ram does the slug have anyway?
<ogra> 30M
<ogra> but it has 256M swap now
<ogra> so its not ram thats the issue
 * ogra curses ... i'd so love to know what that is
<ogra> and that shitty bootloader doesnt let you change the cmdline on boot, you can only change it with apex-utils
<ogra> from the running system ... to which i cant log in to
<ogra> so booting with init=/bin/bash literally means to replace init each time i test something and need eth live HW
<ogra> *the
<ogra> hmm, so unsetting the rootpw gets me in as root
<ogra> but still no way to do it as user
<ogra> ah, well, so the ubuntu basic system with additionally running sshd uses up 7M
<ogra> nt to bad
<ogra> *not
<ogra> root@nslu2:~# sudo -u ogra ls
<ogra> Killed
<ogra> hmm
#ubuntu-arm 2010-02-08
<lool> I merged kexec-tools with Debian
<ogra> nice !
<ogra> but it still doesnt work ?
<ogra> (on arm)
<lool> ogra: It still hangs when you try to kexec within qemu/versatile
<lool> The Debian merge was mostly packaging stuff
<persia> The packaging is sane again?
<lool> Yes
<lool> The Ubuntu diff is absolutely bearable
<lool> We mostly disable kexec on boot by default and add kdump
<lool> Too bad I didn't notice there is a kernel.ubuntu.com/git kexec-tools git tree, but it has its own issues anyway
<persia> I suspect it's from that tree that last week's tests were executed.
<lool> I mailed cooloney on the kexec issue; I hope he can help us there, it's too low level for me
<persia> Probably best to coordinate with ericm_ and NCommander to make sure everyone is testing the same source.
<persia> I thought ericm was doing most of that, but cooloney may also be able to help.
<lool> persia: The tree has the same issues as lucid, it's out of date by one upload before my work and just misses the kdump init script
<lool> I rather suspect NCommander took Debian's or upstream's kexec-tools
<persia> Quite possibly.
<lool> I wonder whether ericm can be bothered for versatile kexec
<persia> lool: Did you ever get anywhere with the pbuilder-dist changes to do better detection of when to use the alternate debootstrap?  Should I track down some other python person?
<lool> I didn't attack that
<persia> I suspect that getting versatile kexec working would be a good step towards getting it working anywhere else.
<lool> My real plan is to remove the need for pbuilder-dist altogether, but that's a longer term effort
<persia> No worries then.  I'll try to find someone else.
<lool> If you remind me of everything we agreed to do, I can certainly do it
<persia> I have a solution to drop pbuilder-dist: migrate to schroot/sbuild :)
<lool> Eh
<lool> schroot/sbuild doesn't have cowdancer though; it does have LVM snapshot, but it's a bit different
<persia> You didn't like me using the architecture to determine when to use the emulator: you seemed to prefer to do host/guest arch compat comparison.
<persia> schroot *does* have COW now, in 1.4, although I haven't quite figured out how to get it working.
<persia> It's on my list to try to get schroot to work with pbuilder-style tarballs, COW, etc. in the next few months (although I'm not sure I can release with lucid)
<lool> I don't see that; are you sure you don't mean LVM COW?
<persia> I am.
<lool> persia: I don't see this in /usr/share/doc/schroot/NEWS.gz though; let me check sbuild
<lool> I don't see it in sbuild's NEWS either
<lool> persia: Do you have any name/reference for the feature?
<persia> "Support for union filesystems has been added ... loopback chroots with a temporary writable overlay ...".  It's not quite COW, but should have similar performance.
<persia> Quote is from sbuild's NEWS.gz
<lool> Ah but that's not in lucid?
<persia> Yes it is :)
<lool> I was checking lucid files
<persia> So was I.  Check item 8) in NEWS for 1.3.0-rc1
<lool> Why don't I see union in NEWS.Debian and NEWS??
<lool> sbuild doesn't have 1.3.0-rc1
<persia> Err, sorry.  From *schroot* NEWS.gz
<persia> sbuild is just a build script that runs against schroots.
<lool> Ack I see it now
<cooloney> lool: yeah, i'm looking at that.
<lool> Using union fses is much cleaner than pbuilder's approach
<cooloney> persia: ericm_ made it kexec works on dove, IIRC.
<lool> cooloney: let me know if you need any help with the setup
<persia> lool: And `sudo pbuilder` is just pointless escalation.  schroot's selective mechanism is much richer.
<cooloney> persia: he will help me about this
<lool> persia: Tell me about it
<persia> cooloney: I thought it kinda worked, but then crashed on the call, but I may be mistaken.  Great to hear you guys will be working together on this.
<cooloney> lool: yeah, do you know where can I download the rootfs for testing
<lool> cooloney: Best to create your own; it's quite easy
<persia> cooloney: Use rootstock to generate one :)
<lool> I still call debootstrap by hand, but the recommended tool is probably rootstock or just build-arm-chroot
<cooloney> persia: yeah, since imx51 also has some issue about kexec, i need to work on that as well as versatile
<lool> rootstock will setup misc configs for you, hostname, passwords and the like
<persia> Definitely rootstock.  It does a lot of the installer bits that build-arm-chroot skips, like user creation, etc.
<persia> (which don't belong in build-arm-chroot, really)
<cooloney> lool: oh, it is very slow for me to download the evironment. i tried rookstock before. heh
<lool> cooloney: You don't have a mirror nearby?
<ogra> cooloney, kexec didnt work on friday when NCommander tried it though that might be because kexec-tools was broken
<lool> cooloney: I can back you my rootfs if you like, hold on
<cooloney> lool: can i try common local ubuntu mirror for that?
<cooloney> lool: yeah, i love that. hehe
<lool> cooloney: You need a ports mirror sadly
<cooloney> ogra: yeah, ericm_ mention that before.
<lool> cooloney: What I recommend is that you use squid as a caching proxy
<lool> If the .debs don't change too often, nost of the debootstrap bits will be cached in there
<cooloney> lool: i guess there is no such ports mirror in China.
<ogra> cooloney, use approx on your local machine
<lool> cooloney: squid-deb-proxy is a package which will setup squid to that effect
<cooloney> lool: great, is there any wiki for such setup?
<ogra> then you at least only have to download once
<lool> cooloney: Then you just need to set http_proxy in /etc/environment and you're done
<lool> cooloney: squid-deb-proxy might have some doc
<ogra> or as lool said
<lool> cooloney: I'm scp-ing my rootfs, but will take a while
<cooloney> lool: got you
<ogra> approx needs no setup though ... you just point to your local IP
<ogra> on port 9999
<cooloney> lool: thanks a lot, if it is done, just email me
<cooloney> ogra: right, i think i tried approx before. any wiki about that?
<cooloney> lool: email me the url, heh
<lool> cooloney: URL will be http://people.canonical.com/~lool/rootfs.img
<lool> but not finished yet
<ogra> cooloney, apt-get install approx ... then use -mirror http://<your local IP>:9999/ubuntu-ports in your scripts (or set http_proxy to <your local IP>:9999)
<ogra> i use it with rootstock all the time to speed up my testbuilding
 * lool simply has a local mirror
<persia> A local mirror tends to be the easiest way to deal with limited bandwidth, but does require a bit more hardware.
 * ogra thinks lool is a rich man who can waste useful diskspace
 * lool thinks his time is more valuable than hardware
<ogra> with a disk that costs â¬20/GB i really dont like to waste it
<lool> 20 EUR/GB?  are these made of gold?
<ogra> well, i rarely need most of the packages from the mirror ... so just caching the ones i use over and over makes a lot more sense
<cooloney> OMG, you guys all have local mirror?
<ogra> lool, no, of super speedy flash :)
<lool> https://www.materiel.net/ctl/Disques_durs_internes_SATA/46461-Barracuda_7200_12_S_ATA_1000_Go_32_Mo.html
<cooloney> so normally, how big disk is enough for setup a  mirror?
<ogra> cooloney, nope, as i said above, i think a local mirror is a waste of diskspace
<cooloney> ogra: apparently, you don't have, heh
<cooloney> ogra: you got faest speed maybe. heh
<lool> That's .075790 EUR/GB  :)
<ogra> a local proxy will only cache what i need, a local mirror copies the whole archive
<cooloney> ogra: right.
<ogra> lool, does it boot in 8sec ? :P
<lool> ogra: That only works if you always the same stuff
<cooloney> but lool doesn't care about that
<lool> ogra: Actually about that yes
<ogra> indeed, its perfect for image builds
<lool> Because it's in RAID10 and doesn't start the desktop
<ogra> haha
<ogra> cheater
<ogra> lool, http://people.canonical.com/~ogra/osiris-lucid-20100202-6.png :P
<ogra> and thats a slow boot ... i usually have around 230MB/s
<persia> Stop wagging :p
<cooloney> lool: how big is your rootfs? heh
<lool> ogra: Err you know I have SSD on my laptop since a year and a half?
<cooloney> lool: 1G?
<lool> Plus mine is bigger than yours
<ogra> lool, yeah, as i said, youre a rich man ... i'm a poor german, cant spend on wine for lunch :P
<cooloney> ogra: lol
<lool> Just don't try teasing me!
<lool> cooloney: Done uploading
<lool> cooloney: There isn't much free space, you can grow the rootfs by appending some zeroes to the file and growing with ext2resize
<ogra> lool, was it you who added the if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then check to rootstock ?
 * ogra cant remember from where that got merged, but it seems silly to additionally keep the version check code 
 * persia suggests `bzr blame ...`
<ogra> persia, bah, trying to kill my lazyness ?
<persia> Every day, in every way :)
<lool> 23     ogra@ub | if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then
<ogra> hrm
<lool> committer: Oliver Grawert <ogra@ubuntu.com>
<lool>   add a check if debootstrap supports $DIST, thanks to Erik Corry <erik.corry@gmail.com> for the fix !
<ogra> oh, k
<ogra> i think i got that one by mail
<ogra> adn i think i'll just kill all the silly version checking then
<lool> ogra: This check doesn't seem too bad though, what's the issue with it?
<ogra> lool, nothing apart from bloating the code if we check for /usr/share/debootstrap/scripts/$DIST anyway
<ogra> its kind of a duplication imho
<lool> ogra: Where do you do that?  in build-arm-chroot?
<ogra> rootstock
<lool> So where is it duplicated?
<ogra> if $(dpkg --compare-versions $DBSV lt $DEBOOTSTRAP_MIN_VER);then
<ogra> vs
<ogra>  if [ ! -f /usr/share/debootstrap/scripts/$DIST ];then
<lool> The version check is the one I'd drop
<ogra> right, thats what i said :)
<lool> The data-driven check seems more future proof than a version requirement which will be out of date every release
<ogra> right
 * ogra -> break
<cooloney> lool: i am downloading now.
<cooloney> lool: it is 300M, need I append some zeroes? I don't understand heh
<ogra> its an img not a rootfs
<ogra> so to have more space on it you need to make it bigger by adding zero byte blocks and resize the partition
<cooloney> ogra: got you. so normally how to do that : adding zero?
<ogra> use dd
<cooloney> ogra: dd conv=notrunc oflag=append if=/dev/zero of=rootfs.img bs=1M count=1024
<cooloney> ogra: is this kind of command, right? add 1G zeroes at end of rootfs.img
<ogra> cooloney, hmm, never used append, but if it does the same as skip and seek that should work
<ogra> best to try it on a copy of the image i guess :)
<cooloney> ogra: heh, right. hehe
<lool> cooloney: That seems about right
<lool> cooloney: Or just dd if=/dev/zero bs=something count=something >> rootfs.img
 * ogra guesses cooloney would already have shouted and cired if it hadnt worked :)
<ogra> *cried
<lool> ogra: But it's actually a rootfs
<lool> It's just that most people say rootfs when they mean rootfs tarball
<ogra> well, one is an imag the other is the content of a filesystem
<ogra> neither is named right anyway :)
<ogra> since neither is actually a filesystem per se
<lool> the rootfs.img is a filesystem
<lool> i.e. root file system
<lool> asac: is bug #474322 on your radar?
<ubot4> Launchpad bug 474322 in linux-fsl-imx51 (Ubuntu Jaunty) (and 1 other project) "linux-image-2.6.28-16-imx51 appears broken on armel (affects: 1)" [Critical,Triaged] https://launchpad.net/bugs/474322
<lool> it's from November and is a regression in a security update of the kernel in jaunty
<lool> rcn-ee: Re: your qemu-arm-static -> qemu-kvm-extras-static issues: this should be fixed in latest versions
<lool> rcn-ee: let me know if it isn't
<lool> rcn-ee: Do you have a place where you publish your daily rootstock build logs, or is http://rcn-ee.homeip.net:81/dl/rootstock/ just updated manually?
<lool> I wonder whether we should publish daily built rootfs like the UEC images
<lool> I wonder why devtmpfs breaks for you
<persia> rcn-ee: Regarding the "fixed" statement above, note that setuid binaries still won't work, but this is an inevitable consequence of how the emulation is done.
<apw> ogra, lool, i've built some kernel .deb's for lool's versatile configuration changes, want to get some testing on them before i upload them; see the 13.18 kernels here: http://people.canonical.com/~apw/misc/arm/
<ogra> apw, will test soon, thanks a lot
<lool> apw: Tested with serial console, works fine up to a console login prompt
<asac> cooloney: can you check the bug lool mentioned?
<asac> 474322
<asac> that is
<asac> cooloney: seems it stopped working on bbg1 after security update... thanks!
<lool> apw: Checking with graphics now (vga/fb video output)
<lool> apw: Boots fine; NB: I just extracted the vmlinuz file and usese that
<apw> ok
<lool> apw: I don't think it's a regression, but I can't actually poweroff/reboot the system
<rcn-ee> lool, yeap it looks fixed... (worked friday night when i was testing things for ogra)...  For reference my 'nightly' builds are here.. http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log  i need to do a bzr pull thou, it's karmic + lucid tweak...
<lool> The userspace bits seem to happen fine, but it doesn't actually reboot/stop
<ogra> i think reboot never worked
<ogra> at least with the archive kernels
<persia> Is this an issue with qemu, or with the kernel?
<apw> ok .. i guess i am trying to ensure its not a regressing kernel for you guys
<lool> persia: I don't know, and it's a case where it's hard for me to tell
<lool> I do see "Restarting" on the console, and then nothing happens
<ogra> ah, no shutdown never worked for me ...
<cooloney> asac: no problem, but I need to setup my bb1 board tomorrow.
<lool> apw: I really don't think it's a regression, but I never paid attention
<lool> apw: The current archive kernel doesn't work at all, so... :)
<ogra> its very likely not a regression
<apw> thats fine with me, as long as ogra is happy i'll call it good
<ogra> apw, just upload, if it works for lool it will surely work for me too (i use way less features)
 * ogra only needs ext2/NIC and serial console 
<ogra> lool,  rm /bin/installer && reboot -fp ... thats in rootstock since day one ... i wouldnt have used -f if it would power doen properly
<ogra> *down
<ogra> not clear though if its qemu ...
<ogra> weird, i cant get it to boot
<ogra> it works if i dont use serial
<ogra> apw, lool ^^^
 * apw puts those changes on one side
<ogra> hrm
<ogra> if i add mem=256M to the append line it works
<ogra> weird
<persia> So it just can't handle much memory?  I thiought there was a patch for 512M (and seem to remember fiddling with it in jaunty)
<ogra> no, its not that, i copied another append line that differs in ro vs rw and mem=256M
<ogra> its not the mem but the ro/rw
<ogra> it boots fine with ro
<persia> Aha.
<ogra> but not with rw
<persia> Very odd.
<ogra> apw, i can work around that in the script
<ogra> so please upload
<ogra> yes, odd indeed
<apw> hrm, ok i suppose
<lool> ogra: How much memory are you using?
<ogra> lool, 256M
<ogra> but see above
<ogra> its not that
<lool> That works for me without mem=
<ogra> it seems it cant boot with rw on the cmdline
<lool> qemu-system-arm -m 256  -drive file=rootfs.img,media=disk -M versatilepb -cpu cortex-a8 -kernel vmlinuz-2.6.32-13-versatile -append 'rootwait root=/dev/sda 2' is what I use
 * ogra tries with dropping ro/rw completely 
<ogra> [    5.451770] VFS: Mounted root (ext2 filesystem) readonly on device 8:0.
<ogra> ok, it defaults to ro
<ogra> lool, does it boot if you add rw ?
<lool> Yes
<ogra> for me it panics with "cant find rootfs"
<lool> It works fine here
 * ogra tries rootwait, probably a race 
<lool> Err yes if you don't have a large rootdelay or rootwait it wont find your rootfs in time
<lool> the scsi disk typically appears a couple of seconds after the kernel tries mounting the rootfs
<ogra> [    5.430661] VFS: Cannot open root device "sda" or unknown-block(8,0)
<ogra> [    5.430938] Please append a correct "root=" boot option; here are the available partitions:
<ogra> nope
<ogra> i usually dont need rootwait or anything ... never did
<ogra> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel tmp/boot/vmlinuz-2.6.32-13-versatile -hda /var/build/qemu-armel-201002081506.img -m 256 -nographic -append "console=ttyAMA0,115200n8 root=/dev/sda rootwait rw"
<ogra> doesnt work
<ogra> exactly the same line but dropping rw works
<ogra> lool, can you try adding rw ?
<lool> ogra: I already did
<ogra> hmm
<ogra> i wonder why it reliably breaks here
<lool> Do you actually have read/write on /var/build/qemu-armel-201002081506.img?
<ogra> heh
<ogra> no, indeed
<lool> pfff
 * ogra re-adds the sudo bit to the README ...
<lool> You don't need sudo to run qemu-system-arm
<lool> Just move your images to your home
<ogra> i just removed that from the rootstock doc ... now i remember again why i added it
<lool> Advising sudo is actually dangerous
<ogra> well, the image is created  as root
<ogra> so owned by root
<lool> Well you don't need to
<lool> You just need to mount the file as root and run debootstrap as root, but you don't need to dd the file as root
<ogra> i do
<lool> Look, I just created this file as user
<lool> And it worked
<ogra> yes, but you dont use it loop mounted until you finished
<lool> I sudo loop mount it
<ogra> it is loop mounted during rootstock
<lool> Yes, so $sudo loop mount it
<ogra> hrm
<lool> Here's an example script I use http://paste.ubuntu.com/371731/
<lool> You can run it as root or not, it will call sudo when it needs to
<ogra> thats ugly because i will pop passwd prompts all the time
<persia> Actually, one should put a check on that class of script to fail if run as root (see mk-sbuild-lv for a nice check)
<lool> There is some caching, so it will only prompt if it's too late; you can workaround that with a helper
 * ogra sighs
<lool> persia: That's an option; you can easily flip the check
<ogra> i will not stop running the script as root
<ogra> i want it to run automated if needed
<lool> ogra: So run qemu-system-arm as root then, but don't advise people to do so by default
<lool> ogra: So how are you going to automate running your script as root?
<ogra> yeah, i'll add inof the the doc
<ogra> i dont, users do
<ogra> and they usually set up root cronjobs
<ogra> i'll just add info to the doc ... i wont scatter sudo calls across the script
<lool> did you actually read the link?
<lool> it doesn't call sudo if called as root...
<ogra> i have the very same check in rootstock ... just not the $sudo var
 * ogra curses about broken userspace
<ogra>  * Starting init crypto disks...                                         [ OK ]
<ogra> hangs :(
<ogra> silly ubiquity -> oem-config merge
<ogra> pulls in half the world and breaks ... old oem-config worked
<ogra> and didnt pull in many deps
<ogra> if [ $(id -u) != 0 ];then
<ogra>     echo "must be run as root"
<ogra>     exit 2
<ogra> fi
<ogra> lool, ^^^ fyi
<ogra> bah, so oem-config goes into an endless loop on my rootstock image
<ogra> i think we need to forget about oem-config usage in rootstock thats way to messed up and only focused on d-i installs it seems
<ogra> s/d-i/d-i or ubiquity/
<ogra> the ui requires metacity which in turn pulls in 400M of deps
<ogra> the debconf frontend doesnt finish and goes into an endless loop
<ogra> ah, well, without recommends its less but still 30MB
<cwillu_at_work> rcn-ee, had disk transfers running over the weekend on that kernel, no random usb reconnects or errors that I can see
<cwillu_at_work> rcn-ee, i.e., looks great :)
<ogra> lool, hmm, did you try running any X programs in qemu yet ?
<ogra> specifically pygtk stuff
<ogra> seems to fail pretty badly here
<ogra> ugh, even metacity
<ogra> i dont think its actually happy with the faked cortex-a8
<ogra> hmm, cpuinfo thinks its capable of thumb and neon
 * ogra calls it a day
<lool> persia: According to linux/Documentation/binfmt_misc.txt, one can set a flag to preserve the original security bits of a program
<lool> persia: It changes the calling convention though, so I don't think it would work with out current qemu-system-arm
<persia> lool: Cool!
<persia> Aha.
<persia> lool: Reading the docs, I'm not sure I understand why we can't just pass the 'C' flag and have it work.
<lool> persia: Because it doesn't pass a real file to the qemu-arm command-line
<persia> It is because of the implied 'O'?
<lool> persia: Currently, when the binfmt hook is triggered for e.g. /bin/sh, what happens is that the kernel calls qemu-arm /bin/sh
<lool> persia: Yes
<persia> Ah, so we'd need to modify qemu-arm-static to take file descriptors rather than file names.
<lool> Yes
<lool> Or have a wrapper
<persia> A wrapper can do FD -> path changes?
<persia> That's more shell than I know, or do you mean a compiled wrapper?
<persia> lool: Reading the docs more carefully, I think we do want to change the calling convention.  I can well imagine cases where a user wants to execute a file to which that user doesn't have read access when dealing with nested chroots, etc.
<persia> But I'm entirely unsure how to do that with a wrapper: I suspect it needs changes to qemu-arm-static itself.  I'd appreciate any pointers if you have them.
<lool> persia: I'm trying to write such a wrapper, but I fail miserably
<lool> When trying to run my x86-64 static wrapper under an armel chroot I get: Error -8 while loading /usr/bin/qemu-arm-static
<lool> persia: I think we would just need a wrapper which passes /dev/fd/N to qemu-system-arm, but I'm not sure; that's what I wanted to verify
<lool> But in the end we would likely patch qemu
<persia> I thought that /dev/fd/N was defined on a per-process basis.
<lool> It is  :-)
<persia> In that case, we can't pass it to a new process :)
<persia> So a qemu patch *is* required.
<lool> persia: exec is the same process
<lool> I think my exec doesn't work because it needs to be handled by binfmt
<persia> Hrm?
<lool> persia: exec() is implemented with binfmt, if my wrapper called from binfmt tries to exec it wont work (well that's my guess)
<lool> not sure it's correct
<lool> Another static utility which just puts() argv / argc works, so it's not my build
 * lool will check this out tomorrow &
<persia> Have a good night :)
#ubuntu-arm 2010-02-09
<lool> persia: Wow flags: OC in /usr/share/binfmts/qemu-arm
<lool> but flags: in /proc
<lool> Pff someone typo-ed that
<lool> persia: Just after fixing flags, it works
<lool> persia: I can sudo
<lool> No change needed to qemu
<persia> Heh.  It takes a night's sleep to try the obvious :)
<lool> persia: LP #519228
<ubot4> Launchpad bug 519228 in binfmt-support (Ubuntu) "Support for C flag (affects: 1)" [Undecided,New] https://launchpad.net/bugs/519228
<persia> I saw the discussion in -devel.  Looks promising :)
 * persia presses the "me too" button
<lool> (works here)
<ogra> sudo worked for me yesterday btw ... i only had a hostname not found warning
<persia> ogra: OK.  Were you root at the time?  Based on the docs I read 12 hours back, it couldn't have worked.
<persia> Because all setuid bits are being dropped by the binfmt_misc handler.
 * persia notes that opening a chroot whilst not being root can be tricky
<ogra> persia, i have to be root to chroot :)
<ogra> well, i usually dont use fakechroot or fakeroot :)
 * persia uses schroot
<ogra> ah, right
<persia> The other option is to do something like sudo to some unprivileged user inside the chroot.
<ogra> whoops, i just dropped off the canonical server
<ogra> hmm, and LP doesnt respond
<ogra> heh, that just looked like a loose cable in the DC ... all back :)
<lool> ogra: Try su - someuser in your chroot, and then sudo something
<lool> It wont work
<lool> See above bug
<ogra> yes, i just read it
<ogra> lool, btw, do you see something like http://paste.ubuntu.com/371902/ trying to start any gtk apps in qemu ?
<lool> ogra: Did you file a bug?
<lool> I didn't try running gtk+ apps
<ogra> not yet, i was researching oem-config and ran into it ... wanted to see if its only me or a missing dep in my minimal setup rootfs
<lool> Would anybody be interested in doing the reverse of the cleanup I did to the qemu versatile config?
<ogra> the reverse ?
<lool> Basically there are some configs which I turned on and ended up being armel specific (or versatile specific; it's the same) but are useless and should be turned off again
<lool> To minimize delta with other Ubuntu configs
<lool> For instance CONFIG_MTD doesn't actually work with qemu/versatile, so could be turned off to reduce delta
 * ogra doesnt really care as long as there are no lockups or other bad breakage
<lool> Flags in debian.master/configs/armel/flavour.versatile should be examined
<ogra> and i'm sure the kernel team wont care either unless they actually get a patch
<ogra> if something gets in my way i'll research the issue and make a change, but if its just a silent delta i'm really not concerned
<ogra> lool, i'm currently more worried about the glibc failure i have seen and start to suspect its caused by the v7 hack we use
<ogra> since it only fakes the v7 CPU but doesnt actually add the features cpuinfo exposes (i.e. neon)
<ogra> (not that i have run any neon capable apps, but you know what i mean i guess)
<lool> cpuinfo doesn't matter for neon
<lool> I just got the double free (fasttop) error when installing packages
<lool> It's not specific to gtk+ apps
<lool> It was during the ldconfig trigger
<lool> startx segfaults in Xorg here
<lool> I also get it with gtk-demo in Xorg
<ogra> startx works for me if i just use xterm
<ogra> as soon as i use a toolkit it breaks, plain X seems to work
<lool> I get a segfault when Xorg quits
<ogra> yay, imx51 with populate_rootfs \o/
<lool> Try running startx, leaving  your session; do you have a segfault in /var/log/Xorg.0.log?
 * ogra hugs ApOgEE__ 
<ogra> opps
<ogra> apw i meant :P
<apw> ogra, ?
<ogra> lool, only if i use toolkit based apps
<apw> ogra, thank me if it boots for you
<ogra> apw, <ogra> yay, imx51 with populate_rootfs \o/
<ogra> i will as soon as i can get it from the archive :)
<apw> heh, lets hope it builds in there :)
<ogra> wow, that changelog looks like someone nearly rewrote ext4 :)
<apw> heheh
<ogra> lool, i have no segfault with an .xsession that just contains xterm
<lool> apw: This is boot speedup work for imx51?
<ogra> lool, for ubuntu in general
<lool> Oh and it was borken on imx51?
<ogra> it just didnt make it in yet
<apw> its a rebase for security and stable updates, plus a couple of patches from brian for performance
<apw> (boot performance)
<ogra> we try to get all the sweetness from our mainline kernel backported now that the patches dont create any hassle
<ogra> lool, the fsl patchset just applied smoothly this time so we actually have time for kernel improvements which we try pull in as many as we can from the ubuntu kernel
<apw> dunno if you will gain anything with such cpu limited platforms, i assume brian tested it and measured it before asking for it
<ogra> no weird forward porting makes everything so much easier
<apw> shame they still frig about in usb, and then wonder why usb drives fail to work properly
<ogra> well, the devtmpfs backport surely gained us a lot already
<ogra> so i'm suspecting the populate_rootfs stuff will too
<apw> ogra, 'surley' ... i am guessing noone tested
<apw> ogra, in my experience its not a gain if you only have 1 cpu
<ogra> i did and see 2-3 sec speedup
<persia> apw: Note that there exists Ubuntu-compatible hardware for other architectures with even less CPU performance than most available ARMv7 hardware.
<apw> persia, indeed, but we are not targetting any specific performance for them
<ogra> are you talking celeron without L2 cache ? :)
 * ogra has such a thing and its slower than my babbage board
<lool> apw: I did test devtmpfs with 2.6.32 kernels in qemu, and I can say the MAKEDEV was taking more than 5 seconds in qemu
<lool> apw: BTW, there are further MAKEDEVs on startup ATM, perhaps we could add more devices to devtmpfs and avoid one more call?
<apw> saved about .2s on a real machine as i recall
<lool> apw: /etc/init/mounted-dev.conf still calls /sbin/MAKEDEV fd in all cases
<persia> ogra: That would be but one example of a large class :)
<ogra> i dont think it was produced in large amounts actually
<lool> apw: Also, I wonder whether we could avoid remounting devtmpfs on top of devtmpfs; that's probably not very long, but still...
<apw> keybuk deals with all that side, i thought all devices were made which were registered in the kernel
<lool> I get the glibc corruption with a minimal gtk+ program which does gtk_window_new + widget_show_all + gtk_main, but not without the window
<lool> Setting MALLOC_CHECK_=0 I can actually run the app
<asac> ericm_: -meeting?
<lool> ogra: I definitely get the segfault when exiting from xterm
<lool> "startx" startx an xterm, I ^D and I get a segfault
<ogra> hmm, i didnt have one yesterday
<lool> dmart: Hey
<lool> dmart: I have this glibc errors which ogra mentionned
<lool> dmart: I wrote a trivial gtk program which reproduces these
<lool> and it aborts but, the backtrace is either useless or useless
<lool> dmart: I've installed our -dbgsym packages for libc6, libx11-6, gtk, pango, and cairo
<lool> I even got a gdb segfault at some point, but not consistently
<lool> dmart: How would I track this down?
<lool> I can break on main() in gdb, but when I get the actual abort, it's somewhere down the gtk internals, and it's hard to break on that
<lool> Ah!  G_SLICE=always-malloc also fixes the bug
<lool> So it's either a bug in glib'c gslice support on armel, or in glibc's memory checks on armel
<dmart> Add some trace I guess, if you can't get a backtrace from the segfault/abort.
<lool> What do you mean by add some trace?
<dmart> Don't really have bright ideas here I'm afraid
<lool> dmart: Do you find gdb useful on armel these days?
<lool> It frequently crashes for me
<dmart> Which version are you using?  lucid's gdb seems a lot more stable than karmic's gdb, but maybe I was lucky.
<lool> lucid's latest
<lool> 7.0 helped, but it's still crashy and frequently fails finding backtrace
<lool> In this case, I get either a corrupted backtrace or an infinite loop
<dmart> hmmm, is there any way you can reproduce the crash?  I often get no backtrace though.  I wondering whether some components are built in a way which nukes the backtrace; or maybe there's some broken unwind info support in gdb.
<lool> The crash only happened one time out of 6 or so, but perhaps I will be able to reproduce it
<lool> I suspect the versatile kernel under qemu might be having some issues of its own which don't help gdb
<dmart> Maybe you can catch it with nested gdb
<lool> dmart: So you gdb gdb?
<dmart> I'm sure I've managed to do this in the past.  gdb has special support for this.
<lool> Ok; never tride this
<lool> A simple g_slice checks works
<lool> Folks, the glib atomics patch was removed in january
<dmart> Hmmm, maybe we need it back in?
<lool> I suspect we do, that might explain my issue
<dmart> Anyway why it was pulled out?
<lool> Is https://bugs.launchpad.net/bugs/491342 the correct reference?
<ubot4> Launchpad bug 491342 in glib2.0 (Ubuntu) (and 1 other project) "assembly fails to build on armel/lucid (affects: 1)" [Critical,Fix released]
<lool>   * debian/patches/70_glib2.0-gatomic-arm.patch:
<lool>     - dropped since that patch was added without details nor reference
<lool>       to a launchpad or upstream bug and it's not clear if it's still required
<lool>       now with the change done upstream recently
<lool> Seb, who removed the patch, had fixed it when syncing 2.23.1-1 over:
<lool>   * debian/patches/70_glib2.0-gatomic-arm.patch:
<lool>     - change to fix the build for armel
<dmart> If the change is upstream, it shouldn't be needed; maybe take a look at the patch and make sure the relevant changes are in the code?
<lool> Yes; glib wouldn't build without it, would it?
<dmart> Probably not... it was a swp issue
<lool> It built on armel
<lool> https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491342 was forwarded at https://bugzilla.gnome.org/show_bug.cgi?id=603780
<ubot4> Launchpad bug 491342 in glib2.0 (Ubuntu) (and 1 other project) "assembly fails to build on armel/lucid (affects: 1)" [Critical,Fix released]
<lool> Which points at https://bugzilla.gnome.org/show_bug.cgi?id=531902 which is closed
<ubot4> Gnome bug 531902 in general "Use GCC atomic buildins for g_atomic*" [Enhancement,Resolved: fixed]
<lool>   Bug 531902 -  Use GCC atomic buildins for g_atomic*
<lool> Summary: 	Use GCC atomic buildins for g_atomic*
<ubot4> lool: Error: Bug #531902 not found.
 * persia pets ubot4 for trying
<dmart> :)
<dmart> Looks like it was fixed upstream, so long as ubuntu's package is now based on the new enough version.
<lool> It's merged in out glib2.0 ubuntu package
<lool> checking whether to use assembler code for atomic operations... checking whether GCC supports build-in atomic intrinsics... yes
<dmart> looks good
<dmart> Perhaps your problems are caused by something else...
 * dmart has do disappear for a bit
 * dmart also can't spell
<lool> I looked at the testsuite, there is one failure trying to create files in the non-writable home, another one on threadpool-test
<lool> and there might be more since it doesn't complete
<lool> slice-test does pass though
<lool> So it could also be a gtk+ issue
<lool> In gtk+, the only failing test is abicheck; again the testsuite might not be running all tests
<ogra> lool, it couls also be a codesourcery issue, lets wait for the actual archive build of versatile
 * ogra still thinks its kernel related
<lool> I have the same issues with my own cross-gcc
<lool> Which is based on a relatively recent FSF tree
<ogra> hmm
<lool> Hmm it's not the same error as with ldconfig
<lool> ldconfig was on fasttop, gtk+ is on !prev
<ogra> lets be patient and see what an in-archive kernel brings us :)
<lool> There's an experimental-malloc in eglibc which takes another code path
<lool> MALLOC_CHECK_=0 G_SLICE=debug-blocks doesn't catch the error
<lool> Ah slice-test actually fail under my kernel
<lool> dmart, ogra: Could one of you try on real hardware with lucid userspace?
<lool> To check whether it's a toolchain or kernel regression
<ogra> lool, i have no issues at all on imx51
<ogra> since weeks
<lool> just build slice-test from glib2.0
<ogra> i'm not sure i can get to that today but will do so if nobody else does
<ogra> my babbage is fully swamped today
<dmart> I'll have a go... what's the easiest way to build just the affected test?
<lool> dmart: unpack memchunks.c and slice-test.c from glib2.0's tests/
<lool> dmart: And then basically gcc `pkg-config --cflags glib-2.0 gthread-2.0` -c memchunks.c
<lool> dmart: And then basically gcc `pkg-config --cflags glib-2.0 gthread-2.0` -c slice-test.c
<lool> dmart: And then basically gcc -o slice-test *.o `pkg-config --libs glib-2.0 gthread-2.0`
<lool> (Sorry for the noise)
<lool> So ./slice-test 1 c 100 works and ./slice-test 1 c 1000 fails
<dmart> ok, I'll let you know what happens.
<lool> It works up to 512 and fails starting at 513
<lool> dmart, ogra: What's the kernel memory allocator on your kernel?
<lool> It's SLAB on versatile
<lool> I think ARM requires SLAB anyway
<dmart>  /boot/config.blah says CONFIG_SLUB=y
<ogra> yeah
<dmart> dunno whether that's better though
<lool> dmart: There was a recent post of slab versus slub on kernel-team@lists.ubuntu.com
<lool> I don't know whether it's better or worse, but I care that it works or not   :-)
<lool> versatile_defconfig has SLAB=y instead
<lool> lpia, i386, amd64 and ports have SLUB=y; pretty much only versatile has SLAB=y
 * dmart is still updating his fs
<dmart> The versatile is probably derived from the ARM kernel trees, which tend to use a more traditional/embedded style config (for whatever reason)
 * lool tries turning on SLUB
<lool> Ok; that worked, let's see if I can build a working kernel with it
<lool> it built, but for some reason I'm missing disk drivers; /me tries again
<lool> So it still fails
<lool> I have CONFIG_SLUB=y
<lool> Same symptoms
<lool> dmart: Did you manage to test on real hardware?
<dmart> not yet... trying to do too many things at the same time...
<dmart> argh, more update problems
<lool> What's the issue?
<armin76> ricing
<dmart> Any idea what's causing the contents of the archive to be broken at the moment?  I get a load of conflicts
<lool> dmart: I don't have that
<lool> dmart: Perhaps some packages you have are missing on armel; I have a minimal chroot
<ogra> mono
<lool> Yeah I was about to mention it
<lool> Currently mono-runtime is older than mono-gac
<ogra> mono breaks the world and the desktop team made half the world depend on it
<lool> So you can't install mono or ubuntnu-desktop
<ogra> so lots of stuff is outdated
<ogra> asac, is working on the mono ftbfs
<dmart> Hmm, I didn't even find that among the conflicts.  But trying to install/upgrade ubuntu-desktop is certainly broken right now.
<ogra> right
<ogra> laincpad-integration and all the indicator- stuff are broken
<ogra> anything that uses either will likely fail to install
<dmart> Is that really all caused by mono?
<ogra> yes
<dmart> argh
<ogra> most of the indicator bits hard depend on mono now
<lool> Oddly it took 2 hours to build in karmic and has been building since 3 hours in lucid
<ogra> as well as LP-integration
<lool> Looks like the build hanged in configure
<ogra> oh, and nautilus depends on mono as well now
<asac> mono is a mess
<asac> it opens zillions of files ... but only on arm
<lool> asac: Does the buildd output looks normal to you?
<ogra> lool, forget about the buildd :)
<lool> ogra: ?
<asac> lool: what do you mean?
<ogra> for now we'd be happy to be able to build on sane HW we have full access to
<asac> lool: i tried it locally and found that we hit the 1024 open files barrier
<lool> asac: https://launchpad.net/ubuntu/+source/mono/2.4.3+dfsg-1ubuntu1/+build/1477421
<asac> lool: no. that doesnt look normal
<dmart> lool, looks like a won't have time to try and reproduce your issues right now
<asac> and isnt what usually happened
<lool> dmart: Ok; thanks
<lool> I'd love to know whether this is kernel specific or not
<dmart> sorry
 * ogra smells one of the regular buildd segfaults
<asac> yeah
<lool> Perhaps someone else could try it on real hardware with up to date lucid?>
<ogra> asac, you gave it back today, didnt you ?
<asac> i tried it on real hardare
<asac> same issue ... open files barrier
<asac> i am now going to debug that
<ogra> asac, i think lool means the qemu issue
<asac> unfortunately i trashed the build tree
<lool> asac: Did you complete a build after bumping the open file limit?
<asac> oh
<asac> sorry
<asac> lool: no it failed later on jocote
<lool> Yeah, I have an issue with glib under qemu
<asac> havent tried to finish it here ...
<lool> asac: Ah so no mono anytime soon
<lool> I wanted to look into the double binfmt issue
<asac> will do that after confirming for the mono guy which mono it is
<asac> which files are kept open
<lool> config.status: creating mono/arch/s390x/Makefile
<lool> make: *** wait: No child processes. Stop.
<lool> make: *** Waiting for unfinished jobs....
<lool> make: *** wait: No child processes. Stop.
<lool> Session terminated, killing shell... ...killed.
<ogra> yes, we see frequent random segfaults on the buildds since a while
<asac> thats not the real issue. most likely just random buildd bustage as ogra said
<lool> ogra: Is there a bug about the mono-runtime binfmt format that doesn't work with qemu?
<ogra> no, there are plenty in debian i think
<ogra> they all point to syscall 242 though which is nonsense
<ogra> get_sched_affinity()
<lool> ogra: could you file a launchpad bug?
<ogra> lool, i filed the one on the possible use of binfmt_ vs non binfmt_
<lool> What is that?
 * ogra cant remember the number
<ogra> lool, bug 427863
<ubot4> Launchpad bug 427863 in linux (Ubuntu) (and 1 other project) "binfmt allows breaking out of chroots due to not respecting namespaces (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/427863
<lool> ogra: That one is blocked on information on your side
<lool> Upstream and Kees both asked you for more info
<ogra> which i dont really have time for to gather atm
<lool> Since September?
<ogra> yes
<ogra> dmart, btw, do you use update-manager ? my upgrade works fine here just removes some stuff i'd rather keep, but still
<dmart> No, that was via apt-get dist-upgrade.  I should probably switch to apt-get upgrade so it doesn't unexpectedly uninstall half the system :P
<ogra> you are not using netbook yet i guess
<ogra> for me only two indicators, rhythmbox, nautilus and the netboot-meta package are removed
<ogra> stuff i can live with until it comes back
<lool> Gah karmic userspace doesn't boot with devtmpfs
<lool> This so sucks
<suihkulokki> iirc the problem with mono in qemu is that it uses boehm gc which reads /proc/self/maps
<lool> suihkulokki: that's a good point
<lool> suihkulokki: Do you have any clue on the slice-test issues I have (see above)
<lool> It's under qemu-system-arm with a versatile kernel, not qemu-arm-static
<suihkulokki> havent seen any such issues
<lool> suihkulokki: You can run gtk+ apps fine under qemu-system-arm/versatile?
<suihkulokki> well, haven't tried versatile for ages
<lool> You're using OMAP?
<suihkulokki> but on omap2/omap3 no problems with our gtk
<ogra> is omap stable already ?
<lool> yeah, I've been tempted to switch to OMAP kernels for qemu
<lool> suihkulokki: So which tree do you use to run qemu/omap?  plain upstream, or do you need linux-omap for qemu too?
<ogra> is there enough in upstream to make use of it for qemu ?
<suihkulokki> so far I've just used linux-omap kernels.
<lool> suihkulokki: You're using the maemo OMAP3 qemu support?
<ogra> sad, no distro option for us atm
<lool> I see some commits from you, so I guess you do  :)
<lool> You probably develop it too
<suihkulokki> yep
<suihkulokki> ogra: ...didn't stop you from shipping mx51 and dove kernels ?
<ogra> suihkulokki, no, but for other arm stuff we can only refer to mainline, for these two arches the kernel team made explicit exceptions
<ogra> s/arches/subarches/ :)
<persia> Does mainline linux-omap work on qemu cleanly?  Might be easier to align, rather than chasing -versatile.
 * ogra files bug 519398
<ubot4> Launchpad bug 519398 in oem-config (Ubuntu) "oem-config with debconf frontent goes into endless loop (affects: 1)" [Undecided,New] https://launchpad.net/bugs/519398
<ogra> finally some progress ...
<ogra> seems its actually an oem-config bug
<ogra> phew
<persia> Can you replicate with a normal desktop install, or does it only happen with rootstock?
<ogra> no idea, i wont do any normal desktop install atm
<ogra> since i a) dont have a spare desktop machine to test on and b) it takes extra time :)
 * ogra wonders why others sponsor fixes to rootstock ... why dont file people bugs so i can sponsor it :P
<ogra> persia, though given that the debconf frontend isnt used on desktops it would have to ba a server install i guess
<ogra> *be
<persia> Does -server support oem-config?
<ogra> yes
<persia> Aha.  Make them do the testing on !armel :)
<ogra> you can do oem server installs nowadays apparently
<ogra> how without HW and broken qemu ?
<ogra> i guess they are using it very rarely :)
<ogra> probably even only testing it on x86 for milestones
 * ogra cant belive there is a thread in ubuntu-users about /bin/flase being to big
<persia> I thought they had working kvm.
<ogra> *false
<persia> heh :)
<ogra> its like 50 mails already
<ogra> nearly beats the "OMG OO.o was dropped by canonical" one
<ogra> rm /
<ogra> oops
<persia> Um, did you really mean to run that locally?
<persia> That command is usually followed by a ping timeout
<ogra> heh, no i hit tab and was on an SD card subdir in another term :)
<lool> haha
<lool> the slice-test issue doesn't affect karmic
<lool> So it's either a toolchain regression or a qemu bug with thumb2
<lool> suihkulokki: ^  :)
<lool> suihkulokki: BTW do you use thumb2?
<lool> I know you use NEON heavily, but I'm not sure you went through the thumb2 pain yet
<lool> It's eglibc
<lool> Well upgrading it breaks things at least
<ogra> funny that we dont see it on real HW
<lool> It might be a bug in qemu or linux/versatile with thumb2
<ogra> yeah
<ogra> i find versatile most likely
<ogra> we just patch the CPU naming but nothing of the instruction set at all
<ogra> anyway, break before the call
<cwillu_at_work> there isn't a thermal sensor on the beagle is there?
<ogra> use your thumb ?
<ogra> :)
<cwillu_at_work> I can't log my thumb :p
<cwillu_at_work> also, when setting mpurate=720, how does one also bump the voltage, or is the recommendation to do that obsolete?
<therealgalen> Hey, I'm looking for vendors who produce high-performance ARM CPUs for use with Linux... who's out there?
<cwillu_at_work> like, ti?
<ojn> therealgalen: depends on what you consider high performance to be. everything is relative.
<ogra> freescale, marvell, qualcomm
<therealgalen> I'll get clearer
<therealgalen> I'm looking for ARM CPUs with PCI-Express support. Examples: Marvell 88F6282 (1.6-2 GHz), Marvell MV78200 (800 MHz - 1 GHz dual core), Cavium Networks CNS3420-700 (700 MHz dual core)
<therealgalen> ojn, ogra, cwillu_at_work: does that give you a better idea the performance range I am looking at?
<ojn> therealgalen: Marvell is the only provider with pci-express solutions to date, I think. most others are targeting mobile devices where there's less need for high-performance interconnects.
<therealgalen> ojn: Cavium has PCI Express too
<therealgalen> I'm trying to find if there are any others
<ojn> Cavium makes ARM processors? I thought they were mips
<therealgalen> Without wading through the 300+ ARM licensees
 * ogra has only seen marvell boards with PCI 
<ojn> ogra: dove has pci-e
<ogra> and i'm not even sure these ones were PCIe
<therealgalen> hey, a few starting points are better than 300+ :)
<therealgalen> ojn: what is dove?
<ojn> therealgalen: if PCI-e is a hard requirement, and ARM is a soft requirement, take a look at Freescale's PPC offerings as well.
<ojn> therealgalen: The eval board for marvell's armv7 chip
<therealgalen> ah
<therealgalen> ojn: is it at all price competitive?
<ojn> therealgalen: I have no idea where any of the vendors price their parts
<therealgalen> the CNS3420-700 costs like $17/unit in 1k quantities
 * cwillu_at_work should stop asking beagle specific questions in #ubuntu-arm
<cwillu_at_work> ogra's tongue-in-cheek response makes sense now :)
<therealgalen> man, powerpc...
<therealgalen> a blast from the bast
<therealgalen> *past
<ogra> cwillu_at_work, nah, there are ,many people using our userspace on beagle :)
<cwillu_at_work> ogra, I know, I'm one of them :p
<cwillu_at_work> I just didn't realize I was in this channel:  I don't expect hardware questions to get good answers here :p
<therealgalen> i'll just take whatever i can find, haha
<ogra> cwillu_at_work, pfft
<cwillu_at_work> ogra, you told me to use my thumb when I asked about the thermal monitor :p
<ogra> well its a reliable methot to measure ... at least in the blister/no blister area of precision ;)
<ogra> *method
<ogra> cwillu_at_work, but you are right, i could tell you more about imx51 than omap currently my beagle B3 is sitting on the shelf collecting dust
<therealgalen> ojn: freescale's CPUs are very expensive!
<therealgalen> at least the PPC line
<persia> ogra: Did you ever find a good way to suppress the extensive "qemu: Ubsupported syscall:" lines?
<lool> persia: Implement them?  :)
<persia> lool: Well, that works too.  ogra was talking at some point about some way to collect them and report each one only once or something.
#ubuntu-arm 2010-02-10
<cooloney> asac: i think you are in the email loop of my ethernet ping email to fsl
<cooloney> i CCed you and oliver
<asac> cooloney: hmm. ok
<asac> thanks
<cooloney> asac: no problem. you work so late, are you still in portland TZ?
<asac> hehe
<asac> no
<asac> off now ;)
<asac> had to fiddle with specs
<cooloney> asac: good night,
<cooloney> lool: just dowloaded your zImage in my qemu, it works.
<cooloney> lool: but my zImage built from latest lucid tree, fails to mount root device
<lool> cooloney: Ah
<lool> cooloney: Did you build it from the lucid source package, or the lucid tip?
<lool> cooloney: Could you try http://people.canonical.com/~apw/misc/arm/linux-image-2.6.32-13-versatile_2.6.32-13.18~masterapw1_armel.deb ?
<lool> cooloney: unpack the .deb with dpkg-deb -x linux-image-2.6.32-13-versatile_2.6.32-13.18~masterapw1_armel.deb linux-versatile/ or something like that
<lool> then use linux-versatile/boot/vmlinuz*
 * apw looks blearily
<persia> apw: Just an incidental strike because you host kernel packages directly
<cooloney> lool: i think, i messed up my build system.
<lool> cooloney: Could be
<cooloney> lool: i rebuilt the kernel from latest lucid
<cooloney> lool: it can find the rootfs now
<cooloney> lool: thanks
<apw> cooloney, pretty sure i've not changed the tip significantly since that build
<lool> I was thinking we should build daily rootfs-es just like we have daily UEC images
<persia> ogra was talking about having a way to script rootstock to do just that.
<persia> There's still the issue of kernel feature support, etc. but that's separable.
<lool> persia: What issue?
<lool> I was thinking of reusing their image building infrastructure actually
<lool> patching vmbuilder to create armel images
<lool> The only major difference is bootloader on hard disk versus kernel on host
<lool> I'd love to have kexec working to hide this fact completely
<persia> Image build infrastructure also works.  The main issue with kernels is that some of our userspace depends on features not available in some kernels.
<persia> By using the distro kernel (or rcn-ee's kernel), one ends up with the features.  Otherwise, one may not.
 * persia doesn't know about other kernels)
<lool> persia: Oh yeah; in theory we should be using one in-disto kernel for each image build
<lool> persia: In practice this will only be possible with lucid
<lool> For <= karmic, perhaps we can provide backports?
<lool> I'm not interested in redoing the work on an older kernel, but it would probably be doable to provide backports for karmic in a PPA or simply to use lucid kernel (a bit ugly though)
<persia> Will it be possible with lucid?  We're nearing FF, and I haven't seen that stuff land yet.
<lool> I managed to boot karmic userspace with the lucid versatile kernel BTW
<lool> persia: Well it's in the git tree
<lool> So hopefully this will be uploaded soon
<persia> Ooh!  That's excellent news.
<lool> Besides, it's not like a versatile is a new feature; we're just fixing it  ;-)
<lool> The biggest problem ATM is that lucid glibc breaks gtk+ apps
<persia> heh.
<persia> That certainly has some potential for regression.
<lool> I don't think I will be able to research this; I mailed doko to ask whether he had any advice on this, or on trying out backports / rebuilds of eglibc, but it's a best effort thing
<lool> I found a workaround to the glibc issue, but I don't know whether it's 100% correct
<lool> Either set G_SLICE=always-malloc, or MALLOC_CHECK_=0
<lool> Setting G_SLICE is safe, I'm less sure about the second one
<lool> It would be nice if someone could chase that bug; it might turn out to be a toolchain, or linux or qemu or glibc bug
<persia> Doesn't that disable checking for available memory when allocating?
<lool> MALLOC_CHECK?
<persia> Yeah.
<lool> Don't think so, I think it disables the sanity checks in glibc which do things like checking around your buffer, or checks for double free etc.
<lool> It's more of a security feature as I see it
<persia> Does Qt also break, or just gtk+?
<lool> Either it's broken, or there is a really dangerous bug, I can't tell
<lool> I don't know about Qt, didn't try
<lool> That's why I would personally start with only setting G_SLICE as a workaround
<lool> Because that just changes the memory allocator of glib with another safe one
<persia> I was just thinking of ways that one might determine whether it's a gtk+ or glibc issue.
<lool> I don't think it's a glib issue because it's only in qemu/versatile
<lool> But I could be wrong
<lool> It might be that it gets the toolchain calls wrong
<lool> Also, it only happens with a particular request size
<ogra> lool, why are you duplicating work ?
<lool> ogra: Sorry?
<lool> We discussed a lot of stuff above, so please be more specific
 * persia suspects it's a rootstock vs. vm-builder things.
<ogra> right
<ogra> lool, you seem to reimplement exactly what will be in rootstock by A3
<lool> Err I could argue that rootstock is a duplication of vm-builder
<lool> (Which itself duplicates part of d-i, but that's a bit far fetched)
<ogra> lool, well, why not use vmbuilder as a backend then, the plan for rootstock is to actually use it for image building with L+1
<lool> I was proposing to reuse the vm-builder daily image build infrastructure instead of coming up with a new one for rootstock
<ogra> and i'd love (and was hoping) to have your help on the code ... thats why i gave you full commit access to the branch etc
<ogra> if you feel vmbuilder is a better backend feel free to change it
<lool> You effectively received help from me before doing that
<ogra> starting a second project from scratch feels like a huge waste to me
<persia> The backend now is debootstrap + apt-get?
<ogra> yes
<ogra> plus oem-config for the system setup
<lool> How is it from scratch??  vm-builder has been around for much longer than rootstock; I mentionned supporting armel even before you started rootstock
<lool> I also discussed the design issues with you at the Dublin sprint
<lool> Why reinventing "set hostname, set password" etc. was not a good reuse of our debconf stuff
<ogra> thats why oem-config is used now
<mbligh> which bootloader do you generally use for ARM?
<ogra> whatever bootloader the board needs :)
<ogra> it really depends on the board
<lool> mbligh: hey Martin; we use either U-Boot or RedBoot
<lool> mbligh: For dove boards, we only have U-Boot support from the vendor, for imx51 boards we get both RedBoot and U-Boot support with different features
<mbligh> ok, any idea where the config file lives / what the flashing procedure for a new kernel is?
<mbligh> grep -r vmlinuz /etc turns up nothing
<lool> mbligh: That depends of the board; where is the kernel stored?
<lool> Is this qualcomm?
<mbligh> it's in /boot
<mbligh> mmm. can't say ;-)
<lool> Qualcomm has multiple stages of bootloaders, so it's a tad complex, and there are signatures at various levels
<lool> mbligh: Recent versions of U-Boot and RedBoot can load files such as kernels or boot instructions from a filesystem
<lool> I would expect that's your case, but perhaps only the kernel lives on a fs
<lool> mbligh: Check your BSP docs; there's certainly some info on writing your own kernel
<ogra> and surely some doc about the used bootloader
 * ogra hands asac a beer some chips and and https://edge.launchpad.net/ubuntu/+source/mono/2.4.3+dfsg-1ubuntu2/+build/1495864
<lool> ogra: Does mono actually work properly in the recent versions?
<ogra> lool, no idea, it didnt build until some mins ago, the last version we had came from karmic into lucid
<asac> lool: i think a testsuite is run in the build
<asac> and the mcs compiler also is mono ...
<asac> maybe it doesnt work fully, but it probably should work somewhat
<lool> asac: You might recall the weird banshee bugs
<ogra> which are still open :)
<asac> no. that was before my time. i wanted to check if it now is better
<asac> i think we might want to disable jit on arm
<asac> --with-jit=no
<asac> i will try that in a ppa if we still have the problems
 * ogra is happy as long as the apps we ship are installable at least ...
<ogra> everything beyond is a bonus
<asac> ogra: will you give some love the ftbfs list and give them back for a bit ?
<asac> i have a call and would check afterwards what can be retried
<armin76> dmart: get me a mwc2010 pass!
<ogra> as soon as its published, yes
<asac> thx
<ogra> but publisher will still take a while
<lool> ogra: http://people.canonical.com/~ogra/arm/build-arm-rootfs was an early version of rootstock, right?
<ogra> lool, yep
<lool> I'll drop references to it from the wiki; I don't think it's a good idea to still point people at it
<ogra> lool, btw, do you think the lucid versatile kernel could work with jaunty qemu ?
<ogra> lool, where will you point to ?
<ogra> there was no rootstock in jaunty and i havent tested it on jaunty since ages, build-arm-rootfs works for jaunty users
<lool> ogra: it would be nice if you could test the new versatile kernels with jaunty qemu-system-arm
<lool> I will point to rootstock for now
<ogra> ok
<lool> It would also be nice to provide backports of rootstock
<ogra> i will do so for karmic
<ogra> not sure for jaunty since it wasnt available there
<lool> I personally would prefer supporting a single tool with the latest Ubuntu release and then perhaps investing in backports rather than supporting different tools for multiple Ubuntu versions
<lool> What wasn't available in jaunty?
<ogra> rootstock
<lool> I was thinking of backports, so we could make anything available anyway
<ogra> yeah, thats surely possible
<lool> e.g. backports of debootstrap, rootstock, qemu-kvm, linux
<persia> can rootstock backport?  I thought it depended on features not available until karmic.
<ogra> persia, the code is that bloated because it still works without qemu-arm-static
<persia> debootstrap is commonly backported, and tends to go through smoothly.  linux is almost never backported: that probably needs a PPA.  I'm unsure about qemu-kvm.
<ogra> qem-system-arm is all that counts
<ogra> and that used to work in jaunty
<lool> Concerning linux, it's probably the one we can avoid backporting in any case since it's typically not installed on the system
<ogra> the question is if the new versatile will work
<lool> It's more of a companion/helper to the rootfs
<ogra> i dont want to keep the different kernels in the script but unify on the archive version
<persia> So just get debootstrap backported (can be very quick if people are willing to test), and then backport rootstock.
<ogra> right
<ogra> but its essential to know if the kernel works with qemu
<ogra> i want to reduce the bloat of the script if possible
<ogra> given that all the lucid features add a lot of extra code
<persia> Well, backport the current version to karmic and jaunty, and then trim it down for lucid fowards.
<ogra> i wonde if i should drop all the locale handling ... oem-config can care for that
<ogra> in case of the debconf frontend i could even drop the tasksel stuff
<ogra> not sure about the gtk/qt UIs
<Hoonse> hi guys
<persia> Hey Hoonse
<lool> Hi
<Hoonse> is anyone here who set up ubuntu on the beagleboard sucessfully? =)
<ogra> several people i think
<persia> There's some instructions on the beagle wiki that are up to date
 * persia hunts
<ogra> Hoonse, http://elinux.org/BeagleBoardUbuntu
<persia> Yeah, that's it :)
<ogra> there should even be test images
<Hoonse> yeah i read this already but for this you have to compile ubuntu for your own right?
<persia> No.
<Hoonse> no?
<persia> You have to create your own rootfs only.
<persia> But you can do that from precompiled binaries.
<Hoonse> the rootfs is the "folder tree" ?
<lool> Yeah
<persia> roughly, yeah
<lool> the bits and bytes!
<ogra> err, that wikipage even has ready made images
<ogra> you dont need to compile anything :)
<Hoonse> can i use for example the synaptic packet manager for installing things?
<lool> Some people actually believe the rootfs is the soul of your board
<Hoonse> lol
<Hoonse> "the thing where the magic happens" =)
<ogra> Hoonse, yes, you can use synaptic/apt-get or aptitude
<persia> Most stuff should just work.  IF something doesn't work, we'd appreciate help getting it fixed :)
<Hoonse> but i think the "normal" programms that you use for the pc arent working. only a few right?
<persia> Anything that works for any other architecture *should* work.
<persia> There are a couple things that just won't, like WINE, but those are exceptions.
<Hoonse> oh my god that would be great...
<persia> That's the point :)
<Hoonse> i think i only need a ftpd a httpd and a java runtime env...
<ogra> persia, if lool ever fixes qemu to run on armel you could theoretically run wine in qemu-user *g*
<persia> ogra: That's advanced hackery though.  The reason WINE doesn't work is that there's a check in the build scripts that gets mad if it's running on armel.
<Hoonse> i think i will try this now =) the only problem is that my only monitor is plugged into my beagle...
<persia> WINE does the same thing for powerpc, which annoys me, because I used to run windows on a powerpc.
<ogra> persia, i men the x86 version of wine :)
<ogra> *mean
<persia> ogra: And that's the advanced hackery bit :)
<Hoonse> can i do this via ssh plugged the mmc card into my server?!?
<ogra> just some binfmt magic :)
<persia> Hoonse: Most people create the rootfs on their host workstation.  If you're just doing a server, you might try installing openssh server, and then logging in over ssh and using DHCP to set the IP, rather than connecting a monitor.
<persia> ogra: The binfmt magic isn't the hard part.  The hard part is getting the binary installed in the first place.
<ogra> details :P
<persia> heh
 * persia watches the publisher impatiently
 * ogra is eager for the first blog entries from people running IE under wine on armel netbooks *g*
<ogra> probably in 12.04 or so :)
<rcn-ee> ogra, did you catch the blog/youtube where someone ran max os (powerpc) thru pear on a n900?
<rcn-ee> max/ mac...
<ogra> no, cool :)
<rcn-ee> http://www.engadget.com/2010/01/31/mac-os-x-10-3-installed-on-nokia-n900-via-pearpc-barely-usable/
<ogra> haha, i should try that on mine :)
<ogra> lool, you missed to remove a sudo qemu call :)
 * ogra fixes
<ogra> OMG ...
<ogra> i just ran rootstock -s gdm ...
<persia> And it worked?
<ogra> that installs half the desktop
<persia> Well, yeah.
<jds_> so i just did the formatting stuff for the mmc card... can i take the "normal" MLO uImage and u-bin files from the angstrÃ¶m image or do i have to take "special" files?
<ogra> why the heck does gdm pull in nautilus?
<Hoonse> u-boot not u-bin sorry
<ogra> arent they linked from the wiki ?
 * ogra thought they are
<persia> ogra: gnome-session is the link.
<ogra> persia, i thought there was a shrunk down gnome-session
 * persia checks
<ogra> gnome-session-core or -bin or so
<persia> Right. gnome-sessoin-bin
 * persia looks again
<persia> I don't see it immediately then.
<ogra> i hope my image size is enough ...
 * ogra doesnt want to do that again ... its just to test the logic for installing oem-config-gtk if gdm is installed
 * persia invokes the heavy artillery
<ogra> i think i'll forbid ll useradd stuff in rootstock in favor of oem-config
<ogra> up to now you can still use --user --password ...
<ogra> can anyone tell me a reason why to keep it ?
<ogra> (gievn its really insecure)
<rcn-ee> ogra, what would oem-config bring up on first boot then? would it require a gui? i'm thinking console installs...
<persia> rcn-ee: There's a debconf front-end
<ogra> it brings up a debconf ui
<ogra> looks like debian-installer
<ogra> but only asks for username, passwd, language and timezone
<rcn-ee> okay, that works.... wasn't sure.. ;)
<persia> ogra: I think it's an issue with dependency resolution.  I'm *definitely* getting it through gnome-panel->gnome-session->nautilus
<ogra> and then removes itself
 * persia blames the lack of versioned provides
<Hoonse> in the wiki there are "usefull packages" listed what should i do with dem?!?
<persia> Hoonse: Install them on your workstation :)
<rcn-ee> Hoonse, you would install them thru the '--seed '
<ogra> or afterwards in the booted system
<Hoonse> yeah but i need at least the wifi drivers do get this thing to the www
<rcn-ee> the key ones are linux-firmware and wireless-tools for wifi devices... since ubuntu's repo gives us the firmware...
<Hoonse> please excuse my strange english skills... normally i speak german =)
<ogra> your skills are fine ...
<Hoonse> lol thanks
<Hoonse> when i spt-get install the xfce4 has this any affect on my PC UBUNTU system?!? i am a little afraid right now =)
<ogra> no, it wont touch your host system
<Hoonse> hmmm the rootstock script is running... everything seems awesome =)
<ogra> it will take a while, get a beer and some dinner :)
<Hoonse> =)
<Hoonse> when everything is done i want to put the beagle in my roomba vacuumcleaner with a webcam and wifi. prog a java tool or something you can enter via a web browser to controll the roomba...  i think i will create a domain like vacmyhouse.com or something so that people can clean my home =)
<ogra> heh
<cwillu_at_work> ooh, rcn-ee
<cwillu_at_work> I has kernel config options for you!
<rcn-ee> hey cwillu_at_work
<cwillu_at_work> if only my server wasn't wedged right now :p
<rcn-ee> ouch... i know that feeling, it's my day off and i'm rotating new harddrives on the beagle farm.. .;)
<Hoonse> hmmm my girlfriend is screaming right now... i think i should go to her before she is making a scene AGAIN... -.- brb when script is finished^^
 * ogra wonders what hapens in ubuntu-system-service's unpack phase that reliably locks up his VM
<persia> strace it :)
<ogra> i cant
<ogra> its inside a VM
<persia> And you can't install strace in the vm, and strace dpkg while unpacking?
<ogra> i just want to get that codepath tested damned
<ogra> that would require any kind of option to get *inside* the VM
<ogra> the VM is spawned by rootstock as backend
<ogra> i cant easily get to it
<ogra> i suspect its the bug that lool just reasearched (and i think fixed too) with libc
<ogra> it simply takes 40min to get to that point, that the annoying part ... but i think i'll kill the build now
<persia> Ah.  Yeah.  It would be painful to untangle that sufficiently.
<Hoonse> holy sh this takes really a while...
 * ogra just goes back to the other kernel and tries again
<ogra> Hoonse, yes, under which host release do you run it ?
<Hoonse> i think 9.04
<ogra> yeah, that was really slow
<ogra> karmic (9.10) wa a lot faster
<Hoonse> seems so =)
<Hoonse> hmmm i got some warnings... is this normal?
<persia> Hoonse: What sort of warning?
<Hoonse> Setting up wdiff (0.5-18) ...
<Hoonse> install-info: warning: maintainer scripts should not call install-info anymore,
<Hoonse> install-info: warning: this is handled now by a dpkg trigger provided by the
<Hoonse> install-info: warning: install-info package; package wdiff should be updated.
<ogra> depends on the warnings :)
<Hoonse> this sort of...
<persia> Hoonse: You can safely ignore those.  Those are bugs in the packages being installed.
<Hoonse> great its cleaning up =)
<Hoonse> aaaand done yeah
<persia> If you're feeling especially adventerous, you can try to fix the bugs, but I'd suggest leaving them alone unless they are causing you issues.
<asac> ogra: how is the mono give back going?
<asac> someone needs to take over? whats the status?
<ogra> asac, i simply gave back everything
<ogra> lest see what sticks to the wall and what falls off
<ogra> *lets
<asac> right :-P
<ogra> i'll do a second run tomorrow
<asac> do you get emails for give backs?
<asac> hmm. i think so
<ogra> yep
<ogra> for failures at least
<asac> coool. then be accurate ;)
<asac> talk to you tomorrow
<ogra> i'll check the ftbfs list tomorrow morning and we'll see
<persia> One only gets give-back fail emails if one was an uploader.
<ogra> ejoy your evening
<ogra> persia, well, the ftbfs list will have them
<persia> Indeed.
<ogra> most of it still sits in the queue
<ogra> gnome-sharp2 is currently building
<lool> ogra: I wasn't done with the wiki page, just went for dinner
<ogra> ah
<therealgalen> does anybody know of any ARM CPUs with compression offload or accelleration?
<Hoonse> are these boot fixup for 9.10 to do or not (i am talking from the wiki page =))
<rcn-ee> Hoonse, just 9.10 for the moment... (unless you've installed a backup battery on your c3/c4..)
<rcn-ee> lucid (10.04) when released, hopefully won't require the fixup.. ;)
<Hoonse> k then i really should do this... =)
<persia> therealgalen: Lots of them have DSPs available, but you'd have to check carefully to see if any of those vendors have kernels that do that sort of offloading.
<cwillu_at_work> rcn-ee, who doesn't install the battery on a c3/c4?
<rcn-ee> me.. ;)
<rcn-ee> and i have 3 other's beagles couple bx's and c2 with out the battery hookup..
<ogra> rcn-ee, whats that fixup ? anything we can pull into the distro to help ?
<rcn-ee> it's the util-linux... missing rtc date, you had mentioned a fix was heading for lucid...
<ogra> ah, k
<rcn-ee> my fingers are crossed that debian picks that up the same fix for squeeze too... then no one would have noticed it was an issue... ;)
<Hoonse> hmmm there is no ./tmp/etc/e2fsck.conf file on my image ?!?
<rcn-ee> Hoonse, that's correct.. by default the file doesn't exist...
<rcn-ee> by default everything works perfectly.. ;)
<Hoonse> i have to make it right?
<rcn-ee> correct...
<Hoonse> thanks
<Hoonse> when i try to umount the ext partition if the mmc card it says the device is busy but the "writing led" isnt blinking... i am afraid to all again when i just stick it out...
<Hoonse> -.- i was ON the partition...
<Hoonse> sorry
<Hoonse> so guys its finished
<Hoonse> please cross your fingers =)
<Hoonse> plugged in...
<ogra> nothing to cross ... it will just work :)
<Hoonse> woooohoooo i see tux on the screen *muahahahaaa*
<Hoonse> holy sh... it works!!!
<ogra> :)
<Hoonse> thanks guys!!!
<Hoonse> hmmm i just got a terminal on a blue backscreen?!?
<Hoonse> but the login was at a gui...
<persia> Hoonse: Well, what desktop environment did you install?
<ogra> i.e. what did you specify for the -s option
<Hoonse> xfce4?!?
<rcn-ee> ahh Hoonse, by default it goes to 'xterm' you need to change it in the drop down on the bottom...
<rcn-ee> (at the login screen)
<Hoonse> k *reboot*
<rcn-ee> 'exit' should do it..
<Hoonse> yeah thats the other option =)
<rcn-ee> that would be a nother good fixup to list on the wiki.. just remove/move the xsession file...
<Hoonse> there is no drag down?!?
<Hoonse> there is login restart and shutdown...
<rcn-ee> you need to click on your login name... or type it.. then the theme changes...
<Hoonse> oh there it is... sorry
<rcn-ee> i know.. it's weird... if you don't have a 'theme' installed it's impossible... ;)
<Hoonse> is there a tool to setup the wifi device?
<rcn-ee> network manager, once installed.... but you'll have to do... "sudo ifconfig -a", "sudo iwconfig wlanX essid "xxx"", "sudo dhclient wlanX"
<Hoonse> iwconfig not found...
<rcn-ee> that was "wireless-tools" one of the usefull packages... you have to download, copy, dpkg it..
<rcn-ee> http://ports.ubuntu.com/pool/main/w/wireless-tools/  it shouldn't have any dependices, dpkg will warn you...
<ogra> under karmic qnd lucid you can just chroot into the SD card from your x86 host :)
<ogra> an just install NM
<ogra> qemu-arm-static ftw !
<rcn-ee> yeah, that would be easier.. and while there, add the nework manager gui for xfce4, not sure on the name.. ;)
<ogra> yeah
<ogra> everything is so much easier in karmic and lucid
<ogra> imagine lucid+1 .... it will just work on its own, we wont even need to do anything anymore :)
<Hoonse> whats the difference between wireless-tools 29-1ubuntu... and wireless-tools 29-1.1ubuntu...
<Hoonse> wich should i download?
<lool> Cool, linux uploaded
<lool> Hopefully a working versatile in lucid soon
<ogra> lool, doe sthat have the fix for the eglibc issues ?
<ogra> or do we need another libc upload for them ?
<Hoonse> i have downloaded the files to my beagle desktop but i cant find any option in apt-get to install from disk
<lool> ogra: I don't have any fix for the regression caused by libc6 update
<ogra> meh
<rcn-ee> Hoonse, from disk, use "sudo dpkg -i <file>"
<ogra> then we wont have working versatile
<rcn-ee> opps, thats why mkfs.ext4 took so long on my server.. usb 1.1 port...
<Hoonse> hmmm i have to take the armel.deb files right?
<ogra> 1.1 ? ouch
<rcn-ee> Hoonse, that's correct...
<Hoonse> no i took 2ubuntu...
<Hoonse> wireless-tools_29-2ubuntu6_armel.deb
<ogra> looks ok
<Hoonse> it says "packet damaged"
<Hoonse> i translatet this...
<rcn-ee> sounds like it didn't copy all the way....
<Hoonse> k i will do it again...
<ogra> Hoonse, https://launchpad.net/~ogra/+archive/ppa/+files/qemu-arm-eabi_0.10.5-0ubuntu1_i386.deb install that on your x86 machine
<ogra> Hoonse, then you can mount your SD to /mnt and do: sudo chroot /mnt apt-get install network-manager
<Hoonse> via ssh too?
<ogra> on your intel machine
<ogra> you can do chroot via ssh too indeed, yes
<Hoonse> i have istalled this
<Hoonse> now?
<ogra> now you can execute stuff on the SD
<ogra> through the chroot command
<ogra> mount it to /mnt and run sudo chroot /mnt
<ogra> that gives you a shell on the SD
<ogra> and then you can just install network-manager using apt
<Hoonse> ok now i am confused..
<Hoonse> i have mounted the ext filesystem from the mmc card
<ogra> right
<Hoonse> yes but what do i do with chroot?
<rcn-ee> cwillu_at_work, the ehci looks good on the c4 with (tested 2.6.32.7-x7.1 and 2.6.32.8-x8.0), using the same stress test i use for the musb port..  i really need to find another way to break it...
<ogra> now you do: sudo chroot /mountpoint
<cwillu_at_work> rcn-ee, troubles?
<Hoonse> angus@serv0r:~/Desktop$ sudo chroot /media/ext
<Hoonse> chroot: cannot run command `/bin/bash': No such file or directory
<cwillu_at_work> rcn-ee, or are things just working properly and you're sad?
<rcn-ee> nope, not troubles.. everything works good.. so it's a good sign..
<cwillu_at_work> :)
<ogra> Hoonse, make sure to mount it manually in /mnt or something, the automount in /media wont work
<cwillu_at_work> I had a weird crash yesterday, don't think it was usb related though
<cwillu_at_work> I've got better blinken lights now so I'll know for sure the next time
<cwillu_at_work> rcn-ee, I don't have it handy, but have you tripped over any omap-pm kernel config options?
<cwillu_at_work> was wanting to play with the thermal monitor a bit, which apparently requires a specific omap pm module;  additionally, this allows for bumping up the voltage when clocking a beagle at 720mhz, which I wanted to try re: the weird crash
<Hoonse> i have manually mounted it on /mnt/ext
<ogra> ok
<ogra> and there is /mnt/ext/bin ?
<Hoonse> yes
<cwillu_at_work> Hoonse, typically you mount things directly on /mnt;  use /media for submounts
<Hoonse> but it seems there is no bash...
<ogra> Hoonse, so the chroot command should work (at least if you are on a ubuntu machine)
<ogra> ls /mnt/ext/bin/bash ?
<Hoonse> yes
<cwillu_at_work> Hoonse, you did chroot /mnt/ext or /media/ext?
<Hoonse> and there is a bin/bash
<Hoonse> wtf?!?
<ogra> might be a bug in the qemu-arm-eabi package but it *should* work
<ogra> its a pre release package i rolled under jaunty, the proper one went into karmic and is a bit different
<Hoonse> do i have to start qemu or something?
<ogra> nope
<ogra> its an automatic wrapper that wraps around armel binaries if you execute them
<ogra> you can try to restart binfmt-support
<Hoonse> ?
<ogra> sudo /etc/init.d/binfmt-support restart
<ogra> thats where it hooks into
<rcn-ee> cwillu_at_work, yeap, now that musb/ehci seem to work, i really want to start enableing the power managment stuff..
<ogra> and then try again
<Hoonse> nope doesnt work
<cwillu_at_work> oh, goodie :)
<Hoonse> strange
<ogra> sorry then, might be an issue with the package
<rcn-ee> crap... anyone know a good source for 3.3 volt pci usb adapters... my server is just a tad bit old only usb 1.1...
<ogra> Hoonse, sudo dpkg -r qemu-arm-eabi
<cwillu_at_work> I've got a good computer store locally, it's been a while since I've had to buy any standard parts online :)
<ogra> Hoonse, try the karmic one http://archive.ubuntu.com/ubuntu/pool/main/q/qemu-kvm/qemu-arm-static_0.11.0-0ubuntu6.3_i386.deb
<cwillu_at_work> ugh, 3.3 volts?
<rcn-ee> yeap... 3.3... full length pci....
<rcn-ee> i think i can get away with a very low profile and left angle pci convertor..
<ogra> are these still built ?
<rcn-ee> it's an old amd-8111 dual core opteron i got surplus a couple years back..
<ogra> i meant the PCI->USB cards :)
<rcn-ee> i have a couple, 5 volt, it doesn't look like anyone built them for 3.3... (just parrell/firewire stuff)
<Hoonse> i think i will try this tomorrow again...
<rcn-ee> okay found a 3.3.. newegg loves me..
<Hoonse> i have to stand up at 5 am because it snows like hell
<Hoonse> by guys and a big thanks for all your help
<Hoonse> see u tomorrow
<ogra> *** glibc detected *** apt-get: double free or corruption (fasttop): 0x000c7160 ***
<ogra> hrm
<ogra> lool, ^^^ thats with the karmic kernel
<ogra> (but i guess you tested that when nailing it down on libc)
#ubuntu-arm 2010-02-11
<asac> not using jit for mono makes compiler hit bad C code ...bails out
<ogra> bah
<sevenseeker> howdy, where can I obtain binaries of 9.04 for a sheevaplug?  Googling is giving me all sorts of goofy pages
<persia> ports.ubuntu.com ought have individual packages.  No idea where to get images.
<persia> Note that upgrading to 9.10 will break your system on a sheevaplug, and require reinstall.
<sevenseeker> persia, yes thank youâ¦ I just read the 9.10 warning and was wondering if there is enough community to support maintaining a non VFP version of ubuntu
<sevenseeker> just now starting to research
<persia> sevenseeker: There's a bunch of people, but not enough infrastructure.
<sevenseeker> persia: what does launchpad currently (if any) support?  I am new to embedded ubuntu, but have used launchpad to make packages for my ppa before
<persia> This isn't the best place to talk about embedded ubuntu, because we don't do anything to make it more embedded friendly: we just do Ubuntu on armel.
<persia> Mind you, many "embedded" systems are now powerful enough that this doesn't matter.
<persia> But I wouldn't try to install Ubuntu on a network interface, for example :)
<persia> Anyway, that aside ...
<persia> launchpad PPAs don't suppprt armel at all right now.
<sevenseeker> aha, good to know
<persia> (same as powerpc, sparc, ia64)
<sevenseeker> sad I am, but still good to know, lol
<persia> But Ubuntu is available for armel.
<persia> So any software in Ubuntu can be used.  Adding new software to Ubuntu isn't particularly hard, but there are several ways to do it, which can be a bit confusing.
<persia> But since there are already something like 20,000 software packages, most of what one needs is already there.
<sevenseeker> I also build Alix based systems but use openwrt for that
<persia> Ubuntu 9.04 was ARMv5t+ compatible.
<persia> 9.10 was ARMv6+vfp+ compatible
<persia> 10.04 seems to be ARMv7/Thumb2
<persia> (but it's not out yet, so no promises)
<persia> Rumour has it that this escalation will be stopping soon.
<persia> So one hopes that in the not-too-distant future, one can safely upgrade on common consumer devices.
<sevenseeker> that would be nice
<rcn-ee> persia, ARM hasn't announced anything past ARMv7...  So any cortex-aX device is safe...
<sevenseeker> then maybe more embedded friendly sub-distros could be worked onâ¦ who knows?
<persia> rcn-ee: So rumour has it, but I'm not privy to all conversations between all counterparties everywhere :)
<persia> sevenseeker: Well, why do you need embedded?  Ubuntu 9.10 runs on devices with 2G storage and 256MB RAM.
<sevenseeker> lol, you could be my 'insider' for info
<persia> You could probably make it even smaller if you just did a single-purpose server.
<sevenseeker> well its like thisâ¦ I love that 'embedded' class systems are getting faster/more ram/better/etcâ¦ but it seems like much software is just banking on this and being lazy (I know I did that previouslyâ¦ ok, now)
<rcn-ee> persia, if you factor in the time between ARM announcing ARMv7 devices, product availably from silicon manufactures and gcc support..  It'll be couple years before the next ARMv+ would be out..
<sevenseeker> but the more tight it is the better it can use whatever system its on basically
<persia> rcn-ee: That's my opinion as well.  I just tend to be careful when I don't have any formal statements.
<sevenseeker> note: I have been optimizing for 2 weeks and probably am stuck mentally in that mode now
<persia> sevenseeker: The main difference in "embedded" is usually stuff like not shipping documentation, etc.
<persia> The code should be made as efficient as possible regardless of the target, for performance reasons.
<sevenseeker> I agree
<sevenseeker> I use EC2 for some 'stuff' and my optimization sure does save me money :) :) :)
<persia> The other common "embedded" choice is monolithic static binaries.  That gets hard to maintain in a modular fashion.
<sevenseeker> wow, yes it is
<sevenseeker> you mean like jffs?
<persia> No, like compiling your app linked statically against glibc so that you don't have to ship as many files (because you didn't ship glibc)
<persia> We (kinda) support jffs2, and I know of at least one consumer device being sold with Ubuntu on ubifs.
<sevenseeker> aha
<persia> But anyway, there's lots of optimisations.
<persia> So the "bloat" is mostly docs, overhead from having lots of files, overhead from having a full package management system, etc.
<persia> But flash is cheap :)
<sevenseeker> I see, yeah that makes sense
<persia> So anyway, for your sheevaplug, just stick with 9.04.  ports.ubuntu.com has lots of packages you can use.
<sevenseeker> sweet, that sounds great
<persia> And when you have a chance to get newer hardware, ask for something that is known to work with Ubuntu :)
<sevenseeker> lol, yeah
<persia> And if rcn-ee and my speculations are correct, you should be able to upgrade that to the latest version and keep up for a while.
<sevenseeker> well, I am considering this summer prototyping a series of Alix boards based on full ubuntu, granted they are x86 and thus OT here
<rcn-ee> sevenseeker, one note thou too, even with an unoptimzed debian dist, the sheevaplug is still pretty quick: http://global.phoronix-test-suite.com/?k=profile&u=robertcnelson-8971-28884-22100
<sevenseeker> is there a similar system to sheevas that is cheap and readily available that uses > ARM v5?
<persia> I haven't heard of anything in that form factor.
<persia> Most people around seem to use development boards (beagle, babbage, etc.)
<persia> The Sharp Netwalker is also available, but I don't know of anyone who hosts a kernel for it that can boot 9.10 ot lucid
<sevenseeker> hmmm
<sevenseeker> thanks for the infoâ¦ and the reminder, I need to try a beagleboard just for kicks
<sevenseeker> since it won't do HD it really would not be useful for me now, but a year ago â¦ woah nellie!
<rcn-ee> sevenseeker, with the dsp, HD'ish is possible.. "1280x720"  i have just not spent enought time getting the ubuntu side to work..  It does play video with the DSP in Angstrom...
<sevenseeker> hmm, now THAT sounds very enticing
<sevenseeker> thank you
<rcn-ee> sevenseeker, this was done at FOSDEM this year, 6 beagles each connected it's own display.. we are still waiting from the ffmpeg guys on how they did it.. http://hardwarebug.org/2010/02/10/1080p-video-on-beagle/
<sevenseeker> WOAH
<sevenseeker> yeah, they need to reveal that :)
<saeed> davidm
<ogra> saeed, i guess thats a bad time to  catch him (2am at his place)
<saeed> hi ogra
<ogra> hey saeed
<NCommander> hey saeed!
<saeed> I need some help with the power button on Dove DB
<saeed> Hi Michael
<ogra> ericm_, ^^^
<NCommander> saeed: whats the issue with the power button?
<cooloney> saeed: long time no see
<saeed> I want to make it trigger user space suspend and power off
<ericm_> ??
<saeed> Hi bryan
<ericm_> hey saeed, how u doing dude
<saeed> currenty that button implemented as input device
<saeed> and it reports EV_SUSPEND when pressed/unpressed
<saeed> hi eric
<ericm_> Saeed, maybe you want your Xorg.log.0 pasted?
<saeed> here?
<eggonlea> paste.ubuntu.com
<eggonlea> http
<lool> saeed: Try xev under Xorg; do you see any event?
<lool> saeed: AFAIK, we expect all buttons to trigger Xorg key press events, then gnome-power-manager listens to them
<lool> saeed: To quickly paste stuff to paste.ubuntu.com, you might find http://people.canonical.com/~cjwatson/ubuntu-paste useful
<lool> Or install the pastebinit package
<saeed> check http://paste.ubuntu.com/373788/
<lool> You have evdev at least
<lool> saeed: Could you try running xev in a terminal and checking whether the power button triggers a Xorg keypress event?
<saeed> xev doesn't show anything when pressing on the button
<lool> (II) UnloadModule: "evdev"
<lool> that's odd
<saeed> also lsof /dev/input/event0 is empty
<lool> Ah the unload is for another device
<ogra> that it configures the kbd as a mouse looks wrong too
<lool> saeed: Your xorg.log doesn't show any setup for event0
<saeed> yes
<lool> saeed: So probably Xorg doesn't think your event0 is an interesting device
<saeed> yes, I added some file to hal/fdi/policy
<lool> I think we're trying not to use hal anymore, but straight udev
<lool> In the xorg-server source package, patch debian/patches/12-Add-libudev-input-hotplug-backend.diff adds this stuff
<ogra> and xinput
<lool> udev rules would look something like:
<lool> SUBSYSTEM=="input", KERNEL=="event*", ENV{x11_driver}="evdev"
<lool> SUBSYSTEM=="input", KERNEL=="event*", ENV{ID_CLASS}=="kbd", ENV{xkb.layout}="fr", ENV{xkb.options}="terminate:ctrl_alt_bksp,compose:lwin"
<ogra> i think we're supposed to use the xinput tool
<lool> saeed: Check /lib/udev/rules.d/64-xorg-xkb.rules, does it match your device?
<ogra> but at least here i cant make it use any device
<ogra> (instead of xev)
<ogra> we should ask tseliot, he cares for the whole xinput stack
<lool> That's just xkb actually
<lool> saeed: I would add a ENV{x11_driver}="evdev" property to your device
<saeed> where should I add that?
<lool> saeed: For now, add it manually to your local udev rules
<lool> saeed: Something like /etc/udev/rules.d/90-power-button.rules
<saeed> at /etc/udev/rules.d/ ?
<saeed> ok
<lool> with SUBSYSTEM=="input", KERNEL=="event0", ENV{x11_driver}="evdev"
<lool> But I'm not an udev expert
<lool> saeed: You can raise the verbosity of udev to debug this
<lool> /etc/udev/udev.conf use info
<lool> saeed: Ah I found some good examples
<lool> saeed: /lib/udev/rules.d/66-xorg-synaptics.rules
<lool> That sets ENV{x11_driver}="synaptics" and some additional options for some devices
<lool> the generic rule is /lib/udev/rules.d/65-xorg-evdev.rules
<lool> saeed: So your problem is that /lib/udev/rules.d/65-xorg-evdev.rules doesn't map your device to evdev
<lool> saeed: It only maps devices of type keyboard, mouse, touchscreen or touchpad
<lool> saeed: What intput type are you using?
<saeed> keyboard
<lool> saeed: Odd, so the generic rule should have mapped it to the evdev xorg driver
<lool> saeed: You probably want some udev debug to see if that gets properly assigned
<lool> saeed: Basically make sure that x11_driver gets set to evdev, then it becomes a xorg-server issue if it didn't load an evdev xorg driver for this device
<ogra> (**) "Power Button": always reports core events
<ogra> (**) "Power Button": Device: "/dev/input/event0"
<ogra> (II) "Power Button": Found keys
<ogra> (II) "Power Button": Configuring as keyboard
<ogra> (II) XINPUT: Adding extended input device ""Power Button"" (type: KEYBOARD)
<ogra> thats what i have on my laptop
<ogra> so the keyboard driver should be fine for it
<ogra> s/keyboard driver/evdev driver in keyboard mode/
<saeed> here is the lshal part for the button http://paste.ubuntu.com/373798/
<ogra> hmm, you shouldnt be having hal installed if you run lucid
 * ogra wonders if that gets in the way somehow
<ogra> (it shouldnt though)
<lool> saeed: udevadm info --query=all --path=/sys/class/input/event0
<lool> this is my power button http://paste.ubuntu.com/373800/
<lool> You can see x11_driver=evdev
 * lool had a great idea before sleeping in last night
<saeed> the info.capabilities is just input, maybe is should be input.keyboard?
<lool> saeed: Yes, that's likely why the generic rule doesn't match
<lool> saeed: On my power buttong I have E: ID_INPUT_KEY=1
<lool> saeed: Do you have it?
<saeed> no
<lool> saeed: Ok, that's your issue then
<lool> saeed: Actually there seem to be two types
<lool> One for keyboard and one for key
<lool> /lib/udev/rules.d/60-persistent-input.rules references ID_INPUT_KEYBOARD
<lool> saeed: But you basically want to set your kernel driver evdev props to key or keyboard
<ogra> are we actually sure we want gpoi mapped to Xorg at all ?
<lool> We're sure we want the power button mapped
<ogra> right, but that doesnt necessarily need to happen with evdev
<lool> ogra: What do you propose?
<ogra> especially for gpio ... i.e. look at lirc which uses gpio buttons
<ogra> it doesnt have much useful stuff, but definately doesnt use evdev ... all we need is to capture the gpio even somehow and make g-p-m aware through devkit-power
<lool> saeed: I checked the ACPI power button implementation, and it does: input->evbit[0] = BIT_MASK(EV_KEY);
<lool> set_bit(KEY_POWER, input->keybit);
<ogra> though the devkit-power rules dont seem to have anything useful in them regarding buttons
<lool> saeed: drivers/acpi/button.c:395
<saeed> ok, I'll try that
<lool> ogra: Can use your lirc device to power off?
<lool> cooloney: WRT LP #516352, did you also cherry-pick the commit removing the file on package removal?
<ubot4> Launchpad bug 516352 in linux-fsl-imx51 (Ubuntu) "fsl-imx51: need backport module.builtin to .31 kernel for lucid userspace compatibility (affects: 1)" [Medium,Fix released] https://launchpad.net/bugs/516352
<lool> cooloney: 69f2227cdca42c4bbaa6fc931e64385f7fdee38f
<ogra> grrr
 * ogra hates reconnects
<ogra> lool, /lib/udev/rules.d/95-keymap.rules has what we want
<ogra> for example ENV{DMI_VENDOR}=="Acer*", ATTR{[dmi/id]product_name}=="Extensa*", ATTR{[dmi/id]product_name}=="*5210*|*5220*|*5610*|*5620*|*5720*", RUN+="keymap $name 0xEE screenlock"
<ogra> (see the RUN part)
<ogra> saeed, do you see any events in dmesg if you press the button ? preferably with a keycode ?
<cooloney> lool: oh, i just cherry picked 2 .32 patches to .31 kernel as we discussed before
<lool> cooloney: You might want the above SHA too
<lool> ogra: What you're pointing at is for extra keys on laptop keyboards
<ogra> lool, yes
<ogra> well, keymapping for buttons not used by X
<lool> ogra: The mvl-dove driver doesn't need any specific rule IMO
<ogra> you want a low level power key event
<lool> We just need to have the power key device using the proper class
<ogra> which isnt mapped atm
<lool> I don't think that's needed, no
<ogra> well, as i understood it already emits an event
<ogra> its just not mapped to power
<lool> ogra: As you can see in the Xorg log, the device is not seen by Xorg at all
<ogra> why should it be seen by Xorg at all ?
<lool> While on your system and mine it is
<ogra> you want a power event from the kernel
<lool> No
<lool> You want a keypress event
<ogra> which you likely already get
<ogra> <saeed> currenty that button implemented as input device
<ogra> <saeed> and it reports EV_SUSPEND when pressed/unpressed
<ogra> if there is a keycode emitted too a rule will just map it properly
<lool> ogra: Try it out
<cooloney> lool: do you mean this "UBUNTU: [Config] armel -- cleanup to-be builtin modules", right?
<lool> cooloney: No, I mean UBUNTU: Add modules.builtin.bin to prerm rm list
<lool> cooloney: Try installing and removing a fsl-im51 kernel package, you will see that a file is left behind
<lool> cooloney: (modules.builtin.bin)
<saeed> now xinput show the gpio device
<lool> saeed: Wee
<saeed> xev shows nothing when pressing on the button
<saeed> thanks lool
<ogra> lool, * include modules.builtin in the binary debs ?? that one ?
<lool> ogra: I don't understand what you're commenting on
<ogra> your discussion with cooloney
<saeed> brb
<lool> ogra: Your comment doesn't make any sense in the discussion
<cooloney> lool: ok, got you, i just recall that this patch is from you, right?
<lool> saeed: You need to have the proper flags when sending the event too
<lool> saeed: Specifically, it needs to be a key event
<lool> cooloney: It is from me indeed, which is why I recall it
<lool> cooloney: It should go together with the modules.builtin backport/cherry-pick you're doing
<cooloney> yeah, i noticed that, thanks for reminding me
<cooloney> but the SHA on my side is 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab29
<cooloney> roc@roc-desktop:/opt/git/Ubuntu/lucid$ git show 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab29
<lool> cooloney: You're right, it's 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab29
<cooloney> commit 48d7349bbc9e47a27c74cdb3e56bbcc92d9bab29
<cooloney> Author: LoÃ¯c Minier <lool@dooz.org>
<cooloney> Date:   Wed Feb 3 05:32:45 2010 +0000
<cooloney> UBUNTU: Add modules.builtin.bin to prerm rm list
<cooloney> BugLink: http://bugs.launchpad.net/bugs/516584
<ubot4> Launchpad bug 516584 in linux (Ubuntu) "modules.builtin.bin not removed on package removal (affects: 3) (dups: 1)" [Undecided,Fix released]
<lool> cooloney: Must be a copy-paste error, sorry
<cooloney> lool: ok, cool. I will cherry pick that to my branch
<ogra> which was included already
<cooloney> lool: no problem, thanks a lot
 * ogra really wonders what you guys are discussing here
<cooloney> ogra: oh, really?
<ogra> look at the imx changelog, apw usually includes the package fixes frim the linux package
<ogra> *from
<lool> ogra: It's certainly not in the git log of the fsl-imx51 branch
<lool> Besides, it needs to be adapted to apply on debian.fsl-imx51/ anyway
<lool> cooloney: I checked the fsl-imx51 and it still needs fixing
<cooloney> ogra: lool is right.
<lool> cooloney: debian.fsl-imx51/control-scripts/prerm, @files_to_remove
<ogra> lool, because there was never a modules.builtin.bin until recntly in imx51
<apw> yep i missed that one when i pulled fsl-imx51 togther
<lool> ogra: And there is one now, because it was cherry-picked
<cooloney> i need to cherry pick that patch with others
<ogra> lool, right, since the very last upload
<ogra> which i pointed to before
<lool> I wonder how many people it takes to convince ogra that I'm right
<cooloney> oh, guys, no problem,
<cooloney> i will fix that soon,
<apw> its in mvl-dove as part of the rebase
<lool> cooloney: thanks; not a big deal anyway
<lool> Just a leftover file, but it causes a warning on package removal
<apw> not in fsl-imx51 cause its a franken kernel
<cooloney> apw: right, because mvl-dove is .32 based anyway
<lool> apw: Do you have some script to adapt the debian.foo/ pathname when doing these rebases?
<apw> yep, cooloney get it to me soon :)
<apw> lool, nope, just use vi on the patch
<lool> hehe ok
<lool> apw: Would it be much work to turn on udebs for versatile?
<lool> I'm sure that's something you'd be excited about  :-)
<apw> what the heck would we want those for
<apw> i am sure the aa's would love a heap of more binary debs to wave though
<lool> apw: I don't know for mobile team, but I'd love to point people at debian-installer images to install Ubuntu in qemu
<lool> apw: That would allow providing just vmlinux on ports.ubuntu.com
<lool> and a d-i initrd
<apw> the work is not normally in eanbling them but in getting the result to pass the d-i pass afterwards
<apw> if you don't have all modules built
<lool> apw: something like http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/dove/ but for versatile
<lool> apw: Ack; the work would probably involve adding some Provides to the binary package
 * cooloney is vi on the patch file as apw said. heh
<lool> apw: Because a lot of modules are builtin in the versatile config
<apw> loads of ?'s to be added and you have to build it to find out which ones
<lool> apw: The d-i side of things is just commented out for versatile BTW; it's well supported in d-i
<lool> apw: Right
<lool> something like that
<lool> apw: Currently, if we want to pull the official kernel for versatile from lucid, we have to download a .deb and unpack it to get to the vmlinuz file which allows running qemu
<apw> i have no objection to udebs or not, they arn't a big bit of the build
<lool> So having d-i images would allow people to use them for install, and would also make it easier for e.g. rootstock to pull a kernel
<lool> apw: I'd love that
<lool> apw: Do you want me to check formally whether there are objections/interest in that from the mobile team?
<apw> sure
<lool> Ok, mailing ubuntu-mobile@
<cooloney> apw: i found lool's patch can not apply to debian.fsl-imx51 directory,
<lool> apw: FYI I just tested the in archive linux-image-2.6.32-13-versatile_2.6.32-13.18_armel.deb and it boots fine with lucid and karmic userspace
<cooloney> apw: it does not have the whole line 'modules.alias.bin modules.dep.bin modules.symbols.bin' at all
<lool> cooloney: You don't have .bin files with your fsl-imx51 kernel?
<lool> apw: (I mailed ubuntu-mobile@)
 * cooloney wants to punch his head to the wall, messed up his board.
<cooloney> i need to reinstall my lucid on my board now
<apw> cooloney, then have a look at the debian.master version of that file
<apw> there is another patch which pulls the other two in you need as well
<apw> cooloney, ironically it was your first patch i think
<apw> commit 8b453930465c15f490ea44c2987b0a1bfe71ed66
<apw> Author: Bryan Wu <bryan.wu@canonical.com>
<apw> Date:   Wed Mar 25 17:31:26 2009 +0800
<apw>     UBUNTU: Add 3 missing files to prerm remove file list
<apw> cooloney, so you need that commit copied over first, then lool's one
<cooloney> apw: that is a good memory for me
<cooloney> apw: will do it soon
<apw> whenever man
<saeed> I changed the button to send EV_KEY instead on EV_PWR
<saeed> now I see message "Failed to suspend" (hibernate)
<saeed> I'll change the code to KEY_SLEEP instead of KEY_SUSPEND
<lool> saeed: Great
<lool> saeed: Where do you see the message?
<lool> saeed: Are you running gnome-power-manager?
<saeed> yes,
<saeed> I think it failed to hibernate because the resume  param was wrong
<lool> saeed: drivers/acpi/button.c uses KEY_POWER for ACPI_BUTTON_TYPE_POWER, so that seems correct
<lool> saeed: Ack
<lool> saeed: And it uses KEY_SLEEP for ACPI_BUTTON_TYPE_SLEEP; it doesn't use KEY_SUSPEND
<saeed> oh, hibernation is disabled
<lool> saeed: Yeah, you certainly don't want KEY_SUSPEND
<saeed> ok
<saeed> look, we are looking for the folowing behavior
<saeed> if button pressed for less that 3 seconds , the system enters standby mode
<saeed> othewise we want the system to shutdown
<lool> saeed: Ok; so you would send KEY_SLEEP for < 3 secs and KEY_POWER otherwise
<saeed> that means driver change, right?
<lool> saeed: Oh you would like to implement the 3 secs in userspace?
<saeed> yes
<saeed> btw, lucid keeps showing the "failed to suspend" again and again
<ogra> lool, bug 520028 ... what was the reason for dropping ubuntu-minimal ?
<ubot4> Launchpad bug 520028 in project-rootstock "ubuntu-minimal doesn't build correctly for karmic (affects: 1)" [Undecided,New] https://launchpad.net/bugs/520028
<ogra> iirc a patch from you dropped it
<ogra> (though if its really upstart being at fault, there should be a hard dep)
<saeed> guys, the suspend works fine now
<saeed> however I wish ubuntu show message that the system going to suspend to ram
<ogra> \o/
<saeed> the rules file not needed of course
<ogra> saeed, /var/log/pm-suspend.log should have something
<saeed> ogra: here it is root@lucid-dove:~# cat /var/log/pm-suspend.log  Initial commandline parameters: Tue Jan 11 21:19:32 CST 2011: Running hooks for suspend. /usr/lib/pm-utils/sleep.d/000kernel-change suspend suspend:success. /usr/lib/pm-utils/sleep.d/00logging suspend suspend:Linux lucid-dove 2.6.32.3-dove-5.0.0-rc3-00671-g43c704e-dirty #200 Thu Feb 11 13:34:59 IST 2010 armv7l GNx Module                  Size  Used by              
<saeed> sorry
<saeed> here it is http://paste.ubuntu.com/373887/
<ogra> ue Jan 11 21:19:33 CST 2011: performing suspend
<ogra> thats the actual suspend
<ogra> /usr/lib/pm-utils/sleep.d/000kernel-change resume suspend:success.
<ogra> Tue Jan 11 21:19:48 CST 2011: Finished.
<ogra> is the final wakeup
<saeed> ogra: I was expecting gui  message telling that the system going to suspend
<ogra> ah
<saeed> because it takce few seconds to do that
<ogra> usually the screen fades out immediately
<saeed> lool, eric, I see this kernel message when pressing on the button:
<saeed> keyboard.c: can't emulate rawmode for keycode 142
<ogra> http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png
<ogra> netbook-launcher is on the screen after 35 sec :)
<persia> Nice!
<persia> That's getting close to boot speeds I find acceptable in my laptop.
<persia> What's the suspend/resume delay?
<ogra> i think if jockey wouldnt run all the time in the background we'd get another 5 sec speedup
<ogra> suspend takes a while to process the scripts, resume is instant
<persia> Don't we need jockey?
<ogra> we will need it once we have 3D drivers
<ogra> the prob is that its *scanning* permanently due to a bug
<persia> That's extra nice.  On my netwalker, I get about 2 seconds suspend and 3 seconds to resume (which Sharp advertises as a "3-second boot")
<ogra> heh
<ogra> i think suspend takes rather five here
<persia> Well, I mean, really.  How often to people actually boot.  Even my laptop only gets booted for kernel updates.
<ogra> but resume is just up after pressing the button
<ogra> probably 1sec
<persia> That's nice.
<lool> saeed: I'm glad it works  :)
<lool> saeed: Did you try emulating the power key as well?
<lool> saeed: Will you do this in kernel?
<lool> saeed: Concerning the feedback on suspend: a) some devices blink the power led in the kernel, and b) the suspend is supposed to be so quick that you don't need feedback, right?   :-)
<saeed> I didn't try the power key
<saeed> in karmic the system enters standby immediately
<saeed> using echo mem > ..
<saeed> regarding the power key,  it's easier for me to do it kernel, but I'm not sure if this is the right way
<lool> saeed: I would think that an userspace hack wouldn't get upstream either
<lool> saeed: IMO it's a device design problem
<lool> saeed: This is going to be in a physical device for which the user experience is going to be "this button can do multiple things"; the button is going to be labelled with or more icons depending on what it does
<lool> In another design you would have two buttons
<lool> So I don't know whether you're trying to do a generic device design or whether you're trying to demonstrate shutdown and suspend with a single button on a particular design
<lool> It's hack either way, but it's really related to your hardware layout
<persia> What's the goal again?
<lool> The kernel can send events for either a power or a suspend button press
<lool> saeed would like a shutdown to happen if pressed more than 3 seconds and a suspend otherwise
<persia> But on what does that depend, in terms of user experience.
<persia> Ah, yeah, that needs to be a kernel thing.
<persia> I'd hope additionally for a hardware shutdown if the key is held longer.  At least I use that on my Netwalker.
<persia> (because sometimes software hangs)
<persia> So HW differentiation for whether hold > 10s, and kernel differentiation for whether hold > 3s.
<persia> But again, why bother shutting down with a button?  Is it that frequent a use-case to turn a device off?
<lool> saeed: Or alternatively, call your key "User button 1", send your own event and keycode and write a tool to handle it   ;-)
<persia> Um, in that case, just use the power button.
<persia> We already have software that can take a power button event and perform various actions, which could be extended to meet the timing case.
<lool> It might be simpler to have another software handle a timed key press and call into gpm rather than patching gpm
<lool> (and easier to maintain/less intrusive)
<persia> I guess.  I just don't like to have too many special HW hacks.
<lool> Which is why I'd prefer having it separate
<lool> instead of running the hack in gpm
<persia> I'd rather enable a use case for a broad spectrum of HW, and have the HW produce something that works with existing software, to preserve user choice.
<lool> You can always remap the key in software if you want
<persia> Right, that would be the special HW hack: "If you have this board, you need to remap your keys like this: ..."
<lool> Well you're proposing to patch GPM to have a mode "If this hardware is detected and button is pressed more than n seconds, do something else"
<persia> Adding a fork function for timing in g-p-m would enable this class of behaviour for arbitrary HW which didn't expose a sleep button (and there's lots of that)
<lool> I'm proposing to have a separate software which doesn't have the "if you have this hardware" and if people want to replace the software to use gpm, they can either patch gpm or remap thier keys
<persia> No.  I'm proposing that g-p-m be patched to be able to have different actions happen for different timing delays in power button presses.
<persia> No special HW detection.
<lool> I don't think that'd fly
<persia> Why not?
<persia> I have hardware for three different architectures that doesn't have sleep keys.
<lool> We'd have to run and maintain the patch for everybody instead of maintaining a single isolated trampoline
<persia> Why wouldn't the patch go upstream?
<ogra> dmart, i remember you filed a bug once on building the kernel with thumb2 but i cant find it on LP, do you happen to remember the bug number ?
<lool> Well that's my opinion that's it's too specific
<lool> Upstream mught have a different opinion
<persia> lool: How specific.  Like I said, I have HW for three different architectures with no sleep button, and none of it is saeed's HW.
<lool> persia: For instance, why do it for the power button and not the sleep button?
<persia> lool: No reason at all.  Generalisation is good.
<lool> Then you also need some GUI, more GUI == more confusion
<dmart> ogra: can you remember what it was about?  I don't remeber filing a bug on Thumb-2 kernels yet.
<persia> Users with both power and sleep would be able to get to all of shutdown, hibernate, suspend, and screen-lock.
<ogra> dmart, well, that the kernel should be built with thumb2 (not the config option but the kernel binary being a thumb2 binary)
<ogra> i know we reviwed that in dallas and i thought it resulted in a bug you filed
<persia> lool: My basic point being that the utility you describe would simply not work for any of my hardware without a sleep button.  To me, this is HW-specific.
<dmart> ogra: I don't think I filed a bug.  It's not required that we build the kernel in Thumb-2, but we can try it if you think we're ready.
<dmart> ogra: I think it is a config option actually
<ogra> dmart, well, apw seems to just research that
<apw> yep ... 'we' have a sprint in a half hour on this stuff right?
<ogra> having smaller kernels surely helps speed up the boot
<ogra> apw, thats more about porting packages :)
<ogra> not sure kernel packages were meant there :)
<apw> linux was listed, i noticed when i read the announcements
<dmart> ogra: Bear in mind that there may be platform-specific drivers with assembler code, so it might not all work out of the box.  I would hope that there's not much of that however.
<ogra> ah
<dmart> Most of the assembler is in the general arch/arm code though, and that should be OK in the lucid kernel versions.
<lool> persia: Technically you could make the utility I describe listen to power button instead and disable GPM
<persia> lool: That would address all of my concerns :)
<lool> I filed lp #520465 on the qemu/linux/eglibc/glib2.0 issue
<ubot4> Launchpad bug 520465 in ubuntu "armel/versatile: glibc detected double-free or corruption (!prev) (affects: 1)" [Undecided,New] https://launchpad.net/bugs/520465
 * asac waves
<lool> It's not a priority for me, but it would be nice to fix it for lucid
 * ogra is here
<ogra> lool, its a priority for me to be able to use the archive kernels though
 * ogra subscribes
 * JamieBen1ett waves back
<ogra> ah, armel is subbed already, good
<asac> dmart: dyfet: StevenK: persia: ping ;)
<dmart> Hi there
<dyfet> pong
 * persia will be about 10 minutes late
<asac> persia: ok. please read the backlog then ;)
<asac> anyone else here for the porting sprint?
<persia> Always :)
<dyfet> dealing also with replacing a furnace this morning :(
<asac> what is a furnace?
 * asac goes for dictionary
<dmart> big firey thing
<asac> dyfet: so you cannot attend?
<dyfet> http://en.wikipedia.org/wiki/Furnace :)
<ogra> oven :)
<dyfet> No I can...
<asac> good
<dyfet> Just annoying distraction ;)
<asac> ok
<dyfet> and a bit cold this morning ;)
<dmart> While we're waiting for persia, people might want to pull up https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
<asac> that should be fine ... our excersizes will make you feel hot i am sure ;)
<persia> NO reason to wait: I'm loosely about, just distracted for another 5 minutes or so.
<ogra> erm
<ogra> did anyone notify any MOTUs ?
<asac> we announced it on mobile
<ogra> given the univers list is HUGE
<ogra> i doubt many MOTUs read mobile
<asac> and on internal list
<dmart> ogra: may not be an issue for the first pass
<asac> ogra: we can spread the news to wider forum for the next time
<dmart> Partly I want to know what else needs to be documented
<lool> dmart: The first pass is not enough to fix all bugs?   ;-)
<asac> we have https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
<dmart> lool: well, obviously, if you're feeling energetic ;)
<ogra> asac, definately should be announced on ubuntu-motu@ next time
<asac> which should give us a decent amount of work
<asac> ogra: well. i usually dont hunt in random territory ... we could also have it announced on -devel
<asac> which most motus are subscribed to too
<ogra> yeah
<dmart> What's the best way to do this?
<dmart> I suggest we pick one package from the list and all take a look, and discuss.
<asac> right
<asac> i suggest that dmart takes the lead ;)
<ogra> either way i dont expect that our litle crew manages all these universe issues
<asac> so boost stuff is already done
<asac> dmart: maybe we can go by topic?
<asac> e.g. today focus on "mov" issues?
<dmart> That was going to be my suggestion
<dmart> any ideas about which one?
* lool changed the topic of #ubuntu-arm to: Thumb2 bug squashing party | https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
<asac> ok lets pick a first mov one
 * asac checks list
<ogra> mono ! :)
<asac> first in list is djvulibre
<dmart> maybe start with something simple?
<dmart> djvulibre looks like it was a simple one
<ogra> yeah
 * ogra wasnt serious with mono :)
<asac> ok everony get the source ;)
<asac> so how do we find the right places?
<ogra> grep ?
<dmart> mono comes later :)
<ogra> *shudder*
<asac> djvulibre-3.5.22$ grep -r mov * | pastebinit
<asac> http://pastebin.com/f55740dea
<dyfet> and mono jit? :)
<asac> guess that grep can be tweaked
<JamieBen1ett> so is this a mov only problem or does that include mov's such as movq?
<ogra> grep -R " mov " * ?
<JamieBen1ett> grep -R "mov " *
<ogra> yeah
<JamieBen1ett> 7 occurances
<persia> So we're just looking at ZPCodec.cpp and MMX.cpp
<dyfet> And GThreads.cpp?
<persia> Can we ignore MMX.cpp, under the assumption that we're not going to take that codepath for HW that doesn't declare MMX?
 * persia doesn't see GThreads.cpp from ogra's grep.
<JamieBen1ett> so no mov's that use the sp
<JamieBen1ett> sorry pc
<asac>  grep -r mov.*pc *
<asac> libdjvu/GThreads.cpp:                    "mov%?\t%|pc, %1"     // branch to address %1
 * dmart was distracted, back now
* lool changed the topic of #ubuntu-arm to: Thumb2 bug squashing party | https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList | https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
<asac> so the GThreads.cpp seems to be right match?
<asac> dmart: ?
<dmart> To find the occurrences, it's probably a good idea to look at the original grep list
<dmart> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList?action=AttachFile&do=get&target=search-arm-mov.filt.gz
<dmart> (linked from https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList)
<dmart> GThreads.cpp is indeed the location of the hit we got.
<persia> So GThreads is the only issue, and we can ignore ZPCodec.cpp as well?
<dyfet> asac: it's a mov pc, someregister op...a candidate for bx?
<asac>  grep djvulibre *
<asac> /var/cache/debmirror/pool/main/d/djvulibre/djvulibre_3.5.22-1ubuntu2.dsc
<asac>  ./djvulibre-3.5.22/libdjvu/GThreads.cpp:                    "mov%?\t%|pc, %1"     // branch to address %1
<asac> persia: only stuff that messes with "pc" is relevant from what i understood
<dmart> dyfet: would you like to suggest a fix? ;)
<dyfet> Well, it may not expand to a simple fix because the actual mov might be a movl, etc...
<dmart> movl?
<dyfet> The closest relevant fix might be using a string constant, and maybe #ifdef (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
<dyfet> #define ARM_MOVPC "mov%?\t%|pc, %1"
<dyfet> #else
<dyfet> #define ARM_MOVPC "bx%? , %1" ???  well, its hard to say how this expands exactly
<dmart> What did you mean by movl?  This doesn't mean anything to me (at least for arm)
<dyfet> Sorry, I meant the mov may not be for pc since it seems like some conditional substitution....thats why I am uncertain
<dmart> oooh, that's a new one on me.  What does %? do in gcc asm?
<dyfet> Yea that is what I was wondering...
<dmart> A good first step could be a stick a #error in there and build (since the code depends on -DCOTHREAD_UNTESTED, which might not be defined in our build?)
<asac> http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
<ogra> AT&T Code ... heh
<asac> i dont see anything about %?
<dmart> can't find it; maybe it adds the right AT&T operand size suffix.  That wouldn't apply to ARM, but then %? is only present in the ARM version.
<ogra> weird
<asac> yeah. lets ignore that
<dyfet> Then I think the simplest case is we want effectively a "bx %1"...
<asac> thats the obvious idea
<asac> what does the |pc mean?
<ogra> yeah
<dmart> Dunno!  I'll see if I can find out from anyone here.
<asac> its probably %|
<dyfet> asac: I read the original as effectively reducing to "mov pc, %1" but yea, I wondered about that too
<asac> right
<dmart> It might be the case that GCC can substitute condition codes for %?
<dmart> but it's no documented if so
<dyfet> But is it even a valid code path?  Its tied to COTHREAD_UNTESTED being defined...
<dmart> indeed
<dmart> I think the best thing iintially is
<dmart> #ifdef __thumb__
<dmart> #error "Needs porting to Thumb-2"
<dmart> #endif
<dyfet> Yes, lets see if it even builds that path first :)
<dmart> If this doesn't ftbfs, then someone can worry about it later :)
<dyfet> dmart: agreed
<asac> dyfet: ok want to create the diff for the file ... and i just upload ;)?
<dyfet> well, we have the other mov's to look at too :)
<asac> we will see if it fails then in a bit
<dmart> OK
<asac> dyfet: that was the only mov
<dmart> hold on
<asac> sure
 * asac waits
<ogra> dyfet, only "mov, pc"
<asac> mov.*pc
<dyfet> true....but then if its not explored, there must be another reason for the ftbfs :)
<dmart> http://pastebin.ubuntu.com/373995/
<asac> dyfet: it currently ftbfs?
<dmart> hmmm, guess we should look at the log
<dyfet> And since the end of it reaches a #error if none of the paths are explored, it has to be here...but yes, let's look at the log
<persia> dyfet: I don't see it at http://qa.ubuntuwire.com/ftbfs/
<asac> dmart: right. i wanted dyfet to produce that ... but ok ;) ... let me upload
<persia> Um, should we not try a local build first to make sure that fixes it?
<ogra> persia, queue is empty
<JamieBen1ett> persia: its not a fix, its just a warning in case that code path is taken
<dmart> doing one, but it may take some minutes
<dyfet> I am going to try a local build quickly...
<JamieBen1ett> (or so I understand)
<ogra> we can play with the buildds unless they are busy
<persia> JamieBennett: Right: it's that I don't tend to like to generate lots of archive churn when it might fail :)
<dmart> Our first priority is to get everything building and working in lucid.  Fixing code paths which are not built is nice to have, but putting a #error bomb is a reasonable way of helping ensure it gets fixed at the appropriate time
<dyfet> dmart: I think that code path has to be built, otherwise it would fall into a default #error after that section
<dmart> ...unless the package is built with -DTHREADMODEL=NOTHREADS
<asac> ok can we use a pastebin != ubuntu?
<dyfet> Hmm...we could also do that :)
<persia> asac: Why?
<asac> thats just annoying. you cant wget the plain text because of openid
<dmart> any suggestions?
<asac> just pastebin.com
 * persia thought that was fixed, but tends to have trouble parsing other pastebins
<lool> dmart: debian's work
<lool> alias debian-paste='pastebinit -b http://paste.debian.net'
<asac> every pastebin works ... just paste.ubuntu.com is broken
<lool> \o/  :)
<asac> i already kicked #is for that ... seems they didnt listen
 * asac does that again
<lool> persia: It got fixed and borken a couple of days later sadly
<lool> asac: It was fixed for a day or two
<dmart> I don't know the answer to thathttp://paste.debian.net/59542/
<dmart> oops
<dmart> http://paste.debian.net/59542/
<persia> That's one I can parse cleanly :)
<asac> dmart: thanks. i did it manually now
<asac> uploaded
<dmart>  /bin/bash ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2  -pthread -DTHREADMODEL=POSIXTHREADS      -c GThreads.cpp
<dmart>  g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2 -pthread -DTHREADMODEL=POSIXTHREADS -c GThreads.cpp  -fPIC -DPIC -o .libs/GThreads.o
<dmart> In file included from DjVuMessageLite.h:74,
<dmart>                  from GThreads.cpp:76:
<dmart> GString.h:745: note: the mangling of 'va_list' has changed in GCC 4.4
<dmart>  g++ -DHAVE_CONFIG_H -I.. -I. -Wall -g -O2 -pthread -DTHREADMODEL=POSIXTHREADS -c GThreads.cpp -o GThreads.o >/dev/null 2>&1
<dmart> File seemed to build OK
<persia> So we conclude that this code path is never exercised, and just leave the comment as a note?
<asac> i uploaded the patch that would catch it for __thumb__
<asac> thats ok imo
<persia> As it turns out, yes :)
<dmart> If it's considered OK to add #error (provided it's for a case we know definitely won't work)
<asac> we should upstream that or suggest the right way ... e.g. bx
<dmart> yes, it might be a good idea to make the comment clearer
<asac> dmart: i think for cases where we cant try the code path its ok to use #error ... otherwise we should obviously fix it
<ogra> next package ?
<persia> I'm perfectly happy to use #error as a base of test builds, and if we don't hit the code path, replace with a useful comment.
<ogra> gmp seems small
<dmart> Probably worth discussing this one a bit further first
<dmart> persia: Why is a comment (which will go unnoticed) better than #error (which won't)
<ogra> well, what if we hit it and have no solution ?
<asac> i think #error is fine. we should upstream that so they know
<ogra> hope for upstream ?
<dmart> #error potentially saves someone a lot of debugging
<asac> ogra: we would have a solution. but we cant test it because the code is not used
<persia> dmart: I want *both* the comment and the #error : the #error to force it not working if the codepath is hit, and the comment to tell someone why we added that patch.
<asac> so should we add something untested? or just ad an error
<dmart> Oh, OK.  Yes adding extra explanation in a comment is of course a very good idea :)
<asac> persia: right. thats what we did
<asac> we can improve the comment on next one though
<asac> +#ifdef __thumb__
<asac> +#error "This code needs some porting to work correctly in Thumb."
<asac> +#endif
<asac> maybe point to the porting page
<dmart> good idea
<asac> anyway. lets move on
<asac> gmp ;)
<dmart> Since djvulibre is a simple example, I think it's worth discussing how we would fix it (if we needed to)
<dmart> Someone suggested bx
<dyfet> dmart: yes :)
<ogra> dyfet, did
<ogra> #define ARM_MOVPC "bx%? , %1"
<dmart> ... so far so good, but it's worth taking a step back and looking at the context of this code so we are sure we're doing the right thing
<dyfet> Well, I was not sure what the %? was about....but essentially something like that...
<asac>                     "mov%?\t%|pc, %1"     // branch to address %1
<asac> so it uses that to branch to %1 ... which is .... hmm
<dmart> I _think_ we could pretend the %? is not there.  I can't think of anything vital that it would do.
<dmart> but best not to alter that aspect of the code in the fix in case it matters
<dmart> scrolling up a bit
<dmart> static void
<dmart> mach_start(mach_state *st1, void *pc, char *stacklo, char *stackhi)
<dmart> Scrolling up a bit more, mach_state contains a jmp_buf
<dmart> So this looks like a long jump / thread starting function if some sort.
<dyfet> Yes, a funny kind of procedure call to start a thread....
<dmart> %1 is the argument pc, which is just a pointer
<dmart> But it's not a function pointer which is slightly suspicious
<dmart> ...because it could be passed a pointer to some data (containing run-time generated code)
<asac> dmart: its a func pointer
<asac> just not declared explicitly
<asac> mach_start(&st1, (void*)th2relay, stack, stack+sizeof(stack));
<asac> void th2relay() {
<dmart> certainly that's the likely case --- I was just going to suggest seeing how it's called, but you beat me to it :)
<asac> and pc is the second argument
<asac> ok lets grep for mor mach_start ;)
<asac> the other is startone
<persia> line 950
<asac> which is also a func
<asac> persia: right. thats the function where the asm code is in
<asac> we are looking for callers now to see if its always a func
<asac> so ... based on that is bx %1 still the right thing?
<dmart> After a couple of examples, we can be reasonably confident, since passing a function is certainly how we would expect a thread start func to be used.
<asac> right
<dmart> but I just wanted to highlight the issue
<dmart> Oh, btw:
<dmart> %? - condition code used only in conditional execution.
<dmart> %| - some kind of register prefix and legacy assemblers. Largely irrelevant today.
<dyfet> it was a good educational example :)
<asac> dmart: where did you find that?
<dmart> Um, our tools guys here ;)  I'll try and get it merged in the docs if it's not upstream
<asac> ok good. so are we confident enough to replace the error with bx %1? or want to keep the error as its not used?
<persia> I think we should keep the error, but maybe add a comment suggesting bx %1 : we can't test the codepath, so we have no way of knowing if our solution works.
<dmart> before that, I was going to talk about what would happen if we were passed a data pointer here
<persia> Given that it's already uploaded, I think we should leave it alone.
<dmart> Maybe someone wants to guess?
<asac> ok
<asac> dmart: bad things
<asac> dmart: trying to call in data memory
<JamieBennett> :)
<asac> exploitable
<dmart> But what if the data is code?  Maybe the caller created a trampoline sequence.  (GCC does this internally for some things)
<asac> then it just runs that code?
<asac> or is there some protection stuff going on?
<dmart> well, you need to synchronise and data and instruction caches and flush the pipeline, so that the code executed is what you wrote.
<dmart> This is what the GCC builtin __clear_cache is for (look at the docs)
<dmart> ...however, this is not a Thumb-2 specific issue, so we would not expect to need to fix that if it already worked in ARM.
<asac> oh cool. so i assume those steps are generated at each "real" function started by gcc?
<dmart> Well, the kernel always does this when paging in an executable page
<dmart> So for the text sections of programs and libraries, you never need to worry.
<dmart> Only self-modifying code or programs which generate code at runtime need to be concerned about this.
<asac> ok good info. thanks
<asac> ok move on to gmp?
<dmart> There certainly were some packages like that in the list...
<dmart> still wanted to make one more point:
<asac> erlang was marked as "potentially creating code"
<asac> sure go ahea
<asac> d
<dmart> JITs, VMs, interpreters etc. should be treated with extra care for these reasons.
<dmart> ...
<dmart> anyway, a non-Thumb aware program which generates code an runtime probably generates ARM instruction encodings (not Thumb)
<asac> right
<dmart> Such packages may need extra attention.  Especially if the generated code may be called by other random (probably Thumb-2) code, or calls out to other functions (also probably Thumb-2) ... it's unlikely to work out of the box
<dmart> Anyway, enough on that for now, until we find a real instance ;)
<asac> maybe mono ;)
<ogra> *shudder*
<asac> ok so gmp?
<dmart> Going back to the suggestion of how to fix djvulibre
<asac> ;)
<asac> hehe
<asac> endles story it seems
<dmart> (I know, nearly finished!)
<asac> (but good to have all details first)
<dmart> ... we're just trying to jump to a passed function pointer
 * persia likes the long explanation, having not much prior understanding
<asac> ack
 * ogra too
<dmart> I thought this would be a good idea --- the wiki page has lots of details, but may not be so easy to understand as an example
<dmart> Anyway, BX <register> is definitely the right way to do jump to a function pointer where we don't expect to return.
<dmart> So adding a comment to this effect would be a good idea, something like
<dmart>  /* instead of "mov pc, <register>", "bx <register>" should be used on ARMv5 and above */
<asac> ok let me add that too and upload ... next time i will wait longer ;)
<dmart> sorry!
<persia> dmart: No need to apologies.  asac is just impatient :)
<dmart> I'm sure I can think of something else to add when you're done ;)
<dmart> We could add the wiki link for completeness
<asac> #ifdef __thumb__
<asac> /* instead of "mov pc, <register>", "bx <register>" should be used on ARMv5 and above */
<asac> #error "This code needs some porting to work correctly in Thumb: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto"
<asac> #endif
<asac> thats what i have now ;)
<asac> are we happy with that?
<dmart> cool, looks good
<persia> Seems sufficiently complete.
<dmart> Of course, it might have been quicker just to fix it :P  but it helps to educate more people this  way.
<asac> itsw really good ... especially since i know that at least persia is eager to work on these things ;)
<persia> dmart: The risk with fixing it is that we can't test the code path, so we have no way to know if the "fix" worked.
 * dmart spies a volunteer
 * persia doesn't really know assembler, and will be slow, but willing
<dmart> agreed, it's better not to commit anything we can't test
<dmart> only joking
<asac> dyfet is definitly a senior volunteer ...
 * asac goes with persia 
<asac> anyway
<asac> so thanks. do we want to look at a second package now?
<dmart> Generally best to stay out of assembler as much as possible (it would certainly make this porting job easier)
<dmart> Yes, if people want to grab that I'll just fetch a quick cuppa
<dyfet> well, in gmp, we have a function return in mpn/arm/copyi/d.asm, and in udiv.asm we find mov pc, lr also...at least to start with :)
<JamieBennett> mov's in copyd, udiv and copyi
 * JamieBennett goes to get a coffee
<ogra> copyd.asm looks like a copy paste job from the wiki :)
<dyfet> and copyi.asm...
<ogra> yeah, its the same
<ogra> all three actually
<asac> so who wants to prepare a patch suggestion?
<asac> feels like its exactly as on the wiki ;)
<dyfet> L(return):
<dyfet> #ifdef  __thumb__
<dyfet>     bx  lr
<dyfet> #else
<dyfet>     mov pc, lr
<dyfet> #endif
<asac> dyfet: on the wiki it uses something else for ifdef
<dmart> Hmmm
<asac> #ifdef (___ARM_ARCH_4T__) || defined (__ARM_ARCH_4__)
<asac> ...
<asac> #else
<dmart> These are not C files
<asac> "bx     lr"
<asac> oh right ;)
<dmart> Separate assembler files are a bit of a different animal
<asac> how annoying
<dyfet> Yes, that's right...
<ogra> yeah, no ifdef i guess ?
<asac> whats the best way to do this if we dont want to do a full copy?
<dyfet> well, unless you want to use cpp in front of it, ogra :)
<dmart> For assembler files which are preprocessed by the C preprocessor (.S) you can use ifdef in the normal way
<dmart> But it looks like these are processed by m4
<dmart> So we probably need to get a configure argument passed in somehow
<asac> nice
<asac> lovely
<dyfet> And then use a .ifdef, .else,.endif
 * dmart knows nothing about m4
 * asac_ had to clone himself
<dmart> Assembler macros could work as you suggest
<dyfet> L(return):
<dyfet> .ifdef  thumb2_config_from_config.m4...
<dyfet>     bx  lr
<dyfet> .else
<dyfet>     mov pc, lr
<dyfet> .endif
<dyfet>  as a starting point....
<dmart> But there are no magic predefined macros in the assembler to tell you what your build target it.
<dmart> yep, something like that
<dyfet> Yes, so we have to feed it into one of the included files which are generated....
<dmart> Or maybe you could have a common macro somewhere else
<dmart> .macro return register:req
<dmart>         .ifdef <blarg>
<dmart>                 bx \reg
<dmart>         .else
<dmart>         mov pc, \reg
<dmart>         .fi
<dmart> .endm
<dmart> Anyway, that should work
<dyfet> that too would be a good idea....
<dmart> Exactly how to create the configure argument, I'm not sure
<dmart> You could preprocess some C with #ifdefs to check the architecture version and look at the output, e.g.
<dyfet> we have to see how config.m4 is created since it includes it...
<dmart> #if defined(__ARM_ARCH_4__) || defined(__ARM_ARCH_4T__)
<dmart> use_mov
<dmart> #else
<dmart> use_bx
<dmart> #endif
<asac_> acinclude.m4
<asac_> has GMP_INIT
<asac_> i think there are various options ... not sure we should discuss them here
<dmart> Agreed, I think everyone understands what's needed.
<dmart> Once we've done this once, we can reuse the solution if it's needed again.
<dyfet> lets ask this, is there any other porting issue in gmp other than the mov instructions?
<dmart> good question --- we should always take a careful look at any assembler which pops up
<asac_> "uses mov; also "add" assumes arm"
<asac_> thats the comment we had from review
<dyfet> yes....thats why I asked :)
<asac_> what does add assumes arm mean? dmart ?
<dmart> I meant "assumes it's running as ARM instructions and not as Thumb instructions"
<asac_> yeah
<dmart> There's a bit more info on this on the wiki page at PC and "." arithmetic and position-independent addressing
<dmart> But in brief, when you read pc in Thumb, the result is not that same as you'd get if you were executing in ARM.
<asac_> ok so we are looking for add.*pc here?
<asac_> mpn/arm/invert_limb.asm:	add	r2, pc, #invtab-.-8
<dmart> That's the one.
<dmart> In ARM, when you read PC, you (usually) get the address of the current instruction + 8
<dmart> So this trick gives you the address invtab in r2
<asac_> right
<asac_> whats the right way to find a good offset?
<dmart> But in Thumb, pc is different.  You get <address of current instruction> + 2 or 4 (depending on the alignment of the instruction in memory)
<dmart> It is possible to work out the correct offset, but ugly
<dmart> ...and you need #ifdefs or other special cases hacks for ARM versus Thumb
<dmart> ...
<dmart> Fortunately, the assmbler can do it for you
<dmart> There's a special pseudo-op to get the address of a nearby label in the text section:
<dmart>         adr <reg>, <label>
<dmart> The assembler actually assembles
<asac_> yeah ... finally found it on porting page ;)
<dmart>         add (or sub) <reg>, pc, #<magically determined offset>
<asac_> so we use adr r2, #invtab ?
<dmart> It's not usual to have the # (it might be a syntax error)
<dmart> but otherwise, that's correct
<dyfet> yes...and no conditional...
<dmart> This is a really old assembler feature, so it ought to be possible to make the change and upstream it as-is
<dmart> ...
<asac_> so adr would work on arm too?
<asac_> feels like
<dmart> Yes, the only thing that changes is how the offset is worked out
<dmart> A couple of things to watch out for:
<dmart> add <reg>, pc, #label - . - 8 is a special case which maps directly to addr
<dmart> If the code actually tries to skip the first word after label, e.g.
<dmart> add <reg>, pc, #label - . - 4
<dmart> ...you'd need to take this into account:
<dmart> adr <reg>, label + 4
<dmart> But really, the best thing to do is to create another explicit label in the right place and reference that directly.  It's harder to break, that way.
<asac_> ok
<dmart> ...
<asac_> so here we have:
<asac_> add     r2, pc, #invtab-.-8
<asac_> invtab is a label with short data stuff
<asac_> so after that we have the address of the invtab first short in r2?
<asac_> or is that not what its supposed to do?
<dmart> Yes, I think it wants the address of the first short (i.e., the address of the label invtab) in r2
<dmart> (the previous point I made doesn't apply here, but might apply elsewhere)
<asac_> so given we already have a label ... just adr r2, #invtab feels ok
<asac_> but you said its rather adr r2, invtab ?
<dmart> yes, that should work
<asac_> what does #invtab mean? maybe it means "relative"
<asac_> Ã
<asac_> ?
<asac_> e.g. you add the relative distance of that label to what is currently on pc
<asac_>  - 8
<dmart> # is just required syntax in some cases, generally before a numeric constant.  Best not to think about it actually meaning something.
<asac_> oh right. now i remember about the constant
<dmart> ...
<dmart> A point to make about out-of-line assembler files
<dmart> as does not default to assembling Thumb code
<dmart> So this code will be assembled as ARM
 * asac back here
<dmart> ...
<asac> hmm. so you say its all ok? or we should fix the build system to use thumb2?
<dmart> It's actually fine for bits of ARM code to exist, so long as they return in the right way (this is what we were talking about earlier), and so long at they are called in the right way.
<persia> Is there a reason we shouldn't change the default?
<dmart> persia: we did investiate, but changing the default is not really supported and breaks too much stuff
<dmart> In any case, Thumb-2 helps to reduce code size, and that's a bit different from speed optimisations.
<dmart> If we only built 90% of the codebase in Thumb, that would still give us most of the overall code size benefit.
<asac> right
<persia> Makes sense.
<dmart> So "if it's not broke, don't fix it" is probably the best policy
<asac> ok ;)
<dmart> ...
<asac> so we can scratch most code that is in ssembler
<dmart> yes and no
<dmart> We still need to be a bit vigilant in places, depending on how the code is used.
<dmart> Suppose we had some assembler code which accepted the address of a callback as one of its arguments?  The callback might be the address of a Thumb-2 function
<dmart> Similarly we need to return to the caller in the right way (using bx)
<dmart> In this case, these look like leaf functions which are called from C (and don't call any other functions), so we just need to make sure the return is correct
<asac> ok that makes some sense indeed
<dmart> This is why we particularly grepped the archive for things like mov pc, <something>
<dmart> This is the classic way to do the equivalent of calling a function via a pointer in C.
<asac> yeah
<asac> so i dont see this asm snippet returning
<dmart> Which bit?
<asac> mpn/arm/invert_limb.asm
<asac> well. i dont see how to check if it returns properly according to what you have said
<dmart> ...
<dmart> Ah, good point -- I should explain this one
<dmart> ...
<dmart> To jump to a value in a register, you can use mov pc, <register>, or preferably bx <register>
<asac> yes. thats what happens on the caller side i guess
<dmart> Could be, though there's a special procedure call instruction BL <label> (branch with link) which is more likely to be used in that case, as long as the location of the label is known at compile time (usually)
<asac> ok. so do we jump back ;)?
<dmart> It magically sets the link register (lr) to the correct return address
<dmart> ...
<asac> ah
<dmart> So what happens to that in this function?
<dmart> It gets saved on the stack at the beginning:
<dmart>                 stmfd   sp!, {r4, lr}
<dmart> "STore Multiple Fully Descending {r4 and lr} at sp and update sp"
<dmart> On x86 we would say "push"
<asac> ok so we have the lr on stack
<dmart> ...
<asac> and then we jump back like:
<asac> ldmfd   sp!, {r4, pc}
<asac> ;)
<dmart> Indeed, this is the "pop", and we can restore the pc at the same time to get back where we started.
<asac> what is r4 used for?
<dmart> You might wonder why we don't need to change this to support thumb, whereas the other cases needed a BX
<ogra> yes, i was wondering that
<dyfet> yes...me too
<dmart> On ARMv4T (the earliest version of Thumb), this was indeed necesary.  You had to:
<dmart>       pop {r4}
<dmart>       pop {r0}
<dmart>       bx r0
<dmart> (or something like that)
<dmart> ...because BX was the only way to switch instruction set
<dmart> ...However we don't need to worry about this: from ARMv5 onwards, all the "load pc from memory" instructions switch instruction set as needed, provided that the bottom bit of the return address was set to the right thing.
<asac> nice
<dmart> So as long as the call side was done right, we're OK
<asac> can you explain to me why r4 is involved at all in these things?
<asac> stmfd   sp!, {r4, lr} -> ldmfd   sp!, {r4, pc} ?
<asac> i would think that its just sp + lr ... and then sp -> pc
<dmart> r4 is saved because it's used in the function
<dmart> The procedure call standard required you to restore some registers if you change them
<dmart> gcc assumes you play nice when generating the code for C functions
<asac> oh ... now i see
<asac> btw, whats a good arm asm reference?
<dmart> Generally, only the first argument of an instruction is modified, so you might expect to see r4 at the start of some instructions, but there is none.
<asac> some handy online resource would be great ; )
<dmart> Oh, I tell a lie, there is         addcs   r4, r4, #1
<dmart> (looks up a documentation link)
<asac> addcs   r4, r4, #
<asac> rigt
<asac> ;)
<asac> anyway. i guess there is a special instruction that also modifies r4?
<asac> otherwise you wouldnt have started like it ;)
<dmart> Yes, I was trying to be clever...
<dmart> umull ("Unsigned MULtiply Long") produces a 64-bit result, and so it has two output arguments:
<dmart>         umull   lr, r4, ip, d
<dmart> bah, our documentation portal seems to be down, but I'll post a link to the ABI docs when I have it
<dmart> In brief though:
<dmart> If you clobber r4-r11 you need to restore them (and obviously sp needs to be the same as it started off to balance the stack)
<dmart> ...
<asac> yeah
<dmart> Nowadays the stack is supposed to be kept 64-bit aligned, so you might want to check for pushing odd numbers of registers.
<dmart> In fact, new code may uselessly save an extra register to achieve this:
<asac> registers are 32?
<dmart> yes
<asac> or different?
<asac> ok
<dmart> This is only required if you call other functions
<dmart> Basically, gcc is allowed to assume that the stack is 64-bit aligned at the entry of every function, and ensures that this is still true when calling functions.
<dmart> Is assmbler code, you need to be careful not to mess up this assumption.
<dmart> ...
<dmart> Final point: is the assmbler code used at all?
<dmart> (should have asked this at the beginning ;))
 * dmart touches those files and rebuilds
<dmart> OK, it looks like that code is used
<asac> gmp-impl.h:    (invxl) = mpn_invert_limb (xl);     \
<dmart> I wondered if this was ancient optimised code which is no longer used (and a C implementation might have been used instead)
<dmart> This is the case in some of the packages on our list (like zip where there's some old code that was written for RiscOS)
<asac> i dont see an alterantive impl for that
<asac> i would assume its used ;)
<asac> so ok. for gmp we have two things:
<asac> 1. fix mov in the .asm files (special casing using m4)
<asac> 2. fix the invert_limb thing to use adr rather than add
<asac> oh
<asac> 2. only if we build with thumb
<asac> i think we said we are ok to keep it "arm"
<dmart> That's true, though since we've spotted it it might be worth fixing anyway, since it's cleaner and won't trap someone trying to migrate this code to Thumb-2.
<dmart> But I'm happy either way.  If we don't fix it we could still add a comment.
<asac> right. so on top of 2. we need to switch the AS to thumb mode
<asac> how is that done?
<dmart> My recommendation is: don't bother
<asac> ok -mthumb
<asac> hmm
<asac> dmart: so fix it, but dont switch?
<dmart> We could, of course, if it turns out to be easy
<asac> right. lets first fix code. and then see if we can switch as easily
<asac> if not, leave it alone
<asac> since dyfet seemed to be fluent on the m4 stuff i will assign the bug to him ;)
 * lool attacked the qemu-kvm armel ftbfs
<dyfet> Okay
<dmart> If you really want the assembler in Thumb, you need to use assembler directives in the files.
<asac> ok updated bug
<dmart> -mthumb doesn't really do what we want in this case (as interprets the code as Thumb-1, which means most code written for arm will fail to build anyway)
<dmart> I'll try to add some details about this on the wiki
<asac> ok thanks
<dyfet> in this case we are concerned more with performance than size
<asac> ack
<asac> but having all thumb2 ready would be nice
<dmart> Or ftbfs -> crash -> performance -> size
<asac> ok. so we didnt get much done, but i think it was a good start
<asac> thanks dmart ;)
<asac> i would like to take a break before the call we have in 30
<ogra> phew ...
<dmart> sure
<asac> feel free to continue though
<asac> i think ogra dyfet and co are happy ;)
<dmart> I think we did enough for today - it was really just to introduce people to the issues
<asac> yeah
<dmart> I'll try to hang around on IRC, so if in doubt please ask :)
<asac> i think it made sure we we are all getting started
<dyfet> asac: I have to deal witht the furnace people for a little bit, but yes, I think it was an excellent start
 * ogra notices that there are not many leftovers of the asm he once learned a decade or more ago :/
<dmart> cool
<asac> dyfet: ogra: persia: StevenK: maybe read the porting wiki carefully to get more detailed info. should be easier to read now we got the intro ;)
<dmart> ogra: Sort of; more that there's a lot of new stuff though
<dmart> comments welcome - it's not 100% complete and was written in a hurry
<dmart> I will dump the log of this conversation on the wiki (in advance of tidying it up)
<asac> good idea
<ogra> lool, can you reestore the topic ?
<dmart> thanks everyone
<ogra> thanks a lot dmart !
<dmart> I'll talk to asac offline about arranging another sprint sometime soon - then people could have a go at porting packages and we can discuss together as needed.
<persia> I was just taking a look at insighttoolkit as a potential task, as there's a number of rdeps and rbuilddeps.  It seems to use "mov pctemp, eax" : am I correct that this is a likely false positive hit?
 * lool passed   CC    arm-softmmu/exec.o
<persia> (because it doesn't seem to be branching with that instruction)
<lool> \o/
<persia> lool: Nice!
<lool> ogra: Is the sprint over?
<ogra> lool, congrats !
<ogra> yes, it is
<dmart> lool: yes, we'll wrap up for now
* lool changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | build probs with your packages in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2
 * dmart wonders how to alert everyone on the channel
<persia> dmart: alert them to what?
<dmart> End of the session.
<dmart> I guess changing the topic works OK
<persia>  /topic changes are usually sufficient, yes.
<dmart> fair enough
 * lool channel-wide alert
<ogra> heh
<dmart> ;)
<lool> dmart: Mind taking a look at http://paste.ubuntu.com/374082/?
<lool> I built arm-softmmu/qemu-system-arm under armel successfully with it
 * lool now attacks a full build
<dmart> persia: your mov pctemp, eax in insighttoolkit is almost certainly a false positive.  ARM and x86 both have a "MOV" instruction, but eax is an x86 register name (arm reg names are always two letters, or r<number>)
<dmart> lool: what package it that? qemu?
<lool> dmart: qemu-kvm, but this patch is against qemu tip
<dmart> oh, right
<persia> dmart: Thanks for the confirmation.
 * persia goes to look for something else
<dmart> lool, so spin_lock makes use of testandset ?
<lool> dmart: Yes
<dmart> Looks sensible to me... I guess the code is already tested on other SMP arches
<dmart> lool, should the typedef for spinlock_t be volatile int?
<lool> I just tested building, and then only on armel; I think I'm going to apply it to lucid's qemu-kvm and if that works ok, I will submit it upstream
<lool> dmart: The other typedefs aren't, but I tend to agree that it would be a good idea
<dmart> I think the GCC atomics do the necessary, but I guess it won't hurt to make it volatile
 * ogra would actually like to see someone running qemu-system-arm under armel ... heh
<lool> dmart: It doesn't make any difference in practice because these are only written to once to init them
<lool> e.g. spinlock_t tb_lock = SPIN_LOCK_UNLOCKED;
<dmart> The atomics write them, but it probably doesn't have to be volatile for that to work
<dmart> http://www.google.com/search?q=itanium+abi+atomic
<lool> Ack; I'll submit this as a separate patch when I upstream gcc atomics
<dmart> OK
<lool> Hopefully it wont take another two months   :-/
<dmart> For anyone still listening, the procedure call standard and other ABI docs for ARM can be found on
<dmart> http://infocenter.arm.com/
<dmart> Browse to RealView software development tools -> Application Binary Interface -> Procedure Call Standard for the ARM Architecture (etc.)
<persia> Only saeed left :)
<persia> So, the next one I picked (lwp) seems to only have "mov pc, r0" in a .S file.  We decided to leave those alone, because they are going to end up as armel instructions anyway, right?
<lool> I have a funny error
<lool> /home/ubuntu/qemu/qemu-kvm-0.12.2/fpu/softfloat-native.c:373: error: impossible constraint in 'asm'
<lool> The code is: http://paste.ubuntu.com/374093/
<persia> And float_relation_* are essentially constants?
<lool> I guess
<lool> It's technically possible to reach float_relation_unordered for some float numbers such as nan
<ogra> lool, btw, i think amitk said ppoll pselect are upstream now
<ogra> (in mainline)
<lool> Indeed
<lool> and I'm adding a patch to stop them from barking
<lool> I wonder whether we should just backport this stuff instead
<ogra> just quieting it or implementing them ?
 * ogra doesnt mid either since there is a properl fallback in libc afaik
<ogra> (referring to your patch)
<lool> It's just very noisy right now
<ogra> yep, i rarely see that, rootstock hides such stuff
<ogra> but in chroot tests its annoying, i agree
<lool> It's not trivial to backport the pselect6() impl
<lool> It depends on at least two other commits
<lool> git cherry-pick is broken for me for some reason
<lool> In fact git is completely borken hmm
<ogra> use bzr ... i always told you :)
 * ogra hides
<Hoonse> i am back =)
<Hoonse> hi guys
<lool> wow
<lool> I'm failing at backporting it because *it's already in*
<ogra> heh
<lool> Does someone have a rough idea of how long it takes to boot dove lucid?
 * ogra can only give numbers for imx
<ogra> its roughly after 40sec at the full desktop
<ogra> (netbook-desktop that is)
<Hoonse> i think i will make the rootfs new... what do i have to add to --seed when i want the gnome gui and not the xfce4?
<ogra> Hoonse, depends, full ubuntu would be ubuntu-desktop
<ogra> i think an upstream plain gnome flavour was only added in karmic
<siji> hi ogra,
<ogra> that would be gnome-staciatella then iirc
<Hoonse> thanks.... ok this will be a long time AGAIN for waiting till the script is finished =)
<ogra> well, upgrade your host to karmic ;) its way faster
<Hoonse> for what projects do you all use the BeagleBoard?
 * ogra doesnt use a beagle ... its collecting dust on the shelf
<Hoonse> but you bought it for a reason? or just for the reason to collect dust =)
<ogra> i got it handed by somebody
<Hoonse> well i think this is an awesome piece of hardware...  the best since the microkopter project...
<ogra> it is ...
<Hoonse> orga: guess what... today i also installed the wireless-tools and the network-manager... =)
<armin76> quick
<persia> Hoonse: So everything is working for you now?
<persia> armin76: ?
<lool> suihkulokki: I'm looking at linux-user/syscall.c, and see I'd need to add some copy_from_user_timespec and to_user and pselect would very much be like select; I find macros would be a bit long and ugly, and real functions would add a small performance penalty, do you see a way we could share the code yet keep it readable and fast?
<lool> suihkulokki: Also, is it ok to unconditionally use the hosts' pselect or do I have to check whether it's available and support arches where it's not?
<zumbi> lool: is this croco?
<lool> zumbi: It's just qemu-linux-user
<lool> Not specific to croco
<lool> croco rocks, I need to resume working on its integration
<lool> Just haven't taken the time
<zumbi> yes :-)
<zumbi> it rocks! time is always the problem
<Meizirkki> Hi all
<Meizirkki> Is the Karmi ffmpeg NEON accelerated?
<Meizirkki> Karmic*
<Meizirkki> Or is there a specific ppa for it ?
<armin76> Meizirkki: its not
<Meizirkki> I heard there was ppa with NEON accelerated ffmpeg somewhere ..?
<jds> is there a special command line "sentence" for autologin on ubuntu (no username and password type in)
<persia> Hoonse: Depends on the desktop environment, but there's usually a way to select autologin from the greeter control tool.
<Hoonse> xfce4 is the desktop enviroment...
<Meizirkki> NCommande, were you dealing neon wccelerated ffmpeg ?
<Hoonse> oh sh.. it seems that the network-manager isnt happy with my WEP key...
<Meizirkki> lool ?
<Meizirkki> did you have the ppa containing ffmpeg w/ neon optimizations?
<Meizirkki> armin76, does the lucid version have neon acceleration ?
<armin76> Meizirkki: ubuntu doesn't nor will use neon afaik
<Meizirkki> ok, thanks
<Hoonse> is it normal that network manager takes reeeaaallllyyy long to connect to a wifi network and a few times shows up the question about the wep key when always entered?!?
<Hoonse> omg this sucks... -.-
<lool> asac: oo.o works again on armel??
<lool> When was that fixed?
<lool> ogra: Do you know?  ^
<ogra> lool, it still carries the hack
<lool> ogra: thanks for confirming
<ogra> welcome
<lool> You guys have any recent bootchart on armel hardware?
<ogra> http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png netbook launcher is up after ~40sec
<ogra> well, visible after about 35
<ogra> disregard the panel and stuff, there are applets missing so its starting delayed atm popping up errors
<lool> thanks
<lool> ogra: that's with SD?  or SATA rotational hard disk?
<ogra> SATA
<ogra> rotational
<amitk> ogra: ppoll is upstream in 2.6.32
<NCommander> armin76: ping. Is OOo known to work on Gentoo with ARMv6/ARMv7 optimizations?
<suihkulokki> lool, huh?
<suihkulokki> NCommander: do you plan to fix OOo build on gcc 4.4?
<ogra> suihkulokki, he does :)
<NCommander> suihkulokki: I'm going to take a stab at it :-)
<lool> suihkulokki: Sorry, context was implementing pselect in qemu/linux-user
<NCommander> suihkulokki: I fixed thunderbird. This codebase can't be much worse
 * NCommander feels like those might be famous last words
<ogra> NCommander, its just way bigger  ... and the issue is in uno
<NCommander> ogra: right, I'm reading through the channel logs from that era to remember the detials
<NCommander> *details
<suihkulokki> lool, unconditional should be ok, the kernel will just give a err if not supported
<ogra> well, it should be supported across the board now
<lool> Ok; I was wondering whether it was ok to require recent linux-headers
<lool> but pselect is old indeed
<lool> some platforms might not have it, I wonder whether it's in the headers in this case
<suihkulokki> NCommander: I think OOo is worse ;) good luck, that fix would be appreceated.
<ogra> ++
<NCommander> suihkulokki: I assume its also broken in Debian?
<lool> Yes
<NCommander> suihkulokki: does building with gcc 4.3 fix the issue? (just for a reference point)
<ogra> NCommander, yes
<suihkulokki> NCommander: yes. iirc it was a binutils rather than gcc issue
<ogra> its clearly a toolcahin issue
<NCommander> ogra: right, I'm just getting up to speed. I was working on Thunderbird during most of the OOo fun
<lool> As I personally recall, we realized that downgrading both binutils and gcc helped, but when we bisected binutils we found another bug which ended up not fixing oo.o
<lool> ogra: well it could be an oo.o issue too
<lool> oo.o is using some quite special toolchain API and has a copy of some unwind headers stuff, it's really an awfully complex piece of code
<ogra> lool, i doubt it, but it could be indeed
<lool> ogra: The code which crashes in openoffice is the one converting C stacks to uno stacks
<lool> so it's very low-level stuff
<ogra> yeah
<lool> Anyway we'll see
<suihkulokki> iirc the toolchain people were suggesting it is OOo issue
<suihkulokki> it was mentioned on debian list
<NCommander> suihkulokki: debian-arm?
<lool> I think so as well
 * NCommander probably should subscribe to that :-)
<lool> It might be that oo.o has to be updated in lockstep with some very deep toolchain API
<suihkulokki>  NCommander that or debian-release
<ogra> NCommander, you should definately be on debian-arm (and if its only for seeing the shiny new netbook stuff they are discussing there :) )
<NCommander> ogra: I was on d-arm, I think I accidenlty unsubscribed myself when I purged out mailing lists I didn't read anymore
<asac> NCommander: your call ;)
#ubuntu-arm 2010-02-12
<therealgalen> anybody use cavium ARM CPUs? or know of products using them?
<suihkulokki> therealgalen: I think the cavium arm cpus arr very new products, so not many users yet
<therealgalen> they're not that new i don't think
<therealgalen> i
<therealgalen> i see the product announcement in like... 2008
<NCommander> suihkulokki (and anyone else around): do you know much about GCC? I might have a lead on the OOo breakage
<NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009/comments/55
<ubot4> Launchpad bug 417009 in openoffice.org (Ubuntu Karmic) (and 3 other projects) "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic (affects: 1)" [Low,Won't fix]
<armin76> dmart: get me a mwc2010 pass!
<dmart> armin76: not wanting to be rude, but I don't know who you are and am not in a position to get anyone passes for anything...
<lool> dmart: armin76 is our uber-excited gentoo developper trying to get as much hardware and invites as he can   ;-)
<dmart> ah... I will enquire, but I don't even know how the mwc invitees are determined ...
<lool> dmart: Do reserve the invites to ubuntu devs, not gentoo devs though!   ;)
<dmart> armin76: apologies if I sounded suspicious! /whois didn't give me any info to go on.
<lool> http://armin762.wordpress.com/about/
<lool> wont tell you much more though
<dmart> thanks
<armin76> :D
<armin76> dmart: nah, thats okay
<armin76> dmart: just remember that i'm better than lool!
<dmart> sorry, we hadn't been introduced
<persia> armin76: Are you still working with the EfiKa MX?  How stable do you find that?
<armin76> Hostname: efikamx - OS: Linux 2.6.31-ER1/armv7l - Distro: Gentoo 1.12.13 - CPU: ARMv7 rev 1 (v7l) - Processes: 118 - Uptime: 49d 17h 46m - Users: 4 - Load Average: 0.00 - Memory Usage: 72.32MB/470.49MB (15.37%) - Disk Usage: 30.55GB/461.23GB (6.62%)
<persia> 49 days?  Do you use this as a build machine?
<armin76> no crash so far as you can see
<armin76> yep
<persia> USB disk, or am I reading the spec wrong (it only says 4GB SSD)
<armin76> usb disk, yes
<armin76> i'm not using the ssd
<persia> It boots from USB?
<dmart> We got to 99 days on some boards (no crash though, just rebooted to solve an NFS screwup.  This was using SD/NFS, not USB)
<armin76> hrm...why wouldn't it?
<armin76> atm i'm booting using the kernel on the ssd
<armin76> but thats it, init=/bin/sdb1
<persia> Oh, booting from SSD, with filesystem on USB.  That makes sense.  I was hoping for a raw boot from USB :)
<armin76> err
<armin76> root=/dev/sdb1
<armin76> well, i haven't looked into that, tbh
<amitk> is that a tapeout 2?
<armin76> but the sheevaplug does, why this shouldn't do?
<armin76> amitk: y
<amitk> so NEON is broken?
<armin76> broken how? i haven't tried neon at all
<dmart> armin76: can you cat /proc/cpuinfo?
<dmart> There's a "Revision" line
<armin76>  http://dpaste.com/157892/
<armin76> http://dev.gentoo.org/~armin76/arm/efikamx/v3boot.log <- bootlog
<dmart> 2.5
<asac> ogra: any more work item to scratch for rootstock? ;)
<ogra> asac, not today, sorry
<asac> ncommander not here?
<asac> anyone knows status of qt4-x11?
<ogra> nope
<ogra> afaik he did only work on likewise and since yesterady he digs around in openoffice
<persia> asac: What about qt4-x11?
<asac> i thought michael worked on that for a reason i cant remember
<asac> its on our thumb2 porting list
<asac> thats why it came back to my mind
<persia> Ah.  He did work on it some time back.
<ogra> he was supposed to make it build, scottk asked for it last release meeting
<persia> It built.
<ogra> right, not on ftbfs anymore
<ogra> didnt you work with him on that ?
<ogra> i saw some chatter about sip
<persia> Not in great detail.
<persia> dyfet: So, I was looking at Thumb2 porting for lwp, and the only instruction that appears to be suspicious is in src/process.S : am I correct that we don't need to do anything because this will end up being ARM code?
<dyfet> Let me look at that one...hold on...
<persia> ./src/process.S:738:	mov	pc, r0
<dyfet> Even if the assembler blocks are arm code, will it be potentially called from thumb2 code?
<persia> That's the sort of thing I don't know :)
<dyfet> If so, then yes, this should be changed to bx r0, because otherwise you cannot switch instruction modes
<persia> This seems to be a function return call, but I'm kinda guessing
<persia> And do I care about all the mov ip, sp stuff?
<dyfet> It is, but it might be only back into it's own code...this is an interesting example :)
<persia> Heh.  So, how would I go about trying to figure out whether it needs switching?
 * persia isn't doing so well picking packages: the first was a false-positive, and the second is "interesting"
<dyfet> Well, we have to go a little further back, and understand what this is.  I think it is a pesudo-context-thread start routine.  I think we cannot be certain what is ran after..
<persia> I see lots of savecontext() calls in various .c files, so I'm thinking it's likely being called from Thumb2 code.
<dyfet> I think so too
<asac> https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
<asac> dyfet: ogra: persia: plars: GrueMaster: StevenK: JamieBennett:^
<asac> seems we get an earlier slot ... please check quickly ;)
<persia> asac: Do you still care about "main and office webservice specs landing" post-Alpha3?
<persia> I thought I saw chatter in -devel about that from rickspencer3 a few days back.
<ogra> asac, bug 507416 is fixed for uboot since a long time
<ubot4> Launchpad bug 507416 in uboot-imx (Ubuntu Karmic) (and 5 other projects) "CONFIG_NEON=y causes platform lockups with certain application/platform combinations (affects: 2)" [Undecided,New] https://launchpad.net/bugs/507416
<dyfet> another thing to look at is stmfd...gcc expects the stack to be 64 bit aligned
<asac> kk
<asac> persia: yes i care about that
<asac> why?
<persia> Just wanted to make sure it wasn't leftovers.
<asac> ogra: is redboot ready?
<asac> for the NEON thing
<asac> persia: no ... it was an addition. thanks
<ogra> sure
<ogra> redboot was always ready :)
<plars> asac: the two bugs mentioned under bugs with fix available are the same bug
<asac> for NEON ... cool
<asac> plars: but differnt package?
<plars> asac: yes, just a separate task for each kernel
<asac> oh
<dyfet> persia: I think lwp is a good example, actually
<persia> dyfet: Good.  Maybe I can use this to build confidence for the next one :)
<persia> dyfet: So I want to change line 738 of process.c ?
<persia> And that ought do it?
<dyfet> Since the assembly is inline in C, we can also use the C preprocessor....well, we need to look at the rest, but that seems the most clear issue, yes
<persia> Is this inline?  It's in a .S file.
<persia> I thought that meant it was an external function.
<dyfet> It is still being processed in c, lets look at the Makefile, though...
<dyfet> .S.o:
<dyfet>     $(COMPILE) -DPIC -fPIC -c $<
<dyfet> And COMPILE in the Makefile is defined as using $(CC)...
<persia> # Needed for mips, hopefully doesn't affect other platforms
<persia> Would it not instead call .S.lo: ?
<persia> Mind you, it's still $(CC)
<dyfet> Yes...it's a libtool archive presumably, and yes, still calling $(COMPILE), which brings us to the c compiler.
<dyfet> It's actually a hacked rule for libtool/automake to treat the .S as a .c source for the purpose of building it.
<persia> So anything done by gcc is "inline" even if in separated files?
<dyfet> well, normally a .s file is the assembler generated output of a c source, so I am guessing they originally wrote a c function, used gcc to create an assembler source, and then hacked that as needed.
<persia> which explains the special discussion in PORTING
<dyfet> And why they commented out the original C code in it
<persia> So I'd just change that to bx r0 in a patch, and expect it to work?
<dyfet> Yes, it still uses the c pre-processor, so we can use the patch suggested in the porting guide directly
<persia> OK.  Now, this doesn't seem to be architecture-specific code.  Does "bx r0" work for arbitrary architectures?
<asac> JamieBennett: there?
<dyfet> It is arm specific, each processor has it's own unique instruction set
<dyfet> the most commonly encountered one is the x86 instruction set(s), which I think are rather feature poor, but that is another topic :)
<asac>  nice ... seems there is porting work going on ;)
<asac> dyfet: one question. what happened to boost1.40 ... did i fail to sponsor that?
<persia> dyfet: Ah, I see it now: "#if defined(__arm32__) || defined(__arm__)" : so this is just safe to patch away, right?
<asac> (sorry if i already asked ... was busy with release team and preparations")
<dyfet> asac: good question, did you fail to? :)
<asac> dyfet: if you gave me a good debdiff then yes. do you have that still ;)?
<dyfet> persia: yes, welcome to arm porting :)
<dyfet> asac: let me look
<asac> thanks
<dyfet> asac: I also recall i did it slightly different in 1.41...
<asac> right
<asac> dyfet: the build system, right?
<dyfet> yes...let me look at that quickly...
<dyfet> asac: I also recall, it was not a clean patch, from something I broke when first experimenting with quilt...
<dyfet> I could quickly redo it...
<persia> dyfet: So, does http://paste.ubuntu.com/374832/ look right to you?
<dyfet> Well...going back to the excellent arm porting wiki page https://wiki.ubuntu.com/ARM/Thumb2PortingHowto...
<dyfet> It should be conditional on armv5 or later...
<persia> Ah, I should be wrapping it in an ifdef
 * persia fixes
<dyfet> well, it is the correct thing to do for our debian upstream, which is built armv4
<persia> It's QA maintained, so I'd be looking at fixing that next :)
<persia> Does http://paste.ubuntu.com/374837/ look like the right contents of 02-thumb2-porting.patch ?
<dyfet> yes
<persia> Excellent.  I'll push this then.  Do you have any suggestions for a good candidate for my net attempt?
<persia> Or maybe you could do one and explain along the way?
<dyfet> I can shortly, I am quickly getting a patch ready for asac :)
<persia> OK.  No rush :)
<persia> suihkulokki: Just to verify, is there any reason that one *wouldn't* want to apply something like http://paste.ubuntu.com/374837/ in Debian?
<fta> asac, "mobile-lucid-arm-lightweightbrowser: decision pending"  what's the current trend?
<ogra> fta, wait for google to commit some kind of release cycle
<ogra> else security team will block
<fta> ogra, it's pretty clear as it is now
<ogra> you mean that they wont do releases ?
<fta> they do
<fta> linux,dev,5.0.307.5
<fta> linux,beta,5.0.307.7
<fta> linux,stable,0.0.0.0
<fta> beta just jumped today
<fta> no stable yet
<ogra> right
<ogra> i think thats the prob
<ogra> but asac might know more, i'm just echoing what i heard in the release tema meeting 30min ago
<ogra> *team
<fta> ok
<dyfet> asac: http://pastebin.com/f4207b842
<persia> dyfet: So, what's the next package?
<suihkulokki> persia: looks sensible, but preferrably apply via upstream
<persia> suihkulokki: So I should't look to a QA upload, but instead send it upstream directly?
<suihkulokki> oh, lwp is orphaned. just go for QA upload then.
<persia> And I presume I'll also add the patch to the BTS, and then forward that upstream when wearing a QA hat?
<suihkulokki> You can forward it wearing any hat your prefer, but yes :)
<persia> heh, OK.  Thanks for the guidance.
<Hoonse> hi guy
<Hoonse> s
<persia> Hey Hoonse
<Hoonse> does anyone know how to setup wifi via the terminal? i think the network-manager hates me... and the vi editor hates me too...
<armin76> NCommander: haven't tried ooo on arm
<armin76> i didn't know it built
 * persia pokes dyfet again in hopes of more Thumb2 porting stuff
<armin76> could try if you want...
<persia> armin76: Could you?  Most of it builds, except this little pesky bit :)
<persia> armin76: Works fine in Debian and in Jaunty, but we started having issues in karmic when the toolchain changed to support more modern CPUs.
<suihkulokki> armin76: http://www.youtube.com/watch?v=J6Z__mepK-Y
<NCommander> persia: no, its broken on Debian with gcc 4.4
<persia> NCommander: It is?  Ugh.
 * persia has seen so many Debian demos that it seemed inevitable that it would keep working
<armin76> should i try with gcc-4.4 i guess?
<NCommander> armin76: yes please
<NCommander> armin76: it takes upwards of two days to build on an imx51 board though
<armin76> its okay, i have the efika doing nothing
<suihkulokki> on thecus it takes a week =)
<armin76> and plenty of space
<NCommander> On an NSLU, it would take a lifetime :-)
<dyfet> persia: where did we leave off?
<persia> dyfet: You were grabbing a package and I was going to follow along
<dyfet> I was? okay, let me look at the list...
<dyfet> Although it was done, and a patch was submitted, since I just updated that, lets look at boost for a minute...
<persia> Could we look at a new one?  As much as I'd like to learn, I'd rather be productive while learning :)
<dyfet> okay
<dyfet> pixman is listed as needs to be checked...
<dyfet> its not clear if it has an issue or is simply suspected, lets take a look...
<armin76> whats up with pixman?
<dyfet> armin76: it was on the https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
<persia> armin76: It's suspected of having assembly routines that may not be safe for context switching and internetworking
<armin76> ok :)
<dyfet> it may take a bit longer, though...it's suspected, but not clearly identified
<persia> armin76: Feel free to jump in if you'd like to help.  I'm sure the patches could be interesting for some of your stuff as well (and we'd certainly appreciate them)
<armin76> i remember a gentoo user having issues with running non-neon kernel and latest pixman...
<armin76> well, i don't think i can't be of much help, but if somethings rings a bell i'll say it
<persia> That's probably a different issue, unless they also compiled with -mthumb2
<armin76> yeah, definitely
<armin76> but is something to keep in mind for dove
<persia> armin76: Depends on your time of course, but dyfet seems to be an expert, and at least I'm learning mostly from scratch
<dyfet> This one may not be a great pick, though, it will take a little time to see what specific issues it may have
<persia> dyfet: The note says something about mov, so I've started with `grep -rn mov *`
<dyfet> Yeah, but that is not a lot to go on :)
<persia> I have a feeling that pixman/piman-cpu contains the bulk of the data for investigation.  But thre's also pixman-arm-simd
<dyfet> lets compare with https://wiki.ubuntu.com/ARM/Thumb2PortingHowto to see if anything stands out...
<persia> Oh, and arm-neon, but are we using that?
<dyfet> That is controlled by USE_ARM_NEON in the Makefile, from configure...
<dyfet> There is also a --disable-arm-simd in configure and --disable-arm-neon...
<dyfet> Let's look at the debian rules to see what is enabled...
<persia> Which makes me think we mostly care about pixman-cpu
<persia> No special --enable or --disable.
<dyfet> nope...
<persia> So that means enabled-by-default, right?
<dyfet> No...there is configure tests...
<dyfet> Let's look at the debian rules to see what is enabled...and a couple of try compile flags
<dyfet> it might well enable neon build by default if gcc allows it
<armin76> persia: dyfet: ssvb may be interested in what you have to say wrt pixman
<armin76> he's the one who has been doing the arm stuff upstream
<dyfet> armin76: we probably should ask him.  I suggest, for expediancy, we punt on pixman for this session for now and pick another from the list
<armin76> haha
<dyfet> well, lots of things that require time to look at :)
<persia> dyfet: Works for me :)
 * persia likes simple examples to learn stuff that can then be applied easily.
<dyfet> well, I am appearently not great at picking simple ones either :)
<persia> How about parrot?  At least that has a clear comment.
<dyfet> hmm....
<dyfet> yes it does
<dyfet> this should be very quick
<persia> That's what I thought.  I'm hoping you'll run through it and it will match my expectations.
<persia> Then I can probably fix that class of stuff easily.
<dyfet> okay :)
<persia> (and I'll ask you about the next class if I run out)
<ssvb> dyfet: if you could tell me what you think is wrong with pixman, that would be a great help
<ssvb> dyfet: btw, what is your target hardware? if it is Coretex-A8 r1pX, it has a lot of thumb related problems which need workarounds
 * persia is happy to wait on other examples to let pixman be investigated
<persia> ssvb: We're trying to be fairly generic, although ARMv7 and Thumb2
<asac> dyfet: look at the comment i posted on the boost1.40 bug ... i adjusted your debdiff a bit ... but now sponsoring
<asac> just some nit
<ssvb> I just want to say, if you are testing thumb/thumb2 code on a hardware which has problems (and no workarounds are applied), you are going to have problems for sure
<ssvb> you may be just wasting time looking for bugs in software...
<persia> ssvb: At this point, we're not really looking for bugs, but for assembly routines we believe to be unsafe with context swtiching and internetworking.
<persia> Stuff like changing "mov   pc, r0" to "bx r0" conditionally for ARMv5+
<dyfet> ssvb: we thought it might be a simple case example :)
<ssvb> ah, this should be pretty easy
 * persia grabs the pixman code again, expecting to learn lots
<dyfet> persia: speaking of which, parrot is an interesting special case.  It emits assembler as part of it's jit...
<persia> dyfet: Right. I'll unpick that one then :)  Let's do pixman whilst we've ssvb around.
<dyfet> okay
<persia> ssvb: So, I checked before, and I think the majority of candidates for investigation are in pixman-cpu.c, pixman-arm-neon.c, andpixman-arm-simd.c
<dyfet> yes...
<ssvb> I may be missing something, but thumb interworking is only involved when functions are fully implemented in assembly
<ssvb> this basically rules out practically all *.c sources
<persia> Oh, I thought I saw some inline stuff in those.
 * persia checks again
<ssvb> maybe with the exception of some really weird stuff
<persia> Yeah, there's deinitely inline assembly in those three files.
<persia> pixman-cpu seems to be only x86 code though, and appropriately "ifdef'd
<ssvb> inline assembly can only have thumb interworking problems if it contains function calls, which almost never happens typically
<dyfet> and even that code is limited to cpu detection
<persia> ssvb: So you think pixman is safe?
 * persia doesn't see any mov pc lines, but isn't confident that this is enough to be sure
<dyfet> It maybe is a false positive
<ssvb> I'm not aware of any problems and actually did test it with thumb2 a bit
<ssvb> but one can be never sure completely, that's why I was interested to know if you have spotted something  :)
<persia> Right then.  I'm glad we did this, as it helps me understand how to decide *not* to patch things.
<dyfet> ssvb: not specifically, but since it was on the high priority list, I wanted to make sure we looked at it
<ssvb> the only problem I know is that pixman-arm-simd just does not compile for thumb and it is a bit ugly :/
<dyfet> ssvb: ok :)....that seems an apt description :)
<dyfet> I have to check another bug for a few minutes
<dmart> I was busy editing the wiki and didn't watch this chat closely...
<dyfet> If you want to pick another package in the interum, persia, I am not sure if any of the remaining high priority ones are good picks for training though
<persia> dyfet: Sure.  I'll try to pick one out.
<dyfet> dmart: hi :)  I saw the chart you added :)
<dmart> The call/return stuff was a bit of a braindump, so hopefully the summary helps a bit
<persia> dmart: Main interesting things were that we got a fix for lwp, and determined that we didn't think pixman needed a patch.
<dmart> The offending lines we grepped in pixman were:
<dmart>  ./pixman-0.16.2/pixman/pixman-arm-detect-win32.asm:    mov pc,lr
<dmart>  ./pixman-0.16.2/pixman/pixman-arm-detect-win32.asm:    mov pc,lr
<dmart> These would need fixing if that file gets built... but "win32" rather suggests is doesn't apply to us.
<ssvb> yes, it's windows specific code
<dmart> OK, if it's not build for Linux we don't have to worry about it.
<dmart> It's getting late here, so I will disappear in a minute...
<persia> dyfet: How about xindy?
<persia> dmart: Have a good evening.
<dmart> Feel free to add comments on the wiki if you'd like to see something clarified better!
<dmart> (or poke me next week)
<dyfet> persia: the review list suggests its a simple issue...
<persia> dyfet: Well, OK.  Go do something hard then, and I'll see if I can do xindy :)
<dyfet> well, okay :).  I will follow along with what your doing though :)
<persia> dyfet: How about newlib ?
<persia> dyfet: I suspect that if I work on xindy and you work on newlib, you can share what you've done, and I can ask questions :)
<dyfet> persia: we have nothing depending on newlib...but okay
<persia> Oh, then I'm just lousy at picking :)  You pick one.
<persia> openssl?
<dyfet> okay, but I have one other thing I need to look at first
<persia> Sure.
 * persia grumbles at bundled sources : why not use modern clisp
<armin76> NCommander: going to mwc?
<asac> unlikely ;)
<armin76> asac: going to mwc?
<asac> wasnt on my radar :(
<asac> and i am sick anyway
<armin76> ubot4: going to mwc? :D
<ubot4> armin76: Error: I am only a bot, please don't think I'm intelligent :)
<asac> ogra: i have a question about LtSP_CLIENT ... is that an upstream env?
<asac> e.g. can we commit the applet not starting on LTSP_CLIENT patch upstream?
<asac> (NM applet)
<NCommander> persia: I can't figure out why kdebindings is waiting on okular, it should be installable
 * persia looks
<persia> NCommander: install only, not build,right?
<NCommander> persia: yeah, its built
<NCommander> persia: doing sudo apt-get install libokularcore1 says it needs phonon
<NCommander> doing sudo apt-get install libokularcore1 phonon asks if I wish to install packages :-)
<persia> "E: Couldn't find package kdebindings" with just refreshed apt-cache
<persia> What am I installing?
<NCommander> persia: kdebindings is the source package
<NCommander> persia: apt-get build-dep kdebindings :-)
<persia> That's why I asked "install only, not build, right?" :p
<NCommander> persia: huh?
<persia> I was asking whether you seemed to be stuck on "install", meaning some sort of arch skew, or "build" meaning issues getitng the build-deps sorted.
<persia> apt-get build-dep kdebindings works for me, with an up-to-date cache, although it will be another half-hour before it finishes installing all the build-deps.
<NCommander> persia: right, it did in an installed system
<NCommander> persia: clean chroot with main only, it didn't work
<persia> Aha.  I always forget to check that.
<NCommander> persia: but everything seems to be in main
 * persia is writing a script to check, and getting sufficiently annoyed by sed to do it manually.
<NCommander_> persia: any luck?
<persia> NCommander: I've stripped to main-only, and managed to replicate your symptom.  I'm investigating now.
<Guest88140> persia: thanks
<persia> Guest88140: Takes me a while though: I need to set up a mirror some day, or convince someone to mirror p.u.c domestically.
<Guest88140> argh
<Hoonse> is it normal that the internet on ubuntu on the beagleboard is really slow? i mean REEEEEALLY slow
<NCommander> Hoonse: slow as in firefox, or slow as in using wget?
<Hoonse> slow that when a desktop pc downloads with 400kb/s the board loads with 1kb/s?!? by apt-get install...
<NCommander> Hoonse: oh, apt-get on ARM uses a different server
<NCommander> ports.ubuntu.com is in the UK and can sometimes really drag :-)
<persia> NCommander: This would go faster if qemu supported syscall 335, if you're bored :)
<Hoonse> oh... i got really wiered trubble with setting up this god dammed wifi...
<Hoonse> i am almost crying =)
<Hoonse> loool 2.875 B/s i feel thrown back to the 56k times =)
<Hoonse> 240B/S but this cant be normal!!!!!
<NCommander> Hoonse: try another webite
<Hoonse> this cant be possible!!! the ftp UPLOAD to the board runs at the begining  with 2,5 kb/s then a short time with 220kb/s and then it seems like it would freeze?!? why is my wifi on this board so buggy?
<persia> NCommander: Looks like the schroot issue is related to some hang when building the documentation.  Could you run a local build (probably overnight) to see if it ever completes or produces an error?
 * persia suspects the "solution" is to split the docs into an arch:all package
<NCommander> Hoonse: wifi on ARM is virtually untested
<NCommander> (under Ubuntu)
<Hoonse> that means?
<NCommander> Hoonse: there may be latent bugs that haven't been found; that being said, there might be issues with the beagle wifi hardware AFAIK
<persia> Hoonse: That I'm the biggest user, and I run jaunty.
<NCommander> persia: I can only use the porters box, no clean chroots. The imx51 board I'm SSH'ed into is grinding away at openoffice for at least another day
<persia> NCommander: Nevermind then.  I'll run it next time I can leave my netwalker plugged in for long enough (as I have pbuilder working there).
<NCommander> persia: I just got new imx51 hardware today, but all the stuff I need to set it up is back in Rochester :-)
<persia> No worries.  I'm just both impatient and wanting to take my hardware out and about in a couple hours :)
<NCommander> persia: I look forward when I can do ARM porting on my laptop
 * NCommander might just buy a Dell netbook with one of those ARM chips and force Ubuntu ARM onto it if I could get the specs on the ARM SoC
<persia> You can do some now: depends on the nature of the issue.
<persia> But in this case, I'm dealing with a timing issue, which would benefit from real HW.
<persia> (or at least it *looks* like a timing issue)
<persia> But I think small servers are better than laptops for that sort of thing anyway, because one likes to suspend a laptop (otherwise I'd be building schroot now)
<NCommander> asac: ping?
<NCommander> er, wrong channel
<NCommander> persia: any ideas on my dep issue?
<persia> NCommander: Most recent message: "E: Failed to process build dependencies"
<persia> This is after manually installing phonon and libokular1
<persia> Err, libokularcore1
<persia> NCommander: I'm running into unexpected mono-related crashes, so I think I can't track it easily.
<persia> But I'll admit to not understanding it.
<NCommander> persia: so do I ping next?
<asac> NCommander: did you ping me somewhere else too?
<persia> NCommander: Well, either give me time (I'm not at my best at this time of day unless I've only been awake for <5Ksec), or whine on kubuntu-devel and hope someone can sort it.  Personally, I think the main limit here is the relative lack of people with hardware.
<NCommander> persia: its not a huge rush thing, I'll look at it more later, but I was wondering who else might know strange resolver bugs
<persia> mvo is probably the expert, but I'm not sure he has an arm device.
<persia> But it's mostly a case of just trying different installation combinations, and seeing what doesn't work.
#ubuntu-arm 2010-02-13
<DanaG> hmm, the versatile kernel doesn't seem to want to boot on my beagleboard.
<DanaG> And it didn't even make a uimage for u-boot.
<Martyn> I didn't know the versatile kernel -could- boot on a beagle
<Martyn> then again, I'm using a Versatile Express (Quad Core A9) kernel
<Martyn> So it kind of depends on which Versatile board you're using
<Martyn> There -are- beagle kernels though...
<DanaG> hmm, I was just hoping for one that had working usb-gadget networking.
<DanaG> I
<DanaG> hmm, so Versatile is a specific product line, not "generic" like on x86 and amd64?
<DanaG> =Ã¾
<Martyn> correct
<Martyn> and it's a product line that spans ARM architectures
<Martyn> so there are Versatile boards with ARMv6, and v7 processors
<DanaG> Might be good to change the package description to say "Versatile[TM]" -- if it's a registered trademark.
<DanaG> use unicode TM, though.
<Martyn> heh
<Martyn> naa
<Martyn> It's just that ARM likes reusing names
<Martyn> And in the ARM world, machines/platforms abound.
<Martyn> however, lets get to what YOU want .. which is a beagle kernel with usb-gadget enabled?
<Martyn> specifically usbnet?
<DanaG> I was using these: http://elinux.org/BeagleBoardUbuntu
<DanaG> It has g_ether seemingly built-in, but it never actually transmits packets.
<DanaG> At least, the host only sees "Ethernet II" frames in wireshark.
<Martyn> Yep, I've got the same kernel
<Martyn> Well, you can download the source and then cross compile your own kernel.
<Martyn> IF you're patient, you can even do it on the beagleboard (compile takes ~2 hours)
<DanaG> eh, cross-compile on a core2duo 2.4 should do that in waaaaaaaaaay less time.
<Martyn> Yep
<Martyn> configuring USB gadget is one of the fiddly drivers
<DanaG> hmm, weird that it doesn't work with those kernels already built.
<DanaG> /sys/bus/pci/devices: No such file or directory at /usr/sbin/sensors-detect line 2453.
<DanaG> well, yeah, there's no pci.
<DanaG> hmm, looks like lm-sensors assumes the presence of PCI.
<DanaG> hmm, so is that usb networking just supposed to not work, by default?
<DanaG> Should I file a bug about it, or not (due to not using an official kernel)?
<DanaG> weird... the first time after I change kernels, the system boots to where it does something... and then auto-reboots once.
<Hoonse> is there any option to get wifi running "stable" under ubuntu karmic on the beagleboard? does the new version come out in february (told in the wiki...)
<armin76> Martyn: going to mwc?
<asac> armin76: maybe put that on /topic ?;)
* asac changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | build probs with your packages in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2 | anyone going to mwc? ping armin76
<asac> hmm ... wonder if http://wiki.debian.org/ArmEabiTodo is actually maintained
<asac> seems last modified in aug last yearh
<armin76> asac: :D
<armin76> he was the last person i was going to ask :P
<asac> you never know ;)
<Martyn> armin76: No, not going to MWC
#ubuntu-arm 2010-02-14
<saeed> lool
<saeed> ogra
<armin76> saeed
<saeed> hi armin
<lool> saeed: Hey
<saeed> as you know, the suspend button worked for me
<saeed> but when I convert it to KEY_POWER , and configure the g-p-m to "Ask Me" when power pressed
<saeed> nothing happens
<saeed> when I configure the g p m to suspend when power pressed, it works
<persia> saeed: So, g-p-m is capturing your button press, but not launching the GUI when configured to "Ask Me"?
<lool> saeed: In a terminal, killall gnome-power-manager and then run gnome-power-manager --verbose
<lool> saeed: That should give you some debugging info on what GPM is seeing
<saeed> persia yes exactly
<therealgalen> What is everybody using to build for ARM? Are there particular compilers that are optimized for ARM?
<armin76> codesourcery's
<therealgalen> armin76: fastest?
<persia> therealgalen: We use native compilation in Ubuntu: compiling ARM on ARM.
<therealgalen> persia: I don't mean the hardware so much as the software - the compiler
<therealgalen> a lot
<therealgalen> of vendors claim to have "faster" or "better" compilers
<persia> Ah.  I don't think Ubuntu claims faster or better, but I know a lot of work has gone into making it appropriate for ARMv7+Thumb2
<persia> But no special secret sauce: most of the changes are upstream, so I suspect anyone could grab them if they felt it was a competition.
 * persia is more concerned about making the software work than about the compiler being especially fast
<therealgalen> persia: architecture-specific issues, or just general development?
<persia> Both :)
<persia> Although a lot of what I personally do is actually neither, but rather just things like improving developer tools to make it easier to do those, or reviewing cases where something didn't build for reasons involving how the distribution is developed, etc.
<therealgalen> well, i am looking at a variety of companies offering gcc alternatives claimed to be faster; i was hoping to hear from people who have tried them
<armin76> therealgalen: its known to be the most optimized, yes
<therealgalen> armin76: are there any benchmarks *not* from the vendor online?
<persia> armin76: optimised for which?  execution time, code size, compilation time, etc.?
 * persia is fairly certain it's not possible to optimise for those three things simultaneously, and suspects there are other similar variables.
<therealgalen> execution performance primarily; compilation time does not matter, code size does not matter
<armin76> persia: no clue, its just what they tend to say
<armin76> persia: in fact they tend to say that vanilla gcc sucks
<armin76> therealgalen: no clue, sorry
<persia> therealgalen: From what I understand, it really depends on which code you need so optimised.
<persia> Try a few different toolchains, and see which one compiles your application in the fastest way.
<therealgalen> hmm, ok
<therealgalen> persia: most of the functions are kernel stuff, ath9k, ec.
<persia> The kernel gets kinda fussy about opimisation.  Generally, I think it's better to walk the code path and optimise in code than try to adjust toolchains for that class of issues.
<persia> Just because the kernel code makes some assumptions about how it will be compiled.
<DanaG> oh heya, where do I get the ARM toolchain for cross-compiling stuff?
<DanaG> apt-cache search gcc doesn't show anything related to ARM.
<persia> We don't cross-compile :)
<persia> we just rebuilt everything natively.
<DanaG> How'd you get the first one up, then?  =Ã¾
<persia> Used Debian's compilation.
<armin76> they stole it :D
 * persia prefers to think of it as "sharing"
 * DanaG wishes somebody would make something like that "touchbook" but with the new Marvell 1.2GHz thingy.
<DanaG> The worst embedded thing I've ever (tried to) use: Microblaze. It was so bad, that building the cross-compiler made the HOST compiler segfault!
<DanaG> hmm, what systems do you run the armel compilation on?
<persia> I'm not sure precisely.  I suspect there's at least one package that shows it in the build log, but :)
<persia> I do know that they are ARMv7 machines.
<persia> Personally, I do test-compilation on a Sharp Netwalker, but we only upload sources.
<DanaG> Oh yeah, worst distro fail I've ever seen was Angstrom on a Zaurus SL-5500.  I can understand drivers not working... but to have your kernel config for that board not enable the ALREADY-IN-KERNEL drivers for that board?  That's just epic fail.
<DanaG> I wish I could get Ubuntu running on the thing.
<persia> The 5500?  That's too old.
<persia> Jaunty should run on the 1000, 1100, 3000, 3100, 3200, and 3300
<persia> But karmic or lucid won't.
<DanaG> My gripe was that they discontinued OpenZaurus in favor of the supposedly superior "Angstrom" -- but then seemingly didn't even TRY to make the old hardware work.
<DanaG> Having it work slowly and poorly... fine.... but disabling in-kernel touchscreen driver?  fail.
<DanaG> Anyway, now I'm using a beagleboard, and that's cool.
<persia> Well, Sharp discontinued the device, which may have had something to do with that.
<persia> You're running lucid on your beagleboard?
<DanaG> Yeah.
<DanaG> Still, they could've at least set CONFIG_UCB1100_TS true, or whatever that was.
<DanaG> anyway, enough bashing Angstrom.
<DanaG> I'm using Ubuntu on it because it'll be just like my main development environment.
<DanaG> Too big for the onboard flash, though -- I'm using a 2-gig SD card.
<DanaG> hmm, is there anything useful I COULD use the onboard flash for?
<persia> I think we still need a slightly better way to dispatch test-builds to other machines though.  I have to manually scp sources to armel or powerpc devices from my laptop to build them.
<persia> But other than that, I think it works just fine.
<persia> How big is the onboard flash?
<DanaG> I think it's just 256 megs.
<armin76> i didn't know the bb had internal flash
<DanaG> And u-boot takes up some of that.
<persia> That's tight.  You might be able to stuff your kernel and initramfs in there.
<persia> But I don't think you can do anything advanced with it.
<DanaG> Might as well just leave it on initramfs.
<DanaG> now, this would be cool, if not for the tiny battery: http://eeepc.net/superthin-netbook-runs-on-marvell-armada-510/
<DanaG> Oh yeah, I did have a lot of trouble getting the usb host-to-device networking working.... it was encoding the packets badly (off-by-one error).
<persia> Nobody seems to want to put a full-size battery in with a low-power device.  I really wouldn't mind an extra 100g for an extra 10 hours of power.
<DanaG> yeah, that sucks.
<DanaG> My network issue: I set guest device to mac address 00:11:22:33:44:55, and the parent saw "Ethernet II" frames from address ff:ff:00:11:22:33 sending packets of type 4455.
<persia> Well, it probably also costs an extra 12,000å for that extra 100g, which makes it perceived as less competitive.
<DanaG> What currency unit is that?
<persia> Wah!  That's just not right :)
<DanaG> I finally fixed it by passing g_ether.use_eem=0
<persia> Oh, right.  That gets used in multiple contexts.  JPY is what I was thinking.
<DanaG> then it used full cdc-ether instead of cdc-subset.
<jonnor> Hi. What libc implementation is being used in Ubuntu ARM?
<armin76> windows!
<armin76> jonnor: eglibc
<jonnor> armin76: cool, thanks!
<DanaG> heh, note to self: ext4 as root on flash means I can't use ext2load.
<DanaG> init: ureadahead main process (41) terminated with status 5        mountall: Could not connect to Plymouth       init: procps main process (369) terminated with status 255        init: ureadahead-other main process (466) terminated with status 4
<DanaG> that's on the beagleboard.
<ogra> seems your kernel misses a good bunch of options and plymouth isnt installed
<ogra> none of these issues should stop it from finishing the boot though
 * ogra goes back to weekendish stuff
<DanaG> init: ureadahead main process (40) terminated with status 5
<DanaG> oh yeah, I don't plan to use the video output for much (at least for now), anyway.
<DanaG> Also weird: the default user's named group is not 1000 like it is on the host system.
<DanaG> beagleboard has this:
<DanaG> mtdparts: mtdparts=nand:512k(x-loader),1920k(u-boot),128k(u-boot-env),4m(kernel),-(fs)
<DanaG> !find pkg-config
<ubot4> DanaG: Found: pkg-config
<DanaG> =Ã¾
<DanaG> odd that command-not-found doesn't seem to work on ARM.
<DanaG> !find dbus-glib-1
<ubot4> DanaG: Found: libdbus-glib-1-2, libdbus-glib-1-2-dbg, libdbus-glib-1-dev, libdbus-glib-1-doc
#ubuntu-arm 2011-02-07
<Homefix>  this message ic comming from ubuntu installed on my EVO
<jhobbs> tsk tsk, irc'ing as root!
<sveinse> Hi. Regarding the alsa profile issue this weekend: Our kernel developer sais that the extra alsa driver text fields are ubuntu specific. Is that correct?
<sveinse> Are there any rules/practices regarding numbering of udev rules? I need to insert a rule for mounting a USB memory device, and I'm trying to figure its number
<ogra> rsalveti, your new phone you got in dallas, was that a galaxy 9000 ?
<rsalveti> ogra: nexus s
<ogra> ah, k
<hrw> which is nearly same ;D
<hrw> hw wise
 * hrw has nexus s
<ogra> right, i thought so
<ogra> (my provider wants me to pick a new phone for free .... its that time of the year again :) )
<sveinse> optimus perhaps ?
<ogra> optimus ?
<sveinse> http://www.engadget.com/2010/12/15/lg-optimus-2x-first-dual-core-smartphone-launches-with-android/
<ogra> ah
<ogra> to late, i just picked the samsung
 * rsalveti lunch
<hrw> ogra: galaxys?
<ogra> hrw, yep
<hrw> I wonder when TI will start making pandas bootable directly from usb...
<hrw> I am going to be sdless...
<hrw> my last card - 8GB microsd
<ogra> buy new ones ... and expense them
<hrw> will have to
<hrw> uf. this card works
<reb`> I bought a Pogoplug and installed Arch Linux from the PlugApps web site.  Is this the best option for this ARM box?  I run Ubuntu at home and at work, but it appears that the latest Ubuntu does not support PogoPlug aka SheevaPlug.
<LetoThe2nd> reb`: pogoplug is the marvell kirkwood platform, right?
<reb`> Something like that ... first generation Marvell architecture ... same as original SheevaPlug.
<LetoThe2nd> reb`: then it's supported until ubuntu 9.04, ut not longer.
<reb`> Are there any independent sources for more recent Ubuntu releases compiled for that platform?
<LetoThe2nd> none that i knew.
<reb`> I'm not unhappy about Arch Linux, it's just that package management is different, system init files are different, etc.
<reb`> LetoThe2nd: Thanks!
<hrw> reb`: use Debian or Arch
<rsalveti> hrw: I believe you can already boot over usb
<rsalveti> I remember having someone discussing this at the pandaboard m-l
<hrw> rsalveti: without sdcard at all?
<rsalveti> usb = micro usb
<prpplague> rsalveti: there are about a half dozen utils for usb booting
<rsalveti> afaik, yes
<prpplague> rsalveti: including a new usbboot tool and nishant's u-boot utils
<rsalveti> yup, that's it
<rsalveti> thanks :-)
<rsalveti> hrw: have fun
<hrw> prpplague: but how does it work? omap4rom will read xloader from ehci->thumbdrive or expect tool talking to it by usbdevice port?
<prpplague> hrw: rom code inits the OTG as a host port, then sends a specific enumeration id
<prpplague> hrw: the client software on the host pc reads that and begins an upload of code
<rsalveti> like what we had for omap3
<prpplague> hrw: once the code upload is complete, the rom code jumps to the start address of the code
<prpplague> rsalveti: exactly like omap3
<hrw> so no use for me. I expect panda to not depend on other devices for boot
<prpplague> hrw: what is your use case?
<hrw> prpplague: during last week I throw 3 sd cards into trashcan. wondering about other ways to boot panda
<prpplague> hrw: ?? what were wrong with the cards?
<prpplague> hrw: why wouldn't the usboot stuff work for you?
<hrw> prpplague: random filesystem failures all over the card
<hrw> prpplague: or cards which magically changed their capacity from 4GB to 0
<hrw> prpplague: panda is far from other machines
<reb`> hrw: Is Debian closer to Ubuntu as far as package management and other system stuff is concerned?
<hrw> reb`: no. its reverse direction
<hrw> reb`: Ubuntu is derivative of Debian
<reb`> ok
<reb`> So there's a full Debian distribution for ARM Kirkwood?
<hrw> yes
<hrw> reb`: you can officially install debian on (some set of) kirkwood based devices
<prpplague> hrw: interesting, this is the first report i have had of that
<prpplague> hrw: well, what i would do is find a small sd card, and place just x-load and u-boot on the boot partition
<prpplague> hrw: then use either network booting for kernel and root, or use a usb thumb drive
<reb`> Great!  I've had a few problems with Arch Linux / PlugApps -- missing dependency after installing a package, inability to find needed linux-api-headers package, etc.
<reb`> It's probably my inexperience ... I'd be more comfortable with Debian/Ubuntu.
<reb`> hrw: thanks!
<prpplague> hrw: you could program up an avr or msp to boot the panda
 * prpplague has done that before
<hrw> prpplague: normally I have xload/uboot/kernel/initrd on sd + rootfs on usbhdd. but it is hard to test linaro images that way ;d
<prpplague> hrw: ahh
<prpplague> hrw: wish you had saved the sd cards, i would have liked to do a post mortem on the cards
<hrw> Angstrom 2010.7-test-20101105 omap4430-panda ttyO2
<hrw> prpplague: send me your address?
<hrw> ok, kernel compilation under angstrom started. under ubuntu it was enough to get buserror/segfault with mem=1G
<sebjan> hrw: you don't have these crashes with angstrom?
<hrw> sebjan: during fosdem I was told that it was not reproduced there
<sebjan> hrw: hum, ok. If you have some feedback on this issue, here is where we track it: bug 633227
<ubot2> Launchpad bug 633227 in linux-ti-omap4 "instabilities with highmem activated" [High,Confirmed] https://launchpad.net/bugs/633227
<prpplague> hrw: and avr boot dongle would be cute for the panda
<hrw> sebjan: I know about that bug
<hrw> drivers/media/IR/ir-functions.c:111: internal compiler error: in attach_dep_link, at sched-deps.c:227
<hrw> Please submit a full bug report,
<hrw> ha!
<rsalveti> :-)
<ogra> just dont compile through infrared :P
<hrw> make -j44 is nice stress test
<armin76> hrw: fyi i also reproduce them with gentoo
<armin76> hrw: ah, nice, you reproduced it :D
<armin76> thing is all the ppl that have said they don't get such failures turns out they don't compile native :/
<sveinse> How long will pastes in ubuntu pastebin linger around?
<TheUni> rsalveti: have you had a chance to look into xbmc?
<TheUni> i'm getting ready to overhaul our packaging, would be great to have some guru help :)
<rsalveti> TheUni: not yet, last week was busy with alpha-2, planning to put my hand on it this week
<TheUni> ok
<rsalveti> TheUni: sure, probably will start working on this bp tomorrow
<TheUni> bp?
<rsalveti> blueprint
<TheUni> ah, roger. bp means backport for me lately :)
<rsalveti> haha, true
<TheUni> rsalveti: one of the big issues will be bundling ffmpeg
<rsalveti> TheUni: hm, ok
<TheUni> we bundle many libs, which we've been working on moving out. but we're tied pretty closely with ffmpeg
<TheUni> though as we discussed, we're open to adding gstreamer support
<rsalveti> yeah, that would help us a lot
#ubuntu-arm 2011-02-08
<Homefix> anyone help with a chroot problem
 * janimo is a bit irked by OMAP3 being called omap while OMAP4  omap4
<ogra> janimo, thats because the plan is to have only one omap flavour at some point
<ogra> for all omaps
<amitk> one OMAP flavour to rule them all, one kernel to find them, one OMAP flavour to bring them all and in mainline bind them
<ogra> well, its likely that by the time we have -oamp for 3 and 4 we will have a new -omap5 flavour :)
<ogra> but yeah, originally that was the plan
<hrw> ogra: unless TI will start from -omap not -omap5
<ogra> unlikely
<ogra> there will always be a patchset before it goes upstream
<ogra> might be smaller for omap5 but you will still have new code that doesnt get immediately upstream
<vstehle> This should be less and less, now that we have teams focused on upstreaming
<ogra> indeed
<ogra> but you will always have new HW that will need basic development before you can push upstream
<vstehle> Ideally upstream kernel will boot on omap5 when the silicon is there, at least :)
<ogra> thats the nature of things
<ogra> ideally that timeframe is very short
<Tims_> Hello,
<Tims_> can anybody help me, to run an Logitech WebCam on an GumStix (ARM cortex A8 - OMAP 3503)
<ogra> whats the problem ?
<ogra> the ubuntu kernel should have everything you need
<Tims_> but it don't
<Tims_> its ubuntu - lucid - 10.4 - lxde
<ogra> oh, 10.04
<Tims_> I build it with rootstock
<ogra> and your kernel comes from ??
<Tims_> rootstock does everything,
<hrw> Tims_: lsusb, dmesg please
<ogra> it doesnt install a kernel if you dont define one
<Tims_> the order was: âsudo rootstock -f âGumstixâ -l âgumstixâ -p âoveroâ -n âGumstix Overo Ubuntuâ -s lxde,gdm,openssh-server,x11vnc -t âEurope/Berlinâ âserial ttyS2 -d lucid âlocale de_DE.UTF-8'
<ogra> that will only roll a rootfs
<ogra> wont install a kernel or create an initrd
<Tims_> http://pastebin.de/14695
<ogra> your kernel must come from somewhere else (NAND boot probably)
<Tims_> http://pastebin.de/14700
<Tims_> i work on a Gumstix,
<Tims_> overo, maybe it is usefull
<Tims_> ah sorry, of course i get the kernel, i was a little bit blind :D
<Tims_> http://dl.dropbox.com/u/211887/Ubuntu/uImage-2.6.34-r88-overo.bin
<hrw> modprobe uvcvideo
<Tims_> "FATAL: Could not load /lib/modules/2.6.34/modules.dep: No such file or directory
<ogra> shouldnt be necessary if his kernel is proper
<ogra> which it obviously isnt
<LetoThe2nd> hrw: ogra: we've been through all this in #ubuntu-de already.
<LetoThe2nd> his kernel is whacked, but he has no clue how to update or bake a new one.
<ogra> ah
 * LetoThe2nd has repeatedly told him to read documentation.
<ogra> is there probably a modules tarball at the dropbox location you could extract to the rootfs ?
<ogra> if not, you need to roll your own kernel
<LetoThe2nd> and once again: http://wiki.gumstix.org/index.php?title=Kernel_Reconfiguration
<ogra> (i'm not sure how well gumstix is supported by mavericks kernel, but might b worth a try)
<Tims_> i can't look into the dropbox
<sveinse> Where can I find a "good" kernel config for omap3 for maverick? I just need the config file to compare my settings against
<ogra> sveinse, in the linux-image-omap3 package
<Tims_> LetoThe2nd, i can't find this link in #ubuntu-de log, but thanks
<LetoThe2nd> Tims_: you can't find it because i've never mentioned so far. by "go read documentation" i though it would also include "go and search it first". i sincerely apologize for that misunderstanding.
<sveinse> ogra, thanks.  Name being linux-image-omap though
<ogra> oh, yeah
<ogra> though that might only be the meta, check the deps
<Tims_> @LetoThe2nd, no problem
 * LetoThe2nd hands out a few spare sarcasm detectors.
<Tims_> orga, thanks
<XorA> persia: ping
<ogra> GrueMaster, ugh, whats all that assigning to ubuntu-armel ?
<GrueMaster> Open bugs that need to be assigned to the team, but not necessarily an individual.
<ogra> why ?
<ogra> where is the change in our bug policy documented ?
<ogra> we never assigned the team, only individuals
<GrueMaster> marjo was concerned yesterday about the armel bugs that weren't assigned to anyone.  I'm just trying to assign them to the team so they are on our radar (and proper bug report).  I am also weeding out the bugs that we don't care about, so that I can go back and say "not our problem".
<ogra> these should better be assigned to individuals
<GrueMaster> Why is lool reassigning bug 705689 from NCommander to janimo?
<ubot2> Launchpad bug 705689 in qt4-x11 "QT applications crash with segfault error on armel when QT is built with gcc 4.5 on natty" [High,In progress] https://launchpad.net/bugs/705689
<janimo> GrueMaster, possibly because I touched it last? No idea
<janimo> anyway we're going to decide how to fix this porperly together
<GrueMaster> I thought a good first step would be to assign these bugs to our team, then we can take individual ownership from there.
<ogra> because janimo had a workaround for using gcc 4.5
<janimo> so not sure that assignment means much in this particular case.
<ogra> instead of just dumping 4.4 in place
<janimo> ogra, I'd rather wait a bit and see if gcc can be fixed so we don;t need another workaround upload (Especially if the NCommander
<janimo> s's latest one gives us working images)
<ogra> GrueMaster, i'd rather see us doing a dedicated bug triage day with the whole team and see that we can get them all assigned properly
<ogra> GrueMaster, also many are linaro (thumb2 porting) and need to be tagged for the new porting querue
<GrueMaster> Works for me, assuming the bugs actually get worked on.
<ogra> *queue
<ogra> and not be assigned to us at all
<GrueMaster> The porting bugs I am leaving alone.
<janimo> ogra, I see a few of the porting to Thumb2 are oboslete. I mean thumb2 is enabled in most packages. There are other issues -multicore for ex
<janimo> but that is mislabeled as a Thumb2 porting issue
<ogra> janimo, well, we have to decide if we want to work on these or give them to linaro
<GrueMaster> One of the issues is that no one has been closing bug reports when they get fixed.
<ogra> thumb2 porting is usually linaro nowadays
<lool> GrueMaster, janimo: I commented earlier that it seemed to me the bug should be open since it's not fixed, just worked around; I've reopened it since janimo was active on it anyway, and because the assignee was NCommander but janimo was actually the one working on it, I've changed the assignee to janimo
<lool> Hope that makes sense
<ogra> the tag you see is likel old
<ogra> *likely
<janimo> lool, ok,. actually we were both working on it, just on different aspects, but I agree it is still an open bug
<GrueMaster> lool: Both have been actively working on it in unison.
<janimo> as far as gcc is concerned
<ogra> lool, thats why i re-did the description a bit
<janimo> ogra, the FTBFS ones I think we can manage, thre toolchain bugs we must give to linaro
<lool> From the comments on the bug, NCommander seemed to be working on gcc-4.4 vs 4.5 and janimo on fixing the cpp code; I am happy if you folks fix the assignee either way
<ogra> really no need to reassign randomly ... the prob here is that we miss a "workaround applied tag, needs revisiting"
<ogra> lool, both workarounds are done in QT while the bug is a gcc bug
<ogra> which still has the task open
<lool> ogra: I am not sure why you frame this as "randomly"; I think I explained how I picked it; I tried to make the best guess
<ogra> sure, but one is uploaded, the other isnt, neither fixes the root cause, bug is being worked on by both
<ogra> janimo, right, thats what i mean
<janimo> rsalveti, ogra, does the version of x-loader/u-boot used get exposed somehwre in linux while booted and running>
<janimo> ?
<rsalveti> janimo: just at the first partition
<rsalveti> atm
<rsalveti> you can install the packages if you want, but it's not installed by default
<rsalveti> and the version you can check probably by just booting the board
<janimo> rsalveti, yes, I know about t6hose, but was wondering if they get passed to linux in some param and mnaybe readable in proc
<janimo> just out of curiosioty, it is not of much use
<rsalveti> janimo: not something they pass to linux
<XorA> would be real easy to add to u-boot/kernel though
<janimo> rsalveti, I copied over the MLO and u-boot.bin from the new natty packages, and while the panda boots, there's no output on serial as it used to, this is why I wanted to see if I can read the version strings elsewhere
<rsalveti> janimo: no output at all or just after loading the kernel?
<janimo> rsalveti, at all
<janimo> before I saw x-loader print stuff
<ogra> weird
<ogra> but it boots ?
<janimo> ogra, it booted
<ogra> very very weird :)
<rsalveti> so could be a problem with your serial connection
<janimo> I rebooted adn and now I still can;t ssh
<janimo> so maybe it does not boot all the time
<janimo> 115200 is fixed right?
<rsalveti> not booting at all would be kind of "ok"
<ogra> should be
<rsalveti> but booting and not getting you anything is weird
<janimo> rsalveti, I agree
 * janimo takes out the SD card to inspect in the laptop
<ogra> 115200n8 *should* be a default
<ogra> no guarantee that didnt change though
<janimo> I did not touch boot.scr, only copied over two new files
<rsalveti> didn't change
<rsalveti> so it seems that you're not even loading the x-loader correctly
<rsalveti> you can easily check by the panda leds
<rsalveti> once u-boot is loaded both leds should blink
<rsalveti> and then stays on until the kernel gets control of them
<janimo> I have one of the leds blinking more often
<janimo> but sometimes they alternates
<janimo> not on permanently though
 * janimo resets
<ogra> one is SD, one is heartbeat
<janimo> it could be a faulty SD card
<janimo> I had issues with it's seconds root partition and was only using it for booting
<janimo> ogra, the one further away fro the SD slot blinks periodcally
<janimo> actually long pause, blink short pause blink, then repeat
<janimo> time for another SD card
<Homefix1> i need help an error that i get installing DarwinSS in qemu or arm7 device? got a min anyone?
<ogra_> darwin ?
<Homefix1> Darwin streaming server
<Homefix1> I...
<ogra_> no idea about that
<Homefix1> it ibstalles fine in normal envirement however in chroot envirement i get these errors......
<Homefix1> ./Install: line 408: /usr/local/bin/qtpasswd: No such file or directory
<Homefix1> ./Install: line 416: /usr/local/bin/qtpasswd: No such file or directory
<Homefix1> cp: cannot stat `DarwinStreamingServer': No such file or directory
<Homefix1> copying PlaylistBroadcaster to /usr/local/bin/PlaylistBroadcaster
<Homefix1> cp: cannot stat `PlaylistBroadcaster': No such file or directory
<Homefix1> copying MP3Broadcaster to /usr/local/bin/MP3Broadcaster
<Homefix1> cp: omitting directory `MP3Broadcaster'
<Homefix1> copying qtpasswd to /usr/local/bin/qtpasswd
<Homefix1> and such.....
<ogra_> did you try to find a darwin related IRC channel ?
<Homefix1> none
<Homefix1> i thought maybe permissions of some sort because of the chroot env.
<Homefix1> im always in root i think
<Homefix1> <hrw> .....................help hrw
#ubuntu-arm 2011-02-09
<prpplague> if anyone has feedback on rev2 of the trainer board, please post at http://www.elinux.org/BeagleBoard_Trainer
<ruckuus> Hello everyone
<ruckuus> I am trying to create Ubuntu rootfs for Samsung s3c6410 based board.
<ruckuus> How to specify the kernel to be used? --seed linux-image-???
<Tims_> Hi, maybe some of you remembering me from yesterday. I can't get my Webcam working on an Gumstix Overo (omap3503). Unfurtunately I have to give the gumstix away, what they tell me just today.
<Tims_> So I hope there is anybody who can help me a little bit.
<Tims_> The conclusion of yesterday was, that I have to build my one kernel
<Tims_> because everytime I try to install, for example "qc-usb-source"-driver, it end in failure due to the kernel, he cant find the one which is neccessarry
<Tims_> but on the gumstix webpage I searched and found a kernel which fits from the kernel-number, but the error apeared further.
<LetoThe2nd> probably you don't have the kernels headers installed.
<LetoThe2nd> for understandment: you don't compile against a running binary kernel, but against its api. the api is in the headers. no headers - no compiling against the kernel.
<Tims_> i installed kernel, maybe the wrong one, let me take a look
<Tims_> i installed kernel-headers, maybe the wrong one, let me take a look
<LetoThe2nd> Tims_: hint for getting your thoughts going: you install a gumstix-specific kernel. you sound like you have installed the kernel-headers from the repo. how should the repo contain the headers fitting for your vendor kernel?
<Tims_> It is installed linux-headers-2.6.32-21 and 2.6.32-28
<LetoThe2nd> Tims_: ok, and that should be enough to make you think. remember the kernel version number you told us yesterday?
<LetoThe2nd> are they fitting?
<Tims_> no, but I cant remove it
<LetoThe2nd> thats not the point. point is, you need the headers fitting your running kernel. and thats where we come back to.... you already know it? wanna guess? right, documentation! :D
<Tims_> the kernel which i get with uname and which i find in the debs are fittig, so maybe so only thing is to remove de wrong one
<LetoThe2nd> yesterday you told us, you're running some whacked 2.6.34 or .35-overo. and thats certainly not fitting to 2.6.32-21/-28. right?
<Tims_> yesterday! do you think I turning my thumbs here?
<LetoThe2nd> honest answer?
<LetoThe2nd> and as of today you have not provided new information, i only can think yesterday infos are still uptodate.
<Tims_> 9:35
<LetoThe2nd> Tims_: "i installed kernel"... sorry, no information given which one.
<Tims_> i said the one how fits, i thought the number is irrelevant if the fit
<XorA|gone> persia: ping
<LetoThe2nd> Tims_: honestly, i doubt your judgement on "fitting". :-)
<LetoThe2nd> Tims_: for a beginning you might name the _exact_ version of the running kernel, where it's from and how you have installed it.
<Tims_> uname -a : Linux gumstix 2.6.32 #1 Thu Mar 18 22:40:54 PDT 2010 amv7l GNU/Linux
<Tims_> i get it from here: http://www.sakoman.com/feeds/omap3/glibc/images/overo/
<LetoThe2nd> Tims_: i see neither a -21 nor a -28. so: guessing time again... fitting or not fitting?
<Tims_> i don't know where or how I can find/see the last number
<LetoThe2nd> Tims_: if it's not there, it's not there. in the case of ubuntu, they mark the service releases.
<LetoThe2nd> Tims_: so one might think that a header set fitting some ubuntu-service-fixed kernel doesn't match some downloaded-from-the-internet-kernel. and one might be right.
<LetoThe2nd> Tims_: seriously, you got to get a grip on the information you're providing and the assumptions you are making. productive support is nearly impossible the way you do things.
<persia> XorA, Hey.  Sorry I missed you yesterday.
<XorA> persia: no problem, was just going to say Im going to be in your part of the world next week
<persia> Oh, excellent.  Which days?
<XorA> persia: landing saturday morning tokyo, leaving the next saturday afternoon
<persia> We'll have to meet up then :)
<XorA> persia: that would be cool
<Tims_> LetoThe2nd: sorry, i can't gave you more information as the system me gave,
<LetoThe2nd> Tims_: i repeat. you assumed a fitting kernel - which isn't there. you didn't mention - you actually installed a new kernel. neither did you name the source of it, if you have built it yourself, the version... nothing. have to ask again and again and again to get the information out of you (or thin air, not much of a difference) and clearing up what you think about your system and is just not true is sooo timeconsuming and irksome that t
<LetoThe2nd> i think i'll give it up, now. good luck - to the supporter and the supported. you'll need it.
<Tims_> cu
<persia> Do gumstix boot the kernels in the repo cleanly?  I wouldn't think one would need a special kernel.
<ogra> persia, alst time i saw one trying it broke on the MMC
<ogra> *last
<persia> Ugh.  That ought get fixed, if reasonably feasible.
<ogra> i think it cant, afaik the gumstix uses some kind of incompatible MMC driver
<ogra> but it might have been fixed, not sure
<persia> source-incompatible or config-incompatible?
<ogra> mpoirier was working on it
<ogra> i think source
<ogra> but i dont know much about it
<persia> That's very annoying.  Oh well.
<ogra> talk to mpoirier if it ever got fixed
<ruckuus> Hello All. Has anyone tried Ubuntu-arm on samsung s3c6410 based board?
<persia> He's not here so much anymore :(  But I'll hunt him down sometime.
<ogra> ruckuus, i think the guys in #linaro use some samsung boards, try there
<persia> ruckuus, I've not heard of anyone trying to get a kernel for that into the archive, but my knowledge isn't all-inclusive.
<ogra> persia, he is regulary in #linaro
<ruckuus> ogra, thank you so much. is that a channel?
<ogra> yes
<ruckuus> I saw working one here: http://www.arm9.net/mini6410-ubuntu.asp
<ruckuus> ogra, thank you I will try to get there
<persia> ruckuus, Unless you know the folk who made an image, I'm not sure I'd trust it entirely.
<ruckuus> persia, well me too. I download the images and will try it soon
<persia> ruckuus, OK.  Be aware that we'll be dropping support for 9.10 in a couple months.
<ruckuus> Is it "that simple" as mentioned in Ubuntu RootStock to create Ubuntu rootfs image?
<persia> ruckuus, You could do that, and the result is something you can probably trust a bit more.
<ruckuus> I have everything from the BSP but still fuzzy on how to put the specified kernel
<persia> You will need to stuff in your own kernel, etc.
<ruckuus> persia, sounds optimistic. Thank you
<ruckuus> I have created rootfs with Poky (PokyLinux) and it works well
<ruckuus> I am interested to put Ubuntu on top of the board, will be easier to develop i guess
<persia> ruckuus, I don't know anything about your board, but you'll want to make sure it supports at least ARMv7a: if it does, you should be fine.  If not, I'll recommend Debian.
<ruckuus> persia, my board is OK6410 http://www.arm9board.net/sel/prddetail.aspx?id=348&pid=200
<ruckuus> I guess that would be simple to put Ubuntu on top of that, but my current issue is how to use my own kernel
<persia> Based on http://en.wikipedia.org/wiki/ARM11 , that looks like it's not a good fit for Ubuntu.
<ruckuus> persia, thank you for the link, I will check it
<persia> You'll likely have a much better experience running Debian, as you'll be able to run current software, upgrade, etc.
<ruckuus> persia, could you please point me out why you come to that conclusion? TIA
<ruckuus> persia, I guess so. I am using Debian now
<persia> Wikipedia says that the Samsung S3C64x0 series of processors is ARM11, and indicates these support the ARMv6 instruction set.
<persia> Ubuntu, since Lucid (10.04) requires that hardware support the ARMv7a instruction set, which means that you won't be able to run any of the recent releases.
<ruckuus> persia, ... for media support (only) ? no?
<persia> It's about the compiler defaults: if you don't have support for the instruction set, the software won't run.
<ruckuus> persia, I see. meaning to say if I want to put Ubuntu, I will need to build everything from scratch using supported compiler that comes with BSP
<ogra> imagine i386 vs i686 ... optimized i686 code wont run on i386 because the i386 CPU doesnt know some instructions the i686 one uses
<persia> And you have no promises the results will work, as the source has often been modified to expect more recent processors.
<ruckuus> ogra, persia, I get it
<ruckuus> hello, it is confirmed that my board only support ARMv6 instruction set. Said on the website it can only run Ubuntu up to 9.10
<hrw> ruckuus: install Debian then
<ruckuus> hrw, I will. Currently I am using Debian packages from scratchbox
<ruckuus> Is there a link for me to study how to achieve it?
<hrw> ruckuus: use Debian directly. my brain shutdowns when I hear scratchbox word
<hrw> ruckuus: use rootstock/multistrap to generate armel image of debian and boot it with your kernel
<ruckuus> hrw, whew seems scratchbox is too traumatic for you :\
<hrw> ruckuus: long story
<ruckuus> hrw, i see. Thank you
<ruckuus> hrw, I almost died with scratchbox, then switch to Poky, but still PITA when adding new package, and just today I saw posting that Ubuntu can run on ARM
<ruckuus> very helpful, hopefully
<persia> In terms of the development experience, Debian and Ubuntu are nearly identical.
<persia> The differences tend to be small patches for individual packages, based on differing philosophies about how the distribution is delivered.
<persia> But the key is to run Debian as Debian, rather than trying to cross-compile Debian on scratchbox or something.
<danger89> Hi
<danger89> I bought the iGEP v2 hardware board with WIfi+ Bluetooth
<danger89> Can somebody say how good the Ubuntu netbook port for ARM is?
<danger89> For example does all the hardware components works on the igep v2
<hrw> iirc it works with 10.10 or 11.04
<danger89> Yes, I believe it will work. But does all the hardware components work OK with the 10.10? Like: Wifi, Bluetooth, i2c, USB, etc.?
<rsalveti_> weee, borked internet today :-(
<ogra> bug 708661, bug 708659, bug 708658
<ubot2> Launchpad bug 708661 in libqtgconf "[MIR] please include libqtgconf in natty main" [High,Incomplete] https://launchpad.net/bugs/708661
<ubot2> Launchpad bug 708659 in libqtbamf "[MIR] please include libqtbamf in natty main" [High,Incomplete] https://launchpad.net/bugs/708659
<ubot2> Launchpad bug 708658 in libqtdee "[MIR] please include libqtdee in natty main" [High,Fix committed] https://launchpad.net/bugs/708658
<danger89> hrw: I can't find the ARM 11.04 version only 10.10: http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/
<danger89> http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/current/
<danger89> foudn it :D
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/releases/11.04/ has the alpha2 image from last week
<rsalveti> NCommander: ogra: unity-2d seems to be working with latest qt
<ogra> yay
<rsalveti> the only thing to fix is that I'm not seeing the places icon that is used to fire up new applications
<ogra> do yu see it elsewhere ?
<ogra> i think the places implementation isnt ready yet
<rsalveti> well, at least it was working at my maverick machine
<ogra> (the unity one, not the 2d one)
<rsalveti> that icon with scissors
<ogra> yeah, it was redone in natty
<rsalveti> oh, ok
<ogra> we need to compare to x86 now i guess
<rsalveti> yup
<ogra> indicators and places were rewritten
<ogra> and the desktop switched to dconf
<ogra> thats the three bits still to be done in natty for unity-2d
<rsalveti> you mean, for unity-2d?
<ogra> everything switched to dfconf
<ogra> *dconf
<ogra> gconf is out
<rsalveti> yeah, true
<ogra> (though might be that dconf is just a different frontend, i didnt really look into that, upstream will care)
<danger89> ogra: why should I use the alfa 2 over the "daily build" of Ubuntu netbook 11.04? Why is it better? And I checked the datum, but the daily build is from 9 feb and alfa 2 is from 2 feb.
<danger89> 3 feb*
<ogra> danger89, alphas usually get a week of archive freeze and QA
<ogra> dailies can be broken in various way and are usually not regulary tested
<ogra> *ways
<danger89> So alfa 2 is the latest version of 11.04 and it is stable?
<ogra> it was tested for the install to work at least
<danger89> ^^
<ogra> dailies only get tested occasionally
<danger89> ok thx
<danger89> ogra: If you got the igep v2 board. What would you  choose for OS version (10.10 vs 11.04 or.. something completly else)?
<ogra> no idea, i have no igep2 :)
<ogra> but the later the better i would say, since its more likely the kernel works better with that HW
<danger89> http://labs.igep.es/index.php/Main_Page
<danger89> and now :P ahah
<danger89> ogra: I se
<danger89> see*
<danger89> thx
<NCommander> rsalveti: yay
<jo-erlend> did you read about the OMAP5? Sounds like something cool.
<davidm> yes, the OMAP 5 sounds quite nice, will be a while before it's shipping in volume though
<jo-erlend> yes, about 18 months, they say. Maybe just in time for 12.04? :)
<jo-erlend> oh... I miscalculated that one... *tralala*
<martyn> Has anyone seen a real, physical Armada XP development board?
<martyn> Marvell announced a chip back in Nov, and theoretically a 'development platform' .. but so far I haven't met or seen any evidence of one...
<ogra> i dont think there were any dev boards, they went dirctly to OEMs
<ogra> *directly
<ogra> essentially it should be close to dove
<martyn> ogra: In theory.  So far though, the only thing I've seen are mechanical engineering samples.
<martyn> ogra : Which is why I'm curious to see if there is, in fact, a working board (or working chip) somewhere.
<rsalveti> janimo: I believe the x-loader update issue was supposed to be fixed with the version we're currently using
<rsalveti> janimo: when you updated your files, did you copy both x-loader and u-boot or just x-loader?
<janimo> rsalveti, both
<rsalveti> if this is still an issue, we should also report it
<rsalveti> if not able to fix it, then recreating the first partition would be the best solution
<janimo> rsalveti, well it may have been the copying to wrong location in VFAT, as I simply copied the files over (after renmaing the old ones to .bak(
<rsalveti> janimo: hm, what happens when you copy the one to .bak and overwrite it?
<janimo> rsalveti, I'll do some more thought out tests, I recovered form yesterday's by rewriting the whole SD card
<janimo> as that too showed kernel errors
<janimo> so it may not be an xloader bug at all
<rsalveti> hm, ok
<ogra> rsalveti, i think only the issue with x-loader not finding u-boot after overwriting it was supposed to be fixed
<ogra> fi the fat changes you will still have issues with the rom code
<rsalveti> ogra: could be
<rsalveti> need to test it more to see what exactly is the issue now
<janimo> ogra, the new packages are to be added to the image in livecd-rootfs?
<ogra> we need to seed them
<janimo> we have no specific seeds for the images right?
<ogra> (that should be a workitem)
<ogra> there is a seed for kernels and the like iirc
<ogra> we have ubuntu-netbook exclusively for armel
<ogra> worst case we can seed it there
<ogra> but that wont cover minimal installs indeed
<ogra> and there is also a prob with subarches, seeds dont know about them
<ogra> so we need to install *all* x-loader and u-boot packages
<ogra> platform.natty/boot might be an appropriate seed
<janimo> ogra, all those packages are for omap based boards now?
<janimo> ogra, the seed should be arm specific  I guess
<ogra> and a hack in livecd-rootfs to remove the unwanted bootloader
<ogra> no
<ogra> the seed needs to be general but the line in the seed should be armel onl
<ogra> y
 * janimo needs to find out what line in the seed means
 * janimo checks ubuntu seeds
<ogra> so i would suggest adding u-boot and x-loader to platform.natty/boot (after talking with cjwatson) and then having a hack in livecd-rootfs to remove the unwanted ones
<ogra> similar to the hack that removes the unwated headers there
<janimo> ogra, ok
<ogra> the boot seed also carries grub for example
<GrueMaster> Would it make sense to have a meta file and seed it?
<ogra> we use seeds to produce meta packages normally
<GrueMaster> Oh?  I was thinking like with the kernel we have linux-ti-omap
<ogra> i dont think the u-boot packages have the version in the package names
<GrueMaster> Not that I have a clue about the voodoo needed for seeds/image creation.
<ogra> u-boot-linaro-omap3-beagle and u-boot-linaro-omap4-panda
<ogra> so we dont need a meta
<GrueMaster> ok
<ogra> same for x-loader: x-loader-omap3-beagle and x-loader-omap4-panda
<ogra> we just need to seed them in the right place and remove what we dont need during rootfs build
<ogra> bah, and now janimo is gone
<ogra> bad timing
<GrueMaster> He definitely needs a caching irc proxy.
<ogra> yes
<ogra> so after discussion with lool in #linaro i see that we cant seed it but need a different approach
<ogra> anyway, here comes my dinner and i'll call it a day
<rsalveti> vstehle: and one more time brazil is loosing for france
 * lool mocks rsalveti 
<rsalveti> lool: nothing to say, 19 years without winning a game over france
<rsalveti> too bad
<lool> And it's the country of football!
<rsalveti> yeah... yeah... yeah... hehe
<lool> that's said, France wasn't really stellar at the WC
<rsalveti> not at all, but it seems it's a lot better already
<lool> but it's ok, I can pretend that I don't like football when we lose, and that I love it when we win
<rsalveti> hahaha
<GrueMaster> Go Packers!!!
<GrueMaster> oh, different kind of football?
<rsalveti> ops :-)
<armin76> lol
<armin76> http://www.linuxfordevices.com/c/a/News/HP-Touchpad-launch/ hrm...dualcore :D
<rsalveti> sounds interesting
#ubuntu-arm 2011-02-10
<rsalveti> working sgx driver for natty published at https://launchpad.net/~tiomap-dev/+archive/omap-trunk
<rsalveti> same version as currently used at maverick, but ported to make it work with natty's xorg
<lool> rsalveti: cool
<ndec> rsalveti: thanks for pushing the DDK update for natty!
<janimo> ogra, in the natty platform seed  I see dove, is that still needed there?
<janimo> also what is the difference between platform.natty and ubuntu.natty seeds? I saw no overview of the relationship between various ubuntu.seed branches
<ogra> janimo, in the seeds we can keep it in case a platform comes back you dont need to redo the whole seeding
<ogra> we dont build images for such platforms so it shouldnt do any harm apart from a bit bit-rotting
<ogra> janimo, also forget about seeds
<janimo> ogra, right but I was hoping version control software was a better fit for keeping such legacy bits around
<janimo> I find almost all the scripts in the area of image building have a lot of unnecessarey baggage
<janimo> making them harder to understand
<ogra> janimo, i had a chat with lool yesterday, they use the same low level seed and have a policy that no bootloader should be installed, we would break it for them
<janimo> ogra, so no bootloaders in the seeds?
<janimo> ok, I'll add them in livecd-rootfs then
<ogra> no
<ogra> just have a line in the upgrade script that apt-get installs them ... we dont need them seeded, you need the latest version from the archive anyway
<ogra> one check of the script should be that -updates is enabled, then get the last versions from there and drop the binaries in place
<janimo> ogra, yes but they will not be upgraded ifg they are not in the image initally
<ogra> the version we would seed would be the original one installed anyway
<janimo> ogra right, but then updates would be automatic
<ogra> why do we need automated updates here ?
<janimo> ogra, if the script needs to bring them the user cannot be notified when an update is there
<janimo> automated fetch not install
<ogra> we dont want to actually encourage users to upgrade their bootloader, we just need a tool for the case where we tell them to upgrade
<janimo> well suppose we have a bugfix, how to propagete to users so they stop complaining about it? I think it shold be like a regular bugfix via apt
<janimo> ogra, ok
<ogra> i.e. we dont need notification here
<janimo> ogra, in this case apt-get installing it just to put it on the 1st partition is strange.
<janimo> anyway I'll do wahtever t tajkes to have some script working for omap3/4
<janimo> without too much fanciness :)
<ogra> well, if you prefer to pull the deb and extract it, i wouldnt object
<ogra> and if you have a convincing reason to have it on the image in advance, feel free to convince me, i was on that page before my discussion yesterday ;)
<ogra> yay, my new mobile just arrived
<janimo> ogra, well for easy of install and not bothering with extra step, plus to notufy users automatically. And if it can be done from livecd-rootfs withoiut touching the seeds what is the drawback?
<lool> ogra: Well, it's not a policy that no bootloader should be installed  :-)
<ogra> ah, i thought it was turned into some kind of policy
<lool> it's just that we decided that the bootloader did not have to be part of the rootfs, even more so if it's not upgraded automatically (which we certainly don't want)
<ogra> janimo, what i see as a compelling reason to have it installed is that you easily can find out the version
<janimo> lool, we also decided that updates would not be automatic, but up to the user
<lool> however this is not implemented, and I believe that current images still install a bootloader .deb, this is a limitation of our image writing tools which will be fixed once we implement what we call hwpack v2
<lool> https://wiki.linaro.org/Platform/Specs/11.05/HardwarePacksV2
<lool> I personally recommend *not* shipping the bootloader with apt/deb if you can avoid it because "updates" of this file wont make any sense (wont actually get the bootloader update, and might result in the rootfs hosting a bootloader which might not work when put to use)
<ogra> lool, yes, but you still get an easy way to check the version, might be helpful for i.e. apport reports of a kernel crash
<ogra> i know its doesnt necessarily show the running version
<lool> It doesn't represent the real version
<lool> it's just a random piece of data
<lool> BTW the point I was making yesterday was about network-dependency
<lool> Since you're going to want a fresher version of the bootloader to install because yours is borken, then you necessarily have access to an archive (since you can apt-get update to it), so why not instead apt-get install it when needed, and not install it by default in the first place?
<lool> I didn't read the spec, so I don't understand how you'd actually boot your board which has a broken bootloader to upgrade it though
<janimo> lool, no provision for fixing that. So even if update is made easy, one still needs some technical skill to restore
<lool> Perhaps one way this would work is from your x86 laptop, putting your rootfs SD card into it and updating the bootloader; if you really need to run ARM code, you could use qemu-arm-static, but I think you could avoid it
<ogra> thats a different scenario
<lool> This would also allow the "download image from ubuntu.com, write to SD, update bootloader on SD, boot on recent hardware" use case
<ogra> the point is to be able to apply fixes, not tro make unbootable systems boot
<lool> What kind of fix?
<ogra> initialization errors of single bits of the hw that the bootloader has by release time for example
<lool> Why can't this be done in linux?
<ogra> because it might be a more ugly patch or it might not be possible to do it after boot
<ogra> the omap4 display issue we had would not have been solvable in the kernel for example
<lool> So how would you do it with another bootloader?
<lool> e.g. in production, with a lightweight bootloader
<ogra> it was an x-loader fix that initialized the HW
<lool> I might not know the specific of this bug, it just seems odd that hardware state would belong into u-boot
<ogra> it wasnt u-boot but x-loader
<lool> If x-loader/u-boot work enough to start a kernel, then it seems to be the kernel could fixup stuff
<ogra> if you set a voltage wrong and the kernel cant adjust it, you cant fix it differently
<lool> Why wouldn't the kernel be able to adjust?
<lool> (I am really ignorant here)
<ogra> because there is no interface to do so
 * ogra needs to vanish for a moment
<rsalveti> morning
<rsalveti> lool: ideally the kernel should handle everything, and the x-loader/u-boot would just bring up the board
<rsalveti> but is not the case atm
<rsalveti> x-loader is still important, and still setting things that the kernel expects to be ready once it boots
<rsalveti> that's why in the last cycle we needed a x-loader update to have a feature working fine
<lool> Yup
<rsalveti> so the system is working, is booting
<rsalveti> but not properly working regarding some feature
<rsalveti> that x-loader, for example, initialize, then we need a way to update it
<rsalveti> as we can easily brick the board with automatic updates, we decided to provide a tool for the user
<rsalveti> and notify him once we have new updates
<rsalveti> so he can run this tool, and update the core boot files
<rsalveti> having both installed at the images can make the work a lot easier
<lool> Hmm the notification part is harder
<rsalveti> at least to identify the version, and also to notify the user
<lool> Do we expect this to happen frequently?  It would make sense to invest in having the init done by linux instead of x-loader
<rsalveti> well, it happened frequently with maverick
<lool> It sounds a bit like a BIOS update, but you can't even check which version of the BIOS you're using!
<rsalveti> and because of the short time frame to have a working 2.6.38, I'd not expect to have the kernel properly setting up everything
<rsalveti> you can only check by the binaries, or by the package metadata, if it's installed at the system
<lool> This is very indirect
<rsalveti> true
<lool> binaries > if you mean the ones on the boot partition, that's ok, but the one in the rootfs that would sound bad
<rsalveti> the ones at the boot partition
<lool> I'm not up-to-date on flash-kernel stuff ATM; is the boot partition always mounted, or mounted when needed?
<rsalveti> mounted when needed
<lool> You're going to want some kind of permanently installed package to raise the notification; perhaps a sensible one would be jockey
<lool> jockey could mount this partition ro when starting (ouch, but eh) and check MLO for a specific version
<lool> then <insert here some magic> you decide that an update is needed; jockey does the x-loader package download if needed and run a x-loader flashing wrapper; question is whether x-loader package stays installed o rnot
<lool> *or not
<rsalveti> we don't want to run the update automatically
<lool> Jockey prompts you
<rsalveti> we want the user to run the flashing tool
<rsalveti> that can work
<lool> it probably needs some adaptations to deal with this, but that would seem to give a good starting platform; maybe pitti would have more comments there
<rsalveti> janimo: ^
<lool> We might not have a text UI for jockey
<lool> only Gtk+ and Qt based ones
<rsalveti> hm, we would need to run this procedure in text mode too
<rsalveti> as we'll have the minimal image
<lool> the actual flashing script should probably be implemented in flash-kernel, but with special care to advertize this as extremely dangerous brick-your-device feature
<lool> You could have documentation for text mode
<lool> run flash-kernel --flash-bootloader
<rsalveti> guess that's ok
<lool> Technically, you could use package upgrades to trigger flashing, but it's not really a direction that seems reasonnable  :-.
<lool> :-/
<janimo> lool, I was also thinking of adding it to flash-kernle as it makes packagihng and coding easier. I am not sure if this does not take it further away from debian and the original intention of the package
<janimo> but, yes I would rather have it in flash-kernel that a separate source package for one script
<lool> janimo: Currently flash-kernel has knowledge of where your bootloader lives (SD vs flash); that's the only non-installer place which has this, so it seems sensible
<janimo> lool, actually for OMAP flash-kernel needs to be told the partition in a config file ia UBOOT_PART
<lool> In general, I think flash-kernel needs to be modernized substantially, but it's a lot of work
<janimo> so it's not like it autotdetecta anything
<janimo> lool, otherwise it assumes NAND
<lool> janimo: I know, but it has code to parse flash-kernel.conf and stuff, doesn't it?
<rsalveti> but the conf is there by default already
<rsalveti> if the user installed by using our image
<rsalveti> not completely safe, but ok
<lool> You wouldn't want to have another tool reading this kind of data; it's very Ubuntu specific and I'd like to keep it flash-kernel-specific; if it spreads to other packages we're bound to lots of pain
<janimo> lool, sure, I am for using flash-kernel, just pointing out that the code in case was not some complex piece
<janimo> lool, true
<lool> It's really not about complexity, it's rather that I find this dirty enough  :-)
<lool> this whole flash-kernel.conf was quickly thrown together some years ago, and never architectured, sent to Debian or anything
<lool> I could easily take the blame for this though
<janimo> lool, actually flash-bootloader may not be enough. I think we;d want to update xloader and uboot independently.
<janimo> so maybe have flash-bootfile  /path/to/opaquefile
<janimo> or flash-uboot, flash-xloader options
<rsalveti> flash-bootloader should be fine
<janimo> however this make it very omap specific
<rsalveti> you can check both before updating
<rsalveti> and updating what needs to be updated
<rsalveti> x-loader is omap specific
<janimo> rsalveti, makes sense, but maybe the user would only want to update one
<rsalveti> and also part of the booting procedure
<rsalveti> the normal user would not update it independently
<janimo> so no GUI, agreed?
<lool> I think it's best if you know what you're doing; flash-kernel --install-to-boot /usr/lib/x-loader:MLO && flash-kernel --install-to-boot /usr/lib/u-boot:u-boot.bin sounds much uglier than flash-kernel --spl --tpl or flash-kernel --bootloaders=spl,u-boot
<rsalveti> probably doesn't not even know about x-loader/u-boot
<lool> You basically don't want to leave any room for hacks or abuses with this kind of stuff
<rsalveti> yup
<lool> otherwise someone is going to suggest flash-kernel --install-to-boot boot.scr in some documentation
<janimo> both of these contradicotry approaches make sense
<janimo> depends who are we targeting and which is more useful in general
<rsalveti> janimo: gui just to warn the user
<rsalveti> aobut the update
<lool> and then the seas will rise, cities will collapse, mountains will fall
<janimo> rsalveti, I think we still need to decide whether these belong to the preinstalled image or not, at least ogra seems to have doubts about the latter
<lool> janimo: Why no GUI?  :-)
<rsalveti> :-)
<lool> I mean, perhaps I'm thinking it wrong, but to me you're trying to distribute an user-friendly Ubuntu for OMAP4 which does the right thing
<janimo> lool, no extra GUI I mean. If it cannot be part of update-manager or some other apt-related I'd rather us not have a special gui for this
<lool> janimo: why not part of jockey?
<lool> jockey will popup and tell you that you bought a proprietary graphics card and that you can't get any boingboing effects without clicking "Install these binary stuff"
<janimo> lool, no experience with jockey, but party because I;d like to first figure out somethig that works and then see if it can be imporved, before touching too many different packages initially
<lool> gnome-power-manager will tell you "This battery has been recalled, contact your manufacturer"
<janimo> lool, yes but that is already running and does this as an extra. We'd not run a dameon specifically to watch for updates
<janimo> that's wha update-manager does
<lool> janimo: Sure; these are kind of orthogonal, but in general user experience is better designed top-down (apple) than bottom-up (linux :-)
<janimo> lool, true as well, but we are talking about a rpocedure which requires running a cmdline app
<lool> You can implement the flash-kernel plumbing first obviously
<janimo> which if goes wrong needs expert intervention anyway -VFAT formatting, copying of blobs etc
<janimo> lool, right, the core operation first and see how it can be improved
<lool> update-manager delivers package updates, or recommends dist upgrades; don't think it deals with special general-purpose hooks like jockey kind of does; I don't know where you'd put the data
 * lool thinks jockey could also be used to install the powervr stuff
<janimo> lool, that is why the solution (until yesterday that is) involved having the packages installed so dpkg post install hooks can be used for this purpose
 * janimo does not know about the powervr use case
<lool> it's technically feasible to decide to do upgrades from package hooks, but I would find that disturbing and risky
<rsalveti> lool: jockey could work fine with pvr, I believe
<rsalveti> at least would make sense
<lool> (because you'd have to protect the action by some debconf prompt which are considered evil and would have to fail by default, and because it would create a perception that you have x-loader 1.2.4 when in fact you have some random other version and it doesn't necessarily get installed)
<lool> the jockey case also makes it more obviously optin than upgrade your system and it might not boot
<janimo> lool, well technically it is just as risky as upgrading kernel/initrd no? If update gets broken it does not boot. And we would not push broken boot loaders to the archive
<rsalveti> janimo: well, kind of
<janimo> sure if jockey is better suited for this it can be used, I just have no experience with it
<rsalveti> the user can still try something at the u-boot prompt
<rsalveti> if we break x-loader, nothing will show at the uard
<rsalveti> *uart
<rsalveti> and the user will cry and screen
<janimo> rsalveti, but if a user can work with uboot prompt via serial he can surely copy two files on the MMC VFAT partition?
<rsalveti> janimo: probably not
<rsalveti> we have cases that the user only uses uart to see what's happening
<rsalveti> and log-in into the system
<janimo> I see this spec as a convenience use-case not one that makes regular users do expert things because of a wrapper
<rsalveti> but don't have proper technical background for other stuff
<rsalveti> yup, we should focus on the simple user, that just want his system to be fixed
<lool> janimo: I tend to agree that it would be best if we had a way to offer booting older kernel / initrd, or passing cmdline options; not visible by default, but to be able to maintain multiple kernels on a system
<lool> but the difference is that we know the kernel is going to see some security updates, while the bootloader shouldn't ever need an upgrade if we don't really need it
<lool> it should basically get out of the way; think of it as firmware
<lool> I have devices where in theory I have source of the bootloader, but I didn't build it myself and I doubt I'd be able to replace a broken bootloader; in fact, if I flash a broken bootloader there is zero way to recover
<lool> it might not be true on SD, but because the solution will involve flash-kernel etc. it would be best to have safety nets in place and not do it unless really needed
<lool> For instance, you might want to decide to only upgrade the bootloader if people are running a specific board
<janimo> lool, you mean variants of beagle or rather beagle vs panda?
<lool> both
<janimo> right now I guess all variant will get a new package being in the same source package even if only one gets a fix
<lool> so you're upgrading the bootloader even when not strictly needed?  sounds bad
<janimo> lool, no, the opposite, was just needing calrification
<lilstevie> lool: not even jtag
<apw> ogra, yo ... seems that the linaro qemu images have hit the archive.  this ought to mean we can emulate omap3 correctly now, which might mean that versatile kernels are no longer needed for arm as they are used for qemu only ... what are your thoughts?
<apw> ogra, i am a little concerned about the interaction between a lucid host and this though
<rsalveti> apw: well, at least with rootstock (that uses versatile) I'll test with omap 3 and see how it goes
<rsalveti> but it should work fine, as linaro is already using qemu with the omap 3 kernel
<apw> rsalveti, that sounds good ...
<rsalveti> don't know if we have any other use for versatile
<rsalveti> maybe ogra knows
<apw> rsalveti, there is a bug open which might make sense to report the outcome of any testing
<apw> bug #715113
<ubot2> Launchpad bug 715113 in linux "Drop versatile support" [Undecided,New] https://launchpad.net/bugs/715113
<rsalveti> apw: sure, will do
<ogra> apw, we were just discussing it in the meeting :)
<persia> And in -kernel
<apw> heh and here, and ... yeah i am suggesting the bug for any position statements or testing :)
<janimo> apw, the bug I filed is part of a spec of the arm team, so they are at least partly aware of the situation :)
<janimo> apw, there are some bugs still with various corner cases but the linaro devs are on them and fix qemu relatively fast
<rsalveti> yup
<rsalveti> so we should be safe with the qemu-linaro and omap 3
<persia> Concern is for folks running a complex environment: for example lucid amd64 hosts running natty/arm buildds under qemu
<rsalveti> ppa should be enough for that
<persia> I'd prefer a proper backport to a PPA: I know lots of folks who don't trust PPAs, for a number of fairly well-argued reasons.
<janimo> persia, sure but those special cases should not block removing versatile from natty right
<janimo> ?
<persia> I don't see any special reason to block the removal.
<persia> That said, it's probably worth filing a backports bug for qemu-linaro once it's known good.
<ogra> NCommander, bug 708661 and bug 708659
<ubot2> Launchpad bug 708661 in libqtgconf "[MIR] please include libqtgconf in natty main" [High,Incomplete] https://launchpad.net/bugs/708661
<ubot2> Launchpad bug 708659 in libqtbamf "[MIR] please include libqtbamf in natty main" [High,Incomplete] https://launchpad.net/bugs/708659
<ogra> see the last comments
<robclark> btw, anyone aware of ppa w/ firefox-4.0 for arm?
<robclark> ppa:ubuntu-mozilla-daily/ppa doesn't seem to build for arm..
<persia> micahg, Hey.  firefox-4.0 in the mozillateam PPA doesn't build for ARM.  Are there any backports available, or other ways to get it for maverick?
<micahg> persia: we might be able to throw it in maverick-backports
<persia> Is there a good version suitable for -backports?
<persia> natty looks like beta11
<persia> robclark, Was there a specific version you wanted/needed?
<micahg> well, actually, the problem with throwing it in -backports is I don't want to replace the current version in Maverick yet
<micahg> I'll have to see, maybe I can get a native PPA for firefox
<micahg> or maybe an ARM enabled PPA
<micahg> also, is there a specific timeframe (i.e. you need a version now, or just want Firefox 4 on maverick at some point)
<persia> Without the completion of https://launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster ARM PPAs are tricky :(
<persia> I'm just asking you as the most knowledgeable person I know because robclark asked earlier.
<persia> I don't know the detailed requirements.
<micahg> ok, it would be nice to know what the use case is, that might help how it's implemented
<robclark> persia, just something recent 4.0 beta
<persia> micahg, ^^
<robclark> supposedly there should be some performance improvements..
<micahg> robclark: can I ask what the use case is?
<robclark> we just want to do some benchmarking w/ our xorg driver
<robclark> browsing the web ;-)
<robclark> scrolling performance and stuff like that
<micahg> robclark: I'm wondering maverick vs natty
<robclark> ahh, maverick preferrably..
<robclark> I'm running mostly maverick right now
<micahg> robclark: do you specifically need a PPA, or is this just for you?  I could build debs for you on ARM
<micahg> robclark: chrisccoulson suggested just grabbing the natty debs
<persia> Do they install cleanly on maverick?  I thought there've been a few ABI transitions.
<chrisccoulson> i can't think of any reason it wouldn't work
<micahg> persia: we use mostly internal libs for Firefox, so there shouldn't be an issue
<chrisccoulson> remember, firefox uses bundled copies of pretty much everything except gtk and libc
<chrisccoulson> and those don't break ;)
<chrisccoulson> i might be wrong, but it *should* work on maverick
<robclark> micahg, doesn't need to be a PPA..
<robclark> oh, are there natty debs
 * persia grumbles about internal libraries, grumbles more about firefox security, and finds a hole in the sand in which to insert head.
<chrisccoulson> persia - it's not really a problem for firefox, it gets frequent security updates anyway (more frequently than any of our system libraries)
<persia> No moving the sand away from my eyes: I don't want to know :)
<chrisccoulson> heh
<chrisccoulson> in addition to that, there are other benefits to using bundled libraries
<ogra> out of shampoo ?
<chrisccoulson> one of them being that we can submit crash reports directly to mozilla
<chrisccoulson> so they have visibility of linux crashes, which is a very important part of their QA
 * ogra heard of birds that prefer sand, i didnt know it was polular in japan
 * persia is emulating an ostrich
<ogra> japanese ostrich ?
<persia> Sure.  Any ostrich.  If I can't see the problem, it doesn't exist, and won't eat me.
<robclark> hmm, wget + dpkg -i http://launchpadlibrarian.net/62913574/firefox_4.0~b10%2Bbuild1%2Bnobinonly-0ubuntu2_armel.deb didn't seem to result in anything workable..
<robclark> although I guess there are probably some other deb's I need to install?
<robclark> one 10mb .deb file seems a bit small for firefox
<GrueMaster> rsalveti: After resolving a few local issues, I finally got around to getting the latest beaglexm image up.  Seeing a kernel oops on kswapd.  System runs, but this is not a good thing to have.  Filing a bug now.
<rsalveti> GrueMaster: ok
<persia> robclark, What sort of error did you get trying to install?
<robclark> persia, it installed fine.. but just crashes on startup..
<persia> heh.
<robclark> but I guess there are probably other deb's I need to install, so maybe I ended up with some 3.6/4.0 hybrid..
<persia> The dependencies should have prevented that.
<persia> chrisccoulson, micahg: maybe you could fix the dependencies, or build a maverick backport?
<chrisccoulson> i really need arm hardware to test this stuff on ;)
<micahg> yeah, it's going to need a backport as the depends are versioned based on natty
<chrisccoulson> i've been debugging an arm build failure with upstream today, but i've got absolutely no way of testing this
<robclark> ahh
<robclark> well, I have the setup to test deb's on maverick if that helps at all ;-)
<chrisccoulson> i just press the button and hope people say if it doesn't work ;)
<chrisccoulson> i can test builds ok on the porter boxes, but they don't have an X display ;)
<persia> chrisccoulson, You might ask if anyone else in mozillateam has ARM hardware :)
<micahg> chrisccoulson: I can test stuff on ARM
<chrisccoulson> that doesn't really solve my problem though (having no way of testing it myself) ;)
<micahg> chrisccoulson: I might be able to set up the machine so you can test
 * persia imagines a video camera and robotic key-presser.
 * micahg is thinking more along the lines of VNC ;)
<chrisccoulson> heh :)
<lool> persia: Hey there; did you build an efikamx .deb as of late?
<lool> persia: I checked the linaro-mx51 one, and it has efikamx enabled in the config, but I bet it misses tons of patches
<persia> lool, I'm working on one.  I have a current tree, but kernel packaging is *hard*
<persia> (it's sascha + rtp + ubuntu sauce)
<lool> persia: Ok; jcrigby has a script to generate linaro-foo sources from a common git tree, not sure if that helps
<persia> I've looked at that, and it doesn't quite do what I want.  I care about d-i integration, etc.
<lool> debian.linaro/scripts/mkflavourbranches in git.l.o:ubuntu/linux-linaro-natty.git
<lool> persia: Ok; what do you do instead?
<persia> I've been working off the variations abogani used for the -lowlatency kernel to get an idea how to package it.
<lool> Ok
<persia> Basically, creating debian.foo and fiddling the scripts to pull the right bits together.
<lool> udebs should in theory be possible with linaro kernels, but I'd expect them to be disabled by default
<persia> That said, I'd much prefer to use a linaro-imx51 kernel, if you guys are happy to produce one with all the d-i bits and Ubuntu sauce.
<persia> Last time I looked at the Linaro kernel packages, they were disabled by default: looked mostly like replacement kernels to test stuff, targeting folk who were capable of initialising their own bootloader, rather than the "Insert card, hold key, reboot" crowd.
<lool> persia: apparently our mx51 kernel spits udebs out
<lool> https://launchpad.net/ubuntu/+source/linux-linaro-mx51/2.6.37-1002.5/+buildjob/2183588
<lool> persia: efikamx is definitely enabled in the config I'm looking at
<persia> Oh, heh.  I was looking at the linaro wiki, and I should have looked at LP :)
<lool> CONFIG_MACH_MX51_EFIKAMX=y
<lool> but not sb, not in upstream yet
<persia> Has anyone tested it?
<lool> No; I have that in mind since beginning of this week
<lool> persia: u-boot-linaro just gained efikamx as well
<persia> I have patches for SB, but I'm honestly much more interested in MX.
<lool> from upstream
<persia> Oh, excellent.  Then I'll stop fiddling with a kernel: no point :)
<GrueMaster> rsalveti: Bug 716761
<lool> still in NEW though
<ubot2> Launchpad bug 716761 in linux-meta "Page allocation failures during system boot on beagleXM" [Undecided,New] https://launchpad.net/bugs/716761
<lool> persia: Well, I don't have it yet  :-)
<persia> Are you moving to 2.6.38 soon?
<lool> persia: did you care about efikamx or sb?
<lool> persia: dunno
<persia> I mostly care about MX.  SB would be nice, but most of the folk I know have MX rather than SB.
<lool> persia: patches > basically our gatekeeper is npitre and I guess he will take stuff which is going upstream
<lool> I'm a bit lazily waiting for u-boot-linaro-efikamx to be published to propose a hwpack
<persia> lool, By "going upstream" do you mean for-linus, for-rmk, or for-sascha?
<lool> eventually going upstream  :-)
<persia> Ah, so for-sascha patches are acceptable?  That's not so bad then.
<lool> I don't think there's a set limit; it's basically good enough quality and eventually ending in mainline via variou trees
<persia> What timezone is npitre?
<lool> I would think patches from Sacha's tree would be acceptable, and hope that for-sascha patches stand a chance  :-)
<lool> Eastern Canada IIRC
<lool> persia: best is email rather than IRC
<persia> Ah.  That makes it tricky :)
<lool> pull request is ideal, preferably based of a linux tree
<lool> well it's his EOD now, he might be around still
<persia> I'd need to find somewhere to put a git tree :)  Most of the interesting stuff I have is quilt.
<persia> But I'll try to merge the quilt stuff against linaro-imx51, and make either a tree or a sequence of mail-formatted patches available, and send to npitre.
<persia> That'll be *heaps* easier than me pretending to be a kernel developer.
<lool> persia: You can send him a patch series or you can host the patches as regular files
<lool> persia: he has access to canonical hosts too
<persia> The hard part is trying to sort which patches are interesting, really.
<lool> yeah
#ubuntu-arm 2011-02-11
<rsalveti> GrueMaster: can you also try to update to the latest kernel?
<rsalveti> the rc4 based one should be available already
<GrueMaster> I didn't see it in the pool yet, but I'll check launchpad.
<rsalveti> https://launchpad.net/ubuntu/+source/linux/2.6.38-3.30/+buildjob/2252836
<GrueMaster> Yea, finished 16 minutes ago.  That's why.
<GrueMaster> Heh.
<rsalveti> hehe
<persia> Hrm?  Says finished 7 hours ago for me.
<GrueMaster> https://launchpad.net/ubuntu/+source/linux-meta/2.6.38.3.17/+buildjob/2255077
<GrueMaster> That's what is currently published (or in the que).
<persia> Ah.  That's probably still stuck in the publisher.
<persia> But it finished enough before the hour that it ought be in this run, rather than waiting until the next run.
<GrueMaster> Right, but last I was told, the publishing run starts at ~:05 and finishes at :40.
 * npitre sees a pending interrupt for himself here
<GrueMaster> So I only have to wait another 30 minutes.
<persia> npitre, I've been trying to package an imx51 kernel tree with sascha's tree + patches from rtp + ubuntu sauce.  lool advised me you were the gatekeeper for linux-linaro-imx51, and I should send you patches and use your package.
<persia> npitre, Since the last upload is 2.6.37, I'll try to sort out what patches I have that are relevant to the efika boards, and prepare a tree for your review.
<npitre> persia: no problem
<persia> npitre, For reference, rtp's work is a quilt patchset at git://git.rtp-net.org/efika.git
<npitre> persia: what is rtp?
<persia> npitre, Arnaud Patard
<npitre> persia: fyi, the linaro tree should move to 2.6.38-rc5 once released
<persia> npitre, Excellent.  If your 2.6.37 boots on the hardware, I'll postpone sending you patches until after the move.  If not, I may send you a few in advance.
<npitre> persia: OK, as lool hinted I'm not that good at tracking irc so feel free to send me an email if you have something you want included in the linaro kernel
<persia> npitre, Absolutely :)  I'm not that good at tracking email: thanks for having the initial discussion with me here.
<npitre> persia: you may try to ping me on irc, but sometimes this might take hours before I notice
<persia> npitre, I'll send you email once I have something substantive.  For now, I'm waiting on a test report for the Efika MX with your kernel.
<npitre> persia: OK
<rsalveti> cooloney: hey, are you back already?
<cooloney> rsalveti: yeah, man
<cooloney> rsalveti: how's going?
<rsalveti> cooloney: good, and you?
<rsalveti> refreshed?
<cooloney> rsalveti: heh, actually a little bit tired
<cooloney> rsalveti: any news?
<rsalveti> cooloney: well, weekend ahead :-)
<rsalveti> cooloney: well, some :-)
<rsalveti> we got a ti-omap4-dev branch
<rsalveti> as you probably know already
<rsalveti> cooloney: one thing I'd like to ask you is if you can test and merge the DVI patches for panda
<rsalveti> for 2.6.38
<rsalveti> so we can have a working display with this kernel
<rsalveti> as my panda has a broken dvi, can't test atm
<rsalveti> look at l-o for [PATCH] OMAP4: PandaBoard: Adding DVI support
<cooloney> rsalveti: sure, i will do it today
<cooloney> i got that HDMI-DVI cable
<rsalveti> cooloney: cool
<cooloney> rsalveti: is this one?
<rsalveti> but even the hdmi cable should work
<cooloney> [PATCH] OMAP4: PandaBoard: Adding DVI support
<rsalveti> cooloney: yup
<rsalveti> rcn-ee said it worked fine for him
<rsalveti> so it should just work
<rsalveti> if it's the case, try sending it to this branch
<cooloney> it's from Raghuveer Murthy <raghuveer.murthy@ti.com>
<rsalveti> ti-omap4-dev
<rsalveti> cooloney: yup, that's the one
<cooloney> OK, i got it
<cooloney> so will we get .38 patches soon?
<rsalveti> cooloney: not directly from serbjan, probably from linaro
<rsalveti> or something like that
<cooloney> rsalveti: right, i know Andy Green is working with sebjan on that
<rsalveti> yeah
<cooloney> rsalveti: thx a lot for this info.
<cooloney> i will test that DVI patch and try to push to ti-omap4-dev
 * cooloney just update his machine, needs reboot, brb
<cooloney> rsalveti: does our ti-omap-dev branch kernel supports graphic, since i wanna test that DVI patch.
<persia> It should.
<rsalveti> cooloney: probably
<rsalveti> cooloney: you just need to check if you have all the dependencies, like described at the patch
<cooloney> rsalveti: i think it is based on 2.6.38-rc kernel which miss some graphic support.
<rsalveti> but as we're basically using the same one as master (rc4), and rcn-ee said it worked fine for him, I expect this patch to be enough to get the display working
<cooloney> rsalveti: OK, I will try it soon
<rcn-ee> rsalveti, did you get the display working on the panda with 2.6.38-rc4?
<persia> rcn-ee, backscroll reports that rsalveti is having issues with the DVI port : cooloney had volunteered to look at the relevant patch.
<rcn-ee> ah, interesting..  Could be something with the  monitors i have here..
<persia> No, it's something with rsalveti's hardware
<persia> quoting "as my panda has a broken dvi, can't test atm"
<persia> Unless you had a HW hack to fix that?
<cooloney> rcn-ee: yeah, i am working on that
<rcn-ee> ah i see, (working my back in the scroll log.. )
<cooloney> rcn-ee: so mainline 2.6.38-rc4 kernel does support graphic things on Panda?
<rcn-ee> mainline + plus the patches posted on wednesday..
<rcn-ee> cooloney, these work on my panda a1.. http://dev.omapzoom.org/?p=anand/linux-omap-usb.git;a=shortlog;h=refs/heads/display-patches-for-v2.6.38-rc4  and they don't seem to break my c4 beagle board with the same uImage
<cooloney> rcn-ee: right, i pull the branch from Anand's display-patches-for-v2.6.38-rc4
<cooloney> rcn-ee: yeah, exactly
<cooloney> rcn-ee: what's kind of root fs you are testing for this?
<rcn-ee> the one thing i haven't tested is the edid stuff, so i did a "1024x768" value on the bootargs...  on that boot test, maverick...
<lilstevie> is anyone here good at fbdev :p
<persia> lilstevie, Try asking the question you'd ask if someone said "yes".  Someone might not consider themselves good, but may know the answer to your specific question.
<lilstevie> heh well I have no idea what is wrong
<lilstevie> the screen blinks the backlight on and off
<persia> What board?  Which image?
<lilstevie> rootstock made image
<lilstevie> and not a usual board :p
<lilstevie> galaxy tab
<persia> Heh, that makes it tricky :)
<persia> I'm not even sure what question would be useful to ask next (I know I don't know the solution to your problem, but I can usually get a bit further in the script :) )
<lilstevie> heh
<lilstevie> I do have logs
<lilstevie> and interactivity over ssh
<cooloney> rcn-ee: sorry, i was dropped
<rcn-ee> np cooloney, i believe i tested it on maverick, (defined the video x/y in the bootargs, didn't do edid).. but it might have been lucid/squeeze, i was testing other userspace things at the time..
<cooloney> rcn-ee: great, i am testing it with our natty userspace and wanna apply those patches to our ubuntu 2.6.38 based kernel
<rcn-ee> is this for the ppa one mentioned on the ubuntu-kernel list earlyier this week?
<cooloney> rcn-ee: from Anand Gadiyar's branch, i found 35+ patches on top of 2.6.38-rc4
<cooloney> rcn-ee: yeah, it is our ti-omap4-dev branch which is 2.6.38 based branch
<cooloney> i think for ti-omap4 stuff, it is almost the same as mainline
<rcn-ee> that's pretty strange, shouldn't have been that much..
<rcn-ee> i know there's 4-5 omap specfic ones that were merged in the rc3-rc4 so that wouldn't add up either..
<rcn-ee> (crap wrong patchset... it's 35..)
<cooloney> rcn-ee: from Raghuveer Murthy's description in DVI patch, it is only depends on 6 patches
<cooloney> rcn-ee: but i think pure 2.6.38-rc4 does not include DSS patches which is required for graphic on OMAP4 like panda
<rcn-ee> yeah, 2.6.38-rc4 only has the omap4 ehci/musb bits, nothing really else.. those 35 on top of that were enough for my dvi port to correctly work on the panda...
<cooloney> rcn-ee: so how did you test that DVI patch? apply those 6+1 patches on 2.6.38-rc4 kernel?
<rcn-ee> i applied the 35 on top of my current 2.6.38-rc4 tree.. https://github.com/RobertCNelson/2.6.38-devel/blob/master/patch.sh#L160
<cooloney> rcn-ee: ok, cool, man
<rcn-ee> yeah, rereading it on the linux-omap archive, Murthy does mention the other 6 patches, but it looks like Anand Gadiyar merged those 6 depencies into the group of 35..
<sebjan> rsalveti, cooloney: I already have a branch with the DVI patches working
<cooloney> sebjan: thanks a lot
<cooloney> sebjan: i'm just trying the DVI branch from Raghuveer Murthy
<cooloney> wanna apply those 35 patches in Anand Gadiyar's branch, but it failed on our ti-omap4-dev branch
<cooloney> some conflict
<sebjan> cooloney: I did not try yet to apply them on the ti-omap4-dev branch, I currently work on mainline (.38-rc4)
<cooloney> sebjan: yeah, i know some conflicts there, will try to solve them
<cooloney> and prepare a branch to test
<cooloney> sebjan: but i am not sure about those patches from Anand Gadiyar's branch, will they be merged into mainline?
<cooloney> it's about 35 patches
<sebjan> cooloney: they are reviewed on LO, but not sure about their status
<cooloney> sebjan: ok, so how about your patches?
<cooloney> DVI patches?
<sebjan> cooloney: let me clean and retest my branch and I send it to you (but tis shall be very similar to Anand's one)
<cooloney> sebjan: great, I will try Anand's soon after i solve those conflicts
<sebjan> cooloney: here is my git / tag: git://github.com/sebjan/linux-2.6.git topic-wlan-iv1-2.6.38-rc4 (https://github.com/sebjan/linux-2.6/tree/topic-wlan-iv1-2.6.38-rc4)
<sebjan> I have DVI working (from DVI connector P1)
<sebjan> and can choose the screen definition with these bootargs for ex: omapfb.mode=dvi:1024x768MR-24@60 omapdss.def_disp=dvi
<NishanthMenon> slnr, hi
<slnr> hi
<NishanthMenon> slnr, can you share the issue with gst-launch with mp3 decoder and filesink with ndec
<NishanthMenon> ndec, ping
<slnr> gst-launch filesrc location=test.mp3 ! mad ! filesink location=test.pcm
<slnr> this is working fine
<slnr> gst-launch filesrc location=test.mp3 ! omx_mp3dec ! filesink location=test.pcm
<slnr> this is not working
<NishanthMenon> slnr, this is for OMAP4 rt?
<slnr> yes
<NishanthMenon> slnr, one more place to ping is #gst_ti
<slnr> thanks
<NishanthMenon> slnr, np
<slnr> we will try to join that channel
<NishanthMenon> ndec, know anything about this pipe failing with ubuntu?
<persia> slnr, You have the omx packages installed, right?  (just for confirmation)
<NishanthMenon> persia, good Q -> slnr try gst-inspect | grep omx_mp3dec
<slnr> it is there
<NishanthMenon> slnr, does fakesink work?
<slnr> yes
 * NishanthMenon out of cookies :( defers to ubuntu experts
<slnr> yes
<slnr> we will try this and let you know
<NishanthMenon> slnr, ?? did you mean, you are now going to try gst-launch filesrc location=test.mp3 ! omx_mp3dec ! fakesink ?
<slnr> yes we tried
<slnr> with fakesink
<cooloney> sebjan: do you have the kernel config file for dvi patches testing?
<slnr> it works properly
<NishanthMenon> slnr, k.. /me out of ideas here..
<slnr> one sec
<slnr> we will cross check this pipeline once
<NishanthMenon> and alsasink works?
<sebjan> cooloney: yes, I have 2: one is minimal, and the other is an Ubuntu-like one. They are located into arch/arm/configs/omap4_panda_* (the 'full' one is an Ubuntu like)
<slnr> with alsasink it is working
<slnr> we just checked fakesink
<slnr> it fails
<persia> fakesink fails and alsasink works?
<sebjan> cooloney: the minimal one also boots with an Ubuntu FS (issue was: not devtmps + .38 issue with omap2plus and ARMv7 SMP)
<cooloney> sebjan: is it in the github?
<slnr> yes
<slnr> persia: yes
<sebjan> cooloney: yes shall be. let me cross-check
<persia> slnr, That's unexpected.  If fakesink fails, nothing ought to work, or something is very odd.
<slnr> ok
<NishanthMenon> slnr, can you post the log on pastebin.mozilla.org and provide us a link of what you see with gst-launch filesrc location=test.mp3 ! omx_mp3dec ! fakesink
<slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec !  fakesink/filesink fails
<sebjan> cooloney: confirmed, they are in my branch on github
<persia> Or paste.ubuntu.com :)  Lots of choices.
<slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec ! alsasink works
<persia> Then it's beyond what I know about gstreamer.  I've always believed that fakesink was a no-op.
<NishanthMenon> slnr, might help us to see the log. dont post the log straight here, instead post it to the paste.ubuntu.com and provide us the link
<slnr> NM: ok
<slnr> sure
<NishanthMenon> persia, i agree, I'd think of it as cat file>/dev/null fails and /dev/dsp works! hmm.. mebbe some weird handshaking requirements?
<persia> Heh, yeah, that's my thought.  But there are plenty of people more knowledgeable about gstreamer than I (although at this time of day, it may be a long wait until they are awake)
<slnr> NM: we are capturing the log and we will provide the link on pastbin in few mins
<NishanthMenon> slnr, thx.. mebbe you should check with #gstreamer as well in addition to #gst_ti.. u'd get a bunch of gstreamer experts there
<slnr> NM: ok
 * NishanthMenon suspects it might have something to do with ti gstreamer omx implementation
<NishanthMenon> some caps negotiation or something "implicitly expected by ducati"..
<NishanthMenon> sebjan, know who can help?
 * NishanthMenon hopes france folks not away on lunch yet ;)
<sebjan> NishanthMenon: not yet :)
<NishanthMenon> sebjan, :D gstreamer issue pretty much needing someone knowing gstreamer and omx_ti :( know anyone lurking arnd?
<cooloney> sebjan: i think we need enable the graphic driver for the DVI testing
<cooloney> sebjan: but it is disabled in your config
<ndec> NishanthMenon: hi
<slnr> NM: http://pastebin.mozilla.org/1047108
<NishanthMenon> ndec, good afternoon :)
<ndec> NishanthMenon: sorry was in meeting.. what's the problem?
<ndec> NishanthMenon: well, technically it's not noon yet ;-)
<ndec> NishanthMenon: where are u?
<NishanthMenon> ndec, slnr has this problem with gstreamer
<slnr> NM: you can see the logs
<NishanthMenon> ndec, blore atm
<NishanthMenon> slnr, yep
<NishanthMenon> ndec, can you glance at the log from slnr? looks like swapping the sink to fakesink instead of alsasink fails
<ndec> NishanthMenon: slnr: for audio MP3 we do not support OMX anymore. that was only on OMAP3
<NishanthMenon> ndec, how come alsasink works then?
<slnr> NM: we have run a video pipeline and
<ndec> NishanthMenon: ok.. too much backlog. can you summarize which pipeline fail?
<NishanthMenon> and looking at the log, it seems to go to GstOmxH264Dec:omxh264dec0!
<slnr> we have pasted the logs
<NishanthMenon> slnr, do u have any mp3 logs?
<NishanthMenon> not mp4 logs
<ndec> slnr: for gst-launch filesrc location=test.mp3 ! omx_mp3dec ! filesink location=test.pcm
<slnr> ndec: we will test mp3 too and paste
<NishanthMenon> slnr, the log you pasted is for video h264_dec!
<ndec> slnr: this is not expected to work. in fact we should removed the omx_mp3dec element for OMAP4 since it's not supported. on OMAP4 audio is thourhg ffmpeg, mad, libaac only
<slnr> ndec: ok
<NishanthMenon> slnr, have you really tested it?
<ndec> for the video pipeline using omx_h264dec element and fakesink, I think it's failing because the sink is expected to be 'tiler aware' which fakesink isn't
<slnr> ndec: can you analyse the video log
<ndec> slnr: does the video pipeline work with v4l2sink?
<slnr> NM: the log we capture fir video is now
<slnr> yes
<NishanthMenon> ndec, so no go for filesink or fakesink? sad..
<slnr> ndec: yes
<sebjan> cooloney: right, I just see Idid not upgrade the 'full' config with the display... The minimal one is up to date. Check the last commit for the relevant changes (otherwise, the minimal config can boot on a Ubuntu FS)
<NishanthMenon> slnr, yeah.. wondering how you claimed mp3 worked before
<NishanthMenon> quote "<slnr> persia: gst-launch filesrc location=test.mp3 ! omx_mp3dec ! alsasink works"
<slnr> NM: that was one ex
<slnr> NM: our colleague quoted as saying
<NishanthMenon> k, looks like it is wrong info
<slnr> NM: we were looking to video mainly
<NishanthMenon> ndec, any chance of looping video output to a file?
<NishanthMenon> some tileraware component that can route data to file/fakesink?
<slnr> i am unable to route video output to fakesink/filesink
<NishanthMenon> slnr, if you notice what ndec said, your sink should be tile aware. obviously file/fakesink is not and hence it fails
<NishanthMenon> v4l2sink is probably aware and should work
 * NishanthMenon wonders if there is something to route the video data to a file, helps for debugging usually - e.g. ssim comparison etc.
<slnr> NM: yes v4l2sink works, how to make filesink tile aware?
<cooloney> sebjan: https://github.com/sebjan/linux-2.6/blob/topic-wlan-iv1-2.6.38-rc4/arch/arm/configs/omap4_panda_defconfig also disabled DSS drivers
<ndec> NishanthMenon: to do this you need to copy the tiler buffer in a regular buffer, robclark would know more about this, he did it in gst-ducati. so with gst-ducati you can have a filesink. the plugin will check for the capabilities of the sink, and will do the necessaru
<ndec> /necessaru/necessary/
<NishanthMenon> ndec, ok.. looks like a few more hrs before robclark appears
<ndec> NishanthMenon: so for ex, with gst-ducati you can do video transcoding which you can't do with OMX ;-)
<NishanthMenon> ndec, thx for the tip ;) I get the message - "more limitations of OMX" yet again :P
<NishanthMenon> ndec, do you package gst-ducati with ubuntu?
<slnr> NM: can this be downloaded from the net??
<sebjan> cooloney: please look at my iv2 tag: https://github.com/sebjan/linux-2.6/tree/topic-dvi-iv2-2.6.38-rc4
<sebjan> cooloney: DSS and DPI are activated here: https://github.com/sebjan/linux-2.6/blob/topic-dvi-iv2-2.6.38-rc4/arch/arm/configs/omap4_panda_defconfig
<NishanthMenon> ndec, dunno.. u need to catch robclark when he comes online
<NishanthMenon> s/ndec/slnr
<slnr> NM: so my pipeline will look like omx_h264dec ! gst-ducati ! filesink location=test.yuv
<slnr> NM: is this assumption correct??
<cooloney> sebjan: thanks a lot, i looked at iv1 tag
<sebjan> cooloney: np
<cooloney> sebjan: so generally, it needs to enable DPI and Generic panel, right?
<NishanthMenon> slnr, i dont think it will be gst-ducati.. it probably will have different component name - ask robclark
<sebjan> cooloney: yes
<persia> janimo, So, the nature of omap4 only specifies booting from MMC: it doesn't specify whether that is SD or eMMC or what.  As a result, depending on the final retail design, it's perfectly conceivable that you'd end up writing internal flash when writing to MMC on some device.
<slnr> NM:  Thanks for the information
<janimo> persia, well I am not sure what else can be done to make this safer, short of not implementing the spec, but I am open to suggestions :)
<persia> janimo, But if you're special-casing only development boards, and won't be doing anything for retail devices, it's probably safe (and most developers like to be able to use newer bootloaders anyway)
<janimo> persia, I don't know anytihng about retails devices. You mean future tables and ARM based OEM sutff?
<janimo> If so they are tweaked by OEM anyway to prevent all kinds of snafu I hope
<persia> janimo, Doesn't have to be future, if you consider OMAP3
<persia> And if you presume that some OSV will tweak the OS, you are presuming nobody will want to run Ubuntu regularly, which I think is an unfortunate presumption.
<janimo> persia, rsalveti and ogra know more about the rationale and potential drawbacks than I do
<janimo> persia, I am not presuming but this is what I understood from the stories regarding OEM customization of Ubuntu
<janimo> that almost all are not quite vanilla images
<persia> janimo, I'm not suggesting you don't implement: just asking for care to make sure it only affects the development boards.  Retail shoppers don't tend to be as adept at recovering from bricked devices.
<janimo> persia, sure
<janimo> that is why probabaly the spec stated it should not be automatic
<persia> Most likely :)
<alf__> Hi! Any idea if Ubuntu can be run on Archos 101 tablets? It can supposedly run Angstrom, so I guess in the worst case someone can use the kernel from that.
<persia> alf__, Which processor do they use?
<alf__> persia: They only say "ARM Cortex A8 at 1 GHz with DSP"
<persia> alf__, Should work fine.  Needs investigation to ensure you can get a working kernel, but userspace ought have no issues.
<janimo> persia, in the meantime if you have suggestions about how to best solve the notification part of this BP I'd appreciate it. So far I was told about update-motd, jockey and debconf notes
<persia> What's the BP URL?
<janimo> https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update
<alf__> persia: aha, some more investigation reveals it is OMAP 3630, so it should be fine
<persia> And here I was hoping that was about porting coreboot :(
<janimo> persia, do you think that woudl make sense for these boards?
<persia> janimo, Reading the spec makes me feel a lot more comfortable in general.
<persia> Looks like we use the normal package update mechanism to update files, but never actually change the boot process.
<janimo> right
<persia> And then there is a tool that allows the user to install new boot files, if they like.
<janimo> although the installation of packages was questioned by ogra recently
<janimo> but then I am not sure if getting them is not much more hassle
<janimo> I'd rather apt&co would take care of that part
<persia> I like packages.  We know how to deal with packages.  That we don't actually deploy the delivered code is not so important.
<janimo> persia, I agree
<persia> I'd suggest using the update-notifier mechanism to suggest to the user that they run the update tool.
<persia> And maybe jockey to select the correct bootloader package to track, which would trigger the tool
<persia> (if the bootloaders all stuff things in /usr/share/bootloaders/... and the package in question has a trigger on the directory, and that trigger enables update-notifier, etc.
<persia> Because for a beagle A2, it would be nice to update the bootloader, but for the Archos 101 above, it's probably risky, at best, while we otherwise probably support the hardware reasonably.
<cooloney> sebjan: that's great, i saw our Natty Unity graphic via DVI port now
<cooloney> sebjan: i applied the patches on top of our ti-omap4-dev branch
<janimo> persia, do the above work just as well in headless mode?
<persia> triggers do.  I don't know about update-notifier.  You might want to have the trigger leverage both update-notifier and update-motd to handle both cases.
<persia> Nothing is going to handle remote X terminals well, but that's significantly less common than ssh sessions, console logins, or GUI environments.
<ogra> persia, the prob is that we cant seed it ... i'm not against packages
<persia> I'd be against seeding as well :)  Thanks for the clarification.
<ogra> i dont care how we get the binaries as long as we do get them in the right place with a single command
<ogra> if there are packages involved or if someone just dpkg -x'es them to /tmp, i totally dont care
<janimo> ogra, what about sort-of seeding via livecd-rootfs?
<ogra> fine with me as well
<janimo> ogra, as wgetting and figuring out version and generally doing apt's job is not too useful
<janimo> great
<ogra> apt-get -d <packagename>
<ogra> ;)
<persia> I'd prefer jockey to livecd-rootfs
<ogra> no wget needed
<persia> Just because, if things go as I hope, we'll see a wider variety of devices capable of using a common image.
<ogra> jockey doesnt really fell like it would fit the task
<ogra> *feel
<janimo> persia,  have no idea how jockey can be used here, do you have some pointers?
<janimo> does it not already know about packages being available?
<ogra> jockeys backend probably has checks and stuff
<ogra> but i wouldnt use the frontend here
<persia> jockey has a means to determine what hardware is present, and then encourage the installation of specific packages that help.
<ogra> iirc it talks about third party drivers and enabling additional HW in its UI
<persia> But, as ogra points out, it's probably only good to use the backend to get the data packages: the front-end is too inviting for the easily confused, and too annoying for the bare-metal types.
<ogra> we do neither here
<kish> hi.. i have a minimal maverick filesystem that works with arm.. it does not have dpkg.. and i want to install additional debian packages..
<persia> Install dpkg :)
<kish> only if i know how i can install it..
 * ogra wonders how you can have an ubuntu rootfs without dpkg in the first place
<persia> Hrm.  That gets tricky.  Do you know that your userspace is entirely compatible with Ubuntu?  If so, which release?
<persia> ogra, Careful manual hacking of the rootfs post-construction.
<ogra> heh, but very careful with much effort
<persia> kish, Do you have ar and tar available?  Alternately, do you have filesystem access to the rootfs from another device.
<persia> ogra, Yes: the sort performed by the most annoying class of OSV
<kish> yes.. i have tar ball available.. i access the rootfs from OMAP3430 using nfs..
<persia> NOTE: the following is disrecommended, dangerous, and incomplete
<kish> yeah.. fine..
<persia> I'd probably unpack the armel dpkg .deb (make sure you have the Pre-Depends working first), and install the files manually.
<persia> The run the preinst and postinst manually.
<persia> Note that dpkg may not work as expected when this is complete, as /var/lib/dpkg is likely not properly populated.
<persia> Mind you, the above is risky, and not in any way sure to achieve your goal.
<persia> In most cases, if you have the ability to replace the rootfs, you'd do better creating a new one from scratch.
<kish> i got that rootfs from someone else.. well then I'd probably try to create a new rootfs..
<persia> Easiest is probably to use the release image.  If that doesn't work, some people are happy with rootstock.
<lilstevie> how the hell do you get an ubuntu, or any debian variant for that manner without dpkg 0.o
<premkiran> Hi
<premkiran> Did anyone try arecord on ubuntu on OMAP4 blaze board
<persia> !ohmy | lilstevie
<ubot2> lilstevie: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<premkiran> We observe that the arecord on ubuntu is not working for blaze
<persia> lilstevie, Consider that someone could create a rootfs, and then delete individual files.
<premkiran> NM: we see arecord has a problem with ubuntu on blaze
<slnr> hi NM
<slnr> NishanthMEnon: we were discussing about the issue of http://pastebin.mozilla.org/1047108
<RBT> rob: gst-launch filesrc location=Angelina.mp4 ! qtdemux ! nal2bytestream_h264 ! omx_h264dec ! filesink location=test.yuv
<RBT> this pipeline fails
<RBT> rob: unable to dump in yuv file
<persia> RBT, Is this different than the issue with not supporting untiling buffers identified before?
<RBT> persia/rob: gst-launch filesrc location=Angelina.mp4 ! qtdemux ! nal2bytestream_h264 ! omx_h264dec ! v4l2sink
<slnr> persia: me and RBT are together
<RBT> this pipeline works fine on blaze
<persia> I thought ndec said this was expected behaviour.  If it's a bug, then it's worth reporting a bug, but if it's expected, then use gst-ducati
<slnr> persia: we installed gst-ducati
<slnr> persia: we do not have pointers of how to fix the pipeline with gst-ducati
<persia> Doesn't that have a different gstreamer bit than omx_h264dec ?
<persia> I'd think you'd want ducatih264dec
<persia> But i'm just guessing, really.
<persia> (based on http://bloggingthemonkey.blogspot.com/2010/11/announcing-libdce-and-gst-ducati.html )
<slnr> persia: did not get
<persia> If you want to use a different decoder, you need to change the gstreamer pipeline.  Just installing a different package gives you the capability to use a different decoder, but doesn't actually use it.
<slnr> persia: yes we understand
<slnr> persia: so you say we can replace the omx_h264dec with ducati plugin and check ??
<RBT> persia: we are looking for both playback and capture. for eg gst-launch omx_camera mode=1 exposure=1 awb=1 nsf=1 device=secondary output-buffers=2 name=cam cam.src ! "video/x-raw-yuv-strided, format=(fourcc)NV12, width=864, height=480, framerate=15/1" ! ffmpegcolorspace ! omx_h264enc input-buffers=3 output-buffers=2 bitrate=4000000 profile=1 level=2048 ! qtmux ! filesink location=/home/blaze/test_
<RBT> 1.mov
<persia> That's what I'd do if I was having that problem, but I'm just guessing.  I have no deep knowledge about the issue.
<ndec> RBT: capture? our public ducati firmware does not support capture and encode.
<slnr> # looking into capabilities of ducati plugin
<persia> RBT, From the backscroll, I have the impression that if you're working on an OMAP4 platform, you want to use the ducati* plugins, rather than the omx_* plugins.  Change your pipeline.
<persia> Ah, if no capture, then no capture :)
<kish> hi.. i use a minimal maverick filesystem on OMAP3. whenever i execute any command I get an illegal instruction error..
<persia> kish, Are you sure you're using an armel filesystem with armel packages?
<kish> yes.. the same file system works well in omap4..
<persia> Very odd.
<vstehle> kish: does your kernel support thumb2 ?
<kish> i see "# CONFIG_THUMB2_KERNEL is not set" and CONFIG_AEABI=y" in my .config
<vstehle> kish, not sure if 'CONFIG_THUMB2_KERNEL' means "kernel supports thumb2 user space" or "kernel compiled in thumb2 (experimental)"
<kish> ok i'll give a try..
<lool> vstehle: I don't think there's a tunable to disable Thumb 2; I think this is to build your kenrel as a Thumb 2 binary
<vstehle> lool: I think you can disable support for thumb2
<vstehle> Lxr says thumb2_kernel means kernel compiled in thumb2. kish, this is not this one
<vstehle> http://lxr.linux.no/#linux+v2.6.35/arch/arm/Kconfig#L1194
<kish> err.. crashed when i set CONFIG_THUMB2_KERNEL
<lool> CONFIG_THUMB2_KERNEL is definitely to have a kernel using thumb itself
<apw> ogra, is ubuntu-mobile@lists still valid ?
 * apw notes that is where he is sending natty upload notificaions to ...
<ogra> apw, nope
<lool> vstehle: I don't see the option to disable thumb in arch/arm/Kconfig
<apw> do you get those?  i am not getting an error
<vstehle> lool, yeah me neither. I should have mistaken with NEON, sorry.
<ogra> apw, not sure, they might get /dev/null'ed
<apw> ogra, now that has to be the silliest idea ever
<ogra> i dont get any mails from that list anymore
<ogra> to be honest i have no idea whats IS policy of shutting down a list
<sebjan> lool, vstehle, kish: are you looking for CONFIG_ARM_THUMBEE?
<vstehle> nope. Thumb2
<vstehle> (thumbee is more "java")
<dmart> vstehle: did you solve your problem?
<vstehle> dmart, you mean kish's problem ? :)
 * dmart scrolls back
<dmart> vstehle: ummm, yeah
<dmart> looks like he's gone anyhow
<rsalveti> janimo: how did your x-loader/u-boot update testing go?
<rsalveti> janimo: did it work fine? or did it break?
<janimo> rsalveti, well it seesm copying works, but not all the time. It may not be the copy itslef but rather the version of the firmware?
<janimo> should versions of x-loader and u-boot be independent?
<janimo> tried xloader 1.41 and would not start (Xloader hung)
<ogra> they are not aligned atm
<rsalveti> janimo: but what version did you use?
<janimo> but I am testing
<rsalveti> not aligned
<janimo> defaults from natty and those from an angrstrom page
<rsalveti> because if you get it quite frequently, then it'll be good to change the tool to recreate the first partition
<janimo> ok not aligned but can they be incompatible? like uboot require a minimum version of xloader?
<janimo> rsalveti, indeed, let's see how testing goes
<rsalveti> janimo: well, it should be fine if you test the maverick's x-loader/u-boot with natty's one
<janimo> ok
<rsalveti> janimo: and also, you set the create the wiki page to done, but it's still a work in progress
<janimo> well it is created
<rsalveti> :-)
<janimo> it reflects the current status :)
<rsalveti> yeah, not the best word used there
<janimo> the rest is bugfixing/polish.
<janimo> I just need to figure out which of the many proposed notification solutions is the simplest and most effective
<janimo> without having to explicitly differnetiate between gui and headless if at all possible
<rsalveti> yeah, true
<alf__> rsalveti: (sorry to repeat this, I am not sure if it got through because of the netsplit)
<alf__> rsalveti: Any luck with clutter and the shaders?
<rsalveti> alf__: http://bazaar.launchpad.net/~rsalveti/clutter/gles/view/head:/debian/patches/defining-correct-shader-precision-gles.patch
<rsalveti> then it worked fine
<alf__> rsalveti: so the precision is needed in the vertex shader, too... interesting
<rsalveti> yup, otherwise it still break
<alf__> rsalveti: the question is whose fault this is? Is sgx not following the standard?
<rsalveti> yeah, I'd say yes, but still need more debugging
<rsalveti> will also try with latest sgx drop as soon I get it working with natty
<rsalveti> this version I'm using is not supported anymore
<alf__> rsalveti: From the standard: The vertex language has the following predeclared globally scoped default precision statements:
<alf__> precision highp float;
<alf__> ...
<alf__> The fragment language doesn't have that
<alf__> The fragment language has no default precision qualifier for floating point types
<rsalveti> alf__: well, this is clearly not the case for sgx
<rsalveti> at least the patch is not going to break others
<rsalveti> but should be fixed inside sgx
<rsalveti> alf__: as soon I can test the new pvr driver I'll report that to imagination
<alf__> rsalveti: what puzzles me is that glmark2 should fail, too, (because it doesn't declare float precision in vertex shaders)
<rsalveti> alf__: probably
<rsalveti> did you test that with omap 4?
<alf__> rsalveti: but last time I tried it it worked (on the SDP)
<rsalveti> hm
<lool> persia: I wrote u-boot-linaro-efikamx and an uImage created with mkimage -A arm -O linux -T kernel -C none -a 0x90008000 -e 0x90008000 -n Linux from linux-linaro-mx51, and could boot up to a kernel panic looking for rootfs
<lool> persia: seems to work fine on efikamx; I see USB EHCI, consoles, MMC... and obviously serial
<persia> lool, Thanks for checking that.  I'm filled with new confidence.  After the 2.6.38-rc5 release, I'll identify specific patches to add to improve things.
<Lopi> Does anyone have any recommendations for virtual keyboards?
<Lopi> I made a custom keyboard layout for matchbox-keyboard and it works decent
#ubuntu-arm 2011-02-12
<XorA|gone> persia: I made tokyo :-D
<YanksRule> !ops
<ubot2> Help! Channel emergency! (ONLY use this trigger in emergencies) - elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici, jpds, gnomefreak, bazhang, jussi, Flannel, ikonia, maco, h00k, IdleOne, nhandler, bilalakhtar, Jordan_U, or rww!
<YanksRule> !ops
<ubot2> Help! Channel emergency! (ONLY use this trigger in emergencies) - elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici, jpds, gnomefreak, bazhang, jussi, Flannel, ikonia, maco, h00k, IdleOne, nhandler, bilalakhtar, Jordan_U, or rww!
<YanksRule> !ops\
<ubot2> Factoid 'ops\\' not found
<YanksRule> !ops
<ubot2> Help! Channel emergency! (ONLY use this trigger in emergencies) - elky, Madpilot, tritium, Nalioth, tonyyarusso, PriceChild, Amaranth, jrib, Myrtti, mneptok, Pici, jpds, gnomefreak, bazhang, jussi, Flannel, ikonia, maco, h00k, IdleOne, nhandler, bilalakhtar, Jordan_U, or rww!
<YanksRule> !staff
<ubot2> hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, stew or tomaw, I could use a bit of your time :)
<Amaranth> Oh, I do have access here
<Amaranth> (he is permbanned from the ubuntu namespace for doing that in every channel he finds)
<Baybal> a bot of some kind
<lilstevie> lol
<persia> Amaranth, Thanks for taking care of that.
<RBT> i am trying to capture image with the following pipeline
<RBT> gst-launch omx_camera mode=2 focus=1 exposure=0 awb=0 device=secondary output-buffers=4 image-output-buffers=1 name=cam cam.src ! "video/x-raw-yuv-strided, format=(fourcc)UYVY, width=864, height=480, framerate=30/1, buffer-count-requested=4" ! queue name=q3 ! v4l2sink device=/dev/video1 min-queued-bufs=2 sync=false cam.imgsrc ! "video/x-raw-yuv, format=(fourcc)UYVY, width=864, height=480,...
<RBT> ...framerate=30/1" ! queue name=q1 ! pngenc ! avimux ! filesink location=/home/blaze/test_h264_img.avi
<RBT> plz let me know the mistakes in this pipeline
<persia> RBT, Are you sure omx_camera is supported for the blaze?  I also thought I saw ndec say earlier that capture was not supported.
<RBT> persia: now we are able to capture using omx_camera
<RBT> persia: but we are unable to capture the image
<RBT> i mean Video capture is working not the image capture
<persia> If you're sure.  I don't know anything about pipelines: I just worried you might be using the wrong capture call.
<ogra> hmm, jani seems to have broken livecd-rootfs
<ogra> hmpf abnd he didnt commit the change in truml
<ogra> *trunk
 * ogra fixes
<GrueMaster> ogra: I thought it was the kernel team when they removed the dove image.  Apparently the linux-headers-dove package is pulled, but since there is no actual kernel headers package the build fails.
<ogra> GrueMaster, two different issues
<GrueMaster> Ah.  ok.
<ogra> one is janis change for omap3 (which doesnt get far enough to break on the dove headers) and omap4 fails with the missing headers
<DTNposix> hi.
<DTNposix> !
<DTNposix> I'm having a problem with rootstock.
<DTNposix> I've built about 20 images, but I can only get ubuntu 9.04 to work properly.   Something about importing to mono.
<DTNposix> Anyone have any ideas?
<DTNposix> I could really use some help.  I'd like any modern system to run on my android.
<DTNposix> ubuntu, kubuntu, kubuntu-mobile, ubuntu-netbook....
<DTNposix> they all have problems building qemu images.
<DTNposix> is anyone here
<DTNposix> I've put about 30 hours of work into trying to get ubuntu running...
<DTNposix> I could really use a bit of help or at least someone to say it's impossible.
<DTNposix> lxde seems to be the only one compiling because of a pacakge called mono
#ubuntu-arm 2011-02-13
<topfs2> rsalveti, a little sneak peak on what I have been working on the last few days http://img97.imageshack.us/img97/5225/xbmcgstreamer.png Only h264 atm and seeking is rather buggy and not tested on arm. Good part is that this is implemented in the current player, which is the proper way it should be done and not how most have thought of doing it
<RBT> libOMX.TO.JPEG.encoder.so.0: cannot open shared object file: No such file or directory
<RBT> any sources to download this file
<persia> You might find apt-file useful as a tool to answer that sort of quesion.
<xerebz> i just installed the maverick image onto my sd.. it booted once then restarted shortly thereafter now it's just stuck on an uncompressing linux.. done booting the kernel
<xerebz> do i have to cut off power and change boot.scr?
<xerebz> to make a console show up?
<xerebz> where is boot.scr?
<xerebz> should i just let it run?
<xerebz> can anyone help with first install?
<persia> What hardware?
<xerebz> beagleboard
<xerebz> xm
<persia> And where are you looking for a console?
<xerebz> well i just installed it
<xerebz> it expanded the root partition
<xerebz> and now i'm wondering where to go next
<persia> Yes, but on what device are you looking for console?  serial?  virtual terminal?
<xerebz> i'm on the serial port
<xerebz> i also have a dvi monitor connected to it
<persia> Does anything appear on the monitor?
<xerebz> but nothing's coming out of that
<persia> I'm not entirely sure, but I *think* that you should expect stuff to happen on the DVI monitor.  If it isn't, I think you have to put a console= line in your kernel command arguments.  I suspect that involves editing the boot.scr in the VFAT partition on the SD, but I've never tried that.
<xerebz> after the sd resize i can't mount the vfat partition anymore..
<persia> That's unexpected.  It ought to leave that their.
<persia> s/their/there/
<xerebz> nvm i had to mount it manually for some reason
<XorA> ouch my feet hurt
<persia> heh.  This is a walking city :)
<xerebz> which city?
<persia> Tokyo.
<xerebz> woah cool yall working in tokyo?
<persia> Only some folk.
 * XorA has covered many miles of tokyo pavement today
<xerebz> i just installed minimal ubuntu, now i installed xfce
<xerebz> how do i get it running?
<rcn-ee> xerebz, did you try rebooting?
<xerebz> rcn-ee: my dvi tv was not capable of the resolution in boot.scr
<xerebz> i lowered it to 1024x768 and it worked fine
<rcn-ee> ah.. yeah an edid detect would be nice for the beagle.. i know it works for the panda, but those bits aren't upstream yet..
<xerebz> i connected my camera and its running smooth on luvcview but every so often it has graphical glitches and hangs
<rcn-ee> any error hints in dmesg?
<xerebz> none but this used to happen on my old comp
<xerebz> never on my new faster comp
<xerebz> hm..
#ubuntu-arm 2012-02-06
<krosswindz> I am trying to build a new kerne
<krosswindz> kernel*
<krosswindz> I am surprised that when I run debian/rules editconfigs it picksup armel as well when I am running armhf
<twb> All I know is I get the upstream kernel and run "make deb-pkg"
<krosswindz> twb: I am not sure if upstream has all the omap changes
<krosswindz> that ubuntu has
<twb> Shrug
<krosswindz> Is anyone using any method to cool the pandaboard
<krosswindz> I am building the kernel natively and dmesg is full of thermal messages
<krosswindz> http://pastebin.com/JxrEkATz
<twb> krosswindz: have you got yours inside a case at all?
<twb> Does the panda's power brick have active cooling?
<twb> (I don't have one)
<krosswindz> twb: i dont have the panda in a case
<krosswindz> twb: the power brick doesnt have active cooling
<twb> What's the ambient temperature?
<twb> If it's like 40\degC, that wouldn't be so suprising
<krosswindz> room temp is much lower
<krosswindz> I guess I might have to move the board from its current location so that it gets more free air
<krosswindz> room temp is probably in the 20s
<twb> Also worth checking if throttling governor &c are on
<krosswindz> i think throttling governor is on which is what is switching the frequency
<krosswindz> the omap_thermal_step_freq_down
<twb> /sys/devices/system/cpu/**/cpufreq/scaling_governor
<krosswindz> ondemand
<twb> That's OK then
<twb> I dunno what else to check
<krosswindz> twb: not a problem
<krosswindz> I was just wondering
<twb> FWIW native compiles on TF101 don't overheat that
<krosswindz> hmm
<krosswindz> ok
<doug> mmm, nice.
<doug> i'm trying to find ARM benchmarks...
<doug> a passmark would work pretty well
<doug> or some other general all-around benchmark that has a baseline on a VAX
<doug> or, barring that, some way to get onto an ARM box to run a benchmark
<doug> hosting service that'll take cash, or ARM enthusiast that'll take beer
<twb> doug: dmips is easy enough
<twb> http://homepages.cwi.nl/~steven/dry.c
<twb> Other (non-synthetic) benchmarks usually involve compiling GCC &c, but they cost money
<twb> The third run in "sh dry.c" output for me, on a dual-core A9, is Microseconds for one run through Dhrystone: 0.4; Dhrystones per Second: 2602811
<twb> With -O3 I get down to 0.3us / 3003003 DMIPS
<twb> Er, 3003 DMIPS, since M is million
<scientes> infinity, can you post that "magic chroot" code again?
<scientes> nvm
<infinity> scientes: As in, copy /usr/bin/qemu-arm-static to chroot/usr/bin?
<scientes> yes, i remember
<scientes> that is so slick
<twb> Note that prior to 1.x qemu-arm-static had some bugs
<twb> Most obviously triggered when using hard float
<scientes> thing with --no-install-recommends, is that emdebian grip actually changes the apt default to that, so i got lazy
<scientes> im using 11.10
<twb> fortunately it's static so you can simply build qemu-arm-static and copy the binary wherever you want
<scientes> twb, indeed
<scientes> or copy the binary/install the .deb anywhere
<twb> The .deb is marked as belonging the the host arch, though, so you can't sensibly install it inside the chroot
<twb> you only need it inside the chroot, you understand, the only thing the host part cares about is the binfmt-support hooks
<scientes> well, ar x and tar works file too
<scientes> how do you extract only one file from a tar on the command line?
<scientes> (however many probably dont know you can do that with .deb files)
<twb> scientes: if you're not going to dpkg -i it there is no point carrying around more than the single qemu-static-arm binary
<twb> scientes: dpkg -x, rather.
<twb> *That is, dpkg -x rather than ar+tar.
<scientes> of course, but im talking about the something you generally are doing one-off
<scientes> twb, ahh that would probably be cleaner than using ar+tar, thx
<twb> You can't extract a single file unless using ar+tar AFAIK, in which case you just do it the tar way
<carli2> hi
<carli2> i have a beagleboard and I want to install the sgx drivers
<carli2> the software renderer is slow
<carli2> i'd like to provide a SD image with preinstalled omapfb drivers, is that possible? is there a toolchain to build custom ubuntu installation images?
<ndec> carli2: what do you mean exactly?
<ndec> carli2: is this what you are looking after http://omappedia.org/wiki/Add_Packages_To_Ubuntu_Preinstalled_Images
<carli2> ndec: ah thanks :)
<carli2> but isn't chroot architecture specific?
<carli2> i should run chroot on a arm system
<ndec> nope.
<ndec> you can cross chroot
<carli2> or does it include a qemu-call?
<ndec> with qemu
<ndec> ok... it seems that the wiki only explains the native chroot.
<ndec> but it would work with cross chroot too.
<carli2> how can I delete all users created at installation time and turn the system back into OEM status?
<ndec> you basically need to install qemu-user-static, and then sudo cp /usr/bin/qemu-arm-static /<your chroot>/usr/bin/, then you can cross chroot from x86 into the ubuntu arm rootfs
<ndec> i don't think you can. or at least i don't know. perhaps infinity would know that... but I still think it's best to start with the preinstalled image before doing the installation.
<ndec> as per the wiki i gave
<carli2> configure a preinstalled ext2/3 system image "jasper"
<carli2> how much faster would the hardfloat image be?
<carli2> and no libreoffice
<carli2> but it's installable :)
<carli2> after installing the sgx drivers, the monitor stays black
<micadeyeye_> hi
<micadeyeye_> I can't login to Ubuntu on my Pandoboard
<micadeyeye_> Login timed out after 60 seconds.
<micadeyeye_>                                                                                 
<micadeyeye_> Ubuntu 11.10 localhost.localdomain ttyO2
<micadeyeye_>                                                                                 
<micadeyeye_> localhost.localdomain login: root
<micadeyeye_> Password:
<micadeyeye_> kindly help!!
<GrueMaster> micadeyeye_: Did you run through the oem-config installer?  It sets up a default account and hostname.
<GrueMaster> Which image are you using?
<micadeyeye_> GrueMaster, ubuntu 11.04 from here http://www.omappedia.org/wiki/OMAP_Ubuntu_Core
<micadeyeye_> I didn't run the oem-config.
<infinity> You also didn't read the instructions there that point out that you need to either remove or set root's password.
<micadeyeye_> i didn't see that.
<infinity> The page recommends just making root passwordless.  I'd recommend setting a password or adding a user, but whatever works better for your use-case.
<GrueMaster> This is not an "Ubuntu supported" installation method.  My best suggestion is to either use one of the preinstalled images from cdimage.ubuntu.com or follow those instructions carefully and ask the author for support.
<doug> what's the quickest(/best?) way for me to get an account on an ARM box?
<GrueMaster> Buy an arm box and install Ubuntu on it?
<micadeyeye_> I thought it wasn't using a password. I followed the instructions and did this "edit the file /etc/shadow and remove the '*' character in between the semi-colons. You"
<micadeyeye_> I am running ubuntu on pandaboard
<doug> hm, what's the cheapest arm box that i can buy (today)?
<micadeyeye_> I got the rootfs from - http://cdimage.ubuntu.com/ubuntu-core/releases/11.10/release/ubuntu-core-11.10-core-armel.tar.gz
<GrueMaster> doug: It really depends on your needs.  I think the beaglebone (http://beagleboard.org) is probably the cheapest that we can support in Ubuntu, but there are better depending on hw needs.
<infinity> micadeyeye_: GrueMaster is right, we don't support core as a bootable/installable OS.  It's meant for people to build on top of.
<infinity> micadeyeye_: If that's not really working out for you, you might want to try a more full-featured installer, like ubuntu-desktop or ubuntu-server.
<micadeyeye_> infinity, am not sure they would run on my omap4 device.
<doug> my need is certainly to find something dirt cheap
<suihkulokki> doug: Some board from Arduino family
<doug> ubuntu on arduino?
<infinity> micadeyeye_: You're using a non-standard kernel?
<suihkulokki> doug: no ubuntu, but dirst cheap
<micadeyeye_> I think so.
<doug> yeah, need something that'll run a linux, something with an MMU
<micadeyeye_> wget http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current/images/omap4/netboot/MLO
<micadeyeye_> wget http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current/images/omap4/netboot/u-boot.bin
<micadeyeye_> wget http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current
<GrueMaster> Well, the "cheapest" is certainly less than that (raspberry PI comes to mind), but we only support hardware that has ARMv7 technology.
<doug> pi isn't armv7?
<micadeyeye_> doug, try Pandaboard
<infinity> micadeyeye_: Right, well, if you need to build something from scratch, just chroot into your ubuntu-core system on another box and "passwrd root" before you boot it.
<micadeyeye_> they now have pandaboard es
<infinity> micadeyeye_: Err, that's the standard Ubuntu omap4 kernel.
<GrueMaster> doug: If you go with something less, you can always run debian.  And no, Raspberry Pi is Armv6.
<suihkulokki> I don't know that would be the cheapest, but beaglebone at 89$ is probably closest
<infinity> micadeyeye_: If you use one of our full-featured images, it'll be exactly the same kernel.
<micadeyeye_> but it's requesting a pwd.
<suihkulokki> cheapest to run ubuntu, that is
<GrueMaster> micadeyeye_: What platform are you running on?
<doug> yeah, beagleboard is what, $89?  3 times the advertised price of the (low-end) pi
<micadeyeye_> pandaboard (omap4)
<infinity> micadeyeye_: Please, just use an image with an installer.
<micadeyeye_> Ubuntu 11.04
<suihkulokki> well lets see what the pi price will turn out tu be in reality
<GrueMaster> micadeyeye_: Then use one of our omap4 preinstalled images.
<infinity> micadeyeye_: http://cdimage.ubuntu.com/releases/11.10/release/
<infinity> micadeyeye_: Either ubuntu-desktop omap4 or ubuntu-server omap4, depending on if you want pretty things or not. :P
<micadeyeye_> okay
<GrueMaster> micadeyeye_: If you want greater speed and performance, you can also try our latest alpha 2 of 12.04.  http://cdimage.ubuntu.com/releases/precise/alpha-2/
<GrueMaster> According to Phoronix, the performance improvements are pretty good.  http://www.phoronix.com/scan.php?page=article&item=ubuntu_1204_omap4460&num=1 (note that we did not run or commission these tests - they just look awesome).
* GrueMaster changed the topic of #ubuntu-arm to: Ubuntu ARMv7 Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Get Precise Alpha2 while it's hot! http://cdimage.ubuntu.com/releases/precise/alpha-2/ Includes armhf images! | Logs at http://irclogs.ubuntu.com/
<pbuckley> any progress on ALSA lib main.c:260:(execute_sequence) unable to open ctl device 'hw:Panda'
<pbuckley> ?
<GrueMaster> pbuckley: Not yet.  The kernel team just got the bug late last week, and I am sure they are looking at it.
<pbuckley> k.. :) thanks for the follow up.. what was the bug id again? I forgot to bookmark
<GrueMaster> bug 925069
<ubot2> Launchpad bug 925069 in linux-ti-omap4 "No analog audio on omap4 panda" [Undecided,Confirmed] https://launchpad.net/bugs/925069
<pbuckley> thank you
<pbuckley> ooh
<pbuckley> looks like they might already have a patch
<pbuckley> any gotcha's about compiling ubuntu kernels?
<GrueMaster> Yea, I don't do them.  :P  Seriously, I don't know other than they take a while on panda.
<pbuckley> well
<pbuckley> at least they compile the kernels with /proc/config.gz support
<pbuckley> that makes it alot easier in theory
<prpplague> lag: greetings
<lag> prpplague: Howdy
<lag> prpplague: Are you well?
<prpplague> as well as can be expected, hehe
<lag> Struggling on by
<lag> :)
<lag> You're not at Connect are you?
<prpplague> lag: not this time, too many irons in the fire
<lag> prpplague: Right, no probs
<lag> prpplague: I wanted you to bring a Flyswatter so we could test it on Snowball
<lag> prpplague: I have some other toys to play with too
<prpplague> lag: ahh, i'll be at ELC on thursday of next week
<pbuckley> kernel source tree has changed pretty drastically since last time i looked
<pbuckley> where is my make oldconfig :(
<lag> prpplague: Unfortunately I'm giving this one a miss
<prpplague> lag: bummer
<lag> prpplague: I know dude - I usually like to attend
<prpplague> lag: i've already allocated my budget of freebie flyswatter2's for this month, let me see what i can do to get one to you for testing
<doug> hm, what's the cheapest i can get an ubuntu-support ARM box for?
<pbuckley> 35 bucks?
<pbuckley> assuming small quality
<pbuckley> bulk orders im sure you could find cheaper even
<pbuckley> actually there is a 25 dollar version too
<pbuckley> ;)
<pbuckley> (raspberry pi) which i assume will have ubuntu on it at somepoint
<pbuckley> though i doubt it will ever run x
<infinity> pbuckley: The Pi can't run Ubuntu.
<infinity> pbuckley: It's ARMv6, we only support v7.
<lag> prpplague: I didn't mean to keep - would just be good to get some shots up of it working great with snowball :)
<pbuckley> really?
<pbuckley> damn so much for that idea
<infinity> pbuckley: Really.
<pbuckley> pandaboards then
<pbuckley> but those are like 180
<infinity> doug: The cheapest Ubuntu-supported board you can get is probably the beaglebone.
<prpplague> lag: no worries, we want to make sure it works with as many items as possible
<pbuckley> oh right
<pbuckley> forgot about the beagle's
<infinity> doug: But the Panda or mx53 quickstart are better options, IMO.
<pbuckley> oh and there is the pandaboard and pandaboard es
<pbuckley> so many flavors
<doug> hm.
<doug> beaglebone is $89, right?
<pbuckley> i personally use the pandaboard es as a desktop
<krosswindz> is there any particular reason precise kernel is missing the pandaboard OTG port kernel module
<doug> i'm particularly interested in running stuff as a server
<GrueMaster> krosswindz: File a bug against linux-omap4 please.
<doug> headless, etc.
<krosswindz> GrueMaster: sure
<GrueMaster> doug: Depending on the type of server, you would probably be better off with the mx53 as it has native SATA.
<pbuckley> its a freescale chip no?
<GrueMaster> Having said that, I can also say that the Panda does really well on server loads too.
<GrueMaster> yes, Frescale.
<pbuckley> yeh.. the pandaboard sucks at disk io :(
<GrueMaster> Here is a list of tests I ran last cycle for arm server.  https://wiki.ubuntu.com/ARM/QA/Server
<pbuckley> even usb drives are pretty bad
<pbuckley> though 12.04 seems to have improved sd performance at least
<GrueMaster> Note that I also ran Raid, iSCSI (client & host), and CEPH ClusterFS, all on pandas.
<pbuckley> oh nice
<pbuckley> i was thinking about iscsi
<pbuckley> how did that go?
<GrueMaster> Well, it initially had issues (same as on x86 when I ran it), but those have been fixed.  I haven't tested it again this cycle, but it is on the todo list.
<pbuckley> Requires a bit of manual configuration. iSCSI-root fails to boot. See LP:838809
<pbuckley> ah ok
<GrueMaster> It will still need either an SD for u-boot or optionally it can boot from a host pc through the OTG port.
<GrueMaster> (documentation on that feature coming soon).
<doug> hm, where's a good place to buy mx53 quickstarts from?
<infinity> Digikey.
<pbuckley> does digikey sell them?
<pbuckley> if so i would go there
<infinity> Digikey sells everything anyone could ever want.  If you want it and they don't have it, you're wrong about wanting it.
 * infinity nods.
<pbuckley> hahaha
<GrueMaster> Yes, I bought two through digikey (and one direct from Freescale).
<pbuckley> how does the mx53 compare to the panda as far as x performance goes?
<pbuckley> that sata port is tempting
<krosswindz> GrueMaster: against linu-omap4 or linux-ti-omap4?
<GrueMaster> Note that the newer START-R model doesn't run Oneiric, and until we get a new kernel in the pool, it won't run Precise.
<pbuckley> oh nm
<GrueMaster> krosswindz: linux-omap4.  Send me the bug number and I can make sure it gets triaged.
<krosswindz> ok
<pbuckley> you can take precise from my cold dead fingers
<GrueMaster> heh.
<infinity> pbuckley: X performance on the quickstart is good.  Its only real failing is the slower CPU.
<infinity> GrueMaster: Does the new 3.1.x kernel we just shoved in still not boot the START-R?
<GrueMaster> When did that get uploaded?
<infinity> I processed it through NEW yesterday.
<infinity> And updated the meta yesterday.
<GrueMaster> Oh, well I will check it out then.
<GrueMaster> (I wasn't working this weekend).
<infinity> Yeahp, fair enough.
<infinity> Oh, speaking of not working on weekends, can you give me a reminder of those flash-kernel/preseed bug numbers?
<krosswindz> GrueMaster: bug#: 927860
<infinity> I'll get to them when I'm bored here at Connect.
<GrueMaster> bug 927860
<ubot2> Launchpad bug 927860 in linux-meta-ti-omap4 "Missing musb-hdrc module required by Pandaboard OTG port" [Undecided,New] https://launchpad.net/bugs/927860
<krosswindz> GrueMaster: ubuntu-bug files it under linux-meta-ti-omap4
<krosswindz> GrueMaster: not sure why
<GrueMaster> Don't worry, I can fix it.
<krosswindz> GrueMaster: thanks
<krosswindz> GrueMaster: it only affects Precise, oneiric 3.0 kernel has it compiled into the kernel
<GrueMaster> Interesting.
<GrueMaster> Ok, I tweaked the bug report and assigned it to our kernel engineer.  We should see an update later this week.  Can you enable it and test it in the mean time?  If it works, post your results to the bug.
<krosswindz> GrueMaster: Yes I am trying to build the kernel by myself
<GrueMaster> infinity: I'll try to get to the f-k-i fixes this afternoon (after lunch).
<krosswindz> GrueMaster: The first time I built it and was doing testing I didnt realize it was missing.
<GrueMaster> Ah.
<krosswindz> GrueMaster: I will keep you updated on the progress, I am at work now :( the board is at home.
<GrueMaster> brb - need to feed.
<prpplague> oh lord, who let jkridner in here?
<jkridner> :)
 * prpplague shakes his head at the low requirements for entry into #ubuntu-arm
<pbuckley> lol
<infinity> GrueMaster: I had it mostly coded in my head anyway, just forgot the bug numbers and lost them in scrollback.
<doug> hm, i found one ms53 board retailing for $149...
<doug> from newark.com
<pbuckley>  never used em
<pbuckley> digikey has always done right by me
<doug> hm, digikey's MCIMX53-START-R-ND is also showing up as $149
<pbuckley> there you have it
<doug> now if i could just find a good source for pricing on the cpu itself
<doug> digikey says "call"
<pbuckley> it depends on the quanity
<pbuckley> (usually)
<doug> well sure
<pbuckley> if i apt-get install linux-source-3.2.0 will that give me the correct branch? or should i pull it out of a git repo somewhere?
<GrueMaster> pbuckley: apt-get source linux-ti-omap4
<pbuckley> ah thanks
<infinity> Which will get the meta. ;)
<infinity> apt-get --only-source source linux-ti-omap4
<pbuckley> should i also do a apt-get build-dep linux-ti-omap4?
<pbuckley> NOTICE: 'linux-ti-omap4' packaging is maintained in the 'Git' version control system at:
<pbuckley> neat
<pbuckley> since when did apt support git?
<pbuckley> or am i not reading that right?
<pbuckley> (because i basically wrote my own package format to get around deb's limitation of only one installed version of a package at a time)
<pbuckley> and i assume if git is in apt they have worked around that
<GrueMaster> No, it is just indicating that our kernel trees are in git as opposed to bzr.
<pbuckley> ah ok
<pbuckley> got all excited
<pbuckley> ;)
<pbuckley> also dont know if this is a packaging legacy defect
<pbuckley> but it points me to http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-maverick.git
<pbuckley> is that the active git repo or is it ubuntu-precise.git?
<GrueMaster>  ubuntu-precise.git
<pbuckley> k
<pbuckley> thank you again :) Hopefully those two patches on that bug report help with the sound issue im having.. going a bit mad without audio
<rbasak> So I've been trying usbboot. It works, but seems to find the boot script on the sd card and uses that. Is there any way to override the boot script?
<GrueMaster> yea, remove the sd.
<rbasak> Without removing the SD :)
<GrueMaster> picky picky.  :P
<rbasak> The reason is that I want to boot off the SD except when automation wants to netboot
<rbasak> Right now I have to assume that the machine isn't bricked and can be shelled into to change the SD to netboot
<GrueMaster> I understand.  I want to use it to recover from a botched netinstall.
<rbasak> Yeah, exactly :)
<rbasak> Right now the only way I can think of is to hack u-boot to never read a script
<rbasak> (and supply the hacked u-boot over usb)
<rbasak> I am hoping that there's a better way.
<GrueMaster> I don't know how the new usbboot works, but the omap4boot utility used abootimg to build an image.  This included a boot script or kernel cmdline.
<rbasak> This seems to use mkimage to convert u-boot.bin into a u-boot.img (with a load address of 0x80E80000)
<rbasak> I take it this is a different image format to abootimg?
<GrueMaster> Yes.  mkimage only creates a checksum wrapper.
<pbuckley> so if i wanted to submit patches to http://kernel.ubuntu.com/git-repos/ubuntu/ubuntu-precise.git
<pbuckley> is there a doc i can read that explains the process?
<GrueMaster> pbuckley: https://wiki.ubuntu.com/Kernel/Dev/KernelPatches
<GrueMaster> That's probably the easiest.
<pbuckley> brilliant thank you :)
<krosswindz> GrueMaster: I edited the kernel config and started a fresh build using the current sources. I will let you know how it goes
<krosswindz> GrueMaster: I will update the bug once I reinstall kernel
<GrueMaster> Ok.
<pbuckley> so compiling on the panda.. make -j2,-j3,-j4?
<GrueMaster> Depends on your storage medium.  If SD, I would not multi-thread.  Otherwise -j2 or -j3.  I think the rule of thumb (thumb2?) is # cores +1.
<pbuckley> k
<pbuckley> ty
<pbuckley> also make oldconfig generates warning: (USB_WUSB) selects UWB which has unmet direct dependencies (EXPERIMENTAL && PCI)
<GrueMaster> That is a question for #ubuntu-kernel.
<pbuckley> k
<mythos> sorry, if ask: but is thumb(2) something like mmx/sse/...?
<phh> not at all
<mythos> *if i ask
<phh> on ARM, instructions have fixed size
<phh> ie 32 bits
<phh> they found that sometimes you don't need full-featured instructions, and you could greatly reduce size with 16 bits instructions
<phh> that's thumb
<phh> then, they decided they could make the best of both worlds with thumb2, when using a 32bits instruction can be more efficient, they use a 32bit, else a 16bits one
<ogra_> shortly said: you get smaller binaries that load faster into ram
<ogra_> (and sometimes also run faster)
<phh> (because it's faster to load from ram to cpu)
<GrueMaster> infinity: New mx53 kernel still appears not to enable usb on the START-R rev of the Quickstart.
<mythos> hm... thanks for the explanation =)
<infinity> GrueMaster: Irksome.  I'll hunt down the landing team this week and see if we can get to the bottom of this.
<GrueMaster> k.
<GrueMaster> I'll see if I can generate some kernel output.
<infinity> That could be helpful.
<GrueMaster> infinity: http://paste.ubuntu.com/832005/
<infinity> GrueMaster: Hrm.  I don't see an obvious kernel failure there at all.
<GrueMaster> infinity: Starting at line 305:  usb 2-1: device descriptor read/64, error -71
<infinity> Does it boot from SD, then?
<infinity> Might make it easier to debug the USB issues if one can hotplug a non-root USB device.
<GrueMaster> I have a few more tests to run, but the only difference between my quickstart (qs1) and quickstart-r (qs2) setup is that qs1 is on port 2 of my kvm, and qs2 is on port 4.
<GrueMaster> It has always booted from sd.  The problem is that it doesn't see keyboard/mouse.
<infinity> Oh.  Key.  I use mine headless, would probably not even notice. ;)
<GrueMaster> Well, considering we only build desktop images for the board...
<infinity> Yeah, I don't test images on my mx53, it's my local mirror.
<infinity> It was also my first armhf system, before I had images.
<GrueMaster> (and I have a slight shortage of sata drives atm).
<infinity> Speaking of, we have armhf+mx5 images now.
<GrueMaster> cool.  I'll test tomorrow.
<methril> hi, someone up?
<methril> i would like to know if someone had a i.mx515 image working
<GrueMaster> infinity: Just to salt the wound a little, the dev image that came with it works ootb.  Kernel 2.6.35.3-1129-g691c08a
<GrueMaster> methril: mx51?  Like babbage3?
<rbasak> GrueMaster: I've adjusted u-boot-linaro-omap4-panda-splusb's default boot script to do pxe only. Is there any situation where this shouldn't be the case, ie. should I propose this as a permanent fix?
<methril> GrueMaster, yes, and Sharp PC-Z1
<methril> i would like to update it
<methril> it's a powerful processor
<GrueMaster> methril: Ah, yes.  That device.  persia used to bring his to UDS all the time.
<methril> GrueMaster, so nobody is working on it, isn't it?
<GrueMaster> Image wise we don't support that platform.  Package wise, it should handle everything current.
<methril> any guid to start porting it "image wise"?
<methril> s/guid/guide
<GrueMaster> Not really.  iirc, that had Jaunty, with was armv5.  I don't know if you can get a kernel for it or not.
<methril> GrueMaster, there is a 2.6.31 port, and a 2.6.35 WIP
<GrueMaster> If the 2.6.31 port works and is at least compiled for armv7, try it.  We can go from there.
<methril> ok, thank you GrueMaster
<methril> i will try to work on it, and come back when something is working
<GrueMaster> If you can boot with an armv7 kernel, the next step would be to see if you can chroot into an ubuntu-core image and do stuff.
<methril> ok, i need to buy a bigger sd card
<GrueMaster> The core images are fairly small.  ~35M compressed.
<GrueMaster> Note that these are NOT bootable images.
<methril> uhm...
<methril> i've a bootable sd card
<methril> i only need to boot it with a newer kernel image
<GrueMaster> Ok.
<GrueMaster> Older binaries "should" still work.
<methril> the older is what i'm going to try
<methril> to get a new version
<methril> i need it for traveling
<GrueMaster> Understand.  From what I've seen of it, it seems fairly capable.
<methril> i think so
<methril> let's see what we could get from this old device :)
<rbasak> GrueMaster: I filed bug 927956
<ubot2> Launchpad bug 927956 in u-boot-linaro "USB SPL boot should be able to override local SD card on panda" [Undecided,New] https://launchpad.net/bugs/927956
<rbasak> (with patch)
<GrueMaster> ok
<pbuckley> you werent joking about kernel compiles taking ahwile on the panda
<pbuckley> i might have to break down and spin up an ec2 instance and start doing my compiles there.. i assume there is a cross compile toolchain somewhere?
<GrueMaster> pbuckley: There is, but I couldn't tell you how to do a cross compile.  Try doing a google search on the ubuntu wiki.
#ubuntu-arm 2012-02-07
<rbasak> pbuckley: export $(dpkg-architecture -aarmel); export CROSS_COMPILE=arm-linux-gnueabi-; fakeroot debian/rules clean binary-omap4
<rbasak> pbuckley: you'll need gcc-arm-linux-gnueabihf installed
<rbasak> err, gcc-arm-linux-gnueabi
<rbasak> for armhf, s/armel/armhf/ and it's gnueabihf
<pbuckley> thank you
<pbuckley> im stil waiting for my first compile i kicked off about 4 hours ago
<pbuckley> so cross compiling is really the only way
<pbuckley> i can do this in any sort of real time frame
<pbuckley> i wonder if distcc is still around
<pbuckley> sweet it is.. anyone have success with it on arm?
<Neko> it works
<pbuckley> ty
<Neko> it's not very useful though, if you have 40 arm boxes to hook up with it you're probably also in posession of a rather powerful PC too :)
<pbuckley> well
<pbuckley> true.. but even in ec2 the kernel is taking forever.. ive gotten spoiled with near instant builds
<pbuckley> going to spin up a couple more instances
<pbuckley> and distcc this shiznit
<twb> Neko: some stuff can't be cross-compiled, though
<twb> Although the same stuff probably also has trouble with distcc...
<Neko> and that;s where you break out qemu to emulate arm enough to get the bits that can't be cross-compiled done
<twb> I guess.
<twb> Not all arches get so much love in qemu :-)
<Neko> suse manage it in their build service just fine, ubuntu are getting this stuff up and running. compiling natively on arm boxes is just looking for a long wait no matter how many you have.
<Neko> when you hit quad or eight core 1.8GHz monsters with 4GB RAM and real hard disks, yeah, it'll make sense again, but they don't exist yet. Not quite yet :)
<twb> AFAIK Debian still relies heavily on native builds
<Neko> and it'd still be faster on a PC. Nobody does a "native" Android build
 * pbuckley drools about the thought of an eightcore 4gb ram monster
<Neko> yeah we own the armhf build farm..
<twb> Well, android are crack-smoking java monkeys, what do you expect
<Neko> and it works.... but there's a better way
<pbuckley> whats the better way?
<Neko> cross-compile :]
<pbuckley> heh
<Neko> use your 8-core hyperthreaded xeon with 32gb ram and a 4TB raid array and build all of android in 25 minutes.
<twb> I expect it'll become trendier in Debian once multilib stuff is done
<twb> Neko: that still takes 25 minutes?  You can build openwrt on an *atom* in that time
<Neko> openwrt is a little smaller though
<Neko> building a 6MB ROM for a router is a bit different to something that comes out about 300MB worth of apps and java crap
<Neko> spitting a kernel out takes a couple minutes for a full distclean build.. you'd never do that on ARM even if you had 50 boxes doing it
<pbuckley> im at about 5 hours for building 3.2.0 on my pandaboard
<Neko> it takes 80 minutes on an Efika MX :)
<twb> Those extra 294MB are just bloat ;-)
<pbuckley> twb: thats the java ;)
<Neko> have 50 of them and it might take half an hour, maybe 10 minutes if you're lucky
<Neko> twb, I did say java crap :D
<pbuckley> efika mx you say
 * pbuckley googles
<twb> Now now, just because dalvik walks like a duck and quacks like a duck, doesn't mean Oracle can sue Google ;-)
<infinity> pbuckley: The Efika's much slower than your Panda, I wouldn't bother with the googling.
<GrueMaster> pbuckley: If it has taken 5 hours on your panda, you're doing something wrong.  https://launchpad.net/ubuntu/+source/linux-ti-omap4/3.2.0-1405.7/+build/3121438
<GrueMaster> And that system isn't even optimized.  I think it is running natty.
<pbuckley> GrueMaster: apt-get --only-source source linux-ti-omap4 (something); cd /usr/src/linux; make oldconfig; make
<pbuckley> is basically all i did
<GrueMaster> Are you running on SD or USB Sata?
<pbuckley> SD
<twb> GrueMaster: he is probably building with debug on
<GrueMaster> Ah.  That explains it.  You'll see almost 10x performance increase on USB.
<twb> That ALWAYS gets me
<Neko> I'm regretting buying a pandaboard, not because it's slow (usb disk makes it fun to use again) but because everything just seems not to be as good as you'd think
<Neko> awesome CPU, awful TI peripherals
<Neko> except the wireless, that works really well
<GrueMaster> Looking at the buildlog from the link I posted, the buildd is running Natty (Kernel version: 2.6.38-1209-omap4 #20-Ubuntu).
<GrueMaster> The panda is essentially a cellphone dev platform.  When thought of along those terms, it is actually quite good.
<Neko> it's a shame nobody's making a real omap4 desktoppy kind of system that's been optimized for usage and not just developing phones
<Neko> the other TI dev board is much better than the panda for that though too
<Neko> like.. if you had the choice you'd buy the MX53 EVK and not bother with the Quickstart
<Neko> if you were developing phones that is
<GrueMaster> Actually, there are a lot of non-phone systems out there (kindle fire, nook tablet).  And I heard of one system coming soon that will just plug into a spare hdmi port on your tv.
<twb> I thought omap4 was a better platform than the dragonball
<steev_> not a big enough market for it
<Neko> tablets are just big phones at the end of the day, same development model
<Neko> omap4 needs a trimslice, efika mx kind of thing
<GrueMaster> True.  Can't wait for omap5.  Could be interesting.
<Neko> well I'm duty bound to wait for MX6, but I can't help thinking most companies will run to nVidia before TI at the moment
<Neko> all the new tablets in the pipeline seem to be tegra3, if that is at all realistic
<Neko> I remember when they were all going to be MX51, hahahaha..
<Neko> what happens at CES, stays at CES
<GrueMaster> Yea, well....
<pbuckley> a tegra3 pandaboard like board would be fun
<twb> *I* remember in like 2008 when asus demoed an 9" eeepc running arm
<twb> And then I had to wait four years for the tf101
<pbuckley> so whats the trick to turn debug mode off?
<twb> pbuckley: make menuconfig, find it in the kernel hacking section
<twb> It basically means whether it builds with -g
<GrueMaster> twb: That is on by default in all of our kernels, from what I can tell.
<twb> GrueMaster: it is on standard ubuntu and debian kernels, yes
<twb> but it makes compile take an order of magnitude longer, ESPECIALLY if you have slow I/O
<pbuckley> ah k
<pbuckley> thanks
<twb> CONFIG_DEBUG_KERNEL=y I guess, I don't have menuconfig in front of me right now
<twb> But IME you can't just edit .config you need to use the UI
<pbuckley> E: Package 'ncurses' has no installation candidate
<pbuckley> oh wait
<pbuckley> that changed to
<GrueMaster> I think you can if you run make oldconfig afterwards.
<pbuckley> ncurses-base
<pbuckley> wow that package name changed again
<twb> libncurses5-dev or so
<pbuckley> though im a bit surprised it doesnt get installed with apt-get build-dep
<twb> ncurses-base is just terminfo files
<twb> build-dep of a kernel *source* package?
<pbuckley> well know.. but of the linux-kernel package
<pbuckley> s/know/no
<twb> linux-kernel is a metapackage, no build deps
<pbuckley> ah
<infinity> libncurses5-dev isn't a build-dep of the kernel because the kernel build doesn't call menuconfig.
<pbuckley> fair enough
<twb> infinity: right, thanks
<pbuckley> flag changed.. thank you for the tip
<pbuckley> :)
<pbuckley> and on that note its time to go home
<twb> If building natively, you can also do "make localmodconfig" and "make localyesconfig" to compile all used modules in, and disable all unused modules
<krosswindz> GrueMaster: the rebuilt kernel works
<krosswindz> GrueMaster: the device is detected
<GrueMaster> Excellent!
<nidsub> hi there :) i bump into a problem building linux kernel for arm xilinx,can anyone help me?
<nidsub> hi there guy, i needs some help please.sorry but i am new in this area
<nidsub> ur help would be greatly appreciated ,thank you
<nidsub> Im building a linux kernel
<nidsub> this the error i have,please show my mistake
<nidsub> nidsub-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ sudo make ARCH=arm
<nidsub> scripts/kconfig/conf --silentoldconfig Kconfig
<nidsub>   CHK     include/linux/version.h
<nidsub>   UPD     include/linux/version.h
<nidsub>   CHK     include/generated/utsrelease.h
<nidsub>   UPD     include/generated/utsrelease.h
<nidsub>   Generating include/generated/mach-types.h
<nidsub>   CC      kernel/bounds.s
<nidsub> cc1: error: unrecognized command line option â-mlittle-endianâ
<nidsub> cc1: error: unrecognized command line option â-mno-thumb-interworkâ
<nidsub> kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch
<nidsub> kernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch
<nidsub> make[1]: *** [kernel/bounds.s] Error 1
<nidsub> make: *** [prepare0] Error 2
<nidsub> here the detail on the step i took ..from this webpage
<nidsub> http://wiki.xilinx.com/zynq-linux
<micahg> nidsub: you need to learn about a pastebin
<micahg> !pastebin | nidsub
<ubot2> nidsub: For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<nidsub> ohh, im really sorry
<nidsub> :( sorry guys
<nidsub> http://paste.ubuntu.com/832267/
<Person987> XavB: thanks for your help the other day, my board has been running flawlessly since installing the arm-extras :-)
<XavB> XavB: yeah !!!
<XavB> Person987: so you are running the 3.1 kernel, right?
<Person987> how can I check? :-)
<XavB> uname -a returns Linux ubuntu-desktop 3.1.0-1282-omap4 #10 ...
<Person987> XavB: yes, thats it.  It was locking up every 30min and since upgrading it has not had a single problem.  I even left my OpenGL app running all day when I went to work and it was still running that night.
<XavB> Person987: just perfect... :D
<Person987> XavB: just ordered another board for my dad's birthday :-)
<XavB> ;)
<XavB> PePe
<krosswindz> GrueMaster: around?
<GrueMaster> Very much so, sadly.  Need to lose weight.
<GrueMaster> Oh, you meant something else?
<krosswindz> GrueMaster: I got a second usb serial cable
<krosswindz> GrueMaster: I have the same issue as well, not being able to hook on to the serial port
<krosswindz> GrueMaster: stty hangs
<GrueMaster> Very odd.
<GrueMaster> I have not seen that issue and I have 7-8 usb-serial cables (I lost track).
<GrueMaster> Do you have any other serial devices you can test that cable with?
<krosswindz> GrueMaster: baud_rate = baud_base / divisor?
<GrueMaster> Not that I know of.
<krosswindz> I just pulled an ancient desktop I have
<krosswindz> I am seeing if it will boot of a USB flash drive
<GrueMaster> You will need a crossover to connect to a regular desktop.
<GrueMaster> (or are you trying it as a host?)
<krosswindz> trying it as a host
<krosswindz> let it export serial console
<krosswindz> see if I can connect to it
<krosswindz> I am wondering if setserial for some reason isnt detecting pl2303
<krosswindz> I tried my second laptop booting lucid
<krosswindz> I have the same issue with it as well
<GrueMaster> I don't see why it would have issues.  Works fine here on all my systems from Lucid forward.
<GrueMaster> That is disturbing.
<krosswindz> Bus 005 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
<krosswindz> from lsusb
<GrueMaster> Most of the usb serial cables I have are from Trendnet.  I also have 1 4-port usb-serial cable.  All of them use the pl2303 chip.
<krosswindz> the keyspan which I borrowed works right out of the box
<krosswindz> I think I will order another cable
<Snark> plop
<Snark> janimo, I've been pointed to your package of the linux 3.0.19 kernel for arm, and wanted to give it a try ; it's unfortunately an armel package -- could you also provide an armhf variant?
<Snark> (I'm now subscribed to the mailing-list, so will follow there...)
<pbuckley> mailing list?
<Snark> pbuckley, https://launchpad.net/~ac100
<pbuckley> ah cool thanks
<Snark> pbuckley, no problem ; I wasn't on that team 15min ago ;-)
<pbuckley>  thihttp://www.engadget.com/2010/06/21/toshibas-ac100-8-hour-smartbook-runs-android-2-1-on-a-1ghz-tegr/
<pbuckley> this the device?
<Snark> pbuckley, yes
<Snark> the android was a joke, and killed the device commercially
<pbuckley> i would love to find a tegra3 board
<pbuckley> (besides the tf201)
<dioxin> GrueMaster: in hiding?
<GrueMaster> dioxin: Nope, just back from lunch.
<dioxin> GrueMaster: would you be able to guide me in the ways of local repositories? I've got ubuntu 10.04 on the spare box, just doing first round of updates now
<GrueMaster> dioxin: Here is my ubumirror.conf:  http://paste.ubuntu.com/833211/
<GrueMaster> With that, you just add a crontab job for the specific ubumirror app you want to run (ubuports for ports.ubuntu.com).
<dioxin> can I just sudo apt-get install ubuports ?
<GrueMaster> dioxin: sudo apt-get install ubumirror.  ubuports is one script in the package.  The package isn't very big.
<GrueMaster> My cron job is:
<GrueMaster> cat /etc/cron.d/ubumirror
<GrueMaster> # Update archive mirror every two hours.
<GrueMaster> 0 */2 * * * root /usr/bin/ubuports >> /var/log/ubumirror/cron.log
<dioxin> postfix local only?
<dioxin> (from install of ubumirror)
<GrueMaster> The /var/log/ubumirror/cron.log file only traps output from the cron job.  ubuports (and all of the other ubu scripts) create their own logs in the same directory.
<GrueMaster> postfix local (unless you want it to run a larger mail server).
<GrueMaster> ubumirror scripts use that to send failure notices.
<dioxin> where does the ubumirror.conf go? /usr/bin/ubuports ?
<GrueMaster> I recommend using my ubumirror.conf and change the destination paths appropriate to your environment.  Mine is set to ignore everything except armel/armhf on ports.ubuntu.com.  It also pulls the daily arm images from cdimage.ubuntu.com (using ubucdimage script), but I don't recommend it as it can be slow.  Better to use zsync and pull as needed.
<GrueMaster> ubumirror.conf goes in /etc
<GrueMaster> See dpkg-query -L ubumirror for all the file locations.
<dioxin> done it in the /etc/ directory
<dioxin> ... only need to wait 1 minute...
<dioxin> changed the 2 to a 1
<GrueMaster> My conf file does not mirror the source files, but it does get everything needed for netboot install.  First run will take several hours (like overnight).
<dioxin> how can I tell its running? ps -U root ?
<GrueMaster> I found that every 2 hours is enough.
<GrueMaster> ps ax|fgrep rsync
<GrueMaster> Or tail -f /var/log/ubumirror/ubuports.log
<pbuckley> GrueMaster: my kernel compile finally finished ;)
<pbuckley> only took 7 hours
<GrueMaster> pbuckley: Cool.  how long did it take?
<pbuckley> went alot faster after i shutdown firefox
<pbuckley> about to boot it.. hopefully those patches help
<pbuckley> next time ill be sure to turn off that kernel hacking debug stuff
<dioxin> GrueMaster: I'm getting errors that /server/mirrors/linux-distro blahblah no such file or directory
<GrueMaster> Yea, those paths are on my mirror.  You need to edit /etc/ubumirror.conf and change all /server/mirror paths to something sane on your server.
<GrueMaster> My server has 4 partitions:  /server/data /server/mirror /server/media /server/roots.  I doubt your system will be the same.
<GrueMaster> Once you have the mirror, it will look like <your local path to>/ports.ubuntu.com/ubuntu-ports/*
<dioxin> I've just added /server/mirror/linux-distros/Ubuntu/ports.ubuntu-com/ubuntu-ports :D
<GrueMaster> Well, copy exact is one way to go.  :P
<dioxin> I've just built the box specially for this task, it dont really matter :D
<GrueMaster> On my system, in my www directory (created by the web server), I have a symlink to /server/mirror/linux-distros/Ubuntu/ports.ubuntu-com/ubuntu-ports.  That way, the mirror resolves to http://<mirror server>/ubuntu-ports, which makes changing the sources.list easier.
<dioxin> I guess I have to sort out the symlink for the apache later.....
<dioxin> ok I think I just added the symlink :D
<dioxin> GrueMaster: do you guys have a x86 >> armv7 cross compiler up and running yet?
<suihkulokki> dioxin: on x86 host just apt-get install g++-arm-linux-gnueabi
<GrueMaster> What he said.  :P
<dioxin> kk I might have to try that once I get my hexa server back up and running :D
<dioxin> it really needs the other CPU tho :(
<dioxin> soon my precious! SOOOOON
<GrueMaster> heh
<dioxin> is distributed compilation supported out of the box for x86 to arm?
<dioxin> (me nub, be gentle)
<GrueMaster> I have no idea.  Usually, cross compiling is only recommended for small projects or projects that don't do any post-compile processing (like running unit tests, etc).
<GrueMaster> And those projects normally fail on a distcc type environment anyways.
<dioxin> boo :(
<dioxin> I've got soooo much x86 horse power available :(
<prpplague> dioxin: unless you are doing a really really really big compile, simply have a dual core box and passing a -j4 to make will be plenty
<prpplague> dioxin: i can do a complete android build in under 20 minutes on a dual core 2ghz box
<dioxin> I've a 2.4 Ghz Hex core with hyperthreading ... so I might be able to do that in 3 minutes :)
<dioxin> I was expecting a full build to take much longer
<dioxin> GrueMaster: how do I tell the repo is completely downloaded.... the sync stopped running....
<dioxin> sudo /usr/bin/ubuports & stopped almost immediately...
<GrueMaster> On your arm system, edit /etc/sources.list to point to it instead of ports.ubuntu.com and run apt-get update for starters.
<GrueMaster> Also, check the ubumirror logs (/var/log/ubumirror/ubuports.log.*
<GrueMaster> )
<dioxin> kk its running again, I'll check properly in the morning
<dioxin> night peeps
<pbuckley> night
#ubuntu-arm 2012-02-08
<pbuckley> for compiling on panda, mount /tmp as tmpfs definitely seems like a win
<pbuckley> (vs having it write out to an sd card as in my setup)
<GrueMaster> yes, that also helps.  :P
<GrueMaster> Although a USB drive is still better overall.
<pbuckley> yeh.. ill bring one in tomorrow
<pbuckley> was hoping to be able to survive off just the sd
<pbuckley> but thats not really being realistic at this point
<pbuckley> might try the iscsi thing tonight
<GrueMaster> Personally, I think the SD is good for running shiny demos.  Not really fast enough for serious development work.
<GrueMaster> NFS-Root also works w/o the iSCSI overhead.
<pbuckley> aye.. i think my experience agrees with your statement
<pbuckley> k.. ill try that first
<pbuckley> thank you :)
<Person987> Does anyone know if it could be harmful to plug a monitor into an already running pandaboard?
<twb> I have no idea, but I would hope not!
<Person987> I'm embedding one in a robot and I'd like to be able to just hook up a monitor if I need to without turning it off.  Normally it won't have a monitor on it.
<dioxin> GrueMaster: you there? I'm getting an error with my local repo, apt-get appears to be looking in the wrong place :(
<dioxin> deb http://192.168.1.205/ubuntu-ports/ oneiric main restricted universe multiverse is whats in my sources.list
<GrueMaster> dioxin: Here now.  You can start checking your server configuration by using a browser from another system to see if that address shows up.  If you don't see anything at  http://192.168.1.205/ubuntu-ports/ something is wrong with your server config.
<Snark> could people check if they are hit by https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/926855 too ?
<ubot2> Launchpad bug 926855 in gcc-4.6 "[ARMhf] gcc produces assembler it can't compile" [Undecided,New]
<GrueMaster> Snark: It compiles fine here with "-marm", which I believe is default on all of our projects.  janimo, is that correct?
<Snark> GrueMaster, yes, that is in a comment
<Snark> the problem is that it doesn't compile without, while it did before
<GrueMaster> Yes, I know.  I read the bug.  I think -marm is a required setting (which is why I asked janimo for confirmation).
<Snark> GrueMaster, uh... if it were required, why isn't it on by default?
<GrueMaster> Snark: I don't know the specifics, just repeating from memory.  Mainly I run the tests, thats why I pinged another member of our team for more detail.
<Snark> the same source code was building on oneiric, and stops building on precise, that is why I think it's a bug on the compiler side...
<GrueMaster> Snark: It could easily be an armhf specific issue too.  Can you try in precise armel?  (if not, I can in a little bit).
<Snark> GrueMaster, I don't have a precise armel install
<GrueMaster> Ok.  I can reimage a spare panda here.
 * Snark doesn't have spares
<Snark> I make experiments with the same device I use for my work...
<dioxin> GrueMaster: the website shows up, but it only has ls-lR.gz and pool/
<GrueMaster> Then something happened and it isn't getting dists/
<GrueMaster> Check your ubumirror.conf
<dioxin> which one?
<dioxin> GrueMaster: my ubumirror.conf file in /etc/ubumirror.conf is a carbon copy of yours
<GrueMaster> Check your latest /var/log/ubumirror/ubuports.log* to see if it indicates any issues.  The app is supposed to pull updates from ./pool and then everything but ./pool.
<GrueMaster> You should see this:
<GrueMaster> tobin@mirror:/server/data/www$ ls ubuntu-ports
<GrueMaster> dists  indices  ls-lR.gz  pool  project
<GrueMaster> Which version of ubumirror are you running?  dpkg-query -l ubumirror
<dioxin> [receiver] io timeout after 601 seconds -- exiting
<dioxin> 0.3ubuntu3
<dioxin> for version of ubumirror
<GrueMaster> let me check mine and make sure I didn't modify it locally.
<GrueMaster> The only script I have changed was ubucdimage (has nothing to do with your issue).
<GrueMaster> And 0.3ubuntu3 has been the latest since 10.04.
<dioxin> running the following command as root atm /usr/bin/ubuports >> /var/log/ubumirror/cron.log
<dioxin> and I've got the ubuport.log tail-f 'ed
<dioxin> currently at pool/universe/t
<GrueMaster> After it finishes with pool/*, it should show: Ubuntu ports pool sync completed.
<GrueMaster> Followed by:  Initiating Ubuntu ports dists and indices sync...
<GrueMaster> Snark: I updated the bug report with my test results.
<GrueMaster> Can you ping someone in #linaro and see what they think?  They do a lot of the arm optimization to gcc.
<Snark> GrueMaster, I see
<Snark> GrueMaster, I was pointed to Michael Hope, which wasn't available, so I sent him a mail
<GrueMaster> ok.
<GrueMaster> Sorry about the run around.  I'm just trying to get you hooked up with someone that would know more about this that I do.
<Snark> I'm used to getting run around with a cannon... you're a soft one!
<janimo> GrueMaster, -mthumb is our default, -marm only for a few cases where package got miscompiled
<GrueMaster> Ah, there you are.  What would you suggest in this case where it builds on oneiric but not precise w/o -marm?  (I haven't tested with -mthumb)
<janimo> Snark, IIRC I saw similar errors where huge assembly code was generated by -funroll-loops, so that in thumb mode it could not be directly jumped too. I only vaguely remember though
<janimo> GrueMaster, it probably is a gcc issue
<janimo> good that Linaro GCC is a bugtask on this
<GrueMaster> Yea, failed with -mthumb,
<janimo> Snark, as a work-around if you need the package on precise ASAP build with either -marm or try without funroll-loops
<janimo> otherwise we may need to wait for a gcc fix
<janimo> Snark, or try forcing a build with gcc-4.5 which was the default in oneiric to see it is indeed a regression
<janimo> but in either case these are workarounds and a proper fix in gcc is needed I'd say
<Snark> yes
<dioxin> GrueMaster: the repo appears to be working now, no idea what was wrong with it :(
<GrueMaster> I'm not sure why, but I had to run ubuports 3 times before I had a working mirror.  Glad to hear you are up and running.  I still recommend a 2 hour update period.
<GrueMaster> Especially during times were we rebuild the entire pool (which I think is currently happening).
<diff_kb> holla
<jom> Hi everybody! owner of a Pandaboard Rev.A4 I get stuck with a ubuntu11.10. Monitor, mouse & kbd are connected and detected but it seems that a problem while resising and mounting the filesystem append I can logging in in manual but what I am suppose to do to fix it? Does the activation of the console help finding a way through this issue? thanks!
<GrueMaster> jom: Which image are you using?
<kurtank> Hello
<jom> this one : ubuntu-11.10-preinstalled-desktop-armel+omap4.img
<GrueMaster> jom: Did you check the md5sum of the image?  What is the error you are seeing?
<kurtank> Im a bit new to linux, and need a little help. Im using Ubuntu 10.10 running via a 4GB image in chroot next to android on a samsung Galaxy SII.
<kurtank> I was wondering if there was any place i could get ARM-specific applications. Most of the app center doesnt work.
<GrueMaster> kurtank: You should be able to apt-get install any application in the ubuntu pool.  I would recommend upgrading to at least 11.10, although you will see a marked performance increase if you were to start with 12.04 armhf.
<GrueMaster> You can download a pre-built core chroot environment from http://cdimage.ubuntu.com/ubuntu-core.
<kurtank> About upgrading: many users report that 11.10 runs slowly and breaks the image.
<kurtank> I think its also worth mentioning that the only way to interact with ubuntu with this method is through VNC.
<GrueMaster> Well, I am not very familiar with your usage model unfortunately.
<kurtank> Im not surprised.
<GrueMaster> Ah, similar to the "nookbuntu" image.
<kurtank> Its more of a hack than anythint.
<jom> The MD5 was correct. The error is "Errors were found while checking the disk drive for/." I zeroed the card with 'dd' ans unfortunatly it doesn't work better at this point
<GrueMaster> What is the card brand/size/class?  You may have a bad card.
<jom> Yes you right I think it could have been that but I previously run an Angstrom distro on it and everything was Ok. The card is a microSD SANDISK/4GB/4
<GrueMaster> Angstrom doesn't do much except basic diag.  It doesn't resize the image, and isn't as complete.
<kurtank> http://forum.xda-developers.com/showthread.php?t=1223128 This is the method and the image i used. Oddly, xchat irc downloaded ans installes fine.
<kurtank> *and installed
<kurtank> Someone also said it would be possible to get sound output, and USB host functions apparantly work. Autodetect will never work though and requires manual detection. Ive been using linux for about only a week and i have no idea how to do that.
<jom> I agree with you GrueMaster about angstrom distro. I don't want to start here a Troll but Angstrom it really nice when you need just a console coz it has a very low memory sized and very efficient. A tool for every needs ;o)
<jom> Could you explain why the image is then resized I don't get the point on that
<GrueMaster> Oh, don't get me wrong, it is an excellent diagnostic image.
<GrueMaster> The image is pregenerated on our servers.  We needed a way to get the image on a variety of SD cards w/o knowing the size of the card in advance.  This setup will boot the kernel and initrd, and a script in the initrd will repartition the rootfs and resize it to fill your SD (4G-32G tested).
<GrueMaster> Easier than having one image for each size SD on the market.
<dioxin_> GrueMaster, do you know of any images for a beaglebone?
<GrueMaster> dioxin_: I don't have a beaglebone, but I have been told that the omap images should work.
<GrueMaster> I think that system is designed for headless, so I would recommend either the preinstalled-server or netboot (exercise your mirror a little).
<dioxin_> I havent managed to get any display out of the serial port tho :(
<GrueMaster> Not even with their stock angstrom image?
<dioxin_> yes with the stock, but not with the ubuntu 11.10 server omap3
<GrueMaster> dioxin_: Try one of the images at http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled for omap (not omap4).
<GrueMaster> Odd that you don't see anything, not even u-boot.
<dioxin_> http://elinux.org/BeagleBoardUbuntu#Demo_Image trying this atm, but I'll let you know about the link you gave
<GrueMaster> Unfortunately, I don't have one (and no budget for one atm).
<dioxin_> I'll keep you posted :D
<GrueMaster> Note that I won't be able to help at all on images we don't produce on cdimage.ubuntu.com.
<jom> But when I enter the Manual recovery I can see that the '/' directory is mounted on the SD card and a 'mount' cmd shows all the necessary diretories any idea?
<dioxin_> i know :)
<GrueMaster> Looking over that link briefly, it looks like beaglebone support was added in linux 3.2 (which our precise images will have).  Can't say about u-boot though.
<jom> when we are on the manual recovery mode what can we do to make the system finish is resizing properly?
<GrueMaster> jom, I would try reflashing and start over.
<GrueMaster> The whole process shouldn't take more than 10 minutes on a 4G card.
<jom> Hum I did it already 2 times and I always step down on the same issue. I will try to find another 4GB card.
<GrueMaster> What method are you using to flash the image to SD.  Keep in mind the image is gzipped to begin with.
<GrueMaster> I have a script that essentially runs "gunzip < precise-preinstalled-desktop-armhf+omap4.img.gz |sudo dd of=/dev/sdf bs=4M".  The 4M helps with the speed of writing to a flash device (and reduces the issues you seem to be seeing).
<jom> I 1st unzip it and I transfert it to the SD device not mounted using 'dd'
<jom> it's exactly what I do
<GrueMaster> ok.
<GrueMaster> I have been testing these images on a variety of SD cards from 4G to 16G, class 4, 6, and 10.  That's why I ask.
<jom> I try to do it once again else I will have to buy another card tomorrow. Do you use uSD HC card? And does it work the same?
<GrueMaster> I have a few uSD cards, yes.  I use them mainly for beagleXM and Freescale Quickstart testing, but the image is identical (except for kernels).
<dioxin> GrueMaster: I finally managed to boot into ubuntu on the beagleBone, but I used the elinux link
<dioxin> I think the problem lies in the tty output
<GrueMaster> What does dmesg show for UARTS?
<dioxin> I dont think it supports UARTS, I'm using a mini-usb cable for the console access
<GrueMaster> The serial console "should" be /dev/ttyO2 on almost all omap hw.
<GrueMaster> Oh, interesting.
<GrueMaster> What is /proc/cmdline say for console?
<dioxin> ttyO0 I think
<GrueMaster> Ah, then you should be able to modify the boot.scr on the normal ubuntu image to point to that instead of ttyO2.
<GrueMaster> You will need to strip the first 72 bytes from boot.scr, then edit the bootargs and rerun mkimage to regenerate boot.scr.  You can't just edit the file.
<dioxin> GrueMaster: do you have a guide for that process?
<GrueMaster> Not exactly.  Here are the steps (assuming the boot partition is mounted on /mnt):
<GrueMaster> dd bs=72 skip=1 if=/mnt/boot.scr of=boot.script
<TheMuso> dioxin: dd should be able to strip it for you.
<GrueMaster> edit boot.script
<GrueMaster> sudo mkimage -A arm -O linux -T script -C none -d boot.script /mnt/boot.scr
<GrueMaster> (I leave the "edit boot.script" part for you to figure out).
<jom> about Ubuntu 11.10 it felt on the same issue!
<dioxin> ok, my first attempts at editing the boot.script failed... so I'm going to cheat :D
<dioxin> hmm... the elinux imaging process doesnt have a boot.script
<jom> :o)) get it works! my SANDISK SD card is on a very bad shape the TDK one make it works! So that was just a hardware problem [SOLVED]
<GrueMaster> Excellent!
<jom> Bye & thanks to you GrueMaster for your help!
<TheMuso> ogra_: In your request for the tegra ALC patches for alsa-lib, you mentioned related patches. What do you mean by this exactly? There is the patch you linked to, but I don't see any others in that thread...
#ubuntu-arm 2012-02-09
<duga3> list ubuntu-arm
<AlexLee> hello , does ubuntu11.10 for panda has no h264enc codec? i run the gst to encode h264 failed, who knows ?
<duga3> can anybody help me with ARM NEON?
<duga3> Good morning, can anybody help me with vector permutation using ARM NEON?
<ogra_> TheMuso, hey, i meant the other paz00/alc patches ... i dotn know if all of them made it into the recent version we have
<janimo> GrueMaster, I am looking at the two main FTBFS you brought up. thanks
 * ogra_ curses, seems my install is seriously scrwed :(
 * ogra_ curses mono
<janimo> ogra_, what does mono do in your install?
<ogra_> fail the assembly install from the postinst
<janimo> but what requires it, it's not in default install right?
<ogra_> note that my system got upgraded from natty over oneiric to precise, i have a lot of shit installed that shouldnt be there
 * ogra_ is just trying to get rid of mono
<ogra_> also i hacked the alternatives for nvidiy-tegra, that fails too
 * ogra_ tries to purge everything with -cil in the name,  lets see if makes it any better
<ogra_> silly mono crap .... and nobody to fix it :(
<xranby> ogra_: the latest mono at least installed on my machine but its asserting all the time
<ogra_> right, for me it seems to already breal when the assembly update happens
<ogra_> luckily we dropped it from the images
<ogra_> still thats a basd situation
<ogra_> *bad
<ogra_> grmbl
<ogra_> update-alternatives: error: alternative nvidia_drv can't be slave of arm-linux-gnueabi_egl_conf: it is a slave of gl_conf
<ogra_> i really wonder how i broke that
<xranby> ogra_: i fixed it on my machine by removing the slave of gl_conf
<ogra_> in the nvidia-tegra package ?
<xranby> i think the bug are simply that the old nvidia-tegra package added the slave for gl_conf
<xranby> so the bug is in the state saved in update-alternatives
<ogra_> well, thats bad, the new package should have a fix for it
<xranby> i think i ran   update-alternatives --remove gl_conf
<xranby> before configuring the new package
<xranby> it will remove gl_conf and all associated slaves
<xranby> ogra_: try ask someone who better understand this alternative system
<xranby> how the transition from non-multiarch to multiarch are supposed to work
<ogra_> well, i know enough about alterbnatives, i'm just to lazy to weed through all the postinst scripts :P
<xranby> the QA team will have a fun time hitting all these upgrade QA issues
<xranby> when testing oneiric -> precise upgrades
<ogra_> i dont think they test ac100 upgrades
<janimo> ogra_, the alternatives issue I saw as well, but was not sure if it is not caused by my broken manual alternatives renaming earlier
<janimo> maybe preinst should have something to remove the early names indeed
<janimo> but I do not understand alternatives well either
<ogra_> yeah, something like that ... i fiddled with the alternatives as well, though
<ogra_> i think the prob is that egl is already a slave of gl ... the driver wants to create a slave for a slave
 * ogra_ purges mesas egl stuff for a test
<ogra_> hmm, intreasting, that removes gimp
<xranby> who would have guessed :)
<xranby> im surprised that gimp needs egl
<ogra_> well, it also installs a ton of QT packages that seem to have been held back
<ogra_> i wonder if we missed a transition here
<NCommander> cooloney: ok, I'm spinning a source package now with the change to changelog (guess I need to retag too :-/)
<NCommander> I'll dump my branch onto zinc once its done
<NCommander> cooloney: also need to delete all non-revelant changelog entries
<cooloney> NCommander: yeah, please send me patch
<cooloney> let me update the git tree
<NCommander> cooloney: great
<NCommander> give me a sec to continue smacking
<NCommander> argh
<NCommander> Freaking changelog manager
 * NCommander headthunks
<ogra_> we have a manager for that ?
<ogra_> how much does he earn per month ?
<ogra_> :P
 * NCommander hits ogra_ with a brick
<ogra_> hey, one day i'll build a house... i already have a good collection of your bricks
 * NCommander his ogra_ with a rock
<NCommander> *hits
 * ogra_ reboots after that dist upgrade finally finished (that took half my workday, sigh)
 * ogra_ throws a mono stack at NCommander 
 * NCommander cuts it in half with his libO foo
<NCommander> cooloney: http://paste.ubuntu.com/835214/ - plz apply
 * NCommander dumps linux-armadaxp into a PPA to testbuild properly
<dumby88> wm8650
<cooloney> NCommander: meta will be ready soon. thx janimo
<NCommander> uploading to a ppa now to testbuild (not sure all the necessary changes to get the _all packages to build prpoerly made it in)
<NCommander> going to go get some food, will return
<janimo> cooloney, you're welcome
<cooloney> janimo: for testing build meta, what's kind of build target should i use?
<cooloney> fdr clean; fdr binary?
<janimo> hmm, I think I just used debuild -us -uc when testing
<janimo> as it builds very fast - nothing to actually build but the metadatat under debian/
<janimo> what you say is equivalent I guess
<cooloney> janimo: yeah, i got it
<cooloney> NCommander: i saw you patch, did you miss to change 3.0.0 to 3.0.17?
<NCommander> cooloney: infinity gave a good reason not to include it
<cooloney> NCommander: i miss that reason, why?
<cooloney> NCommander: let me change back the meta package from 3.0.17 to 3.0.0
<NCommander> cooloney: because its a leftoer when we used 2.6.x, including the sub-minor just means the version number cahnges a LOT and is a pain
<cooloney> NCommander: looks like we have to stick to the tradition
<cooloney> yeah
<cooloney> NCommander: how about i fold your patch to my previous commit
<cooloney> NCommander: and i will push out this change again
<NCommander> cooloney: that's fine. you'll probably get a few more patches as I'm not sure this will build onteh buildds (doing a PPA test build to check)
<cooloney> NCommander: great
<cooloney> NCommander: meta package is here, git://kernel.ubuntu.com/roc/linux-meta-armadaxp.git
<NCommander> great
<cooloney> NCommander: please help to review and upload.
<cooloney> or the gitweb http://kernel.ubuntu.com/git?p=roc/linux-meta-armadaxp.git/.git;a=summary
<cooloney> NCommander: kernel git tree is also updated with your patch
 * cooloney gonna go to sleep
<cooloney> good night, folks
<NCommander> cooloney: sleep well
<janimo> ogra_, are the armhf omap sgx drivers coming?
<ogra_> janimo, at some point, yeah ... with dropping of el
<janimo> NCommander, cooloney wonder why is linux-armadaxp building for i386 too
<ogra_> TI will only support one
<NCommander> janimo: arch-all voodoo, whichis why I wanted to do a test build to see if it actually will build properly.
<ogra_> for the brave that want to run armada kernels on pentiums :)
<janimo> ogra_, are they waiting for something or next release will automatically be armhf?
<ogra_> janimo, next will ... they dont have time and manpower, so we have to wait
<janimo> ok
 * ogra_ finally finds the time to test janimo's new kernel ...
<janimo> do we wait with switching images over to armhf only until they arrive?
<ogra_> though thats probably brave right before a meeting :)
<janimo> ogra_, heh, as long as you don't suspend it should not be an issue :)
<ogra_> janimo, nope, we switch when we switch ... up to them to react then
<janimo> ah, they may not want to put any effort in it until it is 100% 12.04 is armhf primarily
<ogra_> might be, we wont wait for them though
 * ogra_ installs 
<janimo> sure. what about nvidia/ac100? Not sure if they even promised armhf this cycle
<ogra_> no idea
<ogra_> likely not
<janimo> I'd still switch to armhf by default on ac100
<ogra_> same thing for omap3 ... ask rsalveti about that one
<janimo> ok, in today's meeting probably
<ogra_> yeah, me too i guess, though that means a cross grade or some such for me ... i dont want to lose all my data
<xranby> nvidia have produced armhf drivers for meego in the past
 * ogra_ reboots into new kernel
<xranby> do we have any nvidia person to ask directly?
 * janimo wonders what kind of unbackupable/unrestorable heaps of data may ogra's ac100 hold that he cannot just wipe and reinstall armhf
<xranby> i doubt they will support it officially but they may create an armhf build for distribution with a specific distribution
<janimo> xranby, well a binary dump as their current driver is would suffuce
<xranby> janimo: i think it basically boils down to find someone who have access to nvdeveloper.nvidia.com and ask for a rebuild
<xranby> the build will then be uploaded to NV online for use by a specific distribution
<xranby> this request can possibly be made by someone with influence in the oem team
<janimo> xranby, yes, I know some of them work with nvidia occasionally
<xranby> try pull one of those strings, i think thats the only way to get a driver into armhf at this point
<janimo> xranby, last I heard we needed a new armel rebuild for the new x11 abi. But I am not sure if that arrived or not
<ogra_> janimo, that happened two uploads before you touched the package ;)
<xranby> janimo: for armel nvidia was kind to at least include a v11 abi version next to the v10 abi version
<xranby> in the same upstream tarball
<xranby> so i think we have that allready :)
<ogra_> yep
 * ogra_ is currently using it 
<janimo> well I saw xabi6 through 11 in the upstream binaries but was not sure the last one was ok or needed a newer rebuild
<ogra_> and given ui checked the changelog today i can say that it was switched at -0ubuntuX still
<ogra_> it has issues with the 11 abi though
<ogra_> i have a lot of composite messups on my screen
<janimo> ogra_, yes, I think that is what I remembered, it may not be 'the final abi11 rebuild'
<ogra_> hopefully
<ogra_> well, its still usable and i like that it saves so much ram
<ogra_> so i'll keep it running, hoping the best from nvidia
<pbuckley> no usb-creator for arm?
<GrueMaster> apparently not.  Odd, considering it is just a python script (I think).
<GrueMaster> Probably because it depends on i386/amd64 only packages (syslinux).
<infinity> GrueMaster: Definitely because of that, in fact.
<pbuckley> GrueMaster: btw i tried applying those two patches that were posted on that analog sound -panda board bug and no love
<GrueMaster> Ok, good to know.  make sure you update the bug report.  Thanks.
<pbuckley> ah you mean i need to create a launchpad account
<pbuckley> ;)
<pbuckley> (totally joking, ill update the bug)
<GrueMaster> heh
<pbuckley> comment posted
<pbuckley> and a little more info added
<GrueMaster> btw:  Do you have a Panda or a Panda ES?
<GrueMaster> pbuckley: ^^^
<pbuckley> es
<pbuckley> have two of em on my desk right now
<pbuckley> one is my desktop, the other is my development target
<GrueMaster> I think the alsaucm rules need to be changed for that system.
<pbuckley> any idea what too? my alsa foo is non-existant other then knowing where the config files exist
<GrueMaster> I'm booting up to look.
<pbuckley> cool thank you
<GrueMaster> I think there may be a couple of places this needs fixing.  First, /lib/udev/rules.d/90-alsa-ucm.rules, then /usr/share/alsa/ucm.
<GrueMaster> The 90-alsa-ucm.rules is a simple fix.  Just run "sudo sed -i 's/Panda/Panda|PandaES/g' /lib/udev/90-alsa-ucm.rules".
<GrueMaster> The /usr/share/alsa/ucm part is a little more involved.  Need to copy the Panda directory to PandaES, then edit all the files inside to reflect PandaES instead of Panda.
<pbuckley> vi sweet
<pbuckley> my ears thank you.. trying it now
<GrueMaster> I'll file a new bug on alsa-utils & libasound2, then go about getting them fixed.  Even if the kernel is still borked, they will need these fixes.
<infinity> GrueMaster: Yay, I get to duplicate that code again? :)
<GrueMaster> ???
<infinity> GrueMaster: The alsa ucm bits.
<infinity> I suppose we can just ship symlinks.
<infinity> Oh, no.  We can't,
<infinity> Cause the board ID is in the files.
<infinity> *grumble*
<GrueMaster> Oh.  Nah, simple fix.  Already on it.
<infinity> Now I remember why I copied it all.
<GrueMaster> I got this one.  You can fix ksysguardd.  :P
<infinity> Heh.
<infinity> Or, I can attend more meetings!
<infinity> \o/
<pbuckley> meetings, huzzah!
<GrueMaster> Meetings == snooze time.
<pbuckley> $ alsaucm -c PandaES set _verb HiFi
<pbuckley> Im setting defaults
<pbuckley> ALSA lib main.c:276:(execute_sequence) unable to execute cset 'name='HS Left Playback' 1'
<pbuckley> ALSA lib main.c:1460:(set_verb_user) error: failed to initialize new use case: HiFi
<pbuckley> alsaucm: error failed to set _verb=HiFi: No such file or directory
<pbuckley> i probably foobar'd something
<pbuckley> hrmm
<pbuckley> for file in *; do sudo sed -i 's/Panda/PandaES/g' $file; done
<pbuckley> basically just did that
<pbuckley> in the /usr/share/alsa/ucm/PandaES directory
<pbuckley> (ill just wait for you to commit a fix)
<GrueMaster> wip.  Any chance you can post your new shiney kernel (just the uImage) for me to test here?
<GrueMaster> Otherwise I'll have to rebuild it.
<TheMuso> ogra_: afaik those other patches are for the kernel I think.
<pbuckley> yeh, where do you want it?
<pbuckley> i have the deb's too if you want
<GrueMaster> Someplace accessible.
<pbuckley> hrm that might tricky.. can you do dcc?
<GrueMaster> I might.  Not sure if quassel-core can handle it.  Give it a whirl, worst case it blows up my rack of servers.  :P
<pbuckley> heh
<pbuckley> get it?
<GrueMaster> TheMuso: I'm getting ready to patch alsa-libs & alsa-utils for PandaES.  Should I just push them into bzr branches or do you want me to push to alsa-project as well?
<pbuckley> 12:52 DCC SEND request sent to gruemaster:  linux-image-3.2.0-1405-omap4_3.2.0-1405.7+soundfix_armhf.deb
<GrueMaster> pbuckley: I see the request.  Not sure how to handle it.  One sec.
<pbuckley>  /dcc accept?
<GrueMaster> hrm.
<ogra_> TheMuso, oh, ok, i just noticed that there were more patches in the list archive, if its all kernel it should be fine
<pbuckley> unfortunately the deb is 20MB which is a little to big for my email system.. lets see if i can sneak it on a web server
<TheMuso> GrueMaster: Push them into a bzr branch for now. I was actually going to ask you guys about the ucm files for the ARM stuff, we currently carry that. DO you want it all to go upstream?
<GrueMaster> pbuckley: No dice.  Quassel doesn't support it yet.  Give me a minute.
<pbuckley> k
<TheMuso> BTW how is armhf looking for precise, as in supportability etc?
<GrueMaster> TheMuso: I think they should, yes.  I haven't updated my alsa git trees in ages, but it isn't a big deal.
<GrueMaster> armhf is rock solid (with a few cracks).
<pbuckley> ive been having pretty good luck with armhf
<TheMuso> Ok, I know they are not upstream yet.
<TheMuso> I presume such cracks are no big deal, i.e they are not major.
<GrueMaster> pbuckley: Ok, send it to my other nick (GrueMaster-web).
<pbuckley> sent
<pbuckley> 12:59  gruemaster-web SEND: 0B of 19MB (0%) - 0.00kB/s - ETA (stalled) -
<pbuckley> how big can attachments be on gmail?
<pbuckley> lets see
<GrueMaster> Not sure, but it should be smaller than the dirty jokes my mother sends.  Email away.
<pbuckley> lol
<pbuckley> email?
<pbuckley> (address that is)
<GrueMaster> gruemaster@gmail.com (what else would I be :P)
<pbuckley> leet
<pbuckley> sending
<pbuckley> my internet here isn't the fastest.. give it like 10min
<GrueMaster> np.
<GrueMaster> Not like I have nothing else to do.  :P
<GrueMaster> rsalveti: Linaro is already working on the alsa-ucm???  Good to know.
<pbuckley> k
<pbuckley> it should be sent
<pbuckley> let me know if you need the headers deb too
<pbuckley> GrueMaster: receive the email ok?
<GrueMaster> yes, installing now.  thx
<pbuckley> no no, thank you :)
<GrueMaster> WOOT!  Sweet stereo analog on Panda ES is back.
<GrueMaster> Dosen't help that they change the control names for every release.
<pbuckley> sweet, so that kernel worked?
<gandhijee_> hello. could someone point me to a hardfp build of ubuntu?
<gandhijee_> nm
<gandhijee_> i am silly.
<GrueMaster> Between your kernel and me mucking with the ucm config files, yes.
<pbuckley> nice! thats great news.. that just means im doing something stupid
<GrueMaster> I'm going to pasebin the /usr/share/alsa/ucm/PandaES/hifi file for you.  Hang on.
<pbuckley> thank you
<GrueMaster> http://paste.ubuntu.com/8358000
<GrueMaster> Oops.  remove one 0
<pbuckley> got it.. brb going to reboot with that kernel
<GrueMaster> Make the ucm change first.  That way you only need one reboot.
<pbuckley> I HAVE SOUND!
<pbuckley> :D
<pbuckley> thanks GrueMaster
<GrueMaster> Excellent.
<rsalveti> GrueMaster: the multimedia working group is trying to get it properly fixed
<rsalveti> for all the boards
<GrueMaster> Great.
<rsalveti> it's a working in progress atm, but tgall_foo is also trying to get it working at our images
<rsalveti> so then we can simply push a new change to precise
<rsalveti> and get it all working not one day before the release :-)
<Dr_Who> yes .. "work in progress" is important to keep in mind
<TheMuso> Feature freeze is also important to keep in mind...
<TheMuso> I'd prefer having any ucm configs in precise by FF.
<GrueMaster> The "Work in progress" part bothers me a bit.  This is a simple fix.  I have it working here out of tree (took 10 minutes).  I can easily push it to alsa-lib and alsa-utils and have it working in the next image (assuming the kernel update also lands soon).
<pbuckley> (ive duplicated the success for what its worth)
<TheMuso> GrueMaster: alsa-utils is currently being tested at least for x86 in ~ubuntu-audio-dev/ppa, so what would you prefer be done? Wait till they come out of testing and are uploaded to precise proper, or get them uploaded now, and merged back when the update to 1.0.25 of alsa-utils is done?
<GrueMaster> TheMuso: The alsa-utils fix is just a fix for 90-alsa-ucm.rules (and I need to check to see if it even needs fixing).
<GrueMaster> The other part is alsa-lib which has the ucm config changes.
<GrueMaster> I haven't checked, but I don't think they are upstream.
<Dr_Who> GrueMaster:  it is being developed upstream but you're right I don't believe it's captured in a current alsa release , wei_feng would know for sure
 * Dr_Who points to #linaro-multimedia tho i don't see feng at the mo
<GrueMaster> Dr_Who: I'm updating my alsa-project git trees now and not seeing anything.
<GrueMaster> (not counting the drivers).
<Dr_Who> I'd recommend talking to Feng, he's the expert
<GrueMaster> pbuckley: Looks like the fix is even easier than I thought.  No need to change /lib/udev/rules.d/90-alsa-ucm.rules.  Just a minor tweek to the ucm configs (sudo sed -i 's/HS/Headset' /usr/alsa/ucm/Panda/*) and it works.
<GrueMaster> Plus your kernel patches.
<pbuckley> nice.. hopefully that makes it easier to get into the mainline (right terminology? im new to this whole open source dev thing)
<GrueMaster> Yea.
<GrueMaster> TheMuso: looking at the ppa, alsa-libs isn't there.  No update for it?
<TheMuso> GrueMaster: I accdidentally jumped the gun and its in precise already, may be reverting though as there may be issues with flash of all things... But not sure if the new libc may have had something to do with it or not. Still testing that out here.
<GrueMaster> Heh.  I just blame flash.
<TheMuso> I'd like to but...
<GrueMaster> yea, I know...
<pbuckley> can we all just move to html5 already
<GrueMaster> heh.
<GrueMaster> I thought the goal was to move to Silverlight?  :P
<infinity> TheMuso: The flash/libc thing should be fixed in today's upload.
<pbuckley> that was even a joke inside of microsoft (at least the group i was in). (disclaimer, i didn't intentionally get a job there. They acquired a company I was working for)
<infinity> TheMuso: It was related to https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/929713
<ubot2> Launchpad bug 929713 in eglibc "audio unreliable with eglibc 2.15" [Critical,Fix released]
<infinity> pbuckley: It would be a better joke if it wasn't widely deployed by Netflix. :/
<pbuckley> yeh i need to bug some of my buddies who went over there to find out the real reason they are using it
<pbuckley> my guess is microsoft gave them a pile of cash
<pbuckley> as per their sop
<infinity> I can't get Hulu in Canada so don't know much about it.  Is it in the same boat, or did they go with saner tech?
<pbuckley> hulu is flash
<infinity> Well, I'm not sure that's "saner", but... It's not Silverlight?
<pbuckley> true.. and they do have a reasonable explanation why they haven't switched to html5. That is if you agree with the whole concept of intellectual property.
<infinity> I don't really understand how Flash and Silverlight became video delivery media anyway.
<TheMuso> infinity: Ah ok thanks.
<pbuckley> they were better then the <embed> tags available at the time
<pbuckley> and they have support for drm
<GrueMaster> I agree with the concept of IP.  I don't agree with the draconian DRM and absurdly high prices.
<infinity> We solved the streaming video thing more than a decade ago... And then, due to "if you have a hammer, everything looks like nails" web developers, we started using VECTOR-BASED ANIMATION ENGINES to stream video?
<infinity> Brilliant.
<infinity> pbuckley: As someone who doesn't live in the US, DRM and I are usually not on good terms.
<GrueMaster> infinity: Hey, at least flash isn't doing pixel based rendering on Linux anymore.
<pbuckley> have you tried the x-forward-for thing?
<pbuckley> that gets around alot of the drm right now
<infinity> There's absolutely nothing more frustrating than the dozens of links from FB/G+/Twitter/etc to news stories, TV clips, and such that "aren't available in my area".
<pbuckley> (at least for geoip based drm)
<infinity> pbuckley: Yeah, I could just proxy.  It's not worth the effort.
<pbuckley> the x-forward-for thing is just to prepend something like x-forward-for: <ip in the usa, like a ec2 instance>
<pbuckley> to the html header
<infinity> As in, pretend that I'm proxying for a US client?
<pbuckley> yeh
<infinity> Are there ffox plugins to spoof that with minimal fuss?
<pbuckley> i think so
<pbuckley> i had to do it a couple months ago when i was in mexico
<pbuckley> let me see if i can find it in my bookmarks
<infinity> I might look into that.  An extra 40 bytes on every HTTP request doesn't sound too bad to get around some stupidity.
<pbuckley> https://addons.mozilla.org/en-US/firefox/addon/x-forwarded-for-spoofer/
<infinity> And I'll have to re-pack the xpi.
<infinity> Not available for FF10, my ass.
<infinity> pbuckley: But thanks. :)
<pbuckley> lol
<pbuckley> np
<infinity> pbuckley: I'll fiddle with the manifest later and give it a whirl.
<infinity> If this lets me watch Comedy Central clips, I'll be a happy camper.
<infinity> Every time someone links to a Daily Show clip, I get progressively more annoyed.
 * pbuckley links to a daily show clip
 * pbuckley hides
<infinity> Especially given the irony that, I suspect, Jon Stewart would be more than happy with everyone in the world watching it.
<GrueMaster> infinity: This may be your lucky day.  I can't reproduce the ksysguardd crash on today's build.
<TheMuso> 0!0@
<TheMuso> whoops
#ubuntu-arm 2012-02-10
<infinity> GrueMaster: Shiny.
<pbuckley> @0!0@ <-- ferengi
<GrueMaster> heh
<micadeyeye_> Hi, rabbitmq-server won't run on my ubuntu-arm (precision server edition)
<pbuckley> tried activemq?
<micadeyeye_> Here is the error i always get - http://www.fpaste.org/wRVS/ - on installing it.
<pbuckley> /var/log/rabbitmq/startup <- whats in here?
<micadeyeye_> http://www.fpaste.org/WOdt/
<pbuckley> thats useful :\
<pbuckley> hrmm
<pbuckley> is there an init/upstart-job? looked at the init script to see how its calling it and tried calling it directly?
<pbuckley> sorry im not a rabbidmq expert
<pbuckley> s/rabbid/rabbit
<GrueMaster> micadeyeye: I'll take a quick look at it.  It is on the list of needs testing for 12.04 release.
<micadeyeye> root@localhost:/# /etc/init.d/rabbitmq-server start
<micadeyeye> Starting rabbitmq-server: FAILED - check /var/log/rabbitmq/startup_{log, _err}
<micadeyeye> rabbitmq-server.
<micadeyeye> GrueMaster, okay.
 * micadeyeye I can't run Openstack on Ubuntu-arm, at least for now. too bad!!
<micadeyeye> That might be the reason I am getting this error - http://www.fpaste.org/E2LC/
<micadeyeye> I can't run any of the nova commands.
<GrueMaster> micadeyeye: It may have been a libc issue.  There was an update that broke a lot of things.  It has now been fixed and should be uploaded to the pool today.
<GrueMaster> Is this armhf or armel that you tried?
<micadeyeye> armhf
<GrueMaster> Ok.  I'm launching a couple of pandas to reimage to precise tip.  Will take ~20 minutes, then I can check.
<micadeyeye> okay.
<GrueMaster> It appears to be running ok on another test system even after updates to current.  I'll still need to wait for the other systems though.  This system has been thrashed and will need reimaging soon.
<micadeyeye> That would be rabbitmq. right?
<GrueMaster> rabitmq-server
<micadeyeye> okay.
<micadeyeye> I will try and use 11.04. I am not too sure if the headless ver. would be better the netbook ver.
<GrueMaster> Use 11.10.
<micadeyeye> okay.
<micadeyeye> headless/netbook or armhf/armel?
<GrueMaster> I know it was tested.  We did a "pipe cleaning" session last cycle.
<micadeyeye> Okay.
<GrueMaster> ubuntu-11.10-preinstalled-server-armel
<micadeyeye> Do you know of anyone running Openstack on Ubuntu-arm?
<GrueMaster> No, but it is also on the todo list.  rbasak may have done some work on it.
<micadeyeye> rbasak, hi!
<rbasak> hello!
<rbasak> what do you mean by openstack on ubuntu-arm, exactly?
<GrueMaster> brb.  Need to pick up a car from the shop.  Should be back in 20-30 minutes max.
<micadeyeye> okay
<micadeyeye> I wanted to install the Openstack cloud project on my Pandaboard, which has the Ubuntu-arm OS on it.
<infinity> Doesn't openstack rely on some functional virtualisation?  Or do we have it all working with lxc now?
<rbasak> All on one pandaboard?
<micadeyeye> I only need the nova compute.
<micadeyeye> I would like to use the PB as a node.
<rbasak> lxc is working on armhf in precise
<micadeyeye> But if I could install all, that would be great.
<rbasak> and openstack does work with lxc. But I'm not aware of anyone having tried it thus far.
<micadeyeye> lxc??
<rbasak> Daviey might know, and if we have any concrete plans for lxc on precise. But like me he's in UTC+0 so tomorrow might be better
<micadeyeye> WHat's lxc?
<pbuckley> linux containers
<rbasak> The software implementation end of virtualisation on ARM isn't finished yet. AFAIK there is progress on both Xen and KVM
<rbasak> LXC is pretend virtualisation - everything runs under the same kernel, but processes are shielded from each other so they see themselves as owning the machine
<infinity> rbasak: Sure, but even if Xen and KVM were done, paravirt is only supported on the A15.
<micadeyeye> okay.
<rbasak> Yeah so KVM is never going to work on a pandaboard
<infinity> Nope.
<infinity> Well, it could be done in full emu mode, but that would be a Very Bad Thing.
<infinity> If you want PV, you need an A15.
<infinity> Of which we have so many...
<GrueMaster> back
<GrueMaster> And I have rabbitmq-server installed on a freshly imaged panda running precise armhf.  Looking for some tests now.
<cooloney> GrueMaster: hey, man. -:)
<GrueMaster> Hey.
<cooloney> GrueMaster: did you have chance to test kernel for AXP I handed to NCommander
<GrueMaster> You mean the ftbfs one???
<cooloney> GrueMaster: oh, no.
<cooloney> GrueMaster: it's just a kernel i prepared for uploading
<cooloney> it should be named as linux-armadaxp 3.0.0-1500.1
<cooloney> not sure whether NCommander uploaded or not
<GrueMaster> All I know was he was building it in the canonical-arm-dev ppa (and failing).
<cooloney> GrueMaster: ok, let me take a look, thx
<cooloney> GrueMaster: looks like it is still building, started 2 hours ago
<cooloney> maybe NCommander fixed something and upload again
<GrueMaster> Yes, this is the third attempt.
<cooloney> GrueMaster: cool.
<cooloney> GrueMaster: thx. i will check with NCommander, maybe need to apply some fixing patch to the kernel git tree
<GrueMaster> I think he already has.
<GrueMaster> micadeyeye: I found a rabbitmq benchmark tool.  running it now.  https://github.com/chirino/stomp-benchmark
<twb> What SoCs / SKUs whip with mali GPUs?
<twb> (ref. LWN post re lima mali FOSS GPU drivers)
<GrueMaster> I would assume the ones listed here?  http://limadriver.org/Hardware/
<GrueMaster> Interesting.  "A Single Board Computer with a 4210, called origen, is available with android and ubuntu support."  Must be a Linaro enabled board, cause I know I don't have images for it.
<infinity> GrueMaster: Yeah, there are Origens all over here.  But we've never been asked to enable it in the distro.
<twb> Obviously it's just so easy to get Debian on there they never bother with Ubuntu :-P
<allquixotic_> Hi, I have a ThinkPad Tablet (slate), a Tegra 2 based tablet that runs Android 3.1 by default... I have it perma-rooted and can thus do anything to the device (in principle), so does anyone know if I could theoretically install Ubuntu on it similar to the way the Toshiba AC100 is done?
<twb> tegra2 support is still alpha quality
<TheMuso> And whats more, the kernel source for the device would need to be available, so there is source for the device speicifc hardware, like the touchscreen.
<allquixotic_> TheMuso: Good point. I'm not sure that Lenovo has released their kernel source yet. So they are technically not in compliance with the GPL, as I never received any written offer for the source either.
<twb> allquixotic_: they don't have to do that, but they are obliged to respond if you ask
<allquixotic_> twb: Interesting. I don't think anyone has posted the source yet, be it Lenovo or someone else, so I might send them a letter to get the ball rolling, or see if they will brush me off and tempt me to contact the SFLC
<TheMuso> The board itself is likely based on something tegra ish, like ventana, or harmony.
<allquixotic_> oh... it's Ventana actually, I figured that out from some of the low level stuff I was messing with as I was rooting it :-)
<twb> SFLC has no power except where the copyright holders delegate to them
<twb> ventana's a dev board for the tegra2 AFAIK, so it's probably a tegra2 in production
<TheMuso> twb: Yes thats right, but as I said above, there is additional stuff like touchscreen. The transformer as you know has more than that, there is keyboard dock code, battery for the dock, etc.
<cooloney> NCommander: ping
<carli2> hi
<carli2> I have a OMAP3 board and installed the omap3 drivers. after restarting X, the screen was black
<pnphi> joined
<pnphi> excuse me
<pnphi> i want to have GUI for ARM ubuntu or Qemu , what i do ??
<prpplague> pnphi: install ubuntu on a pandaboard?
<pnphi> qemu ! ! !
<pnphi> ARM ubuntu on qemu
<pnphi> and on a beagleboard
<pnphi> excuse me
<prpplague> pnphi: sorry you said "or" first, which is different than "on"
<pnphi> sorry ..on not or
<lctoai> how install desktop ubuntu after install ubuntu for arm in qemu
<pnphi> excuse me
<pnphi> i want to have GUI for ARM ubuntu on Qemu , what i do ??
<GrueMaster> pnphi: You might ask in #linaro.  They do more direct work with qemu and may have a solution.
<GrueMaster> ppisati: Ping - When will we see a fix for bug 925069?  There appear to be a couple of patches attached to the bug, and one user has already added them to the 1405 kernel and tested that they work.
<ubot2> Launchpad bug 925069 in linux-ti-omap4 "No analog audio on omap4 panda" [Undecided,Confirmed] https://launchpad.net/bugs/925069
<ppisati> GrueMaster: i think i already pulled those patches, let me check
<ppisati> GrueMaster: yep, the patches are there, i'll cut a new kernel
<GrueMaster> Excellent, thanks.
<TonyWatertown> Hi.  I need help installing ubuntu-arm on a BeagleBoard XM, Rev. C.  I followed the steps in the wiki page, but I'm having problems installing the image on the board.
<GrueMaster> TonyWatertown: First, which image are you using?  Second, what issues are you seeing?
<TonyWatertown> GrueMaster: I am using the image specced in the wiki page for Rev C. (i.e. beagleXM-natty.tgz.  when extracted produces vmlinuz-2.6.38-8-omap)>
<TonyWatertown> GrueMaster: The problem is that the installation hangs at 15% at keyboard configuration and then starts over from the beginning (i.e. stuck in loop).
<GrueMaster> Ah, I think I know the problem.  Try switching to a console (ctrl-alt-F1) and logging in using the user & password you entered in oem-config.
<GrueMaster> Then run "sudo oem-config-remove && sudo reboot".
<GrueMaster> There is an odd timing issue with oem-config that the slowness of the SD interface has brought out.  It has been fixed recently in 12.04 (faster SD performance, race in dbus).
<GrueMaster> Although you may want to try 12.04 alpha 2 (released last week).  The armhf improvements really are noticeable.
<TonyWatertown> GrueMaster:  Thanks.  Yeah, I think I'd like to try out 12.04 alpha 2.  Newb q: Where can I get it?  Are the installation steps the same as for 11.10?
<GrueMaster> You can find it at http://cdimage.ubuntu.com/releases/12.04/alpha-2/ .  Same basic instructions (except you don't need to replace the kernel).
<GrueMaster> Same as 11.10, yes.
<TonyWatertown> GrueMaster: Excellent.  Thanks!
<TonyWatertown> GrueMaster: in your opinion, any reason not to go with the hard-float image for 12.04?
<GrueMaster> None.  I have been testing both armel and armhf releases, both are equally stable, and the armhf seems faster.  I haven't done any benchmarking per say, but I know my netboot installs are 5 minutes faster with the same preseed.
<suihkulokki> sounds odd as installer shouldn't really use much floats
<GrueMaster> I have yet to find an armhf bug that also isn't in armel.  And 12.04 alpha 2 seems almost as stable as any prior full release (there are still minor glitches, but no show stoppers).
<GrueMaster> The installer itself will when working with compressed packages.
<GrueMaster> Plus the binaries are a bit smaller.
<TonyWatertown> GrueMaster: That sounds great.  I'm really excited about using the FPU.  Question: does the USB hub work fine in 12.04?  That was the big issue I had with previous releases.
<suihkulokki> GrueMaster: unless you use lossy compression, usage of floats with compressed packages is unlikely ;)
<GrueMaster> TonyWatertown: I have a rev B and with the 20120207.1 daily-preinstalled it seems to work even better (for me).
<GrueMaster> suihkulokki: I don't know how the packages are compressed.  I do know that two pandas using the same USB drives and the same network, one images ~5 minutes faster than the other.  Internal mirror.
<GrueMaster> I have a pool of 4, and constantly reimage them to a base ubuntu-server w/ openssh-server and openjdk-6-jre-headless.  Maverick takes ~35 minutes, Natty & Oneiric take ~25 minutes, Precise armel takes ~20 minutes and armhf takes ~15 minutes.
<GrueMaster> Preseeds are identical for all images.  All packages are on a local mirror in my basement.  House is wired 1Gb.
<suihkulokki> such processes are usually IO bound, so perhaps it's the smaller binaries
<GrueMaster> Possible.  Like I said, I don't know the full details of why, I just know that they are faster.
<TonyWatertown> Waiting for the 12.04 armhf image download to complete.  Another question: where can i grab the source and the kernel config file for this image?  I need to compile a 3rd party kernel module once I get 12.04 installed.
<rbasak> TonyWatertown: there's git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git (and a ti-omap4 branch), also you can apt-get source linux-image-`uname -r`
<TonyWatertown> rbasak: Thanks!  Is the kernel config file for the image located at /boot?  Or do I have to grab it from somewhere else?
<TonyWatertown> Hi.  Doing an apt-get source linux-image-`uname -r` results in the following error: E: You must put some 'source' URIs in your sources.list
<pbuckley> cat /etc/apt/sources.list
<TonyWatertown> What should I add to my /etc/sources/list file?  Thank you.
<TonyWatertown> pbuckley: deb file:/var/lib/preinstalled-pool/ ./
<TonyWatertown> #
<TonyWatertown> # /etc/apt/sources.list
<TonyWatertown> deb http://ports.ubuntu.com/ubuntu-ports/ precise main restricted universe multiverse
<TonyWatertown> deb http://ports.ubuntu.com/ubuntu-ports/ precise-security main restricted universe multiverse
<TonyWatertown> deb http://ports.ubuntu.com/ubuntu-ports/ precise-updates main restricted universe multiverse
<pbuckley> depends on what your install target is
<pbuckley> eek
<TonyWatertown> pbuckley: just installed the alpha 2 release for 12.04, the armfb version.
<pbuckley> http://pastebin.com/GMXu8RQc
<pbuckley> this is my sources.list
<pbuckley> also dont forget to do a sudo apt-get update
<pbuckley> before
<pbuckley> (but after you have a sources.list file)
<TonyWatertown> pbuckley: thanks!  giving it a shot now after an update.
<pbuckley> coolio
<pbuckley> :)
<TonyWatertown> pbuckley: dumb q.  do you know where the source is installed?  I expected to find it at /usr/src. but that directory is empty.
<pbuckley> apt-get --only-source source linux-ti-omap4 or something like that
<TonyWatertown> pbuckley: nevermind.  i'm being dumb.  it was installed in the directory from which i ran the apr-get src command
<GrueMaster> TonyWatertown: When you install source, it is usually installed in the current directory.  So "apt-get source linux-image-`uname -r`" should install the source in ./linux-image-`uname -r` , along with a tarball of the original and a dsc file for building.
<GrueMaster> Ah, you found it.
<TonyWatertown> Hi.  I'm trying to compile a kernel module for 12.04 alpha 2.  I see that there is no asm directory in the include directory for the source.  How can I generate the right asm link?
<TheMuso> TonyWatertown: Which linux-headers packages do you have installed?
<TheMuso> It sounds like you are missing one.
<TonyWatertown> I installed the entire source.  So i'm pointing the kernel module makefile to the source directory.
<GrueMaster> TonyWatertown: Try "sudo apt-get install linux-headers-omap4" to make sure you have all of the headers.
<GrueMaster> Then you can build a module using the out-of-tree module build steps.
<TonyWatertown> GrueMaster: I'm on a beableboard xm.  Is omap4 still correct?
<GrueMaster> Oh.  Wrong platform.  Use linux-headers.
<GrueMaster> That is a meta that should pull in all the relevant header files for your system.
<TonyWatertown> GrueMaster: apt-get install linux-headers-`$(uname -r)`?
<GrueMaster> No, just linux-headers.  There are multiple packages, one is generic, another is specific to uname -r.
<TonyWatertown> GrueMaster: E: Package 'linux-headers' has no installation candidate
<GrueMaster> wait one.
<GrueMaster> linux-headers-omap is the meta (my bad).
<GrueMaster> That will pull in linux-headers-3.2.0.15-omap and  linux-headers-3.2.0.15.
<GrueMaster> (or a newer one if it has updated in the last couple of days).
<TonyWatertown> GrueMaster: downloading now.
<GrueMaster> great.
<TonyWatertown> GrueMaster: Should I point the kernel module makefile to the linux-headers-3.2.0-15 or linux-headers-3.2.0-15-omap directory?  Both directories are present at /usr/src.  Incidentally, uname -r returns 3.2.0-12-omap
<GrueMaster> Use uname -r.  That directory should have symlinks to the other directory for generic headers.
<TonyWatertown> GrueMaster:  Hmm.  Pointing to the headers resulted in the following badness: /usr/src/linux-headers-3.2.0-15/include/linux/kconfig.h:4:32: fatal error: generated/autoconf.h: No such file or directory
<GrueMaster> TonyWatertown: Look at https://wiki.ubuntu.com/KernelCustomBuild.  It may have better information on this than I can provide.
<GrueMaster> TheMuso: I've posted a merge request for alsa-lib to update our ucm configs.  Simple tweak, has absolutely no effect on other platforms.
#ubuntu-arm 2012-02-11
<pbuckley> btw, those on pandaboards and having trouble with quiet or muted audio, open alsamixer and goto DL1 Media and adjust the volume. You're welcome.
<GrueMaster> pbuckley: I've uploaded the ucm fixes and our kernel guy was supposed to spin up a new kernel with the patches.  Should have a working system ootb next week.
<GrueMaster> At least for audio out.  Haven't tested audio in yet.
<pbuckley> nice, thats great news. Audio is a lot like oxygen, don't realize how much you use it till it's gone
<pbuckley> also took your advice and attached a hard drive to my pandadesktop board
<pbuckley> huge difference (duh)
<GrueMaster> heh.
<AlexLee> hello all , i encode h264 by using gstreamer in ubuntu 11.10 , but
<AlexLee> can't  encode h264, is that miss some h264enc codec ?
<AlexLee> also i have updated all the  PPA , the kernel is 3.1
<AlexLee> http://groups.google.com/group/pandaboard/browse_thread/thread/d8d98dee7c50f791#
<krosswindz> GrueMaster: I got a third pl2303 cable and it worked
<krosswindz> GrueMaster: third time is the charm
<GrueMaster> Excellent!
<krosswindz> GrueMaster: interesting it reports the same details when I run set serial, I am unable to set baud_base
<krosswindz> GrueMaster: but it works
<GrueMaster> Very odd.
<krosswindz> yes really odd
<krosswindz> not sure what the issue is with those cables
<krosswindz> I guess that company just makes unusable cables
<GrueMaster> Personally, I have had so many problems with them, mainly not being able to enumerate in a sane manner.  I have an old Atom system that I use as a serial console, and I ended up buying an 8-port pci serial card.  Of course, now I have 13 system consoles to monitor...
<krosswindz> nice
<GrueMaster> Not really.  My desk looks like a snake pit.
<krosswindz> too many cables
<krosswindz> wish there were wireless usb serial devices right :p
<GrueMaster> And I just ran out of network ports on my 16 port switch.
<krosswindz> you need a 96 port switch :p
<krosswindz> just left scathing review for those broke cables
<GrueMaster> heh.  I'd probably fill it next cycle (I bout this one last cycle when I only needed 9 ports).
<krosswindz> I need to get a switch to I guess
<krosswindz> I have been using three routers, two of them bridging
<GrueMaster> I've never had a failing cable from Trendnet.  Just no way to differentiate between the 4 that I have.  And the 4 port usb-serial cable is just a cable with an integrated hub & 4 pl2303 chips.
<krosswindz> Thats good
<krosswindz> the last time comcast tech support came to my home he was counting the number computers I had
<GrueMaster> All of my switches are 1Gb "dumb" switches (no programming of vlans, etc).
<krosswindz> he is like you can only have 5 computers connected
<GrueMaster> Yet another reason I don't do comcast.
<krosswindz> i said dont worry 5 of them dont talk to the internet so its fine... he was like ooh ok
<krosswindz> well my apartment gets either comcast or 128 kbps dial up
<krosswindz> or whatever
<krosswindz> its either comcast or dialup
<krosswindz> no dsl
<GrueMaster> I have 15 in my office alone, plus 2 in the study (wife & kids), a PS3, a Wii, an XBox, and two chumbies.
<GrueMaster> I'm on DSL.
<krosswindz> in my town they decided that cable was utility so every apartment complex can just have one hence monopoly
<GrueMaster> Dedicated IP (only changed once since 1999).  No hassles.  They even alert me if they are seeing oddities on my link.
<krosswindz> thats nice
<krosswindz> who is your provider?
<GrueMaster> Yea, they have done that all over the place.
<GrueMaster> My phone line is Qwest/Century Link.  My ISP is dsl-only.net.
<krosswindz> qwest is sitll alive ;)
<krosswindz> still*
<GrueMaster> I only have 3 choices for internet (I don't count dialup/satelite).  Comcast, Centurylink (they bought up Qwest apparently), and one local ISP that uses 802.11b.
<GrueMaster> When I moved here in 2003, I already had dsl & dish network.  I called comcast and asked them to remove their cable from my house.  They said that it was illegal for me to not be connected.
<krosswindz> lol
<GrueMaster> I ended up cutting the cable and leaving it in a pile next to the pole across the street, then called up and reported a down cable.  They removed it very quickly.
<krosswindz> nice job
<krosswindz> comcast only sucks blood
<krosswindz> they charge me $70 for a pathetic 8/2 connection
<GrueMaster> On my street, 7 out of 8 houses have switched to dish or ditect tv in the last 6 months.
<krosswindz> On a good day I get like 3-4 Mbps down
<krosswindz> I wish I had a choice
<GrueMaster> Better than I get, but I'm in the sticks.
<GrueMaster> My line is rated at 7.5/1.5, but even after rewiring my house with cat5e, I still can't seem to get better than 5.5/768.
<GrueMaster> I think it is the pipe between our town and Portland.
<krosswindz> hmm
<krosswindz> well at least you get 5.5 on an average
<krosswindz> most days if get like 2-2.5
<krosswindz> I dont care much for upload
<GrueMaster> And I sometimes need it.  I mirror ports.ubuntu.com every 2 hours, and cdimage.ubuntu.com every 6 hours (only for arm stuff).
<krosswindz> aah
<GrueMaster> I bought a cheap rack cabinet ($150) for the basement.  It has 2 1U rack systems (mirror & firewall), plus a few older boxes and a test platform running remotely.
<krosswindz> nice
<GrueMaster> Between running my own computer consulting business for 6 years in the 90's and working in validation labs at Intel, I kind of got used to having a lot of equipment.
<GrueMaster> Wife thinks I'm nuts.  I call it "Terminal Insanity".
<krosswindz> having lot of computers is never wife approved :p
<GrueMaster> Who said anything about asking permission?
<GrueMaster> :P
<krosswindz> its friday night
<krosswindz> time to head out to the water hole :p
<GrueMaster> It is????   Time flies when you don't know what you are doing.
<krosswindz> have fun ;)
<GrueMaster> You too.
<krosswindz> I am trying to build mainline kernel
<krosswindz> I was wondeirng if I have to pass anything specific to build armhf kernel
<krosswindz> i am running precise
<krosswindz> never mind i figured what needs to be done :p
<micadeyeye> GrueMaster, none of the 11.10 releases (server and desktop) worked for me.
<micadeyeye> My PB hangs here:
<micadeyeye> http://www.fpaste.org/HfXJ/
<TonyWatertown> Hi.  I need some help cross-compiling ubuntu-arm (the 12.04 omap3 hard-float variant).  make CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm hiccuped at the Bulding modules stage.
<TonyWatertown> Clarification: I want to cross-compile the ubuntu-arm source.
<marvin24_DT> TonyWatertown: what's the error?
<TonyWatertown> marvin24_DT:   MODPOST 2285 modules
<TonyWatertown> ERROR: "__sync_fetch_and_and_4" [drivers/staging/line6/line6usb.ko] undefined!
<TonyWatertown> ERROR: "__sync_fetch_and_or_4" [drivers/staging/line6/line6usb.ko] undefined!
<TonyWatertown> WARNING: modpost: Found 4 section mismatch(es).
<TonyWatertown> To see full details build your kernel with:
<TonyWatertown> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
<TonyWatertown> make[1]: *** [__modpost] Error 1
<TonyWatertown> make: *** [modules] Error 2
<marvin24_DT> well, the mismatches should be non critical
<marvin24_DT> the undefined symbol ...
<marvin24_DT> you can try mrproper or disable the module
<marvin24_DT> it is from staging anyway
<TonyWatertown> marvin24_DT: how can i disable the module?  sorry for the newb q.
<marvin24_DT> TonyWatertown: run  "make menuconfig" and find the driver in drivers staging
<TonyWatertown> marvin24_DT:  Ok.  I'll go give it a shot.  Thanks for your help!
<duga3> I know this is probably not the right channel, but does anybody know a channel with people experienced with ARM NEON developing?
<TonyWatertown> marvin24_DT: Thanks for the help.  I was able to get the kernel cross-compiled.
#ubuntu-arm 2012-02-12
<codemagician> Will Ubuntu 12.04 LTS run on the new Raspberry Pi computer with ARM11 CPU?
<desrt> codemagician: that seems unlikely
<desrt> codemagician: http://www.raspberrypi.org/faqs is pretty clear on this topic
<desrt> "Because of issues with newer releases of Ubuntu and the ARM processor we are using, Ubuntu canât commit to support Raspberry Pi at the moment."
<codemagician> thanks for the info
<apokryphus> hello
<apokryphus> could i get some help from here in enabling dvi on a pandaboard es?
<krosswindz> apokryphus: dvi is enabled by default on the pandaboard
<apokryphus> hi
<apokryphus> but not for me
<krosswindz> how are you connected
<apokryphus> i have a pandaboard es
<apokryphus> hdmi
<apokryphus> hdmi to dvi rather
<krosswindz> i mean when you connected using dvi
<krosswindz> what are you running?
<apokryphus> hdmi to dvi-d to dvi
<apokryphus> 11.10
<apokryphus> i want to connect a lvds panel in omapfb.mode=dvi1024x600MR-18@60
<apokryphus> omapfb.mode=dvi:1024x600MR-18@60
<apokryphus> and omapdss.def_disp:dvi
<apokryphus> do you mean connected to the i-net?
<apokryphus> sorry don't understand what you mean
<krosswindz> thats fine
<apokryphus> k
<apokryphus> any ideas?
<krosswindz> not sure
<apokryphus> the validation image runs fine
<apokryphus> i got a signal onm dvi ouit
<krosswindz> dvi should be fine then
<apokryphus> yep
<apokryphus> but no boot will boot into driving dvi
<apokryphus> i have to switch back to the real hdmi port - than i get a signal
<krosswindz> thats weird
<apokryphus> but only on hdmi
<apokryphus> i tried debian - ther it works
<krosswindz> probably you need to wait for some of the devs to answer it
<apokryphus> i got a signal on dvi and on the lcd conected trough the lcd_exp_ports
<apokryphus> ext...
<apokryphus> like extension
<apokryphus> i guess its connected to the "es" in pandaboard es - the newer revision
<apokryphus> but thank you
<krosswindz> sorry couldnt help you
<apokryphus> i mean maybe to nwer revision isn't fully supported
<apokryphus> thank you anyway
<krosswindz> your welcome
#ubuntu-arm 2013-02-04
<vipzrx> hello
<vipzrx> anybody here?
<vipzrx> [   32.533843] omapdss DISPC error: SYNC_LOST on channel tv, restarting the output with video overlays disabled
<vipzrx> [   32.627380] omapdss DISPC error: timeout waiting for digit out to stop
<dholbach> good morning
<mjrosenb> morning all.
<mjrosenb> I have the new(ish) ARM chromebook, i'd like to put the 13.04 prerelease  on there, is this remotely possible yet?
<fabo> mjrosenb: there's several way to do that. the easiest (imo) is to use http://chromeos-cr48.blogspot.fi/ then enable https://launchpad.net/~chromebook-arm/+archive/ppa and dist-upgrade to 13.04.
<fabo> ikepanhc: arndale kernel oops is fixed. you can pick up latest arndale kernel.
<mjrosenb> fabo: so I've used the first part before
<mjrosenb> fabo: and upgrading has bricked it before
<mjrosenb> fabo: although I was attempting to upgrade to 12.10
<mjrosenb> fabo: I take it this doesn't brick the machine with high probability.?
<ikepanhc> fabo: many thanks, the fix on linux-linaro-tracking.git tree?
<fabo> ikepanhc: yes
<fabo> mjrosenb: it can't brick it. you're using a separate sdcard.
<mjrosenb> fabo: at the time the shell script installed to the main sd card
<mjrosenb> and it certainly rendered ubuntu unbootable.
<fabo> mjrosenb: though it could be tricky because of an issue with plymouth. you shouldn't reboot in the process until you get 13.04 dist-upgrade done
<mjrosenb> fabo: yeah, I think my pandaboard ran into that one recently.
<mjrosenb> fabo: is it possible to just disable plymouth, and use the textual boot?
<ikepanhc> fabo: thanks again. I see it and I will give it a try.
<fabo> mjrosenb: if you have an usb ethernet dongle, you're safe as you could still restore graphics driver if it goes wrong with plymouth.
<fabo> mjrosenb: it doesn't brick, it's just that you're stuck at plymouth stage and X doesn't start
<fabo> ikepanhc: you're welcome. it works like a charm. now I'm looking for a guid on arndale to resolve random mac address issue.
<fabo> ikepanhc: is that the reason you use an usb ethernet dongle on arndale?
<ikepanhc> fabo: I have no idea, I am far away from the board and it is setup in a lab with remote power control and serial.
<ikepanhc> I can check with my colleague why they choose a usb-ethernet dongle
<fabo> ikepanhc: arndale has onboard ethernet (asix driver) but the driver assign random mac address because the chip doesn't have a valid one
<mjrosenb> fabo: thanks, I'll try it out in the next few hours hopefully.
<fabo> ikepanhc: if you use dhcpd, dhcpd lease will be full at some point...
<ikepanhc> fabo: the ethernet is asix indeed, its on usb bus right?
<fabo> ikepanhc: I used an udev rule to work around but assign a specific address
<fabo> ikepanhc: yes
<ikepanhc> fabo: I can see it on lsusb
<ikepanhc> fabo: oh, then its not dongle, what we use is on board ethernet
<fabo> ikepanhc: it's problematic if you have several boards in the lab... so I'm looking for a guid
<ikepanhc> fabo: that's alright, we assign static ip for them
<fabo> ok
<fabo> mjrosenb: feel free to ping, I'm around
<diwic> ogra, hi, tried flashing my Nexus7 using the GUI tool to have another stab at the audio, but it hung on "Erasing boot partition"
 * diwic cancels and tries again
<diwic> ok, worked after restarting the bootloader
<nils_> diwic, I had problems with the setup of ubuntu after starting the nexus installer
<nils_> the window of the language selection was to far at the right side and it was difficult to continue.
<nils_> can you confirm that?
<diwic> nils_, I wonder if I got the latest image, I thought I did, but it looks old
<nils_> uname -a shows: 3.1.10-9-nexus7 ... Thu Jan 31 12:23:44
<diwic> nils_, yeah, mine showed 3.1.10-7 something, so I'm reflashing it now
<diwic> nils_, hrm, it still says 3.1.10-7-nexus7 after a reflash! I guess I have to download the image manually or something
<diwic> ...or why not download the latest ubuntu-nexus7-installer first, argh
<nils_> good idea
<mjrosenb> fabo: ok, I tried that script for an external drive
<mjrosenb> fabo: it did not work, it looks like it made a filesystem that was too big for the partition that it made
<mjrosenb> then failed to do anything after that
<mjrosenb> and just rebooted the laptop instead.
<fabo> mjrosenb: external drive or sdcard? the script expect a sdcard
<mjrosenb> sdcard
<mjrosenb> sorry,
<ogra> diwic, if your PC is on raring, usb-creator will offer you the installation, no need for the extra installer
<ogra> diwic, and i would just do a manual install, it's just three four commands to flash manually (see the wiki)
<ogra> -three
<ogra> nils_, btw, did you notice that we have usbnet on by default now ?
<nils_> ogra, yes I was excited. I am studying about networking, ifconfig and so forth. I am already pinging a lot back and forth.
<ogra> thanks again for the suggestion :)
<nils_> I first tried out to set up the network manually with ifconfig but the two systems forgot their ip-addresses after a while.
<nils_> then I took the easy way and configured manually ip-addresses through the gnome interface.
<nils_> now it's stable.
<nils_> next what I have to understand is routing ;-)
<nils_> ogra, I tried to understand where I can see the changes of the build.
<mjrosenb> fabo: any idea?
<nils_> I thought I should find the changes here: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-nexus7.git;a=summary
<mosasaur> For an ARMv7 chroot, should I use an armhf or an armel core rootfs?
<ogra> in /usr/chare/doc/<packagename>/changelog.gz if you have the package installed, and on launchpad in the changelog indeed
<ogra> */usr/share
<nils_> sorry ;-) where on launchpad? I tried to search for the latest changes here: https://launchpad.net/~ubuntu-nexus7
<diwic> hrm, now I got the latest image (I hope), but the "who are you?" section in the installer does not accept input
<diwic> tried both the onboard and keyboard over OTG cable
<ogra> diwic, reboot, there is a race between onboard and compiz, it doesnt seem to happen after a reboot
<ogra> that and the corrupt wallpaper are known issues
 * diwic hopes that doesn't corrupt the sound
<ogra> does pulse have a new bling-test module that looks if your desktop is beautiful ? :)
<diwic> ogra, I was referring to the reboot :-)
<ogra> ah
<diwic> ogra, did you see my latest comment in bug 1068804 ?
<ubot2> Launchpad bug 1068804 in ubuntu-nexus7 "sound only works after suspend/resume cycle" [Critical,In progress] https://launchpad.net/bugs/1068804
<ogra> did you see mine ?
<diwic> ogra, ok, now I saw it
<diwic> nils_, yeah, the "system configuration" screen is far to the right after a reboot, but it wasn't before the reboot
<diwic> nils_, and if you rotate it to "portrait" there is no "system configuration" screen at all
<nils_> diwic, I had the same. Then I managed to show Onboard and could press Enter in order to proceed.
<nils_> This for a few more screens and after the installation everything fine.
<ogra> file a bug please, i know xnox loves them :P
<diwic> nils_, hrm, I have a keyboard connected to it, but pressing Enter does nothing
<diwic> ogra, btw, does the installer run things differently than the install? I see the installer has a sound indicator but no device in sound settings
<ogra> the installer uns as root
<ogra> *runs
<ogra> i think pulse or teh indicator have some prevention builtin
<ogra> so you cant use it as root
<diwic> ok
<diwic> anyway, this stuff isn't working; I can't proceed in the installer
<ogra> (i would actually like to hide that stuff from the panel ....
<ogra> i diont see a reason to play with sound settings during install (if sound works at least)
<ogra> diwic, try without kbd attached
<ogra> i know it works after a reboot for me ... and i stopped using mice or kbds a while ago on the nexus
<diwic> ogra, right, but I can't reboot it, because the "ok" for the reboot is off the screen too
<ogra> heh
<ogra> just hold down the power button
<ogra> it auto-reboots
<diwic> ok
<nils_> ogra, found it now: https://launchpad.net/ubuntu/raring/+source/linux-nexus7
<ogra> right, clicking the version numbers gets you the changelog details on that page
<ogra> https://launchpad.net/ubuntu/+source/linux-nexus7/3.1.10-9.24
<ogra> thats the change that added g_composite
<diwic> nils_, ogra ok, now I was able to complete the dialogs in portrait mode
<ogra> great
<ogra> we should probably disable auto-rotation during install
<ogra> and force it to portrait
<ogra> or simply switch back to metacity
<ogra> which didnt have any of these probs
<ogra> though thats xnox' decision
<diwic> ogra, sound works after reboot if removing /etc/init/alsa-store.conf and /var/lib/alsa/asound.state
<ogra> funny
<diwic> ogra, would be nice if you or someone else could verify
<ogra> i triesd the latter several times
<diwic> you need to remove both
<ogra> rebooting
<ogra> we shouldnt need to remove the state file if we override the upstart job from the beggingin
<ogra> -in
<diwic> ogra, correct
<ogra> though i /me hugs diwic
<ogra> err
<ogra> - though i indeed :)
<ogra> works fine !
<diwic> ogra, TheMuso deserves a hug too
 * ogra hugs TheMuso 
<ogra> twice !
<ogra> so what if i copy the upstart job back ?
<ogra> would that work ?
<ogra> i assume we still want to store the volume and states  on shutdown
 * ogra does it and reboots
<diwic> ogra, so assuming this actually is the culprit, is there an easy way to remove /etc/init/alsa-store.conf from the nexus7 image without removing it from the entire distro?
<ogra> sure
<ogra> its a simple .override file i need to put in place
<ogra> though it would still be good to know why using a state file doesnt work (and fix the root cause)
<ogra> btw, copying back the upstart job leaves me without sound again
<diwic> ogra, and that creates the asound.state file so you must again remove both to have sound back I assume
<ogra> well, bot upstart jobs then
<ogra> *both
<ogra> but that means that volume settings wont persist over reboots
<diwic> ogra, no I don't think so - PulseAudio should have its own store/restore system
<ogra> ah, k
<diwic> ogra, that said, because we always run both, I guess we haven't tested PulseAudio alone much
<ogra> diwic, workaround uploaded
<diwic> ogra, thanks, could you write that in the bug and point to the workaround?=
<ogra> the bug should auto-close
<diwic> ogra, let's hope this is the one :-)
<ogra> oh, wait, needs a task for the defaults package
<diwic> we've had too many red herrings for this bug already
<ogra> well, it works just fine here
<ogra> just the muted state is left for me
<diwic> ogra, did you confirm it was still working even though you override *both* alsa-store and alsa-restore?
<diwic> ogra, alsa-restore falls back to some default values if it finds no asound.state
<ogra> yes, indeed, i tend to test uploads before i send them upwards :)
<ogra> it isnt executed at all
<ogra> thanks to the override file
<diwic> ogra, there are two different calls to "alsactl restore", one in alsa-restore.conf and one in /lib/udev/rules.d/90-alsa-restore.conf
<ogra> ah, well, the udev rule is indeed still executed, i didnt do anything to prevent that
<diwic> ogra, which one that gets executed, if I understand things correctly, depend on what comes up first of file system and sound device, or something like that
<ogra> in any case it works here atm
<diwic> ogra, so, what is the reason for overriding alsa-restore.conf too?
<ogra> if i hear complaints from users i will look again
<ogra> well, i didnt think about the udev rule, but essentially to prevent users that actually have the state file from having it restored
<ogra> and instead leave the initilization to the kernel
<diwic> ogra, hmm ok
<ogra> though if the udev rule kicks in thats indeed moot
<diwic> ogra, it just feels inconsistent to disable one but not the other
<ogra> it seemed like a better way than having to do postinst hackery to remove the state file
<diwic> janimo, ogra https://bugs.launchpad.net/ubuntu-nexus7/+bug/1068804/comments/31
<ubot2> Ubuntu bug 1068804 in ubuntu-nexus7 "sound only works after suspend/resume cycle" [Critical,In progress]
<ogra> diwic, will test later today (havent got the latest kernel source here atm)
<diwic> ogra, thanks
<diwic> ogra, I did my own test: I took the asound.state file, removed the "Register Control" entry, and let alsa-restore run as normal after a reboot, and audio still worked
<diwic> ogra, so I'm hopeful
<ogra> awesome !
<xnox> ogra: inhibitting autorotation seems fine.
<xnox> is the portrait mode intended as the "default" while configuring these days?
<xnox> (we used to be landscape only, but that's before autorotation worked)
<ogra> xnox, yeah
<ogra> the bootloader sets portrait as default, we dropped all hacks that change this
<xnox> ogra: so how does one "inhibit" autorotation? stop the daemon?
<ogra> xnox, i'm really wondering if we shouldnt go back to metacity though
<ogra> you can stop the upstart job, but make sure to start it again when stopping ubiquity
<ogra> though better talk to janimo, not sure if we will keep the upstart bits in the long run
<ogra> he ports everything over to gnome-settings-daemon
<ogra> (so we'll probably have a dconf key thats better suited for the task)
<xnox> let me upload with more compiz plugins enabled and then I'll maybe will have an opinion about it.
<xnox> (e.g. keep compiz vs switch back to metacity)
<ogra> yeah
<ogra> the focus thing is really bad
<ogra> and that a simple reboot fixes it is irritating
<scottb> lool, ping
<lool> scottb: in a call, but please leave a msg
<mjrosenb> fabo: still around?
<mjrosenb> alternately, has anyone succeeded in installing ubuntu on the sdcard of a chromebook?
<mjrosenb> it seems to die after partitioning because it made the filesystem too large
<janimo> xnox, good point. We probably need some user visible settings to disable rotation
<ogra> janimo, i think there is a setting in gsettings already for the xrandr module
<ogra> (for g-s-d)
<ogra> hmm, or was that just for the touchscreen input rotation ... i forgot
<janimo> ogra, maybe if you disable the g-s-d orientation plugin entirely
<janimo> but that's not enough as it needs a restart to take effect
<janimo> I think a toggle in the current Display Panel would be most appropriate
<ogra> yeah
<drizzy> howdy everyone
<TheMuso> diwic: Good find.
<TheMuso> I suspected there might be something along those lines as well.
#ubuntu-arm 2013-02-05
<sim590> Anyone here using the TF101 under ubuntu or any linux distro? I'm wondering if you get in/out errors with file system on the micro SD card
<infinity> sim590: That's going to be an issue with the card, not the OS.
<sim590> infinity: I know. I'm presently runnin Debian on my tf101 with the SD card (in the keyboard). I'm having input/output errors and I suspect the reason would be the use of the SDcard port in the keyboard.. the connection could be interrupted sometimes because of the lack of stability between the keyboard and the tablet
<sim590> so, I wanted to verify this hypotesis by asking people if they're having problem with the micro SD card (not in the keyboard) so that would solve my problem if I would use the micro SD card instead
<infinity> sim590: Oh, yeah, I've heard bad things about the keyboard SD slot.
<infinity> (Second-hand, since I don't own a transformer, but you wouldn't be the first to complain about it)
<sim590> ok. I guess I'll try the micro SD card and pray for no problems.
<sim590> Thanks for your time to think about my problem!
<lilstevie> sim590, only if you ever let the device sleep
<sim590> lilstevie: ok.. I thought that I have experienced that kind of problem too with my configuration
<sim590> may be I can program something to make it shutdown instead of sleeping each time it wants to sleep
<lilstevie> or tell it not to sleep :p
<sim590> yeah, but if it runs out of battery..
<sim590> it's going to hibernation
<sim590> and I guess that would be bad too
<lilstevie> it won't hibernate
<lilstevie> it will shutdown
<sim590> oh yeah right I remember.. it happenned to me once.. It shuts down but not in a kind way if I remember
<sim590> like if there was no protection configured so that it would just run out of batery and shutting down without writing to the filesystem and journal
<sim590> so we gotta e2fsck afterwards
<sim590> Ok, so I guess I'll buy a micro sd card tommorrow wishing that everything goes well then. Thanks everyone! I hope not to see you again for that matter but other projects may be! ;)
<dholbach> good morning
<nils_> good morning
<nils_> I have tried the nexus installer again. It works now ok in portrait mode. I only had to restart as the keyboard didn't work at the first go.
<nils_> also I have noticed there are two bluetooth icons in the top notification bar. I don't remember seeing two before.
<ogra> nils_, yeah, we are moving to a new bluetooth indicator, the old one wasnt removed yet
<ogra> (the other bugs with the installer are known and being worked on)
<phlipped> Hello
<phlipped> I have a BeagleBoard-XM
<phlipped> I've downloaded 12.04 Server image for OMAP3 - ubuntu-12.04-preinstalled-server-armhf+omap.img.gz
<phlipped> unzipped and dd'd it to a 4Gb MMC card
<phlipped> But it doesn't boot
<phlipped> get's stuck at ...
<phlipped> Loading file "/boot/uImage" from mmc device 0:2 (xxa2)
<phlipped> This isn't too surprising, because there is no /boot/uImage on the second partition of the MMC
<phlipped> So I'm wondering ...
<phlipped> Is this a bug?
<ogra> this is definitely not something the ubuntu images do print
<phlipped> Also, uboot tries to read uEnv.txt, not boot.scr
<ogra> thats the default, yeah
<phlipped> yet there's a boot.scr in the FAT partition
<phlipped> I don't think uboot is even reading it
<ogra> yes, it shouldnt
<phlipped> oh ... so why is it there?
<ogra> the "Loading file "/boot/uImage" from mmc device 0:2 (xxa2)" is simply not something an ubuntu image would print though
<phlipped> no, it's not
<ogra> so check if you accidentially dd'ed to the device (not to a partition) so that an old bootloader partition is around
<phlipped> it's uboot pringint it
<ogra> err, if you accidentially *not* dd'ed to the device
<phlipped> definitely dd'd to the device
<ogra> well, the ubuntu uboot setup doesnt load anything from a /boot dir and doesnt print such stuff
<ogra> so there is something wrong with your SD
<ogra> (did you change uEnv.txt, preEnv.txt or boot.scr from the defaults ?
<ogra> )
<phlipped> I've checked the img file I downloaded from Ubuntu (and checked the hash too), and inspected the partitions in the image file
<ogra> right, but did you change anything ?
<phlipped> They are the same files inside the image
<phlipped> no didn't change anything
<ogra> weird ... these images get tested before release ... quite a lot actually
<phlipped> yeah, that's what I'm confused about
<phlipped> I've downloaded it a second time just to be sure
<ogra> it could indeed be that your XM is to new for the shipped kernel ...
<ogra> but that still wouldnt explain why uboot prints such stuff
<phlipped> Perhaps, but it's actually pretty old - a year or two
<ogra> and it would then rather hang after the kernel was loaded
<ogra> instead of searching in a non std place for it
<phlipped> It seems to me that the problem is the default boot script is trying to load a file form /boot/uImage
<phlipped> from*
<phlipped> the boot script would get modified if uboot would read boot.scr
<phlipped> but it doesn't
<phlipped> This guy http://elinux.org/BeagleBoardUbuntu#boot.scr_-.3E_uEnv.txt shows a way where you can point uboot back to boot.scr by dropping in a small uEnv.txt
<phlipped> I tried this and it looks like everything works again
<ogra> thats wrong
<turbo_ac100> janimo, what's the status of ac100 daily-preinstalled? Are there still changes to the image like newer kernels or similar?
<janimo> turbo_ac100, no work done on newer kernels
<janimo> the changes are from regular package updates only
<turbo_ac100> so same version as 12.10 then? Is this the newest one?
<janimo> turbo_ac100, yes
<janimo> turbo_ac100, do you need a newer kernel for some specific reason?
<turbo_ac100> janimo, well, I asked this on #ac100 some time ago. But my problem with the 12.10 kernel compared to the 12.04 one is that I couldn't set the amount of RAM used for graphics.
<turbo_ac100> I reduced the mem to ~8-12 Mb in 12.04 and it was 64 or similar in 12.10. I downgraded.
<turbo_ac100> And in 12.04 cdc_ether doesn't work.
<ogra> did you file bugs ?
<turbo_ac100> Lemme check
<turbo_ac100> about cdc_ether definitely no, because #ac100 said it wouldn't build so i didn't bother
<turbo_ac100> mem neither. It was common sense in #ac100 that the "old way" of using kernel-cli doesn't work anymore, nobody knew about an alternative
<turbo_ac100> filed a bug about the memory now. https://bugs.launchpad.net/ubuntu/+source/linux-ac100/+bug/1116380
<ubot2> Ubuntu bug 1116380 in linux-ac100 (Ubuntu) "Video Mem too much and not changeable trivially" [Undecided,New]
<turbo_ac100> hehe
<ogra> hrw!!!
<ogra> armsoc !!!!
<hrw> yes
<hrw> someone digged it out of NEW
<hrw> ogra: time to pdebuild new kernel and send to NEW as well
<ogra> ++
<ogra> i'll have to move to a sane install at some point
 * ogra is still on the upgraded chrubuntu
<mcurran> What's the difference between project and "ubuntu for ARM"?  Was this project built from the beginning with an intention of running in a chroot env.?
<ogra> parse error ?
<hrw> mcurran: rephrase?
<hrw> ogra: never used chrubuntu
<mcurran> I believe there would be huge market for handheld devices if ubuntu could be dual/multi-booted.
<mcurran> ie. run natively
<ogra> well, it was the variant that was around when i got my chromebook :)
<hrw> mcurran: I never used ubuntu in chroot on arm devices
 * ogra does all the time for building for different releases
<ogra> but that doesnt differ from what i do on x86
<hrw> ogra: but you do ubuntu-in-chroot under ubuntu so it does not count
<ogra> mcurran, all official ubuntu arm images are native
<ogra> hrw, ah, yeah, i didnt think about android crap setups that people might do
<ogra> :)
<hrw> mcurran: most of customer devices have crazy bootloader setups
 * ogra doesnt touch such stuff
<hrw> neither do I
<hrw> mcurran: which device you want to run ubuntu on?
<Tassadar> I have ubuntu chroot in Android, but it is the same installation which I also dual-boot, which is kinda great :)
<ogra> yeah, but doesnt help the purpose of the n7 image much :)
<ogra> it heps endusers to get a crappy UI though ;)+
<ogra> *helps
<Tassadar> not really, but I had debian in there before because native ssh in terminal emulator is often better than those android apps, now I at least don't have two installations
<ogra> (alongside android)
<ogra> did you fix the kernel upgrade issues btw ?
<Tassadar> yes
<ogra> awesome, how ?
<Tassadar> I just create the initrd symlink during installation so the first boot works, and after the setup it is managed by Ubuntu, so it's okay.
<ogra> you dont just set FLASH_KERNEL_SKIP ?
<ogra> that wouldnt need any additional changes at all
<Tassadar> I also had to disable flash-kernel by "export SKIP_FLASH_KERNEL=1"(or whatever is the right export), because if I do "hold" on uninstalled flash-kernel, it is removed during the setup wizard for whatever reason
<ogra> yeah, you should be able to just add it to /etc/environment
<Tassadar> that's what you said before, and that's what I did, thanks :)
<ogra> (doesnt need "export" i thinnk)
<Tassadar> yeah
<Tassadar> ogra: I was talking about initrd, because the symlink is not created in the daily image, so I searched for "initrd-*" file instead of using the symlink
<Tassadar> which was kinda dumb :/
<ogra> great, so we can at least rely on the fact that people filing bugs have the right kernel
<Tassadar> well, I can't be sure everybody properly updated
<Tassadar>  but I think they did
<hrw> ok, kernel sent to pbuilder
<Tassadar> otherwise flash-kernel would overwrite their Android, which is kinda good reason to check the XDA thread
<Tassadar> and the problem was only if they had older installation and new kernel was installed via apt-get dist-upgrade
<Tassadar> if they got newer image, it should be okay
<Tassadar> but anyway, sorry if it causes any false bugs :(
<ogra> well, it causes bug noise for bugs that have been long fixed, not more
<hrw> ogra, infinity, janimo: linux-chromebook sent to NEW
<ogra> \o/
<janimo>  /\
<diwic> hrw, hey, have you bothered verifying your chromebook ucm stuff? I e flipping the SRU to verification done
<diwic> hrw, https://bugs.launchpad.net/bugs/1085392
<ubot2> Ubuntu bug 1085392 in Cross distro support for Samsung Chromebook (ARM based) "Merge Chromebook UCM profiles into ALSA packages" [Critical,Triaged]
<hrw> diwic: was overloaded with other stuff. And I lost any hope on 'ubuntu on chromebook' lusers
<diwic> hrw, fair enough. I have nothing else in the pipeline for SRUing alsa-lib/alsa-utils right now, but if I do, it would be stupid to already have a pending SRU for it
<diwic> so it's not urgent
<diwic> hrw, just mildly annoying :-)
<hrw> diwic: good point.
<hrw> diwic: good thing is that my changes do not affect other devices
<diwic> all right, have a good evening
<infinity> hrw: How much scary code on top of a 3.4.0 vanilla is in that chromebook, and how carefully am I going to have to review it for licensing oopses? :P
<mjrosenb> can anyone help me get ubuntu on an sd card on my chromebook?
<purezen> Hey guys..!! If I install Ubuntu on the samsung ARM chromebook.. will I be able to carry on my usual compilation tasks..? such as Android development, python scripting, C++...?
<infinity> Sure.
<purezen> infinity: You mean.. all of them..?
<infinity> purezen: Well, Android development could depend on how you currently do it, and things might change.
<infinity> As in, you can't use an x86 SDK on an ARM machine (obviously).
<infinity> But python, C++, whatever, Ubuntu is self-hosting, so it can clearly build for any language.
<purezen> infinity: Yeah..:) so the ARM version available on the site will do the job..?
<infinity> purezen: Don't see why not.  I don't do Android development, though.
<purezen> infinity: Ok.. didn't know that..:) never tried Linux on ARM yet..
<purezen> infinity: Ok..
<infinity> Well, stop calling it "Linux on ARM", and just call it "Linux", and you'll be doing well.
<purezen> infinity: Ok.. even better..:)
<infinity> The underlying architecture should make almost zero difference, unless you're trying to run precompiler binaries for the wrong CPU. :P
<infinity> precompiled*
<purezen> infinity: Ok.. that's great.. cause I am planning to get it.. and it'd be a big decision for me..
<drizzy> i wish there was flash support for arm
<drizzy> i have 32gb and i don't wanna use it all on music
<drizzy> 32gb of storage
<drizzy> actually like 20gb
<drizzy> cause it's used up already
<drizzy> on apps on the other partition
<purezen> So anything I'd loose on Linux on one.. from a developers viewpoint..?
<infinity> purezen: Compared to...?
<infinity> purezen: You mean compared to running ChromeOS?
<purezen> No.. no..
<drizzy> heh
<purezen> I mean the usual x64 processors..?
<infinity> Speed, and proprietary software.
<infinity> (See above with drizzy complaining about Flash)
<drizzy> that's my only complaint
<drizzy> no flash
<drizzy> i use google play music
<drizzy> it has like 20,000 songs
<drizzy> if i put 20,000 songs on my nexus 7
<drizzy> i'll be fucked
<drizzy> with storage problems
<purezen> infinity: Ok.. didn't know that..
<drizzy> i guess i can use my external hdd
<purezen> drizzy: Hey.. get it..:)
<drizzy> for music
<drizzy> i wonder if there's a html5 streaming service for cloud stuff?
<drizzy> other then youtube
<drizzy> and not mega.co.nz
<drizzy> i'm so against kim dotcom
<purezen> Hey.. I can't get any info. on the Chromebook being used for android development.. can anyone confirm here..?
<infinity> purezen: If they offer an ARM SDK (ie: something that isn't an x86 cross-compiler), it should work.
<purezen> infinity: Ok.. java shows an installer for ARM (there' one there right..?).. but I can't figure out if Android does the same..
<purezen> infinty: can you tell from this: http://developer.android.com/sdk/index.html..?
<infinity> purezen: The Sun Java on ARM isn't armhf.
<infinity> purezen: But openjdk is in Ubuntu, most people who think they need Sun Java are wrong.
<drizzy> there's not a android sdk for arm on that page purezen
<drizzy> especially for the adt
<purezen> infinity: Ok.. that'll do for the Java compilation part..:)
<drizzy> adt bundle*
<purezen> drizzy: Ok..
<drizzy> although
<drizzy> i wonder if you could run a vm on top of linux...
<drizzy> wait, no it's stiill not x86
<drizzy> i was gonna say run windows in a vm
<drizzy> but no go
<purezen> drizzy: so eclipse and stuff (android development image..?) is dependent on the platform..?
<purezen> drizzy: or which part is..?
<drizzy> i think you can use eclipse ide on arm
<drizzy> let me see if i can install it
<drizzy> i'm having problems with repos 404'ing
<drizzy> anyone else on ubuntu-arm platform having these issues currently?
<drizzy> i was trying to install audacious earlier
<Tassadar> apt-get update is not helping?
<drizzy> cause i fucked up my last ubuntu
<drizzy> nope
<drizzy> Tassadar: i did that earlier
<drizzy> as soon as i finished installing
<drizzy> i thought it was the wifi host
<drizzy> so i switched networks
<drizzy> i thought they were getting tired of me using up all their bandwidth
<drizzy> but i'm getting the same from this wifi network
<drizzy> purezen: eclipse is installing
<purezen> drizzy: K..:)
<Tassadar> android SDK is not only java, it uses native tools too
<Tassadar> maybe it can be built for arm? dunno
<drizzy> nexus7 32gb + otr usb + 4 port hub + usb keyboard + usb mouse = $300 awesome laptop
<drizzy> just reminded myself to join a channel
<drizzy> lolz
<purezen> drizzy: so, the thing stopping here is the.. Platform image..?
<drizzy> platform image for ubuntu ?
<Tassadar> purezen: Android SDK does not use just java
<purezen> drizzy: I meant.. corresponding to which the compilation takes place.. (maybe poorly expressing though..).. just guessing.. or what's stopping the ADK from being used then..?
<purezen> Tassadar: ok..
<purezen> Ok.. thanks guys for all the info.. Gotta go now..
<purezen> BBye..:)
<hrw> infinity: all new files have gpl headers in them
<infinity> hrw: That's comforting.
<hrw> patch against 3.4 is 9.8MB but looks strange as it removes 7MB
<hrw>  1230 files changed, 13567 insertions(+), 257356 deletions(-)
<hrw> have to check did I did it proper side
<hrw> yep.
<hrw> will read whole patch to confirm
<drizzy> brb ditching xchat
<hrw> infinity: ok. went though that 7MB - gpl headers in 99% of files
<hrw> some had bsd like headers (atheros driver)
#ubuntu-arm 2013-02-06
<infinity> hrw: I can haz a linux-meta-chromebook to go with this kernel?
<hrw> infinity: will make such
<dholbach> good morning
<hrw> infinity: linux-meta-chromebook uploaded
<dholbach> can somebody please reply to the comment on  https://plus.google.com/u/0/109795858099658821877/posts/JKQWnaRVqC1?cfem=1 ?
<ogra_> will do if i'm on a sane machine
<ogra_> (nexus7 isnt so great for typing ;) )
<fly-away> any tablet isnt so great for typing afaik
<fly-away> even ipad
<ogra_> its fine, i use it for hours every evening (i banned all other machinery from my living room)
<ogra_> but not for answering posts with long texts :)
<VarmVaffel> I'm trying to use a regular C write() operation on a i2c bus, but it keeps timing out
<VarmVaffel> could this be because the bus is always too busy, or would I get other error messages then?
<VarmVaffel> Im' using the /dev/i2c interface
<dholbach> thanks ogra_
<ogra_> welcome
<ogra_> might be that he uses an old version of the dual boot image
<ogra_> that had issues with kernel updates
<dholbach> ah yes
<ogra_> (fixed in newer versions of that image, Tassadar is very responsive to fixes :) )
<Tassadar> well, at least that I can do)
<sveinse> Why wouldn't the kernel allow me to umount something I've just mounted in initramfs (local-premount)? I'm getting Device or resource busy
<ogra_> sveinse, lsof ?
<ogra_> or fuser
<sveinse> well neither is included in initramfs afaiks
<sveinse> hmmm. "error: couldn't mount because of unsupported optional features (240)" <-- that is probably why I can't umount it afterwards. Perhaps mount needs to be told explicitly that this is ext4 not ext2
<ogra_> no
<ogra_> if you dont specify a fs the kernel just loops over all the ext* ones
<ogra_> these messages are from probing, not from the actual mount
<sveinse> No, they come when I call mount
<sveinse> Ah. I see. Scratch that. EXT3-fs fails, EXT2-fs fails EXT4-fs mounts
<sveinse> sooo. how come I cant umount afterwards...
<ogra_> something has a file open in your mountpoint
<sveinse> I need a fresh set of eyes on this:
<sveinse>  mount -t vfat /tmp/sr/root/data.img /tmp/sr/data.img -o loop
<sveinse>  umount -f /tmp/sr/root/data.img
<sveinse> umount: can't forcibly umount /tmp/sr/root/data.img: Invalid argument
<sveinse> Does it require the mount device to be specified, not the mount point?
<Tassadar> umount requires the folder to which it was mounted to I think
<ogra_> either should work, though -f might not work on loop mounts, not sure
<wookey> infinity: Can you peruse https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1117602 and tell me if you understand what's going on?
<ubot2> Ubuntu bug 1117602 in eglibc (Ubuntu) "eglibc does not crossbuild for arm64" [Undecided,New]
<infinity> wookey: multiarch doesn't mean what you think it means.
<wookey> right. That's what I was thinking
<wookey> but it's turned on for all arches, I'm just trying what happens if I turn it off for arm64
<wookey> What will that break?
<infinity> wookey: Anyhow, I was going to rev cross-base stuff today.  Let me play with this.
<wookey> OK, there are a couple of patches in there that need merging I think.
<wookey> So that cross-building from the normal source works
<infinity> I'm on top of it.  Don't worry.
<wookey> I guess we should either fix whatever is wrong with dh_shlibdeps or put 'if cross-building don;t do this' round it properly
<wookey> the disable selinux patch is wrong (should be controlled by DEB_STAGE, not just nobbled)
<wookey> arm64 no profile is good
<infinity> The DEB_STAGE stuff all needs fiddling.
<infinity> And the no profile patch is obsolete.
<wookey> yes
<infinity> The dh_shlibdeps thing may or may not still be necessary, I fixed a bunch of things relating to that sort of thing in 2.17, but I'm not sure what the point of the patch was.
<wookey> I'm not sure about the others.
<infinity> Like I said, I'm fiddling with this today.
<wookey> OK. I'll let you poke and go back to perl :-)
<infinity> I'm not entirely sure what the point of the locales patch is either, except to very marginally speed up the build, perhaps.
<wookey> Keen to test though cos I can;t build anything automatically without a buildable libc. SO when yuo think it might go...
<wookey> yes. I'd ignore that
<wookey> Or at least it can stay in cross-base
<infinity> wookey: Wait, is this a cross-only issue, or is arm64 really the only arch that doesn't support IFUNC?
<plars> do we not continue to produce preinstalled images for omap4 on precise?
<infinity> plars: Nope.
<infinity> wookey: Anyhow, it's entirely possible we don't need enable-multiarch for arm64 at all right now, given that aarch64 only has one subarch.
<infinity> wookey: So, yeah, I'll disable multiarch on aarch64 for now.  That seems the sane and reasonable thing.  As Roland points out, any case of this "working" before when it shouldn't have was broken, so this isn't a regression, but a fix. :P
<infinity> wookey: I suspect ARM will probably want ifun/multi-arch madness when armv8 starts to rev with new features, but we'll cross that bridge when we get there.
<infinity> ifunc*
<infinity> wookey: (Basically, this isn't what you think multi-arch is, in the Debian sense, this is being able to build DSOs that contain multiple versions of symbols for different subarches)
<infinity> wookey: So, it was always a mistake that it was in the arm64.mk config in Debian/Ubuntu, it was just luck that it "worked" cause the test was broken.
<infinity> wookey: I'll push fixes for this to experimental/raring today.
<infinity> wookey: I had to do an experimental build to fix mips/mipsel anyway, so this makes me feel less bad about it if I have something else to upload for. :P
<wookey> infinity: right, yes as you say, confusion over what 'multi-arch' meant and luck that it built/worked on 2.16
<wookey> yes aarch64 probably is the only one without ifunc support
<wookey> ifunc is coming, I'm told, jus tnot done yet
<infinity> wookey: All fixed in Debian SVN, at any rate, and tested locally.  Just fixing one more thing before I upload.
<wookey> cool
#ubuntu-arm 2013-02-07
<wookey> infinity: OK, with that stage2 patch and removing --enable-multiarch it at least completes a cross-build here
<twb> Remind me, what's the SoC that's pre-armv7, but still being made?  IIRC there's r-pi and one other.
<wookey> I don;t suppose the rpi soc is still being made, just the boards, using up large stock of videocore 2xxx chips
<wookey> pxa270 is still available I believe
<twb> Hum, OK
<wookey> and various marvell devices which are v6
<twb> The context is me telling people to stop getting excited about rpi because armv6 is obsolete and sucky :-)
<wookey> yes, keep doing that. I do it too
<twb> Ah, right.  My memory said it was marvell dove, but that's v7
<wookey> OK I thought 'dove'. WHat about armada? Maybe it's an earlier one that is v6
<infinity> dove and armadap are all the same general family.
<wookey> armada seems to be v7
<infinity> There are some v6 devices in said family, but none worth talking about.
<twb> dove sucks because it has no NEON, not because it is pre-v7
<infinity> Anyhow, telling people to move to v7 is sane messaging, IMO.
<wookey> so, yes it's geting hard to find things still made which aren;t v7
<infinity> Not that the Pi being v6 is a problem, per se, it's that it's v6 and being used as a general-purpose machine, instead of a fun pseudo-embedded student/hacker device.
<infinity> Pretty much all general-purpose ARM computing should be moving/moved to v7 and v8, IMO.
<wookey> and that we still haven't put ISA info into dpkg metadata
<infinity> (I might be biased)
<wookey> we're going to get the same prob with v8 32 bit ISA at some point...
<infinity> wookey: What v8 32-bit ISA?
<wookey> it'd be nice to put the machinery in so dpkg can just DTRT
<wookey> aarch32
<infinity> wookey: Every single time I've brought this up in the past, I've been told there isn't one, and 32-bit on v8 is v7.
<wookey> no there are a few extra instructions
<wookey> so it's the same ABI, but new instructions
<infinity> Well, yes, I'm sure it's possible to do an x32-like aarch32, I was told (repeatedly) that no one was going to. :/
<infinity> Oh, same ABI as v7?
<infinity> Well, that's not a big deal.
<wookey> and yes at some point people will want to do 'x32 for arm' - just watch them...
<infinity> Same ABI and new insns just means glibc caps.
<wookey> the point is that ABI is not sufficient to determine compatibility - you need ISA as well and we don;t write that down anywhere
<wookey> agreed, but dpkg needs to know too so it can download the right version
<infinity> We don't write that down because we intend for an entirely self-contained distro to have the same basline ISA.
<infinity> Anything else is madness.
<infinity> Err, no.
<twb> infinity: doing x32 on x86 systems is already a dirty hack
<infinity> "download the right version"?
<wookey> well not try to install versions that won't run
<infinity> wookey: You can't have two armhf debs in the same version.
<infinity> This isn't actually a problem.  At all.
<wookey> i.e ubuntu armhf packages on RPis
<infinity> If you don't want to install wrong-ISA debs, don't use the wrong apt source.
<infinity> wookey: Or Ubuntu i386 debs on Debian. :P
<wookey> why not make it possible to enforce that?
<infinity> wookey: This isn't a problem.  It's really not.
<wookey> It's not hard to fix though either.
<infinity> I disagree.
<wookey> just write down the caps used in the metadata
<infinity> You have zero idea what the contents of the deb are without disassembling.
<infinity> You can make some sort of assumptions based on your custom copy of dpkg, if that's what you mean.
<wookey> you know when you build it - or at least you know what you meant to build
<infinity> But, again, I don't see how this is a problem.
<infinity> You're running Raspbian, you install Raspbian debs.
<infinity> People keep making this sound like a big deal and it's not.
<wookey> No-one tries to install3rd party debs on their rpis?
<infinity> I don't really care if they do.
<wookey> from all those bazillions of ppas?
<wookey> the users might care
<infinity> In your scenario, people trying to install Ubuntu debs on Debian wouldn't be allowed.
<infinity> (And they shouldn't anyway, but now dpkg would enforce it)
<wookey> only if their debian hardware couldn't run v7
<wookey> in which case that would be good
<infinity> I'm talking i386, actually.
<wookey> and this is useful for mplayer-686 and other stuff currently bodged into the packagenames
<infinity> Okay, so you're saying that dpkg should check the running system to determine caps at that moment.
<infinity> That entirely breaks portability of system roots.
<infinity> It's not useful for mplayer-686 at all.
<wookey> If I told it to yes. I expect I'm allowed to turn it off for cross-choots
<infinity> Because you can still only have one mplayer.deb in any apt source.
<infinity> So if you want an optimised one, you need another package name.
<wookey> but I can have more than one apt source
<infinity> But mplayer-686 isn't in another source.
<infinity> And shouldn't be.
<infinity> That's user hostile.
<infinity> I think you're trying to solve a problem "normal" people don't have with a nerd solution that only nerds will understand.  And nerds don't need it.
<wookey> I'm tryingto make it possible for dpkg to tell you that what you are instaling won;t run on this machine so are you sure you want to install it.
<wookey> That doesn't seem user-hostile to me
<infinity> Most of your use-cases are user-hostile.
<infinity> Like, adding extra sources to get optimised packages.
<sim590> anyone knows how I can get the battery level on the TF101 under lilstevie's kernel (ubuntu/debian)? I looked up the folder "/sys/class/power_supply" for that information but all I can get is a % level.
<wookey> I'm not forcing anyone to do that, but it would become possible. and you could now easily optimise _lots_ of stuff instead of just a few things
<infinity> wookey: Either way, dpkg installs system roots.  Saying "that won't run on the hardware you have RIGHT NOW" is meaningless.
<infinity> wookey: I could install a sysroot on i686 and give it to someone with an i585 and it won't run.
<infinity> wookey: And no, it wouldn't let you optimise anything in the primary archive any more than you already do.
<wookey> sometimes. most of the time stuff is installed onthe system it's going to be run on.
<infinity> wookey: And optimising out-of-archive is *drum rull* user-hostile.
<wookey> you can check against the target if you know what it's going to be
<infinity> wookey: That's a blatant lie in the Ubuntu case (or any live installer).
<infinity> wookey: The install is always done on a system that isn't the target.
<wookey> OK, so you don;t think it's useful. fair enough
<infinity> I think people need to learn to detect CPU features.
<infinity> Your example above (mplayer) actually has.
<sim590> I want W*h (Joules) or coulons (that's in french though.. its intensity (c/s)
<infinity> When I run it on my machine, it turns on all sort of fancy SSE3 and other crap that it doesn't turn on on an older box.
<wookey> OK, so then it doesn;t need to ask for caps it can live without
<wookey> whichis fine
<infinity> I guess my point is that this is solving a non-problem for pretty much all but the weird case of people mixing and matching distributions.
<infinity> And the answer to that is "stop doing that".
<wookey> but what if the server people start asking for lots of v8 optimised binaries because it's loads faster?
<wookey> we can just say no
<infinity> I've certainly seen people in #debian-arm whine that packages installed from debian-armhf don't work on Raspbian, I don't think the whining would change any if dpkg stopped them before installing.
<wookey> but if we can easily accomodate it with a check I don;t see why that's bad
<infinity> Do you think the "server people" are going to ask for 32-on-64 anytime soon anyway?
<infinity> Anyhow.
<infinity> This doesn't solve that.
<infinity> You still need either a new dpkg arch, or a new distro.
<twb> Can someone confirm that current ubuntu armel uses -mfpu=softfp (i.e. doesn't require hardware FPU)?
<infinity> Cause you can't.  Have.  The.  Same.  Deb.  Twice.  In.  The.  Same.  Archive.
<wookey> don't know - they might do if they have a lot of 32-bit binaires they cant get 64-bit versions of. Hopefully not.
<twb> It's not very clear on the wiki ARM article
<infinity> twb: There is no ubuntu armel.
<twb> infinity: hah, so it's just "arm" now?
<infinity> twb: Did that help?
<infinity> twb: armhf.  We dropped armel.
<infinity> twb: And armhf most definitely required an FPU.  vfpv3-d16
<infinity> s/required/requires/
<twb> It would be nice if https://wiki.ubuntu.com/ARM made that more obvious
<wookey> it's a wiki....
<infinity> wookey: If they want to install multiarch arm64/armhf, they're going to end up with baseline v7 armhf binaries unless they rebuild the archive.
<infinity> wookey: And if they rebuild the archive, we're in "not the same distribution" land.
<wookey> infinity: yes, but I don;t see why a distro _has_ to only support one baseline per ABI. If we labelled them we could provide more variants
<wookey> that would have made the rasbian's people's lives a lot easier, for example
<wookey> but OK. I get it that you're not keen :-)
<raster> wookey: rpi is just a piece of pretty crappy hw. deal with it. its a very outdated instructionset versions pushed out for cheap.
<raster> deal with it. you'll have to jump through hoops and make custom pkgs for it as everyone else has moved on to armv7 ÑÑ Ñ Ð¸ÑÑÑÐ´ÑÑÑ
<raster> err
<raster> armv7 as a baseline
<wookey> I know.
<wookey> it's just an example.
<wookey> because people _have_ gone to the trouble of rebuilding the whole distro
<wookey> for a different ISA
<twb> Hm, arm builds are still on ports.ubuntu.com?  I'd have thought it'd move to archive.ubuntu.com when it was blessed as a fully supported arch
<raster> reality is armv7hf+neon should be the baseline
<raster> and thats a very decent baseline with not much above it
<wookey> twb: sadly not
<infinity> wookey: Err, we can't do more than one without them being in separate archives.
<raster> in x86 land we have also a wide range
<infinity> twb: archive/ports has nothing to do with supported, but with popularity/traffic.
<wookey> right, and it'd be nice if those archives were labelled with the capabilities needed to run them - that's all
<raster> most of the compiling is fine-tuning small percentages of per increase
<raster> the few where its big should be the task of the software itself to detect at runtime
<infinity> raster: Exactly.
<raster> most of that is in in either gfx/video/audio
<raster> and the specific apps and/or libs already "compile all possibilities in" and auto-detect at runtime
<infinity> Like the canonical examples of ffmpeg/libav, libjpeg-turbo, and mplayer.
<raster> eg they probe for mmx/sse/sse3/4 or neon etc.
<infinity> Which all do lovely autodetection these days.
<raster> and they enable specific optimized codepaths for that
<wookey> youre' not telling me anything I don;t already know
<raster> they COULd recompile the same C code into multiple .o's and link them in with differingt entry symbols
<raster> and pick the appropriate one based on detected cpu arch. this generally tho is a much lower gain than the hand-crafted simd asm they carry and detect for.
<raster> then why does the PACKAGE SYSTEM need to have anything to do with this?
<raster> if u already know it?
<raster> and already know that its solved within the code of libs/binaries?
<doko_> you still can use hwcap for these cases
<wookey> a few binaries do this - the great majority don't.
<infinity> wookey: The vast majority don't need to.
<raster> i just wish unxi had a better way to detect instrset caps than "try some code and see if u SIGILL" (/proc/cpuinfo is not portable)
<wookey> agreed.
<raster> then whats the point here?
<wookey> but if we added simple hwcaps info then peope could if they wanted
<raster> if those that need to (ie have a decent gain) do it already.. why does the pkgssystem need to bother?
<wookey> just to save people from installing binaries they can;t run
<raster> this should never be done at pkgs install time
<raster> its horrible
<wookey> e.g v7 on v5 hardware
<infinity> And we're back to square one. Why would they be installing a distro they can't run? :P
<wookey> why is it 'horrible'
<raster> it is ASSUMINg the ultimate target system is the same one that is doing the installing now
<wookey> raster: read the backlog :-)
<raster> thats a horrid assumption i KNOw breaks continually
<infinity> raster: You're making all my same arguments for me again. :)
<wookey> I don't thin kthis conversation is getting anyone anwyhere
<raster> things like scratchbox, OBS, making debootstrap chroots etc...
<infinity> Which is great, I can just tag you in and go have dinner.
<raster> heheheh
<raster> :)
<raster> tbh... pkg installation should be not much more than "unpack files"
<twb> http://paste.debian.net/232365/ did I get everything right?
<raster> anything more than that (other than handling dependencies) is a workaround broken software :)
<wookey> it could be  'unpack best avaialble files'
<raster> it shoudl just ship all possible needed files and choose at runtime
<infinity> twb: Except for the "Ubuntu armel is supported" bit.  It's not a supported arch in 12.04 or 12.10.  Not in any official capacity.
<raster> and that choice is in the hands of the sw devs to deal with
<raster> not packaging
<twb> infinity: thanks
<wookey> but every package does actually _have_ a specified ISA
<wookey> we just don;t write down what it is in the packages
<infinity> twb: Also, the SATA comment is out-of-date WRT many modern SoCs.
<infinity> twb: Lots of A15s have native SATA, and some A9 packages do.
<twb> OK
<infinity> twb: And some clever setups, like the Trimslice, use PCIe SATA on a native PCIe port.
<infinity> wookey: If we specify the baseline ISA for the distro, we don't need it encoded at the packaging level and muddied up.
<infinity> (Now, what we define and what gets spit out of the other end of people's broken Makefiles is another story, but that's no different in your world, and those are just bugs that need fixing)
<wookey> do libc6 and libc6-686 have the same baseline ISA?
<wookey> how does dpkg currently choose the best one?
<infinity> wookey: dpkg doesn't, you do.
<infinity> wookey: There's not mutually exclusive, you can install both.
<wookey> right but I'm a clueless newbie - how should I know?
<infinity> wookey: They use ld.so hwcaps.
<infinity> wookey: We tend to just install both for you, to be fair. :P
<infinity> wookey: The only reason it's two packages instead of one (like, say, libssl which ships several libs in one package) is for size reasons.
<infinity> For people who really, really only want the baseline one and want a tiny system.
<infinity> The only way to be remotely user-friendly and have portable roots is to ship code that works everywhere and optimised at runtime.
<infinity> s/optimised/optimises/
<infinity> Rebuilding the distro 9 times for 9 different hwcap combinations also turns into a debugging nightmare.
<wookey> right. but we probably wouldn't do 9
<infinity> If you isolate that to just a few select binaries with maintainers who actually care about the optimisations, they can also care about debugging the weirdness.
<infinity> wookey: Who's "we"?  If you gave this option to i386 users a decade ago, we'd have 386/486/486+(that insn I cant remember the name of)/586/686/686+cmov/686+3dnow123/686+sse123/etc by now.
<infinity> wookey: Every new fancy, people would want an optimised build "just cause".
<raster> -funroll-loops
<raster> wewt
<infinity> Even if, half the time, the auto-vectorisation and other bits are so mediocre that any gains you might have gotten are lost elsewhere and it's a wash. :P
<raster> auto-vectorization candiates are mostly handled by hand-crafted asm anyway
<infinity> As well they should be.
<infinity> And once you're hand-crafting, runtime detection is, like, two extra instructions.
<infinity> So, don't be a lazy git.
<infinity> It's a shame that hwcaps isn't portable outside the GNU world.
<infinity> Cause "you can just ask glibc" is also quite nice.
<wookey> well distros get to choose how many falvours are worth supporting
<wookey> but without this labelling you can only support one ISA flavour per ABI
<wookey> yes that mostly works
<wookey> but it's not hard to imagine a world where it might be reasonable to have 2
<wookey> hmm. I only came here to say that I'd build a libc, not to have a half-hour argument :-)
<wookey> hmm. hour in fact
<wookey> at least one of us is very argumentative :-)
<infinity> I blame you. :)
<infinity> And yeah, I know cross-base works now, I tested it before I committed the glibc fix.
<infinity> It'll all get uploaded soon, but the buildds are currently having heart attacks.
<infinity> So, I think I'll watch a movie, then do uploads. :P
<infinity> wookey: You should be in bed, young man.
<wookey> yeah it's getting that way. I'll just kick off another perl build before giving up for the night
<wookey> getting it to cross _and_ multiarch is proving to be annoying
<doko_> young?
<infinity> doko_: Compared to you, I'm sure he is.
<doko_> hmm, he doesn't look so
<infinity> Doesn't he?  He looks like the sort who probably started balding at 17.
<infinity> He probably also hates it when people talk about him in the third person when he's right here.
<wookey> I beat a young man at squash today
<wookey> his age is about the same as number of years since I last played...
<wookey> fortunatey he was rubbish at it...
<wookey> infinity: want to guess how old I am ? :-)
<infinity> wookey: My guess is "younger than doko".  But that's a wide range.  He remembers WWII.
<dholbach> good morning
<ogra_> xnox, awesome fix for usb-creator !!!
<xnox> ogra_: not my idea ;-) but i'll take the credit for uploading.
<ogra_> heh
<janimo> ogra_, xnox does usb-creator start when a nexus is plugged in?
<xnox> janimo: or package upgraded.
<xnox> (the latter is a bug currently)
<ogra_> yes, and in on other occasions :)
<ogra_> -in
 * xnox should fix it otherwise i'll be pinged about it all day long.
<ogra_> haha
<janimo> I was just wondering that for many users it may be just another android device they want to exchange files with and not necessarily flash ubuntu on
<xnox> janimo: it checks for nexus7 only. and i was thinking to also check if fastboot detects it.
<janimo> right, nexus7 only.
<xnox> but yeah, it shouldn't popup unless nexus7 is in the fastboot bootloader mode.
<janimo> ok, so no surprises for people who don't know what bootloader mode is
<doko> ogra_, is there no 3.8 kernel for the panda board?
<ogra_> doko, ask ppsati ... iirc he works on devicetree support in our main kernel to make pandas work ... but thats not done yet
<ogra_> (and will stand and fall with support for the binary driver)
<ogra_> the current images are still on the quantal kernel until thats done
<sveinse> After debugging for a day of the failing initramfs script I've found that umount a loopback device in initramfs, leaves the losetup device bound to the target file. Shouldn't umount handle losetup -d itself? It certainly did so for binding/finding an available loop device
<prpplague> if anyone is interested i have two brand new phytec omap4 kits for sale as well as a lightly used snowball board - give me a ping if you are interested
#ubuntu-arm 2013-02-08
<LisaNori1> Curious, I keep reading about ubuntu for smartphones "coming soon", but don't bugs such as #1068994 (button 1 gets stuck) and #1091663 (3G nonfunctional) kinda hamper this?  Or are these only a problem on a nexus7 and not on nexus4?
<infinity> LisaNori1: "soon" isn't tomorrow.
<infinity> LisaNori1: http://blogs.wsj.com/cio/2013/02/06/ubuntu-smartphone-shipping-in-october/
<infinity> LisaNori1: But, also, some of those bugs don't apply to the phone product, no.
<LisaNori1> I understand.  I was just curious and trying to clarify my understanding.
<reb> I have an ARM Chromebook running Ubuntu 12.04.  "apt-get install compizconfig-settings-manager" does not work.  What are my options?
<reb> I'm interested in the settings manager in order to turn off the behavior of the "search" key on my Chromebook keyboard.
<reb> Possibly I just need some xmodmap magic.
<infinity> Are you even sure you're running unity-3d?
<infinity> If you have no binary 3d drivers, you're probably not.
<infinity> Which means you're not using compiz.
<infinity> Which means the regular old gnome keyboar control panel will probably fix you up.
<infinity> Or xmodmap, yes.
<ptl> is this the new samsung chromebook with ARM A15?
<infinity> I assume that's what's being referred to, yes.
<infinity> And we don't have 3d drivers for it, that I know of.
<infinity> So, it's likely not running compiz. :P
<ashes> i'd like to be able to plug my laptop in to my arm box with usb, and have the arm box show up as a hdd, like tablets and phones do. what do i need to read about?
<swjh> where is the kernel .config file on ubuntu-server 12.04?
<dholbach> good morning
<tripelb> <woman with nexus7 seeks Ubuntu dual boot for pleasure and learning. Any race creed or age.
<dholbach> tripelb, https://wiki.ubuntu.com/Nexus7/Installation#Having_both_Android_and_Ubuntu_installed_for_dual_boot
<ogra_> bug #1109197
<ubot2> Launchpad bug 1109197 in ac100-tarball-installer (Ubuntu) "fails to preserve mtimes" [Undecided,Fix released] https://launchpad.net/bugs/1109197
 * xnox ponders about fastboot in main
<ppisati> robclark: hi, back then you pointed me to some patches to make the pvr-omap module work with upstream kernel
<ppisati> robclark: do you know if 1) 3.8/3.9 + your patches will work?
<ppisati> robclark: 2) can you remind me where those patches are (can't find it right now)
<lupus_> how far ubuntu arm is from running on samsung and nexus tablets?
<ogra_> we have an image for the nexus7
<ogra_> no samsung not nx10
<lupus_> :/
<lupus_> Samsung note 10.1 here... would love to run ubuntu on this beast
<ogra_> well, we kind of rely on having an unlockable fastboot on the device
<ogra_> which binds us to nexus and probably asus atm
<lupus_> yeah
<ogra_> additionally you need working GLES Xorg drivers ....
<lupus_> How well the nexus 7 works?
<ogra_> mali doesnt have any that are licensed in a way we could distribute ...
<ogra_> well, unity isnt a tablet UI at all ...
<ogra_> beyond that fact it works quite well i'd say
<shadeslayer> there's a meeting going on about that right now isn't there?
<ogra_> yes
<ogra_> in #ubuntu-meeting
<ogra_> every friday at this time
<shadeslayer> and I pretty much forget every friday :(
<lupus_> well ill hope that linux would hit arm cpus, really like these silent machines
<ogra_> ubuntu runs on arm machines since several years :)
<ogra_> just not on many enduser devices yet, we're just starting with the nexus7
<lupus_> yeah but like all of them, tablets etc :)
<lupus_> heh
<shadeslayer> without unlocked bootloaders and GPU drivers, that will be hard
<ogra_> right, it ios limited to usable HW
<shadeslayer> there's another tablet that I've heard about, the Archos 101XS Gen 10
<lupus_> i had huge troubles with acer s3-931 laptop, uefi and ubuntu.. hate that new uefi boot
<shadeslayer> has an OMAP 4470 SoC ... and has linux GPU drivers
<robclark> ppisati, I think ndec would know if there is some activity for pvr, etc, on 3.8..
<robclark> shadeslayer, 4470 has android support.. not so much linux support tho, unfortunately.. a pity b/c x11 would do well with the 2d core
<ppisati> ndec: ^
<ppisati> ndec2: ^
<lupus_> hey, does the arm version of ubuntu have the same features than normal ubuntu?
<shadeslayer> lupus_: mostly, there's loads of stuff that doesn't compile with GLES so it's disabled
<ppisati> robclark: in the mean time, can you remind me where those patches are?
<shadeslayer> well .. maybe 'loads' is the wrong word here
<lupus_> android lacks real multitasking, so thats the main reason why i would love to have ubuntu on tablet
<robclark> ppisati, on dev.omapzoom.org, there should be a ubuntu kernel tree.. look for the 1488 (iirc) branch.. that should be close enough to get started
 * robclark just heading out the door
<ogra_> xnox, well, the spike persists quite long
<ogra_> but anacron is indeed a good guess
 * ogra_ didnt think about that before
<ogra_> i was suspecting apport or whoosie ... but then i couldnt see any spiking when watching them
<xnox> ogra_: apt-xapian can take a while on arm ;-)
<ogra_> *whoopsie
<ogra_> xnox, do we run it on every boot ?
<ogra_> i thought thats only run at install time
<xnox> well after the initial flash it is your first boot ever so I expect everything to run.
<xnox> ah true, it is at install time.... unless timestamps are off =/
<ogra_> right
<ogra_> for me it happens on every boot
<ogra_> the desktop is fine after a few minutes ... but initially it spikes to 600M
<ppisati> robclark: ok, should be this one - https://github.com/robclark/kernel-omap4/commits/pvr
<ppisati> iirc
<shadeslayer> robclark: oh
<shadeslayer> robclark: from what I was told ( and from what I see on gitorious ) the kernel works fine
<shadeslayer> https://gitorious.org/archos/archos-gpl-gen10/blobs/master/Readme.txt && https://gitorious.org/archos/archos-gpl-gen9-kernel
<shadeslayer> anyway, arm stuff is so fiddly :(
<hrw> shadeslayer: problem with kernels for arm devices is that most of them totally ignore mainline.
<robclark> shadeslayer, yeah, kernel should work fine for *android*.. getting it working w/ linux and gfx accel, etc, will probably not be straightforward
<ptl> any of you guys know why I can't write on my MTD recovery partition without byte differences? I tried dd, flash_image and even tried a statically-compiled ddrescue to write it!!! log here: http://pastebin.com/xhRDazn8
#ubuntu-arm 2013-02-09
<blk_jack> Does anybody know a workaround for the plymouth error on boot?
<ogra_> plymouth error ?
<blk_jack> I've tried adding overrides and deleting the init files but it still crashes and I can't boot
<ogra_> what HW is that on ?
<blk_jack> It's on the Ubuntu launchpad, but the device is the new samsung chromebook
<blk_jack> The bug is reported on the launchpad, I mean
<ogra_> get the source for ac100 tarball installer ... look at the postinst
<ogra_> it adds a bunch of diversions ... apply them
<ogra_> once thats dont add FRAMEBUFFER=True to your intramfs.conf ... then rebuild your intramfs and it should work
<ogra_> s/dont/done/
<ogra_> hmm, even though, on the chromebook you could probably get through without the diversions
<blk_jack> Well right now I'm effectively locked out
<blk_jack> It doesn't boot
<ogra_> can you change the kernel cmdline ?
<ogra_> if so, add break=bottom ... boot and then exit with ctrl-d from the initramfs shell
<ogra_> it should boot normally that way
<blk_jack> I'd need to build a new kernel to do this right?
<ogra_> no, you need  access to the bootloader for this
<ogra_> or to the bootloader config
<wookey> ogra_: is this the general runes for how to boot with plymouth missing?
<wookey> I could really use this info...
<blk_jack> The chromebook bootloader is signed and locked
<ogra_> wookey, the general rules is: make console-setup run in your initrd and plymouth will work
<wookey> ogra_: my problem is building plymouth...
<wookey> it'd be nice to test the system without having to do that
<ogra_> well, mountall kind of relies on libplymouth for user interaction
<wookey> OK, so the short version is 'it's hard'
<ogra_> if you can make sure to suppress all filesystem checks and boot with rw on the cmdline it should work
<wookey> in which case building it should be OK if I can just remove the X build-dep
<ogra_> but will complain
<blk_jack> For some reason I thought 13.04 fixed this issue
<blk_jack> Apparently not
<ogra_> no, its still being researched
<ogra_> its a race condition ... a tricky one
 * ogra_ notes its kind of late and goes to bed
<blk_jack> Bleh
<blk_jack> Hard to believe there's no decently documented workaround for this issue
<infinity> wookey / cjwatson: arm64-cross-toolchain-base is up to date again, enjoy.
 * ogra_ grumbles ... seems one sick cat isnt enough ...
<shadeslayer> robclark , hrw oh ... okay
<shadeslayer> then I'm back to square one basically
<shadeslayer> can't find compatible hardware that I can play with
<shadeslayer> or the ones that are compatible are ETOOEXPESIVE
<shadeslayer> *EXPENSIVE
<bruvik> hello, I have a question about the /debian/* files in a source directory
<bruvik> is it possible to manually install them if I compiled the program and installed it manually or do i have to build a deb package?
<Gaga> Hello, I have a few newbie questions. 1. Please tell me is there any differance between Ubuntu x86 and ARM root filesystem?
<Gaga> Differance in source
#ubuntu-arm 2013-02-10
<jdsa> I have an arm cpu question: http://www.ti.com/lit/ug/spruf98x/spruf98x.pdf page 2614: OVF_Rate = (0xFFFF FFFF - GPTn.TLDR + 1) * (timer-functional clock period) * PS table16-11 the example for TLDR=0xFFFF FFF0 and PS=1 is equal to 524 Î¼s. however, (0xFFFF FFFF - 0xFFFF FFF0 + 1) * (1/32768) * 1 = 488 Î¼s
<jdsa> can anyone explain why I calculate the value different than the TRM?
<wookey> infinity: toolchain seems to basically work, but for some reason gpm fails to build.
<wookey> hmm same failure for native build. Maybe it just doesn't like 2.17
<wookey> Does it build for you?
<wookey> I'm getting http://people.linaro.org/~wookey/buildd/raring-arm64/gpm_1.20.4-6-raring-arm64-20130210-0142.log with a lot of warnings, then missing major()
<wookey> aha. OE people have fixed it: http://patches.openembedded.org/patch/42449/
<wookey> ok, that does the trick
<infinity> I suspect that's the "wrong" fix, but it works for now.
<wookey> is there a list of 2.17 changes that may break things like this?
<infinity> This is the only one I've run into so far.  And yeah, actually, that may be the right fix for gpm.
<infinity> Looks like they were relying on fcntl.h misatkenly including sys/types.h, which it shouldn't.
<infinity> Of course, you can also get sys/types.h for free with enabling some system extensions.
<infinity> Since stdlib.h has this:
<infinity> #if defined __USE_SVID || defined __USE_XOPEN_EXTENDED || defined __USE_BSD
<infinity> # include <sys/types.h> /* we need int32_t... */
<infinity> wookey: Anyhow, uploading the fix to Ubuntu now, and submitting to Debian.
<wookey> Ah OK. I'll not file this patch then
<wookey> cheers
<infinity> Guess it's about time for another rebuild test in Ubuntu.
<infinity> I know of one other case of "I included fcntl.h, but I actually meant sys/types", but I don't know how rampant it is.
<wookey> do you recall which package?
<infinity> alsa-lib
<infinity> (Which ends up manifesting in a cascaded fashion to many things that build-dep on libasound-dev, since the alsa headers have the broken assumption)
<infinity> I should probably fix that right now too.
<infinity> I might consider reverting the fcntl.h thing in glibc for a short while, but this is a case of "upstream is right, sucks to be lazy programmers who need to fix things", so maybe just a rebuild test and some whackamole is the better option.
<wookey> I guess so. It's just annoying for me when unrelated breakage comes and breaks everything
<infinity> Ooo, even more evil, alsa-lib itself doesn't FTBFS, cause it doesn't use the broken header, it just exports it.
<wookey> I have enough related breakage to be going on with
<infinity> That's so much fail.
<wookey> lovely
<infinity> (Well, or it uses it, but everything in the alsa sources that includes the broken header also includes sys/types, which is likely)
<wookey> My vision of running through big long list just rebuilding everything has so far been thwarted thoroughly by new libc, new linux headers, new libgcc
<wookey> and staging fixes I forgot to upload source for
<wookey> BTW you didn;t include my stage2 patch in eglibc. I'll file a bug to stop it getting dropped
<wookey> 1-liner
<infinity> I didn't include it because I'm looking at rewriting the whole stage mess.
<infinity> You'd note that your stage2 patch introduces the *only* case of stage2 anywhere in the source.
<infinity> Which seems a bit odd.
<infinity> And, of course, the cross-base packages have a whole different set of staged build patches.
<infinity> So, yeah.
<infinity> I want to reconcile it all, tear it all out, put it back in with something less confusing, and make sure it works for everyone's (apparently different) bootstrap methods.
<infinity> The glibc/gcc interdependence makes them a bit weirder to really sort out how to codify this in a way that makes sense without a README anyway.
<infinity> Given that a stage1 (or a stage0, really) of glibc doesn't actually produce a library. :P
<infinity> Just a useless stub.
<infinity> I'm also considering pushing the interdependant stageN stuff to glibc and gcc upstream.
<infinity> So you can just (cd gcc && ./configure stage0 && make) && (cd glibc && ./configure stage0 && make) and then repeat for stage1, and have a functional pair.
<infinity> (Any attempts to do otherwise is a useless waste of time, since they need stubs from each other to build)
<wookey> OK fair enough. I agree it needs a good sort out.
<wookey> The staging stuff in there isn;t actually broken. the tooclahin-cross-base packge and -source packages thing is a horrible hack that should die though
<wookey> Or maybe it can hang around as a convenince wrapper
<infinity> Well, some sort of wrapper will always be needed for people who want an automated way to bootstrap a toolchain from scratch.
<infinity> But once you have a toolchain and you're crossing/rebuilding (like you're doing), yeah, that can be done entirely in the package, and I agree glibc's needs a tiny bit of fixing.
<infinity> But, like I said, the fixing looks more like a rewrite, cause half the code is unused, and other half if only right by accident. :P
<wookey> It should work as in http://wiki.debian.org/MultiarchCrossToolchains
<wookey> We need to fix the DEB_TARGET_ARCH=foo bit for consistency too. I've filed a few bugs about that
<wookey> and done most of the work of adding it to dpkg-buildpackage
<wookey> so you can do dpkg-buildpackage --target-arch foo
<wookey> (sadly it has two other sorts of 'target' options already, but that's life).
<infinity> I think I questioned before how much this really needs to be in dpkg, but I don't much care either.
<wookey> This reduced the process cross-toolchain base does to 7 dpkg-buildpackage calls
<infinity> I mean, once you have a toolchain, everything after that is just build/host crossing.
<infinity> Special-casing just for the target toolchain build seems like a lot of engineering.
<wookey> It's no erngineering. everything is already there in the sources
<infinity> Also, there's the part where this assumes buildds will/should be multiarch enabled in the distro, and I'm still unconvinced that's a good idea.
<wookey> It just has different names in differnt packages and dpkg-builpackage ismissing an option for it
<wookey> sbuild is multiarch enabled already, and buildds use sbuild, (don't they?) So it's already done in engineering terms
<infinity> No, I mean, I'm not convinced buildds should be *allowed* to have/use cross-arch build-deps in the official archive.
<infinity> I'm perfectly happy with sbuild doing this for out-of-archive bootstrap purposes, and it's quite handy (and I've even submitted patches to make it less crap).
<wookey> You have to for cross compilers (unless we want to carry on with the libc-arch-cross bodgery
<wookey> (and the libc transition showed why that's a bad plan)
<infinity> That's not technically true.
<infinity> We could do the n-stage bootstrap and then just throw away the results and depend on libc6-dev:otherarch.
<wookey> I had stuff not building because the toolchain carefully used the 2.16 lib it had in libc-arm64-cross instead of the 2.17 installed as libc:arm64
<wookey> OK, true
<infinity> Which I might figure out how to do a bit later.
<infinity> Since that's still an improvement on the road to what you want.
<wookey> now we have multiarch, why not use it?
<infinity> (In that the cross toolchain would now only look at M-A paths, and none of the cross madness)
<wookey> Yes that would indeed be a step in the right direction
<infinity> I guess I just see "bootstrapping a toolchain" as a rather different use-case than most other M-A stuff.
<infinity> And not something people other than the toolchain maintainers should have to deal with, really.
<infinity> It's not like "normal users" (or even normal developers) build native GCC all the time.
<wookey> It is, but now we have the tech I don;t see why we shouldn't use it
<wookey> No, but the native toolchain build is expected to work
<wookey> seems to me the cross one should too
<infinity> Because allowing foreign arch build-deps opens a lot of other cans of worms we need to think about very carefully.
<wookey> Yes, that's fair enough.
<infinity> I'd so far been very careful about explicitly turning OFF foreign arches on our buildds. :P
<wookey> We can afford to be strict about what is accepted
<infinity> (briefly, the amd64 chroot had i386 enabled too, and this did actually cause curious issues when there was arch skew in the archive)
<wookey> but for cross-toolchians foreign-arch deps are definitely reasonable, I would say 'correct'.
<wookey> skew is a problem...
<infinity> Deps, yes.  But we can skip the build-deps part with my above deal.
<wookey> butmostly for new arches
<infinity> Anyhow, I need to run.  Movie date calls.
<wookey> OK. cheers for help
<infinity> No, skew is a problem on every single upload of.. Anything.
<wookey> bedtime here
<infinity> If you have a foreign arch enabled and one of your build-deps builds on the foreign arch before the native one, and that satisfies (technically) the MA build-dep rules, you no longer build in a self-contained arch, you pull in the foreign one.
<infinity> And that's all meant to "work" anyway, but it also means our arches aren't guaranteed self-contained anymore.
<infinity> Or self-hosting.
<ogra_> hrw, http://paste.ubuntu.com/1632851/ chromebook ambient light sensor control
<ogra_> (eats a bit of battery due to polling though)
<mosasaur> where is build-arm-chroot?
<mosasaur> I mean the script
<mosasaur> ah found it: http://packages.ubuntu.com/lucid/i386/qemu-kvm-extras-static/filelist
<ogra_> oh, nice, flash is fully working on my chromebook as long as i dont use any compositor
<tassadar_> like adobe flash?
<tassadar_> or you mean the one built-in chrome?
<ogra_> no, i mean the one that i copied from the chromeos partition to ubuntu
<ogra_> running eith the ubuntu vhromium browser
<ogra_> *chromum
<tassadar_> hm, nice)
<ogra_> bah
<hrw> ogra_: run chromium browser with "--with-gl=egl" (or s/with/use/) ;)
<ogra_> well, better add it to the chromium defaults proper :) but yeah
<ogra_> see /etc/chromium-browser/default
<Vic> Trying to cross-compile an arm kernel on an x86_64 ubuntu 12.10, but get this error: dpkg-architecture: warning: specified GNU system type arm-linux-gnueabihf does not match gcc system type x86_64-linux-gnu
<Vic> Can someone help?
<hrw> Vic: ignore warning
<Vic> Trying to cross-compile an arm kernel on an x86_64 ubuntu 12.10, but get this error: dpkg-architecture: warning: specified GNU system type arm-linux-gnueabihf does not match gcc system type x86_64-linux-gnu
<fly[ac100]> http://dpaste.org/g1Z5T/
<fly[ac100]> how could it be?
<infinity> Weren't those libraries supposed to get proper SO versioning at some point?
<mdz> trying to build a package on armhf, and clang seems to be broken: it tries to execute a command "" (empty string) as in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659481
<ubot2> Debian bug 659481 in llvm-3.0 "unable to execute command: No such file or directory" [Grave,Open]
<mdz> anyone seen this?
<mdz> (precise)
<mdz> trying to compile a hello world has the same problem
<mdz> aha, mounting /proc fixes it
<mdz> in the chroot
#ubuntu-arm 2014-02-05
<snkt> can anyone help how to customize lxde start main menu...  I want to hide "Run" in start menu
<snkt> also right click options customizations
#ubuntu-arm 2014-02-07
<arg> ubuntu saucy 13.10 armhf/arm64 not creating dev nodes
<infinity> Certainly does for me.
<arg> systemd-udevd is not creating /dev nodes. I have a few udev rules in /etc/udev/rules.d. But doesn't seem to create a dev nodes for those rules
<cooloney> infinity: hey, thanks for helping here, arg is my colleague, we met some issue about creating dev nodes for ubuntu arm
<infinity> cooloney: It functions literally identically to x86.  Any variation would be either a kernel bug or badly-written rules.
<infinity> (And I have both armhf and arm64 saucy/trusty machines where I can confirm it's working as it should)
<arg> The same rules work for 12.04, 13.04 versions. Only for 13.10 I see this issue. Also, using the same kernel for both 13.04 and 13.10. works fine for 13.04 but not 13.10. So i guess its not the kernel issue or the issue with rules.
<arg> One main difference I see between these 2 rootfs versions is - /sbin/udevd used in 13.04 and /lib/systemd/systemd-udevd in 13.10 init scripts.
<infinity> arg: Yeah, it got renamed when it became part of the systemd source.
<infinity> Though, there's a symlink from /sbin/udevd
#ubuntu-arm 2014-02-09
<hvn2> Hi, I've built a kernel on Ubuntu 12.04 using make-kpkg for ARMv7 armhf with omap3, but the target tells the kernel is not omap architecture. How can I make sure the kernel is built for omap3, apart from configuring the kernel as such ? I already used --subarch=armhf and tried  --subarch=omap3
<sre-su1> Hi! How can I use pygtk on ubuntu-arm?
<grant__> Will any ARM boards play 1080p smoothly with open-source video drivers?
<hrw> grant__: allwinner ones will
<hrw> grant__: during devconf.cz I saw A10 playing 1080p video with audio
<grant__> hrw: which video drivers do they use?
#ubuntu-arm 2015-02-02
<onla> http://pastebin.com/raw.php?i=v0LVywBi
<onla> new Pi
<onla> http://www.theregister.co.uk/2015/02/02/raspberry_pi_model_2/
<ogra_> https://plus.google.com/116812394236590806058/posts/ZdPvVKc7TBj
<ogra_> snappy port is underway
#ubuntu-arm 2015-02-03
<rangergord> hi
<rangergord> is Ubuntu for ARM identical, from a user (developer running his apps on Ubuntu) perspective? Like are all the libraries in the repo the same, is the behavior when segfaulting/whatever the same, as x86?
<rangergord> or is it more like WinRT is to Windows 8?
<ogra_> rangergord, nearly all packages in the archive are available for armhf ((some esoteric ones like freepascal have never been ported i think)
<ogra_> the behavior migh not be the same since it is a adifferent architecture
#ubuntu-arm 2015-02-05
<hanwentao> anyone installed ubuntu 14.04 on apm x-c1 mustang board?
<hanwentao> i successfully installed following https://wiki.ubuntu.com/ARM/Server/Install/Mustang, but the kernel panicked after reboot
<bunty> HI everyone actually i am looking for ubuntu rootfs on rcn website http://rcn-ee.net/deb/rootfs/quantal/ but its showing error on my server if anyone have please reply, i want it bad
<k1l_> quantal is quite old and not supported anymore. see http://rcn-ee.net/deb/rootfs/  what could be offered
<Parduz> Good morning. I'm a linux newb that needs support about cross-compiling a wxWidgets app for a Beaglebone Black running Debian. I'm using a Ubuntu 14.10 virtual machine to build the wxWidgets libraries but i really need some help. Right now the "configure" commands fails 'cause can't see the GTK libs... but i'm not sure if it is a "true error" or just me not giving the right options. Any help?
<Parduz> Also, some expert from the #beagle channel mentione "multiarch" and sent me here to get help.
<bunty> <kIl_> thanks checking it .
<Parduz> Good morning. I'm a linux newb that needs support about cross-compiling a wxWidgets app for a Beaglebone Black running Debian. I'm using a Ubuntu 14.10 virtual machine to build the wxWidgets libraries but i really need some help. Right now the "configure" commands fails 'cause can't see the GTK libs... but i'm not sure if it is a "true error" or just me not giving the right options. Any help?
<rbasak> Why cross compile at all? Won't it build directly on the Beaglebone?
<Parduz> 'cause compiling on the BBB would be so long, i guess
<Parduz> and requires to have the sources there. I would like to drop the compiled app on the BBB
#ubuntu-arm 2015-02-06
<bunty> HI i want a fully stable ubuntu distro for bbb any sugesstion's
<bunty> I installed one from rcn-ee.net/dev/rootsf but it's dont have any dtb
<superstep> Hello, I want to know how in QtCreatr/UbuntuSDK as you specify the path of qmake to use, i would use one compiled by me for ARMv7
<bunty> anyone there who have installed ubuntu into his/her bbb permanently ??
<jon1012> hi
<jon1012> has someone worked on making ubuntu arm work on Raspberry Pi 2 ?
<genii> I realize it's MIPS and not ARM, but has anyone tinkered yet with the Imagination MIPS Creator CI20 ?
<genii> Specs are here: http://www.elinux.org/CI20_Hardware#Tech_Spec_overview
#ubuntu-arm 2015-02-07
<mach20x> Has there been any work on making a commit for an ARM version of ubuntu to come predefined with a mesh networking protocol, or setup?
<HiDeHo> Hi all anyon earound atm
<HiDeHo> i am on a ubuntu arm os
<HiDeHo> wanting to install a few more apps
<HiDeHo> i dont see a wine meta package available in the repos what other wine stuff do i need
#ubuntu-arm 2016-02-10
<kl326> Hi, how can I get kernel 4.2 on ubuntu mate 15.10 on ras pi?
#ubuntu-arm 2017-02-07
<pvl1> is it safe to ad debian sid repo to ubuntu 12.04 on arm
<k1l> safe? i would say no
<pvl1> uh oh
<pvl1> well what about replacing precise with trusty then
#ubuntu-arm 2017-02-09
<dgm78> Hi! How can I install old PHP version 5.3 in Ubuntu ARM Xenial?
<dgm78> Hi! How can I install old PHP version 5.3 in Ubuntu ARM Xenial?
<ogra_> i dont think 5.x exists in the xenial archive (for any arch, not just ARM) http://de2.php.net/archive/2014.php#id2014-08-14-1
<dgm78> ogra_: thanks
#ubuntu-arm 2017-02-11
<Zoom> Does anyone have any experience cross-compiling packages for arm from a regular ubuntu here?
<Zoom> I'v installed gcc-arm-linux-gnueabi and downloaded the source for the package. But I get the Unmet Dependencies error when compiling, so I tried 'apt-get build-dep -a armhf MYLIB' but it says the dependencies "are not installable"
<Zoom> How to get those dependencies for cross-compilation?
<Zoom> At least, may be there are any QEMU images that I can boot up and compile a package quickly from a VM?
#ubuntu-arm 2017-02-12
<daffodil> does anyone know by chance how to install log4net on ubuntu-mate (running it on a raspberry pi)?  trying to build a smuxi server
<daffodil> wondering if it's hidden in some package name i can't find or something
<k1l> liblog4net1.2-cil   dldurk
<dldurk> wil try that thanks k1l
<dldurk> weird i already have that installed but this configure tells me i don't have it, odd
<dldurk> but i may have found another program to try
#ubuntu-arm 2018-02-05
<Epx998> anyplace I can get a perforce client for arm?
#ubuntu-arm 2018-02-09
<chron097CZQ> ââââââââââ  âââââââ   âââââââââââ   ââââââââââ âââââââââââââââ ââââ   ââââââââââââââââââââââââââââ    âââââââ âââââââ  âââââââ
<chron097CZQ> ââââââââââ  âââââââ   âââââââââââ   ââââââââââ âââââââââââââââ ââââ   ââââââââââââââââââââââââââââ    âââââââ âââââââ  âââââââ
<chron097CZQ> âââââââââââââââââââ   âââââââââââ   ââââââââââââââââââââââââââââââââ  ââââââââââââââââââââââââââââ   âââââââââââââââââââââââââ
<chron097CZQ> âââââââââââââââââââ   âââââââââââ   ââââââââââââââââââââââââââââââââ  ââââââââââââââââââââââââââââ   âââââââââââââââââââââââââ
<chron097CZQ> ââââââââââââââ        âââââââââââ   âââââââââââââââââ  ââââââââââââââ âââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ  ââââ
<chron097CZQ> ââââââââââââââ        âââââââââââ   âââââââââââââââââ  ââââââââââââââ âââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ  ââââ
<chron097CZQ> ââââââââââââââ        âââââââââââ   ââââââââââ ââââââ  ââââââââââââââââââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ   âââ
<chron097CZQ> ââââââââââââââ        âââââââââââ   ââââââââââ ââââââ  ââââââââââââââââââââââââ     âââ   ââââââââ   âââ   ââââââââââââââ   âââ
<meid> (_)                                               | |
<meid> (_)                                               | |
<meid> _ _ __ ___   ___ _   _ _ __   ___ _ __ _ __   ___| |_ ___   ___  _ __ __ _
<meid> _ _ __ ___   ___ _   _ _ __   ___ _ __ _ __   ___| |_ ___   ___  _ __ __ _
<meid> | | '__/ __| / __| | | | '_ \ / _ \ '__| '_ \ / _ \ __/ __| / _ \| '__/ _` |
<meid> | | '__/ __| / __| | | | '_ \ / _ \ '__| '_ \ / _ \ __/ __| / _ \| '__/ _` |
<meid> | | | | (__ _\__ \ |_| | |_) |  __/ |  | | | |  __/ |_\__ \| (_) | | | (_| |
<meid> | | | | (__ _\__ \ |_| | |_) |  __/ |  | | | |  __/ |_\__ \| (_) | | | (_| |
<meid> |_|_|  \___(_)___/\__,_| .__/ \___|_|  |_| |_|\___|\__|___(_)___/|_|  \__, |
<meid> |_|_|  \___(_)___/\__,_| .__/ \___|_|  |_| |_|\___|\__|___(_)___/|_|  \__, |
<meid> | |                                             __/ |
<meid> | |                                             __/ |
<meid> |_|                                            |___/
<meid> |_|                                            |___/
<meid> B e n G 8 3   A c e L a n   s t e n z e l   k a x i n g   c v a s i l a k   p e k k a r i   H e M a n   m o r p h i s _   s i e o g h i s u g f   r b a s a k   m i n g _ l e i   l o o l   m i c a h g   h g g d h   p o p e y   l v r p 1 6   g u e r b y   r e x x s t e r   L o n g y a n G   k 1 l   c h r i s c c o u l s o n   m a r i o g r i p   o g r a _   r o b h e r   n i s k a   T m _ T   t l b r _   m a n j o   a l a i   d r a g a n - s   y o f e l   N 
<meid> BenG83 AceLan stenzel kaxing cvasilak pekkari HeMan morphis_ sieoghisugf rbasak ming_lei lool micahg hggdh popey lvrp16 guerby rexxster LongyanG k1l chrisccoulson mariogrip ogra_ robher niska Tm_T tlbr_ manjo alai dragan-s yofel NCommander mrutland wgrant nslu2-log ChunkzZ doko funnel ubot9 y0sh nashpa ndec awafaa akaWolf Jack87 ubuntulog PaulePanter dannf flexiondotorg chihchun_afk steev rsalveti ColdKeyboard amrith fabo zumbi moon127 #ubuntu-arm
#ubuntu-arm 2020-02-05
<guysoft42> hey all, I am the creator of CustomPiOS, which lets you build custom distros using a base image. I can see the raspberrypi image of ubuntu is creating the ubuntu user and password on boot, with the password expried. And I want to change that. However, I get: chage: user 'ubuntu' does not exist in /etc/passwd . How do I find someone who knows how this works and how to edit settings for the ubuntu user before creation? I am running this by chrooting
<guysoft42> to the image and editing it with scripts.
<guysoft42> The reason I want to do that is that there is a systemd service that is not starting unless you log in
<guysoft42> Is there anybody here? I am not sure who to ask about this kind of stuff. It seems not to fall in to a bug, and its not a general question. its a dev thing
