#ubuntu-arm 2009-03-09
<DDevine> Greetings!
<DDevine> Who is interested in the SheevaPlug?
<persia_> DDevine, Lots of people.  Do you have one?
<DDevine> Not yet - just waiting on my pay-check.
<DDevine> I have started a SheevaPlug channel - #sheevaplug if you want to come chat or idle.
<persia> I'll wait until I get one.  I'd be interested to hear if anyone gets Ubuntu Server working on it though.
<Stskeeps> looks quite trivial to port onto
<DDevine> Yeah, I think they have already ported Ubuntu onto it.
<DDevine> So after that - server kernel should just be a few adjustments.
<Stskeeps> persia: the documentation has jaunty into NAND guide
<DDevine> Yeah, I havent actually read that yet so I didn't want to claim...
<DDevine> Thinking of getting one?
<persia> Oh, cool!
<Stskeeps> a couple of those as buildds could be interesting ;p
<DDevine> I'm looking at channeling some of the nslu2 guys into the sheevaplug scene.
<persia> Indeed, or just as a handy server for IRC presence, etc.
<DDevine> yeah, but that is boring.
<DDevine> You can do MUCH more.
<Stskeeps> i think this plug would actually be gf friendly
<persia> DDevine, I suspect you'll see a fair amount of shared interest...
<DDevine> Stskeeps: If you mean that it would not make them complain about the noise?
<Stskeeps> DDevine: for instance, but my gf is also cautious about power usage
<rabeeh> DDevine: join #openplug
<DDevine> Mine hates servers. She doesn't appreaciate the powerful roar. (and the power usage).
<persia> That's just the big servers.  There are little quiet ones too.
<Stskeeps> my personal worry is that i'll have to find some awkward plug converter though
<persia> Well, one hopes they will have similar devices for other markets.
<armin76> Stskeeps: awkward? a plug adapter is very common :P
<Stskeeps> well last time i had a proper american->dk plug adaptor it nearly torched a camping wagon :> but i guess i just need a good one
<DDevine> rabeeh: Thanks for the OpenPlug referral. I'm merging with them.
#ubuntu-arm 2009-03-10
<juliux> hi
<persia> Hey juliux
<juliux> if i try install ubuntu-desktop on a n800 i got this dependencies problems http://paste.ubuntuusers.de/394406/ my sources.list is http://paste.ubuntuusers.de/394407/
<juliux> i followed this howto http://www.internettablettalk.com/forums/showthread.php?s=3127852160d9e8ec0680bf3720e08e49&t=25975
<Stskeeps> mm, do be aware that that ubuntu howto is hardly actual ubuntu, so there might be weird interactions
<juliux> no problem
<juliux> it is just for testing not for productive use
<juliux> if it's broken it is broken;)
<persia> juliux, According to http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_probs.html it is broken today :(
<persia> It's been working before, and will probably be working again.
<Stskeeps> ah, nice page
 * Stskeeps bookmarks
<juliux> persia: thxs for the link
<juliux> persia: i just find my n800 right bevor cebit back and then it was original playya job to bring ubuntu on it;)
<persia> Check the LP page for anything that produces uninstallable binaries.  I suspect there's probably either version skew, or FTBFS going on.
<persia> If you had playya hacking it directly, it probably got it installed fairly sanely, so it's just archive skew that's hitting you.
<juliux> ok
<juliux> playya found his n810 so we will test it in the next weeks again and again;)
<persia> Mind you, if you're feeling sufficiently inclined to hunt down the reason for the failure, and submit patches ... :)
<juliux> i have ordered two extra sd cards today;)
 * persia needs to dig up some out-of-archive kernels, and install jaunty on more devices one of these days
<Stskeeps> juliux: if you need any assistance with ubuntu and such on the tablets feel free to prod me. b-man is mostly just integrating work done by me related to the mer project (we've had ubuntu/mojo since summer on the tablets but didn't want to have a seperate ubuntu distribution cos it would run into similar problems as with debian on tablets - not power saving enough :P)
<juliux> Stskeeps: good to know
<juliux> Stskeeps: i will wait until ubuntu-desktop is installable and then see what is working
<persia> juliux, While you're waiting, you might want to look at mer: it's got *lots* of patches that haven't gotten to Ubuntu yet.
<juliux> persia: what is mer?
<Stskeeps> http://wiki.maemo.org/Mer , currently playing with new UI implementation based on some of the U-M patches :)
<juliux> ok
<Stskeeps> ubuntu jaunty based
<persia> Personally, I suspect that many, if not most, of those patches will drop into karmic, but none of those who could upload had time to review all the Mer patches during jaunty.
<lool> juliux: Could be apport failing to build on armel
<lool> Unfortunately, a bunch of main packages failed to build on armel
<persia> lool, More than apport.  See the jaunty-probs report.
<lool> persia: There's more than apport failing, but I suspect it's causing the uninstallability because of arch: all/any deps
<lool> ANyway
<juliux> sorry for the stupid question but what is the menu/swap key on a n800?
<Stskeeps> the middle one below dpad
<juliux> Stskeeps: thxs
<juliux> Stskeeps: mer installations runs fine for me
<juliux> thxs for the cool install script
<Stskeeps> hehe, say thanks to b-man for that part :)
<juliux> ok
<juliux> Stskeeps: is there a special irc channel for mer?
<Stskeeps> juliux: we mostly hang out in #maemo and #mer
<juliux> ok
<NCommander> hey lool, I tested ubuntu-desktop on a fresh install twice, its not uninstallable for me
<NCommander> lool, I also have most of my patches to actually get RedBoot to build merged into bazaar repos (ecos's config tools need patching :-/)
#ubuntu-arm 2009-03-11
<perdidopunk> hey, does anyone know what port i need to connect my terminal emulator to to communicate with an ARMmite over USB in ubuntu?
<persia> juliux, ^^
<persia> perdidopunk, If the USB connection supports serial, you should get something like /dev/ttyUSB0
<perdidopunk> persia, thanks
<persia> If not, it's more complicated, and you might want to track it down in ARMite forums.
<perdidopunk> as soon as i asked the question, i had the idea to do a diff on /dev with the thing plugged in and unplugged; that's what i came up with
<perdidopunk> is tcl a good terminal emulator to use?
<persia> minicom is probably the most popular.  cutecom has some fans.  There's also gtkterm, and others.
<persia> Personally, I'd suggest minicom if you want it in a terminal window, cutecom if you want a GUI and you use a primarily QT environment, and gtkterm if you want a GUI and you use a primarily GTK environment.
<perdidopunk> alright, i've connected to my board with minicomm
<perdidopunk> i think i might have wiped it last time i did anything to it in windows
<perdidopunk> thanks for the advice btw
<perdidopunk> damn
<perdidopunk> the only site i can see on google that seems like it will be helpful to me is broken
<perdidopunk> hm, i wonder if i can put a shell on this thing so that i can at least tell if i'm communicating with it correctly
<perdidopunk> persia, ever use the gnuarm toolchain?
<perdidopunk> or anyone who'
<perdidopunk> *anyone who's reading
<persia> "use", yes, but not in the depth you need :)
<perdidopunk> hehe
<perdidopunk> i'm just wondering how the heck to write "hello world" and upload it to the device
<persia> Or maybe not, if you mean the www.gnuarm.com toolchain
<perdidopunk> i can't seem to find any resources on doing so with gcc and/or minicom
<perdidopunk> yeah, that's the one i was looking at
<persia> Oh, then no.
<perdidopunk> have you any experience with other archs that might be of relevance?
<persia> Ubuntu typically does native builds, and we typically either use real hardware or the qemu emulator to test things.
<perdidopunk> hm
<perdidopunk> by "real hardware" i assume you mean a physical ucontroller
<persia> I wouldn't run Ubuntu on a microcontroller: it's simply too big.
<perdidopunk> yeah, i'm not looking to, hehe
<perdidopunk> it's only 60mHz and has something like 32k of flash memory
<persia> Things like the beagleboard, the babbage, the nslu2, the n8x0, the Zaurus, etc. are more common hardware platforms in use.
<perdidopunk> maybe i'm in the wrong channel
<persia> For that hardware, probably.
<perdidopunk> i'm mostly just looking to tinker with using it for some simple control
<persia> Not that other people here might not be interested, but that our focus is on getting Ubuntu working smoothly on higher-end hardware.
<perdidopunk> maybe some LED's, little actuators, etc
<perdidopunk> ah, i landed in the wrong channel
<perdidopunk> do you have any idea where i should go for ucontroller help?
<persia> Unfortunately, I don't.  And don't worry about the channel: given your focus, it seems reasonable that this could have been about getting Ubuntu working with ARM microcontrollers.
<dave_m> Does anyone know if there are Jaunty install images for arm yet?
<lool> dave_m: There are but not for babbage yet
<lool> Actually the babbage images will be quite different
<dave_m> I understand this... but I'm wondering whether there is something more user-friendly than debootstrap at present
<lool> dave_m: There's a script to run debootstrap for you if you like
<dave_m> Can you give me a pointer?
<lool> https://wiki.ubuntu.com/ARM/RootfsFromScratch
<dave_m> Thanks
<ogra> note that kde currently has issues with that script
<ogra> (due to packagekit expecting some dbus services to be available that arent, not the scripts fault, kde people are working on fixing it)
<lool> ogra, NCommander: did one of you ever come across 322798
<ogra> bug 322798
<lool> FAIL
<ogra> (i want a bugbot !!!)
<ogra> no, hal runs fine here
<ogra> and thats reported against an old hal version
<ogra> we have git20090204-0ubuntu3 atm
<lool> dave_m: ^
<ogra> hald/linux/devices.c:leds_add() also sounds like kernel related
<lool> dave_m: Could you retest with latest hal?
<ogra> best to try with the live image
<lool> ogra: Well the bug is from January too
<ogra> right
<ogra> so it might be a) fixed upstream in hal and b) its not using the kernel we use
<dave_m> I will update hald... not that the crash was caused by deferencing a random pointer in usersapce, so the patch should be looked at anyway
<ogra> i'm intrested in getting it tested with latest hal and treh actual kernel we will release :)
<dave_m> I don't have the 2.6.28 kernel update for babbage yet, but I will try updating hal anyway.
<lool> dave_m: Sure, if the code path isn't hit with our kernel / new hal it will be of a lesser priority though
<dave_m> Sure
<ogra> dave_m, http://people.ubuntu.com/~ogra/arm/babbage/
<lool> dave_m: We have built a babbage kernel today in the archive now
<lool> dave_m: You should see it if you upgrade now, but it wont install to flash or SD at the moment
<ogra> the README says that :)
<armin76> whats a babbage board?
<lool> armin76: An iMX51 SoC
<lool> For development
<armin76> i want one :P
<armin76> dave_m: can i get an armv7 board for gentoo? :)
<lool> armin76: Hmm you're aware that you're on #*ubuntu*-arm right?  :-)
<armin76> lool: yup
<dave_m> armin76: Unfortunately, I think that currently these are expensive and only available in small volumes... You'd probably be better off sticking off with Beagle or something right now...
<armin76> dave_m: well, if you want armv7 officially supported on gentoo, and are able to help, just let me know :)
<dave_m> I wasn't involved in getting hold of these boards, but I'll let you know if I get any useful info
<amitk> armin76: Beagle _is_ armv7
<armin76> thanks
<armin76> amitk: i know, but we don't have one
<dave_m> It's not too expensive... nearly bought one myself to play with.
<amitk> I wonder if they released the newer version of the beagle though.
<dave_m> Does anyone else have problems with ports.ubuntu.com?  Some days it's pretty impossible to update the package lists--- lots of stuck TCP connections. Is the server overloaded?  I'm not getting similar problems with other sites...
<dave_m> amitk: I was still waiting for the rev C to come out, since it fixes some things... but I haven't been watching recently.
<lool> dave_m: We had various hardware issues in the last weeks, but if you have current issues let us know
<lool> dave_m: Last I heard, a RAID array failed on the main host so it was down, then was replaced by another temp machine while hardware was replaced, then the regular machine was brought back up, but I don't know whether any other issue popped up since
<dave_m> Right now for example, apt-get update is blocked trying to download a Packages file.  I've tried this 3-4 times now.  As far as I can tell, it's not a local network issue...  Other days it works fine...
<lool> dave_m: It works for me
<lool> dave_m: Could it be a driver issue in the babbage?
<lool> dave_m: Ethernet is known to be flaky in 2.6.28 according to FSL
<dave_m> It's not impossible, but NFS, ssh, scp etc have all been working fine.  Probably not worth worrying about unless other people start to report similar problems...
<lool> ogra: Do you have any issue running apt-get update on babbage ATM?
<lool> dave_m: If it persists, let me know and I'll open a ticket with our IS; they might want to talk to you to debug the issue if needs be
<dave_m> OK, if I can be reasonably sure it's not a problem here.  It's not too serious right now... it just means sometimes I need to wait a few hours before I can update.
<lool> dave_m: Frankly, I've been pain by this in the past and know how unfun it is, but not that much with armel -- we had issue a couple of cycles ago when dealing wiht lpi
<lool> lpia
<dave_m> ogra, lool: hal 0.5.12~rc1+git20090204-0ubuntu3 seems to work OK for me, so the issue I reported is no longer critical. Someone should still take a look at some point in order to understand whether this was just lucky or the bug was really fixed.
<lool> dave_m: Ok, thanks
<ogra> thanks a lot :)
<persia> ogra, There is a bugbot, just not a brilliant one.  bug #123456
<persia> ubot2, bug #123457
 * persia hunts the bug wrangler
<lool> ogra: Just ping persia when you need the URL of a bug   ;-)
<persia> That doesn't work (although it's always https://launchpad.net/bugs/nnnnnn)
<persia> But do bug me if you don't feel like tracking down the bot wrangler and it's not responding.  I may not notice from backscroll, and I'm not a big bugbot user.
<Stskeeps> curious, did you people start out with ARMv4t for libraries and such? just wondering, because when I glance through readelf of some jaunty-armel libraries it shows Tag_CPU_arch: v4T ?
<ogra> lool, perfect :)
<lool> Stskeeps: Yes indeed, we started from Debian armel binaries
<Stskeeps> alright - that explains it then
<lool> Stskeeps: We built Ubuntu sources against the Debian archive, then moved the sources.list to Ubuntu armel only
<persia> bug 322798
<ubot4> Launchpad bug 322798 in hal "Segfault in hald startup (hald/linux/devices.c)" [High,New] https://launchpad.net/bugs/322798
<persia> Right.  Working now.
<ogra> ah, you have beaten it into shape, nice
<persia> Not I.  All credit belongs to jpds.
<NCommander> ogra, I successfully booted your live image on my babbage :-)
<ogra> good
<ogra> if you want to get rid of the dying ttys set the hwclock
<NCommander> ogra, I ddn't get dying ttys ...
<ogra> ah, fine then, so your hwclock is set already
<armin76> lool: who provided you the arm boards apart from marvell? :)
<lool> armin76: I don't know, I got them from my company
<armin76> lool: your company being canonical?
<lool> Yes
<lool> dave_m: Dunno whether you follow the kernel list but the VFP patches were merged in our tree
<sofi1> Hi ...I am having problems making touchscreen to work on jaunty -armel
<sofi1> Can anyone help me?
<sofi1> Was any1 able to get touchscreen working on Jaunty- ARMEL? Can the touch ever work on Jaunty-armel? Is that a known issue?
#ubuntu-arm 2009-03-12
<newz2000> hi, would something like this make a suitable board for experimentation? [ebay link] http://tinyurl.com/cnjbgy (3.5" LCD) or http://tinyurl.com/b46hsg (7" LCD) - both are Samsung S3C2440 ARM9 devel boards
<newz2000> Or does someone have a suggestion for something that has network connectivity and usb host for around $100 USD?
<rwhitby> network and usb host?  Linksys NSLU2
<rwhitby> or a sheevaplug
<rwhitby> both under USD$100
<rwhitby> talk to lool for ubuntu on nslu2, and rabeeh for sheevaplug :-)
<newz2000> so would I be making life difficult by experimenting with a paltform like the ones I linked above?
<persia> newz2000, The main tricks with most platforms are 1) making sure there is a clean working kernel, and 2) making sure you have a mechanism to install.
<persia> It's always safer to go with something that someone else already has working, but if you're prepared for the extra work in getting the basics working, anything ought to work.
<newz2000> ah, good advice. That vendor says they ship with 2.6.13 pre-installed.
<newz2000> is that helpful?
<persia> Not really.  We ship 2.6.28 :)
<newz2000> yeah, big diff.
<persia> Historically, there's been large, incompatible, patches between different ARM kernel trees as well, which complicates things.
<newz2000> Maybe I'll have to just wait for the first gen of netbooks and get one of those. I'd kind of like to get something with a screen.
<lool> newz2000: I recommend you look into modern ARM hardware; there's a change Ubuntu might not support older hardware in future releases
<lool> newz2000: Sheevaplug or beagleboard would both qualify I think
<lool> tbm is working on sheevaplug enablement in Debian ATM
<lool> Oh!  Marvell released U-Boot and Linux downloads for SheevaPlug
<newz2000> ah, good tip
<ogra> Sheevaplug isnt v7 though
<ogra> so might not work in KK
<newz2000> what are some good search words for the best architectures to use?
<ogra> omap3 is surely one ...
 * ogra is a big beagleboard fan 
<lool> ogra: Exactly what I was checking; it's just ARMv5
<lool> How disappointing
<ogra> yep
<ogra> i hope in KK someone from the community adds beagle support to the linux-ports package
<lool> newz2000: ARMv7?
<ogra> that would give us some community
<lool> newz2000: cortex-a8
<newz2000> ok, will check it out
<ogra> cortex-a8 might be the best
<ogra> that specifies all the v7 stuff out there
<ogra> the TI zoom looks like a good platform, though the pricing is a joke
<ogra> http://www.logicpd.com/products/devkit/ti/zoom_omap34x-II_mdp?DCMP=wtbu_zoom&HQS=Other+PR+orderzoom ... "Starting at $1150 Recommended Resale"
<armin76> tbh armv7 is pretty new regarding products using it, if marvell(and therefore almost all NAS vendor) decided to stay with armv5te i'd say its because of something
<ogra> well, v7 is what the ubuntu port focuses on
<suihkulokki> because ARMv7 license is more expensive than ARMv5 license and for a NAS the ARMv7 provide nothing intersting
<armin76> suihkulokki: what does armv7 that armv5 doesn't?
<Stskeeps> plans are to go armv7 exclusively (and not hwcap) in karmic? ..
<Martyn> Hey all.
<Martyn> The company I work for has gotten a babbage board, and I was wondering if I can run the current armel build of jaunty on it.
<Martyn> It's all armel, but will the v4 target that ubuntu uses when compiling the dist give me any issues?
 * ogra points Martyn to http://people.ubuntu.com/~ogra/arm/babbage/
<ogra> note its far from being done yet, its only the first handrolled image ...
<armin76> ogra: who built that board? freescale?
<ogra> armin76, well, who else doe MX$$ CPUs ? :)
<ogra> *does
<Martyn> armin : Pegatron
<Martyn> the babbage board is basically the same thing as the pegatron netbook, but squashed onto a small devboard.
<Martyn> ogra : 48 hours old build .. I'm impressed!
<Martyn> ogra : How long does it take to churn through an entire native build, I wonder...
<Martyn> ogra : I'll 'dd' up a card and boot it shortly.
<ogra> define "native build" :)
<Martyn> It takes a while to download 800 megs worth of image
<Martyn> ogra : Non-cross-compiled
<ogra> you mean compiling a kernel
<ogra> less than 1h
<Martyn> Oh, so the kernel is compiled on the mx51 board, but the entire distribution outside of it is cross compiled?
<ogra> depending on your disk speed ...
<ogra> nothing is cross compiled
<Martyn> Good :)
<ogra> the whole arm port is built natively on our arm buildds
<Martyn> I've been having more and more weird issues with cross compiling on x86 with armel targets.   Those problems simply go away when I use a native toolchain.
<ogra> currently NCommander is the only one cross compiling something for us, since redboot requires its own special toolchain
<Martyn> hzzah!
<ogra> (and he works on packaging redboot for us atm)
<Martyn> Awsome.
<garren> why redboot over u-boot
<Martyn> Well, here does the download.  (insert sounds of bandwidth being sucked)
<Martyn> reboot is more flexible
<ogra> because there is no u-boot support for that HW yet
<Martyn> u-boot has no support on the MX51.
<garren> I thought redboot was no longer being maintained
<ogra> redboot is ugly and evil but nobody implemented u-boot for that SoC
<garren> oh ok
<garren> mx31 does that have u-boot support?
<ogra> u-boot has the big advantage of being able to just use vfat partitions for kernel and initramfs
<Martyn> ogra : Wow .. 6mbit of download speed :)
<ogra> which means you can just use a vfat /boot partition
<Martyn> ogra : I love downloading from well hosted servers .. that's close to our office's max theoretical speed
<ogra> and dont need to jump through hoops to get your kernel into afis partition or omething equally evil
<Martyn> ogra : I know, I know.
<ogra> Martyn, well, the server is in the canonical datacentre
 * amitk watches ogra's temperature rise a few degrees talking about redboot
<Martyn> ogra : One of my tasks is to port a more flexible bootloader.
<ogra> heh
<ogra> Martyn, take u-boot ... many people will love you for it :)
<Martyn> ogra : If I can convince the VP of engineering here.. sure.
<ogra> its the best OSS community maintained bootloader atm
<Martyn> it's a very flexible one, but I prefer my bootloaders to have more 'smarts'
<ogra> it has a big backing by the beagleboard community
<Martyn> having to type 'mmcinit' .. etc.. is just inane
<ogra> so many people look after it and help fixing bugs ...
<Martyn> (not insane, just boring and technical :) )
<ogra> indeed
<amitk> Martyn: what are your options?
<ogra> it surely can use some improvement
<Martyn> I may skip it and port grub.
<garren> I agree u-boot is very popular and quite well maintained
<ogra> if you port grub you will be pretty much on your own maintaining the arm specific patches against it for the start ...
<Martyn> amitk : xosl, grub, u-boot, redboot .. although admittedly there's more work in grub than others, and more work in u-boot than any other for embedded platforms
<ogra> u-boot comes with a big community already
<Martyn> I may just do the 'lazy developer' thing, and extend u-boot to be smarter
<Martyn> But that totally depends on what the company I'm working for sees as a priority.
<ogra> just make u-boot read a config file for the bootcmd :)
<amitk> we should store that in a flash partition
<ogra> no !
<Martyn> can do that.  I was just thinking of having it obey the "active" partition label if using PC-style partition labels
<ogra> in a text file thats just accessible with an editor ;)
<amitk> ogra: that requires an editor inside a bootloader - bloat
<Martyn> hold on .. I'm downloading the u-boot code.   Once I've had a read for a couple hours, I can make more valid comments and directed decisions
<ogra> use flash only fro bringing up u-boot, make it read some kind of partition  in disk by default and make it read all additional options from atext file in that partition
<Martyn> amitk : NEVER.
<Martyn> amitk : It's simpler to just support reading a file off a filesystem.   Once the OS is up and running, you use your text editor of choice.
 * amitk agrees
<ogra> i.e. make it function similar to grub whithout having to port grub :)
<Martyn> That's one of the good things about grub, for example.  It simply knows to read the FS (not caring much what FS it is .. as long as it's supported) finds the config file, and goes from there.
<ogra> right, grub has surely great usability, but u-boot has the biggest bugfixing community backing on arm atm ...
<ogra> megre both and you have the perfect arm bootloader ;)
<Martyn> and as long as the bootloader supports EXT2/3/4, FAT(16/32), and a handful of other commonly used embedded OS'es, then you're fine.
<ogra> the bootloader only needs to support one actually
<amitk> the problem with grub ATM is that the grub1 is a deadend, grub2 is still not stable
<ogra> just to get your kernel up ...
<Martyn> ogra : Sure, and even keep the filenames.  I mean, who cares if the default config file is called "menu.lst"/
<Martyn> -heh-
<Martyn> ogra : I hate having to have two different FS's on a system.  Since the bootloader tends to either live in firmware or on the first sector of the disk .. why not just support the most common FS types and get rid of the idea of a special partition for booting...
<ogra> sure, but that will make your work bigger
<Martyn> One of the interesting things about filesystems, is that it's a bitch to create code to support /write/, but reads are actually relatively easy by comparison.
<Martyn> and most bootloaders don't have the support write for any reason.
<ogra> well, you wont need write support at all for the above setup :)
<Martyn> i already have a code library to deal with NTFS, FAT, FAT16, FAT32(+LBA), EXT(2/3), jffs2, and cramfs
<ogra> the system can do all the writing, the bootloader only needs to read
<ogra> (and execute accordingly to the config)
<Martyn> exactly .. I wrote the bootloader for the IBM/Lenovo "blue button" restore system.
<ogra> sweet
<Martyn> And I can say, with PRIDE, all that fits easily in the first 63 sectors.
<Martyn> The initial bootloader (jump section and some branching code) fits inside the first sector with room for the partition tables :)
<Martyn> Of course, that's not needed on the ARM platform, which doesn't even load a bootsector from disk, ever.
<Martyn> One of the same reasons I love the OpenBoot firmware on macs.
<ogra> what i really hate about all arm bootloaders in their current state is that you always need a second machine since they all require serial interaction ...
<lool> Hey folks RB actually supports FS
<lool> In tip
<lool> packages/fs/fat/current/src/fatfs.c in ecos
<lool> (Well at least ecos does)
<sofi2> I have been asking this questions over and over ...Can any1 tell me if any1 was able to get touchscreen working on Jaunty-ARM?
<sofi2> ???
<Stskeeps> i have it working on a n8x0, but through tslib :P
<sofi2> I have installed tslib and I also removed synaptic
<sofi2> But I am still unable to get it to work
<Stskeeps> maybe if you tell which hardware you're doing it on :P
<sofi2> I can do a cat to the touchscreen event and I get characters back...This means my driver is working
<sofi2> But for some reason I cannot see it on X?
<sofi2> Any suggestions?
<Stskeeps> do you have a /etc/pointercal, since you use tslib? :P
<sofi2> Yes I calibrated the touchscreen...I got those 4 corners and center hair and it generated /etc/pointercal
<Stskeeps> and you got rid of xserver-xorg-input-synaptics (sp)
<sofi2> yes
<Stskeeps> hmm
<sofi2> But I cannot see anything on X
<Stskeeps> cannot see = no actual input working on X, or no cursor showing?
<sofi2> I mean the touch is not showing an input pointer...However wheneven I touch the screen it takes me to the logout pop-up of LXDE
<sofi2> no matter where I touch
<Stskeeps> and you have an xorg not entirely unlike the inputdevice section in http://rafb.net/p/ghLad128.html ?
<Stskeeps> xorg.conf, that is
<sofi2> Actually I am not using omapfb because my hardware is being almost unresponsive ...So I am using      Option          "UseFBDev"              "true"   instead
<Stskeeps> well, it was more about the InputDevice section
<sofi2> Yes ..except that I had to change the event to event1 coz thats where my touch is
<Stskeeps> alright.. i would recommend you to check your xorg log for anything weird :P
<sofi2> Does jaunty have problems in xorg?
<sofi2> Do you know where the paste bin is ? I wanted to paste the xorg log
<Stskeeps> rafb.net/paste can be used
<sofi2> rafb.net/paste
<sofi2> How ?
<Stskeeps> http://rafb.net/paste paste it, and give the url to the result :P
<sofi2> http://rafb.net/p/mxDz4Y48.html
<sofi2> Thanks:)
<Stskeeps> and width/height matches resolution?
<Stskeeps> can you paste your xorg.conf too?
<sofi2> xorg.conf:  http://rafb.net/p/oyRqch80.html
<Stskeeps> hm, seems correct
<Stskeeps> and the tslib tools seem to react correctly?
<sofi2> you mean ts_calibrate
<sofi2> yes
<Stskeeps> i wonder if that stay-clicked touchscreen bug was fixed..
<sofi2> what is that bug?
<Stskeeps> well there was some bug in -tslib that caused the cursor to stay clicked or something, but im not sure
<sofi2> Is there another driver that is more stable then with a calibration tool ?
<Stskeeps> ok, this is not a official ubuntu package at all, but it is one we use on the nokia n8x0s on a ubuntu port, and i know it works, so you can test if it works with that
<Stskeeps> http://repository.mer.tspre.org/pool/main/x/xf86-input-tslib/xserver-xorg-input-tslib_0.0.5-1mer7_armel.deb
<sofi2> ok Thanks :) I will try it right now
<Stskeeps> no promises :P
<Stskeeps> can i out of curiousity ask what kind of device you're working with?
<sofi2> Its a omap3430 device from TI which is not out yet...I cant say more than this ;)
<Stskeeps> alright
<Stskeeps> ah, and with http://repository.mer.tspre.org/pool/main/t/tslib/libts-0.0-0_1.0-4ubuntu2mer2_armel.deb , http://repository.mer.tspre.org/pool/main/t/tslib/libts-bin_1.0-4ubuntu2mer2_armel.deb too
<Stskeeps> forgot those
<Martyn> ogra : Does the babbage board support SDHC cards properly for booting?
<Martyn> lool : Sorry it took so long to get back to you .. I was out to lunch, literally.
<lool> that's fine
<lool> Martyn: I have had issues with some versions of redboot with some cards; one limitation is that it will only see the first 2 GB
<Martyn> So, I can't really comment as to why we have the board .. at least openly.
<lool> Well you're in a public chan here
<lool> So let's avoid it :)
<Martyn> Right :)
<Martyn> Aaaand .. after that wonderful netsplit...
<Stskeeps> sofi2: any luck?
<Martyn> ogra : The image starts at block 4, so you've left room for redboot at the top of the image?
<Martyn> Or does the image have a reboot already on it?
<Martyn> I just did the dd and inserted the card, but got no joy for a boot.
<sofi2> ï»¿Stskeeps: I am still unable to get touch working?
<Stskeeps> sofi2: alright, - i'm not entirely sure what is wrong then :/
 * Martyn gives up on the board for the moment, and moves back to working on the beagleboard.
<Martyn> One of these days, installing ubuntu on non-x86 architectures will be as easy as installing it on x86
 * Martyn *sighs*  It just doesn't have to be this hard.
<Martyn> is there anyone here with a babbage board that could do a quick off-channel chat to check board DIP switch settings
<Martyn> Since I'm short the docs, I just want to get this one in a bootable state.
<Martyn> re
<Martyn> Hi there David
<dad_> hello
<Martyn> re
#ubuntu-arm 2009-03-13
<error404notfound> Hi!
<error404notfound> how easy it is to install ubuntu on an arm machine with no usb port, no cd rom, no ethernet, just wifi and 3g?
<persia> Not very.  You'd need some way to download enough to boot, and then be able to boot off that.
<error404notfound> persia: hmmm, actually I am really confused that if it doesn't have a usb port, a cdrom, or ethernet, how can even copy anything from network to it. I don't know from where should I even start
<persia> I'd recommend starting by looking for someone else who has gotten any linux running on your device.
<persia> You can probably adjust those instructions as required to have the install be Ubuntu.
<error404notfound> I am following your first recommendation by joining this channel...
<persia> In that case, you might want to mention the specific device name :)
<error404notfound> hmmm, wanna know the truth? I still haven't got one, its stuck for clearance on airport and I am waiting for it... may take couple of days.. :P
<Stskeeps> sometimes i want to shoot whoever chose right click as paste.
<persia> Oughtn't be right-click.  Ought be middle-click.
<Stskeeps> yeah
<tomsh> is it normal when using build-arm-rootfs
<tomsh> * Setting kernel variables (/etc/sysctl.d/10-network-security.conf)...          error: "net.ipv4.tcp_syncookies" is an unknown key
<tomsh> * Setting kernel variables (/etc/sysctl.d/10-process-security.conf)...          error: "vm.mmap_min_addr" is an unknown key
<tomsh> ?
<persia> tomsh: It depends on your kernel configuration, really.  It's been reported before.
<lool> persia: Do you know whether we have bug for these?  It shouldn't happen with the versatile kernel as it's a distro kernel
<lool> And the imx51 one is as well now
<persia> We don't have a bug for it: it's never been reported against a distro kernel (that I've heard).
<lool> NCommander: Do you think you could report these issues as well as the babbage ones?
<lool> NCommander: Tag them arm
<ogra> lool, they are on my list of bugs for amitk_
<ogra> net.ipv4.tcp_syncookies definately shows on babbage as well
<lool> ogra: Which list?
<ogra> my personal one i'nm assembling while testing the babbage kernel here
<ogra> klogd not starting is another one ...
<ogra> though currently i'm after finding out whats wrong with aufs/apparmor that makes all ttys die and X not start up
<ogra> thats more important than cosmetical boormessages
<ogra> *boot
<ogra> lool, i wont manage to file these bugs right now, can you mention in the release meeting that there are imx51 bugs to come we will need to fix before beta ?
<lool> ogra: No
<lool> I'll give a general status update
<ogra> ok
<lool> I remember quite well the day were I was shot in place for mentionning bugs which I hadn't filed yet
<ogra> well, they are all under investigation only atm ...
<ogra> the imx51 kernel isnt 100% merged and i assume a lot will be solved once that happened
<lool> NCommander: Please Cc: slangasek on the RedBoot build issues with native toolchain
<obra> Hi. I'm seeing some weird behaviour with ubuntu (and debian) arm ports on qemu. It _appears_ that some of the time the SCSI device just stops responding.  It appears to be fairly random. When it happens, spurious "a"s get printed to my terminal.
<obra> I'm seeing the behaviour across several versions of qemu on OSX and Linux.
<obra> Is there an obvious FAQ I'm missing?
<Stskeeps> versatile kernel or?
<obra> versatile kernel.
<obra> /usr/local/qemu/bin/qemu-system-arm -M versatilepb -m 256 -kernel vmlinuz-2.6.28-8-versatile -hda armel.img -append "mem=256M root=/dev/sda1"
<obra> (Starting from the initrd images and doing an install)
<obra> I get the same behaviour using http://people.debian.org/~aurel32/qemu/armel/
<Martyn> Good morning.
<Martyn> Ogra, look, amit .. any of you online?
<Martyn> lool rather
<lool> Martyn: I'm around, but I'm out for an hour or so
<lool> I'll be back here later
<Martyn> Allright.  I'm trying to do a first bringup of ubuntu on the board, and wanted to verify some settings
<amitk_> Martyn: is this something quick?
 * amitk_ is about to wrap up for the day
<Martyn> amitk : Relatively.  The image that ogra put up (the SD card image) seems to have reboot on it, and the first partition is a few sectors from the beginning of the card...
<ogra> right
<ogra> i think i left 20M ... though 15M shoudl suffice
<Martyn> When I put it in the board and power up, I do see the keyboard flash, but no console output or display output.. is that normal for this image?
<Martyn> yep, about 20M
<ogra> you should get console output on VGA
<Martyn> dreck, I don't.
<ogra> after redboot decompressed the kernel
<ogra> probably an issue with your DIP switch settings
<Martyn> would you mind going through a quick board comparison?  I want to make sure the DIP switches on mine match yours.
<Martyn> the two that are together at the top, read from SATA->pushbutton are:
<Martyn> 0-0-0-0-0-0-0-1 1-0-0-0-0-0-0-0
<ogra> the middle ones are  on
<ogra> right
<Martyn> the one next to the SD card is (read from VGA to serial breakout)
<Martyn> sorry, read from serial->vga direction
<ogra> the second should be on
<Martyn> 0-1-0-0-0-0-0-0
<Martyn> Okay, those match
<ogra> looks ok
<Martyn> So, in theory it should have just worked
<ogra> yes
<Martyn> I'll try a different SD card then.   Darnit!
<ogra> note the kernel doesnt support DVI
<Martyn> Wait, I thought the kernel didn't support VGA...
<ogra> you need to use VGA
<ogra> no
<Martyn> okay, switching connectors.
<Martyn> and switching to a real SanDisk card
<ogra> yup, sandisk ++
<Martyn> okay, I'm going to re dd it to a sandisk 2Gb card.
<Martyn> allright, once the DD is finished, I'll try again.
 * ogra finally got the initramfs booting for amitk's latest kernel 
<Martyn> congrats!
<ogra> well, i dont see the bugs fixed yet ...
 * ogra waits for casper to find the squashfs 
<ogra> amitk, tty's still die :(
<ogra> amitk, oh, but you added fusectl ....
<ogra> at least it doesnt complain anymore
<ogra> oh, and X now starts up but i get a "your session lasted less than 10 secs."+ message now
<amitk> hmm
<Martyn> ogra : At least X starts up.
<ogra> hmm, that looks a bit like the former error though, i see attempts fopr autologin on tty1
<amitk> ogra: this is live image?
<ogra> yep
<amitk> with union=aufs?
<ogra> without union=
<ogra> which defaults to aufs
<ogra> i see it loading aufs
<amitk> ok
<ogra> switching to console i see multiple motd messages
<ogra> something is wrong with the login, but its hard to debug since i konw if i boot into single mode i will see everything with the user is right
 * ogra will boot into single and start executing the initscripts piece by piece ... time consuming, but probably i see where i hit the issue
<ogra> oh
 * Martyn chuckles, the dd is still going :)
<Martyn> this isn't my first dance with new hardware, but I'm frankly amazed at how fast you guys at canonical are doing the bring-up of this one
<ogra> well, we know our tools :)
<ogra> so its just a matter of adapting them
<Martyn> HUZZAH
<Martyn> we're up.
<ogra> the main issue was to get initramfs working with redboot
<ogra> everything beyond that is just small adjustments
<ogra> congrats !
<Martyn> gets as far as sd
<Martyn> then stops
<ogra> give it time :)
<Martyn> timeout issue?
<ogra> it looks for the squashfs that takes some seconds ...
<ogra> amitk, klogd still dies
<Martyn> there it goes..
<Martyn> I should probably disable SATA
<Martyn> okay, I'm seing the tty messages
<Martyn> nice X
<Martyn> and there we go.  Thanks ogra :)
<ogra> enjoy
<ogra> note that its not installable
<Martyn> This is a much faster bring-up than I usually have to do (kernel, then busybox, then ...)
<Martyn> That's fine.  This is enough for us to do some very, very important tests for the work we're doing.
<ogra> but you could for example use debootstrap or the rootfs script from the channel topic and install a system to a usb disk
<Martyn> *nod*
<Martyn> Or sata?
<ogra> then just change the cmdline in redboot to not use casper
<Martyn> Or is boot-to-sata not quite yet ready for prime time?
<ogra> and add root=UUID=<uuid of your disk partition>
<ogra> i havent tried sata at all yet
<amitk> usb disk should work well
<ogra> and i think sata is just a fake ...
<ogra> in the backend its attached to usb
<Martyn> Oh, you think there's a bridge chip?
<ogra> yes
<Martyn> The mx51's spec shows a SATA controller though.
<Martyn> well, doesn't matter :)
<ogra> well, feel free to try it :)
<ogra> (if amitk has the sata driver enabled)
<Martyn> I'm pleased as punch to have a working install.   I'll track your builds from this point.
<Martyn> It looked like it was at least trying to bring sata up during kernel initialization
<amitk> ogra: no sata drivers yet IIRC
<Martyn> amitk : Danke.
<ogra> right, thats what i thought
<amitk> Martyn: I'll flesh out support for _every_ storage driver as a module in the next upload
<ogra> if we find one that doesnt make the consoles die :P
<Martyn> amitk : Ooooo :)
<Martyn> ogra : Just out of curiosity, where are the authentication token error messages coming from?
<ogra> which one ? "your password is expired" ?
<Martyn> yep
<ogra> run "sudo hwclock --systohc" and reboot ...
<ogra> (if your system clock is right at least)
<ogra> that fixes it
<ogra> useradd somehow sets the expiry time to zero if the system date is at 01 01 1970
<ogra> setting the hwclock fixes it
<Martyn> fixed, and thanks.
<Martyn> worth adding to your README
<Martyn> now I want the serial debug dongle ... -sigh-
<ogra> worth fixing the bug rather :)
<Martyn> being a unionfs based image, I'm assuming any changes I make to the FS will be lost at reboot?
<Martyn> very much worth fixing the bug!  It's just more of an appnote for that very first release of the image
<Martyn> thanks :) You guys just made my day.
<ogra> amitk, hmm, klogd tries to access /dev/console
<ogra> and then dies
<Martyn> interesting!
<Martyn> when the hwclock is set correctly, the tty's also come to life
<ogra> yep
<ogra> the autologin works then
<Martyn> it does indeed
<ogra> upstart makes them die if the user isnt set up correctly
<Martyn> no modules.dep file?
<ogra> nope, next image will have the kernel package inside
<Martyn> heh, no modules at all :)
<Martyn> *chuckle*
<ogra> and have the modules.dep
<Martyn> should I apt-get it?
<ogra> apt-get install linux-imx51
<Martyn> done
<ogra> that will get you everything you need
<ogra> note that the NIC driver is shaky
<Martyn> Yeah, I know.  Works okay though.
<Martyn> you guys should be very, very proud of this.   Most hardware first bring-ups are a hell of a lot more shaky than this.
<Martyn> This is practically almost useable in comparison to some projects I've worked on.
<ogra> :)
<Martyn> Wow, everything is arm V7 clean?
<Martyn> no v4 compiles?
<Martyn> what's the process I have to kill to prevent the 100% cpu spinning?
<Martyn> gnome-keyring?
<Martyn> ogra, how do I get the live image to boot single user, if I don't have access to the serial console?
<Stskeeps> Martyn: think it's armv5te targeted, not armv7
<Martyn> Stskeeps : Thanks.
<Martyn> I was wondering how far the system was going to be optimised...
<Martyn> v5 is good enough
<Stskeeps> think they're looking at HWCAP of libraries too, which makes sense
<ogra> Martyn, we might switch to v7 completely with 9.10
<ogra> its still being benchmarked what we gain from it and will be discussed at next UDS
<Stskeeps> or loose in terms of supporting less devices, heh
<Martyn> ogra : *nod*
<Martyn> ogra : If I don't have access to the redboot monitor (thanks to having no serial debug board), how can I get the liveimage you've posted to come up single user?
<ogra> not at all ...
 * Martyn tried hexediting the redboot, to change the kernel bootparams, but that didn't work :)
<ogra> lool is working on something we should see next week that will make it possible to dd changes into the fis partitions
<Martyn> Is there a way to bring down X safely once the livecd has booted, without triggering a reboot?
<ogra> you can switch to a console and sudo /etc/init.d/gdm stop i guess
<Martyn> Tried that.  No joy.
<ogra> well, both options you can set are cmdline options to get into single
<ogra> and the cmdline is only accessible via serial atm
<ogra> one would be to add "text" to it, the other would be "single"
<Martyn> yep
<ogra> text actually gets you a full system, while single gets you only a recovery console
<Martyn> Oh well :)  I guess I have to be patient and wait until Monday when a serial debug dongle will arrive as if by magic.
 * ogra was pondering to add a menu to the boot  ....
<ogra> but i have to much to do to track down the kernel issues on the weekend ...
<ogra> if i magically find the solution i might look into adding some bootmenu
#ubuntu-arm 2009-03-14
<obra> Are folks around? I posted about 9 hours ago - I'm seeing weird freezes apparently in the SCSI device with ubuntu on qemu-arm. Is this a known obvious idiotic thing I'm doing?
<julianoliver> i'm targetting ARM7. does the current version of Ubuntu-ARM support this architecture (even experimentally) or is this slated for an April release?
<julianoliver> i refer to http://www.ubuntu.com/news/arm-linux
<julianoliver> i'm targetting ARM7. does the current version of Ubuntu-ARM support this architecture (even experimentally) or is this slated for an April release?
<julianoliver> i refer to http://www.ubuntu.com/news/arm-linux
<armin76> julianoliver: ubuntu atm is armv5 afaik, and it does work with armv7
<julianoliver> what kind of speed difference would i be look at for raw number crunching?
<julianoliver> s/look/looking/
<julianoliver> eg comparing Ubuntu optomised for armv5 to Angstrom optomised for armv7
<armin76> no clue, i don't have an armv7 :)
<armin76> and i'm no ubuntu dev either
<julianoliver> right thanks.
<lool> obra: No idea about your specific problem, I recall someone mentionning scsi OOPSes in qemu because generic SCSI support was turned on -- IIRC; but I'm surprized you get this with AurÃ©lien's kernel
<lool> obra: I'd report to the qemu folks in all cases
<lool> julianoliver: It's hard to tell, but there are noticeable differences between ARMv5 and ARMv6 + VFP at least
<lool> So I'd expect v7 + VFP to imply an even more noticeable difference
<julianoliver> lool: right, thanks.
<julianoliver> lool: i'll try to make use of as many armv7 compile-time optomisations for my code and see if that helps.
<julianoliver> i'm trying to use the script build-arm-rootfs and after a long process of downloading and building it fails with this output: http://rafb.net/p/tCVnne85.html
<julianoliver> hehe ugh.. i see that the typo's mine
<julianoliver> nvm.
<maxriskfactor> I am trying to make the memory available more than 256MB while making ubuntu arm to run under qemu-system-arm
<maxriskfactor> anybody facing the same problem?
<maxriskfactor> i get a segfault when giving more than 256MB
#ubuntu-arm 2009-03-15
<xlogik> Does anyone know if the "Peek" mobile device is capable of running ubuntu-arm?
<xlogik> Its based on the TI Locosto chipset http://blog.makezine.com/archive/2008/09/peek_email_only_device.html
<xlogik> more info: http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?contentId=15408&navigationId=12656&templateId=6123
<suihkulokki> xlogik: arm7 is not enough to run ubuntu (or any other generic linux)
<xlogik> ok thnaks
<xlogik> What about angstrom?
<suihkulokki> xlogik: I think only uCLinux will work
<xlogik> hmm
#ubuntu-arm 2010-03-15
<hrw> hi
<lool> persia: Hmm I don't think qemu-debootstrap works in pbuilder-dist -- it needs an arch arg
<lool> persia: And I doubt it works in mk-sbuild either
<lool> Eh I see the same biarch stuff in there :)
<persia> I tested both before I shipped, and successfully built armel and powerpc chroots on an amd64 machine.
<persia> So, unless something else changed since I pushed, it works, even if it's not supposed to work.
<persia> mk-sbuild is my primary workspace, with pbuilder-dist attempting to keep up out of courtesy for pbuilder users.
<persia> With the latest mk-sbuild, I consider pbuilder obsolete.
<persia> (because of support for type=file chroots).
<cooloney> plars: for the suspend/resume regression, which kernel works on your side?
<cooloney> plars: i failed to find any kernel on my side.
<lool> persia: Ah I'm wrong indeed; pbuilder and sbuild pass --arch to debootstrap
<lool> So it just works
<lool> I was expecting one had to care for --arch to be passed as well, but that's already the case
<persia> mk-sbuild has always passed --arch.  It was added to pbuilder-dist some time ago (gutsy or hardy, I think).
<persia> One does have to care for --arch, but not quite so carefully.
<persia> Note that neither of these tools are capable of correctly building chroots for unsupported Ubuntu distributions right now.  I'm not sure how much that matters, but figure it's worth mentioning.
<lool> persia: Would you have some time to review some early documentation?
<persia> lool: What sort of documentation?
<lool> persia: https://wiki.ubuntu.com/UbuntuDevelopment/Ports
<lool> persia: On development with qemu / for armel
<persia> Ah, cool.  I definitely have time to review that :)
<lool> persia: This is very much tools focused rather than tasks-focused; I wish I'd document "How to build an armel package" stories
<persia> Also, on a related note, I'd like to get your input on how we should adjust pbuilder-dist and mk-sbuild to work in Debian.  I know you've done a lot to bring nomenclature in line, but I'm not that familiar with the names in Debian.
<lool> persia: I'm afk for most of today, but I wish you go straight to making fixes or mention what should be fixed to me
<persia> lool: For straightforward stuff, I'll just edit.  For discussion / debateable items, I'll send you email.
<lool> persia: pbuilder-dist > I think this functionality should be merged in pbuilder itself; I have some strict views on how it would be done, but didn't finish the (large) task of cleaning things up to make this possible
<lool> mk-sbuild > I'm not a heavy sbuild user, but I wish to change that; the sbuild team is quite active upstream touhg
<persia> lool: You'll merge *all* of pbuilder-dist into pbulder?
<lool> persia: Pretty much
<lool> persia: In fact, I think I already cover most of it
<persia> Fo mk-sbuild, I mostly just need some pointers to how to invoke qemu-debootstrap in Debian.
<lool> Was qemu-debootstrap merged already?
<persia> To where would it be merged?
<persia> The package in which it lives in Ubuntu doesn't exist in Debian, nor does anything obviously similar.
<lool> I think I sent it to qemu
<lool> Because it basically requires qemu and the binfmt stuff
<lool> Which is in qemu-user-static in Debian
<lool> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572952
<ubot4> Debian bug 572952 in qemu "qemu-debootstrap wrapper" [Wishlist,Open]
<zumbi_> lool: that only works on armel
<zumbi_> that is why i wanted to test newer release 0.12
<lool> zumbi_: What only works on armel?
<zumbi_> to see how that works for mips, pcc, etc... *re Bug3572952
<zumbi_> sorry, i have another keyboard layout bug 572952
<ubot4> zumbi_: Error: Bug #572952 not found.
<persia> lool: Thanks.  I'll tack that.
<lool> zumbi_: I created a powerpc chroot using qemu-ppc when writing qemu-debootstrap
<lool> So I think it works with our qemu-ppc static binary at least
<persia> zumbi_: I've also tested it with powerpc successfully.
<persia> zumbi_: Please test with arbitrary architectures, and let us know how it doesn't work.
<zumbi_> uhm.. i should then test again, we tried it a couple weeks ago
<persia> Alternately, if you ran into an older version of mk-sbuild or pbuilder-dist that has the "only supported for armel" warning, please upgrade.
<zumbi_> uhm.. note that i use debian stuff
<persia> Ah.  I haven't ported my stuff to work on debian yet, and lool's work is pending the recently mentioned bug.
<persia> But if 572952 lands for squeeze, the necessary ubuntu-dev-tools stuff will as well.
<zumbi_> yes, i would love to see it applied, also working for all arches, not only armel, but that is qemu lack of enough support for emulate other arches
<persia> I thought powerpc worked in Debian as well.
<persia> Or, rather, powerpc guests.
<persia> I'm less sure about other stuff.
<saeed> ericm_: ping
<ericm_> saeed, pong
<saeed> ericm_: regarding kexec patches
<saeed> I send the patches to mailing list, but has been rejected
<saeed> do you know if both patches were needed also for imx?
<ericm_> saeed, I guess the one for L2 is needed as well - according to cooloney's test result
<ericm_> it's really annoying I know, I didn't look too much into L2 on ARMv7, but it's totally different than ARMv5, guess we need some neater solution for the outer cache
<saeed> ericm_: can you please check with cooloney's regarding the other patch?
<ericm_> saeed, sure
<saeed> ericm_: now I'm debugging the highmem issue (crash when booting from sata)
<ericm_> saeed, cool
<saeed> ericm_: can you please also check if this issue happens on imx?
<ericm_> saeed, called him
<dmart> NCommander: you awake yet?
<ericm_> saeed, he tried kexec with both patches, not individually tested, so the first question is not sure which one is mandatory
<ericm_> or both are
<ericm_> and babbage with imx51 has only 512MB, so actually HIGHMEM wasn't actually even used
<saeed> ericm_: you can pass kernel vmalloc=256M, that will make some dram as highmem
<ericm_> dmart, do you know if Catalin has an IRC name here on freenode? I guess Saeed and I can talk a little bit about some L2 issus we met during kexec debugging
<ericm_> saeed, indeed - I'll see if he has time to test this later
<saeed> ericm_: thanks
<ericm_> saeed, no problem
<dmart> ericm_: not sure whether he's usually online
<dmart> OK, I think he will join - he's cmarinas
<ericm_> dmart, thanks
<NCommander> dmart: yes
<dmart> NCommander: hi, dunno if you saw my post on the OOo bug, but it looks like the fix we had has a problem: privateSnippetExecutor pushes some arguments on the stack, but they never get removed after cpp_vtable_call returns
<dmart> NCommander: this is a more complete attempt http://pastebin.ubuntu.com/395620/
<dmart> Since I have a OOo build tree now, I rebuilt libgcc3_uno.so and clobbered the installed version in lucid with it--- OOo seems to start up and "work"; is there anything else I should look for?
<NCommander> dmart: no, that was our usual test since we never got past start up :-)
<NCommander> dmart: who caught the arguments on the stack problem? (I didn't have an OOo crash, but I didn't abuse it hard)
<NCommander> dmart: actually, there IS an OOo test suite believe it or not. Might be worth trying to run it if you cna spare a few weeks
<persia> Nah.  The test suite should only take 100-150 hours to run.
<dmart> One of the other guys on my side, by inspection (it was a dumb mistake, we push some stuff which is never popped)
<dmart> It means exception unwind annotations are needed after all, to clean up the stack if an exception happens, but it seems reasonably straightforward now we understand what the code is doing.
<dmart> persia: is the testsuite part of the OOo source package?
 * persia checks
<persia> dmart: My apologies: I don't appear to be able to answer the question.  Attempting to download the ooo source from my local mirror (~50cm away) will apparently take 9 hours, and trying to unpack it directly on the mirror seems to break either with the version of dpkg on that server or with the amount of available RAM
 * persia looks forward to more hardware exceeding the 512M boundary
<persia> NCommander: Maybe you could share?
<NCommander> dmart: no, its an addon, and OOo has to be built in a special way
<dmart> argh, so, 4-5 days + x
<dmart> Can I suggest that you verify what's suggested in http://pastebin.ubuntu.com/395620/ works for you and push that (assuming it does work, of course)
<dmart> I did some standalone testing on this, checking that the normal and exception return paths do the right thing: it appears to behave well.
<dmart> NCommander: scrollback the last few posts (forgot to ping you)
<NCommander> dmart: sure
<dmart> NCommander: should I assign the lp bug back to you in the meantime?
<NCommander> dmart:
<NCommander> yeah
<dmart> ok
<dmart> done
<prpplague> davidm: greetings
<NCommander> asac: is chromium on ARM known to be broken?
<NCommander> can someone who has Ubuntu on ARM running on something beside dove or imx51 test something for me?
<prpplague> NCommander: depends on what you need
<prpplague> NCommander: i'm running a beagle
<NCommander> prpplague: can you download and install chromium-browser from the archive (in lucid) and see if it works properly
<prpplague> NCommander: sorry, i am not able to do that at the momment, sorry
<prpplague> NCommander: no display running atm
<NCommander> prpplague: X11 forwarding over SSH?
<prpplague> NCommander: only uart console
<NCommander> prpplague: ouch
<NCommander> prpplague: thanks anyway
<prpplague> NCommander: i should have something up and running towards the end of the week, but i suspect that is too far down the road for you
<NCommander> prpplague: yeah :-/
#ubuntu-arm 2010-03-16
<lool> NCommander: http://pastebin.mandriva.com/17521
<lool> dmart: ^
<NCommander> lool: ?
<lool> dmart: Mandrive patch by rtp (Arnaud Patard)
<lool> Which works for him
<dmart> It will work if the called function only has 4 args or less
<dmart> But if there are more, the saved lr will appear in the middle of them, messing things up.
<dmart> I don't know whether this framework is necessarily supposed to work for arbitrary numbers of args, but I'm assuming it is.
<lool> dmart: I guess so as well, it's meant as a generic bridge
<lool> I'm asking him to join #ubuntu-arm here
<dmart> Other than the issue of where on the stack lr is stored, the patch is effectively the same as mine, so it's reassuring that it works.
<lool> dmart: I found what crashes valgrind on startup
<dmart> I have disappear to a meeting right now :( but I should be back in ~1hr or so
<lool> rtp: dmart and NCommander are around and looked at your changes
<lool> rtp: dmart will be back in an hour (meeting), but says the function probably has to work for any number of args
<rtp> lool: great. :)
<rtp> lool: ok.
<NCommander> lool: I thought ARM already submitted a fixed version
<lool> NCommander: did they?
<lool> NCommander: where?
<rtp> NCommander: the patch in comment #69 doesn't work on my system
<NCommander> lool: it was on the bug, give me a sec
<NCommander> rtp: hrm, worked here, but that may be a fluke.
<NCommander> rtp: lool: seems the patch never made it to LP, hold on, I have to go fishing for it
<rtp> NCommander: fwiw, I'm not running ubuntu on my systems :)
<NCommander> rtp: lool: http://pastebin.ubuntu.com/395620/
<persia> rtp: The patch wasn't distro-specific : it ought work on Mandriva as well.
<NCommander> rtp: of course not, but solving this bug should solve it everywhere. I know Debian, and Gentoo also were watching for a fix
<persia> armin76: Did you test the patch?
<rtp> NCommander: will try this patch. Would bee nice to get it on the bug so that everyone can follow and test :)
<NCommander> rtp: well it hasn't even been tested yet so lets not jump the gun so quickly ;-)
<NCommander> rtp: I didn't even know Mandravia had an ARM port
<lool> dmart: commented on the valgrind bug; happy if you have suggestions to avoid "mvn" on Thumb 2
<rtp> NCommander: my intent was not to blame people at all. sorry
<NCommander> rtp: no blame taken. I should have made sure the patch made it onto LP. That was just a breakdown in communications
<rtp> NCommander: our arm port is something new
<lool> NCommander: even untested, the patch belongs in the bug report
<lool> Where I've sentit now
<NCommander> lool: thanks
<lool> rtp: In the bug now, sorr
<lool> y
 * lool &
<rtp> lool: thanks :)
 * NCommander hasn't run Mandriva since it was Mandrake
<rtp> well, at least, you know that Mandriva was Mandrake before
<rtp> NCommander: your pastebin patch is working here.
<NCommander> rtp: ARM will be thrilled to know that. Do you have upstream commit access to ooo-build
<rtp> NCommander: no, I've no access to it. Maybe the debian ooo guy as commit access ?
<rtp> s/as/has/
<NCommander> rtp: I have someone I can poke to commit it :-)
<rtp> :)
<NCommander> rtp: can you just comment that on LP? I'll nudge ccheney to replace the patch in ooo-build later today
<rtp> NCommander: I've no account on LP :)
<persia> rtp: Are you sure?  For a while LP was creating accounts for all sorts of open-source developer sorts (you may not know your password)
<persia> rtp: Check at https://launchpad.net/people
<rtp> persia: it looks like it created something when I was "playing" with gnome-control-center. I'll prefer using my mail @work
<persia> rtp: If you can log into that account, you can feed it a different address.
<rtp> ok.
<rtp> persia: looks like it worked. thanks
<persia> rtp: No problem.  Thanks for stopping by and helping out :)
<persia> rtp: Feel free to ask if you run into anything with which we can help.
<rtp> persia: well, this bug was annoying a lot of people and needed to be fixed imho. I regret I was not able to look at it before the end of last week :(
<dmart> NCommander, rtp: Hi, I can discuss the OOo fix thing now
<dmart> lool: What was the background to the Valgrind issue?
<NCommander> dmart: rtp tested the revised fix, and it works on mandriva
<dmart> rtp's own patch has the right idea, but appears incorrect in a couple of ways.
<rtp> dmart: I've not played with arm asm since some years so it's possible there are bugs. I've mostly played with mips asm theses days :)
<dmart> Fair enough
<dmart> The issues were a) you should keep the stack 8-byte aligned when calling functions (so you need to push an even number of regs, or adjust sp)...
<dmart>  and b) I think the bridge is intended to work for functions with > 4 arguments.  The way you push lr causes it to appear in the middle of the args, which is likely confuse functions with >4 args.  My version just pushes lr last; otherwise the logic is much the same.
<rtp> I see...
<ius> Is there any reason for lucid alpha3 to be relatively 'slow' out of the box compared to eg. angstrom for arm7?
<ius> It feels rather sluggish, I do hope it's not march=armv-7?
<ogra> it is v7 and thumb2 by default
<ogra> on what HW do you see that ? beagle ?
<ius> Another OMAP3430 board (Samsung H1 smartphone)
<ius> (I borrowed the built rootfs from beagle)
<ogra> well, we dont see any sluggishness on any of our supported boards (actually quite the opposite)
<ius> Odd
<ogra> so it might be a kernel feature you are missing that the lucid userspace relies on
<persia> Also, is there a particular operation that is sluggish?
<ius> Well, 'general' command line use using the serial/ethernet gadget (latter using sshd). Perhaps I should try to get some figures
<ius> Have to admit I'm running root off sd, so perhaps angstrom used tmpfs for some bits or so.
<armin76> persia: which patch?
<persia> armin76: The OOo patch for gcc 4.4
<armin76> persia: nobody told me anything, so no
<armin76> but if it works for you there's no point me testing it :)
<persia> armin76: Not for testing: I thought you might want it for application.
<persia> If you had tested, that's a nice data point, but sharing is always good :)
<armin76> nah, i just tested it because NCommander told me to
<armin76> but thanks for the offer, i appreciate it :)
<DanaG> http://blog.laptopmag.com/hands-on-marvell-armada-powered-smartbook-does-1080p-video
<DanaG> interesting.
<DanaG> Though, hinge that doesn't open to 180 degrees? bleh.
<lool> rtp: sorry, thought I had pushed the patch, but the connection had been reset; thanks for adding it
<plars> ok, seeing something unusual here during install... it appears that kernel messages are passing through to X, and I'm getting text artifacts on the screen from it
<plars> grabbing a screencapture won't see it, and moving the mouse across the affected areas redraws it correctly
<plars> rather annoying though
<plars> anyone seeing that on the current lucid images?
<plars> GrueMaster: ^
<GrueMaster> I haven't seen it yet on Dove, but I had another issue to attend to.
<DanaG> weird... wine-ing "gpu caps viewer" reports a DIFFERENT version of MESA than native glxinfo reports!
<DanaG> 1.5 Mesa 7.7.1-DEVEL
<DanaG> er, wrong tab.
<DanaG> (a.k.a. wrong channel)
#ubuntu-arm 2010-03-17
<apw> ogra_cmpc, lool, we recently added CRAMFS to builtin i think for at least one of our arm bracches... what was the reason again?  initrd support perhaps?
<lool> apw: Yes; and it didn't help
<lool> apw: And I don't know what the issue is
<lool> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524893
<ubot4> Launchpad bug 524893 in qemu-kvm (Ubuntu Lucid) (and 3 other projects) "versatile: Can't boot initramfses (affects: 1)" [Low,In progress]
<apw> lool ... ok thank
<lool> apw: You can try with the images at http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/ and qemu-system-arm -m 256 -M versatilepb -cpu cortex-a8 -kernel vmlinuz -initrd initrd.gz
<lool> apw: Happy if you have any idea what's going on
<apw> looking at it whether it needs to built in for another branch, seems not, so good
<lool> ok
<lool> dmart: Could it be that ldr is causing SIGILL under qemu but it's really a SIGBUS?
<lool> dmart: disassemble shows that it's a "ldr r0, [pc, #24]"; I'm not sure what can go wrong here, I guess only the fact that it's not 4-bytes aligned?
<dmart> lool: hi, are we talking qemu-kvm or valgrind here?
<dmart> pc is rounded down to a multiple of 4 when used as a base in ldr in Thumb
<lool> dmart: It's under qemu-system-arm that I test, but it's a valgrind SIGILL AFAICT
<lool> dmart: Not sure what would cause the SIGILL then
<dmart> Hi, I posted another patch.
<lool> dmart: I have a debug session open here if it helps
<dmart> It looks like the code at _start is executed as ARM, not Thumb, so it's a real SIGILL
<cwillu_at_work> lool, could you pop your head into #ubuntu+1, and glare at thiebaude, and then leave again?
<dmart> The _start symbol needs to be properly tagged to solve this (as for ARM/Thumb interworking generally)
<lool> cwillu_at_work: thiebaude?
<cwillu_at_work> yes
<cwillu_at_work> he's using your name in vain
<cwillu_at_work> ah, he's gone now anyway
<lool> dmart: Oh so it's executing random instructions because it jumps into an assembly which was built as Thumb (our default) but is executed as ARM because it was not annotated properly as such; ok
<lool> dmart: This ARM/Thumb stuff is tricky
<dmart> lool: Yes, it looks like there is also some wrong code in m_syswrap/syswrap-arm-linux.c causing another SIGILL... I have a meeting now though.
<lool> I didn't quite grasp how the various memory locations are ARM or Thumb yet
<dmart> Normally you don't need to worry about the instruction set for the program entry point 'cause that's in crt*.o
<lool> cwillu_at_work:
<lool> cwillu_at_work: As in lol?
<cwillu_at_work> don't mind me, I'm goofy at this hour
<cwillu_at_work> (yes)
<dmart> lool: "I didn't quite grasp how ..." neither does the CPU ;)  so you need to tell it when you jump into code.  The toolchain tracks this by setting the bottom bit of the address of Thumb symbols, but proper tagging is needed to enable this.
<lool> dmart: Wee!
<lool> dmart: Doesn't SIGILL anymore
<lool> I get helpful output
<lool> Now need to start qemu-system-arm as qemu-arm wont cut it
<lool> dmart: Ok; after another similar fix than yours, I'm hitting "unhandled instruction"
<dmart> unhandled instruction: yeah, that would probably be the real "valrgind doesn't support Thumb-2" problems
<dmart> Unless you can eliminate *all* Thumb code (including crt*.o and friends and all libraries including libgcc), this will happen
<Sleep_Walker> hi
#ubuntu-arm 2010-03-18
<DanaG> http://pastebin.com/BFjBG4Ms
<DanaG> vlc segfaults.
<DanaG> er, sorry for the long command line. =Ã¾
<DanaG> interesting... mplayer is UNAVAILABLE
<DanaG> alsaplayer works, though.  once I add myself to "audio" group.
<asac> hi folks
 * ogra gets more coffee
<ogra> morning asac
<ogra> grmbl ... /me curses having to port uboot patches to redboot ...
<ogra> heh, fun ... the change i should revert in redboot-imx doesnt seem to exist in our version at all
<asac> hi ogra
<nosse1> My company are about to make a product based on TI AM3517 (ARM Cortex-A8) and we're going to run linux. We are considering putting Debian or Ubuntu on it because we want a package system/distro.
<nosse1> I forgot to say that I have a TI AM3517 ZOOM development kit
<nosse1> I have to admit that I'm quite new to Ubuntu build-system, so you'll have to excuse me for stuptid questions
<amitk> nosse1: welcome
<nosse1> The first one is linked to the choice of distro: When I have a Cortex-A8, wouldn't it then be most efficient (space and cpu) to use binaries for ARMv7? Which would implicate Lucid right?
<amitk> we've just started supporting OMAP3 kernels in the next release of Ubuntu
<amitk> nosse1: Lucid is guilty as charged
<nosse1> I started rootstock, and when it spawns qemu, it locks up my CPU at 100%. Is this familiar?
<amitk> ogra <--- blame him
<nosse1> I have no kind of feedback, so I don
<nosse1> ...don't know if it has locked up or doing something sensible...
<nosse1> (I'm running amd64 Karmic, and I've seen apps not working because I'm running 64-bit. Don't know if it's it, though)
<amitk> no, i use rootstock on 64-bit successfully
<nosse1> BTW: Are there a seed for ubuntu which is even more minimal than ubuntu-minimal? There's a lot of apps in minimal which is not applicable in my embedded target
<asac> nosse1: yes, the CPU issue is known
<asac> e.g. for qemu
<asac> investigation ongoing
<asac> seems its triggered by apt
<asac> or rather dpkg somehow
<nosse1> asac: But is it dead or processing something?
<nosse1> asac: Can I cat into its output somewhere?
<asac> nosse1: its dead. we think its qemu being broken
<asac> ogra: why is the bug not filed against rootstock nor qemu-kvm?
<nosse1> asac: Thanks
<asac> its bug 532733
<ubot4> Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733
<asac> nosse1: ^
<nosse1> I running Karmic on my host. Would it (not for this specific thing, but generally) be better to run lucid?
<asac> host system seems to make no difference afaict
<asac> its lucid vm that causes this
<nosse1> So when I'm using rootstock it also pulls down a lucid vm? I'm also pulling ubuntu-minimal and not ubuntu-netbook as noted in the bug report
<asac> interesting
<asac> but you are installing lucid?
<nosse1> yes
<asac> e.g. in the vm?
<asac> i suspect this to be a racy thing
<asac> the biggere the task is the more likely you hit it
<asac> for us ubuntu-minimal works usually, but netbook triggeres this
<asac> but i dontsee why ubuntu-minimal wouldnt cause this for some
<nosse1> I can probably strace it, but I'll have to leave for a meeting first...
<asac> what are your host specs?
<asac> e.g. what system is this running on?
<amitk> wouldn't it depend on the system specs too?
<amitk> aah, exactly
<nosse1> Ubuntu Karmic amd64
<amitk> nosse1: your HW spec
<asac> well. cpu mem etc.
<asac> maybe also disk speed etc.
<nosse1> Where can I find disk speed?
<asac> hdparams?
<asac> hdparm ;)
<nosse1> Intel C2Duo T9900, 3.06GHz, 8Gb RAM, Disk: 101MB/sec
<asac> well, but you could say: 5400 / 7200 / SSD etc.
<nosse1> 7200 for my case
<nosse1> I'm sorry, but I have to leave. I'll be back. Thanks guys
<asac> yeah. so from our findings it did go away if you slow down the system, so maybe your system is faster than ours (at least than mine it is)
<asac> so makes some sense that you see it earlier
<asac> ogra: your instructions dont work
<asac> e.g. the saved qemu image isnt good
<asac> getting unable to mount rootfs
<asac> sure root=/dev/sda?
<asac> I: Mounting temporary Image
<asac> I: ARM rootfs created as /tmp/qemu/armel-rootfs-201003181055.tgz
<asac> I: Qemu image saved as /tmp/qemu/qemu-armel-201003181055.img
<asac> i use that img
<asac> ogra: ^^
<asac> ok manually creating .img works it seems
<asac> why is the kept img broken?
<asac> hmm
<asac> "When no option is specified QEMU uses a non privileged user mode network stack that gives the emulated machine access to the world. "
<asac> that doesnt work for me
<asac> ogra: ^^
<asac> i can get an ip with dhclient
<asac> but not ping out
<asac> or wget
<lool> asac: ping is special though
<lool> asac: Which network type did you use?
<lool> telnet should work
<asac> lool: wget doesnt work
<lool> that's bad
<asac> next wanted to try a tap device
<asac> but hoped i didnt need that
<ogra> asac, what are the permissions of the img file (i havent uploaded the permission fix yet)
<asac> let me run again
<lool> asac: You don't
<asac> ogra: permissions flag?
<asac> what should be there?
<asac> ogra: oh thats about rootfs not working?
<lool> asac: ownership of the file needs to be the same as the user you're running the vm with
<ogra> well, chown the img file
<lool> and u+rw obviously
<asac> right
<asac> let me check
<asac> but i could boot it now
<ogra> the recent version saves the img as 666
<asac> ls -l ubuntu-arm.img
<asac> -rw-r--r-- 1 asac asac 2048000000 2010-03-18 11:22 ubuntu-arm.img
<ogra> that should work for the asac user at least
<asac> ogra: it boots
<asac> i doubt that permission has to do something with network
<ogra> so what exactly doesnt work
<asac> wget
<asac> after running dhclient
<asac> and getting ip ;)
<ogra> sudo dhclient eth0 ;)
<asac> apt-get update -> errors
<asac> ogra: well. read two lines above
<ogra> weird, works here
<asac> let me check host iptables
<lool> ogra: 666 uh
<asac> all open
<asac> 644
<lool> ogra: I seriously hope it's not 666, that'd be a major security issue
<asac> yeah. 666 seems overly open ;)
<ogra> sigh
<ogra> 644 *doesnt boot*
<lool> 666 it is   :-(
<ogra> and i have no way to make sure to know which user will use it in the end
<lool> Of course you do
<ogra> since you removed all references to run qemu with sudo
<ogra> lool, how, there are many people that use rootstock with cron
<asac> now network works ;)
<ogra> for daily local builds
<lool> ogra: I've been running qemu all this time without sudo; kees setup the same thing yesterday, and didn't use sudo either or had any permissions issues
 * asac likes things going away ;)
<ogra> lool, with a 644 img owned by root.root and no initramfs ?
<asac> ogra: why not chown to the user that called rootstock?
<asac> oh
<ogra> that would be cron for people doing daily builds
<asac> well, maybe rootstock should call sudo on its own to figure the real owner
<lool> ogra: Why would you want to own it by root?
<ogra> lool, because it was loop mounterd and created as root it gets the systems default permissions
<ogra> wich is 644 for the creating user
<lool> ogra: I personally create the image as myself, and sudo loop-mnt it
<asac> there is SUDO_USER ... so yeah. not sure why its a problem
<asac> you could add an option to command line for cron folks
<lool> Well either use SUDO_USER or actually only call sudo when you need to
<asac> so they can say: --image-user=USER
<lool> that's what I typically do in my scripts; they work as root or non-root, and call sudo when needed
<lool> (We actually already had this discussion)
 * ogra goes for asac's suggestion
<lool> asac: Let's have a cp --user option too!  :-)
<ogra> though i would prefer a more general fix ...
<lool> Anyway, I filed a bug on the usage of 666; please never do that
<ogra> its only in bzr yet, not in the archive
<lool> I filed a bug upstream
<ogra> fine, still, its a dev tree
<asac> it all depends on the common use case
<asac> i think using SUDO_USER makes sense
<asac> --image-user might make sense, but you can also write a wrapper script in cron that does that i would think
<asac> hmm
<asac> printf ... how do i just flush stdout?
 * asac tries
<asac> ok that worked ;)(
<asac> fflush stdout
<lool> Oh I thought you were asking in shell and was puzzled
<asac> heh
<asac> no
<ogra> hmm
 * ogra ponders how to package x-loader
<ogra> it sadly needs a fully configured uboot tree since the headers it relies on are generated by uboot configuration :/
<asac> punch it into uboot? ;)
<asac> or make uboot produce a -dev
<ogra> then i would need to merge the upstream tarballs
<ogra> -dev seems overly complicated ... especially in the light that we will need a -dev for each uboot flavour in the future then
<asac> right
<ogra> effectively i would like to have one uboot package based on upstream with lucid+1 (i.e. merge imx, omap and whatever else can use plain upstream or plain upstream with patches)
<asac> if its soo tightly coupled upstream then it belongs together for now
<lool> ogra: Really?
<lool> I don't remember building xloader against uboot
<ogra> so i dont want to bind to closely to the architecture for the omap package now, thats supposed to be the base for the merge
<ogra> lool, well, i tried for zoom and beagle, both look in the boot tree for headers
<lool> ogra: Which tree are you using?
<lool> I just git clone gitorious:x-load-omap3/mainline.git and then:
<lool> make CROSS_COMPILE=arm-none-eabi- distclean
<lool> make CROSS_COMPILE=arm-none-eabi- omap3530beagle_config
<lool> make CROSS_COMPILE=arm-none-eabi-
<lool> and that's all
<lool> I couldn't get the signed stuff to work
<lool> well not the gpsign one but signGP.c worked
<ogra> hmm, i pulled from the zoom tree, but that should essentially be the same (just with 3630 patches added)
<ogra> the zoom tree expected to find ../u-boot/....*.h for building the ift image
<ogra> (which you need for SD)
<lool> http://code.google.com/p/beagleboard/wiki/BeagleSoftCompile doesn't mention building uboot first either
<lool> ogra: What are you trying to build, the MMC version?  MLO?
<ogra> both
<lool> Err that's the same thing
<ogra> i want a binary with a NAND and a MLO version
<ogra> MOL has a dos header
<ogra> *MLO
<lool> MLO is the file which you write on your vfat
<ogra> right
<ogra> x-load.bin.ift is MLO
<ogra> x-load.bin is for NAND
<ogra> i need both
<ogra> and for creating the ift version the build uses the uboot header files for some reason
<lool> I'm not sure what the ift version is; I don't think I used that
<ogra> at least in the zoom tree, i'll try the mainliune one
<ogra> you cp .ift to MLO and cp it to your vfat to boot
<lool> Oh that's just the signed one
<lool> I know what you're trying to do now
<ogra> its essentially a dos command.com after the signing
<lool> You're trying to sign it with gpsign
<ogra> right
<lool> Which needs u-boot's headers
<ogra> right :)
<lool> Try signGP instead
<lool> it doens't need anything
<lool> and signGP didn't work for me anyway
<lool> http://beagleboard.googlecode.com/files/signGP.c
<ogra> well gpsign did
<asac> ogra: when you hang in qemu is qemu completely dead?
<asac> or can you ssh into it?
<lool> err gpsign didn't work for me rather, typo
<ogra> asac, i never tried to ssh, i use the graphical qemu version and switch to tty2
<asac> ogra: so you can still log in?
<ogra> yes
<ogra> thats how i can see top ps etc
<asac> send a signal to generate a core dump then please
<ogra> to see the defunct dpkg --unpack passing by
<ogra> what do you gain from a coredump without dbgsym ?
<asac> ogra: you generate a core dump
<asac> then install dbgsym to analyze
<lool> you can load a core dump with dbgsyms from another system
<ogra> right, but there are no symbols
<ogra> oh
<asac> first generate core dump
<lool> it doesn't matter, it's just a memory image
<asac> then install symbols and use gdb
<asac> right
<ogra> i'll try that later ... atm i want to get x-loader and uboot ready
<asac> sure
<asac> how do i start graphical qemu?
<ogra> use the command from rootfsfromscratch
<ogra> it fires up the SDL version by default
<asac> i am using qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda arm-rootfs.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
<ogra> with alt-2 you get insto command mode and use send-key ctrl-alt-f2
<asac> how do i switch to tty2 ?
<asac> ah
<asac> ok
<ogra> to get back just send-key ctrl-alt-f1
<asac> alt-2 == alt gr?
<ogra> its annoying ... but the only way
<ogra> alt and 2
<ogra> alt-1 gets you back to the VM
<asac> ogra its alt+f2 here :)
<ogra> weird, alt f2 gets me the gnome exec dialog here
<asac> you first have to click in the window ... so it grabs the input
<asac> then alt+f2345 etc works as usual
<asac> cool :)
<ogra> heh, i always did it through the command console
<ogra> because i'm annoyed if qemu grabs my mouse
 * asac runs bzip2 to preserve state before installing netbook
<asac> lets see how big it gets
<ogra> heh. yeah
<ogra> ./signGP x-load.bin 0x40208800
<ogra> make: *** [x-load.bin.ift] Error 36
<ogra> bah
<ogra> funnily it produces x-load.bin.ift
<asac> 100M
<asac> ;)
<ogra> sweet
<asac> me uploads
<asac> JamieBennett: all fine wfor the localization of .desktop?
<asac> e..g did you get the answers from pitti?
<asac> (or persia)
<JamieBennett> asac: working on it. Its a lot more involved that first thought after I talked with persia
<JamieBennett> and I'm learning how to do it for the first time
<asac> so dh7 isnt ready for that?
<asac> what a crap thing ;)
<JamieBennett> asac: no
<JamieBennett> I considered switching to CDBS
<asac> ok
<ogra> dont you just have to set gettext domain ?
<asac> dh7 really isnt ready? wow
<JamieBennett> but I have something that should be ready tomorrow
<ogra> i thought LP cares for the rest
<asac> ogra: we have cdbs langpack.mk
<asac> seems we have no equiv. for dh7
<JamieBennett> ogra: it was a simple wrapper script
<lool> langpack.mk is mostly useful to desktop packages which used cdbs so far; no pressure to port it to dh basically
<lool> but it should be done
<JamieBennett> now it needs a build system (setup.py)
<JamieBennett> and .po support
<ogra> bah
<JamieBennett> and gettext support
<JamieBennett> e.t.c
<lool> JamieBennett: which package is this?
<JamieBennett> lool: webservice-office-zoho (my package)
<lool> Truth is, the CDBS snippet should be a separate tool, perhaps a dh_langpack
<JamieBennett> lool: I'm looking through doc, web pages, snippets of code trying to learn it too which doesn't help
<lool> JamieBennett: You could copy what you need to some dh override
<lool> JamieBennett: e.g. override dh_gencontrol
<JamieBennett> lool: but would that be 'the proper way' ;)
<lool> JamieBennett: Best way would be to add support to dh to do that automatically
<lool> JamieBennett: But we have packages where we call intltool-update by hand because they are not CDBS based
<lool> e.g. http://paste.ubuntu.com/397186/
<lool> perhaps not very good examples actually
<asac> current cdbs does stuff in binary-predeb
<asac> ogra: http://people.canonical.com/~asac/tmp/ubuntu-arm-lucid-minimal.bz2 ;)
<ogra> great
<ogra> i have several of these around though ;)
<asac> then why didnt you give them to me ;)
<asac> thought you didnt have that online
<ogra> i dont have them online
<ogra> and we only discussed the compressing yesterday :)
<asac> ah
<asac> right. so now we have it ;)
<ogra> yeah
<asac> sigh ... i used 2G onlz
<asac> thats not enough for netbook i think
<lool> asac: You can grow it
<asac> lool: command?
<lool> asac: dd if=/dev/zero bs=1M count=200 >> lucid.img; e2fsck -f lucid.img; resize2fs -p lucid.img
<lool> that's for a raw image
<lool> (not sure whether you're using qcow or something)
<asac> i use raw image with ext4
<lool> no part table?
<lool> then the above should work
<asac> let me try
<asac> not much to loose
<ogra> rootstock doesnt create partitions
<lool> Yeah, worst case you have 200MB of zeroes at the end
<ogra> but creates ext3 by default
<ogra> (or did i change that ?)
<asac> ogra: i didnt use the img from rootstock, but made my own and untarred ;)
<ogra> ah, but you used rootstock to create the tarball ?
<asac> yes
<asac> ok booting with new size
<ogra> (i just wnt to be sure we're not to far away from the rootstock creation here when we try to debug)
<ogra> thought its still weird that lool never saw that issue
<asac> ok it worked
<asac> now have 3g
<ogra> that should suffice
<ogra> i think even 2 would for armel netbook
<asac> wasnt enough
<ogra> (we dont have oo.o in the task)
<asac> it wanted to install 1.8G after ubuntu-minimal
<asac> and i only had 1.6G left or something
<ogra> hmm, the task never wants to install that much for me
<asac> its 1835MB
<asac> so less than 1.8G ... but not much
<asac> ^ubuntu-netbook
 * ogra wonders if there is a size difference between task and metapackage
<ogra> doesnt the caret need to be at the end ?
<lool> asac: Are you trying to reproduce the problem or just analyze the core file?
<asac> lool: want to reproduce and produce core files for now
<asac> yes.
<asac> lool: i already reproduced it here at some point
<asac> furhter above there was someone who saw this even for ubuntu-minimal
<asac> i think the faster the system is the easier you get it (race)
<asac> as we dont see it with dbgsym installed according to ogra
<ogra> right
<ogra> installing dbgsym just makes it pass
<lool> That's odd
<ogra> i have never seen it in -minimal though
<ogra> and i havent tried -desktop since we do -netbook
<ogra> rcn-ee, you see the hang in rootstock too, right ?
<rcn-ee> ogra, ah maybe, it's still halting at "|: Extracting zlib1g..." for me.. ;) debian qemu.. http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log  but it worked just fine yesterday on karmic...
<ogra> yes, its a lucid issue
<ogra> though that is something different i think
<rcn-ee> yeah i was guessing that, i need to setup a karmic chroot on my server...
<ogra> do you have a full log too ? (the one that rootstock spits out if you ctrl-c)
<rcn-ee> so you guys have fun building xloader/uboot for omap?
<ogra> the prob is when building lucid ... not with lucid on the host
<ogra> rcn-ee, well, fun is something different :) but yes, i'm fddling with that
<rcn-ee> sorry, nope, it's a cron job, no terminal, and it doesn't occur when run from the command line...
<ogra> ah
<amitk> rcn-ee: I've seen the hang at zlib1g on karmic too
<amitk> oops, ogra ^^
<ogra> well, this hang is clearly not the same one
<asac> why?
<rcn-ee> ogra, under what conditions is it hanging now?
<asac> i thought we hang in unpack too
<ogra> unpacking of zlib happens in debootstrap which is run in the qemu-arm-static chroot
<ogra> while the task installation hangs in a VM
<asac> hmm. but why wouldnt an io issue in qemu never show up in qemu? maybe its just less easy to trigger because its a fresh process for every command?
<rcn-ee> and what's weird, i had the same issue when building google's x86 os where it would hang on the same file, only x86.. ;)
<asac> err second qemu==qemu-static
<ogra> well, i have never seen it hang in karmic builds at all ... thats very new
<asac> ogra: they install lucid .... didnt you say the host qemu doesnt matter?
<ogra> but i definately can reproduce the netbook task install hang reliably in lucid
<ogra> asac, right
<ogra> host doesnt matter
<rcn-ee> yeah no luck on netbook here either.. ;)
<asac> so that they see something like this in karmic qemu when trying lucid doesnt feel that off based on that
<ogra> but target lrelease of the build does
<asac> right. armv7+thumb2
<asac> in lucid
<ogra> xactly my suspicion
<asac> lool: why are you sure that armv7+thumb2 is working perfect in qemu?
<asac> or arent you sure?
<ogra> asac, you mean kernel wise
<ogra> ?
<asac> no ... qemu in general for now
<asac> as rcn-ee sees it in static
<ogra> i dont think qemu matters here
<ogra> asac, but building a karmic image (unless i misunderstood)
<asac> ogra: the log is named lucid from above: http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log
<ogra> i could imagine that the verstile kernel we use doesnt properly support thumb2
<ogra> asac, oh
<ogra> " but it worked just fine yesterday on karmic..."
<asac> its probably a karmic qemu trying to run armv7/thumb2 code
<ogra> that confused me :)
<asac> hmm
<asac> rcn-ee: so what are you doing?
<asac> host = karmic + target == lucid?
<asac> or both karmic / lucid ?
<rcn-ee> ah crap, my naming confused everyone... host debian squeeze, running latest rootstock building ubuntu-netbook for lucid target... ;)
<asac> yeah
<ogra> debian squeeze ?
<asac> so target is lucid
<ogra> aww
<ogra> thats a totally differend qemu then i think
<asac> didnt lool land some arv7 stuff here?
<asac> and not in debian? or are we in sync?
<rcn-ee> just checking on that, it's qemu 0.11.1...
<ogra> well, lool usually does his qemu stuff upstream
<ogra> but we pull from a different upstream afaik
<ogra> because of kvm
<rcn-ee> and the opteron server i have is too old for kvm...
<ogra> 0.12.3-0ubuntu15
<ogra> thats what we have in lucid atm
<ogra> but pulled from qemu-kvm since karmic
<ogra> rcn-ee, well, kvm doesnt gain you anything for armel emu ... but the point is that we use a different upstream
<asac> rigt. thats wat busted ftas images and he lost everything ;)
<ogra> the question is how much difference there is
<ogra> especially for armel
<rcn-ee> correct... i just use it to verify nightly builds.. it was working early in lucid's cycle, maybe stoped in the last two months.. otherwise i build on karmic exclusively at work.. ;)
<ogra> yeah, i dont test on debian ... so i dont really know if it would work or not
<asac> ok hangs in iputils-tracepath here
<ogra> minimal should work if you build on ubuntu host for all releases we support
<ogra> asac, right, same here
<ogra> that pretty reproducable
<ogra> not 100% though ... there is another package it sometimes hangs ...
<ogra> iso-codes iirc
<nosse1> hi, guys. Back in business!
<ogra> but i have only seeing it hang on either of these two yet
<lool> asac: Sorry, I dont understand your question?
<lool> asac: There might be qemu bugs
<asac> ok
<rcn-ee> it's been a toss up between iputils-tracepath and iso-codes for me..
<lool> I wonder whether a FS benchmark would show a similar issue
<nosse1> Have you come any closer to investigating the qemu hang? Is there anything I can assist with?
<asac> lool: i ran a read/write testcase here today for 1h
<asac> e.g. just reading and writing all the time
<asac> that didnt have issues
<ogra> lool, but are you sure that just telling the versatile kernel that it is a v7 CPU also enables all features properly (thumb2 etc)
<asac> lool: which fs benchmark would you suggest?
<asac> ok so now ... which process should i core dumb ;)?
<asac> probably all dpkg/apt ones
<ogra> i mean i see them in cpuinfo  ... but is it sure they actually work by just telling the kernel it is v7 ?
<asac> not sure if i get the core from all though at the same time
<lool> ogra: Uh the whole userspace works
<ogra> well, apt is the one that hangs
<lool> ogra: All our programs are running in thumb 2 mode aren't they
<ogra> lool, yes
<ogra> so you think other SW would expose issues too ?
<lool> asac: Dunno, some kernel fs benchmark to cause high IO
<lool> ogra: other SW?
<ogra> (if it was kernel side)
<ogra> other apps
<lool> ogra, asac: One thing you folks could try to workaround the issue are different disk emulation in qemu; e.g. cache=none, cache=writeback, etc.
<rcn-ee> aren't some packages, still in arm mode?
<ogra> rcn-ee, very very few
<lool> ogra: Well it might be a dpkg / apt bug exposed by our testing conditions or a qemu bug which triggers under high IO circunstances, perhaps a race
<lool> ogra: I can't tell
<ogra> yeah
<asac> its definitly racish
<asac> ok i have a core ... not sure if it was the apt or dpkg core though
<ogra> i'm close to say its a race ... apt hanging in read() and the issue going away with dbgsym installed point very much to it
<ogra> also the I/O isnt blocked if you work from another tty
<ogra> while the hang occurs
<nosse1> Is there a way I can circumvent the qemu-lockup from rootstock, so that I can build my ubuntu-minimal image?
<ogra> nosse1, juts ubuntu-minimal should actually work
<asac> nosse1: is the hang in second stage?
<asac> then try another disk emulation as lool suggested above
<nosse1> asac: Yes. "Switching to Virtual Machine for second stage processing"
<ogra> nosse1, do you have a full log ?
<asac> nosse1: then try to do that
<lool> Another way might be to have a while sync; do sleep 1; done loop on another vt while doing the install
<nosse1> ogra: Where can I find the log? Is it the rootstock-xxx.log file?
 * lool lunch &
<ogra> nosse1, right, rootstock should have told you it created the file when you stopped it (or it successfully finised)
<ogra> can you put it somewhere so i can take a look where exactly it hangs
<nosse1> The log files doesnt actuall tell anyting.. It shows the output from a wget session. Then "I: Killed ..."
<ogra> whats your host os ?
<nosse1> Karmic amd64
<ogra> hmm, amd64
<ogra> do you use the rootstock package from the archive ?
<nosse1> yes
<ogra> and you try to build lucid ?
<nosse1> yes
<ogra> ah
<ogra> thats fixed but not backported to karmic
<nosse1> should I up my host to lucid then?
<ogra> http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/revision/31
<ogra> the rootstock scrip needs this fix
<ogra> (currently karmic can only build karmic)
<ogra> (without this fix)
 * ogra tries to find some food
<nosse1> The ultimate goal of this is to throw Ubuntu into an embedded product which will go into mass production. What is the state of Ubuntu Lucid for ARM?
<nosse1> The product is at least 12-14 mnths away from release
<asac> nosse1: lucid for arm is quite good. we release beta today
<asac> rootstock is busted though ;)
<asac> there are a few ftbfs and thumb2 porting issues outstanding
<nosse1> Since we're using a Zoom TI AM3517 evaluation kit as a base, is there something I can do to contribute for support for that exact kit?
<nosse1> Pardon my silly questions, I'm quite new to the development flows of Ubuntu :o
<asac> nosse1: yes, testing like you do now is good. also checking if there is software for that that isnt in the archive would help (besides the kernel/bootloader)
<nosse1> I see from the topic that "no, we do not cross compile"? What do you mean? That all packages are built natively on some target/emu?
<asac> nosse1: we build natively on real machines
<asac> nosse1: if there are particular software you need to cross compile let me know which software that is
<asac> currently collecting the main use cases we should support in some way
<asac> nosse1: here you can see our build farm: https://edge.launchpad.net/builders
<nosse1> we will have Qt (>=4.6) running, but if it need cross compile I'm not sure yet
<asac> nosse1: is that newer than in ubuntu?
<nosse1> than karmic, yes. I havent checked lucid yet
<asac> we have Version: 4:4.6.2-0ubuntu
<asac> in lucid
<asac> at least thats the version for libqt4-dev
<asac> so thats already precompiled in lucid for you
<nosse1> Thats latest release from Qt
<asac> if you have fixes for that that you need to get in and that are general issues we can try to get that patched
<rcn-ee> * heads off to work, needs to stop playing with the xm board and send amit some usb/musb patches for omap..
<ynezz> how's xm? :)
<rcn-ee> i like it. ;)
<nosse1> I'm a little uncertain how the rendering system should be done in Qt and/or X11. Because the SDK to access the HW GFX accelerators are not open source
<asac> nosse1: so to get unbut-minimal all you need to do is to create it from lucid (not debian)
<asac> that definitly works for everyone here
<nosse1> Yes! The patch to rootstock worked!
<nosse1> How can I install or sign up for a builder in the build farm?
<nosse1> I mean, the process from making a source package up until it ends up in a apt tree is really unknown to me
<nosse1> Because we will have to make our own apt tree for the closed applications and such
<ogra> ogra@osiris:~/Devel/branches/omap$ sudo build-arm-chroot lucid /mnt http://192.168.2.87:9999/ubuntu-ports
<ogra> W: Target architecture is the same as host architecture; disabling QEMU support
<ogra> lool, that seems broken
<ogra> either drop build-arm-chroot or make it set --arch armel
<amitk> ogra: omap image? :-p
 * amitk hides
 * ogra hits amitk with a rootstock
<ogra> :)
<amitk> :)
<amitk> the kernel should the archive tomorrow
<amitk> *hit the archive
<ogra> great, i'll make sure x-loader and uboot are uploaded before end of day tomorrow
<ogra> and will work on cdimage scripts on the weekend
<armin76> you guys doing omap support now?
<DanaG> OOooh.
<DanaG> heh, every time I try to compile a "newer" u-boot (u-boot-omap) for my beagleboard, I find it mistakenly detects it as Board Revision Ax/Bx (instead of C4, as it should be).
<DanaG> hmm, what benefit do a newer u-boot and/or x-loader give?
<DanaG> http://pastebin.com/BFjBG4Ms --  vlc segfaults.
<DanaG> er, sorry for the long command line. =Ã¾   Oh, and mplayer is UNAVAILABLE.
<DanaG> heh, I left in my sd card with Angstrom (ew) on it, and grub on my host "Found unknown Linux distribution on /dev/mmcblk0p2
<ogra> DanaG, mplayer is availabel in multiverse
<DanaG> hmm, I'll check sources.list.
<ogra> for vlc, please file a bug
<ogra> (and hope that someone from the community puts some work into it)
<DanaG> How do I trigger apport via CLI?
<ogra> ubuntu-bug vlc
<ogra> should work
<DanaG> Will it get the gdb output?
<ogra> if there was a crash file file created it will just attach it
<DanaG> Cool.
<ogra> check /var/crash/
<DanaG> nope, no vlc .crash file.
<DanaG> also, when trying to run amttool on the beagle:
<DanaG> Can't locate SOAP/Lite.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at /usr/bin/amttool line 4.
<DanaG> BEGIN failed--compilation aborted at /usr/bin/amttool line 4.
<ogra> looks like a missing dependency ...
<ogra> a bug as well
<ogra> the community support for apps in universe under armel isnt that great yet
<ogra> (any help appreciated :) )
<DanaG> hah, nvidia-kernel-common exists on ARM restricted.
<DanaG> heh, and so do things like virtualbox-guest-additions.
<KingMuty> yo
<DanaG> weird... ssh into beagleboard and run mplayer... it outputs LOCALLY to pulseaudio on the ssh client.
<DanaG> ah, had to un-export DISPLAY=
<lool> ogra: build-arm-chroot does set arch == armel
<ogra> lool, didnt for me
<lool> ogra: But you're running this on arm, right?
<ogra> no
<ogra> i just tried to quickly build an arm chroot
 * DanaG wishes he had a spare DVI display.
<lool> ogra: Ah I know what happened
<DanaG> Right now, my beagleboard is entirely headless.
<ogra> lool, it also doesnt throw the deprecation warning
<lool> ogra: uploaded
<lool> ogra: http://paste.ubuntu.com/397356/
<ogra> lool, hmm
<ogra> lool, i didnt run build-arm-chroot with a path
<lool> ogra: sudo added one
<ogra> oh
<ogra> indeed :)
<KingMuty> yo
<ogra> ghurt
<KingMuty> juje
<KingMuty> http://blokker1999.info/andromnia/README.txt
<KingMuty> dis ewe do?
<KingMuty> ewe no talk?
<ogra> KingMuty, try #andromnia
<KingMuty> ok thx
<KingMuty> dey iz dead! :'(
<DanaG> interesting... so, if I wanted to have pulseaudio run as my local user... how would I make it auto-start on a headless thingy?
<DanaG> now, here's something funny to do:
<DanaG> screen /dev/ttyUSB0 115200 on host, to beagleboard serial port.
<DanaG> now run byobu within that.
<DanaG> And then within byobu... use amtterm to go back to the host.
<DanaG> ... and then run another byobu there.
<DanaG> or even better... make the first "screen" a byobu, too.
#ubuntu-arm 2010-03-19
<DanaG> oh yeah, so are we going to have an omap kernel in the repos?
<DanaG> argh, not enough free space on my sd card for a whole kernel tree.
<DanaG> And no cross-compiler in the amd64 host's repos.
<rcn-ee> yeap, it looks like it.. just emailed amit the usb config changes. ;)
<DanaG> oh yeah, I hope it'll have the usb-audio gadget, and such. =Ã¾
<DanaG> the rcn-ee kernel doesn't have those.
<rcn-ee> laughs, what's the config change, and it will. ;)
<DanaG> here are the lines I see relevant in the config right now:
<DanaG> CONFIG_USB_ETH=y        CONFIG_USB_ETH_RNDIS=y       CONFIG_USB_ETH_EEM=y        # CONFIG_USB_GADGETFS is not set        # CONFIG_USB_FILE_STORAGE is not set        # CONFIG_USB_MASS_STORAGE is not set        # CONFIG_USB_G_SERIAL is not set        # CONFIG_USB_MIDI_GADGET is not set        # CONFIG_USB_G_PRINTER is not set        # CONFIG_USB_CDC_COMPOSITE is not set        # CONFIG_USB_G_MULTI is not set        CONFIG_USB_OTG_UT
<DanaG> Which ones to enable, is partly subjective.
<DanaG> oh, and the audio one doesn't seem to be there.
<DanaG> time for some googling.
<DanaG> http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:usb-gadget:audio
<rcn-ee> those can be tricky..  if you look in my 2.6-stable repo, under patches/rcn/ there is a 002-defconfig-disable-ga***.diff, basicly you can break usb based rootfs on bx and c2 boards.. ;)
<rcn-ee> sd card based rootfs don't care. .;)
<DanaG> hmm, which repo should I clone, to go experimenting with the stuff?
<DanaG> I'm curious how that file gadget thingy works.... what does the host see... a raw disk, or some magic files?
<rcn-ee> 2.6-stable is 2.6.32, 2.6-dev is 2.6.33, 2.6-mailine is broken (2.6.34-rc1) and lucid-ti-omap is what ubuntu will have.
<DanaG> oh, and one issue I do notice: [10468.479431] Class driver suspend failed for cpu0
<DanaG> hmm, I do see... allowing raw disk access from both host system and the ARM device... sounds like a way to have Very Bad Things happen.
<DanaG> =Ã¾
<DanaG> oh, I see... it's file-backed, not raw-disk-backed.
<rcn-ee> yeah it does, i did that on an 8-bit usb micro to see what would happen.;
<DanaG> 8-bit usb micro? micro-sd card?
<DanaG> http://www.linux-usb.org/gadget/
<DanaG> Oooh, u-boot environment vars for MAC address and such.
<rcn-ee> oh, it was an avr 8bit usb micro, was messing around with usb file systems..
<DanaG> er, wait, no, they just go to cmdline. =Ã¾
<DanaG> I'm curious how the audio gadget would work... playback to device from host would appear as an input stream on the guest, I suppose.
<DanaG> oh yeah, and for rndis in win7 64-bit, you can just manually choose "RNDIS-Compatible" in device manager -- and it's even signed.
<rcn-ee> i'm guessing it would be just like those cheap usb 5.1 audio plugins, the beagle would play the stream..
<DanaG> I have one of those USB sound cards (CM106).
<DanaG> It does some rather weird stuff.
<DanaG> http://pulseaudio.org/ticket/678
<DanaG> also weird: there's no kernel here -- http://rcn-ee.net/deb/kernel/beagle/lucid/v2.6.33.1-dl.2/
<rcn-ee> yeap, i messed up the script last week and didn't clear the queye.. ;)
<DanaG> I wish the beagleboard had more audio outputs.
<DanaG> ... or would at least hide the non-relevant stuff in the hideously complicated mixer. =Ã¾
<rcn-ee> when one of those missing stuff, just take a look at: http://rcn-ee.homeip.net:81/dl/farm/log/  shows the status of my farm.. ;)
<rcn-ee> basicly the *.deb file wasn't spelled exactly as i was expecting.. .
<DanaG> oh, and ureadahead main process terminates with status 5 -- happens on my host system, too (drm-next kernel).  Does ureadahead need some non-upstream patches?
<rcn-ee> it's chewing on that one right now.. http://rcn-ee.homeip.net:81/dl/farm/log/BUILDING-2.6.33.1-dl2_1.0-lucid.txt  should be done in another 4-5 hours...
<rcn-ee> yeah it does...
<DanaG> It also breaks the plymouth splash on my host.  And makes it slow to log in.
<DanaG> oh yeah, and thank you greatly for making those kernel and rootfs images available -- it's a great help for using the board.
<rcn-ee> or i thought it did... http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/ti-omap  i'm going blind...
<DanaG> also funny on ARM: things like nvidia-kernel-common and virtualbox-guest-additions still exist.
<rcn-ee> i've had reports that "console-setup-mini" greatly speeds up serial prompt login...
<DanaG> I've come to have a great appreciation for serial console -- my host laptop has serial-over-lan; awesome for grabbing stacktraces.
<rcn-ee> yeah there's a lot of funny ones, libdrm_intel/radeon/etc.. plymouth actually kinda worked for me today on bootup... although it didn't go any farther..
<DanaG> I got a kernel panic on my other laptop (a netbook)... and had NO way whatsoever to get a full stacktrace.
<DanaG> I'm using drm-next on the host, for the sake of radeon KMS power-management.
<rcn-ee> me too, i'm torn between getting the xm beagle working or test agd5x's new pm patches.. ;)
<DanaG> I'll wait for it to go into the kernel-ppa stuff.
<DanaG> oh yeah, does xm have gigabit ethernet, or just 10/100?
<rcn-ee> not sure, it's smsc and i'm guessing 10/100..
<rcn-ee> lan9514
<rcn-ee> cool, it's a usbhub/usbethernet.. so it should be faster then micrel's zippy2...
<DanaG> SPI ethernet strikes me as weird.
<rcn-ee> it is... but it's perfect for ethernet enabling a pic 8/16bit...
<DanaG> That 3-port-hub-with-ethernet that specialcomp.com sells is pretty cool -- it's also what the macbook air should have come with. =Ã¾
<DanaG> oh yeah, do you have the monochrome LCD from specialcomp.com?  I couldn't quite figure out how you'd tell the kernel to use 480x272.
<rcn-ee> nope i don't.. usually headless installs.. are you connecting between the lcd pins or hdmi connector?
<DanaG> er, a classmate has it (and is going to try it this weekend); it goes to the lcd-controller pins and expansion connector.
<rcn-ee> not sure..  it's the one thing i haven't spent enough time trying to do a one of these boards..
<DanaG> what I've done with mine so far: mostly just mess around with pulseaudio.  It works awesomely well even over usb-net.
<rcn-ee> yeap, that was too easy.. xm still locks..
<DanaG> Do you talk to the people who do the kernel-ppa stuff?  I've noticed that it has all of STAGING disabled, as well as CONFIG_MMC_RICOH_MMC.
<rcn-ee> I think they use the same config as the offical release, so what ever was enabled, gets enabled...
<DanaG> .config:2069:warning: symbol value 'm' invalid for MMC_RICOH_MMC .config:4418:warning: override: reassigning to symbol STAGING
<JaMa> Hi, https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/535183 patch V2, which was now included in upstream pixman http://cgit.freedesktop.org/pixman/commit/?id=18f0de452dc7e12e4cb544d761a626d5c6031663, checks for uqadd8 with forced -marm, which means that when we build that binary with thumb enabled, then it will contain not available uqadd8 and fail with SIGILL on ie armv4t
<ubot4`> Launchpad bug 535183 in pixman (Ubuntu) "pixman doesn't autodetect SIMD support at build time on arm. (affects: 1)" [Undecided,Fix released]
<JaMa> If you really want to do it this way, then there should probably be -marm also in coresponding ARM_SIMD_CFLAGS="-mcpu=arm1136j-s"
<JaMa> ah, there is -marm in ARM_SIMD_CFLAGS but somehow not used somewhere..
<persia> JaMa: Am I reading the patch incorrectly?  I'd expect the failure to unset have_arm_simd=yes, so that it wouldn't compile that bit in.
<persia> I think we're expecting that failure for ARMv4t, so that ./configure can do the right thing.
<JaMa> persia: but that 2nd run, detects uqadd8 usable but with -marm in CFLAGS
<JaMa> persia: and than it builds pixmap probably without forced -marm (ARM_SIMD_CFLAGS is maybe used only in this configure test)
<JaMa> persia: and resulting thumb binary is created with supposed uqadd8 support
<JaMa> persia: trying that patch v1, which looks safer to me
<persia> But shouldn't the second run only happen if the first run is successful?
<lool> JaMa: are you setting -mthumb via CFLAGS?
<lool> JaMa: see <20100314172510.GA3901@bee.dooz.org> on pixman@lists.freedesktop.org
<JaMa> lool: yes
<JaMa> here is my config.log http://paste.pocoo.org/show/191446/
<lool> http://article.gmane.org/gmane.comp.graphics.pixman/59
<lool> JaMa: So I think configure is kind of doing the right thing here, but in an ideal world we could avoid it
<lool> JaMa: You're using CFLAGS which in autotools is an override over the per-file and global upstream CFLAGS
<lool> JaMa: So even if we try with proper -mcpu= and -marm, it doesn't build because you override with -mthumb; perhaps the check could build the piece of code with a newer CPU and -mthumb as well to cover this case more nicely though
<lool> It's a bit ugly as it is, and would make it worse I guess
<lool> ideally, we'd move the code to a separate .S file and turn on what we need in there
<JaMa> this is crosscompile build with OE, so I work-arounded it with --disable-arm-simd for now, but thanks for help, I'll try better, but now I have to go to work..
<lool> Ok
<lool> I don't think you should have to --disable-arm-simd; it should be the default?!
<JaMa> lool: after this commit it changes detected value from No to Yes
<JaMa> lool: so with --disable-arm-simd only for armv4t I'm forcing it to stay disabled as it was before
<JaMa> lool: as -mthumb was there for all builds before and after
<lool> Your config.log indicates USE_ARM_SIMD is false?!
<JaMa> lool: yes for 933540861383da27402680593edefe8d61e6fb02 and older
<lool> Oh, that's an older config.log
<lool> well I'm interested in a newer one  :)
<JaMa> lool: but that's I guess expected, because before it wasn't tried with -marm, mmt I'll pastebin new
<JaMa> 933540861383da27402680593edefe8d61e6fb02 http://paste.pocoo.org/show/191449/
<JaMa> 18f0de452dc7e12e4cb544d761a626d5c6031663 http://paste.pocoo.org/show/191450/
<JaMa> and now really off, see you in an hour or so
<lool> that's odd, I see only one compile with -mcpu=arm1136j-s, not the one wihtout
<lool> JaMa: So it detects it, and then it fails to build?
<persia> Hrm?  That test certainly looked like "compile without, on success, compile with, on success, set variable"
<lool> I wonder why it's called as:
<lool> arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -mcpu=arm1136j-s -marm
<lool> I wrote: CFLAGS="$ARM_SIMD_CFLAGS $CFLAGS"
<lool> So I would think it should look like arm-oe-linux-gnueabi-gcc -mcpu=arm1136j-s -marm -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c
<lool> which should fail
<persia> Could it potentially be doing $COMPILER_DEFAULT_CFLAGS $USER_SUPPLIED_CFLAGS ?
<lool> $COMPILER_DEFAULT_CFLAGS doesn't appear on the cmdline usually
<persia> True.  Hrm.
<persia> Looking at the command line, I wonder if maybe the -march and -mtune stuff is added later, using the same $NEW_CFLAGS $CFLAGS approach.
<persia> They all seem to be based on arguments passed to configure.
<persia> But I'm grasping at straws at this point.
<lool> it seems configure is playing clever with the args
<lool> arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -isystem/OE/tmpdir-dev-shr/staging/armv4t-oe-linux-gnueabi/usr/include
<lool> and then arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -mcpu=arm1136j-s -marm -isystem/OE/tmpdir-dev-shr/staging/armv4t-oe-linux-gnueabi/usr/include
<lool> so clearly the only way for flags to end up in the middle is that someone reorders them
<persia> Indeed.  That is being overly clever.
<lool> and it's done before running CC since the flags only appear once
<lool> Well, I'm tempted to walk away in disgust   :-)
<lool> ah perhaps I'm actually wrong
<lool> -include stuff might be CPPFLAGS
<lool> ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'
<persia> Aha!
<persia> So $CC is the culprit.
<persia> $CC is evaluating to "arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb"
<persia> Followed by -c $CFLAGS $CPPFLAGS
<lool> JaMa: So you're setting the flags in CC, not in CFLAGS?
<ssvb_> JaMa: are you getting pixman build failure or SIGILL at runtime?
<JaMa> ssvb_: SIGILL at runtime
<JaMa> lool: yes it's in CC
<JaMa> lool: here is whole environment, how bitbake runs configure http://pastebin.ca/1845506
<ssvb_> JaMa: that's pretty bad, looks like runtime cpu features detection is failing for you
<ssvb_> JaMa: can you add some debugging stuff in pixman-cpu.c to check whether/why 'arm_has_v6' variable gets set to true?
<persia> JaMa: What breaks if you put that stuff in $CFLAGS instead of in $CC ?  Having it in $CC subverts the test, causing the issue.
<JaMa> ssvb_: runtime? this is crosscompile build and SIMD wasn't enabled before, so SIMD code should workarround missing uqadd8 in runtime?
<ssvb_> JaMa: I know that autodetection was behaving weird in qemu
<JaMa> I don't use qemu here..
<ssvb_> JaMa: so you haven't run your binary on real device yet?
<JaMa> it works ok if I disable simd wiht --disable-arm-simd and probably also work if I disable thumb for whole pixman
<ssvb_> JaMa: if you don't want any armv6 simd optimizations and want to save some space, --disable-arm-simd is your choice
<JaMa> the same bitbake build for armv5te works ok without any work-arround and with thumb enabled
<ssvb_> JaMa: what is your definition of 'works ok'?
<JaMa> ssvb_: that's what I used before, but I'm asking why it's autodetected now as available (not respecting -mthumb, well in wrongly used CC)
<JaMa> ssvb_: works ok = no SIGILL on device and Xorg running ok
<JaMa> ssvb_: doesn't work at all = SIGILL when starting Xorg
<ssvb_> JaMa: so can you confirm SIGILL?
<JaMa> ssvb_: yes
<JaMa> ssvb_: that was first message I sent here :)
<ssvb_> JaMa: I just wanted to have a confirmation
<ssvb_> JaMa: do you have any way to debug this stuff on the device?
<JaMa> ssvb_: and I already prepared --disable-arm-simd builds to get usable device again, because it "restores" old behavior for armv4t with thumb forced
<ssvb_> JaMa: function 'pixman_arm_read_auxv' is the most likely culprit if it detects availability of armv6 instructions wrong
<JaMa> ssvb_: and do I really want simd enabled? as you already said I probably don't need it, so I can debug it, but I'm not sure it's worth it
 * lool is back
<ssvb_> JaMa: yes, if you don't want to debug this issue, then you can use this as a workaround for sure
<lool> JaMa: So to recap, two issues here: one is SIMD gets turned on as intended when CFLAGS allow it (CFLAGS override CC, so it's correct); this is working as expected; second issue is runtime detection which triggers a SIGILL on your device, that's a bug
<ssvb_> JaMa: what I wanted to know is whether 'arm_has_v6' variable evaluates to true (that would be one possible bug), and if it is not, then where exactly is the location of the wrong instruction
<lool> JaMa: In practice you don't care about SIMD, but perhaps you care that everybody with the same use case as yours doesn't have to pass --disable-simd
<JaMa> lool: why cannot you pass -marm to CFLAGS if SIMD is enabled only in that second run?
<JaMa> lool: this would if I get you right, enable working simd for cost of overriding thumb from CC
<lool> JaMa: That's what's happening actually
<lool> JaMa: which is why you can build and run it
<JaMa> lool: but only in conftest not build
<lool> That should be the case during build
<JaMa> mmt I'll check
<lool> JaMa: Note that it's only used to build a couple of files
<lool> Only one actually, -pixman-arm-simd.c
<JaMa> lool: with -mthumb moved from CC to CFLAGS, configure detects simd as "no"
<lool> JaMa: Yes
<lool> JaMa: that's a limitation due to the fact that user-specified CFLAGS override our CFLAGS
<lool> JaMa: But as ssvb_ points out, the bug here is a runtime one; the only real life problem we're seeing is that you get a SIGILL, and it's not clear why
<lool> it would seem the detection code reports v6 as present at runtime while it's not
<JaMa> this is how it fails http://pastebin.ca/1845518
<ssvb_> JaMa: can you also add 'info registers' output?
<JaMa> ssvb_: sure mmt, have to reinstall faulty version
<lool> I wonder whether it's a thumb/non-thumb issue
<JaMa> I think so
<lool> JaMa: What's your CPU again?
<JaMa> samsung s3c2442 ARM920T rev 0 (v4l)
<lool> JaMa: and in configure output, do you get NEON detected or not detected?
<JaMa> lool: neon is disabled with configure option
<JaMa> with thumb disabled in OE (resulting in -mno-thumb in CC) no SIGILL, but SIMD is detected as disabled, so it's not interesting case
<lool> that's odd
<lool> it should turn on SIMD if you only set -mno-thumb in CC
<lool> (but not in cflags)
<persia> JaMa: If you run that ./configure natively, does it work as expected?  (I don't expect a real compile, just curious if it's an OE-only thing, or a hardware thing).
<ssvb_> JaMa: do you have -mthumb-interwork option somewhere?
<lool> ssvb_: Oh good point
<ssvb_> JaMa: I wonder if not having it may also cause some kind of screwup in the linker (even if arm/thumb calls are not supposed to be happening at runtime)
<JaMa> ssvb_: http://pastebin.ca/1845528
<JaMa> ssvb_: configure:11496: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mno-thumb -c -mcpu=arm1136j-s -marm
<JaMa> ssvb_: and with thumb enabled
<JaMa> ssvb_: configure:11479: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb
<ssvb_> JaMa: the most interesting address 0x401af86a (pc register value) is missing in the disassembly
<lool> Weird, I don't find -mthumb-interwork in our Ubuntu defaults, but we don't seem to have screwups without it
<JaMa> ssvb_: http://pastebin.ca/1845535 but still missing I'll try to disassm with objdump instead gdb
<ssvb_> JaMa: it could be that it is just some garbage padding data between functions and not a real instruction, in this case it would be interesing to know how it managed to get there
<ssvb_> JaMa: if it was a function call, then 'lr' register should point to the return address (and call instruction itself should be just before it)
<ssvb_> JaMa: what toolchain are you using? gcc, and binutils versions
<JaMa> gcc-4.4.3 binutils-2.20
<ssvb_> JaMa: now I suspect that the 'alien' object file with arm code may create some kind of bubble in the resulting binary and the function addresses may get all wrong and shifted on one of the sides of the 'bubble'
<JaMa> mmt binutils for target already built, I'll provide disassm with thumb forced
<ssvb_> JaMa: just tried googling a bit: http://old.nabble.com/binutils-2.20.1-td27432353.html
<ssvb_> it says something about "broken thumb->arm  intersection branches", don't know if it is relevant
<ssvb_> JaMa: but if you could downgrading binutils to 2.19 just for testing, it would be interesting
<JaMa> ssvb_: http://jama.homelinux.org/org.openembedded.shr.images/om-gta02/pixman/
<JaMa> ssvb_: here is disassembled lib with objdump with and without -M force-thumb, but with it fails later on some instruction and Aborts
<ssvb_> JaMa: btw, I'm trying to reproduce your environment now (gcc, binutils, CC, CFLAGS), I have a gut feeling that it could be one of the bugs in binutils 2.20
<JaMa> ssvb_: trying to downgrade now
<ssvb_> JaMa: could not break anything here with CC="gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb" CFLAGS="-fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os"
<ssvb_> though I have armv7 CPU, and just noticed that I actually used binutils 2.20.1
<JaMa> ssvb_: on armv5te it works for me too
<ssvb_> JaMa: did you try running the same binary on armv5te? or it had its own CC and CFLAGS?
<ssvb_> JaMa: if something runs on armv5te but does not run on armv4t, then it could be a PLD instruction somewhere
<ssvb_> UQADD8 and the other ARM SIMD instructions would only run on armv6 and newer
<JaMa> ssvb_: yeah same binary
<suihkulokki> pld or clz
<asac> JamieBennett: all fine wrt to langpack.mk ?
<asac> or blocked ;)
<asac> ?
<JamieBennett> asac: still working on it, I have a branch if your available to inspect it
<JamieBennett> (and using distutils)
<asac> JamieBennett: yeah if you have that i can look ;)
<JamieBennett> asac: Its not ready so I would appreciate pointers
<asac> let me look
<JamieBennett> https://code.edge.launchpad.net/~jamiebennett/+junk/webservice-office-zoho-translation-support
<asac> i guess in +junk?
<asac> ok found ;) . oh hehe
<JamieBennett> lots of noise as I had to reorganise it
<JamieBennett> asac: probably lots wrong at the moment
<asac> hmm
<asac> why was all that needed?
<asac> thought we just needed to make .desktop translatable
<JamieBennett> there was a comment about the code being translatable too and persia recommended doing it 'properly'
<JamieBennett> Also had to add setup.py
<asac> where is the bug? https://bugs.edge.launchpad.net/ubuntu/+source/webservice-office-zoho
<asac> there is nothing ;)
<JamieBennett> asac: It was the MIR which has now been approved
<asac> JamieBennett: but you were supposed to file a high bug about this ;)
<asac> also the MIR bug isnt even there ,)
<asac> https://bugs.edge.launchpad.net/ubuntu/+source/webservice-office-zoho/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=&
<JamieBennett> asac: https://bugs.edge.launchpad.net/webservice-office-zoho/+bug/539626
<lool> Ouch
<JamieBennett> :)
<ubot4`> Launchpad bug 539626 in webservice-office-zoho "Needs translation support (affects: 1)" [Critical,Confirmed]
<asac> JamieBennett: thats not an ubuntu bug
<asac> added
<JamieBennett> I know, the project got moved and now the bug is on the wrong project
<JamieBennett> asac: thanks
<asac> JamieBennett: where is the MIR bug?
<JamieBennett> bug: 537323
<ssvb_> JaMa: Don't know what to advise in this case, the problems could be also related to buggy/misconfigured kernel or silicon bugs in CPU. But in this case you would have stability issues with the other packages too.
<JamieBennett> https://bugs.edge.launchpad.net/webservice-office-zoho/+bug/537323
<lool> lp #537323
<ubot4`> Launchpad bug 537323 in webservice-office-zoho (Ubuntu) (and 1 other project) "[MIR] Main inclusion request for webservice-office-zoho (affects: 1)" [Undecided,New]
<ubot4`> Launchpad bug 537323 in webservice-office-zoho (Ubuntu) (and 1 other project) "[MIR] Main inclusion request for webservice-office-zoho (affects: 1)" [Undecided,New] https://launchpad.net/bugs/537323
<asac> ok added ubuntu there too
<asac> i dont think upstream .desktop files can be translated with gettext
<asac> but maybe i am wrong
<ssvb_> JaMa: extracting the problematic instruction at pc address from gdb somehow would provide some insights. Can you at least read it as just binary data (via x gdb command)?
<asac> for real code stuff sure
<JamieBennett> .desktop files should be .desktop.in
<persia> asac: Upstream .desktop can be translated with gettext just fine.  A large number of GNOME packages do that.
<ssvb_> JaMa: it would be 'x/4b $pc' when it dies with SIGILL
<gaspa> what happen if I run Lucid on a armv5 board? (nothing|broken|just slow)
<persia> gaspa: It won't run.
<lool> SIGILL
<persia> gaspa: I suspect that you won't even be able to boot, because upstart will SIGILL
<gaspa> right, as expected, thanks.
<gaspa> further question, given a binary, can I know for which armvX is compiled?
<persia> I don't know of any way.  There may be some trick you can do with magic numbers, but I'm unsure how far I'd trust it beyond ARM vs. Thumb
<JaMa> ssvb_: 0x401af7c2 <pixman_transform_init_identity+10>: -128    -24     -128    32
<JaMa> ssvb_: all info also sent to pixman list now
<gaspa> persia: ok, thanks again.
<persia> gaspa: I have a couple ARMv5 devices myself, but I have decided Debian is the right distribution for them.  It's close enough, and it works.  The alternative is sticking with Jaunty, but that expires soon enough.
<gaspa> debian compiles for armv4, as i know.
<persia> Yeah, but the performance difference isn't that huge.
<persia> If you need performance, get a newer board :)
<gaspa> and I got a big downspeed, in respect with the montavista default filesystem.
<gaspa> lol.
<armin76> gaspa: readelf -a /binary
<armin76> gaspa: you can use gentoo :D
<persia> armin76: Nifty!  Thanks.
<Laibsch> persia: I heard you were looking into mending the chroot build scripts and pbuilder.  Is that correct?
<Laibsch> Anything available for testing somewhere?
<lool> Laibsch: Not sure how aligned it is with your research, but
<lool> https://wiki.ubuntu.com/UbuntuDevelopment/Ports has some bits I wrote down and which might relate
<Laibsch> thanks
 * Laibsch is reading
<Laibsch> I've been out of the loop since about two weeks
<lool> Let us know where it lacks
<persia> Laibsch: I've pushed most of my stuff into Lucid.
<Laibsch> great
<Laibsch> I should already have it, then
<persia> Laibsch: http://people.ubuntu.com/~persia/pull-soyuz-chroot may also interest you
<persia> (that's still WIP)
<Laibsch> looks like you guys really did some amazing work on making this a *LOT* easier
<Laibsch> sudo pbuilder --create --basetgz /var/cache/base-armel.tgz --debootstrap qemu-debootstrap --mirror http://ports.ubuntu.com/ubuntu-ports/ --distribution lucid --architecture armel
<Laibsch> all there seems to be to it
<lool> persia: Oh didn't know one can download premade chroots from LP
<lool> that's great :-)
<lool> persia: Do you actually require bash?
<persia> I thought I did.
<persia> I might not, at that.
<persia> Give it a try.  I think I started with sh and something broke.
<persia> Maybe the getopts stuff.
 * Laibsch suggests /var/cache/pbuilder/base-armel.tgz instead of /var/cache/base-armel.tgz in the wiki instructions
<Laibsch> comments?
<lool> fixed
<Laibsch> thanks
<lool> persia: Is there any signing available for the soyuz chroot tarballs?
<lool> This is great material because it puts people on par with lanuchpad buildds to start their buil
<lool> builds
<persia> lool: That's why wgrant exported them, and why I put together a script to grab them.
<persia> I don't think there's signing now : that probably needs Soyuz extension.
<persia> The part that's stumping me is how to use that chroot with pbuilder.  I can't find the pbuilder configuration file that I need to tweak.  Do you know how the last bit shoud work?
<lool> persia: So you've just put up for a very nice alternative to the qemu-debootstrap stuff for the pbuilder use case
<lool> persia: (Will get to your point in a sec)
<persia> That's part of the idea.
<persia> The other thing is that some stuff FTBFS on the buildds, and not locally, and it turns out to be some odd buildd config thingy.  This helps track that down.
<lool> persia: What I hate with the current approach is the "cp /usr/bin/qemu-arm-static /somechroot" approach; it's ugly because we mix files from various architectures with no tracking, e.g. no updates to them, pollute the namespace etc.
<persia> Indeed.
<lool> persia: Having a pbuilder hook which starts from an armel tarball but copies the qemu binary on every build would be an improvement already (I think)
<persia> That's a much better idea, although I'd want it in sbuild :)
<persia> Or better, in schroot, so it gets updated on every schroot instantiation.
<lool> Back to your point, I think pbuilder is broken with respect to handling of .tar.bz2 tarballs, but "tar" will actually figure out compression if the file uses proper extension
<lool> So it would be possible to remove the -z flag from tar calls and have pbuilder support .bz2 tarballs transparently
<lool> persia: Note that until now the cp was needed to finish the debootstrap; it was kind of logical to keep that stuff around for actual chroot use
 * lool phone call &
<asac_> bug 517300
<ubot4`> Launchpad bug 517300 in likewise-open (Ubuntu Lucid) (and 1 other project) "[armel] likewise-open needs porting to ARM (affects: 1)" [High,In progress] https://launchpad.net/bugs/517300
<asac_> bug 537356
<ubot4`> Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 1 other project) "application menu entries dont do anything (affects: 1)" [High,Triaged] https://launchpad.net/bugs/537356
<asac_> bug 457878
<ubot4`> Launchpad bug 457878 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "imx51 on board ethernet plug/unplug events not detected (affects: 2)" [Medium,Confirmed] https://launchpad.net/bugs/457878
<asac> plars: were there any arm specific RC issues discovered in beta testing?
<asac> bug 513732
<ubot4`> Launchpad bug 513732 in gmp (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/513732
<asac> bug 528887
<ubot4`> Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/528887
<asac> bug 537083
<ubot4`> Launchpad bug 537083 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "Suspend no longer works after updating to 2.6.31-605.9 kernel (affects: 2)" [High,In progress] https://launchpad.net/bugs/537083
<ogra> qemu hang ?
<asac> bug 499881
<ubot4`> Launchpad bug 499881 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "usb storage with ext4 does not work in lucid on imx51 hardware (dup-of: 515023)" [High,Fix released] https://launchpad.net/bugs/499881
<ubot4`> Launchpad bug 515023 in linux (Ubuntu) "ATA pass-through commands preventing external HDD to be mounted (affects: 10) (dups: 1)" [Undecided,Confirmed] https://launchpad.net/bugs/515023
<asac> ogra: qemu hang is RC still
<ogra> ok
<asac> no news on that front afaik
<ogra> i wasnt sure
<asac> bug 528524
<ubot4`> Launchpad bug 528524 in totem (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps on dove (affects: 2)" [High,Invalid] https://launchpad.net/bugs/528524
<asac> bug 532733
<ubot4`> Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 2)" [Medium,Incomplete] https://launchpad.net/bugs/532733
<ogra> should probably be "in progress"
<ogra> incomplete was added by the server team ages ago
<rcn-ee> hey ogra, testing 2.6.33-500-omap with an initramfs, it's been a long time, what should i normally add to the bootargs.. ;)
<ogra> root=UUID=<uuid of your rootfs> should be in there
<ogra> beyond that "ro quiet splash" are ususally the defaults
<ogra> i dont know the exact runes for uboot (loadaddr etc) yet but i think you provided a rootstock patch for that (that i was planning to merge soon)
<rcn-ee> ah found it.. initrd=address. ;)
<ogra> hmm, that shouldnt be needed
<asac> bug 527720
<ubot4`> Launchpad bug 527720 in klibc (Ubuntu Lucid) (and 1 other project) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [High,Triaged] https://launchpad.net/bugs/527720
<ogra> as long as uboot loads it to the proper place in ram
<rcn-ee> sorry, main reason i don't login to irc at work, people keep calling.. ;)
<rcn-ee> okay, anything beyond 'sudo update-initramfs -c -k 2.6...'
<persia> rcn-ee: The thing about IRC is that it can also be asynchronous.  Lots of us idle here when we're out, when we're sleeping, when we're on the phone, etc., and just answer later.  In many clients there are ways to show the last few lines where someone highlighted you.
<ogra> rcn-ee, i think you need to make an uInitramfs out of it
<ogra> or uInitrd
<rcn-ee> yeap i did: mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d ./initrd.img-2.6.33-500-omap ./uInitrd
<rcn-ee> i'm searching google for how other people have done it.. ;)
<ogra> that should be fine
<rcn-ee> so i did this for the boot.scr : http://pastebin.com/byy5u0dR
<rcn-ee> it loads the uIinitrd at boot... but the kernel doesn't like it..
<rcn-ee> [   31.217498] Trying to unpack rootfs image as initramfs...
<rcn-ee> [   31.217803] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
<ogra> i think you need to include the initrd address in your bootm command
<ogra> mmcinit; setenv bootargs 'console=ttymxc0,115200 console=tty0 root=UUID=bfdf1232-7400-4198-a89b-821e69e2fdd2 ro quiet splash'; fatload mmc 0:2 0x90800000 uImage; fatload mmc 0:2 0x91600000 /uinitrd; bootm 0x90800000 0x91600000
<ogra> thats the line i use for an imx51 board with uboot
<rcn-ee> it's weird cause i got away with it here: http://elinux.org/BeagleBoardDebian#Development_PC:_Setup_SD_U-boot_Partition
<rcn-ee> i'll add the bootm change..
<rcn-ee> cool, the bootm change did change things..
<ogra> works ?
<rcn-ee> that would be too easy.. ;) now just: "[   33.794677] Trying to unpack rootfs image as initramfs... "
<ogra> try to drop the initrd= option
<ogra> you shouldnt need it
<rcn-ee> actually that was the other change i did..
<rcn-ee> was going to put it back.. ;)
<ogra> oh, wait
<ogra>  -C gzip might be wrong
<ogra> should be none
<rcn-ee> yeah wasn't sure about that one, pulled from a sheevaplug example...
<ogra> mkimage -A arm -O linux -T ramdisk -C none -a 0x0 -e 0x0 -n UbuntuInitrd -d "$INITRD" "$UINITRD" ... thats what we used for testing on imx51
<rcn-ee> thanks, i'll use that..
<rcn-ee> weird still no go, here's what i got.. http://pastebin.com/h8Hq2Ksh
<ogra> hmm
<rcn-ee> i have week or two old .config from the imx tree, the initrd options seem to match up...
<ogra> well, try dropping rootwait rootfstype=ext3
<rcn-ee> sure
<rcn-ee> no change...
<ogra> well, it definately loads it
<ogra> [   33.773162] Trying to unpack rootfs image as initramfs...
<ogra> [   34.684265] Freeing initrd memory: 7128K
<rcn-ee> yeap, loads and then cleans it up..
<ogra> wait, no change ? i.e. it still gets you a login prompt
<rcn-ee> yeap, command prompt still comes up...
<ogra> but you dropped the rootwait ?
<rcn-ee> yeap: [    0.000000] Kernel command line: console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 ro vram=12M omapfb.mode=dvi:1280x720MR-16@60
<rcn-ee> rootwait is only really useful for usb rootfs...
<rcn-ee> the sd card is happy without it..
<ogra> i need it here to make the kernel not panic
<rcn-ee> which board do you have again?
<ogra> revB
<rcn-ee> this is on a B5, hopefully you don't have a really old B3/4
<ogra> i do :)
<ogra> [   45.171386] VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0)
<ogra> [   45.178344] Please append a correct "root=" boot option; here are the available partitions:
<ogra> [   45.186889] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<ogra> OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz
<ogra> its really old :)
<rcn-ee> That's very weird.. are you:  Ubuntu-2.6.33-500.2 or Ubuntu-2.6.33-500.1
<rcn-ee> same core here.. ;)
<ogra> 500.2
<ogra> ah, no its some kernel amitk uploaded for testing for me
<ogra> saldy my rootfs is ext4 (default) and there are ext4 issues atm so i cant try building an initramfs
<amitk> ogra: that kernel is equivalent to 500.2
<ogra> yeah, i thought so
<rcn-ee> yeah, 500.1 won't do anything.. other then uncompressing..
<ogra> yep
<amitk> the lack of initramfs is the reason for most of those issues, including the rtc one.
<ogra> amitk, right, we just try to solve that :)
<amitk> I am in two minds whether to compile everything in now and then make them modules again when we have installable images with initramfs
<ogra> but see above
<ogra> [   33.773162] Trying to unpack rootfs image as initramfs...
<ogra> [   34.684265] Freeing initrd memory: 7128K
<ogra> so it loads but doesnt exec it
<amitk> initramfs size related?
<ogra> 7M shouldnt be to bad
<rcn-ee> amitk, full log: http://pastebin.com/h8Hq2Ksh
<ogra> well, 7M is a lot ... but still should work
 * amitk will be back in a few
<rcn-ee> and it might be a kernel bug, we've never used an initrd in angstrom.. ;)
<ogra> ogra@babbage2:~$ ls -lh /boot/initrd.img-2.6.31-605-imx51
<ogra> -rw-r--r-- 1 root root 3.8M 2010-03-12 09:57 /boot/initrd.img-2.6.31-605-imx51
<ogra> rcn-ee, i think the ubuntu kernel uses the proper options for booting initramfs
<plars> asac: sorry for the delay, on holiday today and away alot
<plars> asac: probably the most critical issue I found was bug #540477
<ubot4`> Launchpad bug 540477 in xorg-server (Ubuntu) "X restarted, but no .crash file (affects: 1)" [Undecided,New] https://launchpad.net/bugs/540477
<plars> asac: it's annoying, but can be worked past, and I think is a dup of an issue that was also seen on x86
<plars> asac: which is supposed to already be fixed, we just didn't catch the right version
<rcn-ee> we are about 7M -rwxr-xr-x 1 root root 7.0M 2010-03-19 10:17 uInitrd
<ogra> ogra@beagle:~$ ls -lh /boot/initrd.img-2.6.33-500-omap
<ogra> -rw-r--r-- 1 root root 2.1M Jan  1 00:02 /boot/initrd.img-2.6.33-500-omap
<ogra> though it might not contain everything, i get a lot of ext4 errors while rolling it
<plars> asac: also, I believe that GrueMaster hit some bad problems with the netboot images
<rcn-ee> yeah, i haven't had good luck with ext4 on my beagles yet, whereas cwillu_at_work as been using brtfs just fine...
<plars> bug #541399 on dove, and bug #541029 on imx51
<ogra> well, ext4 is the default ubuntu uses
<ubot4`> Launchpad bug 541399 in linux-mvl-dove (Ubuntu) "netboot image fails to boot. (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541399
<ubot4`> Launchpad bug 541029 in linux-fsl-imx51 (Ubuntu) "netboot image fails to connect to the network (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541029
<plars> asac: ^
<ogra> so the beagle images will use that too
<asac> plars: X crash ... reproducible?
<plars> asac: yes
<plars> asac: boot, press enter
<ogra> (unless you pick something differently on purpose)
<asac> ok gdm bug
<asac> can you make the title better for bug 540477 ?
<ubot4`> Launchpad bug 540477 in xorg-server (Ubuntu) "X restarted, but no .crash file (affects: 1)" [Undecided,New] https://launchpad.net/bugs/540477
<asac> thats a awful title ;)
<ogra> asac, plars, huh ? i thought that was fixed with the last plymouth upload
<ogra> (it was a plymouth bug afaik)
<plars> ogra: I didn't check the version we had in that particular image, and can't really from where I'm at right now
<plars> ogra: but yes, sounds like the same issue
<persia> plars: Do you know which image it was?
<rcn-ee> ogra,  for refeence, what uboot version on your bx?
<ogra> rcn-ee, U-Boot 1.1.4 (Apr  2 2008 - 13:42:13)
<plars> persia: candidate image on iso tracker - 20100317
<ogra> the one that was in NAND
<rcn-ee> ouch.. ;)  i think we still have one of those laying around, going to track it down and try the latest u-boot for comparison..
 * cwillu_at_work pokes his head in
<cwillu_at_work> what's the problem with ext4?
<ogra> it makes my kernel panic
<ogra> but that might be a .33 bug, who knows
<cwillu_at_work> that was the "cannot find rootfs"?
<ogra> no
<ogra> i can boot just fine but as soon as i start FS operations it spills lots of errors and at some point panics
<cwillu_at_work> re: rootwait, I've always needed it
<ogra> you dont with initramfs :)
<ogra> but yes, without i also always needed it
<persia> plars: libplymouth2 0.8.0~-16
<ogra> thats what made me curious in rcn-ee's boot
<ogra> persia, outdated
<cwillu_at_work> and this isn't something like a journal having worn out a section of an sd card because there was lots of writes performed while it was nearly full, right? :p
<cwillu_at_work> been bit by that more times than I care to admit
<cwillu_at_work> (hence the btrfs :p)
<ogra> no, the SD is new
<ogra> 4GB and only carries ubuntu-minimal yet
<persia> ogra: Right.  Just confirming because plars couldn't look it up.
<ogra> ~17 has the fix
<ogra> https://launchpad.net/ubuntu/+source/plymouth/0.8.0~-17/+build/1566604
<ogra> and obviously built fine
<plars> right, so it *should* be fixed in the latest... just need to confirm that
<ogra> i wonder why its not on the image
<persia> Right, just needed a respin.
<persia> No respin, probably.
<ogra> aah
<persia> But too late now.
<ogra> it was only uploaded last night
<persia> Yes, which is why beta was delayed.
 * ogra didnt notice since KEybuk is raving about the fix since a week
<persia> But nobody did the release coordination to get respins for all three images.
<ogra> i thought he had uploaded it since ages
<persia>  (-server is actually from the 15th still)
<persia> Could have been stuck in unapproved
<rcn-ee> ogra, just tested on the oldest bx board i have (b4) it boots, follow this for the latest uboot http://elinux.org/BeagleBoardUbuntu#Upgrade_U-Boot  there is a lot of issues with 1.1.4...
<plars> asac: there are also some other issues like 528887, that are medium, and thus not typically marked RC by default.  However, I think they are likely important/annoying enough that we should make sure they are addressed before release
<plars> bug #528887
<ubot4`> Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/528887
<rcn-ee> and make sure to follow the 'old' notes in that section..
<ogra> rcn-ee, heh, my initrd boots fine here
<rcn-ee> what? cool..
<asac> plars: maximus is on our RC list atm
<ogra> http://paste.ubuntu.com/397873/
<asac> https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
<asac> plars: ^^
<plars> asac: ok, good
<asac> i will try to get some support fo rthat
<ogra> rcn-ee, try fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80000000 0x81600000
<ogra> though i'm worried about the size of your initrd
<ogra> mine definately only has 2.1M
<amitk> ogra: rcn-ee: so initramfs issue fixed?
<ogra> amitk, well see the above paste ...
<ogra> http://paste.ubuntu.com/397873/
 * amitk likes it when problems get fixed behind his back
<ogra> though ext4 bugs me hard
<ogra> i cant modprobe rtc atm
<amitk> ogra: please file a bug on ext4, csurbhi is tracking those
<ogra> will do
<rcn-ee> i haven't looked at the rtc yet to see if it's enabled right either.. ;)
<amitk> it is a module
<ogra> yeah
<amitk> as I said before, I am in two minds whether to compile everything in now and then make them modules again when we have installable images with initramfs
<ogra> ogra@beagle:~$ ls /lib/modules/2.6.33-500-omap/kernel/drivers/rtc
<ogra> [  425.706848] EXT4-fs error (device mmcblk0p2): ext4_lookup: deleted inode referenced: 128377
<ogra> ls: cannot access /lib/modules/2.6.33-500-omap/kernel/drivers/rtc: Input/output error
<ogra> i would love to load it :)
<ogra> amitk, i'll have images next week
<amitk> heh, your ext4 rootfs might be fried
<ogra> dont put time into it
<rcn-ee> the address didn't change it for me, same as the last, although i forgot to log the boot...
<ogra> initramfs and bootloaders were my main concern
<ogra> both should be done on the weekend
<ogra> the rest is image build scripts fiddling
<rcn-ee> exactly.. ;)  you guys have a shippment of xm boards coming in right?
<amitk> already have 'em
<rcn-ee> cool, i haven't got mine to boot yet either, so that's going to be fun this weekend..
<rcn-ee> 0x8000000, doesn't help the initd.. http://pastebin.com/E22QL3iW  as far as the size, i just ran 'sudo update-initramfs -c -k 2.6....' on the beagle...
<amitk> rcn-ee: 500.2 ought to boot on XM
<rcn-ee> cool, i'll try that in an hour over lunch, i was trying to get my 2.6-dev (2.6.32) to work..
<amitk> rcn-ee: I'm going to concentrate on core functionality next week (DSS2/PM) instead of flipping modules to built-ins since ogra will have images for us next week
<rcn-ee> okay sounds good, get it working first, then move stuff around.. ;)  I'll cleanup my dss2 patch in my 2.6.33 tree to easily merge into yours...
<ogra> rcn-ee, weird initramfs works even with a newer uboot here with the same commands
<ogra> U-Boot 2009.11 (Feb 24 2010 - 10:58:59)
<rcn-ee> i guess i'm confused... where's the best indicator the initrd worked. ;)
<ogra> Loading, please wait...
<ogra> thats printed from /init in initramfs
<ogra> and all the: "Running /scripts/...." lines
<asac> bug 541399
<ubot4`> Launchpad bug 541399 in linux-mvl-dove (Ubuntu) "netboot image fails to boot. (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541399
<rcn-ee> ahh.. okay, i'll look for that...
<ogra> rcn-ee, probably drop console=tty0 ;)
<ogra> or attach a monitor
<rcn-ee> i can do that... monitor is attached, but dss2 isn't patched to work yet... ;)
<ogra> initramfs will definately spit out messages on the second console arg you set (if you set one)
<ogra> well, then just drop it from cmdline
<ogra> that should show the messages on serial
<DanaG> hmm, I set it this way: console=tty0 console=ttyS2,115200n8
<DanaG> the second one is the one that gets kernel stdin, stdout, stderr.
<rcn-ee> bingo, that did it.. http://pastebin.com/Y42WTD3S .... ;)  so it's loading the initd...
<DanaG> Starting kernel ...
<DanaG> Uncompressing Linux...
<DanaG> uncompression error
<DanaG>  -- System halted
<DanaG> hmm, it might be good to revise install-me.sh to allow it to work on host system (without dpkg -i step, of course).
<rcn-ee> no usb devices.. back to the config from this morning.. it doesn't look like it can be an external module .. http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.33.y.git&a=search&h=HEAD&st=grep&s=CONFIG_USB_MUSB_HDRC
<rcn-ee> Yeah, DanaG i was thinking, if arch != arm stop. .. ;)
<DanaG> On my host, mmcblk0p1 is still mmcblk0p1.
<ogra> rcn-ee, yeah, i was suspecting that, you dropping rootwait and cwillu_at_work confirming it's needs somehow indicated that :)
<DanaG> so, install-me.sh works if I do "dpkg -i ... || true"
<DanaG> weird... uncompression error on 2.6.33.1-dl2
<rcn-ee> but it could be as simple as... ". install-me.sh" -> arm... ". install-me.sh /dev/sdb1" -> on x86...
<DanaG> ah yeah.
<DanaG> Oh, and perhaps check if partition is already mounted somewhere.
<DanaG> Or even better: pass it the dir, not the device.
<DanaG> okay, so 33.1-dl2 doesn't uncompress.
<rcn-ee> It just dies before uncompression?
<DanaG> Yeah.
<DanaG> Starting kernel ...        Uncompressing Linux...        uncompression error         -- System halted        (replaced line-breaks with 8 spaces.)
<amitk> DanaG: could be your addresses? Kernel overwriting itself?
<rcn-ee> DanaG, it's close to lunch, so i'm going to put on my c4 lucid and test...
<DanaG> You can do that after your lunch, if you want. =Ã¾
<rcn-ee> nah, then i can 'unbrick' it during lunch.. ;) i run home...
<rcn-ee> yeap, bricked it... 2.6.33.1-dl2 is bad..
<rcn-ee> what's weird, it's based off the head of https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-dev when i cross built in the lab for lucid/squeeze but with angstrom's 4.3.3...  i'll investigate it tonight...
<rcn-ee> 2.6.33-dl1 had been fine on that machine...
<DanaG> handily for me, I just stick the card back in my host laptop and replace uimage.
<rcn-ee> i just saw sd cards between running beagles and run install-me.sh again.. ;)
<rcn-ee> saw/swap
<ogra> tsk
<ogra> just dont break your installs all the time :)
<rcn-ee> hehe.. it's okay, that's the 2.6-dev branch.. things are allowed to break... ;) 2.6-stable now that can't ever break.. ;)  i removed it from rcn-ee.net, so it shouldn't propgate to the mirrors...
<rcn-ee> what's scarry, it was just the kernel stable bump to 2.6.33.1...
#ubuntu-arm 2010-03-20
<DanaG> hmm, does "splash" without "quiet" do anything on arm?
<DanaG> weird... reference u-boot doesn't have mpuspeed
<persia> The use of "splash" and "quiet" shoudn't be arch-specific.
<DanaG> interesting: with "quiet" boots in 19 seconds; without, boots in 30 or so.
<DanaG> er, 16, not 19.
<persia> Maybe slow console?
<persia> maybe kernel compilation options?
<DanaG> well, console speed is 115200; kernel is rcn-ee's kernel.
<DanaG> I wonder if something similar is a factor on my "host" computer (with serial console).
<asac> plars: the consistence CPU check .... wonder if that should sleep a bit after resume. I guess bunch of stuff gets triggered on resume, so things would be slowed down naturally. ideas?
<asac> (suspend resume testing)
<asac> or does the suspend test script already take care of that?
<asac> plars: anyway. awesome job on getting this spec done ;)
<asac> so i cant find any "armel" tagged mono bug ;)
<asac> ah it was bug 530000 ...
<ubot4`> Launchpad bug 530000 in qemu-kvm (Ubuntu) "mono assembly installation under qemu-arm-static hangs (affects: 1)" [Medium,Confirmed] https://launchpad.net/bugs/530000
<asac> cool bug no. ;)
<plars> asac: no, it doesn't do that currently, but I saw that test failed the last time I tried to run it, and I was thinking of doing just that... because there's a lot of stuff at resume time that could throw the timing off too far
<rcn-ee> ogra, i started working on cherry picking patchs for the IGEPv2 (it's an omap3 based board made in spain), most of it's suppot is in 2.6.34-rc2, the biggest difference, its factory u-boot needs boot.ini vs boot.scr... the dss2 patch needs a little fixup, as it doesn't apply cleanly to 2.6.33..
#ubuntu-arm 2010-03-21
<DanaG> 3 lines of error:
<DanaG> beagleboard console-kit-daemon[2018]: WARNING: Unable to load seats from file /etc/ConsoleKit/seats.d/00-primary.seat: File is empty
<DanaG> beagleboard console-kit-daemon[2018]: WARNING: Failed to acquire org.freedesktop.ConsoleKit: Connection ":1.150" is not allowed to own the service "org.freedesktop.ConsoleKit" due to security policies in the configuration file
<DanaG> beagleboard console-kit-daemon[2018]: WARNING: Could not acquire name; bailing out
<DanaG> netgear fail: wg111 usb adapter gets only 2 megabits per second, tops.
<DanaG> that is so weird... it'll play smoothly... and then go broken-up, and then go smooth again.
<DanaG> it's not just bandwidth -- the stream is only 2 megabits, anyway.
<DanaG> But, if I wave my arm around the usb-wifi thingy, it dies.
<DanaG> netgear fail:   0.0-35.0 sec  5.18 MBytes  1.24 Mbits/sec
<persia> Oh my.  Sounds like you're in a zone with heaps of interference.
<Baybal> hello
<DanaG> Well, it works fine going iwlagn -> beagleboard wired.
<DanaG> it's just netgear fail.
<DanaG> It will play fine for a while, and then I wave my arms around the thing, and it starts dropping.
<DanaG> ... even after I move my arms away again.
<Baybal> bcm is also a not favourable thing on linux
<DanaG> rtl8187, actually.
<Baybal> oh
<Baybal> there should be no problems
<persia> Well, it depends on ambient fields, but in general, it ought be safe.
<DanaG> oh, and the LED on it "sputters" in time with the audio stream.
<DanaG> It doesn't blink... it flickers.
<DanaG1> In comparison, using iwlagn to router, then ethernet to beagleboard... gives 20 megabits.
<DanaG> 0.0-1805.1 sec  1585 MBytes  7.37 Mbits/sec
<DanaG> that's a longer iperf.
#ubuntu-arm 2011-03-14
<XorA> morning
<flag_> guys, anyone know how to preserve a working serial console after framebuffer start?
<flag_> ogra: do you know how i can preserve  a working serial console even after the framebuffer start?
<ogra> preserve ?
<flag_> flag_: yep, when the framebuffer starts, my console dies and i have to switch to my monitor to see what's going on
<ogra> you should get all boot messages if you set the cmdline to point to serial and drop the "quiet" from the cmdline
<ogra> just edit /boot/boot.script and run sudo flash-kernel
<flag_> ogra: and what if one the variable in my uboot environment is longer than 80 chars? on do i print it in its entirety?
<ogra> you editor should display it fine
<flag_> no no
<flag_> i mean, i'm in uboot and i try to "printenv $var"
<flag_> but the content of var is longer than 80chars
<flag_> thus it's truncated
<ogra> there is only the hardcoded env (which just loads the boot.scr file) you will have to change a lot if you dont just edit boot.scr
<ogra> so printenv wont get you very far
<ogra> if it cuts off after 80 chars thats an issue with your terminal program
<ogra> or with the TERM variable you use
<flag_> ogra: i'm using minicom
<ogra> well, i'd really recommend to rather change your boot.scr than to poke around in the uboot env
<flag_> ogra: ok, deleted quiet from bootargs in boot.scr, but still my console dies after:
<flag_> ogra: Starting kernel ...
<flag_> Uncompressing Linux...........................................................................................................................................................................................
<ogra> <ogra> you should get all boot messages if you set the cmdline to point to serial and drop the "quiet" from the cmdline
<flag_> ogra: setenv bootargs root=UUID=e18764f5-7859-4509-gj48-bbcc01a1ff77 ro splash
<ogra> did you set the cmdline to point to the serial terminal ?
<flag_> ogra: bootargs=console=ttyS0,115200n8 root=UUID=54ec8187-d25e-413a-ac5b-99af9cc379fc (from u-boot)
<ogra> is it like that in your boot.scr ?
<flag_> ogra: bootargs in u-boot and boot.scr should match, right?
<flag_> ogra: ah, got it
<flag_> ogra: my bad, there was no console= in /boot/boot.scr but only in u-boot bootargs and i thought the kernel picked the console variable from u-boot
<ogra> no, as i said above the u-boot stuff is totally irrelevant
<ogra> its overriden as soon as boot.scr was loaded
<flag_> ogra: k, thanks
<hrw> heh.. I forgot how long can arm system need to upgrade..
<ogra> heh
<ogra> i did an ac100 update-manager upgrade over the weekend
<ogra> took 36h
<ogra> though on a very slow SD card
<hrw> apt-get dist-upgrade from alpha3 to current - started >1h ago on sd
<hrw> ogra: I reinstalled all packages on my dualcore atom in ~30 minutes. on 60MB/s sata
<ogra> hmm
<ogra> who fired off a netbook buid
<ogra> *build
<ogra> oh, not netbook, headless
<hrw> http://www.computerworld.com.au/article/379549/calxeda_arm_chips_designed_480-core_servers/ - want one ;D
<amitk> hrw: you can try convincing Rob or Martyn in Budapest
<hrw> amitk: calxeda people?
<amitk> hrw: yeah, you might know them as smoothstone people from previous UDSes
<hrw> ah, right
<hrw> the company which changes names
<ogra_> k, finally unity-2d on ac100
<hrw> you did not had it before?
<ogra_> we didnt have neon runtime detection in QT
<hrw> ah, right
<ogra_> and after that i had to find out that the natty libc doesnt woork on tegra2
<hrw> o.. hows that?
<ogra_> http://gitorious.org/ac100/kernel/commit/227af643e6253e9a5c2a2f74468f855686c44117?diffmode=sidebyside
<ogra_> see #linaro, was just discussed there
<XorA> time to blag a ac100 now then :-D
<ogra_> unity-2d is really snappy here
 * hrw -> lunch
<ogra_> janimo, poke
<rsalveti> ogra_: cool, so new qt really worked well for you?
<ogra_> yep
<ogra_> currently using it afer i spent the whole weekend to get natty running
<rsalveti> nice
<janimo> ogra_, hello
<rsalveti> ogra_: did you find what were the issues?
<ogra_> libc is really badly broken on the ac100
<rsalveti> you said you had many issues last week
<ogra_> someone pointed me to http://gitorious.org/ac100/kernel/commit/227af643e6253e9a5c2a2f74468f855686c44117?diffmode=sidebyside
<ogra_> i'm currently running with the maverick libc pinned
<ogra_> janimo, so did you test headless ?
<janimo> ogra_, not yet
<ogra_> seems we have a bunch of issues with oem-config/ubiquity
<rsalveti> ogra_: ouch, got it
<janimo> was trying tosee why images fail
<janimo> ogra_, I saw you made some changes around oem-config/upstrart last week
<ogra_> janimo, the oem-config UI never comes up on serial
<ogra_> unless no tty exists at all
<ogra_> (i.e. it immediately works if i use a broken omapfb mode so ttys cant be started)
<ogra_> i suspect ubiquity/oem-config simply has no code for that and uses the first console it finds
<ogra_> the second big bug i see is that no user is created at all
<janimo> what would a fix be? We need to keep ttys I think
<ogra_> no idea yet
<ogra_> i would suggest looking at d-i how it determines the used console
<ogra_> if werial is set we should defautl to use it i think
<janimo> ok
<ogra_> effectively it doesnt seem like oem-config finishes its job
<ogra_> the most funny part is that the debconf package removal that runs afterrrr oem-config defaults to serial
<janimo> so right now one can log in but even if oem-config is started by hand it does not run
<janimo> ?
<ogra_> oem-config runs fine
<ogra_> but on tty1
<ogra_> while it takes input from serial (since the kernel defaults to it as first console)
<ogra_> i can use my laptop kbd to fiddle with oem-config on the panda dvi screen
<ogra_> :)
<ogra_> it seems to just not use the right output
<janimo> besides oem-config what else is broken?
<ogra_> i havent found ut why we dont have build attempts since three days (ampty mails usually suggest that the connection to the image builder failed=
<ogra_> well, oem-config doesnt create a user at all atm
<janimo> ogra_, telepathy-glib FTBFS (regression) which holds up empathy
<ogra_> janimo, shouldnt affect headless at all
<janimo> ogra_, indeed
<ogra_> we get empty build failure mails and i see no logs at all on the imagebuilder
<janimo> who can debug that?
<ogra_> someone has changed livecd-rootfs or debian-cd ... or the ssh connection from cdimage to the image builder is broken
 * ogra_ will research that 
<ogra_> so there was one change in livecd-rootf that only affects edubuntu
 * ogra_ cant see any changes that could have made our builds fail
<ogra_> lets try a manual build
<ogra_> seems to run flawless
<ogra_> http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/20110314/
<ogra_> hmm, worked fine
<ogra_> janimo, ^^^
<GrueMaster> ogra_, janimo:  It still has issue with oem-config.  The program is displaying the user interactive screens on the attached monitor, but only taking input via serial console.
<GrueMaster> ubuntu
<GrueMaster> oops
<GrueMaster> It also failed to create a user.  May be due to no network.  Not sure.
<ogra_> GrueMaster, yes, as discussed above
<GrueMaster> Bugs filed?
<ogra_> GrueMaster, fi you give a broken frambuffer setting it works (i.e. if ttyS/O is the only console around)
<ogra_> and the debconf bits after oem-config are on serial too
<ogra_> oem-config was simply never used on serial i think
<ogra_> so we are the first ones to face these issues
<ogra_> no bugs filed yet, no
<GrueMaster> I do see something interesting in the /var/log/oem-config.log.  It has an error open: /dev/tty not found.
<ogra_> oh really ?
<GrueMaster> I'll file a bug soon.  Flashing another SD to try on beagleXM.
<ogra_> k
<ogra_> it worked fine for me with the old kernel btw
<GrueMaster> But it is near the end of the log (after other activity).
<ogra_> because the omapfb setting completely broke the framebuffer
<GrueMaster> Also, it failed to create a user, but that may be due to lack of network.
<ogra_> unlikely
<ogra_> wither we dont call all modules from the debconf frontend or what i suspect is my hack to rename the machine to localhost by default is bad
<GrueMaster> Hey, I find unlikely bugs all the time.  I'm good at it, remember?  :P
<ogra_> heh, yeah
<ogra_> but i really doubt missing network has anything to do with it
<GrueMaster> Same here, but I have seen weirder issues.
<TheUni> rsalveti: ping
<TheUni> rsalveti: i've begun cleaning xbmc's packaging and install scripts. it would be nice to have a mentor that i could speak with about best practices. know of anyone who might be willing/able to help?
<rsalveti> TheUni: I can try to help on that
<rsalveti> persia would be the best guy around for that
<rsalveti> he knows a lot about packaging
<rsalveti> TheUni: is it still the packaging tree?
<TheUni> yes
<TheUni> i have some work done locally to begin consolidating packages, but i'd like to know that i'm making things better and not worse
<rsalveti> TheUni: and how is the daily builds, did you manage to get it to work?
<TheUni> rsalveti: yes, daily builds are up. but they're not publicized yet because i'd like to rework the packages first
<rsalveti> oh, ok
<TheUni> incase we end up causing some conflicts while shifting things around
<TheUni> https://launchpad.net/~team-xbmc/+archive/unstable
<rsalveti> TheUni: at the moment it seems you're building for arm
<rsalveti> at least Architecture: i386 amd64 powerpc ppc64
<rsalveti> is that because of the daily builds?
<rsalveti> cool
<TheUni> rsalveti: simply because we haven't tackled packaging it yet
<TheUni> but afaik current git is building/working on beagle
<rsalveti> TheUni: cool, nice to know
<TheUni> rsalveti: ok, i'll work up a list of questions and hand them off to you. you can pass me along if you'd like :)
<rsalveti> some XBMC_CONFIG_OPTIONS would be arch specific, as for ARM we'd like to have gles support, and not gl and vdpau
<rsalveti> TheUni: sure
<TheUni> right
<TheUni> gles is default for arm
<rsalveti> but it does seems to be better
<GrueMaster> Not sure what changed, but unity-2d-places is less than usable in the 20110311 image.  Can't even get to a terminal without crashing.
<pmathews> s/hanf/hang/
<GrueMaster> pmathews: ???
<prpplague> GrueMaster: wrong wide post
<prpplague> GrueMaster: that was for me
<GrueMaster> ah
<pmathews> oops
<prpplague> kgilmer: you still working for bug?
<kgilmer> hi prpplague, yep sure am.
<prpplague> kgilmer: just ran across a post on linuxdevices, and just reminded me to ask
<prpplague> kgilmer: http://www.linuxfordevices.com/c/a/News/Bug-Labs-BugSecure/
<kgilmer> yep, that's our next bug version.
<prpplague> kgilmer: don't suppose you guys are looking into omap4?
<kgilmer> the pb chip is pretty cool
<prpplague> kgilmer: i was curious about the pb chip
<prpplague> kgilmer: i have heard that pb does a lot of cool designs that they keep pretty quiet about
<kgilmer> sorry prpplague, in support crisis mode for a demo atm, got to get back to you later.
<prpplague> kgilmer: np, later bud
<prpplague> kgilmer: i understand all too well
#ubuntu-arm 2011-03-15
<rsalveti> morning
<suihkulokki> timezones greetings
<vin> I am trying to boot ubuntu 10.10 from the igepv2 but it hangs on booting the kernel
<ogra> make[4]: Entering directory `/root/unity-2d/obj-arm-linux-gnueabi'
<ogra> cd /root/unity-2d/obj-arm-linux-gnueabi/po && /usr/bin/msgmerge --quiet --update --backup=none -s /root/unity-2d/po/fr.po /root/unity-2d/po/unity-2d.pot
<ogra> Illegal instruction (core dumped)
<ogra> GRRR !
<rsalveti> ops
<rsalveti> vin: which ubuntu version are you using?
<vin> 10.10
<rsalveti> vin: maybe you should try to install a newer kernel for igepv2
<rsalveti> could be from linaro or our new for maverick, probably should support it better
<rsalveti> after you changed the x-loader and u-boot for igepv2
 * rsalveti lunch
<alf_> rsalveti: I can't get the GL drivers to work on sdp/omap4 :/ . eglInitialize() fails with EGL_BAD_ALLOC. Any ideas what is wrong or how to get more info?
<alf_> rsalveti: answer after lunch ;)
<alf_> rsalveti: that is on natty-alpha-3 with drivers from omap-trunk
<rsalveti> alf_: are you using the latest one available?
<rsalveti> alf_: I updated them today, but just packaging changes
<rsalveti> alf_: is this happening with any application?
<rsalveti> and, did you also updated your kernel?
<rsalveti> not working yet with 38
<rsalveti> working on it
<alf_> rsalveti: libegl1-sgx-omap4  1.7~git0f0b25f.2natty3-1
<alf_> rsalveti: uname -r 2.6.35-1101-omap4
<rsalveti> alf_: hm, this is the one I'm currently using
<alf_> rsalveti: and it happens with every app, even the trivial eglinit.c example
<rsalveti> alf_: what other packages do you have installed?
<rsalveti> I tested with es2gears
<alf_> rsalveti: can you please remind me the package for es2gears? :)
<rsalveti> alf_: mesa-utils-extra
<rsalveti> alf_: can you paste me your package list related with sgx and pvr?
<rsalveti> that you have installed at your system
<alf_> rsalveti: wait
<alf_> rsalveti: All of this has been happening when trying to running through ssh (with DISPLAY etc setup correctly)
<alf_> rsalveti: when I run something in a terminal in unity 2d it all runs fine
<alf_> rsalveti: wait, wrong again...
<rsalveti> alf_: weird, I'm just testing with ssh here
<rsalveti> and my es2gears is running fine
<alf_> rsalveti: ok, this is what happens: when trying to run things through ssh while stile in gdm or using a plain xinit things fail
<alf_> rsalveti: all work fine when logged in unity2d
<rsalveti> alf_: does it also work when using the recovery mode?
<alf_> rsalveti: hmm, how do I log out unity2d? :)
<rsalveti> alf_: no log-out indicator at your version :-)
<rsalveti> fixed at latest upload
<rsalveti> service gdm restart
<rsalveti> :-)
<alf_> rsalveti: I think will reboot to validate my speculations :)
<rsalveti> alf_: ok :-)
<alf_> rsalveti: so rebooted at gdm
<rsalveti> let me also try with gdm
<alf_> rsalveti: ssh, export DISPLAY, es2gears fails with es2gears
<alf_> No protocol specified
<alf_> EGLUT: failed to initialize native display
<alf_> rsalveti: should I try recovery mode for ubuntu desktop edition or classic desktop (or doesn't matter)
<alf_> rsalveti: or recover console?
<rsalveti> alf_: sorry, recovery console
<rsalveti> it's just the xterm
<rsalveti> if it's all black, open metacity first
<rsalveti> error while allocating memory could be related with the kernel module
<rsalveti> for sgx
<alf_> rsalveti: es2gears and glmark2-es2 both work in recovery console through ssh, even before starting metacity to fix the xterm
<rsalveti> alf_: hm, will try with X only
<rsalveti> alf_: interesting, fails while just loading X
<rsalveti> by hand
<rsalveti> even with metacity
<rsalveti> both es2gears and es2_info fails while trying to initialize gl
<rsalveti> alf_: works with root
<rsalveti> alf_: probably just permission issues
<janimo> rsalveti, how's the webkit crasher? Is it fixed now?
<rsalveti> janimo: yup, I'm just writing our latest image to test with it again, before posting at the bug to remove the workaround
<rsalveti> janimo: but I tested already, just want to make sure it works with the version that was uploaded
<rsalveti> easy to test
<janimo> rsalveti, ok . I was reminded now as Kate reassigned the bug to foundations
<rsalveti> janimo: oh, ok, should report the result soon
<rsalveti> took almost 33 hours to build
<rsalveti> that's why I even forgot to test it
<alf_> rsalveti: Right, it works as root. Note, however, that there is still a problem as a normal user after having done "xhost +"
<pmathews> Anyone looking for a cheap 720x480 color LCD?
<pmathews> Check out Bed Bath & Beyond: they are clearancing Sharper Image's Literati e-book reader for $40
<pmathews> Haven't started hacking mine up yet, but it has ARM processor running linux inside
<mrc3_> heyla! i have a problem while trying to build a package. is this the right place to ask?
<GrueMaster> Only if it is arm related.  If it is a general use package, you might get a better response on #ubuntu-devel.
<mrc3_> GrueMaster, thanks! it's intended for arm, but i guess i better go ask there
<GrueMaster> mrc3_: Just understand we can help with the arm bits, but there are far more devs on the other channel.  :)
<rsalveti> GrueMaster: NCommander: now for bug 727468 we just need to remove the livecd-rootfs workaround
<ubot2> Launchpad bug 727468 in webkit "ubiquity-slideshow tears down oem-config on armel" [High,Fix released] https://launchpad.net/bugs/727468
<GrueMaster> Cool.  I'll let him know when he comes back down to earth.
<GrueMaster> (flight lessons).
<StevenK> And the skies will never be safe again.
<ogra_> LOOOL
<lool> hmm?
<ogra_> you read my mind, eh ?
<ogra_> lool, i explicitly used three O's
<ogra_> :)
 * GrueMaster thinks lool needs to requisition a name change.
#ubuntu-arm 2011-03-16
<ppisati> ericm|ubuntu: ping
<ppisati> ericm|ubuntu: ping
<ppisati> ericm|ubuntu: still no sound after fiddling with alsamixer&c, can you confirm me that you've never heard any sound out of this board? (it's an A0 BTW) did you use another board previously for audio related stuff?
<ericm|ubuntu> ppisati, never tried on that board
<ericm|ubuntu> ppisati, X0 was OK
<ppisati> ericm|ubuntu: ok, thanks
<ppisati> ericm|ubuntu: i'll ask grue and ncomm when they wake up
<ppisati> ericm|ubuntu: do you know if they have A0?
<ericm|ubuntu> ppisati, 'k
<ericm|ubuntu> ppisati, they should
<ppisati> ericm|ubuntu: k
<ppisati> GrueMaster: ping
<lil_pete> hi guys. i've got my cross-compiled kernel running with a rootstock-filesystem. now i'd like to cross-comile some applications, but im struggling with dependencies since i get use apt-get build-dep... is somebody out there who could help me out a lil? =)
<lil_pete> **can't use apt-get build-dep.. :-/
<ogra_> do native builds or use xdeb, but it doesnt work with all packages afaik
<lil_pete> ogra_: so you mean natively build every package im depending on?
<ogra_> no, native vs cross
<lil_pete> oohhh
<lil_pete> then I'd have to install the full build-essentials on the device?
<ogra_> you can either do that on the real HW or in a chroot on the machine you used rootstock on
<lil_pete> hhmmm i was hoping i could avoid that
<lil_pete> ? chroot between platforms? i thought thats impossible
<ogra_> create a dir (call it chroot or so) and untar the rootstock tarball to it
<lil_pete> yeah i got that dir
<ogra_> sudo cp /usr/bin/qemu-arm-static </usr/bin in your chroot>
<lil_pete> i did a chroot do add / remove users, but executing arm binaries on a x64 machin?! *confused*
<ogra_> then you can just chroot
<lil_pete> uh that sounds good... let me try it, brb. =)
<ogra_> qemu-arm-static then wraps arm syscalls around every binary and translates them to x86 while you work inside the chroot
<ogra_> its slower than a real cross build, but prevents you from having to build on your HW
<ogra_> and you might hit syscalls that arent implemented, for 90% of the stuff it works fine though
<lil_pete> :-O
<lil_pete> duuuuuude... im just apt-get updating my arm system on my x64 laptop... *lol*
<lil_pete> awesome
<lil_pete> now let me try install gcc
<lil_pete> hmmm Unsupported ioctl: cmd=0xffffffffc020660b
<ogra_> janimo, whats the magic kernel cmdline i have to use for my panda to not have it constantly change its IP ?
<lil_pete> its still running though
<ogra_> lil_pete, just ignore that
<ogra_> there might also be unsupported syscall messages too
<lool> lil_pete: Use some newer qemu; the ~linaro-maintainers/tools PPA has a quite up-to-date one, I'd be surprized if you still got ioctl warnings with it
 * ogra_ must admit he hasnt tried the linaro qemu yet but i'm sure lool is right here
<lil_pete> lool: sorry, you lost me at "~linaro-maintainers/tools PPA"... ?
<lil_pete> <-- pretty noobish student :)
<ogra_> launchpad.net/~linaro-maintainers/tools
<lil_pete> aaahhhhh
 * lil_pete will be installing. :)
<lool> lil_pete: add-apt-repository ppa:linaro-maintainers/tools
<lool> Install qemu-user-static from this PPA, and you should get freshest qemu-linaro which fixes a bunch of missing support for some ioctls or syscalls
<ogra_> https://launchpad.net/~linaro-maintainers/+archive/tools
<lil_pete>  oh yeah that sounds good...
<lil_pete> hhmmm apt cant resolve the ppa:launchpad hostname? did i miss something?
<janimo> ogra_, I don;t think there is a kernel cmd option. I just set static IP in /e/n/i
<ogra_> well, iirc there was a way to give it a fixed MAC
<janimo> ogra_, no idea about that
<ogra_> currently my mac changes all the time which makes the board change its IP (i would like to go on using dhcp here)
<janimo> ogra_, rsalveti may know.
<ogra_> hmm, i'll resort to /e/n/i somehow for now
<rsalveti> ogra_: there was a cmdline argument that you could specify the mac address
<rsalveti> and you could also put it at network interfaces
<janimo> ftbfs status list seems to be updated less often
<ogra_> rsalveti, yeah, thats what i remember, i was to lazy to dig in the bugs :)
<ogra_> janimo, should be twice a day
<ogra_> probably it was dropped to once a day because it took to long to get all the data
<ogra_> persia would know if he had some way to think about such stuff atm i guess
<rsalveti> ogra_: bug 673504
<ubot2> Launchpad bug 673504 in linux-ti-omap4 "Pandaboard chooses a new IP address on each boot" [High,Fix released] https://launchpad.net/bugs/673504
<ogra_> hmm, it actually doesnt do that on each boot but while i'm connected via ssh
<ogra_> and checking even more, i just see it doesnt actually change the MAC at all
<ogra_> i wonder if there is something wrong with PM that powers off the NIC regulary
<ogra_> dmesg is quiet though
<ppisati> NCommander: ping
<GrueMaster> ppisati: pong.  On the dove boards, we used X0 for Lucid and A0 for Maverick.  Both have different audio codec chips.
<GrueMaster> No audio on Maverick.
<ppisati> GrueMaster: that means we need a new update BSP from Marvell to get the audio for A0?
<GrueMaster> Yes, but I wouldn't worry about it unless oem has a project that needs it.  We were only doing maverick to enable OEM.
<ogra> nobody uses the dove maveric kernel
<ppisati> actually i can't even find a maverick image for dove
<ogra> there was one, completely untested iirc but i know we built it
<ppisati> ogra: i think i'll my own, just for testing
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/
<ppisati> ogra: cool, thanks! :)
<lil_pete> ogra: xcuse my being so rude, i was so xcited about that chroot-ability. just wanted to say thanks man, you made my day. :)
<ogra> heh, you werent rude :)
<ogra> and lool helped too :)
<lil_pete> well i just left, if this were a real room that would have been more than rude.
<lil_pete> lool: thank you too, of course. dont wanna leave nobody out... :D
<GrueMaster> looking at the kde ftbfs packages, it looks like they all fail due to differences in GL header typedefs.
<rsalveti> could be that it's compiling with gl support, but using the libqt4-opengl with gles
<rsalveti> I know there are still some packages to port and fix
<ppisati> NCommander: i can't reproduce this one: https://bugs.launchpad.net/ubuntu/+bug/618489
<ubot2> Launchpad bug 618489 in casper "[dove] casper fails to boot if SATA HDD is attached" [High,Fix released]
<ppisati> NCommander: A0 board, sata hd attached
<GrueMaster> ppisati: Fix released
<ppisati> GrueMaster: in kernel too?
<ppisati> GrueMaster: in casper he has workarounded it
<ppisati> GrueMaster: in is_nice_device(), but if i take out that modification, my board still boot
<ppisati> GrueMaster: it refuses to fail! :)
<GrueMaster> So it was fixed in the kernel and the bug wasn't updated.  Happens.
<ppisati> GrueMaster: ok
<GrueMaster> I remarked it.
<ppisati> GrueMaster: let me just double check with Michael, then i close it
<GrueMaster> He lives here, and hasn't worked on Dove since Maverick release.
<ppisati> ah o
<ppisati> k
<ppisati> then i close it
<GrueMaster> But I have mine set up and can do all the testing.
<ppisati> GrueMaster: no, it's ok
<GrueMaster> Just fyi, I am the QA guy for the canonical-arm team.
<ppisati> GrueMaster: if you tell me that the fix was already committed, i'm fine with it
<GrueMaster> Like I said, a lot of older bugs were fixed without updating LP.
<ppisati> GrueMaster: ok
<GrueMaster> Main test is if it can be reproduced with a released image or updates.
<ppisati> GrueMaster: i used this one http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-netbook-armel+dove.img
<ppisati> GrueMaster: opened squash, took out the casper workaround in is_nice_device() and repacked
<ppisati> GrueMaster: and it worked
<GrueMaster> Yep, that was the maverick released image.  If a bug is based on that image, but prior to release and can't be reproduced on that image, it is usually been fixed.
<GrueMaster> I have been trying to retest and close out older bugs recently.
<ogra> ppisati, repacking the squash is a no-op
<ogra> you need to re-roll the initrd *from* the unpacked squashfs
<ogra> its quite complex
<ppisati> GrueMaster: to close a LP bug don't i need the sha? or i can just write "cannot reproduce it anymore, Tobin confirm it has already been fixed" and move it to "Fix released"?
<ogra> casper in the squashfs does nothing
<ppisati> ogra: ok
<ppisati> ogra: you are right, i'll do that
<GrueMaster> Or you could mark it as invalid as not reproducible.
<GrueMaster> ppisati: What type of marvell systems do you have?
<ppisati> GrueMaster: mvl-dove A0
<GrueMaster> ok
<GrueMaster> I want to make sure we have similar systems so I can help as needed.
<ppisati> ogra: rerolled uInitrd and it works
<ogra> using update-initramfs -u inside the squashfs ?
<ppisati> ogra: i'll tell you all the steps i took
<ppisati> copied /casper/filesystem.squashfs from the my usb stick (where i previously i dd-ed the maverick mvl-dove img) to my box
<ppisati> unsquashed it
<ogra> well, its essentially: unpack squashfs, mount proc and bindmount /dev, chroot into it ...
<ppisati> copied qemu-arm-static to squash/usr/bin
<ppisati> chrooted in it
<ogra> make your code change, run update-initramfs -u etc etc
<ogra> sounds like you took the right steps
<ppisati> modified usr/share/initramfs-tools/scripts/casper
<ppisati> and revrted the mvld-ve workaround
<ppisati> then
<ppisati> update-initramfs -u -k 2.6.32-410-dove
<ppisati> mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d /boot/initrd.img-2.6.32-410-dove /boot/uInitrd
<ogra> right, sounds ok
<ppisati> and finally copied uInitrd back to usb:/casper
<ppisati> ok
<ppisati> then i mark that bug as Invalid so we can close it
<ogra> i think tobin already marked it fixed
<ppisati> ogra: the casper part, mvl-dove kernel was still pending
<ppisati> and i'm trying to clean up as much as possible
<ogra> ah, k
<ppisati> "This bug is not reproducible anymore in linux-mvl-dove, and after a bit of testing on IRC with Tobin and Oliver we concluded it has already been fixed. Closing it."
<ogra> sounds fine
<ppisati> k, done
<ppisati> ok, so now i have the 2 sound bugs and the rebase/-proposed pending
<ppisati> cool
<ogra> phew ... finally
<ogra> so teleporter-glib should be installable again... and thus empathy
<ogra> GrueMaster, you should have images tomorrow again
<GrueMaster> Yea, saw the update for telepathy.
<ogra> well, i wasnt sure it would build :)
<ogra> just finished fine
<NCommander> ppisati: thebug itself was worked around in casper, but we had a task on thekernel due to change in name of the device
#ubuntu-arm 2011-03-17
<vin> hi
<vin> the installation broke down
<vin> how can I get into the TTY
<vin> I have no default username/password
<lil_pete> vin: you can mount the filesystem on another linux machine, chroot into it and do $passwd <username>
<lil_pete> you can do even more stuff using qemu: http://wiki.debian.org/QemuUserEmulation
<lil_pete> hey guys can somebody tell me how to install cross-compiled modules?  i cant use make install... can i? :-/
<lil_pete> (im talking about non-kernel modules)
<lil_pete> ((meaning its a driver that isnt included in the kernel)) :D
<ogra_> GrueMaster, how does your panel crash ?
<ogra_> works fine for me
<GrueMaster> Not sure of the nature of it yet, but it dies & respawns continuously atm.
<GrueMaster> could be the resolution.
<ogra_> ah, yeah, i remember something that requires 800px with
<ogra_> *width
<ogra_> you shouldnt see gnome-panel at all though
<ogra_> did you explicitly pick gnome-session at gdm ?
<GrueMaster> Well, whatever is generating the top panel is respawning.
<ogra_> thats unity-2d-panel
<ogra_> (Qt app)
<GrueMaster> Tomato tomato.
<rsalveti> GrueMaster: issue we had was with gnome-panel
<rsalveti> and not unity-2d-panel, so it's probably a different bug this time
<GrueMaster> Yea I know.  Still, same visual effect.
<ogra_> does it go away if you use a higher res ?
<GrueMaster> Don't know.  Just rebooting with the fix now.
<GrueMaster> nope.
<GrueMaster> Hmmm.  Why is there a /home/buildd dir?
<ogra_> that shouldnt be there
 * rsalveti lunch
<GrueMaster> It's on the image I downloaded.  Very odd.
<ogra_> i see it here too
<GrueMaster> Thought it might have been a glitch in the SD.
<GrueMaster> ok
 * ogra_ just copies a loop mounted natty netbook into the ac100 
<ogra_> there is only the homedir though, no user
<ogra_> root@isis:/# dpkg -S /home/buildd
<ogra_> dpkg-query: no path found matching pattern /home/buildd
<ogra_> doesnt come from a package (would have surprised me)
<ogra_> not in any postinst either
<GrueMaster> ls
<GrueMaster> gah
<GrueMaster> I think I know why the bug reports are broken.  There is a chromium-browser bug that the script is failing on.
<ogra_> oh?
<ogra_> how can that be
<GrueMaster> Hmm.  Not related.  Working with Brian now.
<GrueMaster> The unity-2d-panel issue appears to be sound related (figures).
<GrueMaster> dmesg has a long list of "asoc: no valid backend routes for PCM:  SDP4430 Media" and .xsession-errors shows libsoundmenu.so is respawning.
<GrueMaster> Interesting.  This issue is omap4 only (beaglexm works fine).
<rsalveti> dual core?
<janimo> which issue?
<GrueMaster> janimo: The libsoundmenu respawn issue.  And I am not sure yet if it is dual core related.  That is my next step, although I doubt it.
<janimo> ah, I am not uptodate with U-2d related bugs
<janimo> I think I should test that too again
<GrueMaster> This is new as of today's image.
<janimo> I found both compiz an u-2d frustrating to use on x86
<janimo> so did not even tried to use it on arm
<GrueMaster> And I didn't see it yesterday when updating an older image.
<janimo> GrueMaster, there were again libindicator related updates since yesterday, is the soundmenu among them?
<GrueMaster> Might be.  Let me work to dig deeper for a bit.
<GrueMaster> Need food atm.
<GrueMaster> After much digging (mainly in the dark), it appears that the schema from indicator-sound is not being properly registered.
<ogra_> GrueMaster, i claimed the flash-kernel doesnt respect double dash notiation bug back
<ogra_> will work on that during the flash-kernel reworking
<GrueMaster> ok.  Are you actually going to fix it?  It has been there since karmic.
<GrueMaster> ok
<ogra_> its a pretty big task and bound to architectural design changes for flash-kernel-installer
<ogra_> i always planned to work on it ... currently we dont use live or d-i images so its not pressing
<GrueMaster> I'm just trying to whittle down open bugs.
<GrueMaster> btw:  I am making some progress on the unity-2d-panel respawn.  It so far appears to be indicator-sound update.
<GrueMaster> I'm getting ready to backrev and see if it still fails.
<GrueMaster> It is not smp related, but it is omap4 specific (runs fine on beaglexm).
<ogra_> try linking the binary of indicator-sound to /bin/true ;)
<ogra_> runs fine here too
<ogra_> even with broken sound in the kernel
<GrueMaster> Looks like there is a new version as of 3 hours ago.  Will try it first.
<GrueMaster> I have a feeling something broke in the newer releases for the postinst, as upgrading from 20110311 works fine.
<ogra_> fun
<ogra_> its probably the buildd user that broke it :P
<GrueMaster> heh
 * ogra_ really has no clue where that could come from
<GrueMaster> Simple.  A botched update to the posinst script or a bad tweak to the schema.xml file.  The old settings would be still valid.
<ogra_> i was referring to /home/buildd
<GrueMaster> Oh, that.
<GrueMaster> Hmm.  Looks like all of the com.canonical.indicator.* schemas may be hosed.  Updating indicator-sound got passed it's issue, now datetime failes.
<GrueMaster> (as does my typing)
<ogra_> weird
<ogra_> i'm using an omap3 image here, freshly installed on the ac100
<ogra_> (with rolled back libc but no other modifications)
<ogra_> apart from the g-s-d breakage all seems to be fine
<GrueMaster> I can't really consider running on a non-supported system with a non-supported image completely valid.  Besides, it also works fine on my beaglexm
<ogra_> pfft
<ogra_> userspace is always the same
<GrueMaster> There can always be subtle hardware differences.
<ogra_> as long as you have all kernel options it should be fine
<ogra_> which we need to cover :)
<GrueMaster> Not up to us to validate hardware.
<GrueMaster> yet
<ogra_> up to us to make sure userspace runs on all v7 HW
<ogra_> which is one of the reasons to not hard build with NEON enabled
<GrueMaster> Then give me more v7 systems to test on.  Otherwise I can't comment on failures for which I have no hardware.
<ogra_> imho we all should have ac100s and efikas
<GrueMaster> Well, that I'll definitely agree to.  :D
<ogra_> just to be able to validate
<ogra_> i'm considering buying a second one ... i just found out the 3G version is available for 199â¬ now
<ogra_> http://launchpadlibrarian.net/66592855/20110317-ubiquity-sarcasm.png
<GrueMaster> Not bad.  Wish I had the $$$ to spend.
 * ogra_ grins
#ubuntu-arm 2011-03-18
<ogra> GrueMaster, any idea why florence isnt in the archive ? the source was accepted and the binaries are lintian clean, so i dont get why they didnt make it into the archive
<ogra> (your mail indicates you know more)
<Xase> Hi, I had a couple of questions.
<ScottK> ogra: https://lists.ubuntu.com/archives/ubuntu-archive/2011-March/039958.html
 * ogra bangs his head against the serial console 
<ogra> sigh
<GrueMaster> morning, ogra.  Did you see the link above regarding florence?
<ogra> GrueMaster, yes, i'm half done adding an .install file (/me fiddles with it every time he has a spare min)
<GrueMaster> cool
 * rsalveti lunch
#ubuntu-arm 2011-03-19
<ruckuus> Hello everyone
<ruckuus> I am having issue when trying to make Debian work on my board, but I found following problem: When boot up, the system ask for inittab, and also ask for runlevel input
<ruckuus> Enter runlevel: .... (?)
<ruckuus> the root filesystem is put in NFS and this is a fresh rootfs, result from debootstrap
<ruckuus> I expected to run /debootstrap/debootstrap --second-stage in this step
<ruckuus> Thanks in advance
#ubuntu-arm 2011-03-20
<XaSe> Hello ARMites...
<XaSe> Is anyone actice today?
<XaSe> *Active*
<robclark> rsalveti / hrw, maybe dumb question, but is it possible to cross-compile perf tool?  It seems it needs a cross-libelf-dev installed..
<robclark> hmm, ok.. built it natively which will hopefully coexist with cross-compiled kernel..
<robclark> but seems crashy :-(
#ubuntu-arm 2012-03-12
<mail> is there a channel for arm assembly dev ?
<cooloney> NCommander and GrueMaster, hey, guys, i've already uploaded armadaxp kernel to our PPA. which builts fine
<cooloney> please help to test on real hardware
<NCommander> cooloney: saw your email. I'll punt it in the archive tomorrow morning
<cooloney> NCommander: cool, you still around? it's mid night, i guess
<NCommander> cooloney: genius never sleeps!
 * NCommander laughs evilly
<cooloney> NCommander: if you got any new patches, please drop to me
<NCommander> cooloney: none
<cooloney> OMG,
<NCommander> ?
 * cooloney hugs NCommander genius
<cooloney> NCommander: i'm waiting for my Galaxy Nexus
 * NCommander has his and it is awesome
<cooloney> i will get it this weekend
<cooloney> cool, i always follow your choice
<NCommander> Need to rebuild the kernel to put NFS on it so I can use it as a buildd
<cooloney> NCommander: you need buy 10 of GN and that's a good building cluster
<NCommander> ahaha
<RoyK> Neko: thanks
<RoyK> hi all. I installed 12.04 beta1 on this pandaboard, and now it seems the new users I have created are invisible on login. the initial user was at first the only one visible, but now, only the last user created is visible to login. any idea what might cause this?
<ogra_> RoyK, either a bug or improper usage of the tools to create users, what did you use ?
<RoyK> ogra_: probably a bug, then, just curious noone has seen it yet. I used the standard gui tools to create two admin users
<ogra_> yeah, that pretty much sounds like a bug
<RoyK> any idea where the bug might be? I mean, the users are in /etc/passwd etc, but aren't visible to the gui tools either
 * ogra_ knows that some people inappropriately use useradd etc 
<RoyK> I sometimes do, but I didn't do that now
<RoyK> so, user uadmin was created during install and then let's call them usera and userb, and now only userb is visible along with guest - not even 'type thy username' is possible - is that disabled somewhere by default?
<ogra_> you should be  able to scroll through the userlist at the login manager by clicking the not highlighted one
<ogra_> iirc it only shows two by default and keeps the last used one selected
<ogra_> (unlike in 11.10 where it showed three from the list)
<RoyK> ogra_: it shows userb and guest, and nothing else. the user manager doesn't show the other users either
<RoyK> but still, UIDs are unique and things look good in the files
<ogra_> surely a bug then
<ogra_> i would file it against gnome-control-center as a start
<ogra_> and probably lightdm too
<ogra_> i can reproduce it here
<ogra_> adding a new user doesnt ask for a pw ... after that the new user isnt visible in the user management tool ... upon reboot i can only select the new user or a guest session
<ogra_> and indeed selecting the new user doesnt get me anywhere since he has no pw
<ayaka> why does abootimg must have a initrd to create img
<ogra_> aks upstream :) but i guess it is because the bootloader simply requires it
<RoyK> ogra_: I set a password for the new users manually (passwd <user>), and the old user I created during installation is also hidden
<RoyK> something is pretty fscked up in the user part...
<ogra_> for me the old user shows up on next start of the admin gui
<ogra_> yes
<ogra_> file it please
<RoyK> will do
<RoyK> but now: Lunch!
<ppisati> brb
<ayaka> ogra_ but i have a custom kernel
<ayaka> is there more  infomation about fastboot except android mod wiki
<lilstevie> ogra_, I have a question regarding the L4T drivers you have packaged up
<RoyK> https://bugs.launchpad.net/ubuntu/+bug/952909
<ubot2`> Launchpad bug 952909 in ubuntu "New users invisible/unusable" [Undecided,New]
 * ppisati -> out for lunch
<ayaka> ogra_ thank you
<RoyK> ogra_: seems #952909 is being given some priority...
<ogra_> well, i added some prio
<RoyK> ah :)
<ogra_> the desktop team still needs to accept that :)
<RoyK> I guess that should be possible, though
<RoyK> not a very obscure bug
<ogra_> well, tricky to debug for them as they have no arm HW yet and it seems to be arm specific
<ogra_> sdo expect more questions :)
<lilstevie> ogra_, how do you get around all EGL apps trying to use mesa-egl over tegra-egl on the ac100?
<ogra_> lilstevie, i use the packaged nvidia-tegra driver :P
<lilstevie> ogra_, tried that
<ogra_> (it sets the right alternatives in the postinst)
<ogra_> well, works fine here
<RoyK> ogra_: I can possibly expose a pandaboard on the net if that would be of any help
<ogra_> though its moot now that we switched to armhf by default
<lilstevie> things like glmark2-es2 still go for mesa
<lilstevie> ogra_, this is on oneiric
<ogra_> RoyK, hardly, since its a desktop issue
<RoyK> true...
<ogra_> lilstevie, iirc we didnt have the package for oneiric
<lilstevie> the one on the ppa doesn't do it correctly?
<ogra_> RoyK, but ask in the bug, i'm not the desktop team ;) probably they have ways
<RoyK> ogra_: btw, I think I've seen similar in oneiric desktop/amd64
<ogra_> lilstevie, the one in the PPA is ages old, and likely broken in several reagrds (and was for natty)
<RoyK> ogra_: but I'll have to doublecheck that
<ogra_> RoyK, if you can confirm that, note it on the bug ;)
<lilstevie> ah ok
<RoyK> ogra_: erm - not oneiric, precise
<RoyK> but yes, I will
<ogra_> lilstevie, the latest precise one should work fine if you never installed one of the broken ones
 * RoyK runs to check
<lilstevie> ogra_, I will reflash my prime later and try
<ogra_> lilstevie, the older ones did set the alternatives wrongly
<ogra_> i also never tried anything else than es2gears and es2_info
<lilstevie> ok, well that would explain the issues I am having (alternatives being wrong)
<lilstevie> yeah, es2gears and es2_info are still relying on the mesa ones
<xranby> lilstevie: some projects like jogl and lwjgl   first probes all available libEGL variants installed on the system and  decides to pick the hardware accelerated one if both mesa and a nvidia driver are present
<lilstevie> xranby, ok cool, just trying to get a true benchmark of the GPU on the tegra3
<ogra_> are the beta drivers supposed to support tegra3 already ?
<lilstevie> yes
<lilstevie> they do
<ogra_> ah, cool
<xranby> lilstevie: the quickest thing you can do are to pass LD_LIBRARY_PATH=/usr/lib/nvidia-tegra es2gears
<xranby> if the program for some reason are hardwired to mesa
<ogra_> you are using the alpha drivers if you used the PPA though :)
<lilstevie> I did something nasty in my own install and symlinked libEGL{whatever} to the nvidia ones
<lilstevie> ogra_, actually, not from the pap, just realised the link was from the ac100 wiki
<ogra_> ah
<lilstevie> well the entry on the ubuntu wiki
<ogra_> yeah, that links to the ones with the broken alternative
<lilstevie> https://wiki.ubuntu.com/ARM/TEGRA/AC100#Graphics
<xranby> lilstevie: try glmark2-es2
<lilstevie> ah
<ogra_> (the later ones didnt work on oneiric iirc)
<lilstevie> xranby, I did, with the horrible symlinking hack
<lilstevie> but the alternatives being broken in that package explains the issue
<lilstevie> xranby, score is 189 overall
<lilstevie> but I did not handle it as well as I probably should have
<lilstevie> I just symlinked mesa-egl to nvidia-driver
<xranby> hopefully we can get the alternatives correct for the precise release
<xranby> so that things work as intended out of the box
<lilstevie> well hopefully we get some hf drivers too
<xranby> lilstevie: at least things are better now compared to say 2009, back then some hardware got shipped without any hardware accelerated drivers at all like the sharp pcz1.
<lilstevie> true
<lilstevie> it was nice to have almost out the box support for acceleration on the tf201
<xranby> the interesting thing about the sharp pcz1 are that this machine can actually boot the imx53 kernels.. so in theory you should be able to get the imx53 system with hardware acceleration running on the pcz1 by booting up a new kernel and using the right xorg libEGL and friends
<lilstevie> I still wish I could get some acceleration on the galaxy tab 7" the original one
<lilstevie> cause that has a hummingbird processor, with SGX540
<xranby> which GPU are used on the galaxy tab 7" ?
<xranby> ok
<lilstevie> but that seems rather painful to actually get working
<steev_> xranby: the pcz1 is mx51 isn't it? should be able to use freescale's gpu stuff for it
<xranby> right :)
<xranby> its mx51 and got 512mb of ram
<xranby> + neon
<xranby> on paper it are still capable of running the latest linux distributions
<steev_> xranby: have they released the kernel sources yet?
<xranby> freescale have not released the sourcecode for the amd gpu driver
<xranby> since they do not own it
<xranby> the kernel sourcecode exist
<xranby> the hardest part are to deal with the bootloader
<xranby> red_boot
<xranby> you can boot your own kernel quite easily
<xranby> place it on a sdcard inside a boot folder and place a boot.conf containing    /boot/zImage   and bootflags
<xranby> you can then boot this kernel by holing down the both mousebuttons at statup
<xranby> its harder to replace the flashed kernel
<xranby> so if someone have a lot of free time
<xranby> 3d on the sharp are possible
<xranby> by using the latest freescale board support package
<lilstevie> heh
<lilstevie> sounds like a pain
<steev_> xranby: oh i work for Genesi, i know all about the freescale fun
<steev_> ugh, yeah i can reproduce that bug 952909 here on an efika :(
<ubot2`> Launchpad bug 952909 in accountsservice "Some users invisible/unusable" [High,Confirmed] https://launchpad.net/bugs/952909
<steev_> i'm surprised no one on the desktop team has an efika, we gave ~52 out to ubuntu developers, where did they all go?
<lilstevie> lol
<lilstevie> maybe people are having too much fun with it
<steev_> that's one of many possible situations
<steev_> i'd tell the desktop team to check their closets :P
<xranby> steev_: hi, are the armhf port fully hardware accelerated now on the efika?
<steev_> xranby: ubuntu or debian
<steev_> afaik, the debian image that markos made a few months back is
<steev_> i've been working on precise for the efika, but it's been a bit slow going
<xranby> ok. i guess i will have to test that one on my sharp then :)
<xranby> the debian image
<lilstevie> steev_, the efika looks kinda cool actually
<steev_> as i'm mostly doing it in my free time and i was sick last week and moved this past weekend.  still trying to unpack and set up my lab
<steev_> lilstevie: i enjoy them :)
<xranby> is there anything the community can help with to get the bardware acceleration bits in place?
<xranby> hardware
<steev_> xranby: nope, we can't give people access to the gpu source
<xranby> ok, i keep on working on the software layers that uses libEGL then
<steev_> xranby: sorry :/
<xranby> mostly workaround bugs in all the different binary blob drivers
<lilstevie> steev_, heh, I have been stuck with tegra hardware, I have the trimslice for a desktop, and a tf101 and a tf201 as laptops
<steev_> lilstevie: oh nice, i have 2 of the trimslices, one of the dev models, and one of the Pro units
<steev_> i still need to ship them back so they can fix the pmics (i was an early adopter)
<lilstevie> yeah I have a pro
<lilstevie> tf201 has been the most fun
<steev_> i may get around to it next month or so
<steev_> what's a tf201
<lilstevie> tegra3 is a lot more powerful than the older hardware
<steev_> lilstevie: i'd hope so :P
<lilstevie> heh
<lilstevie> I mean a lot
<lilstevie> doesn't have the tegra2 fail feeling
<steev_> didn't they gimp the memory on the tegra2?
<steev_> i've seen the mx6 in action, i'm pretty excited about it
<xranby> steev_: do the mx6 support opencl??
<steev_> xranby: i've not been handson so i'm not sure, iirc there was mention of it in the documentations at FTF
<xranby> i got the impression it supports "desktop grade" opengl so that you can basically run unmodified opengl applciations..
<xranby> if it runs opencl as well then its the first mobile gadget i know that can run really cool stuff
<steev_> that was in the documentation as well, without hands on, i can't say
<steev_> i don't wanna be all, oh yeah, it does and it's awesome
<steev_> and then be lying
<lilstevie> heh
<mik2> Hello guys,
<mik2> do you mind a beginner question about beagleboard xmand ubuntu?
<mik2> does anyone have experience with rcn-ee ubuntu images for beagleboard?
<mik2> I build an image following this http://elinux.org/BeagleBoardUbuntu#Oneiric_11.10 and managed to run it... but I can't find a way to play audio, although from console it doesn't seem there is any error...
<mik2> did anyone expereinced it?
<brendand> mik2, do you have some audio device connected (headset etc)?
<GrueMaster> mik2: What does /proc/asound/cards list?  There has been an issue for a while on beagle audio in Ubuntu.
<mik2> headset yes, or a speaker with amplifier: same 'none' result
<mik2> let me try
<GrueMaster> Headset or speaker is irrelevant.  The kernel is not detecting the onboard audio codec.  I think it is because the driver needs to be built into the kernel (not a module).  See bug 925094 for more info.
<ubot2`> Launchpad bug 925094 in linux "No audio on omap (beagleXM) system" [Medium,Confirmed] https://launchpad.net/bugs/925094
<mik2> $ cat /proc/asound/cards
<mik2>  0 [omap3beagle    ]: omap3beagle - omap3beagle
<mik2>                       omap3beagle
<mik2> oh my...
<mik2> thanks for this...
<mik2> does it mean that there is no way around it than building my own kernel?
<GrueMaster> Oh, you are seeing audio.  In that case, you need to fiddle with the alsamixer controls to boost volume.
<mik2> ah! that's a better news (ta!) do you mean from GUI presumably?
<mik2> or actually maybe the same
<mik2> I'll try that
<mik2> thanks a lot
<GrueMaster> alsamixer is a text gui of sorts.
<mik2> I see (I see it badly from minicom, I'll try ssh into it). thanks for this
<mik2> Generally, would you better use an official ubuntu image rather than an RCN one?
<mik2> I am asking this because.... I didn't manage to get an official ubuntu one to load and run, while it went quick and smoothly with ths rcn one
<mik2> but I don't know if there are downsizes...
<GrueMaster> You can also use screen on the serial console.  "screen /dev/ttyUSB0 115200" (or whatever your serial port is).
<GrueMaster> Better than minicom.
<mik2> oh! does it use an usb cable? (where did I live until now? :-)
<GrueMaster> Well, my "preference" is kind of irrelevant.  I work for ubuntu.  I am the Arm QA guy.
<GrueMaster> I was referring to your serial port on your desktop system.  If you are using usb serial, it is ttyUSB#.  If it is built in, it is ttyS#.
<mik2> screen (in the same port than minicom) seems to hung in my pc... must be something else. But thanks for the tip, I will investigate this in a second time. I actually can use a HDMI cable, so probably I'll go the easy way
<GrueMaster> Ok.  We have both headless (server) and Desktop images for beagle.  The desktop images do not put much on the serial console by default though.
<GrueMaster> What rev beagle do you have?
<mik2> xm rev c
<GrueMaster> Cool.
<GrueMaster> Care to test the latest stuff?
<mik2> you know what - along the side of being incompetent - I may have started on the wrong place for the beagleboard  ubuntu installation
<mik2> I can't promise results, but I can promise to try
<mik2> I am not sure what I need but I bet desktop rather than server is more for me
<GrueMaster> http://cdimage.ubuntu.com/daily-preinstalled/current/precise-preinstalled-desktop-armhf+omap.img.gz for desktop, http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/precise-preinstalled-server-armhf+omap.img.gz for server.
<GrueMaster> Desktop is for doing anything with X.  Server is more for headless development work.
<GrueMaster> At any rate, we have decent installation instructions at https://wiki.ubuntu.com/ARM/OmapNetbook.  Just substitute the new image name.
<GrueMaster> I am really curious how it runs on your system.  I am seeing issues on my beagleXM Rev B, but I have nothing to compare it to.
<mik2> honestly following these installation instructions on that link, my SD card didn't make it to boot...
<GrueMaster> Buh???
<mik2> although its size is 1 Gb (not 4 as recommended) but I thought that it should be enough for starting
<GrueMaster> Ah, that would explain it.  The images are almost 2G uncompressed.
<infinity> mik2: You'd think wrong.
<mik2> well, I tried only the sh cmd: it didn't give any error so I didn't feel it was to be tried with 3 steps
<mik2> ah! sorry then
<mik2> I thought that was a minimal... my fault...
<GrueMaster> 4G is the recommended minimum.  The desktop image won't even fit on a 2G card iirc.
<infinity> It might, just barely.  Haven't looked in a while.
<infinity> But yeah, it hovers around 2G.
<mik2> listen, for audio capability is Server distro a good choice? I need to run some python scripts that play audio
<mik2> or is better desktop?
<infinity> mik2: If all your stuff is command-line, server would be fine.
<mik2> yes it is, Ok I'll try that! let me steal a card first :-)
<mik2> and generally I presume that python packages would be equally available in a server and in a desktop... right?
<infinity> Yep.
<infinity> It's all the same archive.
<GrueMaster> Yes.
<mik2> thanks
<infinity> The difference between image types is what's installed by default.
<mik2> ah ok
<mik2> GrueMaster: it is taking long to decompress so I think I'll let you know tomorrow how it did go with the server on BeagleBoard xm rev C
<GrueMaster> It should't take too long.  What size SD are you using?
<mik2> 4 gigs now
<GrueMaster> Ok.  That should boot to oem-config in ~10 minutes or less.
<GrueMaster> Desktop or server image?
<mik2> it was far more than 10 min (but my pc was doing other stuff). Desktop img
<mik2> booted
<mik2> now tells me: resizing root pa
<mik2> I should not be worried right?
<GrueMaster> This is normal.  It should reboot after this.  Then it will come up in X with oem-config.
<mik2> do you know username and pwd by hart? I can find them if not
<GrueMaster> The image resizes root to fill the SD card prior to running in it.
<GrueMaster> There are none by default.  oem-config will prompt you to create a user.
<mik2> cool, thanks
<mik2> hwclock: select(
<mik2> does it expect some input?
<GrueMaster> It shouldn't.  Are you in an X gui?
<mik2> no
<mik2> let me switch
<mik2> mmm nothing comes up as gui
<mik2> oh no!
<mik2> I didn't follow the instructions "update for BeagleXM rev B & C"
<GrueMaster> One sec.  I'm flashing a daily to SD now.
<mik2> grrr... sorry
<GrueMaster> No need.  That is for older releases.
<mik2> ah
<GrueMaster> Yea, that "update" was because TI released a new spin of hardware the week after Natty release.
<GrueMaster> I fixed the wiki.  Thanks for pointing that out.
<mik2> I didn't mean to :-D ahaha
<mik2> so I guess.. I should try to reboot...
<GrueMaster> Ok, I'm booting here.
<mik2> it is still hanging on hwclock: select(
<GrueMaster> Did you change console screens or something?  Try <ctrl><F7>.
<mik2> nothing comes out on the hdmi cable :-(
<GrueMaster> Weird.  This is the desktop image, right?  What other video source do you have plugged in?
<GrueMaster> I'm getting video on hdmi here.
<mik2> I have my hdmi cable into my pc monitor. It used to work with Angstrom
<mik2> I'll try to reboot and see if something happens
<mik2> nothing to lose
<GrueMaster> Yes.  Also, does your monitor support 1280x768?  I think that is the default res for some odd reason.
<mik2> now hanging on 'fsck from util-l'
<mik2> yes it does
<mik2> another reboot: stuck again on
<mik2> fsck from util-1
<mik2> util-l
<GrueMaster> hrm.
<mik2> I may want to try an older image
<GrueMaster> I'm booting the current desktop image here just fine (except no network or audio).
<mik2> ** Unable to read "preEnv.txt" from mmc 0:1 **
<mik2> Hit any key to stop autoboot:  0
<mik2> The user button is currently NOT pressed.
<mik2> SD/MMC found on device 0
<mik2> reading uEnv.txt
<mik2> ** Unable to read "uEnv.txt" from mmc 0:1 **
<mik2> do these things matter?
<GrueMaster> That is normal.
<mik2> now blocked on hwclock: select(
<mik2> funny
<GrueMaster> u-boot looks for preEnv.txt and uEnv.txt before loading boot.scr.
<GrueMaster> That I don't understand.
<GrueMaster> Are you seeing a text screen or something else?
<mik2> I am still using minicom. I'll post you the output
<GrueMaster> You should be seeing a splash screen.
<mik2> no I don't see anything from HDMI
<mik2> U-Boot 2011.12 (Feb 16 2012 - 18:25:19)
<mik2> OMAP3630/3730-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
<mik2> OMAP3 Beagle board + LPDDR/NAND
<mik2> I2C:   ready
<mik2> DRAM:  512 MiB
<GrueMaster> Oh.  You shouldn't see much of anything on minicom.  How did you flash this image to SD?
<steev> heh
<GrueMaster> The last thing you should see on minicom is "Uncompressing Linux... done, booting the kernel."  Nothing else.  If you are seeing something else, you imaged the SD wrong or are using a different image.
<mik2> I will try tomorrow to use 3 separate commands rather than sh 'zcat....' as instructed in the web sitge
<GrueMaster> What did you use for "of=" ?
<mik2> /dev/sdb
<mik2> so you are using this one right? precise-preinstalled-server-armhf+omap.img.gz
<GrueMaster> Ok.  That should be right.  Might need to blank the SD first.  Try "sudo dd bs=4M count=256 if=/dev/zero of=/dev/sdb"
<GrueMaster> That is the server image, not the desktop.
<mik2> did I say desktop? DAMN I DID! sorrry sorry sorry
<GrueMaster> And it should come up with more on minicom (although I prefer screen).
<GrueMaster> heh.  NP.
<mik2> really sorry, I am nackered!
<mik2> I think server should do as I don't need gui and as it will be able to play audio anyway
<mik2> blanking sd card now
<GrueMaster> What is the serial port on your desktop system?  The one that you are using in minicom?
<mik2> ttyS0
<GrueMaster> Ok, so to use screen, typ "screen /dev/ttyS0 115200".  It will look more like a normal terminal window.
<GrueMaster> Ok, I have a working desktop here.  Now switching to server.
<mik2> Ok thanks. It is still blanking the sd card... and I am sorry but I must leave now... I will be fighitng with this tomorrow morning again
<mik2> maybe I'll find you in this chat to tell you how did it go?
<GrueMaster> I'll be here.
<mik2> really sorry : must leave. Thanks for your great help and patience.
<mik2> Have a good night!
<GrueMaster> I think I hit the same issue.  Will let you know how it goes.
<mik2> cheers, thanks
#ubuntu-arm 2012-03-13
<sveinse> I have a natty system which locks up during boot. My suspicions goes to mountall as previously discussed on  here.
<sveinse> I've created an early login with getty on ttyO2. I notice that echo foobar >/dev/console does not print anything on my console, yet the kernel is setup with console=ttyO2,115200n8
<sveinse> Why could that be? Does ubuntu initramfs do anything special to the console?
<sveinse> I.e. where does /dev/console go if not to the console i've specified on the kernel command line
<ogra_> sveinse, do you have devtmpfs enabled ? thats usually mounted by initramfs as first thing
<mik1> cd
<mik1> ll
<ogra_> file not found
<sveinse> ogra_ yes I think so. When logged into the system devtmpfs is mounted.
<sveinse>  /dev/console has another major/minor number than ttyO2, so I presume the kernel handles this redirection?
<ogra_> if your console= args are right
<sveinse> ogra_ I wouldn't get the initial demesg output from kernel without it. However I have observed for a long time that when the initramfs takes over, any output to the console is stopped
<ogra_> you would get the initial dmesg oputput
<ogra_> for a console on ttySX you need two console args
<sveinse> I have console=ttyO2,115200n8
<ogra_> (forst is for kernel, second for userspace)
<ogra_> *first
<sveinse> aha. so console=ttyO2,115200n8 console=ttyO2
<ogra_> try that and see if you get more
<ogra_> also make sure to not have "quiet" set
<ogra_> this will definitely suppress all msgs from initrd
<sveinse> thanks, I'll certainly try
<sveinse> ...and all of the sudden I cant binfmt armel exec's (e.g. debootstrap) on my natty host (amd64). Has something changed recently in respect of kernel
<sveinse> I notice binfmt_misc.ko is not loaded automatically any longer, and modprobing it does not help the issue :(
<mik1> guys is anyone of you playing audio from the beagleboard? if yes could you please advice which distro to use?
<sveinse> All binfmts were apparently set to disabled. update-binfmts --enable qemu-arm did the trick. Wonder why though
<ayaka> could i let second-stage bootloader don't anything in  a android mobile to boot a linux kernel
<sveinse> ogra_ I worked by doubling console=, thanks! It also reveals why mountall is apparently locked up, see http://paste.ubuntu.com/881794/
<sveinse> Note that I'm not using fixrtc in this setup
<ogra_> apparently :)
<ayaka> could i let second-stage bootloader don't anything in  a android mobile to boot a linux kernel
<sveinse> ogra_ I have basically two options: Either run with fixrtc but then I need the patch you made (haven't checked if the patch has made into natty-update though)
<sveinse> Or without fixrtc, but then I need to get past this interactive part which I pasted
<sveinse> We had a discussion internally, and we prefer not using fixrtc as it has unexpected sideeffects if the user (for some reason) needs to set the time backwards
<ogra_> well, make your installer remove fixrtc from the cmdline after its clear the clock is right, thats the only sane option
<ogra_> imho
<sveinse> yes, I partly agree. Since the product has no interactive way of dealing with questions from mountall, its not an acceptable option either. The RTC battery will expire within the lifetime of the product
<sveinse> Unless other simpler options I am considering making a plymouth theme which can respond to such messages and supply keystrokes to allow it to continue
<danboid> Would anyone know of any newer kernel packages for 11.10 armel Panda as the repo ones don't have ALSA sequencer support compiled in it seems
<ogra_> danboid, you could ask linaro or check the TI PPA
<danboid> ogra_, I've tried 3.1.0 from the PPA but that had the same issue- I presume I can use the linaro 11.10 PPA with canonical Ubuntu right?
<danboid> ogra_, 3.1.0 from the ti ppa
<ogra_> for just the kernel that should be fine
<danboid> So what does Linaro offer over the canonical builds/distros?
<danboid> Whats the relationship between Linaro and Canonical?
<gildean> danboid: http://www.linaro.org/engineering/
<sveinse> ogra_ , does initramfs honor/bring along /etc/e2fsck.conf ?
<sveinse> I.e at the time of mountall and e2fsck, /etc is inside the initramfs, right
<ogra_> well, if its in place it should be used
 * ogra_ hasnt tried it ever 
<sveinse> ok, thanks
<sveinse> Has ureadahead any improving features on armel (natty)? On my system it just reports ureadahead terminated with status 5
<sveinse> ..running off a sdcard
<ogra_> its in two parts, one improves the loading at boottime, the other runs in userspace and preloads libs etc
<ogra_> even if the first part terminates, the second will still gain you improvements
<sveinse> I also have two accounts of "init: ureadahead-other main process (829) terminated with status 4"
<sveinse> I have no problems leaving it as-is, just OOI
<ogra_> hmm, might be that your kernel is missing options
<sveinse> That is what crossed my mind as well. Where can I find these options?
<ogra_> no idea :)
<ogra_> i would compare your config with an equivalent one of an ubuntu kernel
<sveinse> Well I did that some time ago, and there's a ton of differences. Ubuntu kernel = generic. Our kernel = specific. But I'll start looking.
<sveinse> ogra_ if you care at all: Adding /etc/fsck.conf fixed the problem with using the broken_system_clock option. This will ensure e2fsck never fails due to missing or clock in the past.
<ogra_> yeah, i know
<ogra_> it was added upstream a cycle after fixrtc was added
<ogra_> we had some discussions with ted about it
<HokieTux> Hey all - Does Ubuntu-ARM support the NEON instruction set?  The top comment in this bug (https://bugs.launchpad.net/ubuntu/+bug/848154) seems to indicate that NEON is disabled in Ubuntu builds for non-v7 support?
<ubot2`> Launchpad bug 848154 in ubuntu "ARM version not supporting V6 RaspPi" [Undecided,Invalid]
<GrueMaster> HokieTux: Neon support and V6 Raspberry Pi support are two separate issues.  By default, the main packages do not use neon, as there are several v7 SOC's that do not use neon (nVidia Tegra series, Marvell Armada series, etc).
<HokieTux> GrueMaster, yeah, I know they are separate issues - that is just one of the threads that came up when I was searching for details, and the top comment seemed relevant to non-Pi platforms.
<infinity> HokieTux: We "support" NEON, we don't build with it enabled by default, except in packages where run-time selection can be done.
<GrueMaster> Raspberry Pi uses armv6 which means no thumb2 support.  All of our packages are currently compiled for thumb2 since Lucid.
<HokieTux> infinity, GrueMaster - I'm specifically working on OMAP3 platforms, on the moment, and using Angstrom.
<HokieTux> I am investigating using Ubuntu, and that comment just made me suspicious.  So it is possible to build Ubuntu-ARM with NEON support, then?
<GrueMaster> We fully support omap3 (see our omap3 images - they work on beagle systems).
<infinity> HokieTux: You could rebuild the whole archive with neon enabled by default, it would buy you very little.
<infinity> HokieTux: The packages that have hand-tuned NEON routines tend to have those enabled at runtime already.
<infinity> HokieTux: libjpeg-turbo being a good example.
<infinity> HokieTux: "turning on NEON optimisation" does very little without special consideration in the code, from what I've seen, so I wouldn't worry too much about it. :P
<HokieTux> infinity, aha - so the packages that have them auto-detect support at runtime?
<HokieTux> That more or less answers my question.
<infinity> HokieTux: Certainly not every single package that could have NEON support does run-time autodetection, but a good many do.
<HokieTux> Ah - so it isn't disabled in the kernel, then; it's just that not all packages are necessarily built with it?
<infinity> HokieTux: Anyhow, I'd recommend trying out the precise armhf/omap images and just seeing how it all works for you.
<infinity> HokieTux: The kernel couldn't care less.  And the compiler and assembler are more than capable of doing NEONy things.  As you surmise, we just don't build with it on by default (except where it can be done at runtime).
<infinity> Because, as GrueMaster says, we support v7 SoCs that don't have NEON.
<infinity> So, the world would explode for them. :P
<HokieTux> Great =)
<infinity> One could argue that ARM oopsed a bit by not requiring NEON in the ARMv7 spec, but a bit late now. ;)
<HokieTux> infinity, I almost certainly will try it, then.  If that comment about NEON being disabled at the kernel level in all Ubuntu-ARM builds were true, it wouldn't be worth my time at all since NEON is 100% required for my application.
<HokieTux> That's why I was asking-before-trying
<HokieTux> Thanks for clearing up my confusion, though =)
<infinity> HokieTux: Did Oli mention kernels in that comment?  If so, he was typing faster than he was thinking.
<infinity> HokieTux: Anyhow, in your specific case, yeah, life's good.  The toolchain will happily compile your NEON-needing application, and the userspace and kernel will happily run it.
<HokieTux> Hah, no, he didn't specifically mention kernels - he said "... NEON which we forbid to be build-time enabled by default due to teh fact that we support non NEON armv7 devices"
<infinity> Yeah, that's fairly accurate.
<infinity> If a bit awkwardly-worded. ;)
<HokieTux> Yeah, it sounds scary to people that require it, hah.
<infinity> Well, "forbid" probably needed a caveat of "for distro packages".
<infinity> The toolchain will let you do whatever you want to your own stuff. ;)
<HokieTux> Aha
<HokieTux> infinity, so the short version is that distro-wide packages are built WITHOUT NEON support for compatibility, and  most libraries that have hand-tuned NEON assembler will auto-detect compatibility at run-time?
<infinity> Roughly that, yes.
<HokieTux> and if we wanted to add hand-tuned NEON to distro packages, we would need to use the toolchain to build our own packages
<infinity> Or, rather, things that can auto-detect, we let them.  Things that are compile-time "on or off", it's off.
<infinity> So, if you want to add hand-tuned NEON to distro packages, make it a run-time detection, not a compile-time option.
<infinity> And everyone wins.
<HokieTux> infinity, great
<HokieTux> I really appreciate your time and help =)
<ogra_> grmbl
<ogra_> so no initrdless boot for now :(
 * ogra_ wonders if CONFIG_UNIX98_PTYS is set to M in the panda config 
<ogra_> else i dont get why i see bug 954243
<ubot2`> Launchpad bug 954243 in linux-ti-omap4 "booting pandaboard without initrd dies with "init: no available ptys"" [Undecided,New] https://launchpad.net/bugs/954243
<sveinse> Is double usage of console= in kernel commandline mutually exclusive with plymouth? My splash went away when I started using console=...
<ogra_> plymouth shuts down the splash if it detects a serial console option
<ogra_> silly upstream decision, was discussed at lenght a while ago
<sveinse> Hmm ok. Doesn't work too well when the [serial] console != display unit
<ogra_> it omits the splash as soon as you set "console=" iirc
<sveinse> omit = not starting plymouth
<ogra_> well, at least not showing a splash, i'm not sure how the plymouth daemon acts
<ogra_> crap ... so i guess we need to drop the idea of initrdless boot ...
<ogra_> doesnt look like the kernel can mount devpts automatically
<ogra_> and without it upstart will fall flat on its face
<sveinse> in which you need to do mountall / fstab...
<GrueMaster> ogra_: Was this even tested on x86?  Seems to me it would fail there as well.
<ogra_> yes, it would, it used to work in oneiric
 * ogra_ tries with fstab entry but i doubt that saves me 
<ogra_> since upstart will likely fail before
<ogra_> nope, fails the same way as expected
<infinity> ogra_: perhaps upstart changed to require UNIX98 ptys, and it used to fallback to /dev/tty* or something?
<ogra_> something like that i guess
<ogra_> the kernel config (which i suspected first) is definitely fine
 * ogra_ gives up for the day
<GrueMaster> I'd double check the kernel config.  We were bitten by these changes when cooloney copied the omap4 kernel config for the armadaxp kernel.  He reverted some of these omap4 specific changes lst night and it runs fine now.
<ogra_> GrueMaster, i did before haking up fstab
<sveinse> oh joy! AFAICS the splash-off feature in plymouth when using serial console is hardcoded into plymouth
<dpcrespo> hi
<dpcrespo> i try booting ubuntu 11.10 on igepv2
<dpcrespo> and not working
<dpcrespo> i read this https://wiki.ubuntu.com/ARM/OmapNetbook
<dpcrespo> but the last message i have is "Uncompressing Linux... done, booting the kernel."
<GrueMaster> What image are you trying?
<dpcrespo> http://cdimage.ubuntu.com/releases/11.10/release/
<dpcrespo> this
<GrueMaster> Desktop or server?
<dpcrespo> Desktop
<GrueMaster> Do you have a keyboard, mouse, and monitor hooked up to your system?
<dpcrespo> keyboard and mouse
<dpcrespo> no
<dpcrespo> i have only monitor
<GrueMaster> And nothing shows up on the monitor?
<dpcrespo> no
<dpcrespo> when it is booting
<dpcrespo> the monitor change to orange color
<dpcrespo> and after without signal
<GrueMaster> Try the server image to see if it gets further.  Unfortunately, that platform is untested by us, so may not work with our image.
<GrueMaster> I assume the message you are getting is via serial console.
<dpcrespo> yes with minicom
<dpcrespo> you know stable version
<dpcrespo> with igepv2
<GrueMaster> We do not actively test on that platform.  I'm told it should work, but I have no way of knowing.  I recommend trying the server image, because it is designed to do all of the installation steps through the serial console.
<dpcrespo> ok
<dpcrespo> i try this
<dpcrespo> thx for your help
<dpcrespo> when i test
<dpcrespo> i tell you
<dpcrespo> thx
<jbicha> hi, I need some help figuring out how to get cogl to build on arm
#ubuntu-arm 2012-03-14
<infinity> jbicha: I assume you mean other than the copy in the archive that's already built on arm?
<jbicha> infinity: no, the one in the archive that just failed to build
<infinity> jbicha: Oh, just uploaded.  Check.
<infinity> Looks like possible GL versus GLES issues.
<infinity> Did this have an FFe? :/
<jbicha> yes, bug 941617 but I didn't think to ask if someone could test it on ARM first
<ubot2`> Launchpad bug 941617 in clutter-1.0 "FFe: Update clutter/cogl to 1.9" [Wishlist,Confirmed] https://launchpad.net/bugs/941617
<infinity> jbicha: I'm not wildly well-versed on the GL versus GLES issues, but before anyone goes digging too deeply, does ./configure perhaps have any switches that jump out as being "use GLES instead of GL"?
<infinity> Oh, which it is doing.
<jbicha> http://git.gnome.org/browse/cogl/tree/configure.ac
<infinity> I can perhaps help you look in a day or two, when I don't have a mess of deadlines.
<infinity> If you need help sooner, I recommend janimo`. ;)
<infinity> Or, you can log in to scheat, and debug yourself.
<jbicha> scheat? I doubt I have access?
<infinity> You don't have access to the canonical porter boxes?
<jbicha> infinity: I'm not a canonical employee nor has an exception been made for me
<infinity> jbicha: Oh, hahaha.  The logo for the not-canonical LP group throws me every time.
<infinity> jbicha: That needs to be less subtle. :P
<infinity> jbicha: But yeah, I'd either ask janimo` or, if you don't like Jani for some reason and can wait a few days, ask me. :)
<infinity> jbicha: A bit too headless chickeny right now to look into it deeply.
<jbicha> infinity: so how should I fix the archive? do a ~really until we figure it out?
<infinity> jbicha: Or just let it be broken for a bit.
<infinity> jbicha: The cogl stack isn't in any seeds other than supported.
<infinity> jbicha: So, it's not breaking CDs or anything.
<infinity> jbicha: Heck, jani might wake up in the morning and fix it for you. :P
<infinity> janimo`: If you have time to waste when you wake up, can you look at cogl's FTBFS for jbicha and see if anything jumps out at you?
<infinity> janimo`: (If not, I'll help him on Thursday, I just have some annoying deadlines tomorrow)
<GrueMaster> like md5sums????
 * GrueMaster ducks.
<infinity> GrueMaster: Yes, and that.
<GrueMaster> :P
<infinity> GrueMaster: I might just "fix" md5sums for now by removing the clever caching/reusing logic until I can make it do what we mean, not what we asked.
<infinity> Makes publishing a bit slower, but I really doubt that matters terribly when compared to build time.
<GrueMaster> I'm in no particular hurry.  Just adds a level of assurance when an image goes boink during testing.
<infinity> Yeah, it's good to have.
<infinity> But it's not been the top of my queue either.  It's up there, though.
<GrueMaster> As long as Beta 2 is good, I'll only poke occasionally.  :P
<pbuckley> beta 1 has been really solid for me.. for what its worth
<pbuckley> a few years ago you could have even called it a release candidate ;)
<infinity> Blame the +1 maintenance team for some of that.
<infinity> Though from the ARM perspective, we've put a lot of work into precise.
<pbuckley> its noticable
<infinity> (It didn't seem like it, really, but we "accidentally" did a lot of ARM fixing and tweaking while doing the armhf bringup)
<pbuckley> i went to 12.04 just to test it out from 11.10.. never went back
<infinity> I suppose incidentally is a better term. :P
<pbuckley> heh
<pbuckley> makes it sound more intentional ;)
<infinity> Well, it was.
<infinity> Opportunistically, even.
<pbuckley> that those are big words
<GrueMaster> Speaking of...how is your audio?
<pbuckley> great.. i had to tweak some things in alsamixer to get the right "sound"
<pbuckley> but it sounds better then any of my other "mobile" devices
<pbuckley> well
<pbuckley> there is one bug
<pbuckley> but its not that annoying
<pbuckley> and its probably a pianobar bug
<GrueMaster> Ah.
<GrueMaster> I use pithos myself.
<pbuckley> basically when you start a new song.. it stutters for half a second
<pbuckley> pithos?
 * pbuckley goes and looks
<GrueMaster> It is a gui Panda client.
<GrueMaster> Er Pandora.
<pbuckley> nice
<pbuckley> http://kevinmehall.net/p/pithos/
<pbuckley> wow
<pbuckley> that has a few dependencies
<GrueMaster> Are you running desktop or headless?  It is designed for desktop.
<pbuckley> desktop on this guy
<pbuckley> unity ftw
<pbuckley> its impressive how well unity runs
<infinity> Well, it depends on all the gstreamer plugins.
<infinity> Which is just plain wrong.
<infinity> But whatever.
<pbuckley> i was expecting it to fall on its face before i started on this
<infinity> Most people want them all anyway.
<GrueMaster> Yes, I can see the difference also.
<twb> Uh, I guess "pandora client" doesn't meant the hand-held arm game console?
<twb> Oh that's right it's some US-only music site
<pbuckley> its that music streaming service
<GrueMaster> Yea.  US only.  Sad.
<pbuckley> i wonder if pandora is vulnerable to the x-forward thing
<pbuckley> since its all web requests
<pbuckley> might be a way to get around the us only thing
<GrueMaster> Very ugly when I have to ssh tunnel to my home to play music.
<GrueMaster> It works fine when going through a sudo-vpn.
<pbuckley> (i know i "forget" to sanitize x-forward headers at my site)
<infinity> pbuckley: No, Forwarded-for headers don't work for Pandora.
<pbuckley> damn
<infinity> Just one of the many reasons I have a GRE tunnel to my machine in San Jose.
<pbuckley> hrmm
<pbuckley> so do i want aacplus or mp3-hifi?
<pbuckley> i tried mp3-hifi on pianobar
<pbuckley> and that caused a segfault
<twb> I'd rather just use music systems that don't oblige me to jump through hoops in the first place
<pbuckley> like?
<twb> Well, my ISP has unmetered restreams from a bunch of internet radio stations and local community radio stations
<twb> Also magnatune
<pbuckley> are winamp stations still around?
<pbuckley> btw
<twb> http://cyber.com.au/~twb/.bin/radio
<twb> http://cyber.com.au/~twb/.bin/magnatune
<pbuckley> apt-get install pithos
<GrueMaster> What was the linux clone of winamp?  Is that still supported?
<pbuckley> resulted in Error: Your GStreamer installation is missing a plugin
<pbuckley> xmss?
<pbuckley> or xmms?
<pbuckley> or osmething
<GrueMaster> Yea, that was it.
<StevenK> xmms has been dead upstream for years
<GrueMaster> I used that when I was still on Mandriva (before Ubuntu existed).
<twb> GrueMaster: xmms
<StevenK> And xmms2's development pace could be described at best as 'glacial'
<twb> xmms was unmaintained and forked a couple of times
<pbuckley> any idea what gstreamer plugin pithos is complaining about?
<twb> xmms2 is a completely different project from the same people; it's client-server (like mpd) but with lots of plugins and a powerful wire protocol.
<pbuckley> ERROR:root:Gstreamer error: Your GStreamer installation is missing a plug-in., gstdecodebin2.c(3576): gst_decode_bin_expose (): /GstPlayBin2:player/GstURIDecodeBin:uridecodebin7/GstDecodeBin2:decodebin27:
<pbuckley> no suitable plugins found
<GrueMaster> pbuckley: Make sure you have restricted & multiverse enabled.
<twb> StevenK: I hadn't noticed; I used mplayer until ffmpeg broken on arm and since then I've been using mpg123
<infinity> pbuckley: By "WinAMP stations", you mean people using Shoutcast to stream mp3 audio?
<pbuckley> yeh
<pbuckley> sorry im showing my age
<infinity> pbuckley: If so, it's still quite widely used, and supported by more or less every media player in the world.
<pbuckley> deb http://ports.ubuntu.com/ubuntu-ports/ precise main restricted universe multiverse
<pbuckley> that should grab it right?
<GrueMaster> yes.  Should.
<pbuckley> :(
<robclark> rsalveti (or anyone), do I need a newer qemu to do chroot w/ 12.04 armhf filesystem?
<robclark> (from 11.10 host)
<StevenK> twb: Ah. mpg{321,123} won't work for me, I just finished re-doing my music collection in FLAC.
<twb> I don't bother to collect music anymore
<twb> Prety much stopped when I got my 701, because it only had 4G of disk
<StevenK> I have a 3TiB fileserver for that
<rsalveti> robclark: not sure, only used the one at precise
<pbuckley> http://pastebin.com/diMGNbDp
<robclark> ahh.. please don't tell me I have to update my laptop yet?
<pbuckley> if someone wants to show me some pithos love
<pbuckley> thats basically what i did
<infinity> robclark: oneiric's qemu is fine.
<infinity> robclark: Heck, lucid's is fine.
<robclark> hmm, am I doing something stoopid?
<robclark> oh, wait, probably..
<infinity> robclark: Are you talking full system emulation, or binfmt_misc?
<infinity> robclark: If it's the latter, did you copy /usr/bin/qemu-arm-static into your chroot?
<robclark> I guess you would call it full system emulation.. but I think I forgot to copy qemu-static (new rootfs since last time I did it)
<infinity> If it's copying qemu-static into chroots, I wouldn't call it full system, no. :)
<infinity> By 'full system emulation', I mean booting a VM in qemu.
<robclark> ahh, gotcha..
<robclark> but yeah, it was lack of copy of qemu-static.. it was operator error :-P
<infinity> But yeah, the copying of /usr/bin/qemu-arm-static into the chroot trick should work fine going at least back to hardy.
<infinity> So, you're fine on oneiric. :P
<infinity> Oh, maybe I lied.  On hardy and lucid, we're using backported qemu.
<infinity> Whatever.  natty, oneiric, and precise are all good. :P
<twb> StevenK: getting a NAS would double the amount of hardware I have to babysit
<robclark> yup
<twb> I'm a sysadmin, the last thing I want to deal with when I go home is ornery hardware :P
<pbuckley> have you see the xyfi?
<StevenK> twb: Haha
<pbuckley> seen
<pbuckley> http://www.engadget.com/2012/02/29/option-xyfi-is-worlds-smallest-personal-hotspot-we-go-hand/
<pbuckley> its a wifi/cellular/nas in your pocket
<GrueMaster> pbuckley: I just installed pithos on my panda.  No issues here.  You may need to "apt-get update".
<pbuckley> did :(
<pbuckley> grumble
<GrueMaster> Oop.  nevermind.  Tried running with mp3-hifi - fail.
<pbuckley> yeh
<pbuckley> should i use aacplus?
<GrueMaster> Works with aacplus
<pbuckley> k.. thats what i was using in pianobar
<pbuckley> so no big deal
<GrueMaster> I'll note it down and look into it tomorrow.  May be it needs the TI sekrit sauce
<pbuckley> mmm sekrit sauce
<GrueMaster> Maybe this is it.  apt-get install ubuntu-restricted-extras.  Let you know in a sec.
<GrueMaster> (although gstreamer0.10-plugins-ugly will probably give you the same results with less packages).
<pbuckley> have i mentioned your awesome GrueMaster thats the plugin its missing
<pbuckley> however it has a similar result as pianobar
<pbuckley> Segmentation fault (core dumped)
<pbuckley> also
<pbuckley> i can't submit a report
<pbuckley> it gave me an error "Invalid problem report"
<pbuckley> "the report belongs to a package that is not installed"
<pbuckley> just reproduced it
<GrueMaster> Hmmm.  I now have working mp3 & mp3-hifi.
<pbuckley> no segfault?
<pbuckley> i think tonight is flash fresh images to pandaboard night
<pbuckley> its been what? two months of apt-get dist-upgrades
<pbuckley> im sure something is hosed
<GrueMaster> Meh, only a couple of weeks since beta 1.
<GrueMaster> But to be fair, I am running with the latest daily image.
<pbuckley> how rational of idea is it to do a dpkg -l | awk '{print $2}' to get a list of packages.. then after i reinstall do a for pkg in list do apt-get install $pkg done
<pbuckley> ?
<pbuckley> would be neat if ubuntu one had a "restore" like feature
<pbuckley> that reinstalled all the previous packages i had
<StevenK> dpkg --get-selections / dpkg --set-selections
<twb> That'll lose markauto statuses tho
<twb> etckeeper is also very useful
<pbuckley> then just dpkg --set-selections < file
<pbuckley> ?
<pbuckley> markauto?
<pbuckley> no matter how deep i find myself in the dpkg rabbit hole.. it always seems to go deeper
 * pbuckley reminicses about the old days of dselect
<pbuckley> wow
<pbuckley> dselect is still around!
<pbuckley> and integrated with apt now
<pbuckley> man i first started using debian like 17 years ago
<pbuckley> :(
 * pbuckley feels old all of a sudden
<Person987> I am trying to install Mercurial on my pandaboard, I've installed mercurial-common but when I "apt-get install mercurial" I get an error, "Depends: mercurial-common (=1.9.1-1ubuntu0.1) but it is not going to be installed)  E: Unable to correct problems, you have held broken packages.
<infinity> Person987: And what version of mercurial-common do you have installed, and where did you get it? :P
<infinity> Person987: dpkg -l mercurial-common
<Person987> It says version 2.2.1+12-ce292f13
<Person987> I added the mercurial ppa in order to get it (I think)
<infinity> Uhm.
<infinity> Right, then you'd need to install mercurial from that PPA too.
<infinity> The version of mercurial you're installing is from oneiric-updates.
<Person987> how do you control which ppa it comes from?
<infinity> By not removing the PPA. :P
<StevenK> infinity: Which is probably not built for ARM?
<infinity> StevenK: Oh, hah.  Probably.
<Person987> eek
<StevenK> Most PPAs do not support ARM, sadly.
<infinity> Person987: The other option would be to "dpkg -P mercurial-common", remove the PPA, apt-get update && apt-get install mercurial.
<infinity> You don't really need the shiny PPA version, do you?
<Person987> about a month ago I set up a pandaboard and to get mercurial I just went through the "Ubuntu Software Center" and it was in there.  This time I'm having trouble finding it.
<Person987> No, I don't need the "shiny" one, trying your suggestion above...
<infinity> Person987: I'm sure it's in SC somewhere.  But apt-get install mercurial has the same effect.
<Person987> I'll remove the ppa's and remove the bits I have and start over then.  I did start by trying to just use "apt-get install mercurial"
<infinity> Person987: You may not have had universe enabled when you did that.
<infinity> Person987: Though you clearly do now.
<Person987> if I use apt-get remove mercurial (and mercurial-common) and remove the PPAs from my sources is that sufficient to get myself "reset"
<infinity> s/remove/purge/
<infinity> And I don't know.  If all you installed from the PPA was mercurial-common, then yes.
<infinity> (And remember to "apt-get update" after you remove the PPA from sources)
<micahg> Person987: there's a ppa-purge package to do something like that
<Person987> ok after running apt-get update, I got a complaint about duplicate entries, ran it again and its clean, is that a problem?
<infinity> "Duplicate entries"?
<infinity> Paraphrasing error messages doesn't help. ;)
<Person987> ah, I need IRC on my pandaboard so I can copy paste...
<Person987> Duplicate sources.list entry http://ppa.launchpad.net/tiomap-dev/release/ubuntu/ oneiric/main armel Packages (/var/lib/apt/lists/ppa.launchpad.net_tiomap-dev_release_ubuntu_dists_oneiric_main_binary-armel_Packages) W: you may want to run apt-get update to correct these problems
<infinity> Oh, I imagine that's exactly as it sounds.
<infinity> Not really an error, just informative.
<Person987> ok, thats what I thought but I figured I'd mention it since I've been having problems.  Ok I'm going to try to install mercurial now.
<Person987> it automatically got mercurial-common this time...
<Person987> promising :-)
<Person987> worked!  Thanks so much for walking me through this.  So do you think I didn't have the "universe" enabled in the beginning?  How do you enable that?
<infinity> Either by editing sources.list, or by using one of the higher level tools to enable it.
<infinity> Software Properties or some such.  I'm not sitting in front of a standard desktop setup right now.
<gildean> software sources or package sources or something like that
<Person987> Hmm, I definitely did something because I'm finding more stuff in software center now :-)
<Person987> Software Center -> edit menu -> Software Sources.  Dialog box has some checkboxes for "main", "universe", "restricted", and "multiverse"
<Person987> (in case anyone is as noob as me!)
<NsN> Hi, on the 11.10 prebuilt server image, the network card of my gumstix board is not recognized. Can I copy the modules from a known working distribution with a 3.0.x kernel or is this more complicated?
<ogra_> NsN, i doubt they would load (different symbols), you would have to rebuild a kernel package with gumstix config options set or see if there is a linaro kernel (ask in #linaro) that supports it (they are usually packaged and available in the ubuntu archive)
<GrueMaster> ogra_: Can you think of any reason why the omap server image would break inside initrd and the desktop would be ok?
<ogra_> not from the top of my head, no
<ogra_> omap4 server works fine here (just using it atm)
<GrueMaster> Yea, it appears to only be omap server that is having issues.
<GrueMaster> What I am seeing on the serial console is this:
<GrueMaster> Uncompressing Linux... done, booting the kernel.
<GrueMaster> hwclock: select(
<GrueMaster> Then reboot
<GrueMaster> (after a long pause).
<GrueMaster> Nothing from jasper, no oem-config-debconf, nothing.
<GrueMaster> sigh, guess I will have to do a binary search on this between Beta 1 and current.  Find the start of the failure, figure out what package changed.
<ogra_> smells like kernel
<GrueMaster> As I said, desktop works fine.
<GrueMaster> But I suppose if the serial console got hosed that may be it.
<ogra_> really weird, up to jasper they should be identical
<ogra_> did you check the build date, probably one of them is older and was acrried over from a former daily build
<ogra_> (happens if the build fails, though i didnt see any failure mail today)
<GrueMaster> time stamps appear accurate on my mirror.  Sizes change consistently.
<GrueMaster> Of only we had accurate md5sums...
<ogra_> infinity is working on that iirc
<GrueMaster> yes.  I just like poking him.  Keeps him motivated.  :P
<ogra_> yeah, he is way to distracted by the running foundations tream meeting ...
<GrueMaster> So far, it seems to start shortly after Beta1.  0307 failed, flashing 0305 now.
<GrueMaster> I don't know everyone's meeting schedules.
<ogra_> oh, i didnt know you use such old images
<GrueMaster> (hell, I don't even know my own).
<GrueMaster> I have copies of every image back to Alpha 2 (had to clear some space).
<GrueMaster> I only keep the arm images for historical purposes.  I mirror current only for x86/amd64 for spot comparisons.
<jbicha> hi, so cogl was fixed but clutter's now not building on arm
<jbicha> https://launchpadlibrarian.net/96782687/buildlog_ubuntu-precise-armel.clutter-1.0_1.9.14-0ubuntu1_FAILEDTOBUILD.txt.gz
<ogra_> looks like its building some X11/GLX stuff it didnt build before ?
<jbicha> yeah, I don't know much about arm or clutter, nor was I able to get a precise arm chroot working yesterday
<ogra_> sudo apt-get install qemu-user-static;; sudo qemu-debootstrap --arch armhf .....
<infinity> jbicha: Download ubuntu-core-armhf, untar, cp /usr/bin/qemu-.... Or, do what ogra said. :P
<jbicha> I was getting some memory errors yesterday...
<jbicha> I used mk-sbuild --arch=armhf precise but got "%n in writable segment detected" errors
 * ogra_ never used mk-sbuild ...
<jbicha> I might have hit bug 947888
<ubot2`> Launchpad bug 947888 in qemu-linaro "Unable to generate linaro images using qemu-linaro" [Undecided,Fix committed] https://launchpad.net/bugs/947888
<ogra_> no idea, my qemu-deboostrap chroot works fine here
<steev_> trying to apt-get update, and i'm getting BADSIGs
<infinity> steev_: Proxy hates you, mirror broken.
<infinity> steev_: Those are the two standard answers.
<GrueMaster> steev_: Local mirror or ports.u.c?
<steev_> GrueMaster: ports.u
<MrCurious> is there a command that will tell me what package a program is from?  i have a system that is lacking "ps" for some reason
<GrueMaster> Not much I can suggest there other than wait for 20 minutes and try again.
<GrueMaster> MrCurious: Our images usually have "command-not-found" installed, which is a shell extension that will tell you which package to install if you type a command that isn't in the system.
<GrueMaster> (assuming the command typed is an actual app in the pool).
<steev_> yeah i'll wait til i get home, i *really* hate the internets (or lack thereof) at the office
<MrCurious> awesome! installing it now :D
<MrCurious> thanks grue
<GrueMaster> steev_: I have a local mirror that updates every 2 hours.  90% of the time it just flies.  10% it will hiccup, but resolve itsself within 2 hours.
<steev_> GrueMaster: good to know, i tend to update somewhat often while in beta like it is (and not update when it wants to remove ubuntu-desktop)
<GrueMaster> Currently, the mirror is using 261G for all of ports.u.c armel/armhf binaries.  I don't mirror sources.
<steev_> oh that's not bad
<GrueMaster> For updates, I recommend running "apt-get dist-upgrade" and canceling if it lists any packages to be removed.
<steev_> once i figure out the lesser of the two evils (AT&T vs. Time Warner), and get my home internet connection set up, I'll probably mirror as well
<GrueMaster> That usually signals pool churn.
<steev_> GrueMaster: that's what i meant
<steev_> if dist-upgrade wants to remove something i hold off til next time i'm passing through the kitchen (which is where my efika smartbook currently resides)
<GrueMaster> The BADSIG's is a different issue, and usually just means you happened to time it at the same time as the repo is updating.
<GrueMaster> If dist-upgrade threatens to remove stuff, just run apt-get upgrade.  That will keep most stuff current.
<GrueMaster> dist upgrade gets the tip of everything, as long as all dependencies can be met (pool churn).
<steev_> i think it might have screwed up because of the internet connection.  it connected to an open access point (my fault), and it's one of those captive portals, and i ran apt-get update while on it, thinking i was on a different network
<GrueMaster> heh.  oops.
<ogra_> badsig is typical for a so called "transparent" proxy
<pbuckley> GrueMaster: btw that audio studio problem was a pianobar issue.. pithos works great
<pbuckley> /studio/stutter
<GrueMaster> Cool.  Glad to hear it.
<wart___> hi folks. i'm looking for a little more information on ubuntu on the transformer prime.
<wart___> i think lilstevie is here or lurks here.
<wart___> i'm trying to get gentoo on it, but my problem is at a very general level: getting the kernel to compile.
<wart___> here's my bug report: https://github.com/AndroidRoot/android_kernel_asus_tf201/issues/1
<wart___> i'd be curious to see what you did to get a kernel working.  once i have that, i should be good to dd an img and reboot :-)
<wart___> my chroot is fine, and the TFT is amazing for compiling things.
<wart___> lilstevie: ^^
<steev_> ogra_: on 3 different networks?
<steev_> because i'm still getting BADSIG here :/
 * GrueMaster checks 
<GrueMaster> steev_: I don't see that issue here with precise armhf, local mirror or ports.u.c.
<GrueMaster> checking armel now.
<GrueMaster> No problems with either armel or armhf precise here.
<steev_> GrueMaster: yeah, i'm trying the old windows fix currently
<steev_> ><
<steev_> stupid power management
<steev_> 3% means i still have 2 more hours of battery life, stop suspending]
<GrueMaster> heh
<GrueMaster> I assume this is on an arm netbook of some sort?
<steev_> yeah the efika smartbook
<steev_> gah, wtf, every time i unsuspend it warns me again that the battery is critically low and re-suspends
<steev_> p.s. the cancel button is worthless
<flowd> hi, can so here help me with installing ubuntu 11.10 on pandaboard?
<flowd> the system configuration at the beginning always crashes at "copiing installation log"..
<xranby_ac100> flowd: most likely something went wrong when you prepared the sdcard
<GrueMaster> flowd: When that happens after the first pass through oem-config, use <ctrl><alt><F1> to open a console, login with the account you created, and type "sudo oem-config-remove && sudo reboot".
<GrueMaster> Known race condition in Oneiric.
<xranby_ac100> flowd: .. what GrueMaster said :)
<xranby_ac100> GrueMaster: hi, did you have a chance to look at the rare kernel deadlock stall?
<xranby_ac100> GrueMaster: i am planning to try setup a kernel with lockdep kernel lock verifier compiled in in oder to trace and recode the call sequence better that causes the stall
<xranby_ac100> i am able to reproduce the bug using both ubuntu 11.10 and linaro 12.02 kernels
<flowd> @GrueMaster thx, that works :) installed it several times with new downloaded image and other versions, now it finally boots normal :)
#ubuntu-arm 2012-03-15
<steev_> welp, tried at&t, clear, time warner and one other, all of them give me BADSIG
<marvin24> janimo`: would it be possible to supply a wifi backport package (compiled from compat-wireless) for #ac100 for precise?
<janimo`> marvin24, anything you put in your 3.0 stable tree can be put in precise (assuming what you put there is tested :D )
<janimo`> marvin24, or you mean a userland package?
<marvin24> janimo`: no, I mean a package with kernel modules compiled from compat-wireless against the 3.0 kernel
<marvin24> I think ubunutu has some backports-wireless-<kenrel>.deb package
<marvin24> it just needs to be re-compiled against our kernel
<janimo`> marvin24, I'll need to investigate then, I did not know about this package. Mind filing a bug on the linux-ac100 package in launchpad with URLs and any other info that puts me on track? thanks
<janimo`> btw what gets fixed by this upload?
<marvin24> janimo`: ok
<janimo`> marvin24, and assign it to me so I find it easier :)
<marvin24> janimo`: looking at it now, there only exists a package containing the drivers from the lastest ubuntu released kernel
<marvin24> so there is no precise package yet
<marvin24> still searching ...
<marvin24> e.g. https://launchpad.net/oneiric-backports
<marvin24> janimo`: maybe you can try to enable the build of https://launchpad.net/ubuntu/oneiric/+source/linux-backports-modules-3.0.0 for arm
<marvin24> which would be some starting point at least
<janimo`> marvin24, but that is for oneiric, you mean something similar for precise?
<marvin24> yes
<marvin24> there is no precise package yet
<marvin24> as I said, it will only be released if there is a new version > precise released
<marvin24> mmh
<janimo`> ok. I wonmder it's because most kernels are on 3.2 and don't care?
<marvin24> well, we are still on 3.0 ...
<marvin24> and there will be likeley no 3.2 kernel in the next future :-(
<marvin24> *near future, but next is also right
<marvin24> idealy, the package should include latest compat-wireless-trunk (instead of the 3.2 status)
<marvin24> then we could also release a package for precise
<janimo`> marvin24, does thi sonly affect ac100? I wonder why other kernel maintainers are not dealing with it
<marvin24> you mean other arm kernels, or other compat-wireless versions?
<marvin24> maybe other arm boards use a different (more stable) wifi chip
<marvin24> using compat-wireless from trunk isn't very useful for a released distro on the other hand
<marvin24> maybe some personal ppa would be more appropriete
<janimo`> marvin24, in either case if you file a bug please specify what needs to be packaged and from where and which problems it fixes. Or just file the bug and add that such a backport fixes it.
<marvin24> janimo`: already on the way ;-)
<rsalveti> GrueMaster: hm, I'm having quite a few issues with today's image on panda
<rsalveti> at least my panda es is constantly freezing
<GrueMaster> Today's?  I'll check.
<GrueMaster> Actually, I have been seeing that as well.  I'm trying to capture log output,but not successful yet.
<rsalveti> and I just noticed that with my 4430 X11 didn't started correctly
<rsalveti> I'm getting the needed patches to get sgx to work on it
<rsalveti> ok, will try to reproduce and isolate the issues
<ogra_> ppisati, ^^^ for the new sgx drivers we will need kernel adjustments
<rsalveti> yup, I'm just checking that
<ogra_> right, just wanted to warn him about the work coming down the drain :)
<ppisati> ack
<nox-Hand> Evening, humans!
#ubuntu-arm 2012-03-16
<ndec> ogra_: hi. do you mind if i cancel the call today?
<ndec> if you think there is anything we need to discuss, let me know
<ogra_> ndec, feel free, i dont have anything special
<brax> is there anybody that has 5 minutes to help me with a xrandr issue?
<prpplague> ogra_: yea, package updates have fixed my desktop issues!
<ogra_> awesome !
<prpplague> ogra_: actually have to reload my box at home, i fudged up and hosed the permissions for /usr
<ogra_> ouch !
<danboid> Looks like I need to recompile my panda kernel just to get ALSA sequencer support so what kernel version would you guys recommend and why?
<ogra_> the one your release has already
<GrueMaster> danboid: What issues are you seeing?  Precise Beta 1 works for both Panda/Panda ES ootb.
<ogra_> danboid, https://help.ubuntu.com/community/Kernel/Compile
<ogra_> just use the source package
<danboid> GrueMaster, None of the current Linaro or Canonical omap4 kernels have ALSA sequencer support compiled in or as a module
<GrueMaster> (which I just discovered is broken in the daily images...again.)
<ogra_> right, who needs MIDI anyway :P
<ogra_> as long as your mp3's play
<ogra_> danboid, thats seriously worth filing a bug though
<danboid> As I've said before, Panda could be quite attractive to Linux musicians due to its silent aspect (if you use a SSD )
<ogra_> yeah, agreed, i was rather sarcastic above, not serious
<danboid> I'm hoping to use if for music production anyway
<ogra_> so a) file a bug, b) follow the wiki t recompile the kernel package with a config change
<danboid> ogra_, jk- said this has been fixed already
<ogra_> in the ubuntu package ?
<ogra_> ppisati, ^^^ did you enable alsa sequencer support in the config ?
<danboid> ogra_, I presume so but he's not been around today to give more info
 * ogra_ doesnt think so
<danboid> If I want the pvr driver working am I best recompiling the standard kernel rather than going for the latest stable code?
<ppisati> i'm here
<danboid> ppisati, I was told the latest omap4 kernel configs have ALSA sequencer support enabled now?
<danboid> ppisati, If so, can I get a package anywhere of such  a kernel yet?
<GrueMaster> danboid: I see CONFIG_SND_SEQ_DUMMY=m in the current precise kernel.
<GrueMaster> And CONFIG_SND_SEQUENCER=M as well.
<ppisati> sorry, was in a phone call
<danboid> GrueMaster, That'd do me but I expect I can't install a precise kernel under oneiric can I?
<GrueMaster> So you should be able to get the kernel either from a daily image or from http://ports.ubuntu.com.  ppisati can point you to the git tree if you really want to go deep.
<ppisati> danboid: yes you can
<GrueMaster> Why not?
<danboid> Hasn't armel been killed off in precise?
<GrueMaster> Just use the armel kernel variant (so as not to confuse dpkg).
<GrueMaster> Only the image builds.
<GrueMaster> Pool is still active, and I also regularly do netboot installs on my pandas for sanity checking.
<ogra_> we dont build armel images and we dont massively care for armel pacvkages either
<ogra_> the archive is still existing and wont go away
<danboid> ppisati, I can get a package for 11.10 armel with the snd-seq compiled as a module?
<ppisati> danboid: get the P kernel
<danboid> ppisati, ? Link?
<danboid> ppisati, please!
<ppisati> danboid: http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-meta-ti-omap4/linux-image-omap4_3.2.0.1408.8_armel.deb
<danboid> ppisati, Thanks v. much! Will be trying that tonight! :)
<danboid> Thanks for your help guys!
<prp_> does anyone know how to install minicom on pandaboard. I tried sudo apt-get install minicom but it says E: unable to locate package minicom. I enabled all software sources and restarted but it still doesnt work
<GrueMaster> prp_: It should be there.
<GrueMaster> ubuntu@panda3:~$ apt-cache search minicom
<GrueMaster> cutecom - Graphical serial terminal, like minicom
<GrueMaster> minicom - friendly menu driven serial communication program
<prp_> thats exactly what i see
<GrueMaster> ubuntu@panda4:~$ apt-cache madison minicom
<GrueMaster>    minicom |      2.5-2 | http://mirror.gruenet/ubuntu-ports/ precise/universe armhf Packages
<GrueMaster>    minicom |      2.5-2 | http://mirror.gruenet/ubuntu-ports/ precise/universe Sources
<GrueMaster> Heh, local mirror, but should be identical to ports.u.c
<prp_> i opened ubuntu software manager and tried to install 7zip and it gave a button to use universe source. i clicked it, now minicom works as well
<GrueMaster> Note to self, don't run minicom in a remote screen session.  Key bindings are the same.
<steev_> GrueMaster: i normally use screen /dev/ttyUSB0 115200, it gets confusing when i go a few screen sessions deep
<GrueMaster> steev_: I was only testing minicom on panda to verify it ran.
<steev_> ahh
<GrueMaster> I use screen for all my serial consols.
<steev_> i find it easier to use
<steev_> my buddy keeps trying to get me to switch to socat
<GrueMaster> I'm actually going to look for some kind of serial console app that can multiplex.  I need to have screen running, but I also want some script to be able to interact with netboot installs when needed.
<GrueMaster> Not sure if I can just attach to the screen session in python.
<xteejx_> Hi guys, anyone here that can answer 1 or 2 quick questions about Ubuntu for arm please?
<xteejx_> The wiki states Ubutnu arm is for v7+, but I have an arm11 (v6). Is there no way I can get it on there?
<GrueMaster> xteejx_: Sadly, no.  But Debian is very similar and will support your hardware.
<xteejx_> GrueMaster, Damn :(
<xteejx_> I'll have a google around for debian related stuff then, thanks anyway for the pointer :)
<GrueMaster> Good luck.
<xteejx_> lol thank you :)
<Riddell> on what mailing list can I ask arm issues?
<pbuckley> heh
<pbuckley> i wonder how many raspberry pi people we will see in the upcoming weeks asking why ubuntu doesnt boot
<lilstevie> pbuckley, heaps no doubt :p
<pbuckley> btw anyone know of a good eq (per frequency adjustments)?
<pbuckley> thats system wide
<pbuckley> alsamixer seems to have some built in filters
<pbuckley> but couldnt figure out how to change em
<GrueMaster> Riddell: What arm issues?  What platform?  There are quite a few choices.
<Riddell> GrueMaster: the one where my pandaboard doesn't boot with a precise install
<pbuckley> using the right image?
<GrueMaster> Riddell: First, I would recommend going through the troubleshooting section at http://pandaboard.org/content/resources/troubleshooting to make sure your system works and your environment is set up correctly.
<GrueMaster> If everything goes well there, we can work to figure out why Ubuntu isn't working on your pandaboard.
<Riddell> it works fine
<Riddell> it does not work with precise
<GrueMaster> What exactly doesn't work with Precise?  (note that I frequently test the daily precise images).
<Riddell> the same thing as last time we looked at it http://starsky.19inch.net/~jr/tmp/precice-arm-boot.txt
<pbuckley> im running two pandaboards with precise
<pbuckley> that looks like a bad sd card at first glance
<Riddell> works fine with oneiric
<pbuckley> well something is wrong with your setup
<pbuckley> i assure you
<pbuckley> sorry
<pbuckley> bad day
<pbuckley> ill be back later
<GrueMaster> Which image is this?
<GrueMaster> I'm not seeing this on today's daily image.
<Riddell> armhf omap4 daily build from today for ubuntu-desktop, armhf omap4 daily build for when we last tested it, armel precise image from alpha 1
<Riddell> I know you're not.  you weren't when we tested it the other day either.
<GrueMaster> Hmm.  It is possible you have a defective board, but I can't verify that.
<Riddell> got a copy of the validation image?
<GrueMaster> This is on first boot?
<Riddell> yes, also on boot after upgrade from oneiric
<GrueMaster> Not on me.  It is at http://pandaboard.org/content/resources/troubleshooting
<Riddell> that link doesn't work
<GrueMaster> Try http://pandaboard.org.  Click on RESOURCES.
<GrueMaster> Or is it the gforge.ti link that is broken?
<Riddell> yes
<GrueMaster> Let's try in #pandaboard.
<GrueMaster> Riddell: Well, that would explain the broken link.
<Riddell> mm hmm
<GrueMaster> So, do you have a more recent copy of the daily builds, or at least Beta 1?
<GrueMaster> Also, can you download and try the ubuntu-server daily as well?  I doubt it will change anything, but it would be useful to test.
 * Riddell snoozes
#ubuntu-arm 2012-03-17
<danboid> How do I install http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-meta-ti-omap4/linux-image-omap4_3.2.0.1408.8_armel.deb ?
<danboid> The debs there are only a few k in size so is there a ppa I'm missing?
<infinity> danboid: No.
<infinity> danboid: It depends on the real kernel image.
<GrueMaster> You want linux-ti-omap4.
<infinity> danboid: No PPAs required, just apt-get install linux-image-omap4.
<danboid> Nope - if I run that command it will install linux-image-3.0.0-1207-omap4
<danboid> which doesn't have ALSA seq
<infinity> danboid: Because you're running oneiric.
<GrueMaster> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-ti-omap4/linux-image-3.2.0-1409-omap4_3.2.0-1409.12_armhf.deb
<infinity> danboid: 3.2.x is the precise kernel.
<GrueMaster> infinity: He wants the precise kernel on Oneiric.
<GrueMaster> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-ti-omap4/linux-image-3.2.0-1409-omap4_3.2.0-1409.12_armel.deb actually.
<infinity> Sure, but if you want the precise kernel on oneiric, you shouldn't just manually install the debs, you should add precise sources and do some creative pinning.
<infinity> Cause otherwise, you won't get upgrades.
<GrueMaster> Upgrades are irrelevant when you are testing a specific feature of the kernel (Alsa Sequencers in this case if I'm not mistaken).
<danboid> GrueMaster, Yep
<danboid> I'll happily install precise the minute I know pvr is working but its not an option just yet
<GrueMaster> Not sure that pvr will work with the kernel link I pointed to you either.
<infinity> Oh, if you want PVR working, you need to install the 3.1 kernel from the tiomap-dev PPA.
<infinity> It's the one that has the bits that go with their binary driver.
<danboid> GrueMaster, Thanks for the link - I'm going to give that a go
<danboid> I was trying to get my panda to boot off usb and I've trashed my boot.scr although I did back up my old one so now I'm hoping I can fix u-boot on my PC?
<danboid> Apparently I can use mkimage (from u-boot) to get things going again with a re-install?
<danboid> without a re-install, sorry
<danboid> I edited boot.scr directly instead of boot.script you see
<danboid> prob vecause I was thinking 'this is never going to work' as I was doing so :)
<danboid> Just about to try again re-configuring u-boot and I'll be mighty pissed if I have to do all this over again so just want to check a few things
<danboid> I'm mainly following this guide http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#I_want_to_install_Ubuntu_on_external_USB_hard_disk_instead_of_sluggish_SD_card
<danboid> After editing boot.txt, is it just a case of running 'sudo flash-kernel' in the same folder as the u-boot config files?
<danboid> ie the boot partition needn't be mounted somewhere specific or even unmounted when I run this?
<danboid> I can't get buntu to boot off SSD on my Panda
<danboid> u-boot ain't reconfiguring when I run 'sudo flash-kernel'
<danboid> despite me having edited boot.txt
<danboid> I've tried both /dev/sda1 and its volume name but its still booting off SD instead
<danboid> wtf?
<danboid> These instructions aren't working for me http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#I_want_to_install_Ubuntu_on_external_USB_hard_disk_instead_of_sluggish_SD_card
<danboid> because boot.script doesn't exist in my boot partition
<danboid> Does he mean edit boot.txt? Thats what I've been trying with no luck
<GrueMaster> danboid: Morning.  Let me try to help (if you are still stuck).
<danboid> Hi GrueMaster !
<GrueMaster> Morning.
<danboid> GrueMaster, So I think I did get u-boot reconfigured but I'm not so sure I'll be able to boot off my SSD even though I can use it once booted
<danboid> 'line disk installation timed out' is what I'm getting
<GrueMaster> Hmmm.
<GrueMaster> Were you able to rebuild your boot.scr file ok?
<danboid> I think - I didn't see any errors
<GrueMaster> Can you post any console log output?
<danboid> GrueMaster, Yeah - give me a few minutes to move stuff and get you that..
<danboid> Its a 2.5" OCZ Octane S2 64GG SSD
<danboid> but before I try would you know if the Linaro 12.02 desktop image outputs to serial console by default?
<GrueMaster> I haven't used the Linaro images yet.  Too busy testing my own.
<jimerickson> the latest armhf+omap4 image is very stable on pandaboard ES. thank you ubuntu!
<danboid> GrueMaster, http://pastebin.com/vuuNcseK
<GrueMaster> danboid: I'm not sure why it is doing that, but I noticed in the boot cmdline that you have "root=pandadisk".  Did you try changing that to "root=/dev/sda1"?
<GrueMaster> Normally, we have it set to "root=UUID=<partition UUID>"
<danboid> GrueMaster, I think I did but I'm going to try again as I may have had my u-boot config file in the wrong place - that guide I followed needs a fair bit of work
<GrueMaster> The easiest way to edit the boot.scr is to first strip the u-boot crc stuff with "dd bs=72 skip=1 if=boot.scr of=boot.script".  Then edit it as normal text.
<GrueMaster> To make it a u-boot script, run "mkimage -A arm -O linux -T script -C none -d boot.script boot.scr" and put the boot.scr back in partition 1 of the SD.
<danboid> GrueMaster, Is this documented anywhere? The u-boot man page or online help doesn't tell you any of this
<GrueMaster> I think I have it on our wiki, but others have moved stuff around lately without my knowledge.  I'll have to look.
<GrueMaster> Ah, they are still there.  Little dated (the Serial console port ID has changed).  https://wiki.ubuntu.com/ARM/BeagleEditBootscr
<GrueMaster> Also, if I read correctly, your usb drive is labeled pandadisk.  To mount it by label, you need "root=LABEL=pandadisk".
<danboid> GrueMaster, aha! I must admit i've never tried mounting by label before so that makes sense
<danboid> GrueMaster, So this guide needs a thorough editing/ correcting http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#I_want_to_install_Ubuntu_on_external_USB_hard_disk_instead_of_sluggish_SD_card
<danboid> GrueMaster, I'll fix it up this weekend sometime if I can
<GrueMaster> Yea, well I only trust guides I write (most of the time).
<GrueMaster> Also, the cp part would be far faster if you used "cd <sd mountpoint>;sudo tar -cf - .|(cd <usb mountpoint>;sudo tar -xf -)".  This will give you a multithreaded copy that is usually 2x faster.
<GrueMaster> One thing I wanted to create was a tool that when installed would step through partitioning your usb drive, then reboot and move the data from SDp2 to USB while still in the initrd.
<GrueMaster> Never got around to it (way too busy).
<danboid> GrueMaster, That sounds cool!
<danboid> GrueMaster, Anyway, I've got my SSD booting fine now and there is a notable improvement all round
<GrueMaster> Excellent!
<danboid> GrueMaster, I'll correct that guide later today or tomorrow
<GrueMaster> You can add my instructions on boot.scr editing if you want.  I think it would be useful to others.
<danboid> GrueMaster, I could do but I didn't try your tricks so maybe its best stick to what I know actually works? Tried and tested is the only way docs should be wrote
<GrueMaster> I've been using those instructions almost daily since karmic.  I originally wrote them early during Maverick.
<danboid> GrueMaster, I'm not saying they don't work - I believe you
<danboid> GrueMaster, but the existing instructions are just plain wrong in a few places
<GrueMaster> At any rate, it's the weekend and I'm finding myself in my basement office trying to write a python script to generate checksums of a mysql database.  Something seriously wrong here.
<danboid> Yick! :/
<GrueMaster> Did I mention that this is my first Python script?
<danboid> Nope! :)
<GrueMaster> The script is to test the lamp stack and run workload stress runs.
<GrueMaster> (I figured doing yet another Hello World script would be too easy).
<GrueMaster> Started learning Python Monday, haven't used MySQL extensively since 2003...  Can't be too hard, right?  :P
<danboid> I installed the Precise armel kernel under oneiric for panda and X worked on the first couple of boots but now it just says 'ti_hdmi_4xxx_detect: by detect line: 1 (1 == connected)' over and over preventing boot
<danboid> Is there a fix or have I just gotta wait for the pvr driver to arrive in precise repos (+ kernel fix)?
<infinity> danboid: I'm sure I've said this before, but if you want the TI binary drivers to work, you need to use the kernel from their PPA.
<infinity> danboid: Unfortunate, but that's the route they chose to go.
<danboid> infinity, but did you say I could recompile the same kernel version?
<infinity> I don't think recompiling came up. :P
<danboid> (and get pvr to work)?
<danboid> infinity, Well I've tried the other options now
<infinity> I'm not sure what you mean by "get pvr to work".  If you mean "use the binary drivers from the TI PPA", then use the TI PPA kernel.
<infinity> If you mean "make the display work at all", then our kernel (and nothing from the TI PPA) works too.
<infinity> Any combination other than "Just Ubuntu bits" or "Just TI PPA bits" is likely to go pear-shaped.
<danboid> infinity, I want ducati to work- does that depend on pvr?
<infinity> I believe that requires the binary drivers, yes.
<danboid> infinity, I'm quite happy to use the same version of the kernel used by the TI ppa if I can recompile it to get the modules I need
<infinity> Their doesn't already include everything?
<infinity> s/Their/Theirs/
<danboid> No ALSA sequencer
<danboid> This is in the precise kernel as a module
<infinity> When was that added?
<danboid> Last few days?
<infinity> The TI PPA kernel is 3.1 (not 3.0), so... Oh, if it's that new, no. :P
<infinity> And unless you're prepared to backport the feature, you're probably out of luck there.
<infinity> You might try bugging ndec about what's going on with the precise TI binary drivers.
<infinity> Since they plan to ship a custom 3.3 kernel in their PPA for precise, if I recall.
<infinity> Just not sure when.
<infinity> Though, I do wonder how a feature that was just added a few days ago is something anyone "needs".
<danboid> infinity, ALSA seq support has been around since forever - its not a new feature at all it just isn't in the ARM oneiric kernels
<infinity> danboid: As in, it's just a config option you can flip?
<danboid> infinity, yep
<infinity> danboid: In that case, sure, you could rebuild the TI PPA kernels, they have the source in the PPA.
<danboid> infinity, Great - thats my task for tonight then!
<danboid> Thanks - bbl
<prp> I have a pandaboard and a lilliput touch screen. This solution fixes the inverted touchscreen problem but the instructions are for x86 and i cannot find that package for arm. what can i do?http://www.autodeist.com/node/132
<prp> those instructions are for ubuntu x86*
<GrueMaster> Try installing xserver-xorg-input-evdev
<GrueMaster> Also, the instructions were written in 2009.  Little out of date, considering recent X changes.
<prp> Gruemaster evdev is already installed byt i cannot find the .fdi file to change
<prp> usr/share/hal/fdi/policy/20thirdparty/50-eGalax.fdi doesnt exist and i dont know what the equivalent is
<GrueMaster> Yea, I think hal was fazed out in Lucid.
<prp> i have 11.10 but under fdi/policy, there is only 10osvendor
<GrueMaster> Have you tried using this device on an x86 system with the same Ubuntu release?
<prp> no i didnt
<prp> i need to use it with a panda
<GrueMaster> I understand.  Just trying to isolate this to either a Panda problem, an Ubuntu Arm problem, or an Ubuntu All problem.
<GrueMaster> If it doesn't work in x86, it won't work in arm.
<GrueMaster> (and I don't have one to play with).
#ubuntu-arm 2012-03-18
<danboid> If a kernel flash goes wrong, what are the steps to revert to the previous one?
<danboid> I presume you'd restore all the .bak files in the boot partition and.. mkimage?
<danboid> I'm talking about u-boot on a panda btw
<danboid> I'm really unsure about how mkimage is supposed to work - surely you need to have your boot partition mounted in a soecific place or pointed to for it to work?
<danboid> and I don't know which file specifies the kernel to use either - if there is one
<danboid> I don't see that in boot.script so maybe uImage is the one and only?
<danboid> panda|x201, Any idea how to revert to a previous kernel when a flash goes wrong?
#ubuntu-arm 2013-03-11
<cobalt60_> Anyone install Ubuntu on the Lenovo Yoga?
<lilstevie> cobalt60_, I'm assuming you are referring to the yoga 11 given the room we are in
<lilstevie> to which the answer will be, no, nobody will have installed ubuntu on it, because of secureboot
<cobalt60_> Yes the 11.  Thats too bad...
<cobalt60_> any other ARM netbook with a touchscreen running Ubuntu?
<hrw> cobalt60_: asus transformer line of tablets + keyboard dock
<lilstevie> however ubuntu probably could run a little bit better on them :p
<hrw> no idea how it works on those ;D
<marvin24> <ogra_> marvin24, you mean to your kernel package, not flash-kernel, right ?
<marvin24> ^ no - I decided to use flash-kernel
<marvin24> it seemed more appropriete to me
<marvin24> in fact, the scripts gets called on every kernel install
<marvin24> arrr, it failed to upload again
<suihkulokki> plan to use nano-sized usb stick as ubuntu rootfs on chromebook foiled by the fact that usb support is in modules...
<phh>  and then you discover initramfs...
<phh> and realize than on most x86 distribs, everything is in module, either sata or usb or pata or whatever storage you use. including the FS
<suihkulokki> unfortunately the chromebook firmware doesn't support initrd
<hrw> suihkulokki: I think that we need to switch to chainloaded uboot
<hrw> a bit overhead but easier support
<hrw> no kernel signing
<suihkulokki> sticking to sd card booting for now
<suihkulokki> the sd card is anyways 5x faster than the cruzer fit I bought
<hrw> sd ends at ~20MB/s in chromebook
<hrw> my samsung does 20MB/s read and 8MB/s write
<ogra_> USB 3.0 FTW :)
<hrw> ogra_: 76MB/s from old harddrive
<hrw> ogra_: 135MB/s from new one but this one is in use with other machine normally
<ogra_> yeah, i'm still looking for a micro USB 3.0 key for my chromebook
 * ogra_ doesnt like things that stick out of the case to much
<suihkulokki> that was kind of the idea of the cruzer
<hrw> suihkulokki: and you know that default bootloader do not check usb3 port when you press ^u?
<suihkulokki> hrw: no I didn't..
<hrw> probably no xhci support in u-boot for that
<suihkulokki> most likely
<ogra_> ppisati, have you seen marvin24's patch to flash-kernel to support dtb ? would that work generically enough for our own kernel packages too ?
<ppisati> ogra_: didn't see it, where is it?
<ogra_> http://paste.ubuntu.com/5602702/
<ogra_> marvin24, hmm, line 9 looks wrong btw
<ogra_> i guess you meant $x
<ogra_> and line 3 shouldnt use if ...
<ogra_> grep -q 'Flattened Device Tree' /proc/cpuinfo || exit
<ogra_> (and it should rather exit gracefully instead of "exit 1" if there is no device tree, we still have many kernels that dont ship  it)
<marvin24> ogra_: ok, thanks for comment
<ogra_> hmmm, disregard the last one ... i'm not completely awake today :)
<marvin24> I wonder how it worked with $z at all ...
<ogra_> heh
<marvin24> yes, line 3 checks that already
<ogra_> right
<ogra_> i just need ppisati to confirm it works with the other dtb kernels too, then we can pul it into raring
<ogra_> *pull
<marvin24> I used flash-kernel, because the scripts in /etc/kernel/* seems to come from various packages, but linux-image provides none
<marvin24> ogra_: cool - that would be nice
<ogra_> i thougth it provides the postinst.d bits
<marvin24> tegra needs also to be added to the db
<marvin24> ogra_: flash-kernel does, but not the linux-image package itself
<ogra_> k
<ogra_> ogra@anubis:~$ dpkg -S /etc/kernel/postinst.d/*| grep linux
<ogra_> ogra@anubis:~$
<ogra_> yeah
<ogra_> xnox, hmm, did you replace compiz with metacity ? it just struck me that i didnt have a single chrash during my test install
<xnox> ogra_: no, i did not.
<xnox> but there was a compiz / unity update recently?!
<ogra_> yeah, several over the last week
<ogra_> (2 at least i think)
<ogra_> seems to have fixed the world :)
<ogra_> or i was just lucky
<mjrosenb> is there an armel compiler available for armhf systems?
<djvj> need info on how to install armel GCC onto an armhf installation (raring)
<djvj> online info seems kind of sparse on this issue.  tried dpkg --add-architecture armel and apt-get updating, but update simply complained about there not existing armel repos
<NekoXP> mjrosenb, you can compile armel stuff with the armhf compiler. the tuple is just a ridiculous packaging kludge.
<NekoXP> -mfloat-abi=softfp and it'll generate the right binaries (you may need to drag in armel multiarch/lib dependencies first though)
<NekoXP> alternatively if you need the tuple to be right, just install gcc-arm-linux-gnueabi{,-4.7} or so (version dependent on your ubuntu, maybe don't need the version at all to get the right package) and it'll do the right thing.
<infinity> NekoXP: gcc-arm-linux-gnueabi is a cross-compiler.
<NekoXP> djvj, same info to you I think.. the right things should be there, I don't think you have to add-architecture if raring is really multiarch compliant.
<infinity> djvj: Just install g++-multilib and use -mfloat-abi=soft (or softfp, depending on your target)
<NekoXP> infinity, on ARM? not really, just a compiler built to different defaults..
<infinity> NekoXP: That package doesn't exist on ARM.
<djvj> infinity: thx
<NekoXP> huh did it get removed
<infinity> NekoXP: It never existed on ARM.
<NekoXP> it installs fine on quantal armhf... that said maybe I have some linaro ppa floating around
<infinity> NekoXP: All the gcc-triplet packages are cross-compilers.
<infinity> NekoXP: At least, in the archive.
<infinity> djvj: As to why the add-architecture bit didn't work for you, that's because raring has no armel anymore.  We dropped the arch.
<djvj> mjrosenb: I think my issue is not in particular with the compiler.  it's that the object is built with the appropriate -mfloat-abi and -msoft-float args, but then it attempts to build the final binary without passing those.
<infinity> djvj: But if your goal is just to compile a soft-float binary for some reason, g++-multilib will DTRT.
<djvj> infinity: oh.. what was the reasoning behind the drop?
<infinity> djvj: We had no compelling reason to support it.  Every platform we target can use armhf.
<infinity> djvj: Which also leads to the question of why you're compiling soft-float binaries, but maybe you have a reason.
<NekoXP> here's the real question, why would you bother compiling for softfloat anyway on an ARM box running armhf? If you've got to have that capability use an x86 box and use a cross-compiler.. is it just that there's some native packaging requirement that dpkg-cross doesn't handle?
<djvj> infinity: Actually now that you mention it, I'm not sure.  Lemme ask..
<infinity> mjrosenb: Oh, and I didn't notice you'd asked the very same question.  apt-get install g++-multilib and use -mfloat-abi=soft (or softfp, if your target supports that).
<djvj> infinity: Well, no answer yet, but I'm trying to build spidermonkey on ARM.  I think its JIT uses the armel ABI for float ops.
<infinity> djvj: Well, if it's also going to depend on any system libraries other than libc/libstdc++, that's just plain not going to work.
<infinity> djvj: If the intent is to run it on armhf somehow.
<infinity> djvj: If the intent is to build and run it on armel, just use Debian/armel, since targetting a non-existent Ubuntu armel seems silly.
<infinity> djvj: (And, more to the point, if it fails with armhf, perhaps fixing it would be smarter than working around, as all modern armv7 distros are going/gone hard-float)
<djvj> infinity: it should be possible to just set up a chroot environment and target debian repos inside that, no?
<infinity> djvj: You can debootstrap a sid/armel chroot on raring, sure.
<infinity> debootstrap --variant=buildd --arch=armel sid chroot-sid
<djvj> infinity: I'm just getting my feet wet on ARM related stuff, so I can't really defend one vs the other at this point..
<infinity> djvj: There is no one versus the other.  All modern ARM distros are armhf, period.  Some people sort of support armel on older hardware (Debian and Fedora), but it's not anyone's focus.
<infinity> djvj: And with the exception of Debian, no one supports full multiarch between ABIs.
<infinity> djvj: So, if your stuff depends on anything outside the base toolchain, it's just plain not going to work.
<infinity> djvj: So, yes, the only sane way forward is to make your stuff work on armhf, IMO.
<mjrosenb> I remember coming in here a while ago, and hearing that the hardfp compiler with --mfloat-abi=softfp was *not* equivalent to using an armel compiler through and through.
<infinity> mjrosenb: The only difference is the default CPU target (which you can also set).
<infinity> mjrosenb: Whoever told you it was otherwise different was mistaken.
<infinity> mjrosenb: But see above.  If you depend on other libraries, such attempts will fail anyway, since we only give you a base toolchain with the armel ABI.
<mjrosenb> *nod*
<infinity> Still, same recommendation as I gave djvj, moving to armhf wholesale is the sane way forward, rather then entrenching workarounds.
<infinity> We're the only distro that provides multilib toolchains that actually work, Debian is the only distro that provides armel/armhf multiarch, everyone else has moved to armhf entirely, except for Fedora's old armv5/armel port not quite being dead yet.
<infinity> Targetting the old ABI just isn't worth it in the long run.
<infinity> Besides, if I decide to break or drop the multilib toolchain in the future, I'd rather not have people whining about it because they expected it to work forever. :P
<infinity> I do look forward to a day (soon, I hope) where I can just drop all soft-float support, must as we did for OABI.
<infinity> s/must/much/
<mjrosenb> infinity: so we have no issues supporting hardfp
<infinity> I also look forward to a day where I can drop i386.
<infinity> Not sure when either of these days may actually come. :P
<mjrosenb> infinity: the problem is that we're using this to test our jit for android
<mjrosenb> and android only supports softfp these days
<mjrosenb> so for testing purposes, we need to be able to run softfp code.
<infinity> mjrosenb: That's untrue, there are hard-float Android builds.  But yes, by default, you're right.  And I'd recommend just using a Debian chroot if you're looking for a soft/softfp environment.
<mjrosenb> infinity: if you can convince android to switch to hardfp, I won't even look back.
<infinity> Or use Android itself. :P
<infinity> I saw some interesting bits in HK last week about Linaro folks making Android self-hosting.
<mjrosenb> infinity: the problem i've always had is running gdb on android
<mjrosenb> and our test harness that is written in python.
<infinity> Ahh, yeah, those may still be issues.  I've not played with their attempts to make Android pretend to be a real build system to see how far it is.
<infinity> Anyhow, Debian or Fedora chroots are likely a reasonable compromise.
<infinity> Or quantal/armel.
<infinity> Which was our last armel release.
<mjrosenb> infinity: evidently fedora doesn't do the whole cross compiling thing?
<mjrosenb> and they build all of their arm packages on arm machines.
<infinity> They do everything natively, yes.
<infinity> Then again, so do we.
<infinity> We just ALSO provide cross toolchains.
<infinity> But this isn't about cross anyway, is it?
<mjrosenb> infinity: djvj is trying to do it natively, I've been using cross (from amd64) for several years now.
<infinity> Ahh. ;)
<infinity> Well, same arguments.  We ship a cross that works for biarch/multilib just fine, but if you need access to multiarch libs to link against, you're SOL past quantal.
<infinity> Not much I can do about that.  I fought to save armel, I was one of the few.  We just didn't have a compelling enough argument to keep it.
<infinity> Then again, precise should be a good enough base for people to keep doing stuff against for another four years, and we can hope armel is dead by then.
<mjrosenb> sadly, our new arm dev machines are chromebooks, which you *really* want to be running raring on.
<infinity> Sure, but not chroots.
<infinity> It's just the kernel and alsa and such that you want raring for.
<djvj> yeah chroots should serve fine, up until such a point where libs get too old for the kernel, which hopefully shouldn't be for a while
<infinity> djvj: Or ever...
<infinity> djvj: About the only kernel/userspace mismatches that ever matter are with udev (which shouldn't be running in chroots) and glibc (which occasionally bumps required kernel version, but the kernel doesn't break glibc by revving)
<infinity> djvj: So you should be fine with, say, precise/armel chroots on your raring (and beyond) systems.
<djvj> infinity: good to know.  thanks for the help btw.  I just built with hardfp and can replicate the issue I'm trying to track down.
<mjrosenb> infinity: the kernel occasionally breaks glibc by revving
<mjrosenb> infinity: but it has happened like twice
<lilstevie> mjrosenb, infinity fedora most certainly does have some cross-compiler bits
<lilstevie> $ arm-linux-gnu-gcc --version
<lilstevie> arm-linux-gnu-gcc (GCC) 4.7.1 20120606 (Red Hat 4.7.1-0.1.20120606)
<sbaugh_> Is Bluetooth working now on the Nexus 7 image? I am seeing conflicting reports. Does it perhaps require a workaround?
#ubuntu-arm 2013-03-12
<mjrosenb> lilstevie: how do you install them?
<mjrosenb> lilstevie: I asked in #fedora-arm, and they denied its existence.
<lilstevie> um give me a sec
<lilstevie> mjrosenb, I got the package name from fedoras own wiki 0.o
<lilstevie> gcc-arm-linux-gnu.x86_64 : Cross-build binary utilities for arm-linux-gnu
<lilstevie> straight from the yum search
<sbaugh> I guess Bluetooth is working :)
<sbaugh> And so is dwm! awesome!
<sbaugh> Thank you Ubuntu Nexus 7 porters! I have a new netbook!
<lilstevie> mjrosenb, find it?
<infinity> lilstevie: Oh shiny.  I was lied to.  Not running Fedora personally, I had to accept that lie as tentative truth.  Thanks for the correction. :)
<lilstevie> infinity, np :)
<lilstevie> FC18 fwiw
<lilstevie> I can't comment on earlier versions
<infinity> Yeah, I just assume latest release and/or rawhide as a general rule.  Older Fedora releases are worth anyone's time about as much as older Ford Pintos.
<lilstevie> fair enough
<lilstevie> fedoras current recommended setup is to use distcc with arm guests and an x86 server
<lilstevie> which I find a little overkill
<infinity> Just a tad. :)
<lilstevie> if something only builds native, I'll build it native otherwise I'll crossbuild, and packaging is always done native for me
<sbaugh> What script/service is doing the rotation on the Ubuntu Nexus 7 port?
 * Snark wonders how easy it can be to use an arm chromebook with qwerty keyboard... in french...
<marvin24> ogra_: https://launchpadlibrarian.net/133791292/flash-kernel_3.0~rc.4ubuntu29_3.0~rc.4ubuntu29-tegra.diff.gz
<marvin24> ^ this still misses a remove script
<ogra_> marvin24, hmm, doesnt your u-boot support uEnv/preEnv.txt ? we gave up supporting booot.scr quite a while ago, so that we could use plain text files and /etc/default/flash-kernel to seed the cmdline
<marvin24> ogra_: yes, as I said before, uEnv/preEnv is an uboot macro implemented in the omap config
<marvin24> I can look into it again, but I don't see what's the problem with boot.scr
<ogra_> consistency
<marvin24> you still need to run mkimage on vmlinuz and initrd
<marvin24> I'll think about it to add uEnv support to tegra
<ogra_> i.e. telling people "please edit /etc/default/flash-kernel and run sudo flash-kernel" is the std way to change your commandline with all other u-boot supported devices in ubuntu nowadays
<marvin24> yes, editing something in /usr/share isn't nice
<ogra_> it is mainly for systems that use SD cards indeed, so that you can just edit a txt file instead of being forced to have mkimage installed
<ogra_> we just tried to get away from that requirement ... the /etc/default stuff is just a convenient extra to make it more like grub
<hrw> Snark: you can load AZERTY keymap - just do not look at keys ;D
<Snark> hrw, hmmm... wouldn't it be easier to keep the keyboard as qwerty but enable some dead key to obtain accentuated chars?
<hrw> Snark: no idea. Polish keyboard is based on US one
<hrw> and I have UK keyboard in chromebook... but I do not look at keys
<ogra_> there are kbd stickers you could use
<qwertyuiop_v1> Hello!
<qwertyuiop_v1> Do we have support for USB DVB Cards in Ubuntu Raring Ringtail (armhf) ? WinTV-Nova-T Stick is supported (linux-firmware-nonfree) but nothing happens (no smsusb probing done) when I plugged it in my Nexus 7... ;D
<ogra_> qwertyuiop_v1, files a bug and ask for the kernel option to be enabled, its not intentional :)
<ogra_> apw, ppisati ^^^^^
<ogra_> *file even
<apw> ogra_, may well not be on indeed, but yes file a bug and we can look into it
<ogra_> i doubt it is ... i think there is a bug to enable all possible USB module options though
<qwertyuiop_v1> ogra_, apw: thanks for your prompt response, I will file a bug
<davmor2> ogra_: the phablet-flash command do you find you need to run it a couple of times if you haven't for a while?  the first seems to just error out and the second work flawlessly
<davmor2> ogra_: phablet-flash -l I should say
<ogra_> davmor2, i never used it :)
 * ogra_ just copies both zips in place with the bootloader 
<davmor2> ogra_: fair enough
<ogra_> ask in #ubuntu-touch ... probably when rsalveti is around, i think he knows that script
 * ogra_ doesnt have a supported phone so i have to do it manually anyway for my SGS2 port
<davmor2> ogra_`: :(
<ogra_`> ?
<davmor2> ogra_`: to the non-supported phone sorry just playing catch up
<ogra_`> non supported phone ?
<ogra_`> you mean the guy wanting a raspberry Pi port of ubuntu touch ?
<ogra_`> oh, you mean my galaxy SGS2
<ogra_`> well, we only suppport nexus devices officiallly :)
 * ogra_` thought you refer to his current ML discussion on ubuntu-phone
<infinity> ogra_`: After having JUST flashed a GS2 literally an hour ago and discovering that they don't need unlocking or any other madness, I suspect that getting ubuntu-phone going on one would be dangerously close to trivial.
<infinity> ogra_`: I'd do it myself, but I have to give this phone back to its owner now that I've unbricked it for her.
<ogra_`> infinity, it runs absolutely perfect here since the weekend on my SGS2
<infinity> ogra_`: (A Samsung OTA update bricked it, so I opted to just say "eff samsung" and reimage it with CM10)
<infinity> ogra_`: Ahh, cool, you're already on it.  Awesome.
<ogra_`> yeah, ubuntu touch isnt much hardewr once you have the HW issues sorted
<ogra_`> wlan was a bit tricky since there are two firmwares for the same device ...
<ogra_`> took me a while to figure that  out
<rsalveti> davmor2: that's because adb
<rsalveti> davmor2: it seems we need to add some sort of delay from the first time adb is initialized
<ogra_`> and it didnt work with the recent mali android drivers ... but someone patched that bit to use the former version
<infinity> ogra_`: Yeah, there are actually a whole bunch of SGS2 models, from what I discovered doing her recovery.
<ogra_`> now its working as good as a nexus here :)
<infinity> ogra_`: Hers being the "Rogers/AT&T LTE" variety.  skyrocket.
<ogra_`> i havent tried GSM yet since i dont want to actually unlock my SIm
<ogra_`> ugh, yeah, i thinnk vanhoof is also still struggling to get his verizon variant to work
<ogra_`> mine is luckily a plain GT-I9100
<ogra_`> i think slangasek also has one of tehse weirdos that were modified for a network provider
<davmor2> rsalveti: ah thanks
<ogra_`> rsalveti, definitely between adb root and adb shell calls
<rsalveti> bug 1143946
<ubot2> Launchpad bug 1143946 in Phablet Tools "phablet-flash fails on first run" [Undecided,New] https://launchpad.net/bugs/1143946
<rsalveti> yeah
<ogra_`> i even run into issues with that manually
<infinity> ogra_`: My favourite part about the skyrocket variant is that they're identical at the hardware level, but for whatever crazy reason, the volume/power combinations for accessing recovery/download modes are DIFFERENT between Rogers and AT&T phones.
<infinity> ogra_`: Can't fathom how that came to be, or why anyone thought that was a good idea.
<ogra_`> oh my
<ogra_`> i bet that took a while to figure out, eh ? :)
<infinity> It took a lot of angry button-mashing when all the AT&T-centric HOWTOs were wrong for me, yes. :P
<ogra_`> *sigh* why the heck do people want to run ubuntu touch on their RPi !
<ogra_`> that thread starts to annoy me
<infinity> But, much like fighting games on the SNES, if you mash enough buttons randomly, eventually you win.
<ogra_`> haha
<lilstevie> lol
<lilstevie> ogra_`, it is quite simple, people purchased the rpi thinking that it would be the go-to hardware
<ogra_`> yeah, i still wonder what made them think that
<lilstevie> because they don't understand the whole ARMvX issue
<lilstevie> ogra_`, pricepoint
<ogra_`> right
<lilstevie> ogra_`, everyone has this notion that if something is cheap, it will become the standard
<ogra_`> heh, so "ceapest" *must* be good ... indeeed :)
<ogra_`> *cheapest
<ogra_`> well, i was hoping to not have any RPi discussions anymore, but somehow that crap is re-occuring every few months
<lilstevie> yeah
<Snark> ogra_`, hrw eh, I don't mind using a qwerty as long as I have convenient access to dead keys...
<ogra_`> yeah, thats tricky on the chromebook ...
<ogra_`> there are so many keys missing
 * ogra_` really misses delete
<lilstevie> I did a whole rant the other day about how people still insist on releasing armv6 devices in another chan,  and how I will only consider something if it is armv7 but even then there are conditions, and the first thing someone asked me was if I owned a rpi, and if not am I planning to
<hrw> ogra_`: I have Del on F10
<ogra_`> hrw, i have vol up there (as labeled)
<ogra_`> the three volume keys are actually mapped like labeled for me
<ogra_`> (indeed i could change that but would have to re-map the volume stuff elsewhere)
<ogra_`> and wheer del usually sits there is the power key ...
<hrw> ogra_`: Esc F1 F2 F5 F11 F4 VolDown VolUp PgUp PgDown Delete Power - my setup
<hrw> lilstevie: devices <cortex-a15 are below my radar of interest
<xnox> ogra_`: does the rpi discussion frequency matches the batch rpi shipments arrival from china?
<ogra_`> heh, no idea, i try to stay away as far as i can from the RPi :)
<ogra_`> its just crappy proprietary HW
<xnox> OpenCrap (tm)
<ogra_`> heh
<ogra_`> its like a broadcom wlan card that expanded to a whole PC
<hrw> ;)
<hrw> marvin24: on which devices you checked your flash-kernel for DT devices patch?
<marvin24> hrw: ac100
<marvin24> but should work on all tegra2/3/4
<hrw> on chromebook I do not produce /lib/firmware/KERNELVER/ libs
<marvin24> libs? or device-tree?
<hrw> device-tree
<hrw> sory
<infinity> hrw: Well, you should start. :)
<marvin24> this actually comes from the ubuntu raring kernel (3.8)
<infinity> hrw: The distro mainline kernels do.
<hrw> infinity: maybe one day when I switch to uboot chainload
<marvin24> hrw: does /proc/cpuinfo contain "Flattened Device Tree" at all?
<hrw> marvin24: Hardware        : SAMSUNG EXYNOS5 (Flattened Device Tree)
<marvin24> ok
<hrw> infinity: kernel packaging is weird enough already
 * xnox notices that pxz and busybox compatability has been fixed now.
 * xnox TODO merge busybox
<ogra_`> \o/
<ogra_`> damned, so i wont have any excuse anymore to not implement xz tarballs
<ppisati> lp 1126836
<ubot2> Launchpad bug 1126836 in ubuntu-nexus7 "The error "df: warning: cannot read table of mounted filesystems: No such file or directory" is shown. Splash screen appears, then black screen." [Wishlist,Confirmed] https://launchpad.net/bugs/1126836
<ppisati> this is exactly what happens to me
<ogra_`> which is still unexplainable to me
<ppisati> at least i'm not the only one
<ogra_`> ppisati, no, thats the whoopsie bug that was fixed the same week
<ppisati> ogra_`: tried yesterday img, still there
<ogra_`> it exposed the exact same behavior
<ogra_`> yes, you said so
<ogra_`> but it is definitely not realted to that one
<ogra_`> everyone who had that issue confirmed it fixed after the whoopsie fix
<ogra_`> and it was weeks ago
<ogra_`> i'm pretty sure what you see is kernel/HW related
<ppisati> can we have the serial console on usb?
<ppisati> i se network manager keeps trying to bring up usb0
<ppisati> so i guess kernel is still alive
<ogra_`> ppisati, there is a serial console on usb ... in parallel to the usb0 iface
<ogra_`> check your dmesg
<ogra_`> the prob is that yu first need to modify the bootimg to boot with init=/bin/bash, then set a root PW, drop the init= again to be able to log in
<ppisati> ogra_`: no new ttyUSB* here
<ogra_`> its ttyAMA or some such
 * ogra_` forgot how the composite gadget calls it
<ppisati> ok
<ppisati> i see the serial
<ogra_`> you should get a login
<ppisati> yep
<ogra_`> but there is no user or root pw
<ppisati> ogra_`: can't we set a default user? ubuntu/ubuntu?
<ogra_`> not without horrid hackery, nope
<ppisati> :(
<Snark> ogra_, hrw the chromebook keyboard doesn't seem really usable... I'm wondering if a nexus10 + bt keyboard wouldn't be better (though three times more expensive)
<hrw> Snark: depends what you need
<ogra_> depnds if you want to sit in a comfy chair with the thing on your lap or not
<ogra_> if you always have a table its no issue to use an nx10
<Snark> ogra_, http://www.cdiscount.com/informatique/clavier-souris-webcam/bluestork-clavier-bluetooth-avec-support-tablette/f-10702151616-bskbpadbtf.html ?
<ogra_> well, i guess it will be wobbly and loose ... but try it
<ppisati> ogra_: the nexus7 img, what kind of archive is that? tgz? squash?
<ogra_> i used my nx7 for a while with wireless kbd ... and its slightly painful to always have to search a place to have it stand on
<ogra_> ppisati, a special fastboot ext4 based sparse file format .... containing a rootfs tarball
<ppisati> ogra_: can i "open" it in some way?
<ogra_> you can convert it with simg2img from android-fsutils
<ogra_> then you can loop mount it
 * Snark wonders when the new batch of arm tablets will get out... april? may?
<RoyK> Snark: what tablets?
<Snark> RoyK, hmmm... isn't it the right word?
<Snark> http://en.wikipedia.org/wiki/Tablet_computer <- it's the right word
<Snark> RoyK, I don't understand your question, then
<RoyK> what arm tablets are you talking about?
<infinity> Snark: They don't tend to release in batches, I think is the confusion.  Manufacturers release products when they release products...
<Snark> there are generally points in time where they make big announces
<Snark> and my question is : when is the next occasion they have to make such?
<infinity> Snark: You'd have to ask every manufacturer that.
<infinity> My calendar doesn't have a "big tablet announcement day" on it.
<Neko> infinity, generally CES is the big tablet announcement day ;)
<Neko> except it's more like a weekend. Google IO is the "we weren't ready at CES" fallback. But they do tend to announce them all at once to get one-up on each other, at CES, and then go silent (and usually don't produce) for the rest of the year.
<Neko> Snark, so you gotta wait until January basically
<Neko> the "new batch" came out already, got zero traction because the Nexus 7+10 beat the shit out of them.
<Snark> ok
<lilstevie> and asus, who are usually pretty vocal about their refreshes haven't done one yet, probably cause their weird lifecycle with tf201/tf300t/tf700 + n7
<angeloc> Hi guys, I'm building a minimal image for sabre lite
<angeloc> everything boots correctly, but cannot make ethernet working
<angeloc> there is no eth0, and ifup eth0 raise an error
<angeloc> bootlog shows no signs of ethernet device?!
<angeloc> ogra_: have you some hints?
<angeloc> anybody here?
<angeloc> I think I solved my problem
<angeloc> it related to an invalid mac address in  uboot
<angeloc> bug 817315
<ubot2> Launchpad bug 817315 in Linaro U-Boot "eth0 doesn't get a valid MAC address on startup" [High,Fix released] https://launchpad.net/bugs/817315
<angeloc> bye, thank you
#ubuntu-arm 2013-03-13
<ogra_> xnox, did you say pxz was already merged from debian or do i need to take care for getting it in (FFe etc)
<xnox> ogra_: busybox needs merging, pxz is fine on it's own.
<ogra_> but we dont have the fixes yet, do we ?
<xnox> the fix is in the busybox package for it to gain support for pxz compressed streams.
<xnox> the pxz that we have is fine and compliant. the bug is in busybox.
<ogra_> ah, k
<xnox> it was on my todo list to do soonish (busybox merge)
<ogra_> great, thx
 * XorA waits on chromebook
<xnox> ogra_: https://launchpad.net/ubuntu/+source/busybox/1:1.20.0-8ubuntu1 I am expecting it to be stuck in the beta1 freeze, so tomorrow it should hit raring.
<ogra_> xnox, no hurry ... thanks so much !
<mjrosenb_> https://gist.github.com/5154896
<mjrosenb_> uh-oh.
<sbaugh> Any suggestions on a good wm/de for the Nexus 7? I'm trying to use it as a netbook, and it works fine when I have the keyboard around on a tiling wm, but not so great when I don't have it. If only GNOME 3 worked...
<xnox> sbaugh: i use it with a small wireless mouse and touch keyboard just fine.
<xnox> sbaugh: but yeah, you'd unfortunately want tiling window managers to be effective with it.
<sbaugh> xnox: Unity, you mean?
<xnox> yes.
<sbaugh> yeah I'm using xmonad right now and it's really a joy but obviously has no touch support
<sbaugh> i'm waffling between using some floating window manager and just adapting xmonad... it has gesture support you know
#ubuntu-arm 2013-03-14
<XorA|gone> bah, arsed up the chromebook already :-(
<ogra_> how ?
<XorA|gone> following hrw guide to upgrade ChrUbuntu, but on internal eMMC not on SD
<ogra_> hmm, i just changed the sources.list and dist-upgraded
<XorA|gone> plymouth crashes and Im dead then
<ogra_> hmm, can you change the cmdline ?
<XorA|gone> nope
<ogra_> plymouth has a bug where it falls over if console-setup didnt run before ... thats quite racy
<XorA|gone> Ill do a recovery tomorrow and start again :-)
<ogra_> on systems with initrd thats easy to work around ... on the ones without your best chance is to disable plymouth completely
<ogra_> ogra@chromebook:~$ ls /etc/init/*.override
<ogra_> /etc/init/plymouth-log.override  /etc/init/plymouth.override  /etc/init/plymouth-splash.override  /etc/init/plymouth-stop.override  /etc/init/plymouth-upstart-bridge.override
<ogra_> just add these files to your system
<ogra_> each only containing the word: manual
<XorA|gone> cant as I have no access to system, but will remember that for next time :-D
<ogra_> yeah
<ogra_> well, you can do it from chromeos i think
<XorA|gone> I cant get to chromeos
<XorA|gone> unless there is some magic key to switch which kernel boots
<ogra_> no, not magic ... quite painful
<XorA|gone> and I forgot to enable usb boot
<ogra_> but you can switch back and forth ...
<XorA|gone> yeah, but Im totally locked out ;-)
<XorA|gone> Ill get it sorted tomorrow
<XorA|gone> or over weekend or something
<XorA|gone> got enough other linux/arm thingies
<XorA|gone> time to sleep
<ogra_> ah, yeah, there was that
<Splendor> Hello. I'm getting a "network unreachable" error in Chrubunut and hoping someone can help.
<Splendor> Chrubuntu*
<angeloc> Hi guys, I'm playing witha sabre lite and I can see that currente kernel fromRobertCNelson (3.8.2) currently has no video
<angeloc> do you know the latest kernel version where video is working?
<mjrosenb> https://gist.github.com/5159648 welp.
<mjrosenb> hey, do you guys know if crubuntu builds its own kernel from the chromeos tree, or if they just steal the chromeos kernel?
<mjrosenb> ugh... gdb :(
<hrw> mjrosenb: chrubuntu 12.04 is using chromeos kernel binary
<Mohamed-Anwar> Hi
<Mohamed-Anwar> AnyBody here ?
#ubuntu-arm 2013-03-15
<infinity> wookey: You know how I keep pointing out that multiarch-enabled buildds should be considered harmful for native builds, but I can never come up with a failure scenario to prove the point?
<infinity> wookey: https://launchpadlibrarian.net/134148682/buildlog_ubuntu-oneiric-amd64.libvrui2.6-collaboration_2.4-1~oneiric_FAILEDTOBUILD.txt.gz
<infinity> wookey: That pretty much sums it up.
<infinity> wookey: Arch skew there means he's stuck installing the i386 version of the build-dep and, since it's a build-dep on itself, there's no way out of it (cause the only way to fix the skew is to build the package that can't build)
<infinity> wookey: Anyhow, fixing this by tearing multiarch out of that chroot, like I did for precise and beyond (not sure how I missed oneiric), but that seems to prove my point nicely.
<mjrosenb> hey, I want to cross-compile iceweasel, but |apt-get build-dep iceweasel:armhf| gives me: E: Unable to find a source package for iceweasel:armhf
<ogra_> mjrosenb, on debian ?
<ogra_> i dont think ubuntu ever had an iceweasle package
<mjrosenb> oh hey, this is #ubuntu-arm, not #debian-arm
<ogra_> :)
<mjrosenb> but, question still stands, since they are basically indistinguishable from apt's prespective.
<XorA> hrw: where does chromium-mali-opengles come from?
<mjrosenb> i'll attempt to reason it away by saying "i'm going to be running this on crubuntu/arm :-p"
<XorA> ok, I have ssh running on my chromebook, not a particularly good demo ;-)
 * ogra_ has unity running :)
<ogra_> not so pleasant though :)
<XorA> ogra_: how do I get X11 running, that would be a good start?
<ogra_> i just installed the armsoc xerver package
<ogra_> and then copied the EGL libs over
<ogra_> from the chromeos partition
<XorA> ah hrw guide references a non existent chromium-mali-opengles package
<XorA> I have armsoc installed
<ogra_> hmm, then X should start unaccelerated at least
<XorA> I just get a dead Xorg process, probably started by lightdm
<ogra_> http://paste.ubuntu.com/5617221/
<ogra_> my xorg.conf
<ogra_> see if that helps
<XorA> trying
<ogra_> i thought hrw had included a config snippet in the last package
<XorA> ahah that fixed it
<ogra_> i have never touched my setup after i had it working
<XorA> i see mouse cursor
<ogra_> yay
<XorA> thanks ogra_
<ogra_> :)
<XorA> how do I copy those magic libs then?
<ogra_> sudo mount /dev/mmcblk0p7 /mnt/
<ogra_> then search for libGLES
<ogra_> iirc p7 is chromeos
<XorA> hmm, that has made system unhappy
<ogra_> weird
<XorA> total lockup on that process
<XorA> very odd
<ogra_> probably i'm wrong wrt the partition
<ogra_> but it doesnt make my device choke
<XorA> getting nearer anyway :-D
<XorA> that mount command deffo makes things unhappy
<ogra_> hmm, bad
<ogra_> my install is based on the very first chrubuntu script ... might be quite different to what you have
<ogra_> i bought my chromebook the first week they cam eout
<XorA> I have chrbuntu 12.04 + hrws guide on upgrading, + fixes because that guide is wrong
<ogra_> yeah, there was no such guide back then :)
<XorA> guide is wrong enough to be a hinderance :-(
<ogra_> i used the chrubuntu script (the one which silly downloads the whole rootfs in 50M tarballs)
<ogra_> changed my sources.list to raring and dist upgraded
<XorA> well I just went into chromeos and copied the *GL* to ubuntu that way
<ogra_> and then slowly moved useful chromeos pieces over over time
<ogra_> like GLES stuff, flash etc
<XorA> at least I have a desktop now
<XorA> seem to be missing any test consoles though
<XorA> oh actually that will be because changing console crashes X
<hrw> there are many things wrong with chromebook
<ogra_> everything is fine here on mine
<ogra_> at least for what i use it
<XorA> hrw: many typos in your guide
<XorA> hrw: and a non existant package
<ogra_> better than a non existant typo ... hmm, no, not really
<hrw> XorA: opengles pacakge got removed due to lack of any useful licence for it
<XorA> ppa:chromebook-ppa should be ppa:chromebook-arm/ppa
<XorA> hrw: ah, some of the typos are not typos, they are wordpress messing up formatting
<XorA> /dev/mmcblk1p1 should bo /dev/mmcblk1p6
<hrw> ok, will fix some
<hrw> now have to go
<prpplague> hey folks, just fyi if you were a linuxdevices.com fan, a new embedded linux news site is up now as a replacement http://www.linuxgizmos.com
<ogra_> why did you have to rename ?
<prpplague> ogra_: linuxdevices.com was purchased as part of a sale from ziff-davis
<prpplague> ogra_: the new owners weren't interested in running the site
<prpplague> ogra_: so the original founder of linuxdevices.com has started a new site
<ogra_> ah, they wanted to keep the domain but not do anything with it ?
<XorA> ogra_: which kernel do you use?
<ogra_> XorA, the installed one that was on the device
<ogra_> i dont think the chrubuntu script updated it
<ogra_> just changed the default rootfs
<XorA> ogra_: hmm, Ill give that a try then, the one I installed from cromebook ppa seems rather broken
<hrw> XorA: fixed partition number and ppa name
<XorA> hrw: thats it for the typos then, the thing I thought was typo was wordpress hyphenating words :-D
<hrw> '_~)
<XorA> hrw: but if you copy n paste that big command the extra hyphens are not htere
<hrw> "vbutil_kernel --pack /tmp/kernel-to-boot-ubuntu --keyblock /usr/share/vboot/devkeys/kernel.keyblock --version 1 --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk --config CMDLINE_FILE --vmlinuz /boot/vmlinuz-3.4.0-5-chromebook --arch arm" one you mean?
<hrw> copied from http://marcin.juszkiewicz.com.pl/2013/02/16/how-to-update-chrubuntu-12-04-to-ubuntu-13-04/
<XorA> hrw: yeah, on screen it says --key-block
<hrw> ah.
<hrw> anyway - I never wrote good installation howto
<XorA> which messed with my head :-D
<XorA> hrw: now I know which is happening I can do an internal install now :-D
<hrw> :)
<hrw> XorA: there is one thing I regret from HK trip.
<hrw> XorA: I should waste some money on one of those chinese tablets.
<hrw> my omap4430 based archos g9 drives me mad... it is crazy how slow dual a9 can be ;D
 * hrw -> sleep
#ubuntu-arm 2013-03-16
 * Snark wonders how doctesting works
<Snark> the ptestlong target of the toplevel Makefile calls sage with the "--sagenb" option, which is described neither in -h nor in -advanced :-/
<omapian> Hi eveyone. Why is there no omap3 sgx support in recent Ubuntu?
<ogra_> because nobody stepped up to maintin it
<ogra_> omap3 stuff has not been maintained in years
<ogra_> (in ubuntu that is)
<omapian> ogra_: okay. That's kind of a let down... well, thanks for answering.
<ogra_> if someone supplies the needed bits and takes care, nobody will block indeed, patches accepted :)
<omapian> ogra_: no idea how to do that. I hope someone will find a Minute or two for that.
<XorA|gone> aaaaaah I see why suspend on chromeboox is impossible :-(
<Snark> XorA|gone, s/boox/book/ -- impossible sounds like a strong word
<XorA|gone> Snark: armsoc crashes on VT change, which makes suspend fail as it does a vt change when it restarts
<XorA|gone> Snark: switch to fbdev and it suspends again
<XorA|gone> now its just a pity closing the lid wakes it up :-D
<XorA|gone> ogra_: Chromebook running much better now, thanks for the help
#ubuntu-arm 2013-03-17
<tripelb> :p
<Ethernin> jeffb, hey man you're the one who made the bohdi image for the nexus7 right?
<Ethernin> bodhi i mean
<Snark> it is annoying: I wanted to see if it was possible to run ubuntu on the nexus 10, and I only see things about ubuntu tablet :-/
<darkfader> thats silly :/
<darkfader> Snark: i had looked at the same 1-2 months ago and it was mostly "different internals" than nexus7
<darkfader> err i have the quotes wrong
<darkfader> "different internals than nexus7"
<darkfader> nothing concise
<loaded247> hi]
#ubuntu-arm 2014-03-10
<awafaa> rsalveti: ping me know when you're up, please
<hrw> awafaa: your appearance at james bond theme evening was awesome
<infinity> awafaa: Stop hitting on my coworkers.
<awafaa> hrw: thanks, people complained there was too much hair and not enough heels, but it was a good laugh
<awafaa> infinity: jealous are we? you didnt seem to mind on wednesday ;)
<infinity> awafaa: I knew you'd come back to me, then.  Not so sure now.  rsalveti's a handsome man.
<awafaa> infinity: yeah, you snooze you loose :)
<awafaa> rsalveti: sorry to have bothered you. i've been adequetly serviced by infinity
<awafaa> oh wait, that really doesn't sound right!
<infinity> *cough*
<rsalveti> awafaa: hey
<awafaa> rsalveti: hey, i was going to ask you some questions but infinity has managed to fill me in
<rsalveti> alright :-)
<infinity> awafaa: I went from "servicing" you to "filling you in".  This isn't improving.
<awafaa> infinity: it's the natural progression of things ;)
<applepi> Hello all...  working on an ubuntu-arm rootfs made with debootstrap and I'm able to boot into it, however everything I try to run inside it, I get 'illegal instruction'
<applepi> I'm not sure why, I targeted armel, and when I did this with debootstrap to make a debian rootfs, it seems to work fine...
<infinity> applepi: If it's not an armv7 CPU, it won't work.
<infinity> applepi: Debian/armel is armv4t, Ubuntu/armel is armv7, which is likely your issue.
<infinity> (And Ubuntu/armel is also a dead product now, we stopped shipping it)
<applepi> infinity: Really?  Because my kernel is built for armv7..  and oddly it's my Debian build that works.
<applepi> infinity: however that's good to know.
<infinity> applepi: What CPU/board are you running on?
<applepi> imx6sl
<applepi> dev board
<applepi> infinity: well..  I tried with armhf..  didn't even make it through booting.  :/  the sd card reader for some reason seems to be failing during bootup..
<applepi> I'm seeing 'mmc0: no vqmmc regulator found' and then a ton of 'init: Failed to create pty - disabling logging for job', 'mountall: event failed'
<applepi> Any suggestions?
<infinity> applepi: None off the top of my head, though I have a sabrelite here that I need to find the time to fix up for trusty.
<infinity> So, it might magically start working soon. :P
<Valduare> wonder if we will ever see small arm computers with mini pcie slots for ssd instead of nand storage
<infinity> Valduare: Yup.
<Valduare> I have an mk808 right now that i've been playing with
<Valduare> dual core, 1.6 gig   8 gigs of nand and 1 gig of ddr3 ram
<Valduare> pretty snappy little device
#ubuntu-arm 2014-03-11
<applepi> Can anyone point me toward the kernel configuration that ubunutu armhf was built with?  I'm attempting to boot my freescale imx6sl-evk with an ubuntu armhf rootfs, but I can't seem to get all the way through.
<rbasak> applepi: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=tree;f=debian.master/config;hb=HEAD
<applepi> rbasak: thanks :)  ah, just noticed Thumb2..  I don't have that on in my kernel..  should I be able to get the imx6sl up and going with that on?
<rbasak> I have no idea, sorry. I just happened to have needed to dig into the kernel config before.
<applepi> ah okay, thanks.
<Valduare> anyone here have an mk808
<Valduare> or 802 or 802_a10s
<nuit123> I'm using Ubuntu (in reality, just the networking piece), none of the desktop stuff) on a PC and now want to shrink it all, preferably to a chip not a board.  Any embedded gurus in here?
<rbasak> !anyone
<ubot2`> A high percentage of the first questions asked in this channel start with "Does anyone/anybody..." Why not ask your next question (the real one) and find out? See also !details, !gq, and !poll.
<nuit123> :-)
<nuit123> i'm looking for a Linux and tiny computers (SoC/board) seasoned expert who can advise on the best way to get Linux networking running on the smallest and least expensive hardware.
<nuit123> !details
<ubot2`> Please give us full details. For example: "I have a problem with ..., I'm running Ubuntu version .... When I try to do ..., I get the following output: ..., but I expected it to do ..."
<nuit123> !gq
<ubot2`> Are you sure your question allows us to help you? Please read http://www.sabi.co.uk/Notes/linuxHelpAsk.html to understand how to ask a 'better' question.
<nuit123> !poll
<ubot2`> Usually, there is no single "best" application to perform a given task. It's up to you to choose, depending on your preferences, features you require, and other factors. Do NOT take polls in the channel.
<rbasak> nuit123: well, the most minimal Ubuntu you can get is Ubuntu Core. https://wiki.ubuntu.com/Core
<rbasak> nuit123: if you want to go smaller than that, then you could do just a kernel + busybox + whatever you need, but you'd be out of Ubuntu territory then.
<rbasak> Whichever way you go, you're generally expected to know what you're doing at this level.
<nuit123> i could use a guiding hand if anyone wishes to helpout.  I'm willing to compensate for a way out of the woods.
<rbasak> It sounds too involved for IRC to me. I'd say that you need a consultant or something. But you're welcome to see who else can help you here.
<nuit123> yes, consultant.
<trem> nuit123: you want to run a linux on an "embedded board" ? like pandaboard or smaller ?
<nuit123> whatever is least expensive.  solution only needs to support networking - the same components that are already in Ubuntu Desktop although likely much can be stripped out.
<ogra_> trem, except that a pandaboard is really way beyond "embedded" :)
<trem> embedded is not very very clear
<ogra_> (you can run a full ubuntu desktop on it relatively fluidly)
<trem> now, I see embedded board with more ram than my laptop ;)
<ogra_> well, i wouldnt call something "desktop class" being embedded
<trem> I agree, that's my question
<trem> on "small" board, I'll use buildroot + uboot + kernel + busybox
<ogra_> the beaglebone is sometihing i would call an embedded board
<ogra_> and the *durino's
<nuit123> sorry, if i added confusion.  My "breadboard" was Ubuntu and a laptop because it was easy to get my solution working.  Now trying to shrink the software and hardware footprint and cost...
<ogra_> well, the smallest Ubuntu install that rbasak pointed to above uses something like a 200MB disk footprint ... and there are not even networking pieces installed
<trem> too big
<ogra_> not sure ubuntu is actually a good choice for "embedded"
<trem> rasbetty pi should be smaller
<trem> I agree with ogra_ (again)
 * ogra_ disagrees about the RPi being an embedded board though :) 
<ogra_> its a PVR chip on a board ;)
<ogra_> (it would be my choice if i wanted to build a video recording box ... for everything else i would choce something else)
<ogra_> *choose
<nuit123> Something roughly like this?  http://hardkernel.com/main/products/prdt_info.php?g_code=G138745696275
<ogra_> wow
<ogra_> quad core and 2G ram
<ogra_> well, not actually what i would call embedded ... but you can definitely run an ubuntu rootfs on it
<hrw> and cheap
<hrw> and ubuntu can run on it
<ogra_> right
<ogra_> you dont want to hook it up to a battery i guess ?
<hrw> I have wandboard quad at desk. nice it is
<ogra_> sure sure
<ogra_> i just expect that people looking for embedded are actually after resource saving somehow :)
<trem> ogra_: RPi is cheap
<ogra_> trem, yeah, and awful for anything but video decoding
<trem> even network ?
<ogra_> its a USB attached NIC on a shared USB HUB ...
<ogra_> yes, specifically network
<hrw> ogra_: over shared usb hub connected to otg port
<trem> arg, not good, ip over usb ...
<hrw> r/pi is good for....
<hrw> nothing comes to mind. even not for door stopper or papers holder
<trem> http://liliputing.com/2013/04/99-mars-board-dev-board-features-freescale-i-mx6-dual-processor.html
<trem> may be this
<hrw> trem: with today's board you can set a list of requirements first and then select boards and start looking for shops
<trem> yes
<hrw> sata, 1 or 2 hdmi, usb 2 or 3 and how many
<trem> the wandboard seems to be nice
<hrw> fast of gigabit ethernet
<ogra_> hrw, if you can live with the blobs RPi is an awesome video decoder
<hrw> amount of iÂ²c, spi, gpio pins
<ogra_> the chip was designed to run settop boxes
 * hrw off
<trem> ogra_: the wandboard ?
<ogra_> trem, nope the RPi
<trem> oh ok
<ogra_> wandboard is definitely a nice board
<trem> ogra_: and for light embedded linux, buildroot + kernel + busybox ?
<ogra_> well, for that anything works :)
<nuit123> ogra and trem, thanks for your helpful comments earlier!
<e-Ra> Is it really a bad idea to install xserver or other window manager on ubuntu server?
<infinity> CONFIG_ARCH_MXC=y
<infinity> applepi: That's on in the Ubuntu config too.  I maintain that you didn't use our congfig. :P
<applepi> bugger...
<infinity> applepi: This is our current config http://lucifer.0c3.net/~adconrad/config-3.13.0-17-generic
<applepi> Okay, that's not what I was pointed to earlier..  let me take a look at this.
<infinity> applepi: If what you were pointed at was git, that doesn't really tell the whole sorty, since our config in git are split.
<applepi> ah
<applepi> yeah that would explain it
<infinity> applepi: So, you need to run a script to combine ubuntu.common, armhf.common, armhf.generic, etc...
<infinity> applepi: Anyhow, the above that I linked it the finished product, as shipped in the kernel package.
<infinity> applepi: And, in fact, no need to build your own kernel, if you want to extract ours from the deb and try it out.
<infinity> https://launchpadlibrarian.net/169034851/linux-image-3.13.0-17-generic_3.13.0-17.37_armhf.deb
<infinity> That even includes the imx6q-sabrelite.dtb device-tree, so I expect it's meant to work.
<infinity> I just need to test it and build d-i for it.
<applepi> ugh, thank you for this..  I am still a bit newbish at this..  I can build my own by trudging through git still loses me sometimes.
<infinity> applepi: Yeah, probably not much point in building your own, though, and I'd love ours tested. :P
<infinity> applepi: If you need to extract that kernel package to try to get at the image, you can do something like "dpkg-deb -x linux-image-blahblah.deb sometempdir/"
<infinity> And the kernel will be in sometempdir/boot/
<infinity> And the DTB in sometempdir/firmware/$ver/device-tree/
<infinity> Err, lib/firmware.
<infinity> And the modules in sometempdir/lib/modules/$ver/
#ubuntu-arm 2014-03-12
<applepi> infinity: around?  :)
<infinity> applepi: Sort of.  Pretty busy today.
<applepi> infinity: no worries I may have just tracked down the issue.  :)
<infinity> Oh?
<applepi> infinity: been trying out the kernel you passed me to test...  it still can't seem to boot but it appears modules.dep is missing but I think I should be able to generate it if I can chroot in with the right uname and depmod
<infinity> applepi: Yeah, we run depmod on install, it's not shipped.
<applepi> Yeah
<applepi> Makes it unhappy on boot D:
<applepi> No worries I think I can figure it out..  qemu-arm can take a uname as an arg...
<infinity> applepi: depmod takes a version argument.
<infinity> ie: 'depmod 3.13.0-17-generic'
<applepi> bloody hell..  -_-;
<applepi> I didn't realize.
<applepi> Thanks :)
#ubuntu-arm 2014-03-13
<olfa> hi, when i install ihe package ubuntu-omap4-extras on  pandaboardes and i reboot the carte nothing is displayed only the background of the screen empty no panel no icon, i can only use the mouse. and an error say" a problem occured while installing software , package:pvr-omap4-dkms
<olfa> any help please
<kayneo> hello, everyone. I want to install a ubuntu launcher for my android
<kayneo> so, where to download the ubuntu for android
<wookey> presumably python3-gi installs OK on Trusty arm64?
<wookey> it barfs on debian
<wookey> struct.error: 'l' format requires -2147483648 <= number <= 2147483647
#ubuntu-arm 2014-03-14
<infinity> wookey: If it's build-dep of a lot of things, so yeah, I'd say it installs okay.
<wookey> hmm. I wonder what's going on there. This error seems to come from a tightening up of struct conversion rules in python3
<wookey> I wonder if something got a wrong header somewhere.
<wookey> better check the debian/ubuntu delta
<infinity> Our pygobject delta is large, since we're using the experimental version.
<infinity> But what we had in saucy was older than sid, and it worked...
<wookey> yes this worked OK for me in saucy. It's cauing trouble in unstable
<awafaa_> infinity: have you had a chance to look at that doc i sent you last week?
<infinity> awafaa: Not yet, I've been going flat our here with other messes since I got home. :/
<infinity> s/our/out/
<awafaa> infinity: piss poor excuse, but OK âº
<infinity> awafaa: The dog ate my homework?
<awafaa> Sure, works for me
<reb``> Will Ubuntu 14.04 install on ARM Chromebooks with full disk encryption?
<infinity> The last part of that sentence makes some curious assumptions about the first part.
<infinity> We don't officially support installing to Chromebooks at all, you kinda need to hack that together yourself.
<reb``> Yes, Ubuntu is not officially supported on Chromebooks, but various people have managed to install it in various ways.
#ubuntu-arm 2014-03-15
<busybox_> I am trying to create a rootfs following the instructions at  -  https://wiki.ubuntu.com/ARM/RootfsFromScratch
<busybox_>  sudo ./rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 3G --seed ubuntu-desktop
<busybox_> command finishines with saying - I: Running on a i686 machine
<busybox_> I: Creating temporary qemu Image to be used as rootfs
<busybox_> I: Mounting temporary Image
<busybox_> where does it mount the temporary image? Should not it create a tarball? I can't find that
<busybox_> I am trying this for the first time
<busybox_> lets put it another way
<busybox_> how can I build a root fs on ubuntu 13.04 to use with qemu-arm
<busybox_> ?
<Valduare> hi guys got question, I got an mk802iiis device running ubuntu but the kernel apparently is configured to look in 3.0.8 dir in /lib/modules and the rootfs has 3.0.36 folder
<Valduare> can I do a symblink and reboot and all will work?
<Valduare> trying to get wifi found
<infinity> Erm, if the kernel is 3.0.8 and the modules you have are 3.0.36, you absolutely can't just symlink, no.
<infinity> You need modules that match your running kernel.
<infinity> Or a kernel that matches that rootfs.
<infinity> Pick one. :P
<Valduare> hmm
<Valduare> off to google heh
<infinity> Or, off to the people who provided you the kernel and rootfs.
<infinity> Since it wasn't us.
<Valduare> aye thats what I'm trying to do
<Valduare> any idea if ubuntu is planning to support all winner soc?
<Valduare> there's a lot of these little arm devices flooding the market
<ogra_> probably once they start supporting devicetree
<ogra_> (which they refuse to ... and which keeps them from getting their stuff into linux proper)
<infinity> ogra_: Not true, there's (finally) allwinner support landing upstream in a sane multiplatform way.
<ogra_> oh !
<infinity> Though, mostly too late for trusty's kernel, I believe.
<ogra_> so they finally saw the light ?
<ogra_> or is that a community effort
<infinity> I think the light might have been forced on them, but yes.
<ogra_> heh, cool
<infinity> I've not gone patch hunting myself, but I heard promising things at Connect.
<ogra_> i saw the deiscussions on the debian-arm ML ...
<Valduare> interesting
<ogra_> but there it didnt look like they would get to some final conclusion
<ogra_> and discussions with luke kenneth lehighton involved get a bit stressful over time
<infinity> Oh, he's a twit. :P
<ogra_> definitely
<Valduare> I'm in my hotel room right now got my mk device plugged into the hotel room tv trying to get its wifi up and running lol
<Valduare> hmm what do I type to get dmesg to run in the terminal 15 seconds after I hit enter
<infinity> Valduare: sleep 15 && dmesg
<Valduare> ty
#ubuntu-arm 2015-03-09
<flexiondotorg_> Hi. I'm the project lead for Ubuntu MATE.
<flexiondotorg_> An Ubuntu MATE community member has created a Raspberry Pi 2 port of Ubuntu MATE 15.04
<flexiondotorg_> I'd like to discuss how we might be able to make that official image to sit along side our i386, amd64 and powerpc versions.
<flexiondotorg_> Anyone here who can help with that?
<rbasak> flexiondotorg_: oh - #ubuntu-devel or #ubuntu-release might be a better place for that question. It doesn't really need any ARM specialism - just in image publication etc.
<ogra_> flexiondotorg_, first of all you will eed to get the bootloader packaged and into the archive ...
<ogra_> then you want to make sure our kernel works with the HW
<flexiondotorg_> ogra_, Thanks. Is that not the case considering the Snappy Core version?
<flexiondotorg_> If not, we know what is required for the Pi 2.
<ogra_> no, snappy is completely different
<ogra_> we dont have an official image for the RPi
<ogra_> snappy is designed in a way that you keep the HW bits separate from the rest of the system
<ogra_> which is why there is a device tarball for RPi around that you can combine with the generic bits using the ubuntu-device-flash tool
<ogra_> (i.e. we dont ship anything HW related in the snappy image)
<flexiondotorg_> ogra_, Understood. So, to recap.
<flexiondotorg_> 1. Package RPi2 boot loader in the official archive.
<flexiondotorg_> 2. Make sure the default kernel works, if not work with the kernel team to get the required changes made.
<ogra_> 2 might be just a devicetree file
<ogra_> if all Pi2 bits are mainline already at least
<flexiondotorg_> 3. Update ubuntu-cdimage to enable armhf for Ubuntu MATE.
<ogra_> if i was you i wouldnt build such an image but instead produce a preinstalled rootfs tarball in cdimage
<flexiondotorg_> ogra_, Thanks. That is a useful starting point.
<ogra_> and putr instructions up how to assemble a RPi install from that
<flexiondotorg_> ogra_, Good idea.
<ogra_> so people can use their own kernel/bootloader setup
<ogra_> arm people are usually knowledgeable enough to handle such things :)
<flexiondotorg_> ogra_, That is a really good idea. Because we want to target ODROID C1 too.
<flexiondotorg_> Thanks for the help.
<ogra_> http://people.canonical.com/~ogra/snappy/ btw ;)
<flexiondotorg_> ogra_, Thanks.
<ogra_> yeah, wont help you much i fear, but you could pick kernel and bootloader bits out of that tarball if needed
<flexiondotorg_> ogra_, Everything is useful right now.
<ogra_> i can imagine :)
#ubuntu-arm 2015-03-12
<LusoBlue> Anyone else running Ubuntu 14.10 / Linaro 15.01 on Raspberry Pi 2?
<LusoBlue> Anyone else running Ubuntu 14.10 / Linaro 15.01 on Raspberry Pi 2?
<daniele12457> hi guys
<daniele12457> can anyone explain me how does the arm architecture works?
<k1l_> daniele12457: what do you mean?
<daniele12457> i want to read the etm buffer :)
<daniele12457> etb buffer
<k1l_> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0242b/index.html   well, that is something to read
#ubuntu-arm 2016-03-16
<zzarr> hello! how do I turn the HDMI display to portrait on the Dragonboard 410c (Linaro)?
<ogra_> tried fbset ?
<zzarr> I will try that ogra_ thanks
<zzarr> have anyone managed to compile a qmake for aarch64?
<zzarr> if so, is there a schroot?
#ubuntu-arm 2016-03-19
<mijk> h
<mijk> hi
<mijk> is there a way to launch Android apps from Ubuntu ARM?
<mijk> hey, is there a way to launch Android applications from Ubuntu on an ARM system?
#ubuntu-arm 2017-03-13
<G33kDad> i'm trying to boot ubuntu core on my rpi 2. it doesn't seem to be working
<G33kDad> is this the right channel to get some help?
#ubuntu-arm 2017-03-14
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
#ubuntu-arm 2017-03-19
<femsheeple> hello
#ubuntu-arm 2018-03-12
<Strykar> I've installed the official Odroid Ubuntu image for the C2 and it stops responding after 20ish mins printing this to console - https://paste.ubuntu.com/p/XQc2V9HSN8/
#ubuntu-arm 2018-03-14
<eraserpencil> hi! how could I compile a package for arm if i have the source code?
<eraserpencil> hi?
#ubuntu-arm 2018-03-15
<emankcin> New to Pi.  I have the image on the miniSD. I have gotten boot to run until the color splash with video first starts, then a restart.  Looks like a boot loop.
<yjwxkx> THIS IS A FREENODE BREAKING NEWS ALERT!! Hitechcg AND opal ARE GOING AT IT RIGHT NOW WITH A LOT OF FIGHTING AND ARGUING WOW YOU DON'T WANT TO MISS THIS!! TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
<yjwxkx> kaxing dragan-s k1l NCommander ubot9 AceLan BenG83_ steev lool zzarr chrisccoulson ogra_ micahg y0sh dannf alai manjo rexxster PaulePanter doko guerby ptl Strykar rsalveti nashpa BenG83 persia moon127 ChunkzZ Freejack Heroih ColdKeyboard funnel popey lvrp16 awafaa flexiondotorg mariogrip robher ndec chihchun_afk nslu2-log wgrant zumbi_ tlbr amrith mrutland yofel Tm_T akaWolf rbasak niska ubuntulog Alesk13 fabo Jack87
#ubuntu-arm 2018-03-16
<ubuntuarm-user> Hi, I'd like to modify the ubuntu base rootfs tarball so that it contains the openssh server. What is the easiest way to do this?
<rbasak> Doing that is dangerous. You'll end up with cloned private host keys which is a security problem.
<rbasak> So you have to work around all of that, which is error-prone.
<rbasak> Better to use official images that include cloud-init.
<ubuntuarm-user> i see
<ubuntuarm-user> I didn't know that something like cloudinit exists. I'll have a look. thanks
#ubuntu-arm 2020-03-09
<ailion> Hi
<ailion> I need some help
<ailion> I'm able to build a bootable iso image for BIOS on x86 platform, the boot sector I passed as a parameter to mkisofs is "/isolinux/isolinux.bin".
<ailion> Now I'm working on a dual-socket arm64 server, which has UEFI only without legacy BIOS compatible mode supported.
<ailion> I found a document from Debian, which pass "-e boot/grub/efi.img" to mkisofs.
<ailion> https://wiki.debian.org/RepackBootableISO#arm64_release_9.4.0
<ailion> However, I can't find "boot/grub/efi.img" after installing ubuntu-18.04.4-server-arm64.iso on my working machine.
<ailion> Which package should I install to have this efi.img?
<ailion> BTW, I foud an efi.img at "debian-installer/build/tmp/cdrom_grub/grub_efi/efi.img" but I don't know if it's the corrent file since it's in a tmp dir.
#ubuntu-arm 2020-03-10
<qzio> also, it seems as if neither chromium nor firefox can handle u2f/fido/webauthn keys on ubuntu arm64.
<qzio> or is it just me?
<qzio> pamu2fcfg works as expected, and dmesg showes the keys as they should
#ubuntu-arm 2020-03-12
<rainmatter> how can I enable hardware acceleration on Raspberry Pi 4 running Ubuntu 19.10.1 x64?
<rainmatter> arm64, sorry
