#ubuntu-arm 2009-03-02
<NCommander> hey all
<EL> I still got the same problem when I run ubuntu-arm on QEMU
<EL> I press a key, then it output 'u'.
<EL> I had used newest QEMU-0.9.1+SVN20081112
<EL> My linux kernel is: vmlinuz-2.6.28-versatile
<EL> Any suggection? thanks
<EL> Sorry, I fix my problem by add "-k en-us" to qemu-system-arm command. :)
 * lool just got the pun with "sheeva"
 * lool is slow
<EL> ha
<EL> hi lool
<EL> what's the clock of sheeva?
<lool> EL: It's on the marvell page; 1.2 GHz
<EL> see
<EL> One Question: Is ubuntu-arm too fat to run on modern ARM chip?
<Stskeeps> i have ubuntu base system running on a nokia 770 .. :P (not with GNOME, though)
<EL> I means "ubuntu-desktop" on ARM
<EL> Another Question: what is biggest problem for ubuntu-desktop on ARM?
<suihkulokki> memory (RAM) consumption :P
<EL> Agree. Maybe, we need a ubuntu-desktop-lite.
<EL> So, is ubuntu-mid a better solution?
<lool> EL: It's lighter, but didn't receive much care in Ubuntu recently
<lool> EL: "modern" ARM chips as you say are quite fast and often come with a lot of memory; depends on what you're exactly targetting
<EL> but you said that sheeva is slow for running ubuntu-desktop
<EL> It has 1.2GHz clock!
<EL> I like arm-version netbook solution. fanless, low-cost, lower power-consuming
<suihkulokki> I don't think anyone said sheeva is too slow for ubuntu-desktop
 * lool didn't say that
<lool> EL: GNOME is decent on 800 MHz cores
<lool> With 512 MB of RAM though
<EL> ok, I may misunderstand.
<EL> Does ARMEL mean "ARM Little endian"?
<lool> Yes
<lool> Alebit the "arm" port was also le
<EL> thanks
<EL> If I need cross-compile for ARM on x86, where can I get a fine toolchain?
<ogra> EL, see the rootfs from scratch page in the topic
<ogra> use qemu
<EL> for compiling?
<ogra> for an environment in which you can develop, compile and test
<EL> I think so, but it's a little slow.
<ogra> what do you plan to develop ?
<ogra> kernel stuff or something more top level ?
<EL> kernel
<ogra> ah, right, for that a cross compiler is indeed a good choice, our prob is that many people ask for a cross compile toochain stuff for userspace development so my general asnwer is qemu ;)
<EL> got it
<ogra> in userspace you need a ton of dependencies first built for the cross toolchain, which we dont want to provide
<EL> So for a cross-compiler, do you have any suggection?
 * ogra looks for amitk's blog, he had a howto for a kernel toolchain 
<ogra> (and i belive lool works on something more integrated but i dont know the status)
<lool> status is I made good progress to pass the point where I was stuck
<lool> But I keep quiet about it because I don't want to set high expectations from other people
<EL> :)
<EL> good policy!
<lool> I likely found the reason of the newlib and glibc FTBFS-es I was getting and am likely to have something working soon
 * lool &
<ogra> EL, http://idlethread.blogspot.com/2009/01/recipe-of-day-cross-compiling-armel.html
<EL> thanks
<lool> Right, the codesourcery toolchain works right now
<lool> Or the emdebian one for debian
<ogra> yeah
<EL> I think there are many toolchain for arm.
<EL> So I need a suggected one, ha.
<EL> In other words, which one is better?
<ogra> the tested one usually ;)
<ogra> amitk is our current arm kernel maintainer in ubuntu, he should know what he recomments :)
<ogra> so just follow his howto and you should be fine for now
<EL> ya, It's what I need.
<EL> thank you very much!
<EL> :)
<ogra> :)
<lool> ogra: Did you see #336770
<lool> I guess so since you're subscribed
<lool> ogra: Could you debug and see whether it's a hwclock, installer, or kernel issue?  or perhaps it's out of RAM at this stage again?
<ogra> bug 336770
<lool> No bot
<ogra> grr
<lool> Not sure I terribly like having bugs subscribed to canonical-arm-dev
<ogra> ah, andy just subscribed me
<ogra> unsubscribe it, i'll assign to me, i meant to look into that anyway
<ogra> he sent a mail already
<lool> Thanks
<ogra> i dont see flash-kernel in the d-i environment, i suspect it has to do wit it
<ogra> it cant run out of ram at that point
<ogra> as soon as partitioning is done there is swap
<ogra> partman moans loudly if you dont use swap
<lool> Good point
<Tscheesy> ogra: still the same building error - hal won't restart in latest Kubuntu-Root-fs
<ogra> Tscheesy, thats very very weird, i have built multiple ubuntu-desktop, xubuntu-desktop and commandline rootfses since
<ogra> and never saw that error
<Tscheesy> it's perhaps because KDE4.2 is not Ready Yet?
<Tscheesy> is there a possibiltity to build the Image anyway and try to repair it later?
<ogra> build a commandline image
<ogra> then install kubuntu-desktop on the running system
<Tscheesy> good idea.. is this ubuntu-minimal ?
<ogra> yep
<Tscheesy> thanks.. this way i get into qemu also..
<lool> NCommander, ogra: new kexec-tools merged
<ogra> yippie
<ogra> that took a while :)
<NCommander> yay
#ubuntu-arm 2009-03-03
<rbelem> hi ogra
<rbelem> i released a python module called smaps-plotter
<rbelem> http://gitorious.org/projects/smaps-plotter
<rbelem> it gives memory consumption information
<rbelem> related to a specific process
<rbelem> using the smaps from linux kernel
<lool> Is there a Qemu machine which can run RedBoot or APEX?
<ogra> lool, i doubt that
<ogra> there are ways to use u-boot in qemu
<lool> http://www.mail-archive.com/qemu-devel@nongnu.org/msg09189.html
<lool> Unfortunately we don't have a packaged mipsel BIOS
<ogra> heh
<ogra> hmm
<ogra> http://sources.redhat.com/ml/ecos-discuss/2008-03/msg00092.html
<lool> Does U-Boot support FIS / RedBoot partitions?
<ogra> i dont think so
<ogra> but then i never used it from something else than SD ...
<NCommander> lool, it might, I haven't used it that much
 * NCommander is looking at what is necessary to package ecos
<NCommander> at least just the source bits
<lool> amitk: Is there a reason why the redboot kernel module only works with mtd devices?  If I plug a RedBoot formatted SD card with the module loaded I get "sdd: unknown partition table"
<amitk> lool: there are several redboot related configs in advanced MTD config
<amitk> related to partitioning, block sizes, etc.
#ubuntu-arm 2009-03-04
<[insert_name_her> so do i have to build this myself or what?
<lool> hahaha gentoo on freerunner
<lool> "This mean you can cross- and natively compile a basic system..."
<lool> Native compile   \o/
<ogra> lool, well, isnt OE the same as gentoo, only smaller ?
<sof> Hi
<sof> Does anyone know of a calibration tool that works on ARM?
#ubuntu-arm 2009-03-05
<goshawk> hi
<goshawk> i was looking at the armel support
<goshawk> what are the differencies between ixp4xx and versatile images?
<EL> goshawk: I think you can check their config file in kernel.
<EL> For original kernel source, they are in arch/arm/configs
<EL> For debian packed source, they are in debian/config/armel
<EL> Question: Is there any way to compile one kernel but all kinds of them by debuild with ubuntu's kerenl source pack?
<goshawk> thx
<EL> :)
<goshawk> but
<goshawk> http://cdimage.ubuntu.com/netboot/jaunty/alpha-5/
<goshawk> you don't have any config file here
<goshawk> there are just netinst
<goshawk> and you don't know which one to get
<EL> I means you need a kernel source code to check what's difference bewteen them.
<goshawk> no sources in this case :)
<EL> git clone git://zinc.ubuntu.com/ubuntu/ubuntu-jaunty.git
<EL> Q2: How to get source code by git but .git dir ? like cvs release
<goshawk> i don't know, i don't like git, i use hg :) i'm installing it right now
<goshawk> what? 990000 objects?
<goshawk> what am i downloading?
<goshawk> i've to go
<goshawk> EL: thanks for you help :)
<EL> Q3: Is ubuntu 0904 support EXT4 when installing?
<amitk> EL: yes, it support ext4 as an _option_, not default
<EL> see, thanks :)
<EL> I got problem when I change QEMU's -m option to more ram size
<EL> QEMU will show nothing.
<EL> a workable ram size setting is 256M
<EL> It's too small to run ubuntu-desktop image.
<EL> Any suggection?
<amitk> 256M should be enough, seems to work for me for versatile images
<EL> 384M, 512M fail. I also added kernel parameter "mem=MYRAM_SIZE".
<EL> I can see the login screen.
<EL> but I can't login successfully
<EL> By the way, I ran my ubuntu on VMWare on WinXP. :p
<EL> Basically, I think it should be ok, when I changed ram-size. What's wrong????
<amitk> can't say
<EL> ok :)
<amitk> I use this cmdline: qemu-system-arm \ -M versatilepb \ -kernel $KERNEL \ -hda jaunty-armel.img \ -append "root=/dev/sda rw console=ttyAMA0,115200n8" \ -m 256M -smb /share \ -serial  mon:telnet::4446,server,nowait
<EL> Another question, How to use git to get source but .git like CVS release?
<EL> my cmdline: qemu-system-arm -k en-us -M versatilepb -kernel ./vmlinuz-2.6.28-versatile -hda ud.img -m 256M -append "root=/dev/sda rw"
<amitk> EL: I don't follow the question. you can use 'git clone <git repo>'
<EL> I see
<EL> "git clone" will get source + git's control data.
<EL> but I just want source.
<EL> Maybe git didn't implement the function I want. :p
<amitk> i guess. Just clone and then delete .git
<EL> Baically, I want to download the source quickly.
<EL> anyway, thank you.
<EL> amitk: Do you know how to build single kernel image by debuild with ubuntu's source pack
<amitk> EL: debian/rules binary-versatile inside Qemu
<amitk> replace versatile by the flavour you want
<EL> Is it possible to build but pack them to deb?
<amitk> EL: above commaned will do that
<EL> see
<suihkulokki> vnc4 -dep-wait appears to be incorrect in ubuntu/armel
<EL> I can login ubuntu-desktop with my 256M ram, when I wait more time with bigger patience. :)
<EL> It's slow~
<EL> :)
<lool> suihkulokki: Thanks, gave it back
<lool> suihkulokki: Hmm it failed to build in the same way and has the dep wait again
<lool> I can't find mesa-swx11-source in my packages, it seems it was dropped a while ago
<lool> It's not in intrepid and jaunty
<suihkulokki> I didn't say giving back is the proper fix :P
<suihkulokki> lool: as you noticed, dep-wait is incorrect as there is no mesa-swx11-source
<lool> suihkulokki: Well there's a bdep on it
<lool> For some reason it was dropped from mesa
<lool> Right, it was dropped in experimental which we pulled
<EL> ARM's versatile don't support more than 256mb memory.
<EL> Someone had make a patch: http://qemu-forum.ipi.fi/viewtopic.php?f=20&t=4818&sid=f4a881881e7a1f5ef9f64a50188a24da
<EL> Is there any other arm kernel that can support more RAM?
<EL> qemu-0.10.0 is released today!
<lool> suihkulokki: Needs a merge from Debian; vnc4 doesn't bdep on this -source in Debian
<lool> suihkulokki: bug #338148
 * lool slaps bugbot
#ubuntu-arm 2009-03-06
 * Stskeeps yawns
<Stskeeps> persia: u-m patches for hildon desktop seem to apply fairly cleanly on top of latest h-d release btw
<persia> Stskeeps, Cool.  Ubuntu passed FeatureFreeze, so we avoid updating to the new upstreams between now and release, but for the next cycle, that ought make the merge go smoothly.
<Stskeeps> yeah, was just informing :)
<persia> How is your effort with upstream going?  Are your patches getting merged?
<Stskeeps> when it comes to hildon-desktop (the old UI) they've pretty much put that codebase in our hands, their new clutter-based hildon-desktop is what they're focusing on now
<Stskeeps> where desktop and home area is seperated
<persia> In that case, I'd encourage you to review the u-m patches, and accept anything you think is worthwhile.  Be nice to drop the distro-specific patches if possible.
<Stskeeps> *nod* we have merged them actually, and working a bit to see what we can make of them
<Stskeeps> been playing a bit with marquee :)
<persia> Cool!
<Stskeeps> we have a rather insane artwork guy so we're trying to implement some of his themes and ideas
<Stskeeps> http://tabletui.wordpress.com/2009/02/18/mer-ui-scalability/
<persia> Stskeeps, Sorry.  I was distracted.  So you're looking at scaling from 240x320 through to 1600x1200?
<persia> Or just 480x640 through 1600x1200?
<Stskeeps> for instance, but this was just a blog article based on a challenge to employ hildon-like UIs on smaller screens and bigger screens :)
<Stskeeps> so he made some mockups
<persia> Well, it's very promising.
<ian_brasil> mer looks like unr
<persia> ian_brasil, Kinda, although the underlying components are closer to Ubuntu MID
#ubuntu-arm 2009-03-08
<rbelem> hi all
<rbelem> which package caching is recommended? approx, apt-cacher, apt-cacher-ng?
<ffbb> i have used apt-cacher with success, it works never have bothered to try any other
<rbelem> thanks ffbb. I have been using apt-cacher too. I got some little problems, but nothing that annoys me so much. But is it the better option?
<rbelem> s/better/best
<ffbb> can't know, only one i have used, maybe some one else will (maybe in other place than this)
<rbelem> ffbb, i asked here because of the ogra 's script
<rbelem> ffbb, it downloads all the packages from ports.u.c
<ffbb> ok, ahem ahem im just random guy who saw a nice looking name
<rbelem> ffbb, and my internet connection is not so fast
<rbelem> :-)
<rbelem> ian_brasil_, throw away your damn wireless router
<ian_brasil_> rbelem: there was a power cut (another one)
<rbelem> ian_brasil_, damn manaus energia
<ian_brasil_> right, these things are sent to test us
<ian_brasil_> rbelem: did you get the system to boot on the beagle?
<rbelem> ian_brasil_, yep ;-)
<ian_brasil_> nice.it boots into what desktop?..xfce?
<ian_brasil_> or just into ubuntu-minimal?
<rbelem> ian_brasil_, xfce for now. I'm trying to install ubuntu-desktop now, but my internet connection is very slow today
<ian_brasil_> I was thinking of doing a theme for it so if you install MID we can use the one I already did..what do you think?
<rbelem> ian_brasil_, xfce for now. I'm trying to install ubuntu-desktop now, but my internet connection is very slow today
<rbelem> ian_brasil_, sounds nice
<ian_brasil_> or maybe just leave xfce and i use this ->
<ian_brasil_> How to make a GTK theme that uses multiple theme engines
<ian_brasil_> http://arstechnica.com/open-source/news/2007/08/how-to-make-a-gtk-theme-that-uses-multiple-theme-engines.ars
<ian_brasil_> this might be more useful
<rbelem> ian_brasil_, cool!
<ian_brasil_> cool so if you have it booting into xfce i will do the the theme
<rbelem> ian_brasil_, nice! I will install ubuntu-desktop on another sd card
<ian_brasil_> ok
#ubuntu-arm 2010-03-08
<persia> lool: Needs work on options to handle both --arch powerpc and --arch=powerpc, but looks lovely otherwise.
<persia> Ugh.  No it doesn't.  Looks bug-for-bug compatible with debootstrap :(
<persia> Anyway, you shipped it, and it looks good, and I'll make the tools use it.
<persia> ( well, unless system_arch == amd64 && deb_arch == i386 | lpia )
<aaron> morning all
<aaron> i'm coming again
<aaron_liuj> how to use the qemu in the rootstock
<persia> You'll have to wait at least 5 hours for good rootstock support.
<tkmedia> hi guys i dont see the mini2440 as being a supported board is possible and just untested ?
 * persia tries to figure out what a "mini2440" is
<persia> tkmedia: It might be able to run Jaunty, but nothing newer.
<persia> I'd recommend using Debian on that platform.
<persia> (assuming we're talking about a board with a Samsung S3C2440A ARM920T )
<tkmedia> yes thankyou
<persia> Glad to help.  If you decide to run Jaunty, the install may be a bit tricky, but ought work.
<tkmedia> intrepid actually would be nice
<persia> If you decide to run Debian, the install may be a bit tricky, but you should have continued support for longer (Jaunty runs out of support in October).
<persia> Intrepid wasn't compiled for armel.
<tkmedia> k
<tkmedia> whats the best way to try jaubty
<tkmedia> juanty
<persia> Do you have a working 2.6.28 or newer kernel for the board?
<tkmedia> 2.6.29
<persia> That ought work.
<persia> Do you have a local Ubuntu install from which to prep stuff?
<persia> (if so, which release?)
<tkmedia> i have severla vm's
<tkmedia> ones a 0910
<persia> OK.  So the easiest way to get a rootfs is probably to run rootstock in the 9.10 environment.
<tkmedia> yep did that
<persia> And you created a jaunty rootfs?
<tkmedia> hmm let me chk
<tkmedia> i used the example
<tkmedia> with minal lxde
<persia> Which example?
<tkmedia> top
<persia> From which page?
<tkmedia> sec
<tkmedia> sudo rootstock \
<tkmedia>         --fqdn myhostname \
<tkmedia>         --login ubuntu \
<tkmedia>         --password temppwd \
<tkmedia>         --imagesize 2G \
<tkmedia>         --seed xubuntu-desktop
<tkmedia> but changed seed
<tkmedia> to lxde
<persia> Right.
<tkmedia> ,gdm
<tkmedia> so that should work with the .29 kernel right?
<persia> Yes, but.
<persia> You want to add --dist jaunty
<tkmedia> kernel panic
<persia> The default is --dist karmic
<tkmedia> ahhh
<persia> And that will generate binaries that include instructions not supported on your chip.
<tkmedia> ok cool
<persia> So try again, and if that doesn't work, please ask again.
<tkmedia> so thats why i got kernel panic ?
<persia> I'm not sure, but possibly.  How did you construct your kernel?
<persia> Are you sure your kernel works?
<tkmedia> yes
<tkmedia> let mtry with dist-juanty
<persia> If you're sure the kernel works, then yeah, I'd blame the rootfs, especially if I expected the rootfs to generate instructions the processor can't handle.
<persia> "jaunty"
<tkmedia> and will be back if any more questions
<tkmedia> thanks
<persia> Good luck!
<tkmedia> so just -dist jaunty on the bottom
<tkmedia> added
<DanaG> hmm, weird thing about the rcn-ee images: the ubuntu username isn't uid 1000.
<DanaG> same for GID: not 1000.
<StevenK> DanaG: It isn't on the Live CD either, since that would conflict with installed systems
<StevenK> (And then you could potientally read other users files)
<DanaG> Though, with livecd, you can read them anyway, as root.
<DanaG> And the UID was like 1002 (which still could collide), and the image was an installed system.
<StevenK> Right, but that falls under "You have physical access, so ..."
<DanaG> Oh, and the UID of things like "fuse" were different too.
<DanaG> I fiddled with the things a bit, and made them match better (along with finding files that were owned by corresponding old UID, and chowning them.
<gevz> hello
<gevz> can somebody help me?
<DanaG> go ahead and ask the issue itself, instead of just asking if anyone's around.  =Ã¾
<gevz> ok, I have PDA Asus A363 can I install ubuntu on this device?
<DanaG> hmm, you'd have to find out more about what the chip is, for one.
<gevz> one moment
<gevz> processor type - Intel XScale PXA272 416 MHz
<DanaG> weird, I see nothing about "asus a363" on the internet.
<DanaG> er, not "nothing", but not too much.
<gevz> ROM 128 Mb, RAM 64 Mb
<DanaG> 64 megs RAM is tiny.
<DanaG> http://vip.asus.com/forum/view.aspx?id=20070507004052843&board_id=6&model=MyPal+A636&SLanguage=en-us&page=2
<gevz> :) I don`t like a Windows
<gevz> I want ubuntu ;)
<persia> gevz: OK.  What device do you have?
<gevz> A363
<persia> ASUS MyPal A363?
<gevz> yes
<persia> OK.  According to http://www.handhelds.org/moin/moin.cgi/MyPal you should be able to run linux
<persia> Or maybe not
 * persia looks harder
<persia> Really a A363 and not a A636>
<persia> s/>/?/
<persia> I can't find any information about the A363, unfortunately.
<persia> The A626 can run Linux, but only Ubuntu 9.04 and nothing newer.
<persia> The resolution is also low enough the experience may leave something to be desired.
<persia> I'd recommend Debian for such a device.
<gevz> oh...  excuse me, I mistake
<gevz> A636
<persia> Which is the mistake?
<persia> Ah, that's better :)
<gevz> not A363
<persia> But yeah, for the A636 you can run Jaunty if you hack it.
<gevz> how i can do it?
<persia> I'd recommend starting from http://www.handhelds.org/moin/moin.cgi/A636
<persia> Once you have figured out how to install linux, installing Debian or Ubuntu becomes easier.
<gevz> ok, I do not quite understand where I start
<gevz> this link to list of hardware, but I can`t understand how to install linux?
<persia> For devices of that class, one usually has to construct a replacement firmware and proceed with the "firmware upgrade" procedure.
<persia> I recommend searching for available documentation carefully, as there is a risk you can make the device unbootable.
<persia> I don't see any good guides from a quick search myself.
<gevz> ok, please help me
<gevz> I have compiled a list of equipment, what next?
<persia> I'm really not sure how to help, and don't want to give advice that will make your device useless.
<persia> The next step is to understand how the device boots.
<persia> Once you have that, compile a customised kernel, and get the device to boot that kernel.
<persia> Once you have that, you can start considering what you want for a filesystem.
<persia> But the first two steps are big ones.
<gevz> What image do I download ubuntu?
<persia> There exists no image of Ubuntu that will work on your hardware.
<persia> You can potentially construct something that works, but it's non-trivial.
<gevz> ok, thanx
<Laibsch> I ran "sudo ~/bin/qemu-debootstrap --arch=armel lucid lucid-armel-chroot http://rie:3142/ports.ubuntu.com/ubuntu-ports", but the chroot sources.list file does not contain any entries for package sources.
<Laibsch> Is that to be expected?
<persia> Yes.
<Laibsch> hm
<Laibsch> please explain
<Laibsch> I kind of expected the file to be populated, obviously.
<persia> I don't believe debootstrap automatically populates that.
<persia> So this is expected behaviour.
<Laibsch> let's rephrase the question
<persia> From your ability to run that command, I presume you're using lucid.
<Laibsch> Shouldn't debootstrap populate the file?
<persia> No.
<Laibsch> why not?
<Laibsch> I run lucid, yes
<persia> So, if you want to create a chroot for use, I'll recommend you use `mk-sbuild --arch=armel lucid`
<persia> This will work, populate everything, and give you a summary of ways to use the chroot.
<Laibsch> lool: asked me to test his scripts
<persia> Oh, if that's what your're doing, then you're doing it right.
<Laibsch> and I don't mind a few rough edges here or there
<Laibsch> why do you think debootstrap ought not to populate sources.list?
<persia> because there's extensive logic in mk-sbuild to populate it after the debootstrap run.
<Laibsch> gevz: you may also have a look at openembedded
<gevz> what this?
<Laibsch> gevz: google should tell you
<gevz> I have ban on google ;)
<persia> or any other search tool, really.
<persia> Then use something else :)
<lool> Laibsch: morning
<Laibsch> gevz: OE is very well suited for your problem of getting a kernel compiled
<Laibsch> lool: good morning
<persia> OE is also well suited to that class of device.
<Laibsch> probably
 * Laibsch hopes to lower the bar for ubuntu-arm eventually
<Laibsch> But I fully support the decision to focus on more powerful devices first
<persia> Laibsch: Not first: only.  We expect the market to catch up with us by the time we're sorted.
<Laibsch> yes, I was afraid that may be the case
<Laibsch> There ain't nobody there to tell me I can't try, though ;-)
<Laibsch> Speaking of which
<lool> persia: (from this night) ARM920T + jaunty isn't going to work I'm afraid
<Laibsch> Now that I have my armv7l chroot, how would I go about trying to compile armv5te software?
<Laibsch> what knobs do I need to fiddle with?
<persia> lool: No?  Why not.
<persia> Laibsch: You need to change the compiler defaults.
<lool> Laibsch: debootstrap is now expected to create a binary sources.list, but most people don't need source entries, so it defaults to disabled for these
<lool> Laibsch: sbuild usually pulls the source by its own means IIRC
<lool> persia: ARM920T is v4
<persia> lool: Ah.  So it needs to be ARM11+ ?
<persia> I thought it was ARM9+
<lool> I think some ARM9xxs are v5, but rare
<lool> Best to check the wikipedia page
<persia> That makes sense.  Still, I think anyone with older hardware should be running Debian anyway.
<lool> yes
<persia> It's frustrating to get stuck not being able to upgrade.
<persia> Anyway, sbuild doesn't do anything special with sources.list.  It just presumes that one exists in the chroot.
<persia> mk-sbuild populates one based on the arguments it gets passed.
<Laibsch> persia: where are those changed?
<persia> Laibsch: Which?
<Laibsch> the compiler defaults
<Laibsch> so that I can compile for armv5te
<persia> No idea.  I'd guess in the gcc package.
<Laibsch> lool: ?
<Laibsch> I guess the question can be put another way
<Laibsch> who changed what where to specify that lucid is armv7l?
<Laibsch> I'll just turn that back locally ;-)
<lool> Laibsch: gcc-4.4 package
<lool> we configure it with the defaults
<lool> Laibsch: I'm not sure you realize how long and complex and heavy that's going to be
<lool> It's not impossible, but building gcc-4.4 takes days espcially under qemu or older v5 hardware
<Laibsch> probably
<lool> Then you need to bootstrap everything such as eglibc, binutils etc.
<Laibsch> I don't mind days of compilation
<lool> Laibsch: You intend to build on v5 hardware?
<Laibsch> When I started with OE my machine was seriously underpowered (it kind of always was)
<Laibsch> It took about a week to build the toolchain for me
<Laibsch> and things broke often, so it may have been a month before I had anything working
<persia> You should expect a similar amount of pain.
<Laibsch> not a big problem
<Laibsch> especially since I can always use OE-compiled software
<Laibsch> But I want to move slowly away
<ynezz> uh?
<Laibsch> I think native compilation makes more sense
<lool> Laibsch: If you intend to build on v5 hardware, the easiest path for you (in terms of man hours) is probably to build the Ubuntu toolchain source packages after changing their defaults inside a Debian armel chroot
<ynezz> Laibsch: tired of OE? :p
<Laibsch> ynezz: yes
<Laibsch> but basically I understood that OE is not the right tool going into the future
<Laibsch> for me
<Laibsch> I'm looking more for a desktop experience on the devices I have
<ynezz> isn't it more about koen?
<Laibsch> Openembedded is of course, more embedded
<Laibsch> yes and no
<ynezz> ok
<Laibsch> I sat down and thought about if OE gives me what I need
<Laibsch> and if it's going in the direction I want it to go
<Laibsch> I've been with OE for 5 years and I'd say OE has never managed to put out anything usable for end-users
<Laibsch> I don't see that changing and I'm more of an end-user
<Laibsch> My hope is ubuntu-arm/debian-arm will eventually be able to output something usable for the ordinary user
<tkmedia> [02:45] <lool> persia: (from this night) ARM920T + jaunty isn't going to work I'm afraid
<persia> tkmedia: Sorry about that.  My mistake.
<tkmedia> hmm looks like troouble
<tkmedia> np
<tkmedia> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
<persia> tkmedia: Should be able to run Debian, I'd think.
<tkmedia> k
<ynezz> Laibsch: I've started using ubuntu for the same reason, for headless boards with 32MB RAM is OE the best...
<gevz> Congratulation of all women in this chatroom with 8 March!!!
<gevz> bye
<tkmedia> how can you tell which ver arm the device will run
<persia> http://en.wikipedia.org/wiki/ARM_architecture gives some useful guidance
<Laibsch> ynezz: yes, I agree that for the seriously low-powered devices and embedded devices, OE still makes a lot of sense.  But that's not necessarily my area of interest.  I hope I can lower the bar enough so that the spitz becomes usable.  Otherwise, I'll have to wait for some sexy hardware (the Palm Pre might be something I like)
<persia> cooloney: Do you happen to know if our kernels do anything with XN ?
<lool> tkmedia: This is not related to jaunty thouhg
<lool> tkmedia: a binary incomptibility would show up as a sigill, like init being killed
<tkmedia> ok what is a good dev board .... i like the beagle boards but want a 7" lcd like the samsung
<persia> tkmedia: DO you need 7"?  The NetWalker has 5" and is a complete netbook to boot.
<tkmedia> prefer a little larger but will look into it thanks
<persia> You could also get one of the 7" USB displays.  As long as you get one that uses DisplayLink it ought to work with lucid+
<persia> (or if it doesn't, complain to me about it, and I'll try to fix that)
<ynezz> tkmedia: in month or so, there should be LCD+Touchscreen avialable for BB from Tincantools
<cooloney> persia: sorry, have no idea about that? what's XN? for fsl-imx51?
<tkmedia> yes I want something that could be wall mounted
<Laibsch> tkmedia: Always Innovating Touchbook may be something to check out
<persia> cooloney: According to the ARM wikipedia page, XN is a technology available in newer ARM cores that it similar to NX for x86.  I'd like to see us enable that if we can.
<persia> Laibsch: Have they solved the shipment delay issue?
<Laibsch> no idea
<Laibsch> I was just visiting their homepage this minute
<Laibsch> which is why I mentioned it
<Laibsch> what backlog do they have?
<tkmedia> interesting
<tkmedia> nice form factor
<persia> Laibsch: I heard it took a couple months to get delivered.  I'd be glad to be wrong.
<DanaG> ynezz: I believe specialcomp.com also has some sort of touchscreen, though probably low-res.
<Laibsch> When I was shopping around for a new netbook last month I had a brief look at it, but was disappointed by 512MB RAM only.  So, I went for a pinetrail atom instead :-P  I'm very happy so far.
<ynezz> DanaG: that show dog board from tincantools should have 800x480 for price about $149
<ynezz> DanaG: 7"
<ynezz> forget to mention that
<DanaG> what's the difference between zippy and zippy2?
<persia> ynezz: Which driverdoes it use?
<DanaG> I see no LCD at tincantools.
<ynezz> persia: dunno :) ask prpplague on #beagle
<DanaG> oh yeah, I used these kernels: http://rcn-ee.net/deb/kernel/beagle/
<DanaG> ah, 10/100 in zippy2.
<ynezz> DanaG: it should be available in month or so
<persia> ynezz: Oh, it's a special Beagle expansion?
 * persia was hoping for something generic
<cooloney> persia: ok, i see, just a quick digging
<persia> cooloney: If you can get that to work, the security team will love you :)
<cooloney> it is available since ARMv6
<persia> Right, but I don't think we ever turned it on.
<ynezz> persia: yes, beagle related
<cooloney> #define PMD_SECT_XN             (1 << 4)        /* v6 */
<cooloney> persia: but i am not sure how to use it.
<cooloney> persia: need some time to take a look
<lool> persia: I think Kees had a look and flipped a logic bug in arm code
<lool> So I actually think it's working and enabled
<persia> lool: Really?  That's different than what I last heard, but I would be glad to have missed something.
<persia> cooloney: Cool.  Maybe check with kees: if lool is right, nothing to do.
<lool> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/364358 http://www.outflux.net/blog/archives/2009/11/24/missing-kernel-features-in-arm/
<ubot4> Launchpad bug 364358 in linux (Ubuntu Jaunty) (and 1 other project) "ARM: image is running with READ_IMPLIES_EXEC (affects: 1) (dups: 1)" [Undecided,Fix released]
<lool> cooloney: ^
<lool> So I'm pretty XN works now
<persia> Cool!
<lool> +sure
<persia> I caught the original blog post, but not the followup.
<DanaG> what does "ASLR" stand for?
<persia> http://en.wikipedia.org/wiki/Address_space_layout_randomization
<persia> Makes it harder to take advantage of buffer overflow exploits, poke exploits, etc.
<DanaG> ah.
<DanaG> anyway, bedtime now.  =Ã¾
<cooloney> lool: thanks,
<lool> cooloney: Did you manage to look into the kexec problem?
<cooloney> and from the code arch/arm/mm/mmu.c
<cooloney> lool: yeah, we found a way in imx51 and mvl-dove
<cooloney> i prepared a kernel package for versatile alreayd
<cooloney> and going to test it now
<cooloney> if you wanna test, please take a look at this bug
<cooloney> https://bugs.launchpad.net/adana/+bug/517841
<ubot4> cooloney: Error: Bug #517841 is private.
<cooloney> persia: XN bit is enabled when arch >= ARMv7
<lool> http://kernel.ubuntu.com/git?p=roc/ubuntu-lucid.git;a=shortlog;h=refs/heads/kexec-versatile is the branch
<lool> http://people.canonical.com/~roc/kernel/kexec/ has the binary kernels
<cooloney> yeah,
<cooloney> but we still have to patch the kexec-tools
<persia> cooloney: That's fine.
<lool> Only for initramfs support though
<cooloney> lool: do you mean another issue about initramfs on versatile?
<cooloney> lool: i saw your config patch was merged
<lool> cooloney: Didn't yet try with
<lool> my patch in
<lool> cooloney: But we should really fix the initramfs issue
<lool> perhaps it's a similar problem actually!
<lool> perhaps our kernel is too big!
<lool> I didn't think of that
<cooloney> yeah, the issue is very similar, without patching the kexec-tools to increase the size
<cooloney> we can not kexec reboot the kernel
<lool> cooloney: Question
<cooloney> it looks like the similar in qemu
<lool> cooloney: the kernel knows where it's loaded, how big it is, and where the initramfs is supposed to me
<lool> cooloney: Don't you think the kernel should test whether kernel start + kernel size < initramfs start?
<cooloney> lool: normally, the bootloader should take care of that, such as uboot or qemu
<lool> cooloney: Don't you think it's a good idea to have such a sanity check to avoid debugging kexec like we did?
<lool> cooloney: With your kernel, I still can't load initrds *gah*
<lool> cooloney: I think it's due to the same bug as for kexec, or similar
<lool> cooloney: Do you have a recipe for converting a vmlinuz to a vmlinux?
<cooloney> lool: you wanna try vmlinux, right? i can uploaded for you
<lool> cooloney: Would be nice, thanks
<lool> I do see "cramfs" in the list of attempted file systems now; but it doesn't work
<lool> cooloney: So with your kernel to run qemu and loaded with kexec, it still hangs as before
<lool> "Starting new kernel" and nothing more
<cooloney> ok
<cooloney> there is no "Uncompressing...," right?
<lool> cooloney: Let me try with the serial console trick
<lool> I get more output in this way
 * ogra glares at klibc buildlog ... -march=armv4 -mtune=strongarm 
<lool> cooloney: Well using an uncompressed kernel might improve the test; let's try with one
<ogra> hrm
<cooloney> lool: no problem, i am uploading, but it will take some time
<cooloney> due to the slow connection at my home
<lool> cooloney: Press the "FAST" button below your modem
<lool> sometimes it's labeled TURBO instead
<persia> ogra: Please fix :)
<ogra> persia, well, thats not the cause of the ftbfs
<persia> Yeah, but :)
<ogra> lool, isnt that a software switch that needs this proprietary program from www.modemspeedier.com ?
<persia> ogra: Depends on the modem.  The better class have external controls that do the same thing as the extended AT sequences.
<ogra> heh
<lool> cooloney: Updated the kexec/versatile bug
<lool> lp #518567
<ubot4> Launchpad bug 518567 in linux (Ubuntu) (and 1 other project) "armel/versatile: Can't kexec (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518567
<lool> cooloney: Found how to convert the image (I think)
<lool> Hmm not sure
<lool> I get no vidoe output, so seems my vmlinux is busted
<cooloney> lool: i found 2 vmlinux in my build dir
<cooloney> one is 61M,
<cooloney> one is 3M, which is not for this
<cooloney> lool: or just Image?
<lool> cooloney: I think we want vmlinux
<lool> cooloney: but you can strip it
<lool> vmlinuz is stripped and gzipped which is why it's much smaller
<lool> My vmlinux is 6.3 MB so that seems about right
<cooloney> ok, will do that
<lool> cooloney: YES!
<lool> cooloney: So booting your vmlinuz and kexecing the vmlinux I created works
<lool> cooloney: So don't bother uploading
<lool> So many problems here, vmlinuz loading broken, vmlinux boot broken, need to test initrd support...
<cooloney> ok, understand now
<cooloney> you convert the vmlinx from my vmlinuz
<cooloney> and kexec that, right?
<lool> Yes
<cooloney> ok, cool
<asac> ericm_: why do we use CONFIG_OABI_COMPAT=y ?
<lool> cooloney: That's a good workaround, but would you be interested in chasing the other issues?
<ericm_> asac, that's for old ABI binary to be still able to run
<ericm_> asac, it's harmless - any issue you found related to this?
<cooloney> lool: i'd love to,
<persia> lool: Are you certain that we don't need to use qemu to support ppc64 on ppc, sparc64 on sparc, and amd64 on i386?
<lool> persia: I'm not, I applied the same heuristics as the qemu Debian package
<persia> OK.  I'll just follow along then.
<lool> persia: I think it's only possible to run ppc64 on powerpc if you have ppc64 hardware and you run a 64-bits kernel (with a powerpc 32-bits userspace)
<asac> ericm_: mvl asked why we still have that. i think they thought it would help if we'd drop it
<asac> iirc there were also some performance claims
<persia> lool: I think the same is true in every case in my example.
<asac> if you say it shouldnt hurt at all, fine.
<lool> persia: but I don't have hardware and I didn't want to write overly complex code I couldn't test
<lool> persia: Yes, I'm only giving an example
<ericm_> asac, so far no related issues with that
<amitk> ericm_: we could get rid of OABI. We don't care about letting older ABI binaries run on Ubuntu...
<asac> ericm_: but is there any reason to keep it? e.g. EABI is already really really old
<asac> right
<lool> persia: Similarly, it might be possible to use qemu-x86_64-static under i386, but I don't think we actually have a binfmt for that as it might mess up config_32 for users of amd64 hardware with a 64-bits kernel
<lool> Anyway, if someone wants to support using qemu there and has a patch which I can understand, I'm happy to review + merge it  :-)
<persia> lool: I think you're right, and I don't want to fuss with it enough to try to fix it now.
<amitk> ericm_: I remember that I turned it off on FSL
<ericm_> asac, amitk, no specific reason, just want to keep a certain degree of backward compatibility, but it's OK to remove I agree
<ericm_> asac, amitk, it's actually not very old, EABI became popular in less than 2 years
<amitk> ericm_: with the distro compiled for armv7+, backward compatibility is not one of our stated goals :)
<ericm_> amitk, agree
<amitk> and we want to make sure that we run all EABI code. Debian does a great job of supporting OABI and EABI as it is.
<lool> Does OABI support hurt?
<cooloney> lool: is there any option in qemu to enable a host directory to share with the running qemu virtual system
<lool> ISTR it caused some weird bugs on dove
<ericm_> well, in some cases, that depends on the source code availability to be recompiled with new EABI and new toolchain
<lool> cooloney: There is, but I don't use it
<cooloney> lool: ok,
<lool> cooloney: Consider either a nfs export if you have that, or just loop mount your image
<lool> (I do the latter)
<ericm_> but it's not always true - esp. in some areas source code is not available, but anyway those are corner cases
<lool> cooloney:
<lool> http://people.canonical.com/~lool/loop-mnt-do
<ericm_> lool, I don't think OABI support is harmful - so far no evidence
<lool> cooloney: loop-mnt-do some.img
<lool> ericm_: I think there was a suspend resume bug under dove triggered by this config
<ericm_> lool, that's caused by other issue but could be worked around by turning this option off
<ericm_> lool, Marvell has provided a right fix to that bug
<lool> lp #453682
<ubot4> Launchpad bug 453682 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "late resume failure on dove (affects: 2)" [High,Fix released] https://launchpad.net/bugs/453682
<lool> ericm_: I agree, this bug is fixed, I just don't know whether OABI_COMPAT is exposing us to more of such bugs, or whether it's truly harmless
<ericm_> lool, so far none - I tend to keep a certain backward compatibility, but as amitk said, this might not be necessary, and I'm totally fine to turn this off if everyone agrees
<lool> The only other reasons I can think of to drop it: * size of the kernel (but then it's a pig anyway), * security issue in one of the OABI code pathes (no track thereof until now though)
<ericm_> lool, fair enough
<lool> ericm_: Frankly, I have no opinion either way; I'm just curious of what would justify the config either way -- as to be able to answer questions on this choice
<lool> I didn't face someone running an OABI binary on Ubuntu so far, and didn't have to run one myself; perhaps it's useful for e.g. flash tools or proprietary software like skype or flash?  no idea really
<ericm_> lool, could you include me in the CC loop when discussing these config options with Marvell, I know they intend to keep their kernel config as close as ours so to minimize the future developing effort
<asac> i doubt it
<lool> ericm_: I actually don't discuss this with marvell myself
<asac> (flash/skype)
<lool> ericm_: If I ever do, I'll Cc: you  :-)
<ericm_> lool, thanks
 * lool is just polluting the amitk/ericm discussion out of curiosity
<asac> ericm_: amitk: so i take it that we can drop this? /me goes files a bug
<ericm_> asac, thanks
<asac> bug 534277
<ubot4> Launchpad bug 534277 in linux-mvl-dove (Ubuntu) "disable OABI_COMPAT (affects: 1)" [Medium,Triaged] https://launchpad.net/bugs/534277
<asac> cooloney: is that on for -fsl too?
<asac> (see above)
<suihkulokki> disabling oabi compat gives a tiny performance improvement on making syscalls
<asac> good... we want performance ;)
<suihkulokki> then you should start with disabling the PIE binary stuff which has major impact in performance
<suihkulokki> the PIE/address randomizing stuff is snakeoil for security on 32bit archs anyway
<cooloney> asac: i just checked that
<cooloney> it is disabled in fsl-imx51
<amitk> ericm_: cooloney: ^^^ what suihkulokki said about PIE is very pertinent.
<cooloney> grep -r CONFIG_OABI_COMPAT ../Ubuntu/fsl-imx51-lucid/debian.fsl-imx51/config/
<cooloney> ../Ubuntu/fsl-imx51-lucid/debian.fsl-imx51/config/config.common.ubuntu:# CONFIG_OABI_COMPAT is not set
<cooloney> roc@roc-macubuntu:~/Work/qemu-arm$
<amitk> cooloney: I disabled it very early in Karmic I think
<cooloney> amitk: yeah, thx, man, heh
<ericm_> suihkulokki, what is PIE binary, sorry?
<persia> http://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables
<cooloney> so we need to disalbe that PIE stuff in kernel?
<cooloney> will some apps fail to run due to that?
<ogra> we should try :)
<ogra> if the performance penalty is really that high it might be worth to look at
<persia> Um, why?
<ericm_> PIC sounds more familiar to me, but anyway - how's this related to oabi?
<persia> PIE isn't that useful for security on 32-bit architectures, but PIC is critical for sane shared libraries.
<persia> And we probably have to unwind some other things: kees implemented the ASLR stuff a while back.
<amitk> ericm_: its not related to OABI, it is related to performance
<ogra> persia, oh, i meant pie
<ogra> err
<ogra> pic
<amitk> ogra: no, you meant PIE ;)
 * ogra curses the similarity of all these abbrev.'s
<ericm_> that's true, PIC hurts performance a bit
<amitk> ericm_: no, we are talking about PIE
<cooloney> PIC hurts perf, but it necessary for .so
<ericm_> why do we need PIE anyway?
<cooloney> i have no idea about PIE stuff as well as ericm_
<persia> Right.  We aren't giving up PIC.  Once we have PIC, PIE doesn't generally matter that much, performance-wise.
<cooloney> and what kind of app is using PIE binary
<cooloney> persia: so PIE is an older trick than PIC?
<amitk> ericm_: for security, It randomizes the address space layout
<ericm_> lool, apparently I missed the discussion of kexec vmlinux, it looks the arm kexec-tools doesn't support vmlinux/vmlinuz, but the one generated with objcopy can be used directly by kexec to avoid the zImage uncompressing code overwritting initramfs data issue
<persia> cooloney: PIE just means the *entire executable* is PIC.
<ericm_> and give a better performance since uncompressing can be skipped
<amitk> so there is no well-known location for the executable code
<amitk> but we'll need to talk to the security team about disabling it for ARM. They might have other views.
<Laibsch> lool: I assume you are using glibc for ubuntu-arm?  Have you guys considered eglibc?  The OE toolchain guru swears by it.
<persia> Laibsch: Have you checked?  I think we are using a variant of eglibc
<Laibsch> persia: no, I have not
<Laibsch> "assume"
<Laibsch> I thought it was quicker to just give that information and let lool decide what he wants to do with it
<Laibsch> I wouldn't even know where to check ;-)
<persia> Laibsch: It's almost always more efficient to investigate a bit :)
<persia> Or ask questions generally.
<ogra> we use eglibc by default
<ogra> on all arches iirc
<Laibsch> persia: I did ask, see above
<persia> By "generally" I meant "without highlighting any individual" :)
<NCommander> morning persia
<persia> NCommander: So it is :)
<Laibsch> persia: I'm trying to help by pointing out possible lessons learned for ubuntu-arm from what I know about OE.  If I need to finish an IT education first before being allowed to do that, I'll just simply stop. Becuase my time is limited.
<NCommander> OE is nifty because they cross-compile everything, which makes it a lot easier to build than say Ubuntu which requires native building
<Laibsch> it's both a blessing and a curse, I guess
<NCommander> Laibsch: indeed, some packages are mindbogglingly difficult to cross-build
 * NCommander glares at mySQL
<persia> Laibsch: It's not about an education.  It's just about trying things, and asking questions not of specific folk so that they aren't distracted if someone else has the answer.
 * NCommander sighs
<Laibsch> we've spent more time discussing this now than it will take an expert to decide what to do with the info
<Laibsch> I'm not an expert
<Laibsch> if you want me to become one before I can point out possible differences then I'm sorry, I can't do that
<persia> Laibsch: You've taken that wrong.  My apologies.
<Laibsch> I will try my best not to waste people's time
<Laibsch> But there's two sides to the equation
<persia> Absolutely :)
<Laibsch> lool's time and mine.  I'm looking at overall efficiency.  I think that may be where our diffrences are
<Laibsch> It will cost me an immense amount of time to understand the toolchain issues
<Laibsch> it will be only seconds to either discard or decide to look further into it for an expert
<Laibsch> hence the decision I made
<Laibsch> btw, no offense taken, don't worry
<persia> Cool!
<ogra> funnily i cant find the public discussion for it, but we switched to eglibc in karmic
<Laibsch> great
 * amitk remembers it being posted to ubuntu-devel
<Laibsch> I understand that ubuntu on arm still has some speed issue, though, correct?
<lool> Sorry, I was interrupted by someone at my door
<cooloney> lool: for the kexec on versatile
<asac> hmm axis build failure looks odd https://edge.launchpad.net/~asac/+archive/armel1/+build/1543870
<asac> is java working at all on armel atm?
<cooloney> lool: you mentioned kexec -l vmlinux works on your side
<cooloney> lool: is on versatile hardware?
<lool> cooloney, ericm_: http://people.canonical.com/~lool/vmlinuz-to-vmlinux
<cooloney> lool: but failed on qemu, right?
<lool> That converts a vmlinuz to vmlinux
<cooloney> lool: got you, thanks,
<lool> cooloney: It's in qemu
<lool> cooloney: a) I can't qemu-boot the vmlinux kernel (unrelated to kexec), only the vmlinuz one b) I can't kexec the vmlinuz kernel (original bug); that seems to be a bug in the way kexec choses addresses (perhaps)
<lool> cooloney: I don't have versatile hardware (probably nobody does around here); I just use qemu
<cooloney> lool: understand. i cannot kexec vlinux, it does not work on my qemu
<cooloney> lool: right, just was confused by your post in the bug
<cooloney> heh
<cooloney> 'I can't boot the vmlinux in qemu though.' hehe
<lool> cooloney: I need to update the bug again
<cooloney> i played versatile hw before, so i assume you got it
<cooloney> lool: ok
<lool> That was after testing your kernel, but before testing vmlinux
<cooloney> lool: let me try your vmlinuz-to-vmlinux
<lool> cooloney: I don't have it; we just use versatile because it's well supported in qemu
<lool> cooloney: you need to pipe the output
<lool> cooloney: e.g. vmlinuz-to-vmlinux ~/yourvmlinuz > output-vmlinux
<cooloney> lool: yeah, just got an vmlinux file with the pipe after the funny symbols popped up on my screen w/o pipe
<asac> thumb2 rebuild ftbfs: http://paste.ubuntu.com/390975/
<cooloney> lool: OMG, the vmlinux generated by your script works with kexec
<cooloney> lool: cool
<persia> asac: Not bad at all!
<persia> ~4% of the rebuilds
<lool> Laibsch: So as pointed out above, we use eglibc by default everywhere, just like Debian
<Laibsch> great
<lool> suihkulokki: Do you know of public benchmarks of PIE versus non-PIE on armel?
<Laibsch> anybody here using a native arm compile host coupled with a bunch of icecc clients?
<lool> I can expect that basically any security feature has a cost, but I wish we had some data to quantify
<cooloney> then we can comfirm what patches need to be applied into our master.versatile, fsl-imx51, mvl-dove
<lool> Laibsch: To clarify, there is exactly one source packages pool which is the Ubuntu archive; the Ubuntu armel port uses the very same source as the Ubuntu Desktop Edition for instance
<lool> cooloney: Let me test a pristine vmlinuz to see whether your patches are required
<Laibsch> yes, that is my understanding
<Laibsch> and that is the benefit of ubuntu-arm over OE imho
<Laibsch> it will likely scale better going into the future
<amitk> IMHO, s/likely// in the above sentence :)
<Laibsch> future is always uncertain ;-)
<amitk> its worked for Ubuntu for over 4 years now...
<amitk> and in the Linux kernel for much longer (embedded -> PC -> mainframe)
<cooloney> lool: thanks please update the status of launchpad
<lool> cooloney: done
<Laibsch> amitk: right now, I think OE-derived stuff is more usable.  the debian-arm project apparently predates OE, yet I would venture to guess that Angstrom is more usable currently than debian-arm.
<lool> Depends of the purpose
<lool> OE doesn't provide an end-user installer, or security support
<ogra> or easy upgradeability
<lool> People running Debian on ARM NAS devices care about these
<persia> And it works great for that use case.
<persia> I know a bunch of folks happy with Debian on handhelds as well.
<amitk> Laibsch: for a different definition of "usable" from our typical users.
<Laibsch> OE is not meant to provide that.  That would be distro stuff
<amitk> ... developers as well, in fact
<Laibsch> an end-user installer in that sense may not be necessary
<Laibsch> devices have traditionally been flashed with a complete rootfs
<Laibsch> upgradeability is something that Angstrom does care very much about
<Laibsch> security is indeed a very weak point
<persia> Laibsch: That only works for pre-sold stuff, and even pre-sold stuff may want a refresh for a variety of reasons (e.g. install Kubuntu Netbook on a Netwalker)
<Laibsch> but there's been some work there lately
<Laibsch> persia: what do you mean pre-sold stuff?
<Laibsch> I don't understand what you are trying to say
<persia> err, stuff sold pre-installed.
<ogra> i think he means pre-installed
<Laibsch> no, that is not true
 * persia goes to find calories in hopes of thinking better
<Laibsch> I'm not aware of any device with angstrom installed as shipped (althought that may have changed lately)
<ogra> Laibsch, what we want is that your sister can buy that arm netbook ... and if she doesnt like the perinstalled OS is able to install ubuntu on it and use it like on x86 with no drawbacks
<Laibsch> sure
<ogra> (and without prior computer knowledge)
<Laibsch> that's how OE got staretd
<Laibsch> people replaced Sharp ROM with OZ ROM for example
<ogra> your sister would be able to replace os-blah on her arm netbook with OE ?
<Laibsch> so, I don't understand the point being made there
<ogra> would that even be possible without knowing how to use a serial console ?
<Laibsch> of course
<Laibsch> you guys seem to have some serious misconceptions
<ogra> no, i've just seen a lot of hard to work with arm hardware :)
<Laibsch> I think it's much easier to change the OS on a Z with OE-derived stuff than put Ubuntu on it
<kblin> Laibsch: are you surprised? this is an ubuntu chennel :)
<ogra> and i want to meet your sister !
<ogra> *g*
<Laibsch> My sisters are older than me and married
<Laibsch> sorry ;-)
<ogra> heh
<kblin> Laibsch: it's a bit like talking about the benefits of perl on #python
<amitk> heh
<Laibsch> well, it's good to know what else is out there
<Laibsch> and I think there is a lot that can be learned from OE
<ogra> kblin, nah ... OE surely has its advantages
<Laibsch> so that the wheel doesn't need reinvention
<kblin> ogra: good point
<ogra> but there is a reason why endusers pick ubuntu over gentoo on theirt x86 machines :)
<lool> kblin: Oh don't worry we often debate python versus shell here
<Laibsch> There was no alternative to OE at the time it was invented
<Laibsch> native compilation was not possible
<ogra> and i think the same reasons apply if you look at OE vs ubuntu-arm
<Laibsch> that's changing and that's why I'm considering to switch
<ogra> lool, well, if asac joins the discussion there will also be C involved :)
<Laibsch> You need to look back 5+ years when OE came to life
<ogra> sure
<ogra> there was no ubuntu-arm back then
<kblin> Laibsch: the reason why I run ubuntu on my ARM boxes is one of convenience rather than a technical one
<amitk> Laibsch: It is safe to say that most people here have played with Zaurii, OE, familiar, etc. in a previous life.
<Laibsch> then it's pretty amazing to read "OE is hard to install"
<Laibsch> for two reasons
<Laibsch> 1) you never install OE on your device
<kblin> so?
<Laibsch> 2) OE-derived distros do provide an easy to use installer mechnism (at least for the devices I'm familiar with)
<lool> Folks, I'm not sure the Ubuntu versus OE discussion is leading anywhere
<ogra> yeah, lets turn it into a gnome vs kde one rather !
<Laibsch> lool: I'm not sure anybody is trying to convince anybody else
<lool> Different projects stand in different states and fit different people; I'm happy to discuss specific things we can rip from OE if there's something we can easily rip right now and it fits with the priorities of Ubuntu ARM
<Laibsch> for me it's an exchange of facts, more than anything else
 * amitk gets back to real work
<kblin> lool: armv5 support? ;)
<Laibsch> kblin: good idea!
<kblin> lool: cheap shot, I know :)
<kblin> Laibsch: not really important, ogra's sister won't buy a netbook with an armv5, so that's not a problem :)
<ogra> she only buys what i tell her is easiest to use for her :)
<lool> cooloney: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/534324
<ubot4> Launchpad bug 534324 in qemu-kvm (Ubuntu) "Can't run uncompressed (vmlinux) kernels (affects: 1)" [Undecided,New]
 * kblin gets back to work
<lool> cooloney: So a vmlinux from the archive vmlinuz just works
<ogra> oh my ... so klibc defines armv4 and tunes for strongarm upstream
<ogra> hrm
<lool> cooloney: So your patches/build aren't needed to load vmlinux; perhaps these are needed for initramfs?
<lool> kblin: Oh it's absolutely desirable
 * ogra was hoping that was a debian setting from rules
<lool> kblin: I have some thoughts on that, but it wasn't really a high priority until now
<kblin> lool: like doing two builds?
<lool> Wow, I end up with apex on my versatile install; I bet the kernel did it
<lool> kblin: I don't think we would build this all the time
<lool> kblin: What would be ok is taking Ubuntu's armel archive, using some clever machinery to rebuild everything a couple of times, and storing this new archive somewhere else
<lool> Where that machinery could either be an expensive set of ARM hosts or qemu on a lot cheap x86 hosts (such as EC2)
<lool> apw: I'm considering a d-i upload; do you plan uploading linux-fsl and linux-mvl this week?  if you do, I'll hold it a bit
<apw> lool, yes i think i have patches pending on both branches
<apw> i'll have a look shortly and let you know ...
<lool> Thanks
<ogra> lool, apex is in universe
<ogra> lool, but only moved out of the d-i deps recently
<ogra> so it depends when you installed
<lool> I'm not sure why it got pulled really
<lool> I created the chroot with debootstrap
<lool> Hmm it might be the d-i build-deps
<lool> Right
<Laibsch> seeing that CPU cycles on arm are still scarce, I'd like to reiterate my earlier question. Anybody here using a native arm compile host coupled with a bunch of icecc clients?
<lool> So nm, just my setup
<persia> Laibsch: Just use the emulation if you can't do native.  It's not that slow.
<Laibsch> I'm really interested in that question, though.
<lool> I don't think anybody here does that
<Laibsch> I see
<lool> I think it's used in the OBS, in the Xandros ARM builds, and perhaps in the mojo tools
<Laibsch> Any technical reason to make that infeasible?
<Laibsch> OK
<Laibsch> Maybe I'll have a bit of fun with something like that, too
<lool> We just use different solutions
<Laibsch> I've previously used OE and distributed that with icecc
<Laibsch> It worked pretty nicely
<asac> JamieBennett: https://launchpad.net/ubuntu/+source/fio/1.33.1-1ubuntu1/+build/1550048/+files/buildlog_ubuntu-lucid-ia64.fio_1.33.1-1ubuntu1_FAILEDTOBUILD.txt.gz ;)
 * JamieBennett looks
<asac> its ia64
<asac> /build/buildd/fio-1.33.1/verify.c:907: undefined reference to `write_barrier'
<asac> guess we can ignore it ;)
<asac> unless you see the problem right away
<JamieBennett> Why is that code being included on IA64 ?
<asac> not sure
<asac> most likely the problem is that its not included :;)
<asac> the symbol isnt defined
<asac> e.g. it lacks a ia64 implementation
<JamieBennett> Its ARM specific though (in arch/arch-arm.h)
<asac> or the ia64 implementation currently in the code is not picked up
<asac> JamieBennett: verify.c
 * JamieBennett didn't touch verify.c
<asac> ./arch/arch-ia64.h
<asac> JamieBennett: #define nop             asm volatile ("hint @pause" ::: "memory");
<asac> #define read_barrier()  asm volatile ("mf" ::: "memory")
<asac> feels like its a missing _
<asac> #define writebarrier()  asm volatile ("mf" ::: "memory")
<asac> simple fix we could try in the next upload
<JamieBennett> asac: still don't understand what the current fix could of done to effect that unless IA64 was broken before
<asac> JamieBennett: its not a regression
<asac> the problem existed before
<asac> (i am quite sure)
<JamieBennett> asac: so yes, missing '_' it seems
<asac> sorry if i made you feel that way ;)
<asac> JamieBennett: ok. have you updated the patch? i can just add the _ for next upload
<JamieBennett> asac: np
<JamieBennett> asac: I was looking for what I had 'broken' ;)
<asac> heh :)
<asac> this time it wasnt you
<JamieBennett> :)
<JamieBennett> I'll update the patch and attach it to the bug
<JamieBennett> unless its easier for you to just do it ?
<asac> i will wait for you
<ogra> asac, so you were complaining about http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png boottimes ... i did a test on a similar scaled x86 system with the same software ... http://people.canonical.com/~ogra/celeron-M-lucid-20100308-3.png
<ogra> i dont think we look so bad on babbage compared to that
<ogra> (note the celeron has even 10MB/s higher disk throughput)
<asac> ogra: when is the UI up?
<asac> e.g. what do i need to look for?
<ogra> netbook-launcher
<ogra> and then gnome-panel
<asac> so its 50s v. 60s?
<ogra> or 35 vs 45
<ogra> depends what you look at
<ogra> launcher is up very fast
<ogra> panel has 10-15s delay
<ogra> but its definately not arch specific if you compare two similar systems
<ogra> (similar slow)
<ogra> lool, bah, you broke rootstock packaging ... "qemu-kvm-extras-static | qemu-kvm-extras" .... qemu-system-arm is still needed for the image building and system setup, oem-config installation etc
<lool> ogra: Back then, I think it used to use either system emulation or syscall emulation but not both, didn't it?
<ogra> nope
<ogra> it always did use qemu-system-arm for the system configuration, user steup and preparation for running on real HW
<ogra> mono was always my showstopper
<ogra> syscall emu is only used for the debootstrap part (which is the smallest bit of rootstock)
<ogra> lool, soo, our versatile kernel ... would you expect it to do thumb2 instructions properly ? i now ran a rootstock build of karmic ubuntu-desktop under lucid that seems to properly finish (not done yet but all the steps where lucid hangs are definately done) ... that somnewhat points to userspace imho
<ogra> i wonder if the versatile hack that enables a v7 cpu actually enables the needed bits and pieces to execute lucid binaries
<ogra> (though its still weird that it just silently hangs withouot errors, segfaults or anything)
<lool> ogra: I don't understand what you're saying
<ogra> lool, well, you know about my hang of qemu
<lool> ogra: I can run a lucid thumb2 userspace under qemu-system-arm with our versatile kernel
<ogra> but can you run it under heavy IO disk load ?
<lool> I don't see how that relates to thumb2
 * ogra refers to 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
<ogra> well, i dont know why it hangs but installing karmic ubuntu-desktop doesnt expose the hang
<lool> ogra: did you strace the processes as I suggested?
<ogra> while using a lucid userspace inside qemu does
<ogra> yes, nothing
<lool> nothing?
<ogra> well, i straced apt ...
<lool> It's certainly in one syscall, or its hung using all CPU; no?
<ogra> no, nothing, it just stops
<lool> On which syscall?
 * ogra will need to re-run ... i threw away the image to make room 
<ogra> these qemu-system-arm images start to eat my disk space :/
<lool> ogra: You mean the expensive megabytes of your SSD :)
<ogra> heh, yeah
<Meizirkki> What's the state of Lucid regarding arm support ?
<Meizirkki> dpkg goes segfault on my Touch Book..
<ogra> lucid is v7 and thumb2
<Meizirkki> hmm
<ogra> does your CPU support both ?
<Meizirkki> lemme see
 * ogra thinks touchbook was omap ... some cortex-a8 so it should actually work
<Meizirkki> it's based on beagle board
<Meizirkki> thumb is supported, i'm not sure about thumb2 :(
<ogra> right
<ogra> it should be supported ...
<ogra> how exactly does it fail ?
<Meizirkki> for example: "apt-get install something" it starts downloading but very soon says http method died unexpectedly (Segmentation Fault))
<ogra> thats not dpkg
<Meizirkki> and if i repeat it enough it will eventually get it all downloaded, but then dpkg fails to unpack packages because of Segmentation Fault
<ogra> hmm, intresting
<Meizirkki> Yes they both segfault
<ogra> we dont see that on imx51 or dove boards
<Meizirkki> According to elinux.org lucid does run on BB as well..
<ogra> where did you get the kernel ... and what kernel version are you running ?
<Meizirkki> The kernel is a mess.. provided by Always Innovating (the company selling TB)
<ogra> what version
<ogra> lucid needs .32
<Meizirkki> 2.6.29
<Meizirkki> alright
<Meizirkki> that's it :)
<ogra> hmm, might be :)
<Meizirkki> thanks for all the help
<ogra> welcome ...
<ogra> there is a beagle kernel for lucid on the beagle wiki though
<lool> Meizirkki: this sounds like a hardware stability proble
<lool> m
<ogra> not sure that has all the touchbook drivers though
<lool> Meizirkki: Is the segfault happening always at the same place?
<Meizirkki> lool,
<Meizirkki> yes
<lool> Meizirkki: Is it actually a "segfault", or is it e.g. a sigbus?
<Meizirkki> segfault
<Meizirkki> lool, knowing there are some hardware bugs.. it might be a hw stability problem as well
<lool> Meizirkki: Unless your libc/dpkg are heavily modified causing the segv, it rather points at hardware stability issues to me
<lool> Meizirkki: If random programs segfault, not just dpkg, then it's certainly the case
<lool> Meizirkki: Out of curiosity, where did you get it?
<Meizirkki> Touch Book ir Ubuntu ?
<Meizirkki> o
<ogra> cant you buy it at AI ?
<lool> Meizirkki: the TB
<Meizirkki> I bought my Touch Book from AI
<Meizirkki> It's from the second batch i guess..
<lool> Meizirkki: If you want to rule out userspace changes, you can debootstrap Ubuntu lucid into a local clean chroot, dpkg is stable for us
<Meizirkki> AI kernel is a bit strange too, size 5MB and it doesn't have any omap3 powersave stuff or even IP multicasting.. but some android patches..
<lool> Meizirkki: So that it can run android!
<ogra> instead of lucid :P
<Meizirkki> haha
<Meizirkki> I'm looking forward seeing a recent omap-pm kernel running on it though, they will never get 10-15 hours of USE with this kernel
<Meizirkki> (on one charge)
<ogra> sure ... with the extra car battery attached :)
<Meizirkki> lol
<Meizirkki> it does 16 hours without wlan which is nowhere near enough
<Meizirkki> They'll send me a new keyboard-part for free => 12A extra battery :P
 * Meizirkki boots up lucid
<lool> persia: poke
<lool>         if [ ! -f "/usr/bin/build-arm-chroot" ]; then
<lool>             sudo apt-get install qemu-kvm-extras-static
<lool>         fi
<lool>         DEBOOTSTRAP_COMMAND=qemu-debootstrap
<lool> persia: Sounds like DEBOOTSTRAP_COMMAND=qemu-debootstrap should be first and you should test with if ! which $DEBOOTSTRAP_COMMAND >/dev/null 2>&1 ...
<ssvb> Meizirkki: Cortex-A8 r1pX (typically r1p3) from OMAP34xx/OMAP35xx chips has quite a number of thumb/thumb2 hardware bugs
<ssvb> if you really want to use thumb, you need to apply some workarounds
<ssvb> Meizirkki: at the very least you need to have CONFIG_ARM_ERRATA_430973=y option in the kernel configuration
<Meizirkki> okay, thanks
<ssvb> and some of the fixes have to go to the bootloader
<ssvb> so without this option enabled, you are going to have segfaults in thumb code for sure. If it does not help, then your bootloader did not set IBE bit in AUXCR and you will have to fix it there too
<ssvb> Meizirkki: additionally your binutils package should be recent enough to have this workaround: http://sourceware.org/ml/binutils/2009-05/msg00297.html
<Meizirkki> thanks
<ssvb> good luck and if you get stuck, you can poke me regarding all this thumb stuff :-)
<Meizirkki> I'm stuck already :P as I'm not that familiar with the hardware.. but i'll at least file bug to AI so they can fix their kernel and u-boot :)
<ssvb> ok, that may be the best solution, don't forget to provide them with these errata numbers and links, if they have Cortex-A8 errata list pdf, they will be able to dig up all the necessary details from it
<persia> lool: Indeed.  That's a much better way to do it.
#ubuntu-arm 2010-03-09
<napster> I've a tarball of the root file system
<napster> How to transfer it to the board?
<napster> And how to extract it there?
<napster> jussi01, ?
<napster> What is actually a uImage?
<napster> !hawkboard
<ubot4> Factoid 'hawkboard' not found
<napster> !angstrom
<ubot4> Factoid 'angstrom' not found
<napster> ANYONE CAN HELP ME OR ATLEAST RESPOND???
<persia> Bother.  Had to be a Tuesday :(
<kblin> persia: they call it stormy monday, but tuesday's just as bad? :)
<persia> kblin: No, it's that I like to help folk, but tend not to be around in the 3-9 UTC range on Tuesdays.  Most days that range is quiet anyway, but not today.
<persia> And nobody else ever seems to answer questions at those hours any day, so if someone comes by on Tuesdays looking for help, I wish they'd picked a different day :)
<kblin> I see :)
 * ogra pokes the builder "come on glib ... paddle faster !"
<asac> boing
<asac> ogra: how can we best produce a log of info about failed/succeeded image builds?
<persia> asac: We can get that from Soyuz.  What do you need?
<ogra> image or livefs builds ?
<asac> at best both
<persia> asac: And how do you want it presented?
<asac> i would think image comprises livefs
<asac> so if livefs fails and image suceeds we have a problem
<persia> Oh, images.  We can get those from people.canonical.com
<asac> persia: a daily log table
<asac> like: row: date / column: arch/subarch
<persia> asac: Why is it a problem if livefs fails and image succeeds?  That happens for most livefs failures.
<asac> and then just "green" ... "red"
<asac> with link to the logs if available
<ogra> i guess that would either need a script that parses people.u.c or a mail filter and a generic mailbox for the build failures
<asac> persia: how does image succeed if no livefs is produced?
<persia> That's not hard to implement, but it'd be easiest to implement *inside* the build-system.
<persia> asac: It uses the old livefs.
<asac> right thats what i thought (inside)
<ogra> persia, we have the mails ... we could add a ML to ubuntu-armel
<ogra> the prob is that you cant filter them by arch easily
<asac> i think we need three data sources published: 1. cron job publishes info about started /scheduled build (so we can figure if something broke seriously
<ogra> at least server side
<asac> 2. log info about livefs failure/success
<ogra> the cronjob never changes
<asac> 3. log info about image failure/success
<ogra> we know when it starts
<ogra> 2 and 3 are alreasdy existing
<asac> ogra: yes, but something has to seed the info
<asac> ogra: where?
<ogra> just not merged/parsed automatically
<persia> asac: Let's get the build system to publish a summary in a machine-parsable format daily, and then we can use that to construct reports as we like.
<asac> where is the raw data
<asac> with just date/imageid: FAIL/SUCCESS
<ogra> for the livefs on the live builder
<ogra> for the image builds its on antimony
<asac> persia: yes. just wanted to understand what parts we need
<asac> ogra: what format do those files have?
<ogra> what you see on peole is an exact mirror of either of them
<ogra> txt
<ogra> *people
<asac> and yes, i figure that we probably hav that. i just want it to be exported in a parsable fashion
<asac> ogra: where?
<ogra> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/
<ogra> for the livefs
<asac> those are the logs
<asac> those dont say: "fail/success"
<asac> thats not that useful
<ogra> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ for the images
<asac> we need to publish the exit code
<asac> with date
<ogra> as i said, you need to parse them
<ogra> for the image builds there exists a mail function
<asac> well. thats too difficult. too many things can happen
<ogra> antimony mails about failures
<asac> if it would print "exited (code=X)
<asac> "
<asac> that would be ok
<ogra> but thats not easy to filter
<persia> May I?
<ogra> since it only mails per-flavour, not per arch
<asac> right. in short. that info isnt there ;)
<ogra> it is
<asac> makes no sense to write an ever greowing parser of the logs
<asac> persia: go ahead ;)
<ogra> its just not broought to the right people atm :)
<persia> So, let's alter the scripts that build stuff to make a shortlog, and publish the shortlog.
<asac> ogra: this discussion is about what to do ;)
<persia> We can then parse the shortlogs, and build the reports we want.
<asac> persia: shortlog is good. or a good parseable tag at the end of the log
<ogra> as i said, thats already there for the image builds
<asac> like: EXITCODE====1 ;)
<persia> asac: Can't do that: the logs are per-flavour
<asac> ogra: its not there, because i dont see it on the web
<ogra> asac, you could get it by mail
<asac> ogra: right. but thats not the preferred way
<ogra> but as i said above its lacking filtering on subarches
<asac> we want something parsable through http ;)
<asac> persia: you say there is no common code?
<ogra> asac, right
<asac> or you dont want to add that to logs of other flavours?
<ogra> its only per flavour
<ogra> not per subarch
<persia> asac: I say that the logs don't currently have enough information in a format that is easily extracted.
<asac> persia: yes.
<asac> so we alter the scripts to either add something easily parsable there
<ogra> i.e. all ubuntu-netbook failures are the same atm ... there is no distinction between i386, ppc, armel etc
<asac> or we produce shortlogs ;)
<persia> asac: I suggest that publishing a separate shortlog is likely to better enable lots of uses of this data, and will cost less bandwidth than expensive log parsing.
<persia> ogra: That's not precisely the case, although they are in the same log.
<asac> ack ... if that doesnt kick off loads of things
<asac> to do
<asac> and coordinate i am for shortlogs
<persia> RIght.
<ogra> its quite complex and requires a lot of debian-cd hackery
<asac> persia: can you check how much work that would be ?
<ogra> effectively what you want it to turn the mial function into a spit-out-log-to-http function
<ogra> but you need to additionally write a filtering for arch/subarch
<asac> that feels too difficult
<persia> asac: To expose the shortlogs?  Sure.
<ogra> but thats the place to add it
<asac> i want to fix the place that currently execs the image/livfs process
<asac> that place should just check exit code
<ogra> debian-cd has that feature already
<asac> and produce a log
<persia> ogra: You're complicating things.  let's get shortlogs, and parse them in some other script.
<ogra> it simply doesnt filter and doesnt spit out http
<asac> if it already has that place, then its easy to do ;)
<ogra> yes, it just mails the short logs
<asac> i agree with persia ... lets let him check ... i would epxect this to be trivial if someone knows the details
 * ogra knows the details
<ogra> i worked through that with StevenK before
<asac> if we already send the mails, then its really easy
<ogra> more than one time
<asac> just push them in a file ;)
<ogra> and we decided that adding the filtering was quite complex...
<persia> Right.  We don't need the filtering.
<persia> We just need shortlogs.
<ogra> that wont help much for armel
<persia> Yes it will.
<ogra> sinc eits still just by flavour
<persia> I can write a parser for shortlogs in a day.
<persia> As long as the shortlog has a machine-readable format.  e.g. flavour:arch:result
<persia> (probably less than a day, but still)
<asac> date
<asac> ;)
<asac> or buildid
 * ogra doesnt remember anymore and tries to dug up some edubuntu failure mails
<asac> needs to be a column
<ogra> the mail contains the full log :/
<ogra> for all arches
<ogra> so that wont help without having a parser
<ogra> its like 1MB big only for a failed edubuntu build for all arches
<persia> ogra: Right.  I don't want the mail.  I want to be able to get shortlogs from people.canonical.com/~ubuntu-archive/*-build-logs/...
<ogra> persia, so you screen scarep the files ?
<persia> and I want the logs to go in the appropriate dated directories, etc.
<ogra> *scrape
<asac> we can make a good html page out of such shortlogs and rss feeds etc.
<persia> ogra: No.  I don't want HTML.  I want files specifically designed to be consumed by a program at deterministic URIs.
<asac> i really would like to have info about kicked off builds though
<asac> e.g. just build-id
<asac> in that way we can see if stuff is overdue and display a big burning icon ;)
<asac> but thats nice to have ;)
<ogra> cron gets that info ... (or whoever fires off a build manually)
<ogra> its two lines per flavour
<asac> right. so lets add that to the wanted feature list for shortlogs
<persia> asac: That's less interesting, because of how it works.
<ogra> build started on livebuilder <blah> at 12:34:56 etc
<ogra> build succeeded on livebuilder <blah> at 15:34:56 etc
<asac> i dont mind how it happens ;) .... just want to see a big burning state on the final HTML page if a build never lead to a livefs etc.
<ogra> thats what you get if you fire off a manual build
<asac> or never even lead to a log
<ogra> and these lines whould be in the logs if cron execs them
<ogra> *should
<asac> yeah. that thing could create a shortlog entry then
<ogra> right
<ogra> but i dont think we have access to the logs cron writes to
<ogra> at least not the cdimage team
<ogra> cjwatson would know
<asac> yes. thats the other question. we need to get the logs we produce to a public location
 * ogra checks on antimony
<asac> maybe it just publishes a full dir or something that is produced by the parts
<asac> that would make things easy ;)
<asac> if it just copies the log there needs some work done
<ogra> nope, no access to syslog or messages on the builder machine
<asac> i dont see why we want to access those logs
<ogra> because they have the one line info you want from cron
<asac> we would need to produce a log file wherever the main log goes
<asac> ogra: right the hook should happen in whatever script is run rather than relying on that
<ogra> its crond
<asac> what script does that run?
<asac> anyway, details. lets wait for persias eval ;)
<persia> What eval?
<ogra> ARCHES='armel+imx51 armel+dove' buildlive ubuntu-netbook && ARCHES='armel+imx51 armel+dove' for-project ubuntu-netbook cron.ports_daily-live
<ogra> thats our cron line
<asac> persia: checking what it would take to get shortlogs
<asac> e.g. what needs to be done, how much time is it etc.
<persia> Oh, sure.  I was just going to bother a different member of the cdimage team.  ogra is a fair candidate.
<asac> thought you signed up for evaling that ;)
<ogra> so you need to edit buildlive for putting the info into some place additionally to writing to stdout
<asac> ogra: yep
<asac> ogra: if you manually kick a build off it also runs buildlive?
<ogra> additionaly you need to edit for-project
<persia> ogra: That's just >&3 though.
<asac> what about buildalternative etc.? do such scrpts exist?
<ogra> which will be a lot more complicated
<ogra> for-project is highly modular
<ogra> asac, no, for-project does everything realted to image building ... that includes alterante and live
<asac> right. but if there is an initial point of entry that feels like the right place to put the "started" log
<asac> for-project might be a candidate?
<ogra> buildlive just creates the livefs
<asac> we also want to know about that ;)
<ogra> you need to edit both if you want info for both+
<asac> yeah
<asac> we want started for buldlive and started for for-project
<ogra> buildlive should be easy to achive
<asac> and whatever other variant might exist
<asac> i think buildlive would be most essential
<ogra> its only these two
<asac> thats the starting point
<ogra> persia, buildlive is in livecd-rootfs iirc
<asac> then with the "exit" results for the livefs build and the image fs production scripts
<asac> that would give us all we need i think
<ogra> that should be the easiest
<persia> asac: It's not really exit codes: it's more complex than that, but that's the idea.
<persia> ogra: So, how much effort does this shortlog creation involve?
<ogra> oh, buildlive isnt in livecd-rootfs, i lied :)
<ogra> thats BuildLiveCD
 * ogra checks on antimony
<NCommander> ogra: its there, its installed into /usr/share (and it was in the source package)
<ogra> NCommander, hmm ?
<NCommander> ogra: BuildLiveCD is in the livecd-rootfs package
<ogra> sure
<ogra> thats what i said above
<NCommander> ogra: you just said it wasn't O_o;
 * NCommander makes another interesting OOo discovery
<persia> Doesn't matter.
<napster> Can anyone help me to install on hawkboard?
<ogra> <ogra> oh, buildlive isnt in livecd-rootfs, i lied :)
<ogra> <ogra> thats BuildLiveCD
<persia> napster: That's an ARM920T, right?
<ogra> NCommander, ^^^
<napster> persia, I think its OMAP L138
<NCommander> ogra: oh, I read that as you typoed on buildlive, and meant that BuildLiveCD isn't in livecd-rootfs
<NCommander> EPARSERFAIL
<ogra> heh
<ogra> buildlive is part of debian-cd i think
<persia> napster: OK.  That can run Ubuntu Jaunty, but nothing newer, and requires a custom kernel.
<persia> napster: So, do you have a known working kernel >= 2.6.28 ?
<ogra> http://blog.binaerwelt.com/2010/02/ubuntu-on-the-hawkboard/
<persia> Even better :)
<napster> persia, Not yet, (I'm new can you be a little bit simpler?)
 * ogra slowly starts to know all the places where rootstock is mentioned :)
<ogra> (and they get more every day it seems :) )
<persia> napster: Try the link ogra referenced.  There are no images, so that install is very much a do-it-yourself thing.
<lool> ogra: No, of cdimage
<ogra> oh, ok
<persia> napster: We're happy to help you if you get stuck, but we may not be able to help you set up your kernel very well.
<napster> persia, ok, will be back to you when I'm stuck :)
<persia> napster: Good luck.
<NCommander> dmart: ping?
<NCommander> dmart: I need to poke a toolchain expert's brain
<dmart> Hi... hang on, I'll see if Ramana's around.
<NCommander> hey ramana
<ramana> hi NCommander. I'm just about to go get a shower. Can I chat with you in about 10 minutes.
<ramana> ?
<NCommander> ramana: sure, I'm going to go then run towalmart, so I'll beback in 20 :-)
<lool> I wonder whether we might be stripping .debug_frame and that would cause the unwind failures (oops)
<lool> dmart: Do you know how to test/list .debug_frame presence/contents?
<lool> or ramana ^
<dmart> lool: Probably best to wait for ramana to answer this one.
<lool> If we have a bug in strip or dh_strip, we're in trouble I tell you
<lool> We call strip --remove-section=.comment --remove-section=.note --strip-unneeded on shared libs
<lool> and strip --remove-section=.comment --remove-section=.note on binaries
<lool> (and strip --strip-debug on static libs)
<persia> Do all of those get shoved into -dbgsym packages, or is it more complicated than that?
<lool> I think it gets into -dbgsym
<lool> sorry, these do in -dbg.debs
<dmart> It sounds a bit broken if debug frame info is somehow essential for runtime exception handling...
<ramana> hi . back again.
<lool> the -dbgsym packages have the result of "objcopy --only-keep-debug" and objcopy -R .gnu_debuglink --add-gnu-debuglink=$1 on the same file
<lool> dmart: I think there were two standards, and they picked the best one
<lool> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
<ubot4> gcc.gnu.org bug 40521 in debug "[4.4/4.5 Regression] -g causes GCC to generate .eh_frame" [Critical,Resolved: fixed]
<persia> OK.  That's a little different, but that makes sense.
<lool> ramana: So, how would one check whether a binary has a .debug_frame?
<lool> I see .eh_frame in readelf -l, but not .debug_frame, not even on an unstripped binary I built with -g
<ramana> readelf -w should tell you if there is a debug_frame
<ramana> but why is there a .eh_frame in an ARM shared library ? There should only the .ARM.exidx and .ARM.extable sections.
<lool> ramana: Indeed
<lool> Contents of the .debug_frame section:
<lool> [...]
<lool>   DW_CFA_def_cfa: r13 ofs 0
<lool>   DW_CFA_advance_loc: 2 to 00008da2
<lool> etc.
<lool> ramana: Well I think the .eh_frame stuff as due to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521 wasn't it?
<ubot4> gcc.gnu.org bug 40521 in debug "[4.4/4.5 Regression] -g causes GCC to generate .eh_frame" [Critical,Resolved: fixed]
<ramana> Exactly.
<ramana> But that's presumably been fixed .
<ramana> and we need to figure out where this is being pulled from ? The correct fix for that is in the Ubuntu tree . I need to be removing my workaround from the FSF tree now.
<lool> ramana: That was only fixed "recently" a lot of binaries might have been built before that
<lool> ramana: Also, readelf -w libgtk-x11-2.0.so|grep .debug_frame => empty
<lool> I see it on a self built binary built with -g
<lool> But I suspect it's missing in pretty much all our shared libs if it gets stripped
<NCommander> ramana: back
<ramana> if it gets stripped that's fine.
<lool> ramana: I'm pretty sure we have the fix in Ubuntu lucid tip, what I don't know is how many binaries still have .eh_frame instead of .debug_frame; in fact .debug_frame seems to be missing *everywhere*
<lool> ramana: Can you unwind without .debug_frame?
<NCommander> lool: manually built OOo packages still show the same issue
<NCommander> (that is to say, packages that haven't been stripped)
<lool> NCommander: It's not just oo.o
<lool> NCommander: it's all the libs they call
<NCommander> lool: I manually built OOo from source end to end to get gdb traces, and still got the issue
<ramana> The exception stack unwinder should use the .ARM.exidx and .ARM.extable implementations. It doesn't have anything to do with.eh_frame.
<lool> NCommander: I'm not entirely clear on which software does the unwinding, but say that it assumes that if the first lib hsa .debug_frame or .eh_frame, then all libs do...
<lool> ramana: Ok; good to know, that pretty much kills the theory I was proposing
<NCommander> ramana: is that an ARM specific quirk? I thought eh_frame was the standard location of exception handling information
<ramana> Ncommander: Yes that is ARM quirk.
<ramana> We prefer to call it the ARM exception handling ABI :)
<NCommander> ramana: I thought ARM and ia64 shared an ABI
<ramana> not really .
<NCommander> ramana: so the difference in eh_frame information is nothing to be concerned about w.r.t. to determining our exception handling issues?
<lool> all binaries I see do have a .ARM.exidx
<ramana> Well it is something to be concerned about. I don't understand why there is a .eh_frame section in the first place.
<NCommander> ramana: I built a little C++ program that does exception handling, and it has a *very* full .eh_frame
<ramana> Is this with the lucid toolchain ?
<asac> bug 532548
<ubot4> Launchpad bug 532548 in ubuntu "[needs-packaging] [FFe] ubuntu-weboffice-zoho package for armel netbook (affects: 1)" [Wishlist,Confirmed] https://launchpad.net/bugs/532548
<NCommander> Manually built OOos have more info in the eh_frame regardless of distro
<NCommander> ramana: I'm very confused then ...
<NCommander> ramana: so then .ARM.* is passed to libgcc for unwinding versus .eh_frame/.eh_frame_hdr? (I'm thinking I need to shove some debug libgcc_s.so, assuming of course that exception handling frames are registered with libgcc_s on ARM
<NCommander> ^)
<ramana> I believe that to be the case. I'll have to ask someone else internally.
<asac> JamieBennett: sponsored zoho
<JamieBennett> asac: Cool, thanks
<asac> StevenK: ^^ maybe check in NEW in a few minutes
<asac> JamieBennett: the Exec command should open browser if %F is empty
<asac> imo
<NCommander> ramana: *grumble*, then the difference in eh_frame information was a red hairing
<NCommander> *herring
<asac> so if you click on it in the applications menu it opens xdg-open https://...zoho.com/...
<NCommander> *fish
<JamieBennett> asac: OK, that makes sense
<ramana> I don't think it's a red herring yet.
<JamieBennett> asac: let me finish this FTBFS then I'll take a look
<asac> sure
<JamieBennett> asac: what were the bugs you mentioned in your comment?
<asac> JamieBennett: the bug from above ... and icons
<asac> being wrong ... and apikey
<asac> but we dont have anything better yet ;)
<asac> also we need to verify that all the mime-types are ok somehow (or not)
<JamieBennett> asac: ah, so known bugs, thats OK, thought you'd found some more :)
<asac> nope
<asac> JamieBennett: didnt know you had the menu not doing anything on your list ;)
<asac> so somewhat new
<asac> (one)
<JamieBennett> :)
<NCommander> ramana: I have another interesting tidbet since doko pointed me to a readelf that can properly read unwind info; the karmic version has a ton of cantunwind flags in it that aren't in jaunty
<ramana> Ah good that you found that. I had pointed that out to someone last week.
<ramana> It skipped my mind to point you at it.
<NCommander> ramana: yeah, on karmic, .ARM.exidx has 233 entries, and 52 of those are marked cantunwind
<NCommander> ramana: jaunty has 332, no cantunwind
<ramana> The CANTUNWIND generation happened between the jaunty and karmic toolchains.
<NCommander> ramana: sounds like that may confirm the original theory that we're running into a CANTUNWIND where we shouldn't
<ramana> and that's the comment by the author about us debugging to find out what the problem is there.
<NCommander> ramana: but biulding with gcc 4.4 in a jaunty chroot works
<ramana> NCommander : How many of the dependencies have you rebuilt with 4.4 ? Is it just ooo that you've rebuilt ?
<NCommander> ramana: just OOo
<NCommander> ramana: I did some tests with karmic and jaunty toolchain bits. Results are in the Lp bug
<ramana> there is someone else looking at this internally I'll pass on this conversation and your comments on the LP bug.
<ramana> s/looking at this/starting to look at this
<NCommander> ramana: thats good. I think I've done a pretty good job at isolating the root cause of the bug; specifically, the phase2 unwind blowing up in our faces, but I'm not sure how we can determine what segment it dislikes
<ramana> other than poking something in libgcc's unwinder.
<NCommander> ramana: I tried that, and I felt my brain ooze
<ramana> ok
<NCommander> ramana: its not very clear to me where libgcc checks the CANTUNWIND bits, I didn't see anything as I stepped through the code with gdb.
<ramana> if you look at get_eit_entry in unwind-arm.c it's checking if the frame can't be unwound.
<JamieBennett> asac: if your in an uploading mood theres Bug #535093 and Bug #535000 :P
<ubot4> Launchpad bug 535093 in kbuild (Ubuntu) "FTBFS: kbuild fails to build on armv7l hardware (affects: 1)" [Undecided,New] https://launchpad.net/bugs/535093
<ubot4> JamieBennett: Bug 535000 on http://launchpad.net/bugs/535000 is private
<JamieBennett> doh
<JamieBennett> both are public according to launchpad
<NCommander> ramana: right, which then triggers a _URC_END_OF_STACK. If the expcetion handler hasn't been found, theres a ton of logic that causes the unwind command to return, and then finally call std::terminate()
<lool> JamieBennett: looks good
<NCommander> ramana: so at the risk of being dense, why are sectoins marked CANTUNWIND?
<JamieBennett> lool: great
<NCommander> ramana: http://sourceware.org/ml/binutils/2009-05/msg00048.html - nm, this seems to answer my question
<lool> JamieBennett: uploaded; sent to Debian and/or upstream?
<JamieBennett> lool: which one?
<lool> JamieBennett: fio
<JamieBennett> no, I'll submittodebian now
<lool> JamieBennett: kbuild > looks like this will break every now and then; can't we support arm*?
<ramana> Yes I was looking for that.
<JamieBennett> lool: Yes with a more invasive patch, this simple patch will stop the FTBFS while we work on a generic solution for all packages (dmart is looking into it)
<lool> JamieBennett: Is there another bug on the generic solution?
<NCommander> ramana: seems libgcc can actually unwind parts of the table that are marked CANTUNWIND
<NCommander> which seems to mean that CANTUNWIND really should be SHOULDNTUNWIND :-)
<JamieBennett> lool: yes
 * JamieBennett hunts for a number
<lool> JamieBennett: just mention it in your bug
<JamieBennett> OK
<lool> uploaded
<JamieBennett> lool: Thanks
<dmart> JamieBennett: "dmart is looking into it": which package is this?
<ramana> what gives you that idea ?
<JamieBennett> dmart: the generic arm detection
<JamieBennett> script
<lool> JamieBennett: actually, please rename Vcs-* fields when you change a package from Debian
<JamieBennett> lool: Oh, OK
<dmart> JamieBennett: oh, right.  I don't have a solution on that yet.
<lool> JamieBennett: uploading a fix there too
<JamieBennett> dmart: Yes, I had a simple fix for kbuild which can be done better when we have a more generic solution
<NCommander> ramana: since if the CANTUNWIND entries aren't in the linker table, it seems unwinding successes
<dmart> JamieBennett: I agree; probably best to go for a simple stopgap solution for now.
<NCommander> *successes
<NCommander> er
 * NCommander spelt it right the first time
<lool> succeeds?
<NCommander> lool: er *cough*
 * NCommander goes to relearn basic English
<persia> NCommander: Don't do that.  Odgen&Richards were smart, but there are many lost subtleties in such communication.
<lool> I guess it matters more here that you can read ARM unwind sections
<ramana> NCommander : I need to get into another meeting in a few minutes and need to finish something before that.
<ramana> Before I disappear - I'll look out for the following bits of info.
<ramana> 1. Why is there a .eh_frame being generated for exception handling in C++ for ARM ? It was my understandign that this should not happen.
<ramana> 2. Look into unwind-arm.c for more about how CANTUNWIND entries are handled .
<NCommander> ramana: for 2, it aborts the unwind
<ramana> yes it should gracefully abort the unwind but you said something about unwinding "succeeding"
<NCommander> ramana: oh, no, I said the unwind succeeds if the CANTUNWIND entries aren't there
<NCommander> (as when we build the code in jaunty)
<ramana> NCommander - ah ok .
<NCommander> ramana: if we can determine how the linker determines if something should be CANTUNWIND would be most helpful
 * NCommander suspects we're looking at a binutils regression, although its not clear when just using binutils 2.19 by itself doesn't resolve the issue
<NCommander> or bug, not sure if this is a regression or not
<ramana> well it's hard to say.
<ramana> We'll have to look into it further. I'll pass this on to the guy who'll be looking at it.
<NCommander> ramana: thanks. If you can point them my way, it would be appericated.
<ramana> I have already pointed your LP comments to him .
<NCommander> ramana: well, talking with him on IRC always helps :-)
<NCommander> http://www.engadget.com/2010/03/09/freescales-7-inch-tablet-runs-android-chrome-os-or-linux-cost/ - I want :-)
<persia> For too big :p
<persia> That resolution would be fine at 3.5"
<ramana> NCommander : are you around ?
<NCommander> ramana: yup
<ramana> mgretton has been looking at the LP bug and has some questions .
<NCommander> mgretton: what can I do to help you?
<mgretton> Hi, I'm interested in the functions privateSnippetExecutor and GetVersionInfo.  I believe these are C functions, were they compiled with -fexceptions?
<NCommander> mgretton: where are those functions?
<NCommander> oh wait
<NCommander> mgretton: privateSnippetExecutor is an ARM ASM stub
 * NCommander looks for GetVersionInfo
<mgretton> In the test case associated with bug 417009 these functions are marked 'can't unwind' and the backtrace for the test case shows that privateSnippetExecutor is in the call stack when the exception is thrown
<ubot4> Launchpad bug 417009 in openoffice.org (Ubuntu Karmic) (and 3 other projects) "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic (affects: 1)" [Low,Won't fix] https://launchpad.net/bugs/417009
<NCommander> mgretton: I don't see GetVersionInfo
<mgretton> NCommander: GetVersionInfo doesn't matter so much its privateSnippetExecutor I see in the call stack.
<NCommander> mgretton: we're not building with -fexceptions
<NCommander> mgretton: but thats an ARM ASM function (.s) thats build separately into a .o, and then linked in
<NCommander> mgretton: .cantunwind is not within the .s file, so the linker shouldn't be marking it as CANTUNWIND
<mgretton> NCommander: Are there any unwind directives at all in the .s file?
<NCommander> mgretton: no
<NCommander> mgretton: let me pastebin it
<mgretton> NCommander: ld now explicitly marks code that it can't unwind through due to lack of unwind tables as CANTUNWIND.
<NCommander> mgretton: http://paste.ubuntu.com/391906/
<NCommander> mgretton: that sounds like that might be the cause. How do we add unwind information?
<mgretton> NCommander: You need to add .fnstart, .fnend, .save, and .setfp directives into the assembly...
<Sarvatt> pixman could use some looking at to see why its not building with SIMD enabled on arm, I haven't been able to figure out why
<NCommander> mgretton: got a doc for me to look at?
<mgretton> NCommander: Write a simple hello-world program compile with -fexceptions -S and look at the assembly file produced.
<mgretton> The gas info pages have full info - I'll find a link.
<Sarvatt> it sets the -mcpu=arm1136j-s CFLAG and tries asm("uqadd8 r1, r1, r2"); in the check to see if it should enable it
<lool> Sarvatt: I see that in the code, but I don't have any clue why it would fail either
<mgretton> NCommander: See http://sourceware.org/binutils/docs-2.20/as/ARM-Directives.html#ARM-Directives
<lool> Hmm it's prepended to CFLAGS though
<NCommander> mgretton: how'd you determine that there was no unwind info for privateSnippetExecutor out of curiosity?
<lool> but we dont pass anything fancy, so shouldn't matter
<lool> So that would be a v6 instruction hmm
<mgretton> NCommander: I used readelf from a very recent trunk binutils which will decode unwind tables, and looked for the areas of code marked CANTUNWIND, and then mapped that to functions.
<NCommander> mgretton: ah!
<mgretton> NCommander: I then checked the call frame and privateSnippetExecutor became the immediate suspect.
<lool> Sarvatt: /tmp/cciD0vDI.s:37: Error: selected processor does not support `uqadd8 r1,r1,r2'
<lool> configure:12379: gcc -c -mcpu=arm1136j-s -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden  conftest.c >&5
<lool> Sarvatt: Could it be that uqadd8 is a vfp instructions which we dont turn on by default?  Or perhaps a NEON one?
<lool> I didn't find it in the ARM reference manual
<NCommander> mgretton: test building my first try
<ramana> NCommander: After fixing this, the question still remains about why there is a .eh_frame section. Talking to other folks around and looking at stuff makes me believe that's also something which is not correct and should be looked at .
<lool> mgretton: Ah, could it be it's an ARM only instruction, and isn't available under Thumb?
<lool> err s/mgretton/Sarvatt
<NCommander> mgretton: well, for my first attempt, the program just blows up versus reaching std::terminate :-)
 * NCommander guesses he didn't quite get everything right
<mgretton> NCommander: Do you mind binpasting your attempt and I'll take a quick look as well?
<NCommander> mgretton: sure, let me just try one other thing before I post it
<lool> Sarvatt: checking whether to use ARM SIMD assembler... yes
<lool> Sarvatt: That's with CFLAGS=-marm
<Sarvatt> if -mcpu is prepended is the gcc default that gets added at the end overriding the first one?
<lool> Sarvatt: No, the gcc defaults isn't added at the end; it's the default CPU mode which causes it
<lool> We switched to -mthumb by default in lucid, and -mthumb lacks uqadd; only -marm has it
<lool> Sarvatt: Mind opening a bug on that?
<NCommander> mgretton: http://paste.ubuntu.com/391919/ - if I remove the saves, I don't get a crash, but it just hangs
<lool> Sarvatt: Quick workaround for you: add CFLAGS+=-marm in debian/rules
<NCommander> mgretton: with this, I get the terminate message again (phase2 unwind error)
<mgretton> NCommander: Before mov ip, sp add a .movsp ip directive, before the sub fp, ip, #4 add a .setfp ip, #4 directive and see what happens.
<NCommander> mgretton: I admit my ARM ASM isn't so good :-/
<mgretton> NCommander: If that doesn't work change the .setfp ip, #4 to .setfp ip, #-4
<NCommander> mgretton: .setfp needs two arguments
<NCommander> I think that has to be .setfp fp, ip, #4
<mgretton> NCommander: Sorry .setfp fp, ip, #4 (or .setfp fp, ip, #-4)
<lool> mgretton: According to the binutils doc you pointed at earlier, #4 seems correct
<Sarvatt> sure thing lool, can we just patch configure.ac to add -marm to the check?
<mgretton> NComamnder: Yes but its the opposite of what GCC produces...
<lool> Sarvatt: I need to dive a bit in where that's actually used
<lool> Sarvatt: Adding -marm in configure is probably not a good idea
<Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/535183
<NCommander> mgretton: no luck with either one. with .setfp ip, #4, I get to std::terminate
<ubot4> Launchpad bug 535183 in pixman (Ubuntu) "pixman doesn't autodetect SIMD support at build time on arm. (affects: 1)" [Undecided,New]
<NCommander> mgretton: with #-4, it just quits, no message
<lool> Sarvatt: So I had a look, and it's used in the middle of pixman/pixman-cpu.c
<napster> Where I can get a uImage file?
<lool> Sarvatt: Hmm sorry, apparently for libpixman-arm-simd.la only
<Sarvatt> thats the runtime autodetection code I think?
<lool> Which has pixman-arm-simd.c only
<lool> Sarvatt: So it would appear to be ok to pass -marm in pixman-arm-simd.c
<lool> Sarvatt: However note that this means that the code will be switching to arm-mode whenever it's jumped to
<lool> Sarvatt: Would it be possible to rewrite the functions in thumb instead?
<ogra> wasnt pixman on the thumb2 porting page ?
<mgretton> NCommander: Not sure - have all C files been compiled with -fexceptions as well? (main.c springs to mind in the call stack in the image we're looking at)
 * ogra cant remember but i thought i saw it
<NCommander> mgretton: not explicately
<ogra> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList yep
<dmart> I think pixman was on the list, but flagged as done
<NCommander> mgretton: I'd have to rebuild OOo from scratch to force -fexceptions to be built, but thats going to take days
<ogra> https://bugs.launchpad.net/ubuntu/+bug/514237
<ubot4> Launchpad bug 514237 in pixman (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid]
<ogra> invalid
<lool> was marked as invalid though
<lool> ogra: it was listed for something else
<mgretton> NCommander: All files need to have exception unwind information added to them.  Sorry - that sound horrible.
<ogra> yeah for mov
<dmart> Our greps couldn't tell the difference between broken and non-broken asm, but pixman has been under recent maintenance and should work fine.
<lool> dmart: Problem is that it uses uqadd which isn't available in thumb mode
<mgretton> NCommander: You'll also need the right fix for privateSnippetExecutor that we might have worked out above :-)
<lool> dmart: Do you have a suggestion on replacing it, or should we just build the arm_composite_add_8000_8000() routine in arm mode?
<lool> (and others)
<lool> Basically the whole pixman/pixman-arm-simd.c file
<NCommander> mgretton: ugh, that seems broken.
<NCommander> mgretton: we shouldn't need -fexceptions on ARM where no other architecture requires it
<ogra> NCommander, if it makes it work its still a better workaround than shipping a jaunty binary .so though
<NCommander> ogra: that's true
<NCommander> mgretton: at the risk of being dense, main.c isn't part of the UNO library that has the issue
<NCommander> mgretton: so I'm not sure that being built with -fexceptions would change anything
<mgretton> NCommander: Agreed.
<lool> dmart: Also, I'm thinking perhaps we should grep for uqadd?
<NCommander> mgretton: how can I determine if we're actually emitting unwind info? (i.e., our fix is correct and ld isn't doing something stupid silently)
<mgretton> NCommander: Where are we expecting this exception to be caught?
<NCommander> mgretton: er, you haven't seen the code, have you?
<mgretton> NCommander: Grab and build a trunk binutils and use readelf...
<NCommander> mgretton: I already have a patched version, just not sure what to look for in the output :-)
<dmart> lool: possibly; I hadn't previously been aware of that one.
<NCommander> mgretton: we're bypassing throw(), and calling __cxa_throw directly :-/
<NCommander> mgretton: it should end up landing in deleteException in UNO before being rethrown
<dmart> The quickest solution is simply to build the affected parts of pixman for ARM (or all of it)
<lool> dmart: Yes; but Sarvatt is upstream apparently; what would the proper upstream fix be?
<lool> dmart: They have a separate file and separate CFLAGS for it, so -marm doesn't sound too bad
<mgretton> NCommander: readelf -u will dump the unwind tables.  Look for PrivateSnipperExecutor in the tables
<NCommander> mgretton: ok, so I have an unwind table entry for it
<NCommander> woo
<NCommander> (not sure its correct, but its close enough that we're not breaking the stack over it)
<mgretton> NCommander: I'm afraid I've got to go.  I'll have a think about this and come back tomorrow with any other thoughts.
<lool> Sarvatt: At least for now, s/ARM_SIMD_CFLAGS="-mcpu=arm1136j-s"/ARM_SIMD_CFLAGS="-mcpu=arm1136j-s -marm"/ would be fine
<NCommander> mgretton: fair enough. Is there a way to get the old linker behavior back?
<NCommander> (some sorta LDFLAG or something?)
<dmart> lool: Is the build log on launchpad?  uqadd8 is available in Thumb-2
<lool> Sarvatt: I don't know whether there's a high cost in switching between thumb and arm, nor whether comparable instructions exist in thumb mode
<lool> dmart: I can reproduce here
<lool> dmart: Yes, it's on launchpda
<dmart> Can you paste me a log?
<mgretton> NCommander: No - you need to revert the original patch that added the functionality.
<lool> dmart: http://launchpadlibrarian.net/38024749/buildlog_ubuntu-lucid-armel.pixman_0.16.4-1_FULLYBUILT.txt.gz
<lool> dmart: (was looking it up)
<lool> dmart: checking whether to use ARM SIMD assembler... no
<NCommander> mgretton: I'm going to guess we want this cantunwind functionality?
<lool> dmart: I can reproduce with ./configure in an arm qmeu chroot here, and CFLAGS=-marm passes!
<NCommander> mgretton: (I should note that I tried using an earlier binutils from 2.19 on karmic, which we built OOo with before, and I still got a broken library build)
<dmart> Can you paste me your failing log?
<dmart> lool: ^
<lool> dmart: the launchpad log is the failing one
<lool> dmart: Oh you mean config.log?
<mgretton> NCommander: Yes - its better than the alternative - that we unwind using a different function's unwind table.
<NCommander> mgretton: *grumble* :-/
<lool> dmart: 18:08 < lool> Sarvatt: /tmp/cciD0vDI.s:37: Error: selected processor does not  support `uqadd8 r1,r1,r2'
<lool> 18:08 < lool> configure:12379: gcc -c -mcpu=arm1136j-s -g -O2 -Wall  -fno-strict-aliasing -fvisibility=hidden  conftest.c >&5
<lool> (above)
<NCommander> mgretton: I have no good ideas where to go from here, hopefully you'll get a brainwave later today
<lool> dmart: Ah I know, they force a CPU which has an older thumb2 implementation -- could that explain?
<mgretton> NCommander: Original change here: http://sourceware.org/ml/binutils/2009-05/msg00048.html
 * mgretton is back
 * mgretton is back
<NCommander> mgretton: that was quick
<mgretton> NCommander: I'm really going this time :-)
<dmart> lool: -mcpu=arm1136j-s [-mthumb] will be broken, because Thumb-1 doesn't have these instructions.  Do you know why it's building for ARM1136?
<NCommander> mgretton: heh
<lool> dmart: I guess earliest CPU adding quadd
<ogra> NCommander, thats ARMs "instant on" function :)
<ogra> gets you such quick suspend/resume cycles
<NCommander> ogra: hrm, what I need is an ARM enginneer fork() function so I can have one always available versus having them be a shared resource :-)
<dmart> lool: We had in instance of this in something before: the build must not downgrade -mcpu or -march in order to "turn on" features.  If you just build this file with the Ubuntu defaults (-march=armv7-a -mhumb) I believe it should work.
<lool> dmart: Testing CFLAGS=-mcpu=cortex-a8 right now
<dmart> lool: that should work, yes
<lool> dmart: The thing is that they likely want to turn it on under Debian for instance
<lool> dmart: It's a separate function which only gets called if auxv says v6 is preesnt
<lool> It passes
<dmart> lool: I think you need two tests for this:
<lool> Sarvatt: So the bug is in that -mcpu= you're setting, it's incompatble with Ubuntu's -mthumb default; let's find something
<dmart> lool: echo '... uqadd8 blah ...' | gcc => if OK then turn on this file and build it with default opts
<dmart> otherwise
<lool> dmart: Well AC_TRY_COMPILE, but right
<dmart> lool: echo '... uqadd8 blah ...' | gcc -mcpu=arm1136j-s => if OK then turn on this file and build it the overridden opts
<dmart> (I know, but it's pseudocode anyway)
<dmart> ...if neither works, turn off that file.
<lool> dmart: I would like you to please talk autoconf on this chan
<lool> pseuco-code is not an acceptable conduct!
<lool> :-P
<dmart> meh
<lool> dmart: Ok will try cooking some autofoo for Sarvatt if he like
<lool> s
<dmart> anyway, I think that's the answer; you need 2 tests to determine the right options
<dmart> NCommander: fork: Resourse temporarily unavailable
<dmart> ;)
<NCommander> dmart: thats not a valid error code from fork() :-)
<NCommander> dmart: sounds like your having some issues with too many threads touching errno
<dmart> fork(8)
<dmart> ...
<dmart> ERRORS
<dmart>        EAGAIN fork() cannot allocate sufficient memory to  copy  the  parent's ...
<dmart> Cygwin does this to me a lot for no reason...
<dmart> ...but I digress...
<NCommander> dmart: I thought EAGAIN translated to a different strerror() message ...
 * NCommander might be wrong
<dmart> ah, maybe.  It wasn't a good joke anyway...
<NCommander> dmart: yes, but we're geeks for understanding it anyway :-)
<lool> Sarvatt, dmart: http://paste.ubuntu.com/391944/
<lool> (untested)
<dmart> I think the second test needs ARM_SIMD_CFLAGS="-mcpu=arm1136j-s -marm"
<dmart> ...if the toolchain might default to Thumb
<dmart> (may not be an issue for Debian though?)
<lool> dmart: good point
<lool> http://paste.ubuntu.com/391946/
<dmart> Makes sense, I guess.
 * dmart has to disappear...
<lool> Sarvatt: checking whether to use ARM SIMD assembler... yes
<lool> with the second patch
<lool> Sarvatt: Could you merge that upstream?
<ssvb> lool, Sarvatt: just send a patch to http://lists.freedesktop.org/mailman/listinfo/pixman it should not make arm simd (aka armv6) support any worse
<Sarvatt> sure thing, sorry I'm at work at the moment and missed all that earlier. I will upstream it, no problems :)
<Sarvatt> thanks for looking into it and fixing it, I wasn't having any luck
<lool> Sarvatt: I just subscribed to the pixman list; shall I send it here, or will you just pick it up from the bug report?
<lool> ssvb: thanks for the pointer ^ btw
<Sarvatt> ah that works, was just about to ask you for attribution info and such :)
<lool> Sarvatt: sent there
<lool> JamieBennett: https://launchpad.net/ubuntu/+source/kbuild/1:0.1.98svn2318-4ubuntu1/+build/1552
<lool> 656/+files/buildlog_ubuntu-lucid-armel.kbuild_1:0.1.98svn2318-4ubuntu1_BUILDING.
<lool> txt.gz
<lool> kbuild failed to build on armel
<lool> and mutt ate my link
<lool> JamieBennett: Actually:  * State: Failed to upload
<lool> JamieBennett: It seems this was retried, so don't worry
<JamieBennett> lool: so what was the problem?
<lool> Sarvatt: Sorry for the lack of proper From:
<lool> JamieBennett: Dunno, transient buildd upload failure
<lool> e.g. connection reset or something
<lool> JamieBennett: apparently it reached the archive
<JamieBennett> lool: OK
<pdxspork_> Anyone got experience with the OMAP2 hsmmc driver?
<DanaG> weird... the rcn-ee 2.6.33 kernel doesn't get any input from the "twl4030_powerbutton" input device.
<lool> apw: I guess you saw -dove failed to build due to perf trying to include/link libelf
<guilhem> hi all
<lool> hi
 * lool wnders off
<guilhem> I'm building a arm system to run ubuntu from scratch and i'm having some trouble to make the kernel deb that rootstock need does someone knows where I can find some help on this topic ?
<guilhem> I have tried to make deb-dpkg but when it arrives at dpkg-gencontrol it tels me gcc arm-eabi uncnown :/
<lool> guilhem: rootstock should fetch the kernel that it needs itself
<lool> guilhem: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/ this kernel works with rootstock AFAIK
<guilhem> yeah I know that in fact i need to make it clean to be able to share with others
<guilhem> in fact i need to build my own kernel
<guilhem> what i'm doing is that i'm building ubuntu on nvidia platform
<guilhem> and the only bootloader available today is fastboot which boot my zImage flrom flash and then should mount the rootfs from the memory stick sda1
<guilhem> I have managed to boot the memory stick and mount the ext3 filesystem
<guilhem> but now I want to put ubuntu on top of that
<guilhem> and it's a litle bit dark for me
<guilhem> I have understand that i should build my rootfs with rootstock and then put my vmlinuz & modules on the rootfs
<guilhem> but when i try to boot this i get a kernel panic after mounting the filesystem
<guilhem> [42949392.430000] PC is at setup_arg_pages+0x28/0x20c
<guilhem> [42949392.440000] LR is at load_elf_binary+0x3fc/0x1268
<guilhem> anyone knows ? :|
<apw> lool ... dove should have that turned off ... hrm
<rcn-ee> guilhem, just catching up on the irc log, did you solve your create deb image problem?
<Bre> hi
#ubuntu-arm 2010-03-10
<Bre> where would i be able to get an ARM devboard from?
<Bre> can't seem to find these marvell dove boards on marvells website
<rcn-ee> Bre, the dove isn't very easy to find...  Freescale's i.mx515 is sold by a company that's name escapes me for the moment... Other wise there are ton of omap35xx (cortex-a8) based boards...
<Bre> is that the beagleboard?
<rcn-ee> beagleboard, overo, igep2, allwaysinnovating, etc.... yes..
<Bre> ah ok seen those for sale yeah
<Bre> we use some omap flavour at work
<persia> After playing with moserial a bit, it seems *way* better than all the other tools we have to manage serial consoles.
<ogra> lool, so i finally have a setup to strace apt ... it simply hangs in read()
<ogra> looking at top apt-get only consumes a maximum of about 50% CPU
<ogra> dpkg about 10%
<ogra> nothing that looks serious at all
<ogra> aha, now apt-get CPU usage rasies above 90% ... and i dont see any dpkg processes anymore (strace didnt change though)
<lool> ogra: Which kernel are you using?
<ogra> the archive netinst kernel
<ogra> no initramfs
<lool> It might be that you uncovered a race in apt or in qemu
<ogra> i tried to stay as close to the rootstock setup as possible
<lool> You want to gdb apt I guess
<ogra> well, that means i need to start over :( indeed i dont have a dbgsym package in the VM and next run of apt will work
 * ogra curses how time consuming all this is
<ogra> i wonder when apt was built last
<ogra> hmm, feb 02
<lool> ogra: You can dpkg install it
<ogra> err 03
<lool> You don't need to apt install -dbgsym
<ogra> lool, but it wont replace the running process
<lool> ogra: It doesn't affect processes
<lool> ogra: gdb will pick up the symbols....
<ogra> oh, right
<ogra> lool, no way ... db is locked
<ogra> bah and scp hangs ... i cant copy the strace log :/
<ogra> ah, just took a bit
<lool> ogra: Just dpkg-deb unpack it
<ogra> to late
 * ogra killed the VM and already rebuilds a qemu minimal image
<ogra> i'll just make sure to have all possible requirements installed this time in advance
<ogra> http://launchpadlibrarian.net/40681851/apt-strace.log is the strace btw ...
<ogra> i think the read is apt reading from dpkg here
<ogra> so i think its more likely a dpkg bug than apt
<asac> ogra: did you ever get mxc_ts working?
<asac> touchscreen?
<asac> (EE) PreInit returned NULL for ""mxc_ts""
<lool> babbage 3 has a touchscreen?
<asac> not sure ;) X complains about it
<ogra> it has a touchscreen interface
<ogra> asac, ask persia :) i think the netwalker has a touchscreen
<lool> It does
 * persia is trying to fixure out which one
<ogra> you might need a patches tslib for it
<ogra> *patched
<persia> Yeah, it's mxc_ts
<ogra> and probably a udev rule we dont have atm
 * persia checks for tslib patches
<persia> ogra: Wouldn't I have most of it on the Netwalker?
<ogra> persia, definately
 * ogra checks the bsp
<ogra> whee, there are a bunch of tslib patches in there
<persia> Doesn't need tslib patches.  Netwalker is running 1.0-4ubuntu2 uploaded by NCommander.
<persia> And I don't have a udev rule for mxc_ts (although I do have ones for mxc_iim and mxc_vpu)
<persia> So I think it just works if the kernel does the right thing.
<persia> Unless there's somewhere else I should be looking.
<ogra> geez there is a huge patch that enables input events in tslib
<ogra> ah, most is autofoo
<ogra> persia, seems most of the patches i see are changes to ts.conf
<persia> Where is that file?
<ogra> and this one: http://paste.ubuntu.com/392488/
<persia> /etc/ _
<ogra> the ts.conf should be in /etc
<persia> I'm running stock Jaunty /etc/ts.conf : no changes.
<persia> And I really don't have that udev rule.
<ogra> -# module_raw input
<ogra> +module_raw input
<persia> Hrm?  I'm not showing any patches, but I have "module_raw input" rather than "# ..."
<ogra> do you have module_raw commented ?
<ogra> right, so that seems to be upstream
<ogra> the rules should be in /etc/udev/ltib/10-imx.rules
<persia> I *don't* have module_raw commented.
<ogra> yes
<persia> But I think we already uncomment in Ubuntu.
<ogra> yes
<persia> `grep -r mxc /etc/udev/rules.d/*` doesn't show those rules.
<persia> I don't have /dev/input/keyboard or /dev/input/ts0, but I don't really care, because it works anyway.
<ogra> heh
<ogra> do you have an xorg.conf ?
 * persia has a bundle of /dev/input/event* 
<persia> I do, but it's 0 bytes long.
<ogra> weird
<persia> Why?
<asac> ogra: did you have a working xorg.conf?
<ogra> asac, for imx gpu stuff ? no
<ogra> well, i did once
<asac> ok
<ogra> but dont have it anymore
<asac> i am looking at the fbdev code and wonder how that does the probing
<ogra> iirc you only need to add the right driver line
<asac> seems it only does that for PCI
<ogra> right
<asac> how does it work for us then?
<ogra> forget about autoprobing
<asac> well. i want to understand how the fbdev code does it ;)
<ogra> NCommander did look into fb probing quite a while ago
<persia> Works for me.  If someone identifies a package, I can hunt a patch.
<ogra> UGH !
<asac> seems that we probe for fbdev properly
<asac> but i dont see how that is happening
<ogra> i wonder if the clock issues we have with resets are based on the fact that we dont have mxc_rtc enabled at all
<asac> ah so you get resets too now?
<asac> ;)
<persia> http://paste.ubuntu.com/392496/
<ogra> well, i have seen your issue when i removed power
<ogra> # CONFIG_RTC_DRV_MXC_V2 is not set
<ogra> # CONFIG_RTC_MXC is not set
<ogra> persia, LoadModule: "evtouch"
<ogra> heh
<ogra> you dont use tslib at all
 * ogra pats good old evtouch
<persia> Well, that explains it :)
<ogra> to sad it wont work with the new xinput model
<persia> Why not?
<ogra> nobody ported it
<ogra> the desktop team took over touchscreens
<ogra> but at "very low prio"
<asac> ogra: file a bug and get cooloney look
<asac> so anyone can explain why our X auto selects fb?
<asac> ;)
<ogra> asac, well, i'D like to find our old conversation first, there must be a reason why we use mc13892 instead of mxc_rtc
<ogra> asac, yes, NCommander should be able to
<asac> NCommander: there?
<asac> oh seems its doing pci access
<asac> ah ... ok
<ogra> i think it iterates iver fb devices in a hardcoided manner if it doesnt find anything on pci ... but i'm not sure i remember correctly
<asac> there is some stuff i cant even find a header for
<asac> fbdevHWInit
<asac> forinstance
<asac> oh got it
<asac> ok seems fbdev is somewhat hardcoded ;)
<asac> or i am missing something ... if i ship the imx_drv.so as fbdev.so ... it will use that ;)
 * asac goes #ubuntu-x
<lool> can someone send the contents of /proc/fb on dove?
<lool> plars, saeed: Hey, would you mind sharing the contents of /proc/fb on dove?  it's for asac
<lool> asac: ^
<saeed> hi all
<saeed> 0 GFX Layer 0 1 Video Layer 0 2 GFX Layer 1 3 Video Layer 1
<saeed> I have lcd and vga (two fb) enabled
<saeed> lool, asac: xawtv fails on lucid
<lool> saeed: Do you know why it doens't display the kernel driver name?
<lool> saeed: asac is looking at extending the xorg-server logic to select a fb driver for ARM depending on the contents of /proc/fb; on x86, it nicely containts the kernel drivers
<lool> But on ARM, these are descriptive strings instead   :-/
<saeed> lool: no idea, I'll forward your q to the lcd drivers maintainer
<asac> saeed: lool: thanks. much appreciated
<asac> (II) EXA(0): Offscreen pixmap area of 31981568 bytes
<asac> (II) EXA(0): Driver registered support for the following operations:
<asac> (II)         Solid
<asac> (II)         Copy
<asac> (II)         Composite (RENDER acceleration)
<asac> (II)         UploadToScreen
<asac> (II)         DownloadFromScreen
<asac> (II) FBDEV(0): IMX EXA acceleration setup successful
<asac> ;)
<persia> That looks kinda familiar :)
<ogra> asac, now use xranrd and see it explode
<asac> ogra: you ask for too much ;) ... i dont even have a monitor connected atm. fighting on other fronts first ;)
<ogra> composite ?
<ogra> wow the version i tested in karmic definately didnt have that
<asac> ogra:
<asac> asac@babbage2:~$ xrandr
<asac> Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
<asac> VGA1 disconnected (normal left inverted right x axis y axis)
<asac> LVDS1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 246mm x 185mm 1024x768       50.0*+   85.0     75.0     70.1     60.0     40.0   832x624        74.6   800x600        85.1     72.2     75.0     60.3     56.2   640x480        85.0     72.8     75.0     60.0     59.9   720x400        85.0   640x400        85.1   640x350        85.1
<asac> no crash ;)
<ogra> well, but only 1024x768
<asac> no monitor connected
<asac> let me do that ;)
<ogra> is your monitor limited to that ?
<ogra> ah
<ogra> but no crash is a good thing
<ogra> for me it did crash
<ogra> but that was a pre-pre-pre-pre...-pre-release
<ogra> though i could bump the resolution to 1440x900 with an xorg.conf
<asac> so yeah xrandr doesnt see that i have a great monitor
<asac> hmm
<ogra> right, the EDID code still needs love
<asac> too bad that netbook-launcher doesnt install
<asac> would like to see if that works
<ogra> does here
<asac> right. seems its a problem if you run apt-get instlal from minimal
 * ogra is just running apt-get install ubuntu-netbook^ 
<ogra> for the third time today
<ogra> on top of minimal
<ogra> (note i'm installing a task, not a metapackage)
<ogra> though the task shouldnt make a difference to the metapackage in that case
<asac> wow
<asac> it only worked when i did this:
<asac> sudo apt-get install netbook-launcher libbonoboui2-0 libgnome2-0 gvfs libgdu0 udisks libparted0
<asac> had to specify those manually
<asac> hmm
<asac> odd
<ogra> something is clearly screwed on your setup
<asac> heh
<asac> not sure how ;)
<asac> my setups usually work forever
<ogra> was your minimal install up to date ?
<asac> sure
<asac> oh
<asac> libparted1.8-12
<ogra> ah
<asac> needed to be removed
<asac> that was holding it
<asac> not sure how i got that
 * asac hopes it was a intermediate packaging bug
<ogra> nobody else sees it :)
<asac> nobody runs a minmal system and installs from there
<asac> but i think it was fixed ;)
<ogra> i do every day :)
<ogra> rootstock FTW :) its our best archive tester
<asac> but you rewinstall all the time
<asac> mine came from upgrading
<ogra> ah
<ogra> indeed i do a fresh minimal and then dump a netbook task on top
<saeed> plars: any idea how to make paplay work?
<saeed> aplay works fine to me on dove
<plars> saeed: in my tests, I was seeing it had some relation to sampling rate of the file I was trying to play
<plars> saeed: see 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,New] https://launchpad.net/bugs/528524
<plars> saeed: unfortunately I'm blocked on doing much further at the moment, my board isn't working well (possibly bad memory)
<saeed> is dove x0 rev 1.4?
<saeed> plars: i tried paplay /usr/share/sounds/alsa/Side_Left.wav, but I hear nothing
<plars> saeed: interesting, could you try paplay /usr/share/sounds/gnome/default/alerts/bark.ogg and paplay /usr/share/sounds/gnome/default/alerts/sonar.ogg
<saeed> plars: silence
<plars> saeed: on both?
<saeed> yes
<saeed> plars: with aplay, I have to run with sudo
<plars> saeed: oh, did you adjust settings in alsamixer?
<plars> saeed: see: http://launchpadlibrarian.net/33792996/alsamixer.png for what it should look like
<saeed> plars: yes, I've this settings
<saeed> how can I check that pulseaudio uses the sound controls I've on the board?
<Who_> Has anyone got experience building xbmc for ARM? I've got GLES working on my IGEP and I would like to try to get xbmc working...
<plars> saeed: odd... I did have a Y1 board for a while that I could not get *any* sound out of, no matter what.  GrueMaster had much better success with his, even with the same settings.  I never fully resolved before trading it out for the x0, but assumed it was possibly just a hardware problem on my board
<dmart> NCommander: ping
<plars> saeed: how about calling aplay on those wav files mentioned in that bug? does that work on any of them?
<saeed> plars: aplay works fine
<plars> saeed: or another thing to try might be: speaker-test -t wav -r 48000 and speaker-test -t wav -r 44100
<plars> does one work, and the other does not?
 * ogra doesnt get it ...
<ogra> seems i cant reproduce the apt hang anymore
<ogra> i reproduced it twice today ... very reliable ... then glib got out of sync ... now ubuntu-netbook just installs
 * ogra scratches heads
<ogra> -s
<ramana> dmart: ping
<dmart> Hi
<saeed> plars: sudo speaker-test  -t wav -r 48000 works
<saeed> plars:  speaker-test -t wav -r 44100 fails on bad sample rate
<plars> saeed: so it sounds like you are seeing basically what I was, but also paplay not playing *anything*
<plars> saeed: could you update the bug with your observations, and possibly collect the log files they were asking for?  Would be nice to move the bug forward, but I can't in my current state until I get working board again
<Who_> Has anyone compiled omapfbplay for Ubuntu? I had a bit of a go last night (cross compiling) but didn't get too far - I'd appreciated pointers! Or, anyone know a good way to get smooth video on OMAP3/Ubuntu?
<asac> hmm isnt there a trick to change SONAME for binary lib?
<dmart> If the new name is the same length or shorter, you might be able to hack the string directly, but otherwise some tables would need to be rebuiilt --- I don't know of a tool which can do this.  (Stripped) binaries might not contain enough info to do it safely.
<asac> yeah ok
<asac> so no chance i guess
<asac> i would like to append something ;)
<dmart> Unfortunately you probably have to relink :/
<dmart> You could create an empty proxy library with the right soname which pulls the second one in, but that's a bit of a hack
<asac> nah ,)
<asac> we have to live with it unverseoined then ;)
<dmart> NCommander: ping
<KjetilK> Hi all! I just came across this: http://news.softpedia.com/news/Acer-Prepares-Freescale-i-MX515-Powered-Smart-Monitor-131435.shtml
<KjetilK> and it occured to me that the monitor could be ideal for running a mythfrontend and X server only, assuming it has the power...
<KjetilK> I don't know if mythtv-frontend is packaged for ARM, but would it be realistic to do something like that with Ubuntu?
<now3d> Hi All
<now3d> Has anyone been able to get the ARM port working on Datawind Ubisurfer?
<now3d> It is an ARM9, rather than ARM7
<Martyn> You are mixing up arm7 and armv7
<Martyn> (v7 is the generation of the processor architecture)
<Martyn> an ARM9 chip is actually a v5 processor, and thus not supported by ubuntu
<Martyn> ( arm versions are like intel numbering -- i386/486/686.. etc )
<now3d> Martyn: Thanks for clarifying.
<Martyn> ARM926EJ-S rev 5 (v5l)
<Martyn> (according to my quick bit of research)
<Martyn> This is therefore probably supported by upstream debian though
<Martyn> so you should, in theory, be able to get it running debian Lenny
<now3d> Martyn: I don't know what distro the Ubisurfer currently runs, so someone must have ported to it.  However, have not been able to find out any more. Datawind have not responded to my emial
<Martyn> it runs 8.04
<Martyn> 9.04/9.10 dropped support for v5
<Martyn> 10.4 drops support for v6
<now3d> I see that version now on this output: http://www.linuxquestions.org/questions/linux-laptop-and-netbook-25/datawind-ubisurfer-784464/
<now3d> Martyn: Do you know if anyone tested running 8.04 on Ubisurfer? I saw only some development boards by Marvel were listed as officially working.
<Martyn> no idea
<Martyn> sorry :(
<now3d> no probs.
<now3d> I was looknig for an ARM netbook, not found one yet.. well only this ubisurfer
<plars> now3d: there are these: http://www.pocketables.net/2009/09/first-impressions-of-the-sharp-netwalker-pcz1.html
<plars> now3d: from what I understand, pretty difficult to acquire if you are not in japan though
<now3d> thanks for the tip!
<now3d> ok, logging off now. thanks for help
<plars> now3d: ah, don't know how reputable the site is, but I did find one place that claims you can order
<plars> doh
<plars> http://www.geekstuff4u.com/sharp-netwalker-pc-z1.html for anyone else who might be interested
#ubuntu-arm 2010-03-11
<persia> conics.net also ships the NetWalker worldwide
<ericnj> Hi guys, is it possible to get armel on Palm Tungsten T3?
 * persia checks for specs
<persia> ericnj: You might be able to shove 9.04 on it, but nothing newer.  I'd recommend trying to install Debian on that device.
<ericnj> where can I get a ready made image,  rootfs?
<ericnj> 9.04 is fine for me, just want minimal with light widows manager.
<persia> There aren't any images for the Palm Tunsten T3.
<ericnj> can I use the instruction on https://wiki.ubuntu.com/ARM/RootfsFromScratch?
<persia> The babbage image from http://cdimage.ubuntu.com/ports/releases/jaunty/release/ will have an extractable rootfs for all of desktop (but that might need too much RAM)
<persia> Yes.  Those instructions should work fine (you got the URL faster than I)
<ericnj> what is the smallest image size I can use on the rootstock?
<ericnj> I want to install it on a SD card
<persia> I don't know precisely about "smallest".  The buildd minimal chroots are about 60MB after bzip2, so maybe a couple hundred MB?
<persia> Try installing the ubuntu-minimal task only, and see what that gets you.
<ericnj> Do I have to do it with qemu?
<persia> No, but that's easiest.
<persia> So, there are two ways to construct a chroot that are fairly easy.
<persia> 1) If you have a current Ubuntu armel install, you can use debootstrap.  This may or may not work for some Debian installs, depending on a number of factors.
<ericnj> ok, I'm listening
<persia> 2) If you have an Ubuntu install on i386 or amd64 (and potentially other architectures, but not well tested), you can use rootstock to run debootstrap in an emulated environment.
<persia> There are, of course, N other ways, but neither is as easy as those.
<ericnj> can you send me some instruction on my e-mail?
<ericnj> I'm a noobie
<persia> What sort of instruction, and for which path?
<persia> and I'd much prefer to work with you interactively to sort it, rather than trying to write some customised documentation..
<ericnj> I understand
<tkmedia> yes and others may bennefit from it
<persia> That too :)
<tkmedia> ;)
<ericnj> I've tried the instructions on the above page and that's what I've got at the end of my log file: Reading package lists... 99%  Reading package lists... Error!  E: Unable to write mmap - msync (28 No space left on device) E: The package lists or status file could not be parsed or opened. Kernel panic - not syncing: Attempted to kill init! I: Killed ...
<persia> That usually means you need to pass a larger value to --imagesize
<tkmedia> if if setup ubuhntu-armel I should be able to debbostrap lenny right ?
<persia> tkmedia: That *should* work, but it's not well tested.  There is a small chance that there are some internetworking issues that could be exposed.
<ericnj> thanks, I'll try that
<tkmedia> k
<persia> tkmedia: If you are up for testing and reporting any bugs, that would be great.  I'd much prefer if we could support that use case.
<tkmedia> can i setup ubuntu-armel in kvm by chance ?
<Martyn> ??
<Martyn> I thought there was zero KVM support in armel.
<Martyn> There's no hardware support for hypervisor functions...
<Martyn> (TrustZone doesn't provide the right kinds of abstraction)
<persia> tkmedia: You can't in kvm.  You can in qemu-kvm.  I personally use `mk-sbuild --arch=armel lucid` to create build chroots (works in lucid)
<persia> tkmedia: Also, read https://wiki.ubuntu.com/ARM/RootfsFromScratch for richer instructions on getting something running in real qemu, rather than just a chroot.
<tkmedia> yep tried that
<tkmedia> unfortunately i have arm 4
<persia> Then you can't run Ubuntu anyway.
<tkmedia> hence then lenny deboostrap question
<persia> aha!
<persia> You might do better to try to port rootstock to work also with Debian, and then just build your Debian rootfs directly.
<tkmedia> am i way off
<persia> No, but I think you're doing it the hard way :)
<tkmedia> k
<tkmedia> what else is new
<tkmedia> if there is a hard way ... i seem to find it
<tkmedia> i guess i should jkust suck it up and build a qemu
<persia> tkmedia: What are you trying to accomplish as an end goal?
<tkmedia> but i have proxmox and it makes kvm soooo easy
<tkmedia> good question
<tkmedia> dev environtment under lenny iguess
<tkmedia> ARM 4
<persia> kvm doesn't deal well with cross-architecture things.  Works *great* for i386/amd64/powerpc as long as the guest architecture matches the host architecture, but that's not usually the case here.
<persia> tkmedia: What hardware?
<tkmedia> samsung 9
<tkmedia> mini2440
<tkmedia> 7-10 touch screen
<tkmedia> maybe a cortex board is better
<tkmedia> ?
<tkmedia> wall mount
<persia> If you're just looking for an electronic picture frame, a newer board is a waste of power.
<tkmedia> http://www.friendlyarm.net/products/mini2440
<persia> http://code.google.com/p/mini2440/wiki/EmdebianChroot might be a reasonable place to start.
<tkmedia> yep i keep ending up back there
<tkmedia> so iguess i should stop fighting that
<persia> It oughtn't be that hard to generalise the emdebian instructions to work with Debian proper.
<persia> Also, rootstock would benefit from growing the ability to also create Debian rootfs artifacts.
<persia> But if you just want it to work today, the emdebian instructions are probably fastest.
<tkmedia> I have been tainted by the M$ world
<tkmedia> so my mind needs reprogramming
<tkmedia> and VB by day doesnt help
<persia> Martyn: Just for completeness sake: 9.04 supported ARMv5, 9.10 supported ARMv6, and 10.04+ is ARMv7.
<tkmedia> is rootstock script based ?
<persia> Also, there were no formal Ubuntu releases of armel prior to 9.04 (although the mojo project had good stuff for several releases from cross-compilation)
<Martyn> persia : Thanks for the clarification
<persia> tkmedia: https://code.launchpad.net/project-rootstock is the best place to check.
<tkmedia> k
<tkmedia> thanks
<persia> Martyn: Thanks for steering now3d in the right direction :)
<Martyn> persia : I had a complete 8.04 system built for/from ARM itself, but that was before the release of the Cortex-A8... more a proof of concept than anything supported
<persia> Not the mojo stuff?
<persia> ( mojo.handhelds.org )
<Martyn> nope, not the mojo stuff
<Martyn> in fact, a lot of it was compiled with the CodeSourcery toolchain, inside of ARM.   It predates all the nice root filesystem tools too...
<Martyn> Which, for the record, rock my world.
<Martyn> rootstock = FTW
<persia> rootstock is very nice indeed.
<persia> But yeah, that sounds like a special thing.  Not something I'd heard about before.
<Martyn> It was, but it was also fun
<Martyn> And these days I'm still working on getting Lenny working as an arm server
<Martyn> so much that we discussed at UDS has been abandoned
<Martyn> No Device Tree
<Martyn> no software boot
<Martyn> and there's no point in even trying to get an official arm server build...
<persia> Hrm?
<persia> What's http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/
<persia> Looks like two armel server builds to me.
<persia> DeviceTree just didn't get finished in time, from what I heard.
<persia> And mukluk needs love, but there's been persistent bugs about kexec() issues, which I believe are finally just getting sorted (but too late for lucid).
<Martyn> Yep.  Grant is working really hard
<Martyn> but the patches are only just now starting to flow
<persia> Yeah, all credit to him.  It's just a matter of timing against the 6-month cycle.
<persia> Based on what I hear, I have a feeling that we might be able to get that for the next cycle.
<Martyn> yep
<Martyn> and that's kind of critical for smooth-stone chips
<Martyn> device tree will make booting our SoC much, much easier
<tkmedia> hmm ps3 install
<persia> Make booting *everything* easier.
<persia> tkmedia: -> #ubuntu-powerpc :)
<tkmedia> anyone try that?
<tkmedia> is it virtual
<tkmedia> it runs intheir hypervisor right ?
<persia> Martyn: Have you been testing the DT stuff in your kernels?  Do you know what we need to tweak in image builds to make it just work?
<tkmedia> or can you take full advantage of the hardware?
 * tkmedia is off to read up
<Martyn> no, I'm not touching the DT stuff at _all_
<Martyn> Right now, I'm porting linux to specifications, since we don't have a test chip built .. and RTL runs 8 million times slower than the actual processor
<persia> 8 million!  So you get, what, about 1.5KHz?
 * persia can't do math, and gives up.
<Martyn> no, 200Hz
<Martyn> 300 if the simulation is run on a very, very fast nehalem (3.2Ghz or better)
<persia> Ouch!
<Martyn> multicore isn't yet supported by anyone for RTL sim
<Martyn> so you basically are running unicore
<Martyn> (that's being addressed, but a lot of this kind of thing CAN'T be run parallel)
<persia> Right.
<persia> So if DT gets far enough to land in lucid+1, that actually works for you.
<Martyn> yep
<Martyn> One of my workmates (JAson Hobbes - n3onfr3on) is working on that part
<persia> Also, have you tested the server images at all?  I don't know that they are getting enough testing, but I suspect they ought get some.
<Martyn> since he's writing the bootloader
<persia> (and it was your spec that made them happen)
<Martyn> I can't test them .. while they are built for v7a, my kernels don't properly support thumb2 yet
<persia> I thought you had a Lange
<Martyn> because I'm running in FastModel
<Martyn> Yeah, I have a lange board .. but I don't have the debug cable
<Martyn> I need to get that from ojn before I can reconfigure u-boot
<Martyn> lange 5.1 even
<persia> Oh right, I remember now.  Sorry for the reminder of the pain.
<Martyn> in fact, I'd like to try the -desktop- build on the lange 5.1
<persia> That's been dropped.  THe only images being built are Ubuntu Netbook, Kubuntu Netbook, and Ubuntu Server.
<persia> Not to say you can't create one, but images just aren't being built.
<Martyn> yep
<Martyn> I can use the server image, and apply most of what's needed to get desktop
<persia> Just preseed a late-command to install the ubuntu-desktop task, and you can do it in one shot.
<Martyn> yep
<persia> Although netinstall images might be better for that use case, because most of the server pool is uninteresting for desktop.
<Martyn> but, for now the lange sits on my desk unused
<Martyn> the versatile2 gets a lot more attention
<persia> Waiting on ojn :)
<Martyn> even if it is just a 400Mhz Cortex-A9
<persia> That's not bad at all.
<DanaG> interesting... device-tree coming to ARM?
<persia> DanaG: Indeed.  The idea is to move from kernel-per-board to kernel-per-SoC by using DeviceTree to handle board-level variations.
<DanaG> hmm, how would it handle different memory locations?
<persia> And this is critical from a distribution POV, as it means we can actually support N devices.
<persia> How do you mean?
<DanaG> ah, that's the per-SOC part.
<DanaG> Same SOC will have same memory layout for at least main RAM.
<persia> Oh, yeah.  Moving from per-SoC to per-architecture will require an entirely different level of cooperation
<DanaG> First time I'd used Device-Tree was with Microblaze.... that was an exercise in broken tools.
<persia> If you've experience working with it, and want to help make it happen (to avoid the broken tool situation), please track followups to http://www.kernel.org/doc/ols/2008/ols2008v2-pages-27-38.pdf
<persia> git://git.secretlab.ca/git/linux-2.6 test-devicetree seems another good source
<DanaG> what I mean by broken tools, is things like a cross-compiler, that, when trying to build, segfaults the host compiler. =Ã¾
<persia> Ugh.  Yet another argument against cross-compilers.
<DanaG> Yeah, I thought that was comically bad -- I mean, I don't even see how you could make a compiler segfault.  Really bad code? =Ã¾
<persia> ICE isn't hard to achieve if one takes the effort.
<persia> THis is unfortunate, but the nature of developing tools.
<tkmedia> what do you guys think of the smart Q7
<persia> tkmedia: It's too big :)  Also, it can't run lucid (ARMv6)
<GrueMaster> persia: I thought lucid was armv7?
<GrueMaster> (or are you referring to the smart?
<persia> GrueMaster: SmartQ7
<GrueMaster> ah
<persia> They ship with something based on jaunty, but I *think* they could be upgraded to karmic if someone uses a custom kernel.
<persia> I'm fairly certain they can't run lucid.
<persia> (although SmartDevices may well come out with another generation, and the price is certainly right)
<ethana2> hello, from my Droid
<asac> JamieBennett: gave you a RC  bug so we can upload in freeze: 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> xserver with imx fallback patch is about to finish building ;)
<JamieBennett> asac: thanks :)
<ogra> wohooo
<ogra> asac, now it just needs proper EDID detection :)
<asac> ogra: the current solution is quite good enough i think ;)
<persia> Well, depends on one's monitor
<ogra> i want my 1900x1002 !
<asac> oh edid
<asac> yeah
<ogra> *1200
<asac> ogra: how is that done?
<ogra> no idea i have to look into it, it wasnt ready in the old driver i have around here
<asac> well its not ready here either
<asac> but maybe its just a code fix ;)
<ogra> but i think its already done when the fb device inits
<asac> hmm on init feels wrong
<asac> monitor might get plugged in/out swapped etc.
<asac> xrandr should tell us better info ;)
<ogra> xrandr is after EDID
<ogra> iirc
<asac> ok i will check that
<asac> sure xrandr hopefully just reflects what EDID gave us
<asac> or gives us (when mohnitor changes)
<persia> I was under the impression xrandr wasn't available based on the snipped of the log that was pasted yesterday.
<ogra> fbcvt: 1024x768@60: CVT Name - .786M3
<ogra> thats what i have in dmesg
<ogra> xrandr is available but only with a handfull of default resolutions
<ogra> up to  1024x768
<asac> ack
<asac> at least it detects for me its a lcd with proper subpixel
<ogra> and we dont know if resolution changing works yet
<asac> cant you try lower resolution in fbdev?
<ogra> you can try setting modelines with fbset
<ogra> and you can indeed add modelines in xorg.conf
<ogra> if xranbdr works you should even be able to use modelines there to add new modes
<NCommander> dmart: ping?
<dmart> NCommander: hi there
<NCommander> dmart: sorry I missed you yesterday
<dmart> no probs; just wondering what our next steps should be on OOo
<NCommander> dmart: funny, I was going to ask you the same thing :-)
<NCommander> dmart: I retested karmic gcc-4.3 + jaunty binutils, and got a working uno from fresh sources
<ogra> NCommander, did you talk to doko btw, i think he did all these varaition tests already
<ogra> he should have a test matrix for what combo works and which one doesnt
<NCommander> ogra: I talked to him earlier, but he didn't say anything about that. I'll make sure to ask him for that
<ogra> i tested a *ton* of different builds he did
<ogra> each with a different combo of gcc and binutils
<NCommander> ogra: I'll ping him
<NCommander> ogra: that's good to know. I just wish it was on the bug :-/
<NCommander> dmart: TBH, I'm kinda out of ideas on this one.
<NCommander> dmart: we know what appears to be the base underlying cause for the OOo boom
<NCommander> but I don't really know how to fix it, or how to even rewrite the ASM snippet to be less evil
<ogra> NCommander, just build it with --no-uno-crash
<ogra> ;)
 * NCommander whacks ogra
 * NCommander feels better
 * ogra feels short now
<persia> So, about OO.o.
<persia> From what I saw recently, I thought we knew what changes to the toolchain were providing what extra bits that caused which problems.
<persia> Was the .eh... issue resolved or still open upstream?
<persia> Or did someone confirm this wasn't really the issue?
<NCommander> dmart: I'm not even sure what to bring to OOo upstream about this, from there perspective, it looks like a pure toolchain bug
<dmart> NCommander: the problem file had some maintainers' names -- have you tried to contact them?  I think the first thing is to understand from them what the code is trying to do, and explain our concerns about why it looks incorrect.
<NCommander> dmart: no, I haven't
<dmart> I can draft a mail if you like.
<dmart> oooh
<dmart> hang on a moment
<dmart> NCommander: did you look at this?: http://pastebin.ubuntu.com/393294/
<NCommander> dmart: I smell magic in that file
<NCommander> deep scary magic
<dmart> Ummm, yeah
<dmart> The two first *p++ poke ARM instructions into memory
<dmart> > mov r12, pc
<dmart> > ldr pc, [pc, #4]
<dmart> This explains why privateSnippetExecutor assumes there is something in ip (r12)
<NCommander> dmart: I think my crack fuse just burt out :-/
<dmart> I guess it's used to look up the functionIndex and vtableOffset values which get poked
<NCommander> dmart: there is no guarette thats going to laid out like that in memory though, or with no padding and stuff done
<NCommander> dmart: actually, it could have been the move to ARMv6 that might have brokened it in the first place since that removed the strict algnment access requirements
<NCommander> (not sure, but a possible theory)
<dmart> Hey ramana
<dmart> I know what's in ip (ish)
<dmart> It contains the pc value in a trampoline used to read the destination vtable offset and function index, see http://pastebin.ubuntu.com/393294/
<dmart> ...or at least it would contain that if any version of the linker ever provided a guarantee
<NCommander> dmart: on a scale of 1-10, how high is the crack factor of what OOo is doing here?
<NCommander> dmart: but privateSnippetExecutor works
<NCommander> dmart: thats been previously tested, and works as expected
<persia> Shouldn't it not work as expecting, as with all the mov *,pc stuff?
<dmart> The linker is allowed insert trampolines for function calls, which are permitted to corrupt ip.  The chance of this happening is pretty low, but it's not "safe"
<dmart> I think the code in question will get executed as ARM, and the way it branches it interworking-compatible.
<dmart> ...anyway, I don't think this code is failing, it's just a bit scary
<NCommander> dmart: bit?
<NCommander> dmart: ugh, I just realized something nasty
<NCommander> dmart: part of the ASM instructions exist outside the .S (as the hex magic)
<NCommander> dmart: so even if we add unwind table entries, ther're not going to properly "mesh"
<dmart> Because the trampoline generated by privateSnippetExecutor only trashes ip, it might not need any unwind info... but I'm not the expert on this
<dmart> Also, I think no exception can occur in the trampoline itself, because it calls no functions except for jumping to privateSnippetExecutor
<NCommander> dmart: thats not the problem, the problem is libgcc bails out because on CANTUNWIND segments (in theory)
 * dmart is grepping the OOo source to try and work out where this code gets called from, but it will take a while
<johannes_> cortex a9 processor seems to be the fastest and most fitting processor for a small client with gui, does someone know where I can buy a mainboard with this cpu?
<ynezz> nvidia tegra2
<dmart> johannes_: I've seen Ubuntu at least Ubuntu karmic working on tegra2
<NCommander> dmart: uno2cpp.cxx only
<NCommander> dmart: same folder
<dmart> NCommander: I mean, where the functions codeSnippet and flushCode in uno2cpp.cxx are called from...
<ynezz> johannes_: http://tegradeveloper.nvidia.com/tegra/
<NCommander> dmart: if you read the UNO CPP code, your mind will release itself from mundane concerns as the horror of it takes over
<johannes_> thanks Ill have a look at tegra2
<NCommander> dmart: ah. theres a porting uno guide you might want to look at
<dmart> Oh, where?  That sounds useful
<NCommander> dmart: http://wiki.services.openoffice.org/wiki/Lazy_Hackers_Guide_To_Porting - skip to the first part of Hard Bit
<NCommander> dmart: it deals with how the HPPA port was done.
<johannes_> mhm bei tegra2 finde ich nur dinge, wie tablet pcs, ich suche aber nach etwas, wie dem beagleboard nur mit einem oder mehreren Cortex A9
<ogra> johannes_, i dont think they are freely sold yet
<persia> One needs to apply.
<johannes_> oh sry for writing in german
<ogra> macht nix :)
<persia> johannes_: Are you looking to build something, or do you want a shipping device?
<johannes_> I thought about a fileserver with a quadcore Cortex A9 as I read some articles it would have a lot of power
<johannes_> I want to build something for myself
<ynezz> tegra is dual core "only"
<ogra> yeah, lame, isnt it ? :P
<johannes_> but there are processor on it, I dont need, 3d graphics for example
<johannes_> and I couldnt find a mainboard yet
<ynezz> it's too hot
<ynezz> you can't even buy it in Europe
<persia> I've not seen any bare mainboards except for "development boards".
<persia> Most stuff seems to be inside devices.
<johannes_> thats sad
<ogra> http://www.dlink.com/boxeebox
<ogra> that will use a tegra2
<ogra> i read somewhere
<ynezz> but who knows when they start shipping it out :)
<persia> Real Soon Now
<ynezz> hm, good
<persia> heh
<persia> That's why I like the devices I *know* are shipping.
<persia> We can get them today.
<ogra> well, just hit the fast forward button ...
<persia> One of those several-month retreats?
<ogra> heh, yeah
<johannes_> a question in general: would a quadcore Cortex A9 actually be powerful enough to support: mdadm raid 5, trunked Gigabit Ethernet, 2 HDTV tuner cards (for a vdr backend without decoding)?
<ogra> if you find HDTV cards that fit into any ARM device ...
<ogra> are there HD USB tuner cards ?
<johannes_> size doesnt matter, it is only about power consumption
<johannes_> some but most are pcie or pci
<ogra> right, PCI is rare on ARM boards
<ogra> sockets at least
<persia> There are USB HD DTV devices.
<johannes_> mhm I guess I was a bit naive, thinking I could simply change my opteron board with a armsystem
<persia> Well, there exist a few boards with PCIe, but nothing running those chips I've seen
 * persia has PCIe on an orion board
<ogra> there will surely be some server boards with a9 chips *soon*
<johannes_> what do you mean by soon?
<ogra> those would have PCIe i assume
<ogra> johannes_, within the next 254 months ?
<persia> Maybe.  Maybe PCIx
<ogra> err
<ogra> 24 :)
<persia> No, 254 is definitely correct.  24 is a bet.
<johannes_> mhm better than 254, but still a long time
<ogra> no idea ... i dont know how many companies wortk on server boards
<ogra> but a9 are definately somehting thats intresting for datacenters
<johannes_> When ubuntu is installed on an arm system, can I use all the programs, that are available for x86 ubuntu too?
<persia> johannes_: I suspect that what you want is a next-generation NAS box (for the raid), with the HDTV USB bits plugged in the back.
<persia> This wouldn't be building it yourself, but is probably the earliest purchase option.
<persia> johannes_: There's a couple hundred packages that don't work right now, but we try to get that as close to zero as we can.
<ogra> johannes_, yes, the majority works on arm as on x86
<johannes_> I would prefer if it was still more pc than NAS, as I like to try things out with linux
<johannes_> that sounds great
<johannes_> what about drivers? (for tuner cards) can they simply be installed or do I need special ones?
<persia> johannes_: The difference between a "Small form factor PC" and a "NAS box" is a USB keyboard and a USB Display module :)
<ogra> johannes_, as long as there are linux drivers they should just work
<persia> For USB tuner cards, the same drivers should work for any architecture.  For other tuners, you may need to do some tweaking.
<suihkulokki> johannes_: openrd board comes with one PCIe slot
<johannes_> I look it up
<ogra> suihkulokki, but can the CPU do HD processing ?
<ogra> though its a backend ... probably thats not actually needed if the card is powerful
<suihkulokki> ogra: didn't he say we won't do decoding ?
<persia> suihkulokki: That's the ARMv5 chip that's in the SheevaPlug, right?
<suihkulokki> persia: which is good enough for the usecase.
<persia> Absolutely.  Just wanted to confirm my reading.
<ogra> suihkulokki, well, recording and streaming i guess
<johannes_> basically streaming only
<suihkulokki> oviously thing like recompressing streams or analyzing + cutting out ad breaks is out of question with any arm cpu
<NCommander> dmart: *sigh*, how best do we draft this email?
<dmart> I will look a bit more and then send you something...  But I think the code in armhelper.s is a fairly straightforward trampoline in which case the solution might not be too complicated.  Too early to say though...
<tkmedia> how about using a network tuner like hd homerun
<ogra> i think thats only DVB-T
<ogra> there are no german HD channels over DVB-T
<tkmedia> k
<ogra> (assuming johannes_ is german after he spoke german here :) )
<persia> wikipedia claims there are 4 modles of which only one is DVB-T
<tkmedia> I use the US version
<ogra> persia, the german version is DVB-T only afaik
<persia> Ah.
<johannes_> yes, I am german and thing is: I already got myself a skystar hd2 for the server I am using right now
<dmart> NCommander, ramana: The code which looks interesting is in:
<dmart> bridges/source/cpp_uno/shared/vtablefactory.cxx
<dmart> bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx
<dmart> bridges/source/cpp_uno/gcc3_linux_arm/armhelper.s
<dmart> (if you want to look and didn't already look at one of those)
<dmart> NCommander: hi again
<lool> dmart: Yes, that's the uno2cpp bridge, and it's what upstream told me was likely broken
<NCommander> dmart: hola again
<dmart> Hi there... I was just chatting for ramana and matt
<dmart> We now understand better what privateSnippetExecutor is doing
<dmart> and we think we have a fix: http://pastebin.ubuntu.com/393376/
<dmart> (i.e., delete 2/3 of the function :P )
<NCommander> dmart: O_o;
<lool> dmart: Amazing!
<NCommander> that will be one hell of a fix if it works
<dmart> This may just expose the next bug :/
<dmart> Could you give it a try?
<ogra> haha
<dmart> My OOo build will take some more days to finish...
<ogra> funny fix :)
 * dmart admits that we did change a couple of lines as well as deleting some
<persia> !ohmy
<ubot4> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<NCommander> dmart: incremently building, please stand by
<NCommander> persia: where was the language violation?
<dmart> Basically, the unwinder doesn't need to see this function at all if we tail-call optimise it (i.e., just jump to cpp_vtable_call and let it worry about the return)
<ogra> persia, if i would mention it in a religious context would you also "ohmy" me ?
<persia> ogra: No.
<ogra> so why do you do it in this context ?
<persia> (but if I don't ohmy people in #ubuntu-* I may get chastised by those who oversee me keeping the channels open)
<NCommander> dmart: we MAY have a winner
<NCommander> stand by
<persia> ogra: IRC guidelines for #ubuntu-*.  I don't personally really care, but I like having IRC channels :)
<dmart> Ummm, actually, who was the ohmy for?  If no-one can tell it will just cause confusion...
<ogra> thats a pretty silly rule
<ogra> dmart, <NCommander> that will be one hell of a fix if it works
<ogra> (risking another ohmy)
 * dmart kpees smoe fngries cssoerd but it mkeas it hrad to tpye
<ogra> heh
 * persia should get better at passing | to the bot
<dmart> NCommander: it would also be interesting if you can shove this patch into your current working distro+libs+OOo combination and see whether it breaks anything
<dmart> If not, pushing the patch is a no-brainer because is provides some cleanup, and also will avoid the risk the current code has of an incoming signal corrupting the stack
<NCommander> dmart: buildingnow
<NCommander> (with g++ 4.4/binutils 2.20)
<dmart> =lucid?
<NCommander> dmart: kmaric
<dmart> Oh, right
<NCommander> ladies and gentleman
<NCommander> IT WORKS!
<lool> \o/
<NCommander> (also tested on lucid)
<ogra> well, try lucid
<ogra> hooray !!!!
 * lool thinks the ARM folks deserve some Champagne
<dmart> Ooo works, or just builds?
<NCommander> dmart: works
<dmart> Wow, cool :D
<ogra> lool, free beer for dmart and his team for the whole UDS i'D say !
<NCommander> ogra: +1
<dmart> What, I have to wait till then :(
<NCommander> dmart: we don't have beer transport over IRC
 * ogra send some virtual beer right now
<NCommander> dmart: how'd you figure out to reduce armhelper.s to what it is now?
<lool> Someone uploads to lucid?
 * NCommander quite envious to cracked this so quickly
<ogra> *german* beer
<dmart> Save some for ramana and matt, this was definitely a collaborative effort
<NCommander> free beer for anyone who touched this bug
<ogra> dmart, so i hope we'll see them in brussels
<NCommander> lool: someone has to dump it into ooo-build upstream. OOo in lucid has no patch system of its own
 * NCommander goes to grab ccheney
<ogra> NCommander, heh, then i'd get the most beer, i filed it :P
<ogra> touching really doesnt count :)
<NCommander> ogra: we can just make david file it as expense. Brain damage remover!
<dmart> NCommander: looking at the call too privateSnippetExtractor, we observed that it does nothing after the call to cpp_vtable_call, except to tidy up a stack frame which is only needed at all because it was set up
<dmart> ...so we just branch to cpp_vtable_call.  cpp_vtable_call's return later goes straight back to the original caller.
<NCommander> dmart: thats clever
<lool> It's basically a jump trampoline I guess
<dmart> Because there's no return address on the stack pointing into privateSnippetExecutor, the unwinder doesn't need to know about it at all
<NCommander> dmart: so the unwinder was the root cause of the problem, and you just made privateSnippetExecutor disappear?
<dmart> When an exxception occurs, the unwinder saw that there was a pending return into privateSnippetExecutor, but didn't know how to unwind that function
<dmart> But since no state needs restoring anyway, we can have the unwinder skip it completely simply by not returning to it.
<NCommander> dmart: wow. thats clever
 * NCommander feels humbled
<NCommander> ^in the precense of greatness
<asac> dmart: you guys fixed it?
<persia> asac: That's the theory : we have to do the upload / builder / install dance to 100% verify.
<asac> yep
<asac> NCommander: patch attached to bug? ooo target opened?
<NCommander> asac: I just poked ccheney to add it to ooo-build
<asac> yeah saw in -deesktop
<asac> dmart: plenty of kudos to whoever was involved in this!!
<dmart> Since we don't really understand OOo, I don't understand much about exceptions and we couldn't debug or test this locally, I'll certainly be happy if it works ;)
<dmart> I passed on the good news to ramana and matt here
<NCommander> dmart: lets call it a successful joint effort between Canonical-ARM in futhering the position of ARM on the desktop. Regardless, this wouldn't have been possible without you, ramana and matt :-)
<dmart> Well, the OOo community might have fixed it, but it's harder to persuade upstreams to undertake that when we're not sure whether the real problem is a tools issue or something else.
<lool> dmart: the arm port isn't actually upstream, it's a fedora patch
 * dmart anticipates a shiny new .deb to confirm all this
<NCommander> lool: its partially upstream, but not considered a priority by OOO as far as I can tell
<NCommander> half of it is in their CVS, the other half is in ooo-build
<dmart> Anyway, hopefully they'll accept the patch without problems; it cleans up some code if nothing else.
<dmart> ...and we still think the old code wasn't signal-safe
<dmart> ramana: take a bow :)
<ogra> *clap* *clap* *clap* *clap* *clap* *clap*
<ogra> :)
<ramana> Thanks but the credit is actually due to Matt and the others in the team who spotted the differences with respect to the frame.
<dmart> Well, it was a shared effort...
<dmart> NCommander: thanks to you too
<lool> dmart: Oh I'm sure the maintainer of that piece of code will welcome it heartily
<NCommander> dmart: I just figured out how build the beast
<lool> I'm pretty sure it's going to hit the next RHEL and I think they care about the ARM port there
<armin76> thanks to me too!
<dmart> ;)
<dmart> mgretton: quick, take some credit before it's all gone!
<Who_> ogra: ping - I've got an issue with building from rootstock and the wiki says to come and talk to you...
<ogra> whats the issue ?
<Who_> ogra: I'm using a Lucid VM to build a lucid image, and it got as far as unpacking libglibmm but has been hung for the last two (ish_) hours after outputting the message 'udevd[45]: specified user 'usbmux' unknown'
<Who_> that message is there three times
<ogra> yeah, known bug (and no fix yet)
<ogra> 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
<Who_> ogra: so for now, there's not a way to build a lucid image that requires libglibmm?
<Who_> ogra: thanks
<ogra> Who_, build an image with ubuntu-minimal for now, then just apt-get install waht you need on real HW
<ogra> minimal definately works
<Who_> ogra: yep - I was just modifying my script :)
<Who_> ogra: do you know much about sound on Beagle/IGEP?
<ogra> its some mystical qemu issue i'm not able to track down properly
<Who_> or can you point me to someone who does?
<ogra> no, sadly not, rcn-ee builds the beagle kernel package, he might at least know the kernel side
<Who_> ogra: it doesn't seem to be kernel related: I've got an 9.04 image (shipped with device) that has working sound and my 9.10 rootstock (using the same kernel and modules) doesn't work...
<ogra> NCommander, so since you like to dig into the odd bugs ... i'm lost on bug 532733, probably you have any ideas
<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
<NCommander> dmart: what do we want to call teh patch?
<ogra> Who_, try to create an audio group and add your user to it
<persia> NCommander: dmart: Also, to whom should be given author attribution?
<Who_> ogra: also, while I'm thinking about it... I made this for myself: https://launchpad.net/rfsm - I don't know if it is of any interest more generally - but if there's now a good way to tie it in to the rootstock system I should look at doing that... (I notice rcn-ee seems to be using a --script command)
<ogra> Who_, rootstock in lucid has the --script option
<ogra> Who_, even the new gui has the option to select a post install script :)
<Who_> ogra: okay, I'll try and tie in with that
<Who_> ogra: also, audio group already exists. I'll keep digging on the sound issue
<dmart> NCommander: How about "privateSnippetExtractor simplification to avoid exception unwind failures and stack corruption risk" ?
<dmart> or
<dmart> "privateSnippetExtractor simplification to avoid exception unwind failures and stack corruption risk on ARM"
<persia> Ideally we want a name that can also be a filename :)
<persia> That looks like a Description: entry for DEP3
<ogra>  branch_directly_to_cpp_vtable_call_on_arm.patch
<ogra> and dmart's description
<persia> Just needs Author: then.
<dmart> Yeah, sounds ok
<ogra> "the arm guys"
<persia> It's supposed to be a person who can grant license for reuse in the project, etc.
<persia> silly tort law to work around silly copyright law, etc.
<Martyn> I'm going to spend my day porting this: http://community.livejournal.com/openvz/24651.html to Lucid
<persia> I think that a bunch of that work was already done
<ogra> Martyn, openvz was rejected from the ubuntu kernel
 * persia hunts for the bug
<Martyn> ogra : I know, but I need to get it working for a demonstration of virtualization on the A9
<Martyn> ogra : Rejected or not ...
<ogra> then you likely need to maintain your own kernel as well
<Martyn> Because OpenVZ is the Path of Least Resistance .. unless you have a suggestion for a better container solution?
<Martyn> ogra : I already do ...  the Versatile2 is anything but supported...
<ogra> whats versatile2 ?
<Martyn> ogra : Quad core a9 platform from ARM .. I showed one off at UDS
<Martyn> now generally available
<ogra> ah, you call it versatile ?
<ogra> heh
 * persia can't find the bug
<Martyn> That's it's final name "Versatile2"
<Martyn> (our internal codename for it is 'crandall')
<ogra> i like the internal one more :)
<Martyn> persia : If you happen to come across it, ping me : martin@smooth-stone.com
<ogra> Versatile makes me thing of qemu which makes me think of underpowered
<persia> "Versatile2" is too easy to confuse with the qemu target.
<persia> Martyn: I'm not likely to, since I didn't find it in a search.
<Martyn> persia : The QEMU target is a simulation of /real/ hardware, called versatile :)
<persia> Ah!
<ogra> Martyn, which is underpowered as well :)
<Martyn> There are various models over time .. Versatile PB, PBX, EB ...
<Martyn> (EB is the current generation -- Cortex-A9)
<Martyn> ogra : hey, don't scoff at a 400MHz quad core processor.   It's pretty snazzy
<ogra> heh, ok ok
<Martyn> ogra : And I've already got another, faster platform to play with now too -- tegra2
<ogra> i'm waiting for the 1GHz quad cores
<ogra> yeah
<ogra> i'd love a tegra2
<ogra> its the future !
<Martyn> ogra : We're targeting 1.6GHz now.
<Martyn> ogra : If Global Foundries becomes available to us, the second rev of the chip will be shrunk and probably hit 2.2GHz
 * ogra thinks tegra2 will be the direct atom competiotor
<persia> Martyn: Based on https://lists.ubuntu.com/archives/kernel-team/2010-March/thread.html I believe there's a git tree, but not a package.
<Martyn> it's a nice chip, but has it's .. issues.
<ogra> indeed, nvidia built it :)
<Martyn> persia : Git tree of a valid, running kernel is enough
<ogra> but i'd be willing to live with that drawback :)
<Martyn> persia: that would save me -tons- of time
<Martyn> ogra : I /need/ 8x PCIe .. and tegra2 doesn't have it
<Martyn> only 1x and 4x
<ogra> you should really switch your servers to USB
 * ogra ducks
<Martyn> persia : Looking at the threads, haven't found the mention of openVZ yet
<persia> Martyn: Mail Kir for details : I didn't see a git repo listed.
<Martyn> done already :)
<Martyn> he has patches available for the overo
<persia> There you go :)
<persia> Cool.
<Martyn> http://download.openvz.org/.kir/overo/kernel/
<Martyn> 2.6.27 though
<ogra> Martyn, "OpenVZ kernel for Ubuntu 10.4"
<ogra> ids the thread name
<persia> Martyn: If you get it all working, toss it in a PPA :)
<persia> Yes, PPAs don't build for armel, but it means that anyone can build it easily from your source.
<Who_> rcn-ee: are you there? I've got a sound-on-igep question (I have no sound from aplay, but can by piping to /dev/dsp) and I'm making very little headway with just my head and Google.
<Martyn> persia : You got it
<persia> Martyn: Thanks.
<Martyn> persia : although if it's integrated into Lenny, would I still have to build a PPA?  (it's upstream at that point)
<Martyn> ojn: You around?
<Martyn> (we really need a messaging bot on channel :) )
<persia> Martyn: If it's in Lenny, people can grab from there and build, so it doesn't matter.
<persia> Martyn: email?
<Martyn> mine?
<Martyn> martin@smooth-stone.com
<Martyn> OH ..
<Martyn> heh .. no, because I don't have everyone's email on channel
<Martyn> there used to be a note-server capability on chanserv ... you could leave someone a sticky note that would be displayed when they next came on channel
<Martyn> sort of like:
<Martyn> chanserv, tell <recipient> <message>
<ogra> doesnt that still work ?
<Martyn> however it's long gone...
<ogra> though its nickserv i think
<persia> One can use /ms for that, I thnk
<persia> (MemoServ)
<ogra> ah
<ogra> yeah
<ogra>  /msg memoserv help ;)
<persia> "/ms help" works
<ogra>  /msg MemoServ SEND Martyn "get me a tegra2"
<ogra> ;)
<persia> "/ms send Martyn" is *shorter* and *easier* :p
<ogra> tsk ... you embedded folks
<ogra> *g*
<persia> Me?  Embedded?  No.  I happen to like 3.5-4" laptops, but I want full features.
<dmart> http://www.arm.com/products/tools/versatile-express.php
<Martyn> Oh!  We have a msgserv again!
<Martyn> I had no idea :)
<Martyn> me? Embedded?
 * Martyn points to the mid-sized tower with a Tegra2 mini-ITX board 
<Martyn> It's got 2 sata drives, a DVD burner, but is using the integrated graphics .. and a whole -2GB- of memory
<Martyn> embedded my buttocks...
<persia> Precisely.  ARM != embedded.
<Who_> ogra (et al - anyone who will know): are there plans to change the build scripts for some packages in the arm repositories so they make 'more sense' on ARM - such as specifying EGL as or XEGL as the clutter backend?
<Who_> sorry - that should have been to ogra_cmpc, I guess ^
<persia> Are we sure that makes more sense for arbitrary hardware solutions?
<persia> I'd much prefer not to align "armel" and "embedded" in any way.
<Who_> persia: interesting. do you know of any armel devices with full OpenGL support (just asking, not suggesting there aren't!)?
<Who_> persia: I guess though that there'd be no harm in a 'clutter-backend-egl' package or equivalent
<persia> I know of armel devices with PCIe slots.
<persia> Getting full OpenGL there is just a matter of driver testing.
<Who_> persia: and armel drivers for the cards?
<persia> I also stuffed some DisplayLink drivers in the archive for lucid, for which I hear there are plans to grow OpenGL support upstream.  That's USB, and arch-independent.
<Who_> persia: okie, sounds like changing the build isn't ideal
<persia> Who_: Why not?  No good reason any of the existing opensource drivers can't be ported.
<persia> Who_: Well, maybe building twice and making two flavours of a binary is useful.
<Who_> persia: Sorry - I should be more clear - I was agreeing with you that making the default packages more 'embedded' didn't make sense
<persia> That's just tricky, and it's important to identify which packages make sense for that, and how much work.
<Who_> but I think it would be helpful for people like me if there were some more embedded-target style packages built
<Who_> persia: and I guess you also then need to have some (likely non OS) graphics libraries on the build system to be able to compile?
<persia> Right, that's why I say that in some cases, two flavours may make sense.
<persia> I'm not sure I understand that last question.
<Who_> persia: My understanding is that in order to build Clutter with, for example, an EGL backend, you would need to have EGL development headers on the system - are there Open Source headers that you can link against, and then still get hw accelerated performance on systems that have hardware drivers?
<persia> But I think the real solution for X is to have a more pluggable GL library, so that various libraries can register the ability to do various functions, using a GPU, CPU, DSP, etc. (whatever hardware happens to be available).
<persia> Oh.  I have no idea if there are open-source EGL headers available.
<Who_> persia: seems so http://www.khronos.org/registry/gles/
<persia> Cool.
<persia> It's probably too late for lucid, but we ought be able to get that stuff into the next release.
<Who_> persia: sounds sweet
<Who_> persia: I made sound work on my IGEP, but the process was a bit... confusing... I'm not entirely sure I should have needed to do what I had to do (run .snddevices from the alsa-driver source package on the arm) - is it worth raising as a bug, or is it too device specific?
<Who_> persia: more specifically, I made aplay work. Pulseaudio is still unhappy
<persia> It's worth filing as a bug.  If you're not using a distro kernel, and it looks like a kernel thing, don't be too surprised if it gets rejected.
<Who_> persia: I _think_ it's a kernel thing - I don't know where the line between kernel and userspace is when it comes to alsa. I am using the kernel sources from the board manufacturere
<persia> If you want help with investigation, file a bug :)
<persia> Worst case someone tells you it's your kernel.
<Who_> :)
<Who_> persia: on further investigation, it seems udev is at fault, as it is supposed to create these devices. any new thoughts?
<persia> If it's udev, file a bug.
<persia> But udev mostly relies on kernel events, so it might be a kernel issue or a udev rules issue.  Hard to say without looking closely.
<andruk> i followed the guide at http://elinux.org/BeagleBoardUbuntu page and im getting "Unhandled fault: external abort on non-linefetch (0x1018) at 0x40..." errors on booting my Beagleboard rev C4.  im not new to coding, but im new to kernel debugging...help?
<persia> Unfortunately, the best person to help you is rcn-ee, who tends to be idle at this time of day.
<rcn-ee> sweet timing.. just walked in after work...
<persia> Wonderful :)
<rcn-ee> andruk, those errors are annoying, but safe to ignore..
<rcn-ee> aka i haven't debugged to figure out what it was, but it doesn't seem to affect anything.. ;)
<rcn-ee> persia, just noticed this last night: https://wiki.ubuntu.com/KernelTeam/TopicBranches  your kernel guys are going to be busy. ;)
<persia> so they say :)
<persia> rcn-ee: Feel free to jump into #ubuntu-kernel if you want to help push that effort.
<rcn-ee> persia, of course.. ;) already queied my first patch https://code.launchpad.net/~beagleboard-kernel/+junk/lucid-ti-omap
<rcn-ee> still need the beagle/iegp2 to boot before i open my mouth on ubuntu-kernel. ;)
<persia> heh.
#ubuntu-arm 2010-03-12
<andruk> rcn-ee: they may be safe to ignore, but they halt my booting process....
<rcn-ee> andruk, really? it shouldn't...  could you pastebin your boot.scr?
<andruk> rcn-ee: sure, give me a sec
<andruk> rcn-ee: boot.scr: http://pastebin.com/SearKknE   and boot process: http://pastebin.com/aGw0dzpf
<andruk> rcn-ee: im going to move to a friends house, so ill be offline for a bit, but ill be back on in about 15-30 mins.  thanks for all your help.
<rcn-ee> ah, it's bombing here: #
<rcn-ee> [   30.379852] EXT3-fs: Unrecognized mount option "error=remount-ro" or missinge
<rcn-ee> what's your /etc/fstab list..
<ojn> rcn-ee: errors=remount-ro is the correct syntax. note the missing "s"
<rcn-ee> yeap, that should fix andruk's boot problem...
<rcn-ee> so the question, did i miss type it somewhere on the wiki/fixup.sh script. ;)
<rcn-ee> Nope, my wiki is clear, looks like copy paste error..
<andruk> rcn-ee: back
<rcn-ee> andruk, check your /etc/fstab, it looks like your missing an 's' in 'errors'
<andruk> rcn-ee: updated boot process failure: http://pastebin.com/mu0LGjvL
<andruk> rcn-ee: oh, wait, it actually does present me with a login...
<rcn-ee> yeah, it takes a good 30 seconds, there's actually a package that optimizes it.. ;)
<andruk> sweet!
<andruk> rcn-ee: thanks so much.  :-)  now, would you happen to have a guide/walkthough/wiki/FAQ/forum/etc. (anything really) regarding exposing an SPI device to userspace so i can get hacking on interfacing with a few sensors?
<rcn-ee> Sorry andruk, not really...  Other then writing an application for i2c access, i haven't done much other then getting the kernel to work...
<rcn-ee> sweet! my x2 545 is now a x4.. time to start cross building.. ;)
<andruk> rcn-ee: cool, thanks anyway, i really appreciate the help.  i will be looking into eliminating that error; ill let you if i find anything (I assume you are rcn-ee.com and Robert Nelson on the mailing list?)
<rcn-ee> your welcome, yeap that's me... that would be cool, it's some package..  if you want a big challenge on lucid right now there are like 3-4 annoying errors messages.. ;)
<cooloney> plars: paul, thanks for the testing, i got your bug post
<plars> cooloney: which one was that?
<cooloney> plars: the suspend regression might be related to the patch for kexec
<cooloney> plars: one is the suspend regression, the other is the usb cause crash
<plars> cooloney: oh, GrueMaster noted that one first, I just made sure it got routed correctly after noticing the same problem today
<cooloney> plars: i am preparing the kernel package for testing. since i am away from babbage board for biz trip this week
<cooloney> plars: yeah, thanks GrueMaster
<plars> cooloney: sure, just attach to the bug and we will see to it that they are tested
<GrueMaster> I heard my name, Anything I need to know?
<cooloney> plars: ok, i am going to post the url, if it is possible, pls download the kernel package and test on your board
<GrueMaster> Will do.
<cooloney> GrueMaster: nothing important, just talk about the fsl-imx51 suspend regression
<plars> thanks cooloney
<cooloney> i don't have babbage on my side now.
<cooloney> thanks for testing
<powderluv> folks has anyone else noticed qemu hitting 100% CPU and hanging after unpacking "iputils-tracepath" with rootstock building lucid ubuntu-desktop ?
<rcn-ee> powderluv, yes... this morning when i tried it...
<powderluv> any potential workarounds?
<rcn-ee> sorry nope..  last i read, ogra was still investigating why qemu was locking up on some packages..  best just to get most of your packages on your hardward and just apt-get the rest..
<powderluv> ohh ok. I dont have network on my hardware yet :( .. so will try to start with ubuntu-minimal inside qemu and try to update individual packages/ubuntu-desktop.   Thanks for the info.
<rcn-ee> powderluv, it's just specific packages, that are causing issues.. before iputi*.. it was iso-*something
<powderluv> ahh i see. btw are there any prebuilt lucid rootfs images with rootstock.
<rcn-ee> yeah... i put up a alpha-3 based on here: http://elinux.org/BeagleBoardUbuntu#Lucid_10.04_.28alpha-3.29
<plars> cooloney: that kernel still won't resume :(
<powderluv> rcn-ee: thanks for the link. Will try it out. and in case you get lucky with a lucid ubuntu-desktop image can you post it.
<rcn-ee> powderluv, my goal is to provide a ubuntu-netbook rootfs.. ;)
<powderluv> cool.. and I can test it for you whenever it is ready :)
<persia> rcn-ee: Are there any particular blockers left towards that goal?
<persia> Or is it just a matter of respinning regularly?
<rcn-ee> persia, pretty much daily respins at the moment... it's dieing on iputils-tracepath like it was on iso-codec's last week...
<persia> rcn-ee: I wonder if it's not possible to just extract the rootfs from one of the dailies.
<persia> I like rootstock, but if you seek ubuntu-netbook, I'd think that scripting something to pull out the squashfs and reformat it into the target format would be easier.
<rcn-ee> i thought about wrapping a script around ubuntu's daily and adding the beagle kernel stuff..
<persia> The other alternative would be to work directly in the scripts we use for dailies now: debian-cd .  Something like extracting the squashfs, and then generating a new image with the beagle stuff.
<persia> I think that's where it ultimately belongs, but any script that sets stuff up properly for a first boot would probably be a good start.
<persia> (just because debian-cd can be a pain to set up)
<rcn-ee> and with ubuntu's omap kernel, that would become a reality too...
<persia> If/when it ships :)
<persia> But yeah, once we have the scripts that take some squashfs and create an image, it's just a matter of sticking it into debian-cd, and making application to the cdimage team to host dailies.
<persia> I'm just thinking it may make sense to kickstart that process by trying to get some scripts ready-to-hand for insertion.
<persia> (so that if/when a kernel appears, it's a matter of a couple hours to get everything ready for official images)
<rcn-ee> specially with the ubuntu-netbook option, as i think that's going to be the default arm setup?
<persia> There's three images being built right now: ubuntu-netbook, kubuntu-netbook, and ubuntu-server.
<persia> I don't think any of them are especially "default", although I suspect different groups will advertise each of them differently post-release if they are of sufficient quality.
<rcn-ee> true, and any hardware manufacture will end up tweaking it anyways...
<persia> Most certainly.  For that there's rootstock.
<rcn-ee> thinking off the wall, how about a native arm rootstock..  Some of use got arm cycles to spare.. ;)
<persia> You mean, something like vm-builder?
<rcn-ee> yeap.. debootstrap and friends... :)
<rcn-ee> sweet, ubuntu's omap kernel now boots on a beagle.. now just to remove the 8 other defconfig changes that didn't make it boot...
<persia> Oh, cool!
<rcn-ee> here's the screen shot.. ;) http://pastebin.com/EFKZQi4A
<persia> nice!
 * persia heads off for a while
<asac> bug 514257
<ubot4> Launchpad bug 514257 in xine-lib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514257
<asac> bug 514254
<ubot4> Launchpad bug 514254 in upx-ucl (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514254
<asac> bug 514253
<ubot4> Launchpad bug 514253 in qt4-x11 (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514253
<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: 1)" [Medium,Triaged] https://launchpad.net/bugs/528887
<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,Triaged] https://launchpad.net/bugs/517300
<ogra> 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> bug
<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 udev (Ubuntu) "ATA pass-through commands preventing external HDD to be mounted (affects: 8) (dups: 1)" [Undecided,Confirmed] https://launchpad.net/bugs/515023
<asac> bug 519897
<ubot4> Launchpad bug 519897 in squid (Ubuntu Lucid) (and 1 other project) "[armel] squid FTBFS: cf_gen Segmentation fault (affects: 1)" [Medium,Triaged] https://launchpad.net/bugs/519897
<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,New] https://launchpad.net/bugs/528524
<asac> bug 512959
<ubot4> Launchpad bug 512959 in nautilus (Ubuntu Lucid) (and 5 other projects) "causes crashes on armel with -Wl,-O1 (affects: 1)" [Low,Invalid] https://launchpad.net/bugs/512959
<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,Triaged] https://launchpad.net/bugs/517300
<persia> dyfet: I noticed http://launchpadlibrarian.net/40354346/buildlog_ubuntu-lucid-armel.libmad_0.15.1b-4build1_FAILEDTOBUILD.txt.gz when trying to get stuff built for beta.  Any ideas on what those instructions *should* be?
<dyfet> Not yet, but let me look
<persia> I can't quite tell from the log if it's the compiler emitting stuff we don't want, or just a code change, but I know I can't sort it :)
<dyfet> this may be a thumb issue...
<dyfet> And it looks like it is in effect a dec on carry....
<dyfet> thats interesting, its from the compiler generated asm side, too....
<persia> dyfet: May I leave it to you to sort?
<dyfet> Yes
<persia> Thanks.
<prpplague> davidm: greetings
<prpplague> davidm: long time no see
<prpplague> davidm: you ever do anything with your nail board?
#ubuntu-arm 2010-03-13
<Gopal> can some one help me get ubuntu running on beagle baord
<DanaG> http://elinux.org/BeagleBoardUbuntu -- that site is helpful.
<Gopal> I have installed as per instruction and now at waiting for root filesystem
<DanaG> I use kernels from "rcn-ee.net"
<DanaG> there are some root images also.
<Gopal> I have tried those images but stuck at  Waiting for root device ...
<Gopal> [   23.791564] mmc0: new high speed SDHC card at address aaaa
<Gopal> [   23.797668] mmcblk0: mmc0:aaaa SD04G 3.69 GiB
<Gopal> [   23.802490]  mmcblk0: p1 p2
<DanaG> hmm, try without the "boot.scr" file on the FAT partition.
<DanaG> and what format is your second partition?  if it's ext4, you'll need to tweak u-boot.
<Gopal> no it is ext3
<Gopal> I will try removing boot.scr file and try
<Gopal> Hello Dan, I have removed boot.scr file and still same situation
<DanaG1> hmm, what kernel, and what root?
<DanaG1> I found if I tried to use a karmic listed kernel with lucid rootfs, for example, it hung at about the same point.
<DanaG1> If you have serial console, it might be helpful to pastebin it.
<KjetilK> Hi all! I just came across this: http://news.softpedia.com/news/Acer-Prepares-Freescale-i-MX515-Powered-Smart-Monitor-131435.shtml
<KjetilK> and it occured to me that the monitor could be ideal for running a mythfrontend and X server only, assuming it has the power...
<KjetilK> I don't know if mythtv-frontend is packaged for ARM, but would it be realistic to do something like that with Ubuntu?
<persia> It's completely realistic.
<KjetilK> sounds great!
<KjetilK> so, this CPU will give sufficient performance for 720p with a mythfrontend?
<persia> Well, depends on a whole number of factors :)
<persia> You will want to have the right graphics drivers, or it won't be as useful as you'd like.
<persia> Or just show simple video.
<KjetilK> right
<persia> I have a similar CPU in my NetWalker.  For some sorts of video, it works great.  For other sorts, it's slow.
<KjetilK> oh, ok
<persia> Looks like mythtv needs a bit of work to compile though : https://launchpad.net/ubuntu/+source/mythtv/0.23.0~trunk23623-0ubuntu1/+build/1534609/+files/buildlog_ubuntu-lucid-armel.mythtv_0.23.0~trunk23623-0ubuntu1_FAILEDTOBUILD.txt.gz is a log of the build failure from a couple weeks ago.
<KjetilK> is it the encoding is the main factor?
<persia> I don't really know.
 * persia doesn't tend to watch much video on that device.
<KjetilK> OK
<persia> KjetilK: Any help getting the mythtv stuff ported/working would be much appreciated.
<KjetilK> yup, I know :-)
<KjetilK> I would need to buy the device first, then :-)
<KjetilK> I haven't got any ARM devices now
<persia> We have an emulated compilation environment available, if you have an Ubuntu lucid i386 or amd64 install.
<KjetilK> Yeah, I was hoping to get a lucid system running RSN, but real life has interferred too many times :-/
<KjetilK> also, the real reason why I started to look into this was not myth, but something else
<persia> Well, when you get one, ask here, and I'm sure someone can explain how to set up the emulated environment (it's just `mk-sbuild --arch=armel lucid` but that's easy to forget)
<KjetilK> I was looking for a cheap device that could transcode and stream video real-time from commodity video cameras over wifi :-)
<persia> Also, if you want to look at mythtv on armel, JamieBennett is probably the person regularly in this channel with the most interest in that area (but perhaps little time).
<KjetilK> yup, great!
<persia> Same issues really : transcoding.  A lot depends on having drivers that can *use* the DSP.
<KjetilK> right
<KjetilK> could the TI OMAP3525 be a candidate for something like that, or would one need something more powerful?
<KjetilK> I kinda like the Gumstix way of doing things :-)
<persia> Personally, I think all the chips are roughly similar in power, but a lot depends on the drivers.
<KjetilK> ok
<persia> Hunt around and find out which chip seems to have the best open DSP drivers for linux.
<persia> Otherwise you'll be doing it on the CPU, and none of them will perform wonderfully under those conditions.
<persia> (not that the CPUs are slow, just that they aren't as fast as GPU or DSP processing).
<KjetilK> yeah, this clearly requires some work
<KjetilK> Also, I suppose another matter could be if Acer has decided to try to prevent people from replacing the OS of that device
<KjetilK> well, for all I know, it could be Ubuntu running on it already
<persia> Oh, right :)  But most devices get hacked eventually.  It's just a matter of tracking which devices have a way to install them.
<DanaG1> oh yeah, you may not actually need a usb-hub power adapter if you have a power adapter for the beagleboard itself.
<KjetilK> yup :-)
#ubuntu-arm 2010-03-14
<koffu> hi
<saeed> ericm_: ping
<koffu> ping reply
<tomeff> hello, i wont try run ubuntu on HTC Hero, but i cant find any how to compile kernel and some rootfs, and bootloader in htc wont .img but all kernels is .bin, how xD
<tomeff> ok i found rootfs :)
<armin76> tomeff: lucid won't work on it, btw
<armin76> and karmic either
<tomeff> comes to me at all to find out if it goes on, you think you could help neak? (compile kernel and switched to. img)
<tomeff> neak = any :D translate.google :D
<armin76> tomeff: sorry, i can't, i have no clue about putting linux on a phone, i only know that neither karmic nor lucid will work on the htc hero, since it has an armv6 processor that lacks vfp
<tomeff> and you know someone who could help?
<armin76> nope, sorry
<tomeff> or another distro for arm :D
#ubuntu-arm 2011-03-07
<Xase> Think I can fully install Ubuntu on the Nook Color with this processor ARM Cortex A8-based Ti OMAP 3621? Instead of that stupid Ubuntu ARM over VNC on Android trick?
<hrw> can someone copy me bootcmd from normal ubuntu uboot for panda/beagle?
<hrw> ~summon ogra
 * ogra waves
<hrw> http://pastebin.com/YXWdZTfe - lovely hang
<hrw> ubuntu mlo + uboot + .35 kernel
<hrw> same with linaro mlo (1.44)
<hrw> worked with .37-linaro kernel
<hrw> and my board shutdowns when ubuntu/xload + ubuntu/uboot + linaro.37 are used
<ogra> weird
<ogra> we dont have such probs
<hrw> I will dig other psu to compare
<ogra> http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-3/
<ogra> try with this image, it definitely worked on all our boards
<ogra> .35 kernel, and the x-loader and u-boot from natty
<ogra> afaik we are using all the same x-loader and u-boot linaro packages
<hrw> will check
<ogra> i have never seen such an x-loader hangs message that late in the boot
<hrw> if image will fail to boot I will start to send more curses^Wcomplains in TI direction
<ogra> only if the FAT wasnt ok but then usually before the kernel gets exectuted
<hrw> fsck passed
<ogra> doesnt matter
<ogra> x-loader-omap4-panda and u-boot-linaro-omap4-panda are the binary packages we currently use in ubuntu
<fairuz> outer_flush_range will flush L1 and L2 or only L2? =)
<noah1989> hi, has anyone got s-video working correctly on the beagleboard xM?
<noah1989> it kinda works with the natty alpha-2 image
<ogra> i think GrueMaster wanted to test it once
<ogra> but you have to wait until he gets up (US Pacific TZ)
<noah1989> however the resolution is not correct (larger than 640x480) and the left part is off-screen
<noah1989> twaeaking the timings doesn't work. only the predefined "ntsc" and "pal" are accepted
<noah1989> everything else -> invalid argument
<hrw> so far so good - booting
<ogra> with what files ?
<ogra> and what did you do to get there ?
<noah1989> orga: are u talking to me?
<ogra> no to hrw
<noah1989> ok
<ogra> i have no svideo around to even test so i cant tell much about it
<hrw> ogra: alpha3 image
<ogra> ah, k
<ogra> intresting
<hrw> ogra: booted to language selector and have to findout where my usb devices are
<ogra> if you used the same packages it can only be your formatting
<hrw> so linaro-image-tools
<ogra> right, likely a wrong formatting of the vfat
<hrw> time to report bugs against installer?
<ogra> which installer ?
<ogra> l-i-t ?
<hrw> oem-setup or how ubuntu installer is named
<ogra> hmm, why ?
<hrw> keyboard selector lacks Polish chars in country/layout lists
<hrw> "Po?udniowoafryka?ski" or "Pakista?ski"
<hrw> font has "Å Å" characters cause they are used in other places
<ogra> hmm, intresting
<noah1989> " S-video resolution is 720x574 (pal) or 720x482 (ntsc). The edges of that
<noah1989>     area are usually not shown by the TVs. To get a framebuffer that is
<noah1989>     fully visible, you need to resize and move the overlay."
<noah1989> ah! didn#t know that..
<hrw> http://42.pl/u/2z8N
<hrw> ogra: http://42.pl/u/2z8N
<ogra> intresting
<ogra> they dont wear bras
<ogra> :P
<LetoThe2nd> oO( erm... what? )
<ogra> the pic hrw linked to
<LetoThe2nd> gnah. that one again.
<hrw> nice thing is that installation does not require mouse
<hrw> desktop is unusable without it
<ogra> yeah, there is a bug open for unity-2d accessibility
<ogra> you can select classic gnome at the login manager though
<ogra> that should be usable by kbd
<hrw> cyanish framebuffer works
<ogra> indeed
 * ogra wonders whern someone will add fi fix for the color offset
<hrw> ogra: there are rumours that 2.6.66 'ivil edition' will have it
<ogra> should really not be to hard to manipulate the rgb defaults
<ogra> your font stuff is intresting, seems to only affect the selection list, all other parts of the app have the right encoding
<hrw> exactly
<hrw> #ubuntu-installer exists?
<ogra> yep
<ogra> talk to ev
<hrw> thx
<noah1989> installation works w/o mouse EXCEPT time zone setting
<ppisati> orga: ping
<ppisati> ogra: ping
<apw> ogra, meet ppisati ...
<apw> ogra, is going to be doing some arm work on the kernel team
<armin76> looks like ogra is hiding from him
<ogra> ppisati, apw, awesome
<ogra> !!
<ogra> janimo, whats that about your NEON patch to Qt ?
<ppisati> ogra: Hi! i just got a mvl-dove board, do you know where i can find an image for it?
<janimo> ogra, FTBFS fix, some files were not properly passed -mfpu=neon  so gcc bailed
<janimo> needed a change to gui.pro in the sources
<janimo> I'll update the bugreport
<ogra> janimo, i see that, but i would know about the implications
 * janimo is annoyed by whatver changed lately in natty that fails to highlight xchat pings
<janimo> ogra, we'll see the implications once it builds I guess
<ogra> are there now *any* files in the archive that have NEON enabled in a hardcoded way ?
<janimo> there are a few files built with neon options
<janimo> the rest of Qt without
<ogra> thats not acceptable
<janimo> so hopefully only when those are enabled at runtime will run
<janimo> I looked over the bugreport comments and am not 100% sure I understand everything
<ogra> all NEON paths in code need to be runtime switched or off by default
<janimo> however my patch so far is not assuming it fixes neon
<janimo> just fixes the build
<janimo> then we see if neon runtime detection works and fix it if it does not
<ogra> well, -mfpu=neon will enable it hardcoded for these files
<janimo> ogra, I believe that is what Qt does but have not checked. A few files which are built with neon should only be used when neon is detected
<janimo> ogra, right, but those function will not be called all the time
<ogra> k
<ogra> lets test then
<janimo> otherwise there is not neon at all if we do not build at least some functions with it
<ogra> i guess i need to upgrade my ac100 to natty this week :(
<ogra> ppisati, http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ was the last release we built for dove (not sure how well that image works though, you might be better off with the lucid one)
<janimo> ogra I also took out gnome-panel from u-2d deps, hopefully it wil not be included on the image soon
<janimo> as it is not used
<ogra> it is used
<ogra> by gdm
<janimo> I don;t think it is
<janimo> if so it will be pulled in by gdm then
<ogra> gdm uses a cut down gnome standard session in the greeter
<janimo> I have not seen anything resembling the gnome-panel in gdm login screens
<janimo> just shutdown/reboot menu but that is different
<ogra> the panel at the bottom is gnome-panel afaik
<ogra> in any case we need gnome-panel for the classic session, if all deps are removed i need to seed it
<janimo> ogra, we also have the classis session on the image??
<ogra> sure
<janimo> I thiught unity and unity-2d is all
<ogra> no
<janimo> oh boy
<ogra> we have a minimal classic session as -desktop does
<janimo> the whole kitchen sink. So the chances of getting a mixed up nonfucntional environment like now compiz crashing+gnome classic creates on x86
<ogra> the only thing we additionally use is unity-2d, else our setup needs to match -desktop
<ogra> doesnt carsh for me here
<janimo> I have not yet run unity successfuly
<ogra> wow
<ogra> graphics card ?
<janimo> and am not sure the bothed experience I get with classic now is due to unity bits remaning or gnome-calssic changed as well
<janimo> intel
<janimo> had workse on ati r300
<janimo> I mean it runs for a while then crashes
<ogra> hmm, my 965 works fine here
<ogra> with unity as well as witch classic
<janimo> dual screen support looks weird - tooltips on a different screen than the buttons they belong to
<janimo> I seea deluge of unity bugs and I do not have the time to fight it
<ogra> ah, i only use an external screen on my laptop, but in single screen mode (laptop LCD off)
<janimo> this is GMA4500
<ogra> ah, thats newer
<janimo> maybe it is the dual setup, anyway I cannot image how this is going to be very stable in less than two months
<ogra> heh
<janimo> did the gnome-classic experience change too?
<ogra> ask the DX team, they seem to be confident
<ogra> (from what i gather in the release team meetings on fridays)
<janimo> I see only one menu now in the corner (not app/places/system)
<ogra> gnome-classic should look like it did before
<ogra> i.e. in maverick
<janimo> and the app menus are gone - I thought only unity moves them to top of screen
<ogra> i have appmenus here
<janimo> ok, so unity bits stay around even if compiz crashes. convenient
<janimo> I guess I need to reboot more often and not just suspend/resume
<ogra> i have to use classic because i just digitize my LP collection, audaciy (and i guess other wxwidget apps) doesnt work right with the appmenu in panel
<ogra> runs as smooth as always
<janimo> ok, that is reassuring
<janimo> ogra, have you seen the debian-cd merge request?
<ogra> hmm, no
<lool> janimo: I did
<lool> janimo: I flagged it as "I should really look at it" but didn't get the time
<janimo> lool, ok thanks
<ogra> gah
<ogra> wh does update-manager install postfix on a maverick->natty upgrade
<rsalveti> morning
<ogra> hey, isnt it a public holiday in brazil ?
<ogra> or only if you dance ?
<rsalveti> yup, carnival
<rsalveti> but I'm more to rock and roll than the usual carnival dance ;-)
<rsalveti> ogra: janimo: in theory the neon issue would be solved by compiling just the neon affected files with neon support
<rsalveti> and then at runtime it'd load the correct lib
<rsalveti> that's what I think it was changed for qt 4.7.2
<ogra> rsalveti, yeah, the question is if thats really the case
<rsalveti> we'll see :-)
<ogra> but i'm just upgrading to natty here
<ogra> so as soon as it built i can test
<ogra> (if that upgrade ever finishes)
<janimo> ogra, only one day left to go :)
<ogra> yeah, possibly the same for my upgrade :P
<janimo> it just finished buildin on a panda here, started lastd night
<rsalveti> ppisati: welcome!
 * ogra urgently needs to re-roll the ac100 kernel with all patches here ... the MMC driver doesnt know about fast cards and limits itself to 16M/s
<janimo> ogra, do you have the sources to that kernel? can it be patched to 2.6.38?
<ogra> it cant, but some people are working on moving it to .36 atm
<ogra> once thats done the next level shouldnt be to hard
<ogra> problem is that apparently the clocks arent set anywhere in the 2.6.29 code so they currently use random values and try to determine the right ones
<ppisati> rsalveti: yeah :)
<hrw> ogra: you have devscripts installed?
<ogra> hrw, only with --no-install-recommends
<ogra> might be that u-m doesnt respect that though
<ogra> which is annoying
<ppisati> ericm: ping
<ericm> ppisati, pong
<ericm> ppisati, did you get the package?
<ppisati> ericm: got the board, but i'm unable to get it running
<ericm> ppisati, what's wrong?
<ppisati> ericm: wait let me tell you what i did
<ericm> ppisati, 'k
<ppisati> ericm: i got a mvl image (http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-netbook-armel+dove.img)
<ppisati> ericm: dd it on a sd card
<ppisati> ericm: put the sd card in sd 1 or 2 (tried both)
<ericm> ppisati, ah - it doesn't boot from SD
<ericm> ppisati, try USB
<ppisati> ericm: ah
<ppisati> ericm: so i need a usb stick?
<ericm> ppisati, yep
<ppisati> ericm: k, let my try
<ppisati> ericm: does it make any difference in which usb port i plug the stick?
<ericm> ppisati, nope
<ericm> ppisati, but you can try
<ericm> ppisati, if it doesn't boot on one or the other
<ppisati> ericm: the serial should work, right?
<ericm> ppisati, I remember so - but last time I was unable to see anything from there
<ericm> ppisati, cannot remember of if it's now using the USB serial besides that RS232 connector
<ppisati> ericm: but at least the vga output should spit something, right?
<ericm> ppisati, yep
<ericm> ppisati, or you may want to try a different monitor
<ericm> ppisati, I have two monitors here, one work, the other doesn't
<ericm> ppisati, :-)
<ppisati> ericm: no signs of life :(
<ericm> ppisati, :-(
<ppisati> ericm: which .img did you use with that board?
<ericm> ppisati, I used 10.04
<ogra> as i said above, maverick might not work
<ppisati> ogra: k
<ericm> ogra, cannot find the 10.04 dove image though, strange
<ppisati> ericm: yep, it's not there
<ogra> might be on releases.u.c
<ppisati> ogra: found it, let me try that
<ogra> GrueMaster, hmm, when did you do your last natty upgrade test, cups seems to hang here upgrading the ac100 to natty
<ogra> i wonder if thats a recent regression or something new
<ppisati> ogra: no luck either with 10.04
<ogra> weird
<ppisati> yep :(
<ogra> ppisati, talk to GrueMaster and NCommander, they are the only ones still owning dove boards in the arm team
<ppisati> ogra: ok, thanks
<ogra> (we havent touched it actively in the team since a year, NCommander did a special spinnoff for the maverick release)
<ppisati> NCommander: ping
<ppisati> GrueMaster: ping
<ogra> what revision is your board ?
<ppisati> ogra: is it written on the pcb?
<ogra> there should be a sticker
<ogra> i think we only supported X0 and upwards in the end
<ogra> not sure though
<ppisati> ogra: actually ericm said he was using this
<GrueMaster> ppisati: morning.
<ogra> hmm, k
<GrueMaster> (barely)
<ppisati> GrueMaster: morning
<ogra> GrueMaster, ppisati is our new arm kernel victim :)
<GrueMaster> I'm sorry.
<ppisati> :)
<ogra> lol
<ericm> ppisati, it's A0 and lucid installation should be working
<ericm> ppisati, I installed it days ago
<ppisati> ericm: usb stick and vga output, right?
<ericm> ppisati, yes
<doko> janimo: saw a new qt4-x11 update today. this should be repeated after today's gcc-4.5 is in the archive
<ogra> doko, you mean rebuilt  :)
<ericm> ppisati, is the hex LED increasing ever?
<ogra> and the ugly hack dropped
<ppisati> ogra: actually it's completely off
<ppisati> ogra: while a couple of other green leds are on
<doko> ogra: whatever ...
<ppisati> ogra: did you use an atx power brick to power it?
<ogra> doko, i meant to say ... its high up on our radar, dont worry :)
<ogra> ppisati, yes and a sata disk ... but i only had a Y0
<ogra> thats loooong ago
<ppisati> ogra: k
<ppisati> ericm: and did you use an atx power brick too?
<ericm> ppisati, yes
<ppisati> ericm: and do you remember if the HEX leds were on?
<ppisati> ericm: i mean, even when it didn't boot
<ericm> ppisati, it's powered on as '7'
<ericm> ppisati, or '0'
<ppisati> ericm: i'm trying to rule out a power problem
<ericm> ppisati, and when kernel actually boots, it starts increasing from 0 to 7
<ericm> ppisati, it's a standard ATX, shouldn't be much a problem
<ppisati> ericm: uhmm...
<ericm> ppisati, have to sleep now - let me know if you succeed with that crappy board :-)
<ericm> ppisati, good luck
<GrueMaster> ppisati: I can work with you on getting your dove running, but I need my coffee first.  Give me 15 minutes.
<ppisati> GrueMaster: k, thanks
<GrueMaster> ppisati: Ok, I'm semi-awake now.  Have you gotten anywhere with your dove board yet?
<ppisati> GrueMaster: nope
<GrueMaster> Are you getting power?
<ppisati> GrueMaster: i tried with a Lucid and Maverick image on sd and usb
<ppisati> GrueMaster: well, i'm using an ATX power brick
<ppisati> GrueMaster: the HEX lcd is off, but a couple of green leds on the board turn on
<ppisati> GrueMaster: so i guess power is ok
<ppisati> GrueMaster: could you try to power on a board with no usb/sd inside and tell me if the LCD turns on?
<GrueMaster> No, that just means standby power is available.  Press the power button.  It is on the mainboard, next to the barrel power connector .
<GrueMaster> I am currently rebooting mine into Lucid.  Works just fine.
<ppisati> GrueMaster: ...
<ppisati> GrueMaster: i fell really dumb now...
<GrueMaster> heh.
<ppisati> GrueMaster: thanks
<GrueMaster> No problem.  And don't worry, I won't start your beer tab for at least a week.  :P
<GrueMaster> ogra: What was the issue you had with Cups?
<ppisati> GrueMaster: :)
<ogra> GrueMaster, service restart/stop from the preinst/postinst scripts seemed to hang
<GrueMaster> Hmmm.
<GrueMaster> This is in natty?
<ogra> maverick to natty on the ac100
<GrueMaster> Not that I have an ac100 to test with, but I'll try to reproduce it today on panda.  May take a while (install, update, upgrade).
<ogra> yeah
<ogra> 3h up to now on the ac100
<ogra> i just used do-release-upgrade on cmdline though
<GrueMaster> Ok.  I'll keep that in mind.
<hrw> ogra: you finally upgrade?
<ogra> yes
<ogra> need to test neon bits
<hrw> ;D
<hrw> I am waiting for courier to replace alix.1c (amd geodelx x86) with d510mo (d510 64bit atom)
<hrw> will see how good/bad ubuntu server will work on my router
<ogra> its just x86 hw ...
<ogra> it will work well
<hrw> I had binutils-powerpc-linux-gnu on router...
<GrueMaster> ppisati: Did your system boot?
<janimo> doko, I noticed the new gcc contains the fix, but I wanted to do an upload so I don't wait another day, and more importantly so that we have a 4.7.2 in a a hopefully working state with gcc 4.4 and have the compiler change as a separate step , in case somehtign goes wrong we don't have to scractj our heads againt whether it is a toolcahin on upstream change that caused the difference
<janimo> but yes, we need to rebuild with gcc 4.5 ASAP
<ogra> janimo, well, we also need to drop the patch anyway
<ogra> i guess if we take care by thu. it will be ok
<ogra> both packages will have built then
<janimo> what is thu, another milestone?
<ogra> yeah, the weekly thursday milestone ... comes right before the weekly friday one ;)
<janimo> ogra, by tomorrow we'll see if neon runtime detection work adn whether another qt change is needed
<janimo> :)
<ogra> right
<ogra> i dont think we are in a hurry with the rebuild ... though the kde people might disagree
<ogra> not sure how much pressure has built up there
<janimo> ogra, whay would they care that much?
<ogra> because not all of kde is built yet ?
<janimo> as long as it is agreed it is a temporary measure and has no drawbacks
 * ogra hasnt checked the list
<janimo> ogra, ah, I thought it was in reference to qt
<ogra> nah, kde
<janimo> indeed kde needs rebuilds, I think this is taken care of kubuntu devs unless it is arm specific FTBFS
<janimo> I think it is just the usual deps not yet met thing
<ogra> yep
<ogra> xulrunner-1.9.2 (1.9.2.14+build3+nobinonly-0ubuntu2) wird eingerichtet ...
<ogra> Segmentation fault (core dumped)
<ogra> hrm
<ogra> not good
<GrueMaster> Hey, I got Blaze running natty A3.  replaced x-loader & u-boot with rsalveti's secret sauce and everything looks good, even unity-2d.
<rsalveti> GrueMaster: \o/
<ndec1> GrueMaster: which kernel are you using?
<ogra> awesome
<GrueMaster> Default kernel that is in the image.  2.6.35-1101.4 I think.
<ndec1> GrueMaster: thx
<GrueMaster> ogra: rsalvetiWhat are the chances of having both panda & blaze versions of uboot & xloader in the deb package?  Or are they heading towards a single binary?
<GrueMaster> Ugh.  Fresh install of maverick, then dist-upgrade == 242 package updates.
<rsalveti> GrueMaster: they will be the same binary
<rsalveti> but we're still waiting correct sdp support from ti with x-loader upstream
<GrueMaster> Cool
<rsalveti> oh, sorry, at least x-loader needs to be a different binary
<rsalveti> because of the hardware id
<GrueMaster> It can't auto-detect?
<rsalveti> it could be the same binary, but then it'd need a way to identify the hardware before actually initializing it
<rsalveti> hrw: the x-loader you were using is a quite old one
<rsalveti> that could be your problem
<rsalveti> or even a simple fat problem with your first disk partition
<GrueMaster> rsalveti: linux-image-2.6.38-1204.5 working on my panda.  Even have dvi output (shocking).  Thought I might need a rework.
<rsalveti> GrueMaster: awesome
<rsalveti> GrueMaster: does it crash when you halt or reboot?
<rsalveti> GrueMaster: please check if the sound and wireless is also working
<rsalveti> if possible
<GrueMaster> Didn't appear to on reboot
<GrueMaster> (crash that is).
<GrueMaster> Had to reboot a couple of times.  Once to add dvi settings to boot.script, and another because I forgot to add the kernel version to flash-kernel when updating boot.script (oops).
<GrueMaster> So I have booted back and forth a couple of times between .35 & .38.
<GrueMaster> Bluetooth appears to be enabled.  Haven't tested yet.  Wifi also appears to have been detected.
<GrueMaster> Does wifi need firmware?
<rsalveti> GrueMaster: it needs a firmware
<rsalveti> but probably already installed
<GrueMaster> Ok.  Might need an antennae.  Don't have one handy and my wifi AP is in another room.
<rsalveti> could be even the lack of proper calibration values
<rsalveti> sebjan may help here
<sebjan> GrueMaster: the wlan firmware coming with the linux-firmware package is the good one.
<sebjan> for calibration: http://wireless.kernel.org/en/users/Drivers/wl12xx#Calibration
<sebjan> (did not try that myself yet)
<GrueMaster> sebjan: ok, will check in a sec.  Trying to get audio now.
<sebjan> GrueMaster: for WLAN, you may have a MAC address set to 0. This can hurt. For now, the best is to set a random MAC address manually (using ifconfig)
<sebjan> GrueMaster: fyi, here is the way I tested wlan and audio on this kernel: http://paste.ubuntu.com/577134/
<GrueMaster> rsalveti: no audio at all.
<sebjan> GrueMaster: you need some mixers settings
<rsalveti> hm, I think you need to set the mixers by hand
<GrueMaster> Yea, I was tweaking alsamixer manually.
<GrueMaster> While running speaker-test -c 2 -t wav in another terminal.
 * sebjan has to go
<rsalveti> GrueMaster: http://paste.ubuntu.com/577137/
<rsalveti> from sebjan's email
<sebjan> yep, you have this one plus the record mixers in my above http://paste.ubuntu.com/577134/ compilation ;-)
<rsalveti> that should do it :-)
<GrueMaster> Nope, nothing.
<GrueMaster> This is on natty w/ 2.6.38-1204.5.
<GrueMaster> Hmmm.  dmesg has "asoc:  no valid backend routes for PCM:  SDP4430 Media" repeated multiple times.
<GrueMaster> Could be pulseaudio related though.  No hw in pulseaudio.  No sound using alsa tools.
<rsalveti> hm, weird
<rsalveti> even after erasing the current alsa state?
<rsalveti> because it'll try to load with the settings with had form maverick's kernel
<rsalveti> *we had
<GrueMaster> Nope.  No audio.  I deleted /var/lib/alsa/asound.state, sync'd the SD, then hard reset so state wasn't saved.  Then ran script with amixer settings to start fresh.  Still no sound.
<brose> hey all, is the maintainer of the ubuntu-omap4-extras package present?
<rsalveti> brose: ti is in general, but you can ask the question
<brose> I was interested in making a similar package for fedora-arm, was wondering if it was possible to attain the source in some manner (e.g. binary blobs like the nvidia prop driver)
<dcordes_> rsalveti: you guys keep anything platform specific in such packages ?
<rsalveti> brose: I believe you can distribute some packages
<rsalveti> need to check the licenses from all binary packages, but I believe you'd be ok to at least distribute the powervr sgx ones
<rsalveti> the wireless is now upstream, so you don't need to distribute the firmware
<rsalveti> for the video decoding part I don't know the details of the license, need to check
<rsalveti> dcordes_: only the ti blobs to make panda work with all the extras
<dcordes_> rsalveti: ok I'm considering to add all the device specific things for htc hd2 in some package so people can use their own rootfs base
<rsalveti> dcordes_: sure, if you can distribute this pieces it'd be ok
<dcordes_> rsalveti: it's mostly some ugly scripts for networking
<rsalveti> dcordes_: oh, ok
<dcordes_> hm it's a good point. I didn't think of the bcm4329 blob
<Jack87> Hola!
<Jack87> Ubuntu on Arm sounds like a lot of fun!
<Jack87> how successful has it been?
<dcordes_> Jack87: very successful
<dcordes_> Jack87: it makes many people happy
<Jack87> on any actual mobile devices? or just some of the development boards?
<dcordes_> I use it on the htc hd2
<Jack87> what processor does that have?
<Jack87> dcordes_, are you using Utouch interface stuff with it to?
<armin76> haha
<Jack87> armin76, no making fun.. i dunno what i am talking about. haha here to pick brains and learn
<dcordes_> Jack87: cortex-a8
<Jack87> is there any walk throughs for omap boards?
<Jack87> any work being done on newer devices?
<Jack87> What port would best be sugested for omap 3 devices?
<Jack87> so my goal is trying this out on a nook color
<Jack87> be a great tablet experince i think with netbook remix style and maybe utouch interface
<Jack87> besides the sucker is only $250 for amazing hardware!
<Jack87> any advice would be appreciated
<doko> GrueMaster: ping on bug #605042
<ubot2> Launchpad bug 605042 in linux-fsl-imx51 "[armel] java fails to start with eglibc-2.12-0ubuntu4" [Critical,In progress] https://launchpad.net/bugs/605042
<GrueMaster> doko: Thanks for the reminder.  Last week was psychotic getting Alpha 3 out.  Will start it now.
<doko> cool, thanks
<hrw> rsalveti: it was ubuntu xloader
<rsalveti> hrw: sure, but from what image?
<hrw> rsalveti: from ports.ubuntu.com/pool/ directly
<hrw> rsalveti: it was attempt to try other versions then linaro ones to check for shutdown bug
<rsalveti> oh, ok
<rsalveti> the new package name is x-loader-omap4-panda
<hrw> rsalveti: alpha3 image works so far
<rsalveti> it could be the case you used the older x-loader-omap4
<hrw> maybe
<rsalveti> hrw: cool
<hrw> xloader should die
<rsalveti> yes
<rsalveti> it'll soon I believe
<rsalveti> well, dinner time
 * rsalveti bbl
<sveinse> I got a fatal from qemu while trying to install natty using rootstock (from maverick)
<GrueMaster> doko: Ok, after compiling and running the testcase attached to bug 605042 on a normal babbage image with latest kernel (2.6.31-608.22), I am able to reproduce the segfault.  However, booting with the kernel from Jeremy Kerr (comment #42), I no longer segfault.
<ubot2> Launchpad bug 605042 in linux-fsl-imx51 "[armel] java fails to start with eglibc-2.12-0ubuntu4" [Critical,In progress] https://launchpad.net/bugs/605042
<doko> GrueMaster: and installing the mentioned libc6/libc6-dev, java -version works?
<doko> of course in a maverick chroot
<GrueMaster> I am using the latest openjdk-6-jre-headless, 6b18-1.8.5-0ubuntu1~10.04
<GrueMaster> java -version hasn't failed in either test.
<doko> GrueMaster: I just wanted to double that it still works with the libc6 package from mentioned in the report
<doko> double check even
<GrueMaster> I'll check.
<GrueMaster> The one I have is:
<GrueMaster> ubuntu@babbage3:~$ /lib/libc.so.6 --version
<GrueMaster> GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.8) stable release version 2.11.1, by Roland McGrath et al.
<GrueMaster> not sure why the different versions.
<doko> GrueMaster: is this a lucid install?
<GrueMaster> yes
<doko> because the version I need to have tested is 2.12-0ubuntu4. so you would have to install a maverick chroot and downgrade to this version in the chroot
<doko> both libc6 and libc6-dev
<GrueMaster> ok
<GrueMaster> Lucky for you my system doubles as a buildd test env when not testing updates.  :P
<doko> if you want to check further, grab the natty eglibc, and back out the any/cvs-revert-flush-cache-textrels.diff patch
<GrueMaster> Ok, I was able to rebuild and retest the testcase in a maverick chroot with downrev'd libc6 2.12-0ubuntu4.  Works.  Will reboot to older kernel and see if it fails.
 * doko waits for the reboot
<doko> GrueMaster: ?
<GrueMaster> ok, segfaults with the released kernel, passes with the test kernel.
<doko> sucess! tvm!
<GrueMaster> np.
#ubuntu-arm 2011-03-08
<doko> GrueMaster: please document your testing in the bug report
<GrueMaster> ok, will do.
<GrueMaster> Updated.  And I'm calling it a day.  Ping me if you need me.
<sveinse> Anyone tried running rootstock installing natty? I'm getting a fatal from qemu and a subsequent lockup
<rsalveti> sveinse: are you trying with qemu from maverick?
<sveinse> yes
<rsalveti> that could be the issue
<rsalveti> newer qemu is a lot better, but I believe only available for natty atm
<rsalveti> maybe linaro is also providing it at a ppa
<sveinse> ok, thanks. I'll try natty then
<rsalveti> it's now called qemu-linaro
<rsalveti> the src package
<sveinse> OT: Is there installers for natty (i386) available? I need to setup a new virtualbox with natty then
<rsalveti> sveinse: you can download and install our alpha 3 image
<rsalveti> that was released last week
<sveinse> rsalveti: uhm, where exactly can I find the alpha 3 images? I cant seem to find them
<rsalveti> sveinse: http://www.ubuntu.com/testing/natty/alpha3
<sveinse> thanks
<ppisati> ericm_: ping
<Audio> HI All, I have used latest  Maverick image and booted the panda board. But none of the sound drivers are installed. How can i get audio drivers installed?
<ppisati> ericm_: i managed to get the dove board working (it was a dumb mistake on my side... :P)
<ppisati> ericm_: now i'm building a new kernel for it (old way make uImage ARCH=arm CROSS_COMPILE...)
<ppisati> ericm_: but i noticed that i used on dove, contrary to omap that uses rootstock and a plain fs, a squashfs
<ppisati> ericm_: can you tell me how to recreate it? or, how to get a new kernel there?
<ppisati> ericm_: i mean, besides copying uImage over the stick
<ppisati> ericm_: is there something else that i should do? i.e. what about the modules? and so on...
<Audio> #pandaboard
<ericm_> ppisati, I normally use fdr binary-dove
<ericm_> ppisati, for the kernel package, but you need something like below first
<ericm_> export $(dpkg-architecture -aarmel); export CROSS_COMPILE=arm-linux-gnueabi-
<ericm_> ppisati, and then do a 'fdr clean; fdr binary-dove'
<ppisati> ericm_: fdr? let me try
<ericm_> ppisati, fakeroot debian/rules
<ppisati> ericm_: and excuse me if i hammer you with stupid questions, but i want to get started (boot the board, compile custom kernels for it, install new kernel, etcetc)
<ericm_> ppisati, dude I'm completely fine, you are doing good
<ppisati> ericm_: k
<ppisati> ericm_: and with the binady-dove i get... a .deb?
<ericm_> ppisati, yep
<ericm_> ppisati, in the parent directory
<ppisati> ericm_: ok, and how do i install it in the dove image?
<ppisati> ericm_: it's a squashfs image, i can't copy there and dpkg -i ...
<ericm_> ppisati, copy it over - through wire or usb
<ericm_> ppisati, oh - you may want to install that image first
<ericm_> ppisati, you need a SATA hard drive
<ppisati> ericm_: no no, wait... :P)
<ppisati> :)
<ppisati> ericm_: we have 2 things (actually 3)
<ppisati> ericm_: to update here
<ppisati> ericm_: the uImage in casper/ (and i can just copy over it) and that's ok
<ppisati> ericm_: but then i've to update the modules and uInitrd
<ppisati> ericm_: i already tried to copy an uImage i produced with make uImage but at boot the board was not so happy
<ericm_> ppisati, the casper/ image is the installer image, so you just want to use that image as a test base instead of a full system?
<ppisati> ericm_: ok
<ericm_> ppisati, yeah - probably modules missing due to uInitrd not matching
<ppisati> ericm_: right
<ppisati> ericm_: how do i recreate uInitrd and the lib/modules/... stuff?
<ericm_> ppisati, to cross generate the uInitrd is much more painful
<ericm_> ppisati, if you insist doing that - you may need a chroot environment
<ppisati> ericm_: uhm
<ppisati> ericm_: so i guess you compiled it natively?
<ppisati> from the arm board itself
<ppisati> i guess
<ericm_> ppisati, but I personally prefer to install the system and get it generated natively
<ericm_> ppisati, yes
<ppisati> ericm-dinner: so let me see if i got it right, you attached a sata hd to the mvl dove
<ppisati> ericm-dinner: booted via a usb stick
<ppisati> ericm-dinner: installed everything on sata disk
<ppisati> ericm-dinner: and then used that for all the work, right?
<sveinse> Hi. I'm getting a lot of "include/qt4/QtCore/qstring.h:187:17: note: the mangling of âva_listâ has changed in GCC 4.4" while cross compiling Qt for armel. Anyone familiar with a fix?
<ogra> fix the code :)
<sveinse> The source has been patched with 92_armel_gcc43_valist_compat.diff from qt4-x11 sources, but it doesn't seem to stop the nagging
<sveinse> interestingly I'm getting no response from the qt-developers, they don't have the issue
<ppisati> ogra: can i ask you for the dove board too?
<ogra> well, are they using 4.5 and the gold toolchain ?
<sveinse> I've noticed that qt and (linaro/ubuntu) gcc isn't always best of friends
<ogra> ppisati, you mean hos i installed my dove back then ?
<ogra> *how
<sveinse> I've tried both 4.4(.4) and 4.5(.2)
<ppisati> ogra: yep, more or less
<ogra> iirc i used usb to install to the sata disk
<ppisati> ogra: booted from the disk and did all the compilation from there, right?
<ogra> having my full system on sata in the end
<ogra> compilation ?
<ppisati> ogra: yep
<ppisati> ogra: new kernel and stuff like that
<ppisati> ogra: actually it's the kernel, kernel modules and uInitrd
<ogra> well, i only compile userspace packages usually, but yes
<ppisati> ogra: uhm... k
<ogra> i dont touch kernel if i dont have to, thats what we have you guys for ;)
 * ogra is a consumer of the binaries here 
<ogra> sveinse, well, i can only point you to the toolchain specialists in #linaro
<ogra> but i would think that gcc and binutils gold are way more strict than whats out there elsewheer
<ogra> *elsewhere
<sveinse> well, thanks
<ogra> s/gcc/linaro gcc/
<sveinse> yeah, I got that.
<sveinse> Except I'm not running linaro gcc yet, since my target system still is maverick. And I can't install natty via rootstock since qemu fails *sigh*
<ogra> maverick uses linaro gcc
<ogra> all over the place
<lool> sveinse: You could try with qemu-linaro
<lool> sveinse: We have a backport in the ~linaro-maintainers tools PPA; it's fairly solid
<lool> it does break versatile kernels though, but we can switch to vexpress instead  :-)
<lool> ogra rsalveti: ^
<ogra> do we have a netinst setup for vexpress ?
<ogra> (to have an easy place to download vmlinuz)
<sveinse> lool, I found this: https://code.launchpad.net/~linaro-maintainers/ubuntu/maverick/qemu-linaro/ppa - Are there any prebuilt packages available, or do I need to build from source?
<lool> sveinse: https://launchpad.net/~linaro-maintainers/+archive/tools is the one
<sveinse> lool, aaah. Thanks a lot
<ppisati> ogra: do you know who created the dove image?
<ppisati> ogra: i'm trying to replace the kernel there with a new one
<ericm|ubuntu> ppisati, it's auto generated I guess
<ogra> design and initial creation was a team effort, all further maintenance after bringing it to existance is done by NCommander
<ppisati> ogra: k, all ping ncommander then
<ppisati> we are rallying in Millibank
<ppisati> and i don't have any sata disk to attach to that board
<ppisati> else i would install the system on the disk, compile a new .deb kernel
<ogra> you will have to re-roll the whole initrd if you replace the kernel
<ppisati> copy over there, and install
<ppisati> ogra: right
<ppisati> ogra: that's one of my problem :)
<ogra> since its a casper initramfs
<ppisati> yep
<ppisati> i'ts a squashfs
<ogra> also note that there were massive issues (screen/console related iirc) with the recent set of kernel patches (GrueMaster knows more)
<ppisati> ogra: that's what i'm trying to reproduce :)
<ppisati> ogra: and i hope i got these
<ogra> to re-roll your initrd, just unpack the squashfs ion an intel machine, use qemu-arm-static to chroot into it and do the changes you need
<ppisati> ogra: uhm
 * XorA needs a new cool device :-D
<ppisati> ogra: that's a good idea
<ppisati> ogra: can you walk me to that process?
<ogra> install qemu-kvm-extras.static on your host pc
<ogra> hrm
<ogra> qemu-kvm-extras-static
<ogra> then unpack your squashfs somewhere
<ogra> copy /usr/bin/qemu-arm-static into the unpacked root to usr/bin/
<ogra> then just chroot <your unpacked root>
 * ogra needs to work on a machine without internet access for a while ... afk for a few ...
<sveinse> are there a gdb-armel-cross available now? There were some talk of it a while ago
<hrw> sveinse: https://launchpad.net/~linaro-maintainers/+archive/toolchain/+packages
<hrw> sveinse: grab gdb-multiarch
<lool> That reminds me I should do the same thing for gdb-multiarch as for binutils-multiarch
<sveinse> So I install the gdb-multiarch on the host and install gdbserver on target, right?
<lool> sveinse: Yup
<lool> sveinse: There are other gdb servers out there, like the one in qemu or kgdb
<sveinse> lool, yes, but the biggest issue in my experience is to find a native gdbserver for the target system. CSL provides target gdbserver, but it's doesn't run without hazzle due to different runtime libs configs.
<lool> sveinse: well we provide a gdbserver package
<lool> sveinse: It's linux+eglibc
<sveinse> lool, ok. I planned on using the gdbserver package in armel ubuntu... Or simply the gdbserver armel package in the linaro PPA
<ppisati> ogra: the idea is good
<ppisati> ogra: but update-initramfs complains about missing files in /proc&c
<lool> sveinse: Sure, either is fine
<ppisati> root@longino:/# update-initramfs -u -k 2.6.32-204-dove
<ppisati> update-initramfs: Generating /boot/initrd.img-2.6.32-204-dove
<ppisati> cryptsetup: WARNING: could not determine root device from /etc/fstab
<ppisati> /bin/cat: /proc/cmdline: No such file or directory
<ppisati> /bin/grep: /proc/cpuinfo: No such file or directory
<sveinse> lool, excellent. Thanks!
<ppisati> ogra: what scares is that, even if i mount /proc inside the new chroot environment
<ppisati> ogra: stuff like cpuinfo will still reflect the host system
<ppisati> ogra: and that's what update-initramfs is looking for
<sveinse> Hmm. Are there any side-effect to qemu-linaro?
<sveinse> It's eating my cpu cycles while doing apt-get...
<ppisati> ogra: it seems initrd is ok
<ppisati> ogra: even if it complained about /proc
<rsalveti> morning
<GrueMaster> morning all.
<janimo> GrueMaster, hello
<ogra> yo
<GrueMaster> janimo: What's up?  (other than me).
<rsalveti> janimo: how is the qt neon bug going?
 * ogra has to report that testing neon on the ac100 is impossible atm
<ogra> my upgrade to natty failed miserably
<rsalveti> :-(
<ogra> alignment traps, SIGILLs and segfaults all over the place after rebooting
<rsalveti> ouch
<ogra> no input at all in X ... all GTK apps fail
<janimo> GrueMaster, nah, it's just you :)
<janimo> rsalveti, waiting for Qt build to finish
<GrueMaster> Pffft.  Figures.
 * GrueMaster needs his own private barista.
<ogra> i'll try to do a piecemeal upgrade later this evening to identify the package that introduces the issue
<ogra> probably libc but could be higher level
<GrueMaster> ogra: I should be able to tell you later today how my maverick->natty upgrade went.  Spent all day downloading packages (it didn't like my mirror).  Just noticed it was stuck on sudoers file.
<ppisati> NCommander: ping
<ppisati> NCommander: are you the guys who roll the mvl-dove images?
<NCommander> ppisati: were mostly
<ppisati> NCommander: ok
<ppisati> NCommander: can you tell me how do you create it?
<ppisati> NCommander: i'm trying to recreate one with a newer kernel
<ppisati> NCommander: s/^/^cause /
<NCommander> ppisati: why are you trying to respin with a new kernel? Spinning a new image requires a considerable amount of work and trouble
<ppisati> NCommander: i know
<ppisati> NCommander: we are sprinting in Millibank, i've the dove board but no sata disk
<ppisati> NCommander: so the only way to get a new kernel on that board, is to recrate the usb image
<ppisati> NCommander: this is what i did
<ppisati> NCommander: i unsquashed the fs on my fs
<ppisati> NCommander: copied over the modules
<ppisati> NCommander: and recreated the squashfs
<ppisati> NCommander: then i chrooted in it
<NCommander> You need to use livecd-rootfs to respin the squashfs, and modify it to grab your new kernel
<NCommander> ppisati: then use the files it generates
<ppisati> and create the uImage and uInitrd
<ppisati> -update-initramfs -u -k 2.6.32-214-dove
<ppisati> -mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -n initramfs -d /boot/initrd.img-2.6.32-214-dove /boot/uInitrd
<ppisati> -mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n 2.6.32-214-dove -d /boot/vmlinuz-* /boot/uImage
<NCommander> something like that
<ppisati> then i copy the uImage and uInitrd over the usb stick
<ppisati> and boot with that
<NCommander> Yeah
<ppisati> NCommander: uhmmm... so it should be ok
<NCommander> ppisati: ?
<ppisati> NCommander: i mean, i wanted to double check that i didn't do anything stupid on my side
<NCommander> ppisati: no, that sounds right
<ppisati> NCommander: k
<ppisati> NCommander: do you do that by hand everytme?
<NCommander> ppisati: no, there's an entire infrastructure to do and handle it automatically
<amelim> Are there any additional steps required to boot a preinstalled OMAP3 image for a Gumstix Overo?
<rsalveti> probably correct x-loader and u-boot
<rsalveti> you can already find the packages at the archive
<rsalveti> and it should work with natty
<rsalveti> just need to replace the original x-loader and u-boot from the image to the ones for overo
<NCommander> janimo: w.r.t. to the headless stuff, what seed are you using?
<janimo> NCommander, minimal+standard
<janimo> avoiding complicating it to see it work
<janimo> then if we need more custom stuff we can create a seed
<janimo> at least I assumed it is less complicated by not creating a specific seed
<janimo> less files needing change etc
<GrueMaster> Ok, wrt upgrading frm Maverick to Natty, the only issue I have run into so far is that the current default session is for une-efl to run in Maverick, and upgrading reverts to ubuntu desktop (unity + clutter) which fails.  Need to figure out a way to autodetect and select unity-2d.
<amelim> Thanks rsalveti, I'll try that
<GrueMaster> Grrr.  ubiquity is broken on current images.
<amelim> how long should it take to pop up on my monitor on the first boot?
<rsalveti> GrueMaster: how broken?
<GrueMaster> Bah.  Appears to be a simple typo in the latest ubiquity-dm.  I edited /usr/bin/ubiquity-dm:385 and removed one ")" and now it works.
<rsalveti> :-)
<GrueMaster> Bug filed with patch attached.  Sad thing is vi picked it up immediately in auto-syntax check.
<GrueMaster> Aha, looking at the bzr diff, I see how it came about.  4 lines previous changed from "extras.append(subprocess.Popen(" to "proc = subprocess.Popen(" which is why the extra parenthesis was missed.
<GrueMaster> Still, a simple code check would have picked it up.
<lool> GrueMaster: bug #?
<lool> lp #731536
<ubot2> Launchpad bug 731536 in ubiquity "Typo in ubiquity-dm causes ubiquity/oem-config to not launch" [High,New] https://launchpad.net/bugs/731536
<GrueMaster> yep, that's the one.
<GrueMaster> I'm just glad it wasn't uploaded last week.
<lool> Hmm can't commit to it
<lool> send a mp though
<GrueMaster> Huh?
<lool> GrueMaster: Vcs-Bzr is owned by ~ubuntu-installer, so I've sent a merge request with your patch
<GrueMaster> Ah, ok.  I was getting to that next, but had to deal with a system running the latest image.  Multitasking can be fun.
<GrueMaster> janimo: Your boundary limits fail on an 8G class 10 card.  partition 1 file system is unrecognizable.
<GrueMaster> Same with partition 2.
<GrueMaster> dmesg
<janimo> GrueMaster, ouch. Thanks
<janimo> did you test on another card where it works?
<janimo> GrueMaster, omap3 or omap4?
<GrueMaster> I'm doing a write-timing test atm.  Compare flashing yesterday's image with todays.  It appears to be taking a very long time.
<GrueMaster> And this was with omap4.
<janimo> I wonder why the omap4 image is 78M
<janimo> instead of 500M+
<janimo> maybe not fully built?
<janimo> http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20110308.1/
<GrueMaster> Hmm.  Didn't even notice that.  sigh.
<janimo> GrueMaster, so only omap4 was respun I guess, and it came out only slightly larger than the VFAT partition
<GrueMaster> That means zsync clobbered my 20110308 image.  Ok.
<GrueMaster> I'll smack NCommander.
<NCommander> hrm
<NCommander> GrueMaster: bah, it was a case of extreme stupidity on antimony's part.
<NCommander> maybe
<NCommander> hrm
<NCommander> janimo: sfdisk: ERROR: sector 0 does not have an msdos signature /srv/cdimage.ubuntu.com/scratch/ubuntu-netbook/daily-preinstalled/debian-cd/armel+oma$
<NCommander> your fix broke it, I'll back it out and do a .2 to confirm its been unbroken
<janimo> NCommander, hmm, maybe dropping the initial 63 from the first partition
<janimo> I am puzzled why the boot sector was not written
<NCommander> janimo: I'm not really interested in madly guessing to fix this :-/
<janimo> NCommander, do you know why the image came out only 78 M ?
<janimo> was the above error given by the script without >/dev/null ?
<NCommander> janimo: it was what was in the log
<janimo> ok
<amelim> hmm, so I replaced the u-boot.bin and MLO for the Gumstix. However, once I start it up nothing happens. The console outputs that it's booting the kernel but nothing pops up on my screen. :/
<GrueMaster> amelim: What video output are you using?  DVI?
<amelim> HDMI -> DIV
<amelim> sorry DVI
<GrueMaster> Well, that *should* work ok.  Can you try adding console=ttyO2,115200 earlyprintk=tty)2,115200 and seeing if there is something in the kernel output?
<GrueMaster> Unfortunately I don't have one of these devices to test with.
<amelim> to boot.src?
<GrueMaster> yes.  Add them to the bootargs.  You will need to convert the boot.scr to text first (dd bs=64 skip=1 if=boot.scr of=boot.script), make the mod, then reconvert to u-boot script (mkimage -A arm -O linux -T script -d boot.script boot.scr
<GrueMaster> )
<ogra> janimo, NCommander, the script only fails because of the missing redirect to /dev/null, the sfdisk error is normal
<ogra> oh, jani is gone
<NCommander> ogra: I backed it out, and I'm not going to run it down ATM
<ogra> sfdisk always complains if no partition table exists at all
<ogra> Warning: partition 1 does not end at a cylinder boundary
<ogra> Successfully wrote the new partition table
<ogra> Re-reading the partition table ...
<ogra> ....
<ogra> the script runs "set -e", thats why sfdisk fd1 and 2 were redirected to null
<amelim> GrueMaster I'm not getting any output on my console other than what I've seen previously. Here is my boot.script http://pastebin.com/6ZiFYTwU
<GrueMaster> These console lines should give you output on the serial port.  I am assuming you have a serial debugging cable hooked up to your pc?
<amelim> doh, I'm connected through ttyUSB0
<amelim> should I change the script accordingly?
<GrueMaster> Is ttyUSB0 on the desktop system or the overo?
<amelim> host side
<rsalveti> amelim: it could be a bug at the display code for overo
<rsalveti> amelim: can you try linaro's kernel?
<amelim> rsalveti: Where can I find that?
<rsalveti> amelim: package linux-image-linaro-omap
<rsalveti> if you're testing with natty
<amelim> I was working with maverick
<rsalveti> amelim: oh, not sure if it was ever tested with overo
<amelim> I don't suppose there are any pre-installed images for Natty yet?
<rsalveti> amelim: yup, and we just had alpha 3 last week
<amelim> rsalveti: Any chance you can direct me to them? I'm having difficulty finding them
<GrueMaster> amelim: http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-3/
<amelim> many thanks
<GrueMaster> use the omap image.
<amelim> GrueMaster, rsalveti: I've gotten the console to output on boot and have encountered the following error with the installer http://pastebin.com/UWBqtxcX
<GrueMaster> amelim: Which image is this?  Natty Alpha 3?
<amelim> yes
<amelim> Is there a recent version of Ubuntu which is verified to work on an Overo that I can use in the meantime?
<GrueMaster> Not having said hardware, I couldn't tell you.  I am looking into this issue now though to see what may be the cause.
<GrueMaster> But it appears there is a difference with the image I tested vs the image they posted.  Not good.
<GrueMaster> At the console prompt that oem-config dumps you to, try "apt-get remove ubiquity-slideshow-*" and see if it produces anything.
<amelim> neither ubiquity-slideshow-kubuntu nor slideshow-ubuntu were installed
<GrueMaster> ok
<GrueMaster> I'm flashing an SD with that image now.  I should have it ready for boot soon.
<GrueMaster> Good thing I keep a mirror of all images between release milestones.
<GrueMaster> (well, all images I actively work with).
<GrueMaster> Hmm.  Ok, the install finished here without errors.
#ubuntu-arm 2011-03-09
<rsalveti> amelim: did you change the x-loader binary to be the one compatible with overo?
<rsalveti> just to be sure
<rsalveti> it seems that no display is recognized, and that's why X can't start itself
<hrw> morning
<fairuz> hrw: morning
<ogra> janimo, is your local sfdisk lucid ?
<ogra> (note that the build server runs lucid, if you test such changes you should use a chroot)
<dcordes_> morning
<janimo> ogra, natty
<ogra> yeah, thought so
<ogra> it probably behaves differently between natty and lucid
<ogra> but your partition table is created fine as the log shows
<janimo> ogra, I have no idea of the builds systems internal operations so my patch was best effort and Works For Me
<ogra> the error message about the missing table is normal
<janimo> sure
<ogra> you could just add an || true ;)
<ogra> then set -e wont break on it
<janimo> ogra, so on lucid sfdisk actually returns non-0 there?
<ogra> no idea
<janimo> I put an echo $? after that line and it was 0
<janimo> if that is ocnfirmed than indeed || true is a workaround
<ogra> i guess its simply that it outputs to stderr
<janimo> but set -e does care about exit code only
<ogra> the original line redirects both, stderr and stdout to null
<janimo> can I log in and try a build on the server?
<janimo> I cannot debug easily this way
<ogra> i dont think you can if you arent in the cdimage team
<janimo> ah, the team I woved to avoid being tricked into joining
<janimo> ok
<ogra> with a lucid chroot on an x86 machine you should have the same setup ... though note that builds dont run as root
<janimo> ogra, does the script behave the same otherwise?
<janimo> is it the same as inthe public bzr branch?
<janimo> ogra, ah, I completely missed the >/dev/null thing. Even after being told before
<janimo> that may be it
<janimo> I coudl only test this by pasting bits of the script locally somehow that poart gt dropped
<janimo> even if this is not the cause of the bug it still needs to be there for consistency
<ogra> right
<ogra> though i would suspect its the cause
<ogra> janimo, for headless you will also need a line in debian-cd Makefile
<ogra> in tools/boot/natty/common.sh too
<ogra> (not that important since we dont use preseeding (yet))
<lool> janimo, ogra: Ah you folks are reviewing the debian-cd changes?
<ogra> lool, yes, i'm actually integrating them atm, needs a bunch of additional changes
<lool> Ok; I was about to review it, but I see Michael applied, and then revertede
<lool> And you seem to be reviewing
<ogra> lool, oh, that change
<ogra> yeah, he blindly applied and ran a testbuild
<ogra> then reverted when it failed
<ogra> lool, i'm on the headless image changes, not the partition alignment ones
<lool> Oh actually I thought I had written parts of tools/boot/*/post-boot-armel+omap, but I did not
<lool> There are some oddities there
<ogra> lool, tell me
<lool> it mixes bc and $(()) for computation, there is no check on data overlaps
<ogra> h, te mix is likely because two persons worked on it
<lool> This might give rounding errors:
<lool> IMG_SIZE_BLOCKS="$((($BOOT_SIZE + $IMAGE_SIZE + 512 - 1) / 512))"
<lool> It's ok because BOOT_SIZE is a multiple of 512, but would it not be, it would give a too small number
<ogra> we never had any since lucid
<ogra> the script is two releases old already, it has at least no blocker bugs ...
<lool> In janimo's changes, I preferred 0x0C and ",,,-" instead of "C" and ",+" but that's cosmetic
<ogra> well, janimo's changes fail atm
<ogra> http://paste.ubuntu.com/577608/
<ogra> i suspect its simply because the sfdisk output of stderr isnt redirected
<lool> ah there is a bug
<lool> Hmm
<lool> ogra: This seems like fdisk failing to me
<lool> Probably because it's confused
<ogra> well, it creates the part table
<ogra> which looks fine in the output
<ogra> imho its just ignorable
<lool> Yes, but it wont help your failure
<lool> I'd rather keep the stderr/stdout output
<ogra> and add || true ?
<lool> You can pass -L to sfdisk to avoid some warnings
<lool> ogra: I don't think sfdisk fails
<ogra> but sfdisk is the only thing that changed
<lool> Hmm I wonder if this is because it's a sparse file
<ogra> yes
<ogra> the error it spills about the missing partition table is normal
<ogra> i really think its set -e thats stops it because there is output on stderr
<lool> sfdisk doesn't fail for me here
<lool> I tried running the commands locally
<lool> I did get BLKRRPART: Ioctl() inapproprÃ© pour un pÃ©riphÃ©rique
<lool> with -L I avoid the warning: Warning: partition 1 does not end at a cylinder boundary
<lool> ogra: set -e doesn't care about stderr
<ogra> are you sure ? i know it doesnt in bash, how about dash ?
<lool> VATSIZE gets set to 73696+
<lool> that's bogus
<lool> problem is that all commands are silenced, so you don't see the actual errors
<lool> the problem is with the mkdosfs call failing
<lool> It fails because VATSIZE is set to 73696+ instead of 73696 or so
<ogra> hmm, yeah
<lool> So the issues are a) fdisk output is in cylinders, that is not suited for partitions not aligned to cylinders as is the case here
<lool> You can use fdisk -u to use sectors instead (but of course you need to multiply the size)
<lool> b) all commands are run with stderr closed, which makes it hard to see failures or to debug
<lool> c) mixture of sfdisk, parted, and fdisk
<ogra> i wouldnt call c an issue :)
<lool> This is definitely shooting yourself in the foot IMO
<ogra> well, then everything would have to be sfdisk, the other two dont provide the needed felxibility
<lool> ogra: Yes I'm sure about stderr and set -e  :-)  this is POSIX; search for errexit in the dash man page to get a description of how set -e works
<janimo> lool, I put C instead of 0xC as that was in manpage examples too (it said those numbers are hex) but I agree it is cosmetic and I am fine either way
<ogra> beyond that we dont know if the code works at all yet, it needs to be generic enough to not break the ROM code if you dd the image to a totally random SD
<lool> janimo: I find it confusing if the part id is "12", so I prefer always prefixing hex with 0x
<lool> So I've worked recently on the OMAP boot layout
<lool> I can say that you're not checking for a possible error condition
<lool> I don't have OMAP4, so I don't know whether OMAP4 ROMS are affected
<lool> But OMAP3 ROMs are
<lool> if the boot partition (first fat partition with bootable flag set => your first partition) has an odd number of sectors, the ROM can't read MLO from it and fails
<lool> this is unrelated to placement
<lool> Just size
<lool> Basically size needs to be a multiple of 1KiB on OMAP3 for MLO to be picked up
<ogra> i think the rom code looks at CHS though
<lool> No
<lool> It does not
<ogra> hmm, i thought TI told me so
<ogra> at least for omap3
<lool> which is the other think I was going to suggest: if you don't care about support for older x-loader, then I wouldn't worry about 255/63; you could use 128/32 for instance, and that would avoid the warnings
<lool> ogra: The only piece of code which I've found to care about the CHS was x-loader, and this was in old version of x-loader; in fact, it didn't really care about CHS
<lool> It hardcoded the vfat partition to be at +63s (start at sector 63)
<ogra> right
<ogra> i thought the rom code had the same to find x-loader
<lool> I don't think you have any x-loader in OMAP4, and you don't care since you're providing x-loader anyway
<lool> I can say that the x-loader in maverick for instance was still broken
<ogra> we indeed do have x-loader in omap4
<lool> so for Linaro, I keep support for creating the boot partition at +63s just for maverick images
<lool> So I'm pretty sure your images wont boot on OMAP3
<ogra> and we do care about older ones since we provide upgrade capability nowadays
<lool> I can't say for OMAP4, would love to know
<ogra> or rather we do care about older partitioning with newer code
<ogra> we dont care about old code with new partitioning
<lool> aligning at 4 MiB means that the start sector is even, while the boot partition's start sector is odd (63) so it's guaranteed that your boot partition, if it goes up to the rootfs, will be an odd number of sectors
<lool> ogra: What I'm saying is that it doesn't matter because you provide MLO in your images
<lool> It's only relevant if you're providing a broken old NLO
<lool> MLO
<lool> but I would hope you have a new x-loader at this point
<ogra> which is the case for pre-XM beagles
<ogra> since they ship MLO in nand which is relevant for first boot
<ogra> not so much afterwards anymore though
<lool> ogra: But do they read MLO from SD or from NAND when SD is available?
<lool> janimo: Didn't hear much from you, did the above make any sense?
<ogra> they read MLO from nand, then read u-boot from nand and then try to read boot.scr from sd
<lool> Then the question is which MLO version they have in NAND
<lool> Well actually it doesn't matter
<lool> since they read u-boot from NAND too
<lool> and u-boot isn't affected
<ogra> well, someone should merge it with the fixes and do a testbuild
<ogra> i'm still concerned about having enough testing with random SD cards though
<lool> I don't see how it relates
<ogra> the existing code is proven to work with any SD card today, i dont want to lose that capability
<ogra> because our image isnt aligned at all to the hardware
<ogra> i dont trust the TI rom code until i have enough test data
<lool> I don't understand what you mean
<lool> like SanDisk versus Patriot etc.?
<janimo> lool, yes the above makes sense
<ogra> the image isnt aligned to any actual CHS value of the HW
<janimo> I'll try to make some more tests locally
<ogra> that only happens during jasper repartitioning
<lool> ogra: Uh the hardware doesn't have any CHS
<janimo> I did not look into changing fdisk parted to keep the diff small but apparently that is not enough
<lool> ogra: CHS is a concept related to the format of the partition table, it dates from the 70s or so
<ogra> i know
<lool> but the SD card only sees reads and writes at various offsets
<ogra> i'm talking about the rom code
<ogra> i know you said above that it shouldnt care about CHS
<ogra> but io really only trust that after i have seen testing data
<janimo> the info above is more than I could find on various omap wikis
<janimo> I was also under the impression it needs VFAT starting at 63 and that is 'somehow' cares about old style CHS
<lool> janimo: I gathered it in my brain with a lot of pain over the last year  :-)  it's also in the linaro-image-tools' comments
<lool> I wish we had some boot design documents for boards/SoCs
<janimo> lool, actually the comments in the script still state that :)
<ogra> the rom code is a super fragile pile of possible errors, that scares me, today we have a working concept which i dont want to risk
<lool> janimo: You might be looking at the packaged version
<lool> janimo: the one in bzr is very different
<ogra> thats why i want to see test data before saying we make the new code our default
<janimo> lool the public bzr branch
<janimo> OMAP3 requires very specific CHS partitioning that can't easy be done with parted
<janimo> so we'll use sfdisk to properly make the necessary partition layout
<lool> janimo: yup, the main lp:linaro-image-tools one
<janimo> by specific I assumed it meant the 255/63/10
<lool> janimo: I don't think OMAP3 requires any CHS partitioning
<lool> It's just these two limitations I mentioned
<janimo> lool, not the image crate tool, the debian-cd scrip6t I modified has this comment
<ogra> lool, linaro-image-tools operates on hardware (existing SD cards), no ?
<lool> the documentation which states that you have to use 255/63 is just to allow creating the boot partition at +63s
<lool> janimo: Oh ok
<lool> janimo: Yeah, that's likely; it's what all the wikis say, but it's just completely wrong historical assumptions  :-)
<lool> ogra: I don't understand the Q.
<janimo> " the first primary partition must contain a FAT32 partition formatted with 255 heads and 63 sectors"
<lool> ogra: you can write image files or straight to SD
<janimo> omapzoom wiki
<janimo> maybe not the most authoritative sources I admit
<lool> janimo: Yeah, that's bullshit  :-)
<janimo> but the only ones I could find
<ogra> lool, files that work on every SD card i dd them to ?
<lool> It's very hard to get the straight dope on how the SoCs boot like
<janimo> ok
<lool> ogra: Sure, well it wont boot an imx51 with an OMAP image
<lool> :-)
<ogra> lool, right, but it creates a partitioned img file i can dd ?
<lool> ogra: Sure
<lool> ogra: It can do that with --image-file
<ogra> ah, i thought it needs an SD as target media
<lool> or --image_file rather
<lool> ogra: nope, you can create images and dd them later, or boot them in QEMU; give it a try!
<ogra> i will once i have some spare time :)
<ogra> i'm still fighting with the debian-cd changes for headless atm
<ogra> janimo, we really need to get you access to antimony (cdimage) for future projects
<janimo> ogra, ok
<ogra> the private vs public stuff means that i have to add a good bunch of stuff
<janimo> or I should just pick task which are not related to image building :)
<ogra> and etc/config seems to actually be totally different
<ogra> janimo, haha, yeah, indeed
<lool> janimo: that's a sane choice  :-)
 * ogra must admit that he actually never looks at the public branch
<ogra> i have merged all your code now ... now on to the headdache bits ... make-web-indicies is a pain
<ogra> hmm, i wasnt aware we have a preinstalled-mobile image
<ogra> i dont think anyone has ever built that, why is there code
<lool> Where's the other debian-cd branch?
<ogra> AH
<ogra> The Mobile Image allows you to unpack a preinstalled preview of the
<ogra> Plasma Mobile workspace onto an SD card.
<ogra> kde stuff :)
<ogra> lool, its all on antimony
<lool> I mean what other changes are being proposed?
<janimo> ogra, indeed I saw a lot of confusing dead-looking code in the build scripts
<ogra> lool, one sec
<ogra_> janimo, livecd-rootfs changed, applied to trunk, packaged and uploaded
<ogra_> i'll do a new test after it was published
<janimo> ogra_, thanks
<ogra_> i always forget if BuildLiveCD changes need lamont or if trhats automatically ... but we'll see
 * ogra_ sighs about the slow publisher
<apachelogger> rsalveti: seems your qt gles change is incomplete
<apachelogger> p   libqt4-dev        Depends  libglu1-xorg-dev | libglu1-mesa-dev | libglu-dev
<rsalveti> apachelogger: well, I believe it was properly changed for a previous revision
<rsalveti> didn't check the current one
<rsalveti> let me see
<apachelogger> the ubuntu11 upload only features changes to opengl-dev
 * apachelogger wonders why -dev should have any relationship with gl stuff actually
<rsalveti> apachelogger: the original patch had libglu1-mesa-dev [!armel] | libglu-dev [!armel],
<apachelogger> rsalveti: http://launchpadlibrarian.net/65213847/qt4-x11_4:4.7.1-0ubuntu10_4:4.7.1-0ubuntu11.diff.gz
<apachelogger> only for qt4-opengl-dev
<rsalveti> apachelogger: -dev and build-depends
<apachelogger> then the upload is flawed
<apachelogger> :S
<rsalveti> apachelogger: why?
<rsalveti> -dev is just to avoid installing the wrong headers and such
<apachelogger> rsalveti: the first hunk of the ubuntu11 diff is build-deps the second hunk is -opengl-dev
<rsalveti> and build-depends enough to build with the proper support
<apachelogger> -dev however remained unchanged
<apachelogger> or
<apachelogger> maybe
 * apachelogger might have been in a wrong chroot
<rsalveti> qt4-x11_4.7.1-0ubuntu12 seems fine here
<apachelogger> let me check again
<apachelogger> oh
<apachelogger> rsalveti: ok, my bad
 * apachelogger now faces the question why kdelibs then installed glu as build-dep :S
<rsalveti> kde needs further changes, not sure kdelibs
<apachelogger> rsalveti: possibly not that many changes
<apachelogger> libplasma links against libgl (due to a silly glapplet class, which is actually unmaintained...)
<apachelogger> I think this causes runtime problems
<rsalveti> apachelogger: I believe this was removed at trunk already
<rsalveti> at least linaro was working on it
<apachelogger> rsalveti: the glapplet?
<rsalveti> apachelogger: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/46b3025245ee6b22cfa8d2a898756f5c075d822e
<apachelogger> groovy
<apachelogger> patchy patchy patchy :D
<rsalveti> :D
<ogra_> grmbl ... now the source is published but the binary isnt
 * ogra_ hates the publisher
<apachelogger> rsalveti: uploaded kde4libs with that patch
<rsalveti> apachelogger: cool
 * rsalveti lunch
<sabayonuser2> hi has any one tried kubuntu mobile  with motorola charm
<dcordes_> sabayonuser2: what's the CPU architecture ?
<sabayonuser2> its an android phone so I guess it should be ARM
<alf> rsalveti: https://bugs.launchpad.net/ubuntu-omap4-extras-graphics/+bug/732053
<ubot2> Launchpad bug 732053 in ubuntu-omap4-extras-graphics "GLES2 drivers don't advertise the GL_OES_texture_npot extension" [Undecided,New]
<rsalveti> alf: cool, will take a look
<GrueMaster> sabayonuser2: Try the #kubuntu-mobile channel.  That's where they focus on that image.
<dcordes_> sabayonuser2: the question is which arm version (what instruction set is supported)
<Neko_> hey guys
<dcordes_> sabayonuser2: you will first have to sort out what processor you have no matter what kind of image
<amelim> rsalveti: In regards to the x-loader for the overo, I compiled the one found here and uploaded it as the MLO on the SD card git://www.sakoman.com/git/x-loader.git
<amelim> same with the u-boot
<rsalveti> amelim: you could just grab the package x-loader-omap3-overo
<ogra> rsalveti, good question why we dont speak here :)
<rsalveti> :-)
<ogra> http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/20110309.1 should actually get an image now
<rsalveti> awesome
<rsalveti> will need a blog post after this
<rsalveti> maybe today
<rsalveti> something the arm community is waiting for months
<ogra> as soon as we know it builds and boots :)
<rsalveti> sure sure :-)
<ogra> years :)
<rsalveti> yeah
<alf> rsalveti: ogra: I am considering using a natty image (replacing maverick) with the SDP (omap4). Would you recommend it?
<ogra> alf, works, kind of
<rsalveti> alf: keep same kernel
<rsalveti> no proper x-loader support for sdp yet, so you should also use the one you're using now
<rsalveti> but, give it a try
<rsalveti> alf: you can also wait the headless image
<ogra> whats the SDP ?
<ogra> blaze ?
<rsalveti> ogra: like blaze
<rsalveti> but without that beautiful case
<ogra> "like" ?
<rsalveti> it's huge
<ogra> ah
<rsalveti> like old omap boards
<rsalveti> alf: headless should be a very small image
<rsalveti> alf: then you can install what ever you need
 * alf shudders
<rsalveti> don't know what you currently need :-)
<alf> I 'd rather get it up front than wait for it to install :)
<alf> rsalveti: ogra: I 'll try it (tomorrow) and let you know how it goes
<alf> thanks
<rsalveti> cool
<GrueMaster> alf: I have the natty alpha 3 image running on my blaze, using the x-loader & u-boot.bin from http://people.canonical.com/~rsalveti/maverick/blaze/
<ogra> take the alpha
<alf> GrueMaster: ogra: nice, thanks
<ogra> grmpf, still something missing it seems
<GrueMaster> I don't think the publisher knows how to handle .raw files.
<ogra> there are no raw files this time
<ogra> and the publisher never gets to see a raw file
<ScottK> janimo: Why did you still build Qt with gc4.4 on armel?  I thought the gcc4.5 fix was in?
 * ogra fires off a full build, somehow i lost my rootfs
 * ogra hopes http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/...9.2 will work now
<janimo> ScottK, the Qt build started before the gcc build had finished
<ScottK> janimo: Ah.  Makes sense.  Are you going to upload it again once the build is done?
<janimo> but more importantly to have a 4.7.2 built with a known working gcc, in case something is weird we know whether to look for the issue in Qt or gcc
<janimo> ScottK, if no other Kubuntu patches are queued we will do an upload
<janimo> although I'd rather let people with more Qt packaging experience do the next upload. There is a 7Mb patch now in debian/ whih I think was not meant to be there
<janimo> was noticed by cnd yesterday
<janimo> ScottK, so hopefully we'll see whether the neon/smp issues are cleared with the new 2.4.7 build and then next upload should switch back to 4.5
<ScottK> OK.
<ScottK> Riddell is the best one to do it, but he's at a conference this week.
<ScottK> Qt build system is funky, so the patch doesn't suprise me.
<janimo> ScottK, I meant to drop the thumb build fix patch as the membarrier one is a superset of that but gave up because of a few faild patch attempts.
<janimo> so they now stack
<ScottK> That works.  That's one of the primary use cases for quilt (stacked patches)
 * ogra always thought quilt was something to hide your bits 
<ogra> janimo, GrueMaster, rsalveti http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/20110309.2/
<ogra> happy playing :)
<rsalveti> ogra: awesome
<janimo> ogra, wonder why omap3 is 8Mb larger? Any idea?
<janimo> ogra, indeed, you may as well have had this spec assigned to you
<janimo> no way I could have made that patch work without tweals without access to the servers
<janimo> :)
<ogra> janimo, i would have postponed it without your preparation
<janimo> ogra, ah, good then
<ogra> the changes i had to do were a lot last thanks to that
<ogra> s/last/less/
<ogra> GrueMaster, happy with the name ?
<GrueMaster> Works for me.
<ogra> lets just hope we never get a chicken arch ;)
<GrueMaster> aww.
<rsalveti> :-)
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  wanna cross build ? http://42.pl/u/2u8U | Natty alpha 3 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/alpha-3/
 * ogra fixes A2 mentioning ...
<ogra> hmm, now to find a time when to build them from crontab
<janimo> right after/before the netbook images?
<ogra> no, right after we have kubuntu
<ogra> right before kubuntu-mobile
<ogra> ah, no, thats live
<ogra> preinstalled is after kubuntu actually
<ogra> 7me puts it on 23:45 UTC
<GrueMaster> Too bad we can't use them as a base for ubuntu/kubuntu preinstalled images.  Seems to me we are duplicating some effort as all of these images share the same base.
<ogra> how would you solve that ?
<ogra> the headless image is a good testbase for debconf based oem-config
<ogra> gah
<ogra> 23:45 might not be a good idea
<ogra> the images will always be a day behind
<GrueMaster> Well, ubuntu-preinstalled-headless boots past jasper.  But that's it.  No oem-config, no serial terminal.  Just a console login with a hostname of sycamore (yea, that's another bug).
<GrueMaster> But it is a step in the right direction.
<ogra> did you check all consoles ?
<ogra> oem-config might come up at an unexpected one
<ogra> i'm not sure the server team tests oem-config server installs
<GrueMaster> yep.  login in f1-f6, nothing beyond that.
<ogra> bad
<GrueMaster> And serial looks the same as it does on standard images.
<ogra> yes
<ogra> i mentioned that before
<ogra> we dont have code that switches the cmdline between images yet
<ogra> it uses the same code netbook uses atm
<ogra> no oem-Ã¤config is indeed bad
<ogra> i see it in the manifest
<ogra> so i wonder why it doesnt start
<ogra> can you check if /var/lib/oem-config/run exists so we can exclude jasper from being bad
<GrueMaster> Yea, it's there.
<GrueMaster> I'll add a test user so I can at least log in.
<ogra> or a root pw :)
<ogra> might be that the cmdline version of ubiquity-dm is just broken
<amelim> rsalveti, GrueMaster: I'm able to boot on the Overo using Alpha 3, an overo u-boot I compiled earlier, and x-loader-omap3-overo
<amelim> Thanks for the assist
<GrueMaster> amelim: Cool!
<GrueMaster> Grr.  Need to get video to not suck.  Mainly blame my HDMI switch for autoswitching to a different system on reboot.
<GrueMaster> Ok, logging in as root (after mucking with the passwd) I can launch oem-config with "start oem-config", so it must be something in upstart or init.
<GrueMaster> Also, didn't ask for system name.  Odd.
<GrueMaster> Oh, nevermind.  Did the network time update first.
<amelim> :/ Now I have to figure out why my USB peripherals aren't working...
<amelim> They function fine on the same hardware setup during a boot of the preflashed angstrom image
<rsalveti> amelim: cool
#ubuntu-arm 2011-03-10
<Neko> is ubiquity-3d going to be happy with GLES2 (i.e. is someone actively finishing Compiz for GLES2?) for Natty release?
<Neko> is there any way I can know if a bug got reported for the fact that Natty alpha3 doesn't install a working backend (gconf for example) by default, so Compiz doesn't run?
<Neko> (once you install compizbackend-gconf and reboot it works fine but fails GL and gives you a "working session" anyway)
<rsalveti> Neko: linaro is doind the for to port compiz to gles
<rsalveti> don't know yet if it'll be ready for natty
<rsalveti> but we'll release at least at a ppa
<Neko> so on ARM, default desktop will be unity-2d?
<Neko> or unity-3d with the compiz falling back to software?
<rsalveti> Neko: for now default will be unity-2d
<rsalveti> ideally unity-3d would be the default when you have your drivers installed
<rsalveti> and unity-2d the fallback
<rsalveti> only at arm
<rsalveti> at desktop the classic desktop will be the fallback
<Neko> unity-3d does fall back properly though
<ScottK> unity-2d does 3d just fine if the drivers support it.
<ScottK> (I'd assume so anyway since it's Qt)
<Neko> it just doesn't *today* because of some compiz misversioning halfway-uploaded builder mania :)
<Neko> ah well. I guess we had the weekend to get a stable snapshot of the mirror and missed the opportunity :3
<rsalveti> ScottK: well, unity-2d with 3d support, from Qt is a little bit different, but yes, 3d still
<rsalveti> the normal unity would be with compiz
<rsalveti> and nux, but still need more work to support gles
<rsalveti> GrueMaster: cool, webkit bug is finally tested
<rsalveti> just running ubiquity again with the slideshow
<rsalveti> working fine
<rsalveti> will update the bug with the debdiff
<rsalveti> more than 15 hours per build
<GrueMaster> Sweet
<rsalveti> and at least 2gb of ram to be able to link it
<rsalveti> scary
<GrueMaster> Now to fix openoffice.
<rsalveti> one step at a time
<rsalveti> :-)
<StevenK> GrueMaster: I suggest more fire.
<rsalveti> lol
<GrueMaster> That takes something like 2 days on x86.
<rsalveti> ouch
<StevenK> GrueMaster: Uh? libreoffice on i386 finished in 5 hours.
<GrueMaster> Well, it did back in 2006 when I was at Intel.  That was on 8x PIII Xeon 900mhz with something like 8G ram (32 bit PAE).
<GrueMaster> Systems are a little faster these days.
<StevenK> The armel build started ... yesterday
<GrueMaster> Back then, we created a 4G ram disk to do the build.  Watching it with -j 10 was cool (for about 30 seconds).
<prpplague> ogra / rsalveti  ping
<rsalveti> prpplague: pong
<prpplague> rsalveti: hey, i'm totally brain dead this evening but......
<prpplague> rsalveti: i need to compile a custom kernel for the panda ubuntu images
<rsalveti> prpplague: ok
<prpplague> rsalveti: what git tree do i need to use, and are there any gotchas to doing a based install on the sd card, and then replacing the kernel with my custom one?
<rsalveti> prpplague: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=summary
<rsalveti> for natty
<prpplague> rsalveti: is that 10.10 ?
<rsalveti> prpplague: ti-omap4-dev gets you to the 38 kernel
<rsalveti> 11.04
<rsalveti> do you need for 10.10?
<prpplague> 10.10 is what we have on omapedia, but if 11.04 is current that is fine
<prpplague> rsalveti: any gotchas on doing a basic install on sd , then replacing the kernel with a custom built one?
<prpplague> i need to add support for a lvds display via the DPI interface
<rsalveti> prpplague: just need to install the kernel package, that will generate the initrd
<rsalveti> then you need to generate and copy the uInitrd and uImage files to the first partition
<rsalveti> or if you're running the board, just call flash-kernel
<rsalveti> if it's not called automatically already
<prpplague> rsalveti: is the procedure documented somewhere?
<rsalveti> prpplague: you mean, to build the kernel package?
<prpplague> rsalveti: correct
<rsalveti> cooloney: do you know the correct wiki page that describe how to build the kernel?
<rsalveti> the kernel wiki list is quite huge
<rsalveti> prpplague: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance may help
<prpplague> rsalveti: thanks!!!
 * prpplague looks
<rsalveti> I generally cross build it with debuild -eCROSS_COMPILE=arm-linux-gnueabi- -b -aarmel
<rsalveti> but at this wiki you can find all the details on how to maintain your own ubuntu kernel package
<prpplague> rsalveti: hmm, looks like i need to do some reading tomorrow to come up to speed
<rsalveti> prpplague: yup
<prpplague> rsalveti: well i'll bookmark and have look in the morning
<prpplague> i'm totally brain dead
<prpplague> got the hardware for my netpandabook working today
<prpplague> rsalveti: just need to get the kernel updated for the ubuntu build
<rsalveti> NCommander: https://bugs.launchpad.net/ubuntu/+source/webkit/+bug/728211
<ubot2> Launchpad bug 728211 in webkit "webkit crashes with SIGSEGV on ARM" [Undecided,In progress]
<rsalveti> one merge proposal for the webkit fix
<cooloney> rsalveti: sorry, just back from lunch.
<cooloney> rsalveti: yeah, your URL is right.
<rsalveti> cool
 * rsalveti gone, back in 7 hours
<cooloney> rsalveti: good night
<rsalveti> thks!
<janimo> ogra, managed to upgrade your ac100 to natty?
<janimo> anyone else with a tegra or other non-NEON capable hardware could test latest Qt in natty to see if it works - it is supposed to be built without NEON except for a few files which should only be used on NEON-capable hw
<alf> vstehle: rsalveti: Hi! Is there a reason for pvr-omap4 to depend on libgles and libegl? It breaks my workflow (installing libgles, libegl separately under /usr/local and using LD_LIBRARY_PATH to run with them) :(
<vstehle> alf: yes, the "test" binaries, which are in pvr-omap4 package today
<vstehle> What does this break exactly?
<alf> vstehle: 1. The ability to have both mesa and pvr installed and select at will (eg LD_LIBRARY_PATH) and 2. the pvr packages don't provide -dev versions so I can't build anything with them (I have to have mesa -dev packages installed which I can't because they conflict with the pvr ones)
<alf> vstehle: previously I had installed pvr-omap4 normally and manually extracted libgles/egl -sgx under /usr/local/lib/sgx, so I could just select what to use with LD_LIBRARY_PATH
<alf> vstehle: (and still be able to compile using the mesa -dev packages)
<vstehle> alf: I am not sure we can have 1. For 2, we now have a -dev package on-going "internally". rsalveti is on it :)
<alf> vstehle: That's good news I guess. Still I don't think pvr-omap4 depending on libgles is the best approach. Eg you could have eg a pvr-omap4-tests that contains the tests and is suggested by pvr-omap4
<vstehle> alf: agreed. I'll track that.
<alf> vstehle: Thanks :) Another argument for this is that although there are separate packages for gles, gles2, vg there is no way to install only a subset of them (because they depend on pvr-omap4 that in turn depends on all of them).
<ogra> janimo, probably GrueMaster can test if i.e. mumble starts on hhis dove, i havent attempted a new upgrade yet on the ac100
<ogra> janimo, i see that the tsaksel WI was closed, did it just work ?
<ogra> *tasksel
<janimo> ogra, GrueMaster closed that, I have not worked on that yet
<janimo> so I don;t think it should be DONE unless things just fell into place by default :)
<ogra> well, i'll do a test install later today lets see, probably it just runs if the debconf frontend is selected
<janimo> alf, is GLES 2.0 preferred over GLES 1.1 or they should be picked on an app by app basis and should coexist?
<janimo> since the API's are so differnet 2.0 does not look like a regular 'improvement'
<alf> janimo: gles1 and gles2 are not compatible
<janimo> alf, yes I know. But is one preferred over the other when writing new apps
<janimo> when peiple tlak about let's port to GLES
<alf> janimo: yes, gles2
<janimo> do they mean both?
<janimo> ok
<janimo> great, thanks
<alf> janimo: in the sense that programmable gfx pipeline is the future (and there is good support for it even now)
<alf> yw
<ranisuneela> ./join #gstreamer
<rsalveti> alf: yeah, makes sense
<rsalveti> will change it together with the new -dev package
<rsalveti> should hit the ppa later today
<alf> rsalveti: cool, thanks
<alf> rsalveti: btw, I am getting a Do you want to continue [Y/n]? y
<alf> rsalveti: E: Could not perform immediate configuration on 'libgles2-sgx-omap4'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
<alf> rsalveti: on alpha3 image, any ideas?
<alf> rsalveti: (using omap-trunk)
<rsalveti> alf: not yet, will try to reproduce
<rsalveti> I have a fresh a3 that just booted
<rsalveti> alf: this is at the first moment you install the packages?
<rsalveti> or after already installing the mesa ones
<rsalveti> including the -dev package
<alf> after having installed the mesa ones, I do an apt-get install pvr-omap4
<rsalveti> alf: did you installed the -dev packges first?
<alf> rsalveti: yes mesa -dev packages are installed
<rsalveti> that could be the issue
<rsalveti> will try to reproduce
<alf> rsalveti: FWIW, http://pastebin.ubuntu.com/578346/
<rsalveti> janimo: would you mind applying merge request from bug 728211?
<ubot2> Launchpad bug 728211 in webkit "webkit crashes with SIGSEGV on ARM" [Undecided,In progress] https://launchpad.net/bugs/728211
<janimo> rsalveti, will do
<rsalveti> janimo: thanks!
<janimo> rsalveti, upload too I presume?
<rsalveti> janimo: yes :-)
<janimo> oki :)
<rsalveti> alf: what happens if you remove the -dev packages first?
<alf> alf: trying that now...
<alf> rsalveti: trying that now...
<alf> rsalveti: no improvement :/
<rsalveti> weird
<rlameiro> anyone in here as experience in doing nfs boot using diferent sub-subnets
<rlameiro> connecting from 192.168.1.xxx to 192.168.10.xxx
<janimo> rsalveti, I think it is better to keep UNRELEASED instead of natty in branches in the future. Otherwise it creates  a branch for revision name. I am not too good with bzr/debcommit so scracthed my head a bit why it says tag already exists
<rlameiro> being that the latter is a router connected to the other one
<rsalveti> janimo: hm, ok
<rsalveti> not a problem
<ogra> janimo, ++ (on the UNRELEASED part)
<ogra> janimo, tasksel runs fine by default, the only two probs i have seen are oem-config not starting at all and colormap distortion during package removal
<janimo> rsalveti, uploaded, fingers crossed. I am really lousy at UDD style sposonring, took me more than 20 min
 * janimo awaits the merge triggers pkg upload LP feature
<janimo> I dislike the need to manually keep in sync the branches and packages
<janimo> ogra, yes I saw the two bugreports. Any idea where I should start looking? Is this in the ubuntu-cdimage or debian-cd project?
<janimo> I guess where the FS is created
<ogra> not sure, there is an event entry for "start on oem-config-debconf" but that doesnt seem to exist anywhere
<rsalveti> janimo: thanks
<ogra> i think its an ubiquity prob with the upstart job, notthing to do with the image creation
<janimo> rsalveti, yw
<rsalveti> once the new webkit package hits the archive we can start using it again at ubiquity
<janimo> rsalveti, great. So one week :)
<rsalveti> :-)
<janimo> LibO is 1 day 16 hours, Qt is 1 day 14 hours
<rsalveti> alf: just installed it here and it went fine
<rsalveti> alf: after install all mesa packages I installed the sgx ones from the tiomap-dev trunk ppa
<rsalveti> and it went find, could be another bug
<rsalveti> will now try to install back the mesa ones to see if it works fine
<rsalveti> janimo: ouch
<rsalveti> webkit will take more than 1 day for sure
<alf> rsalveti: :/, this means that something is messed up with my setup, wish me good luck ;)
<rsalveti> we'll see after removing the test applications from pvr-omap and having a proper -dev package
<janimo> rsalveti, last build was 1 day 1h on armel, so not quite as heavy as Qt or LibO
<rsalveti> sill more than 1 day :-)
<GrueMaster> janimo: I tested the headless install yesterday.  Had to launch oem-config manually after manipulating the image to get a login.  oem-config launched tasksel just fine, so I marked that WI as done.
<janimo> GrueMaster, ok thanks
<janimo> GrueMaster, any non-NEON hw around you to see if latest Qt works?
<GrueMaster> Yea, but it will need to wait for the caffeine to melt the crud keeping my eyes from focusing.
<janimo> GrueMaster, 7 AM at you? Sorry
<GrueMaster> Almost.
<GrueMaster> Few minutes left.
<GrueMaster> But I have coffee.  :D
 * NCommander coughs
 * rsalveti out for lunch
 * ogra takes a break and will then test the oem-config fix
<rsalveti> wow, i386 webkit build takes 53 minutes
<rsalveti> and the arm one more than 1 day
<NCommander> rsalveti: almost as bad as OOo
<janimo> Order of decreasing time-to-build: OO, Qt, gcc, webkit
<janimo> s/OO/LibO/
<NCommander> firefox/thunderbird
<NCommander> should be on that list
<janimo> probably
<janimo> neh, unde 12 hours
<janimo> https://launchpad.net/ubuntu/+source/firefox/4.0~rc1+build1+nobinonly-0ubuntu1/+buildjob/2312427
<janimo> the ones above are over one day
<janimo> just noticed chromium FTBFS two days ago without buldlog
<janimo> like LibO and Qt back then
<janimo> given back
<ogra> geeez, the headless image is so fast
<rsalveti> ogra: :-)
<armin76> how can you say that being an ubuntu dev :P
<ogra> ??
<armin76> thats like saying windows has more market share than ubuntu :D
 * ogra doesnt get it ... do you mean ubuntu has to be slow or ubuntu has to have a head ?
<armin76> the latter
<armin76> i mean, it doesn't need to have a head, but its the common thing when you think about ubuntu
<ogra> heh, being the number one linux distro in cloud deployments doesnt count ?
<ogra> ubuntu server comes headless by default ;)
<armin76> well, you don't redirect kernel output to serial in the omap4 images :P
<ogra> yes, it doesnt make sense on the netbook images and breaks plymouth
<ogra> the headless one will have serial
<ogra> rsalveti, janimo, GrueMaster, any suggestion how to set the default console on headless ? if i set to serial only the installer will default to serial too, if i set serial and tty1 the installer will default to DVI
<GrueMaster> Well, headless would imply serial console only.
<ogra> do we want to enforce the installer to run on serial
<ogra> headles just implies no graphical interface
<GrueMaster> No, headless implies no kvm.
<rsalveti> I don't think it implies serial console only
<janimo> ogra, can also imply console text mode interface
<ogra> janimo, yes
<GrueMaster> I've been doing headless systems for 15 years.
<ogra> thats what i mean
<GrueMaster> Headless in the industry indicates no local console.
<janimo> I mean monitor but no GUI just framebuffer
<GrueMaster> No gui is different.
<ogra> yes
<ogra> well, the question is what do we want to default to
<rsalveti> I believe uart would be better for us
<GrueMaster> http://en.wikipedia.org/wiki/Headless_system
<janimo> but for the scope of this spec I understood people who don't hook up a monitor just ssh into the hw
<rsalveti> most tutorials and such uses uart when dealing with panda and beagle
<janimo> what does linaro do for their nano/dev images?
<GrueMaster> As do most headless installs.
<GrueMaster> for other arches.
<GrueMaster> What does server do for x86?
<ogra> console
<ogra> they dont even set serial by default
<GrueMaster> For headless installs?
<ogra> for server installs
<ogra> the default iso uses console mode
<ogra> you have to change the default to get serial
<janimo> Does modern server hw still have UART?
<janimo> x86
<ogra> yes
<GrueMaster> janimo: most current x86 server platforms also have a special serial over ip system at the hardware level.
 * GrueMaster worked on this at Intel in 2006.
<armin76> which you have to configure :P
<armin76> at least on hp machines
 * ogra wonders what plymouth will do on serial only systems
 * GrueMaster is surprised that we don't have a method for installing on a headless server.
<ogra> we do
<ogra> d-i has one
<ogra> but you have to tell it to use serial console
<ogra> through kernel cmdline and preseeding
<GrueMaster> ogra: As to headless console and output either via dvi or serial, you could check from jasper if a keyboard is present.  dmesg | grep "USB HID" will either show a kb or be blank if none present.
<GrueMaster> I've tested this twice now on the headless image with break=init at boot before jasper-setup runs.  With usb keyboard it returns a value (... USB HID v1.10 Keyboard...)
<GrueMaster> Returns blank if nothing found.
<ogra> GrueMaster, hmm, i didnt actually plan to put it into jasper since we will need to add additional info to the image then
<ogra> i.e. jasper would need to know its on a headless image
<ogra> we have code for setting the default cmdline in the image builder, i would rather like to use that
<GrueMaster> Ok.  That will create an image that *only* works one way or the other.  My idea could be expanded to auto-detect.
<ogra> well, your auto detection would need to be a bit bigger :)
<GrueMaster> Might be worth exploring in O.
<ogra> not all omap kbds are attached via USB HID
<ogra> yes, definitely
<ogra> (teh blaze kbd isnt usb afaik)
<GrueMaster> Is there another method for attaching a keyboard?
<ogra> plenty
<ogra> i bet persia could hold a talk about it ;)
<prpplague> ogra / rsalveti lvds is working, just need to add in the kernel modules to the initrd
<ogra> the omap3 evm boards (which should boot with our image) only has a keypad for example
<rsalveti> prpplague: cool
<ogra> prpplague, awesome
<GrueMaster> but how is the keyboard mapped?  It would make more sense to have it connected via usb as the driver base is already there.
<rsalveti> not usb
<rsalveti> it's a keymap driver
<ogra> its a great idea but definitiely requires more than a grep in demsg
<prpplague> GrueMaster: i2c, spi, ps2, smbus, usb, and via the omap3/4 keyboard matrix
<GrueMaster> ok
<prpplague> GrueMaster: thats just to name a few
<ogra> i think you can detect them on the input device layer though
<GrueMaster> Still could be a grep in dmesg.  Just need to change the search parameters.  The full line looks like this:
<GrueMaster> [1380061.936154] input: USB KB as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2.1/2-2.1:1.0/input/input5
<GrueMaster> [1380061.936511] generic-usb 0003:05D5:6781.0004: input,hidraw0: USB HID v1.10 Keyboard [USB KB] on usb-0000:00:1d.0-2.1/input0
<ogra> it should better be a udev rule that sets a flag or execs a script
<GrueMaster> As I don't have HW to test, I don't know what to suggest to look for, but maybe hidraw0?
<prpplague> GrueMaster: easiest would be to check the input events, either as part of /dev/input or in sysfs
<ogra> you can match against the input subsystem
<prpplague> GrueMaster: iirc the android framework opens each of the /dev/input/events  and check to see if certain buttons are available
<ogra> thats lame
<ogra> i'm pretty sure there is a way to do it through udev
<rsalveti> well, I guess you can use udev to behave in a similar way
<rsalveti> yup
<ogra> without having to walk all input devices
<rsalveti> just dump all events
<rsalveti> and see what can be used
<ogra> yep
<ogra> i know you can match against SUBSYSTEM=input but i dont know if you get actual info if its a kbd
<prpplague> i don't think that is going to help since you could have something like a usb numberic keypad or even just some gpio buttons
<ogra> and that doesnt use the input subsystem of the kernel ?
<prpplague> yes those use input subsystem, but the input subsystem doesn't really distinguish between input "types", only the keys/functions that are registered to the device
<ogra> right, thats what i feared
<GrueMaster> Better yet, how about we make a simple check based on HW we can test, and let the community add to it?
<prpplague> you could easily take evtest.c and hack it a little to open each of the events, check for the keys QWERTY registered. if it finds one return a known value
<ogra> the prob will be that you dont see jasper output at all if you dont have the right console before jasper already
<GrueMaster> We don't see jasper now, not sure it makes a difference.
<ogra> ??
<GrueMaster> Plymouth.
<ogra> i see all jasper output in the text splash atm
<ogra> the missing text on the graphical theme is a bug that will be fixed before release
<GrueMaster> So, what happens if you add console=ttyO2,115200 console=tty0?  (other than losing plymouth).
<ogra> you will see the boot on serial, oem-config will come up on tty0
<ogra> plymouth will die and jasper will echo to tty0
<rsalveti> so can't you be smart enough to just open oem-config to the "best" place for the user?
<ogra> since thats the default console after the kernel has booted
<rsalveti> like if he's using an usb keyboard
<ogra> rsalveti, same issue, you dont see the rezize process
<ogra> we need a default at image build time
<rsalveti> for now I'd put ttyO2 as default
<ogra> i.e. we need a decision
<rsalveti> good that now it's the same one for omap3 and omap4
<ogra> yep
<ogra> k, hedless defaults to console=ttyO2,115200n8 now
<ogra> *headless
<GrueMaster> Well, currently I see nothing on serial beyond u-boot standard output.  I would suggest using both console output additions, or creating a way for jasper output to be mirrored on serial at the least.
<ogra> we need to cover that in the docs somewhere
<ogra> GrueMaster, if you use both, oem-config will pick tty0
<GrueMaster> Then either jasper or some pre oem-config process can decide were to route.
<GrueMaster> Also need an /etc/init/ttyO2.conf regardless.
<ogra> jasper cares for that
<ogra> at least it should ;) if not thats a bug
<GrueMaster> Must be a new feature.  Not in the latest image.
<ogra> while i really like the ideas coming up here, i suspect its all Oneric material
<ogra> GrueMaster, bug number ?
<ogra> ;:)
 * GrueMaster is currently reproducing 2 other bugs on different systems, checking NCommander's panda to figure out why it is unstable, and chatting on 2 irc channels.  I'll get to it.
<ogra> http://paste.ubuntu.com/578496/
<ogra> thats the code in jasper
<ogra> you should in any case have a serial.conf file if you had a console=ttyS* or O* option set before jasper runs
<GrueMaster> Oh, so it only works if I have console=ttyO2 on the boot cmdline.
<ogra> yes
<ogra> it copies the upstart job in place if it detects that a serial console is used on first boot
<ogra> i simplified the upstart script today, it should work more generically in tomorrows image
<ogra> in case there was a bug in it
<prpplague> ogra_: https://picasaweb.google.com/lh/photo/XBDVyGLKlEfA1qimY9IkpQUEcMIzmiipT-Yyx8698II?feat=directlink
<rsalveti> prpplague: finally an omap 4 netbook :-)
<rsalveti> if you put natty with unity-2d it'll be even better
<TitanMKD> hi
<prpplague> rsalveti: hehe
<prpplague> rsalveti: think there would be demand for it?
<rsalveti> prpplague: I'd like to get one :-)
<prpplague> rsalveti: with a panda inside?
<rsalveti> yup
<prpplague> rsalveti: this wasn't designed for the panda to go inside
<rsalveti> prpplague: what was the original idea?
<prpplague> rsalveti: basically to do netbook development with a stock panda
<GrueMaster> From the photo, it looks like someone has a laptop connected to a panda.  Nothing in the photo indicates that the laptop is just a display & keyboard for the panda.
<rsalveti> but it's nice either way
#ubuntu-arm 2011-03-11
<rooferdave> new to compiling get this error at end (almost the end) :http://pastebin.com/FTfHhJQY ..could u give me a little help how to solve?
<GrueMaster> Not sure what you are trying to do based on that info, but I would guess you are trying to build an android kernel?
<rooferdave> yes i am sir
<alf> persia: Everything alright with the tsunami? Did it affect the are you live in?
<alf> s/are/area/
<ogra_> he said he's ok in another channel
<alf> ogra_: good, thanks
<ppisati> ericm_: did you use an ATX power supply for Casper?
<ogra> sigh, the serial console bits are harder than i though
<ogra> +t
<ogra> and oem-config-debconf seems to start wherever it likes ... randomly on serial or tty1
<Martyn> Has anyone heard from persia?
<Martyn> I tried calling him, but most major infrastructure is down.
<alf> JesseBarker: I have been trying to build some applications using the imx EGL/GLES2 headers and I noticed that, in contrast to the Mesa ones, they don't reference the X11 types
<NCommander> the "joys" of building the mono stack by hand :-/
<Neko> alf, no shit ;)
<Neko> EGL is meant to be agnostic
<alf> Neko: sure, but they latest KHR headers has support for X11 in eglplatform.h
<alf> Neko: (tentative)
<alf> Neko: I just wasn't sure if I can rely on that
<alf> Neko: and by support I mean "typedef Display *EGLNativeDisplayType;" etc
<Neko> it's an opaque pointer either way
<Neko> I'm looking at the possibility of updating the EGL headers.. we just updated to fix missing GLchar and the glTexImage2D prototype among a few other minor changes that happened in the last year or so
<Neko> but EGL uses the public header internally so changing stuff tends to break builds and make behaviors subtley different
<ogra> hrm
<ogra> getting oem-config to run on serial any other tty exists seems impossible
<ogra> *while any
<Neko> alf, bugs noted, the image stuff we knew about since a long time, the implementation inside is broken except for some common fringe cases, but not proper behavior
<Neko> to be honest we've been reluctant to touch it while there was nothing to really test it with :D
<kgilmer> hi hrw
#ubuntu-arm 2011-03-12
<Xase> Hello ARM unit.
<Xase> I'd like to know some information about flashing ubuntu arm onto my nook color if anyone is willing to congregate with me on this topic.
<Xase> Or maybe an inexpensive fully usable ARM system with which I can use Ubuntu ARM build.
<Xase> I swear.... ARM should stand for  Alive... Really Man?
<Xase> ... no one ever lives here -_-
<GrueMaster> I kindof do.
<Neko> alf, ping
#ubuntu-arm 2011-03-13
<Martyn> Hey, has anyone heard from Emmet?
<GrueMaster> Martyn: Not since yesterday morning.  He let us know he's ok, but his apartment is a mess of clutter as stuff fell off shelves.
<Martyn> That's all I care about :)  That's he's okay
<steev> hey all, perhaps I'm going about this the wrong way... I'm trying to find everything that has a build dependency on cairo, but... apt-rdepend doesn't quite seem to be what I'm actually looking for; apt-rdepends -b lists way more than I think should actually need cairo to build; What's the correct way to go about this?
<zumbi_> steev: apt-cache rdepends libcairo2-dev ?
<steev> zumbi_: aha, perfect, thank you sir
<zumbi_> no prob :)
#ubuntu-arm 2012-03-05
<steev_> so, running into an... interesting issue with ubuntu-core, on an efika, i am installing, and really not doing much special, but, i'm doing it in a chroot, so i have the policy-rc.d file, but, upon reboot, once going through oem-config, when you login as the user created, it throws up 2 system errors, and it seems to be man-db and ubuntu-extras-keyring need to be re-installed.  is there a way to do
<steev_>  that before oem-config is run?
<infinity> steev_: I don't see how having a policy-rc.d in place would prevent man-db and ubuntu-extras-keyring from installing correctly.
<infinity> steev_: What are the actual errors?
<steev_> infinity: one sec, i'm about to reboot on a new install again
<steev_> infinity: ugh, for some reason it only happens *after* oem-config is run.  and i'm trying to get all the different packages i want in order, before i set it to run oem-config.  i'll do more research, but i definitely remember it complaining about man-db and ubuntu-extras-keyring, but when i told it to report the issue, it complained about some log being empty.  Next time I will pay more attention
<steev_> (i haven't slept since friday night)
<infinity> Your man-db issue could just be that you need to manually run /etc/cron.daily/man-db (or wait for the cronjob to trigger later), but without seeing the error you're talking about, I don't know.
<infinity> If you mean that either of them is complaining about actually not being installed correctly period, that's a packaging bug, and not something you should be working around in installers.
<infinity> But, yeah.  Seeing the errors would be helpful.  Filing bugs, too.
<steev_> like i said, i hit the button to report issue, it complained about some log file being empty, next time i see it, i'll take a screenshot just to be safe
<steev_> for the moment though, i'm going to say this one is cooked, and prep it so i can mass install ;)
<micahg> janimo`: I'll be uploading chromium in a couple hours, it would be nice to enable armhf properly :)
<janimo`> micahg, well I do not have a proper patch, just handedited the files in question
<micahg> janimo`: can you diff them for me against what's in precise?
<janimo`> micahg, ok. I was not sure if a sed call in rules would be ok or a more elegant way that intriduces new variables in gyp
<micahg> janimo`: we usually just patch the files ;)
<janimo`> micahg, I am not sure if it was chromium (maybe thunderbird) that made me not want to work with it much. IIRC it did not work with edit-patch but some custom quilt paths and runes that were not documented
<micahg> janimo`: yes, you need to be in build-tree/src for chromium
 * micahg would love to switch to straight source format 3 and dh7, but that would require time :)
<janimo`> micahg, that would be awesome. It would be time gained in the long run
<janimo`> micahg, what rule does only the unpacking for chromium?
 * janimo` tries to come up with a cleanish patch
<micahg> janimo`: debian/rules patch I think
<janimo`> Laney, around?
<micahg> oh, did you fix ghc?
<janimo`> micahg, yes
<janimo`> but just like chromium. Fixed the build, have no idea what the 'proper' upstream patch should be
<janimo`> could be a sed in debian/rules if armhf, of some haskell code + config stuff in another unusual build system
<janimo`> s/of/or/
<janimo`> I think it needs a normal patch though, upstream assumes softpf and has no config for armhf at all
<Laney> janimo`: nice work! Can you show me the patch? I'll show the ghcarm people what was needed and they should be able to take it from there
<janimo`> Laney, just filed a bug in ghc trac. A moment
<Laney> oh ok, nice
<janimo`> http://hackage.haskell.org/trac/ghc/ticket/5914
<Laney> are you uploading to ubuntu?
 * janimo` praises his habit of using a simple identical password almost everuwhere, so wehn visiting sites every couple years he does not have to scratch his head.
 * janimo` oopses
<janimo`> Laney, no, it is a hack, I;ll leave the proper patch to people who know how to integrate with the ghc build system and make it conditional
<janimo`> Laney, I could not figure out from a few minutes of using the code whether all options need to be hardcoded in haskell or can be driven exclusively from some human readable file, like settings in the root dir
<janimo`> as this option only needs passinf fo armhf
<Laney> there is mk/build.mk but I am not sure exactly which options it takes
<janimo`> Laney, another approach would be making llvm/llc default to hard float when invoked on a hard-float system, like gcc does .Not sure if that is ok with llvm people whough
<janimo`> Laney, so if you could point this to arm/ghc people they may fix it properly
<Laney> ok, thanks for the work!
<janimo`> Laney, you're welcome
<janimo`> micahg, can you help me with the patching of chromium. Finally untarred a sample package. cd build-tree/src
<micahg> quilt push -a
<janimo`> ok
<micahg> quilt new fix-armhf-gyp.patch
<janimo`> ok
<janimo`> micahg, will attach the patch shortly
<micahg> janimo`: thanks
<janimo`> micahg, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/943281 fingers crossed. With restarted package builds and not knowing how and what exactly the build system regenenerates and which bits of config drive what this is a best effor tpatch :)
<ubot2`> Launchpad bug 943281 in chromium-browser "armhf FTBFS in precise" [High,In progress]
<micahg> janimo`: thanks
<micahg> will look at it in a few minutes
<janimo`> micahg, thanks
<janimo`> at least the gyp bits i am fairly confident should work. The v8 one, may or may not
<janimo`> I hope the TODO item - 'migrate to external v8 lib ' is not too unrealistic :)
<micahg> we won't do that as chromium will move too fast in the stable release
<janimo`> TODO: remove v8 entry from TODO file :)
<micahg> janimo`: heh, anyways, patch looks sane and won't break armel builds, I'll upload shortly
<micahg> janimo`: maybe that's why it works in Debian, they use the system v8
<micahg> janimo`: well, we should find out in ~1hr if it worked or not, I'm about to upload
<sveinse> Hi. I'm having some troubles with a custom natty armel installation (on custom HW). One particular device isn't booting properly, while others are. I'm debugging upstart and it seems it locks up in mountall, i.e. it doesn't emit the correct signals for upstart to continue into runlevel/rc-sysv modes.
<sveinse> Mountall --verbose show that is indeed stops in mountall, but no errors on the console. How can I debug this? Any ideas?
<ogra_> sounds like a kernel issue to me
<micahg> janimo`: armhf seems happy, it's building
<sveinse> ogra_: The device had an old HW clock setting. So from what I can see mountall (not fsck) halt if the HW clock is older than the superblock of the fs. If I set the hwclock to newer, it works. Is this expected or a bug?
<ogra_> well, if you use an ubuntu initramfs you can easily work around this by using the ficrtc cmdline option
<ogra_> it will force the RTC to the past mount time of the disk
<sveinse> a kernel parameter?
<janimo`> micahg, I still suspect it may fail later on when it tries to link v8 against it all. So in case it does not figure out what the eabi should be another bit in debian/rules may be in order
<sveinse> fixrtc I suppose
<ogra_> yeah
<ogra_> (to both)
<janimo`> micahg, amended the bug with a comment in case it fails because of V8 being built without HF
<micahg> janimo`: well, the v8 parts compiled, we'll see if it links later
<janimo`> ok.
<sveinse> ogra_: It works. Thank you very much!
<janimo`> ah qtwebkit-source keeps being ftbfs. But that looks nastier as if it was a kernel/glibc/toolchain issue
<Laney> janimo`: "VFPv3D16" does not imply armhf?
<janimo`> Laney, not necessarily afaik. We had that for armel as well
<janimo`> it means use a certain set of VFP registers
<janimo`> but even in softfp you could use those as long as they do not cross proc call boundaries
<janimo`> so not part of the ABI
<janimo`> so we only want to use registers D0-D15 and not D16-D31 as found on some chips.
<janimo`> so generate code for that VFP config for both armel and amrhf. For armhf use said regs also for passing arguments and return values between calls
<janimo`> Laney, we've been passing -mfpu=vfp3-d16 for a while in Ubuntu for armel
<Laney> okey dokey, just thinking how ghc could tell if armhf or not
<janimo`> Laney, if it has the equivalent of autogen, it may discover it by seeing gnueabihf in the triplet instead of plain gnueabi
<janimo`> if not, it may be good enough to just pass a config option from debian/rules
<janimo`> would be nice to be able to drive some options outside haskell code. I see settings.in but am not sure it has sections for passing options to LLVM, as it has for gcc
<xranby> Laney:   you can use  #ifdef __ARM_PCS_VFP
<xranby> to check for hard-float calling convention
<janimo`> xranby, not in haskell code I assume
<xranby> maybe.. depends on if you pass the haskell code through the gcc preprocessor or not
<janimo`> xranby, there is a preproc step, not sure if it is gcc's
<Laney> you can ask it to AFAIK
<xranby> some parts of GHC are written in c.. if the arch version detection are done in c code then you can use it
<micahg> janimo`: yep, you called it, linking with v8 broke :)
<janimo`> micahg, ok, so the snippet I appended to the bug should help
<janimo`> or maybe not , this build system is crazy. I know I got it working by setting that variable to 1 in the sconscript
<janimo`> if you know that debian/rules can actually pass that v8_armeabi var reliably to SConscript it would be helpful
<micahg> janimo`: that I don't know Scons is pretty greek to me
<micahg> but, if there's a gyp flag, that's likely to work
<janimo`> the script itself is legible, but wherever it is hooked in with gyp and the rest is a mistery to me
<micahg> janimo`: so, I'll drop your scons change and use the gyp flag, how does that sound?
<janimo`> sure
<micahg> janimo`: is this worth doing now, or should I wait for the next stable update?
<janimo`> although that SCons thing looks suspicious. Why there's no EABI setting like in the other cases simialr in that file - all come in threes soft/softpf/hard in 2 places, buit this one where only soft is specified
<janimo`> micahg, next stable
<micahg> ok, thanks
<janimo`> progress has been made with this release too :)
<micahg> yes, indeed :)
<janimo`> is next stable in 6 weeks? Or do you have intermediate uploads too sometimes?
<janimo`> either way, next upload, wherever it is
<micahg> yeah, there are intermediate uploads whenever chromium feels like releasing it's cache of CVE fixes
<janimo`> I'll actually do a test run these days, let it build to have a tested fix
<micahg> s/it's/its
<janimo`> soon, until I do not forget how to quilt patch the tree
 * micahg will start using the word attempt with fixing armhf FTBFS :)
<janimo`> exaclty - I have been cautious enough to use attempt in many changelogs and bug comments so far :)
<janimo`> or the more optimistic - making the build progress
<sveinse>  /etc/init/ttyS*.conf is set to start on stopped rc, which is rather late in the boot process, which can prevent login if booting fails. Would there be any problems starting getty very early, like on startup (upstart event)?
<sveinse> I did this for debugging, and it seems ok. Of cource you are warned of ro rootfs, but that's fine as long as you get a login. Now I'm wondering if we should ship this config permanently
<sveinse> Where does the logs from e2fsck run by mountall end up on a natty system?
<int_ua> Is it possible to install deb package for armel that depends on other armel packages on armhf system?
<int_ua> I tried dpkg -i --foreign-architecture armel but it still complains about missing package despite it's installed
<Riddell> GrueMaster, ogra_: oneiric armel images boot fine on my panda board, precise armhf images do not
<ogra_> oh ? intresting
<ogra_> whats the error ?
<Riddell> is that something in the pandaboard hardware that can't do armhf, or is it my low power I've giving the board?
<Riddell> ogra_: green LED is the error
<ogra_> i mean on your serial console :)
<Riddell> I don't have a serial console
<ogra_> for development it really helps to have one
<Riddell> ogra_: what do I need to buy?
<ogra_> an usb to serial adapter, try to get one you can attch directly to the pandas serial connector (female i think)
<smplman> is their any way to CC entire deb packages then transfer the binaries to the host machine?
<smplman> target, sry
<infinity> smplman: Define "cc entire deb packages".
<infinity> smplman: If you mean "attempt to reconstruct it based on what's currently on the filesystem", you want dpkg-repack.  But there's no guarantee that's going to give you a sane package.
<infinity> smplman: Usually, you just want to install the same deb everywhere, and then customise your configs accordingly.
<smplman> say i want to install the nano.dpkg on my arm system, but i want to cross compile if first on my x86 system so its faster
<smplman> then transfer the binary over
<smplman> i realize packages are usually platform independent, but i think its probably faster to cc my packages then transfer them over
<smplman> if this is crazy talk just let me know
<smplman> i know how to CC normal source, then transfer the binary
<smplman> im more concerned with ubuntu packaged now
<smplman> i meant *.deb earlier not *.dpkg
<smplman> infinity: if that makes sense
<infinity> smplman: I'm still lost by what you mean by "CC the package".
<infinity> Unless you mean compile?
<infinity> And packages are most certainly not platform independant.
<smplman> cross compile the package on my x86 machine then transfer it to my arm machine
<infinity> Yeah, it's sometimes doable.  But not often.  And we're still working on making it work better.
<smplman> Anything documented yet?
<infinity> You're really just better off building the package natively, unless you're ready to do a lot of reading on dpkg-cross and the like (and prepared to curse a lot when your use-case fails).
<infinity> Well, all the dpkg-cross stuff is documented.  But also in the process of being deprecated for better and shinier methods.
<smplman> its for personal dev so not that big a deal
<infinity> I really do just recommend building natively for most people.
<smplman> i have 11.10 running on both my xoom and beagleboard xm
<infinity> The special case to that rule being people who build a lot of kernels, since that's all set up to "just work" with a cross-compiler installed.
<smplman> yea im good with building kernels
<smplman> it just takes forever to install packages on my xm
<infinity> For most other packages, the odds of it working, and the odds of you wanting to throw things are high enough that building natively is just easier.
<smplman> or just build from source vs using the .deb?
<infinity> I don't see how that changes anything...
<infinity> Wait.  Are you talking specifically about dpkg itself taking a long time?
<infinity> There's zero ways around that.
<infinity> I thought you meant building the deb on another system, then copying it over and installing it.
<infinity> There's no sane way to avoid the part where you invoke dpkg.
<int_ua> ogra_: You've mentioned ficrtc boot option earlier today. But I can't find docs about it. Was it some typo?
<GrueMaster> int_ua: It is fixrtc, a simple shell script that is part of initramfs-tools.
<int_ua> GrueMaster: Thanks
<brendand> are the sudden switch offs i'm seeing on the pandaboard with this weekends daily expected?
<tvoss> Hi all, is it possible to run the 12.04 omap4 image under qemu?
<ogra_> no
<tvoss> ogra_, is there any image that I can run under qemu?
<ogra_> the omap3 image might run in the beagle emu
<ogra_> qemu simply has no emu for omap4 at all
<tvoss> thanks ... are imx images supposed to be running in qemu then?
<ogra_> no
<ogra_> there is no qemu emulation for any of the images we have apart from omap3
<brendand> tvoss, qemu is not a platform as such
<ogra_> you can roll something yourself based on the vexpress kernel and a self rolled rootfs (or ubuntu-core)
<GrueMaster> ppisati: ping - not sure if you noticed, but I figured out why I didn't have sound & networking on the beaglexm.
<ppisati> GrueMaster: network works here
<ppisati> GrueMaster: dunno about audio
<ppisati> GrueMaster: on the othert hand, while updating this morning i noticed latest kernel hangs before mounting root
<ppisati> GrueMaster: did you try it?
<ppisati> 3.2.0-18.28
<GrueMaster> I have had spotty network at best.  I usually have to unplug, plug in the network cable several times to get it working.
<ppisati> GrueMaster: works immediately here
<ppisati> rev c and rev a
<GrueMaster> I am just waking up.  Haven't even really started anything yet.
<ppisati> k
<ppisati> GrueMaster: when you are caffeinated enought, tell me which kerbnel version were you running
<GrueMaster> I have a rev b beaglexm.  It has had these issues for 2 cycles now.
<ppisati> 3.2?
<GrueMaster> I documented everything in bug 925094 and bug 838200.
<ubot2`> Launchpad bug 925094 in linux "No audio on omap (beagleXM) system" [Medium,Confirmed] https://launchpad.net/bugs/925094
<ubot2`> Launchpad bug 838200 in u-boot-linaro "No network support on Beagle XM" [High,Confirmed] https://launchpad.net/bugs/838200
<GrueMaster> 3.2.0.18 iirc.  I pulled from git.
<ppisati> latest one is 3.2.0-18.28
<ppisati> but it seems it's broken
<ppisati> previous one -17.27 should be ok
<GrueMaster> Well, it worked in my build of it.  Must be a patch since Friday?
<ppisati> GrueMaster: i'm booting off the sd FWIW
<GrueMaster> Same here.  I just added my kernel to the Beta 1 image.
<smplman> GrueMaster: im running 3.2.9 from https://github.com/RobertCNelson/stable-kernel , good results
<smplman> on my xm rev b ATM
<GrueMaster> smplman: We are using the mainline kernel, not a hacked up version.  We really want to be as close to main as possible.  Eventually, the omap4 kernel will also be done this way.
<ogra_> you wish :)
<GrueMaster> I am well aware of other working kernels.  The test image that ships with the XM works perfectly, but not all of it is upstream.
<GrueMaster> ogra_: well, I did say eventually.
<smplman> GrueMaster: I understand, just trying to help
<ogra_> yeah, it will take years until the DSS code goes upstream
<hrw> janimo, ogra: can you endorse me on my motu application? https://wiki.ubuntu.com/MarcinJuszkiewicz/DeveloperApplication-MOTU
<Riddell> ogra_, GrueMaster: ok here is loading with oneiric successfully and with precise unsuccessfully http://starsky.19inch.net/~jr/tmp/arm/
<Riddell> there's not much in the diff
<Riddell> could it be just not showing on the monitor in precise?
<Riddell> I have a full power supply now
<ogra_> looks like the bootloader runs fine
<smplman> Riddell: omapfb missing maby?
<Riddell> smplman: I have no idea what that is
<ogra_> smplman, thats compiled in
<ogra_> Riddell, it would help to get the kernel bootmessages (which we supress by default)
<Riddell> ogra_: how can I do that?
<ogra_> Riddell, open the boot.scr from the first partition of the SD card in vi
<ogra_> delete the garbage (u-boot header) in the beginning
<ogra_> then edit the cmdline in that file and save it as boot.script
<smplman> Riddell: what image are you using?
<Riddell> smplman: ubuntu desktop precise beta 1
<Riddell> omap4
<GrueMaster> ppisati: I am uploading my kernel .deb to http://people.canonical.com:~tobin/linux-image-3.2.0-18-omap_3.2.0-18.28_armhf.deb for you to try.  Should be available in ~12 minutes.
<ogra_> Riddell, you will then need to install u-boot-tools to get the mkimage command
<smplman> is omap4 backwards compatible with omap3?
<GrueMaster> Actually, save it back as Env.txt and reboot.  Newer u-boot should be able to take it from there.
<GrueMaster> ogra_: Riddell ^^^
<ogra_> oh, i didnt know we got that bit from zupstream working nowadays
<ogra_> smplman, no
<ogra_> different arches
<Riddell> ogra_: the whole of the first line is garbage?
<smplman> i know the xm is omap3
<ogra_> well, the stuff vim doesnt show properly :)
<Riddell> GrueMaster: so don't save it as boot.scr but as Env.txt ?
<ogra_> Riddell, right
<ogra_> and put it on the first partiton of the SD
<Riddell> ogra_: and what do I need to do with mkimage?
<ogra_> not sure, you might need to remove boot.scr from that partition
<ogra_> Riddell, if Env.txt works you dont need it at all
<GrueMaster> Yes.  Strip the u-boot header (garbage at the beginning), then remove the quiet & splash lines on the bootargs and add "console=ttyO2,115200 console=tty0".
<ogra_> else you would need it to add the header back to the file
<Riddell> "[    5.272796] panic occurred, switching back to text console"  ouch
<ogra_> hrw, done btw
<Riddell> how can I get minicom to save to a file?
<ogra_> ctrl-a+h
<Riddell> ogra_: that saves it?
<ogra_> that should give you the list of commands ... there is some way to use a logfile
<Riddell> that hangs up
<ogra_> i never used logging, i just scoll back in my terminal in screen and copy/paste that
<Riddell> this is giving me a bit too much output to do that
<GrueMaster> Riddell: Use "screen /dev/ttyUSB0 (or shat ever the serial port on your pc is), then use screen's logging capabilities.
<ogra_> yeah
<Riddell> aah
<GrueMaster> ppisati: My kernel is up if you want to test it.
<Riddell> GrueMaster, ogra_ http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-noquiet
<Riddell> [    4.463867] EXT3-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)  ?
<GrueMaster> odd indeed.
<infinity> Did we misplace ext4 support somewhere? :P
<infinity> I'm assuming 240 is an ext4 feature flag.
 * infinity looks.
<ogra_> it just loops over the ext filesystems usually
<ogra_> thats a red herring
<infinity> Yeah, 240 is an ext4 feature.
<GrueMaster> Something doesn't sound right with his image.  I tested all (and I do mean ALL) images for beta 1 on multiple systems.
<ogra_> it should be trying ext4 next ... not sure why it doesnt
<infinity> Riddell: Is that a fresh precise install, or something hacked up and/or upgraded?
<Riddell> infinity: installed like this  sudo sh -c 'zcat ./ubuntu-12.04-beta1-preinstalled-desktop-armhf+omap4.img.gz |dd bs=4M of=/dev/mmcblk0 ; sync'
<Riddell> which works fine for oneiric
<ogra_> did you let it finish the resize on first boot ?
<Riddell> ogra_: I don't know, I had no output
<ogra_> if it was interrupted it indeed might corrupt your fs
<infinity> You have no monitor connected?
<Riddell> infinity: I do have a monitor connected.  it does not show anything with precise
<infinity> Wrong port?
<infinity> Is it HDMI or DVI?
<infinity> (Yes, people mess this up all the time)
<infinity> The HDMI port is the one next to the ethernet.
<GrueMaster> Do you have the monitor on the HDMI port (closest to the USB ports).
<infinity> ie: Not the one on the outside of the board.
<Riddell> I have a DVI monitor plugged into the DVI port which worked fine with oneiric
<ogra_> might have changed with the new kernel version
<ogra_> try HDMI :)
<infinity> Ahh, kay.  Something may have broken DVI.  I only ever test with HDMI (cause it's all I have the cabling for)
<Riddell> I have no HDMI monitor
<infinity> HDMI TV?
<ogra_> just plug the DVI into the HDMI port
<Riddell> I have no TV
<ogra_> should work fine
<infinity> ogra_: That really shouldn't work.
<infinity> ogra_: But I'd be curious to see if it does.
<ogra_> or was it the orther way round ?
<ogra_> it wont do any harm either way though
<infinity> True.
<GrueMaster> infinity: Yes, it should.  hdmi is the same signal as DVI-D.
<infinity> Riddell: Also, despite all protests to the contrary, you can just zcat foo.img.gz > /dev/whatever
<infinity> Riddell: The dd is entirely pointless.
<ogra_> right, i thought so
<infinity> GrueMaster: Yes, HDMI is a superset of DVI-D, but it also intentionally leaves out (in many implementations) lots of the possible resolutions.
<ogra_> infinity, using a 4M blocksize speeds up the writing
<infinity> GrueMaster: If that's the case on the omap4 kernel (or at the hardware level), I have no idea.
<GrueMaster> I don't know if the dvi port on panda will work w/o the TI drivers (not in FB w/o kernel parameters).
<ogra_> i know i used the HDMI port of my monitor with a HDMI cable plugged into the DVI port in the past ...
<GrueMaster> But signal wise, an HDMI port can connect to a DVI monitor just fine.
<ogra_> but i dont think i ever tried the other way round
<infinity> The other way around really shouldn't work.
<infinity> But HDMI->DVI will work, if it supports the resolutions you need.
<GrueMaster> The only thing that will be missing is HDMI audio.
<infinity> The audio channels just go off into la-la land.
<GrueMaster> And DVI->HDMI works the same way.
<infinity> Anyhow.
<infinity> Riddell: Using the HDMI port may well make things happy.
<Riddell> I gathered :)
<Riddell> remaking the image on the SD card
<infinity> Or, we could discuss it more. :P
<GrueMaster> As long as it is all digital.  DVI also supports analog (but that is a different discussion and irrelevant to this discussion).
<ogra_> infinity, awesome idea !
<GrueMaster> Riddell: I relooked at your kernel output (above).  Why is "rootfstype=ext3" in the kernel cmdline?
<GrueMaster> That isn't normal in our images.
<damian0815> hey ubuntu-arm, ld is complaining that 'main.o uses VFP registers, a.out does not'
<damian0815> i'm compiling main.cpp with -mfpu=vfp + other args. how can i convince ld that a.out should use VFP registers also?
<Riddell> GrueMaster: I have no idea
<Riddell> I just used a normal image with the edited boot command edited to remove quiet
<GrueMaster> Well, since we use ext4 images, that line would have given you issues.
<GrueMaster> Riddell: Was this the Ubuntu beta 1 or Kubuntu Beta 1?
<Riddell> GrueMaster: Ubuntu Desktop Beta 1
<GrueMaster> Ok.  Checking here, I see no indications of where "rootfstype=ext3" could have come from, unless it is in u-boot and you didn't use the boot.scr.
<GrueMaster> Your console log above was started after u-boot had booted.
<Riddell> GrueMaster: I didn't use the boot.scr after I saved it to Env.txt
<GrueMaster> Did it load the Env.txt?
<Riddell> dunno reformatting the SD card and trying again
<GrueMaster> Oh, wait.  I think I see what is happening.  u-boot only looks for the uImage & uInitrd lines in Env.txt.  I was told it works the same as boot.scr.
<GrueMaster> So nix the Env.txt idea.
<GrueMaster> At any rate, you should have video on hdmi.
<infinity> damian0815: That sounds like you're using -mfloat-abi=hard on an armel system.
<infinity> damian0815: Which will only work if you link with gcc as well (or pass the right bits to ld), since ld won't magically do what you think it should.
<infinity> damian0815: Alternately, run armhf if you want armhf. ;)
<damian0815> infinity: thanks for the reply
<damian0815> infinity: i am in fact linking by calling gcc
<damian0815> infinity: i guess gcc isn't telling ld to do the right thing?
<infinity> damian0815: On which release is this?
<damian0815> infinity: 10.10
<infinity> Oh, yeah.
<infinity> That's almost certain to just plain not work.
<damian0815> rightoh
<steev_> what is this install RELEASE shortcut that's started showing up on my shortcut bar (and how do i get rid of it?)
<steev_> clicking on it just gives me a crash in ubiquity
<damian0815> i'm installing 11.10 as we speak. was avoiding before due to lack of omap-extras-graphics.
<infinity> Besides, even if you compiled your application as hardfloat, if it links to anything else, it won't work.
<steev_> (it's still rotating circle on collecting info)
<infinity> damian0815: Install precise/armhf if you want hard-float.
<infinity> damian0815: You'll like it better than oneiric anyway.
<GrueMaster> Riddell: The ubuntu beta 1 image works for me on a non-hdmi DVI monitor here, so you "should" have no issues.  If you still do, we can figure it out.
<Riddell> GrueMaster: http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-using-hdmi
<Riddell> that's ubuntu beta 1 with a dvi monitor plugged into the HDMI port
<Riddell> I'm awaiting instructions :)
<damian0815> infinity: what's the status of SGX drivers in precise?
<steev_> er, this is interesting.  so ubiquity is crashing with IOError in main() Errno 2, No such file or directory: '/proc/2058/oom_score_adj'
<steev_> why would ubiquity crash because oom_score_adj doesn't exist?
<GrueMaster> Riddell: This is normal so far.  You see nothing on screen?
<Riddell> GrueMaster: nothing
<infinity> damian0815: As I understand it, it's all working in the tiomap-dev/trunk PPA.
<GrueMaster> (not serial console, but on the monitor).
<GrueMaster> And you have a proper power supply now?
<Riddell> GrueMaster: I do
<infinity> damian0815: But depends on installing the 3.1 kernel from the oneiric PPA.
<infinity> damian0815: (That will be resolved soon)
<damian0815> infinity: super. i'll see how i go with oneiric. i'm trying to build a straightforward enduser experience for openFrameworks (C++ art+code toolkit)
<GrueMaster> Monitor is using an HDMI->DVI cable and no other conversions?
<infinity> damian0815: Sure.  oneiric should work fine.  But just stop trying to pass whacky float options to the compiler.  Stick with the defaults and your life won't be pain. ;)
<infinity> damian0815: (But, like I said, precise/armhf will treat you better than oneiric/armel, except for the bit where it's not quite done yet)
<damian0815> infinity: heh. thx.
<GrueMaster> Riddell: Monitor is using an HDMI->DVI cable and no other conversions?
<infinity> steev_: Is /proc mounted at all?
<Riddell> GrueMaster: HDMI-DVI adaptor and DBI cable to monitor
<GrueMaster> Ok.  Wanted to make sure there were no DVI->VGA adapters in the mix.
<GrueMaster> Do you have another device with HDMI out that you know works?
<GrueMaster> It is also possible that your cable only handles DVI-A (VGA), although those are rare.
<Riddell> GrueMaster: I have no HDMI devices no
<GrueMaster> No PS3 or XBox?
<Riddell> no
<Riddell> GrueMaster: this setup works fine for oneiric
<GrueMaster> The oneiric image works?  Now that is odd.
<Riddell> yes
<GrueMaster> Out of curiosity, what rev board is this?
<Riddell> GrueMaster: how do I find out?
<GrueMaster> Sticker on the bottom?
<Riddell> GrueMaster: Rev A1
<GrueMaster> Panda or PandaES?
<GrueMaster> I'll look at my stacks and see which is an A1 so I can try to reproduce it here.
<Riddell> GrueMaster: Model: PandaBoard Rev A1
<GrueMaster> Ok.  I have one (I have one of each and then some).  I'll try it here.  Works fine on PandaES and Panda A3 so far.
<shadeslayer> infinity: ping
<shadeslayer> infinity: https://bugs.launchpad.net/ubuntu/+source/qtwebkit-source/+bug/945393 << Any ideas how to fix? (/usr/bin/ld: final link failed: Memory exhausted)
<ubot2`> Launchpad bug 945393 in qtwebkit-source "qtwebkit-source version 2.2.1-1ubuntu2 failed to build on armhf" [High,Confirmed]
 * micahg wonders if it's worth filing a toolchain bug for https://launchpadlibrarian.net/95446439/buildlog_ubuntu-oneiric-armel.chromium-browser_17.0.963.65~r124586-0ubuntu0.11.10.1_FAILEDTOBUILD.txt.gz
<GrueMaster> Riddell: I can't seem to reproduce your issue here at all.  Give me a minute and I will send you a replacement boot.scr for debugging.
<Riddell> GrueMaster: thanks
<GrueMaster> Did it get through the first boot ok?  Easiest way to check is to look at the sd card in your desktop and see if the second partition fills the SD.
<Riddell> GrueMaster: I think it did but I've since reformatted it ready for your new boot.scr
<GrueMaster> Ok.  One sec then.
<GrueMaster> I have to flash it fresh to an SD then modify it.  Takes the same time as uncompressing/loop mounting.
<infinity> shadeslayer: It's on my TODO, but no, I don't have any immediate ideas right now.  I have a few things on the go.
<infinity> micahg: I wouldn't bother, personally.
<GrueMaster> Riddell: http://people.canonical.com:~tobin/boot.scr
<GrueMaster> Download it and copy directly to partition 1 (fat partition) overwriting existing boot.scr.
<micahg> infinity: ok, well, if there isn't a way to work around it then, Chromium on arm in the stable releases looks slim
<GrueMaster> And make sure screen is set to log before powering on the panda.
<GrueMaster> I need food, will return shortly.  Pastebin the console log (or save it somewhere).
<infinity> micahg: I'm much more interested in the LTS anyway, but if we have a spare moment, we can look at the oneiric FTBFS.
<micahg> well, we're 2 hours (build time) closer to havign armhf work, armel already works in precise
<Riddell> GrueMaster: what changed?
<Riddell> GrueMaster: when I run screen /dev/ttyUSB1 I just get junk output and it causes minicom to get junk output to
<GrueMaster> Works fine here.
<Riddell> ogra_: not at cebit are you?
<ppisati> GrueMaster: which u-boot/x-loader version do you have with beaglexm? and which cmdline do you use?
<ogra_> Riddell, nope, 150km south of it
<Riddell> ogra_: you couldn't ship yourself and your office to hannover or Bielefeld for tue/wed/thu could you, just to help me? :)
<ogra_> Riddell, hmm not really, what are you doing at CeBIT ?
<Riddell> see cebit
<Riddell> seeing cebit
<Riddell> I've never seen it before
<ogra_> ah
<ogra_> i have been to each since i was 16
<ogra_> but not since i work for canonical
<ogra_> <- grew up in hannover
<Riddell> too many travelling days for UDS et al? :)
<ogra_> nah, just no interest, i moved south a few years before starting ubuntu stuff, havent been back often
<ogra_> if i go, i just do it to visitn my parents, but thats not more than a few hours (though i love hannover, but all friends i had there moved to berlin or elsewhere)
 * ogra_ is off for the evening 
<Riddell> GrueMaster: http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-using-tobiins-boot.scr
<Riddell> GrueMaster: now I'm getting a very jumbled login prompt http://starsky.19inch.net/~jr/tmp/arm/ubuntu-precisebeta1-armhf-using-tobiins-boot.scr-login
<Riddell> from the serial
<Riddell> nothing on monitor
<davidhayesbigtoe> hello
<davidhayesbigtoe> can anyone direct me to any ubuntu ARM's that might be able to run on the new rasberrypi's?
<rcn-ee> the rasberrypi is an arm11 "armv6" core, ubuntu's current minimal arch for supported dist is "armv7-a"....
<Riddell> "use debian"
<davidhayesbigtoe> rcn-ee damn..
<davidhayesbigtoe> i guess i would've found that out had i read more on the man for the pi. i haven't bought one yet as they first B boards haven't even shipped yet.. but i heard about it 3 days ago and i'm excited and would like to get my hands on one. so i'm trying to plan my assault on the thing the moment it arrives..
<davidhayesbigtoe> Riddell i was hoping for ubuntu or slax... but i digress...
<davidhayesbigtoe> i know there is bt ARMS for android phones.. but obviously an HTC incredible is much more powerful than a pi and i think it uses v11? idk..
<rcn-ee> the htc incredible is a QSD8650, armv7-a core..
<davidhayesbigtoe> yea..
<davidhayesbigtoe> ARM cortex-A15 cpu
<davidhayesbigtoe> for my specific phone.. using the armv7 arch.. anyhow. i know my phone HAS the capability to handle 720p/1080p but is not enabled by default?
<rcn-ee> ah, no.. currently no "cortex-A15" cores are shipping yet.. But shorty.. ;)
<davidhayesbigtoe> i need to root and crack this baby open
<rcn-ee> usually. 720p/1080p video is handled by a video coprocessor..
<shadeslayer> davidhayesbigtoe: you can boot debian tho
<rcn-ee> (the rasperby pi's core has the same feature, that's why they can show it doing video..)
<davidhayesbigtoe> blah.. i'm dumb.. the successor to the current scorpion chip i have.. the S4 SoC has the cortex cores
<shadeslayer> also, I'm waiting for my RasPi as well
<davidhayesbigtoe> rcn-ee yea, i know that's why i want a pi
<davidhayesbigtoe> lol
<davidhayesbigtoe> but i also wanna fully crack open my dINC1 now that my contract is up and i'm do for a new phone
 * shadeslayer has a voucher code, but no way to redeem the voucher
<davidhayesbigtoe> i wanna integrate the pi and the droid together.. maybe use it for touch screen display on the pi
<davidhayesbigtoe> hah
<shadeslayer> http://lists.qt-project.org/pipermail/qtonpi/2012-March/000215.html ... :(
 * davidhayesbigtoe :-(
<davidhayesbigtoe> i didn't even order
<davidhayesbigtoe> i put myself on the mailinglist and sent an inquiry
<danboid> How do I install 12.04 (nightly or beta) on my pandaboard?
<danboid> I've booted a recent nightly and modified it to show a serial console but I dunno how to log in to it- username/password?
<danboid> I've tried ubuntu with no password or ubuntu as password too with no luck
<danboid> There don't seem to be any headless OMAP4 builds of Precise yet, which is what I'd use if I could get some
<infinity> danboid: s/headless/server/
<infinity> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/
<danboid> infinity, Aha! Thanks v much!
<pbuckley> Kernel /boot/vmlinuz-3.2.1 does not match your subarchitecture
<pbuckley> omap4, therefore not writing it to flash.
<pbuckley> got this on this morning's apt-get dist-upgrade
<infinity> pbuckley: And where did that kernel come from?
<infinity> pbuckley: It's not a distro kernel.
<pbuckley> hrmm it might have picked it up from ti's repo
<pbuckley> ill let you know once it finishes
<infinity> dpkg -S /boot/vmlinuz-3.2.1
<infinity> And it wouldn't be from TI's PPA, they're building 3.1
<pbuckley> nm.. i must have built it
<pbuckley> its not showing up in dpkg
<infinity> Yeah, I suspected as much.
<infinity> If you want flash-kernel to play nicely with local kernel builds, just tack an -omap4 extraver on the end of them.
<infinity> Cause we do machine type to subarch mapping to make sure Bad Things don't happen if someone installed a kernel package for another subarch.
<CodeWar> https://wiki.ubuntu.com/ARM/RootfsFromScratch
<CodeWar> What in God's name are you guys using to build that kernel,  if I replace it with my own kernel it says rootfs not found. Is there a driver MMC perhaps you guys bake in there?
<CodeWar> :-)
<pbuckley> i just use the ubuntu tools for building a kernel
<pbuckley> let me get you a link
<pbuckley> https://help.ubuntu.com/community/Kernel/Compile
<CodeWar> pbuckley, thanks let me read that wiki, if there is a .config file you have somewhere that would be very useful too
<GrueMaster> CodeWar: What platform are you building a kernel for?
<CodeWar> GrueMaster, vexpress-a9 running on QEMU
<CodeWar> I can build zImage and load run and have fun with NFS boot all I want but booting off qemu img never worked for me. It appears to work for you guys so diffing whats different :-)
<GrueMaster> I know nothing about the vexpress build or running on qemu, but I believe we have a vexpress kernel in the pool.
<CodeWar> can you point me to the .config file for whatever kernel works successfully on QEMU?
<CodeWar> thats all I m looking for anyways :-)
<GrueMaster> Not easily.  Either pull the deb package or use the kernel git tree from the link pbuckley pasted.  I think the omap kernel is what is used for qemu.
<mythos> hmm... not versatile? :o
#ubuntu-arm 2012-03-06
<pnphi> How choice RAM of qemu-system-arm
<mythos> pnphi, qemu-system-arm -m 256 -append "mem=256M ..." <-- do you want to specifiy how much ram is available?
<pnphi> i want > 256
<pnphi> more ?
<mythos> results in segfaults, as far as i know
<pnphi> what is segfaults ?
<mythos> pnphi, http://en.wikipedia.org/wiki/Segfault
<twb> You could use qemu-arm-static instead and just run it in a chroot instead of with a separate arm kernel
<twb> Then you'd have access to the entire host system's ram
<pnphi> how to change Memory of qemu-system-arm ? ? more 256 ??
<steev_> is there any way to get rid of the 'Gtk-Warning **: Unable to locate theme engine in module_path: "pixmap",' messages? I can't seem to find the pixmap engine
<steev_> i thought it was part of gtk2-engines, but that is already installed
<steev_> aha, it's gtk2-engines-pixbuf (why is it called pixbuf when it installs libpixmap.so ?)
<twb> steev_: hysterical raisins
<twb> You should not need that driver unless you're using a very silly and inefficient GTK theme, though
<steev_> twb: well i'm running arduino, though there are a few other apps that pop up the messages that get installed by ubuntu-desktop
<twb> Specifically, one that works by stretching small images (usually 2x2) to fake gradients.
<steev_> and it's using the defaults
<twb> steev_: interesting
<lilstevie> even chromium shows that
<lilstevie> on x86
<twb> You could try something like echo 'gtk-theme-name = "Raleigh"' >> ~/.gtkrc-2.0
<twb> Although gnome will cause that dotfile to be ignored :-/
<lilstevie> steev, I wouldn't be overly concerned
<twb> Hmm, on oneiric I don't have gtk2-engines-pixbuf, I do have libgdk-pixbuf2.0-0, I do not get that warning AFAIK
<twb> http://cyber.com.au/~twb/.gtkrc-2.0 is my GTK2 theme
<twb> Using epdfview and midori GTK2+ apps, but no gnome
<steev_> twb: this is on a precise armhf install from -core, apt-get installed minimal, standard, desktop, then adding a few special things
<steev_> namely our ancient efika kernel (we're working on a new one, i swear)
<twb> Well, suffice to say that it WFM without that warning and without that .so, so it is apparently POSSIBLE to avoid the warning
<steev_> i haven't changed anything from the defaults (except editing /usr/bin/ubiquity to change oom_score_adj to oom_adj otherwise ubiquity dies, and deleting the /usr/share/applications/ubiquity-gtkui.desktop file because I was tired of seeing Install RELEASE in my sidebar)
<lilstevie> steve@steve-tf201:~/Downloads$ chromium-browser
<lilstevie> (chromium-browser:4567): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap",
<twb> lilstevie: is gnome-settings-daemon running?
<lilstevie> that is on oneiric-armel
<lilstevie>  1259 ?        Sl     0:16 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
<twb> That's why
<lilstevie> heh
<twb> It causes all your dotfiles to be ignored and overridden by gconf
<twb> So whatever silly pixmap-based theme you're using, is not mentioned in .gtkrc-2.0
<twb> You may find changing your theme to (e.g.) raleigh in GNOME's control center, causes the warning to go away
<steev_> i haven't bothered to look in precise, i'm okay with installing pixbuf, it's all of one file and like 4 docs
<twb> Indeed, but using it will increase (probably significantly) the bandwidth consumed between X server and apps
<lilstevie> in any case, it is only a warning
<twb> And also it's a stupid ugly irresponsible design :-/
<twb> lilstevie: right
<twb> lilstevie: although not loading that driver basically means you get a GTK theme that looks different
<lilstevie> twb, well this is an out of the box configured install
<lilstevie> and same as on my desktop
<lilstevie> same deal there too
<lilstevie> :p
<twb> Then I guess ubuntu's default theme is silly and asks for a feature it doesn't install by default
<lilstevie> so maybe it needs a bugreport
<twb> I agree
<steev_> i'll let twb file it and get the karma
<lilstevie> yep twb can have it :p
<lilstevie> I don't care enough to file a bug report
<lilstevie> :p
<twb> I can't even reproduce your silly problem, so I won't report it
<lilstevie> if(WARNING){ ignore;}
<twb> Also I have a policy on not reporting problems to launchpad because it isn't debbugs
<lilstevie> twb, heh you can't reproduce it because you are silly and use xinit
<twb> If you mean I don't waste time starting X when I don't need it, sure
<lilstevie> well samsung repair man be here
<lilstevie> later
 * twb struggles to turn that into a joke
<recur> from make, is there a way to force use of a different linker?
<twb> make LD=gold
<twb> Of course that assumes your make rules aren't silly
<recur> ah interesting, it's still using the wrong one when I pass that
<recur> I'm trying to crosscompile libpng
<recur> I'll take a look at the make rules, tahnks :)
<twb> Cross-compiling is a whole extra ballgame, one with which I am less familiar
<twb> Hmm, default gmake rules actually don't call LD, they call CC or FC with linker options
<twb> http://paste.debian.net/158723/
<recur> ohh, hmm
<twb> Suggest you find someone good at cross-compiling and ask them
<recur> thanks, will do :)
<NekoXP> recur, what linker are you trying to use?
<recur> Hi NekoXP :  I was able to get it working by editing libpng's Makefile :)
<hrw> ogra_: thx for comment
<ogra_> np :)
<twb> Ahahahaha
<twb> Sorry, wrong channel.
<twb> When someone has a minute, I'd like to know if "w3m http://www.menumate.com.au/sofias-pizza-house" generates gc warnings
<twb> poss. only happen when w3m-img is installed.  I'm getting them on oneiric in screen in fbcon.  I wasn't geting them a while back, might have been before I switched to ARM tho
<twb> (Except tell me tomorrow because I'm about to go to dinner.)
<sveinse> ogra_: What does fixrtc do specifically? Could it affect valid time (Hw clock > Fs timestamp) in any way?
<ogra_> it checks if the last mount time of the disk is in the future, if so, it sets the hwclock to that time
<ogra_> (plus a few seconds)
<hrw> ogra_: janimo` will be next to comment - he complained yesterday to me about 'why you are not motu/core-dev yet' :D
<ogra_> heh
<hrw> https://blueprints.launchpad.net/linaro-ubuntu/+spec/toolchain-backports-ppa-update-12.03 - one 'simple' ppa update
<ogra_> sveinse, indeed it could, if the time of the machine that last mounted the disk was wrong (in the future) it would move your board to that time (plus a few seconds) ;)
<sveinse> ogra: interesting. So if user erroneously sets the date to sometime in the future, he will either have a non-working system or stuck with this future time, right?
<sveinse> ogra_ ^
<ogra_> not if his system is networked
<ogra_> ifup calls ntpdate on connect
<ogra_> that will correct the time and on unmount (shutdown) the time of the disk will be correct
<ogra_> if the system is non networked your statement is true indeed
<ogra_> but thats still better than hanging in an endledd mountall fsck loop on boot ;)
<sveinse> If the mounttime is indeed written on umount, then it does not matter if its ntp or the user which corrects the clock
<ogra_> right, but something *has* to correct it indeed
<sveinse> yep, I feared that fs mounttime was the last 'mount' time and not umount
<ogra_> well, check the code, iirc i made it check for the last unmount time, if not, thats indeed a bug
<sveinse> in mountall source, right?
<ogra_> no, the fixrtc script somewhere in /usr/share/initramfs-tools
<sveinse> thanks, I'll check
<ogra_> oh, i think i did use last mount time, but that gets updated on umount
 * ogra_ remembers again
<janimo`> hrw, I am missing the context in the scrollback. Not sure what I am next to comment on. If you have a MOTU application written up then great :)
<ogra_> i guess he wants you to comment on his wiki ;)
<janimo`> ogra_, I think that's the context/link I miss in scrollback
<hrw> janimo`: https://wiki.ubuntu.com/MarcinJuszkiewicz/DeveloperApplication-MOTU
<hrw> btw: http://marcin.juszkiewicz.com.pl/2012/03/06/updated-cross-toolchain-for-ubuntu/
<janimo`> hrw, added note. Good luck! :)
<hrw> janimo`: thx
<sledges> hello
<sledges> where can I access sources to i.MX53 hardware graphics drivers?
<sledges> used by UBUNTU 1109 IMX53 build
<ubot2`> Ubuntu bug 1109 in gringotts "No desktop entry in /usr/share/applications" [Medium,Fix released] https://launchpad.net/bugs/1109
<ogra_> sledges, no, you used the linaro 1109 ubuntu build, ask in #linaro
<ogra_> ubuntu didnt have any 11.09 release :)
<sledges> ogra_, you are right
<sledges> 'cause all i could obtain for now were source of kernel, but nothing outside
<ogra_> i dont think the binary drivers for mx53 are made available by freescale though
<ogra_> *the sources for the binary drivers
<ogra_> but ask the guys that build the image ;)
<sledges> i use ltib from freescale for imx53, and their kernel is just rubbish :)) but provides the rest of binary drivers from sources..
<sveinse> ogra_: We're seeing that the mount time (or last write time) is never updated in the fs. This is why the clock is always reset by fixrtc. / is mounted with noatime, could this be the cause?
<ogra_> no, noatime shouldnt affect mount time
<ogra_> iirc
<ogra_> try it ;)
<sveinse> I just did and I see that dumpe2fs always reports the same timestamp on last write time and last mount time
<ogra_> hmm, it shouldnt
<ogra_> but try with noatime removed and see if that fixes it
<sveinse> This is weird! noatime does not affect the last mount time either
<sveinse> But I am indeed writing to the fs
<sveinse> That shouldn't matter when I come to think about it. As long as the hw clock is newer than the fs, then it ought to work
<sveinse> What I'm seeing is that the clock is _always_ reset to the date of the last mount time, so getting the clock from HW might not work properly
<ogra_> well, do you power off the board com,pletely and have no RTC battery on that board ?
<ogra_> then you indeed will always have a reset HW clock
<sveinse> ogra_, there is a RTC battery and hwclock reports correct rtc clock across reboots.
<ogra_> then it should not attempt toi set the clock at all
<sveinse> Where does it compare the clock? My /usr/share/initramfs-tools/scripts/local-premount/fixrtc contains http://paste.ubuntu.com/871392/
<ogra_> it doesnt
<ogra_> intrestingly
<ogra_> i know my original version did
<sveinse> this is in natty
<ogra_> the script comes from lucid
<ogra_> sveinse, that looks like a bug
<sveinse> Ok. I think we need to refrain from using fixrtc and rather make our own init script which replaces hwclock and make it last-mount-time aware
<ogra_> well, you should file a bug and make me fix fixrtc ;)
<sveinse> This is currently holding back production, so I can't wait for an upstream resolution
<ogra_> all you need it to convert the date to a timestamp and compare against the hwclock
<sveinse> where should I file the bug? Ubuntu-11.04 ?
<sveinse> ogra_ bug #947988
<ubot2`> Launchpad bug 947988 in initramfs-tools "fixrtc kernel option always sets system time" [Undecided,New] https://launchpad.net/bugs/947988
<ogra_> thx
<sveinse> np
<ogra_> sveinse, bug has a patch, could you test it ?
<ogra_> argh and LP messed up the style
<ogra_> added a .patch file now
 * sveinse is embarrased. Forgetting all about update-initramfs...
<sveinse> ogra_ it works
<sveinse> yet I observe that my ext4 fs "last mount time" seems to be written at mount and not on umount. last write time is never touched
<sveinse> if and if ubuntu shutdown really runs any umount on rootfs
<ogra_> great, did you counter test (with a mount time in the future) too ?
<sveinse> Yes, I did. Both prior and former dates
<ogra_> i need to be sure the old behavior still works before applying the patch
<ogra_> awesome !
 * ogra_ includes in the next upload then
<sveinse> (when) will this be published into natty?
 * sveinse is holding back production until fix is available...
<sveinse> I confirm that my ubuntu system does not write "last mount time" to disk when ubuntu shuts down. It only writes upon startup
<sveinse> This means that with the fixrtc option, the user will never be able to turn the clock back in time
<ogra_> thats illogical
<ogra_> your last mount time will never be newer than the installation date
<ogra_> if the RTC is set properly after the fist boot (by ntpdate or the user) the mount time will be updated next time you boot to a proper time
<ogra_> sveinse, ^^^
<ogra_> indeed that fails if your system clock is set years in the future during install, but thats a special case i'm willing to live with
<rbasak> Is fixrtc in the kernel or early userspace?
<rbasak> (OOI)
<ogra_> initrd
<ogra_> see the backlog
<ogra_> init-premount to be precise
<rbasak> thanks, I didn't go back far enough
<oneric> hi all
<oneric> i put SD on Board, when i start with ubuntu, start always the system configuration of ubuntu
<oneric> it not install
<oneric> i have pandaboard
<sveinse> ogra_ The reason I ask is because a user did indeed make a mistake when setting the time. He sat i to 2013. In this case, and if rtcfix is used, the user nor ntpdate will never be able to correct the time back to 2012
<xranby> oneric: thats normal, you are booting a preinstalled image
<sveinse> Because AFAICS "last mount time" is only updated when ubuntu is mounting root, never on shutdown
<ogra_> sveinse, right, he can just drop fixrtc from the cmdline in that case
<sveinse> Hence, the "last mount time" will only move forward in time
<ogra_> and it will be updated properly on next boot
<xranby> oneric: you are expected to see a welcome screen where you select language timezone keyboard etc. when the setup are complete your panda will reboot and start ubuntu from the same sdcard
<ogra_> i think for the normal usecase its a proper assumption that your clock moved forward normally and RTC will be > mount time and thus the mount time will be updated
<oneric> xranby when the setup is complete my panda reboot and restart configuration
<ogra_> in cases where you did weird things to the clock, manual intervention is required
<sveinse> Is this limitation (linux wont boot when date is in the past) constant across all linuxes? Because I've never seen this issue until now
<ogra_> it will boot ...
<sveinse> With that rationale I agree that it's not occurring very often
<sveinse> boot = start in runlevel 2 ;)
<ogra_> thats a weird statement as runlevel 2 is identical to 3-5 in debian and ubuntu :)
<xranby> oneric: can you tell which install image you used and which instructions you followed to prepare your sd card?
<sveinse> "on stopped rc" to use more upstart lingo then
<ogra_> the original issue for having fixrtc was that mountall/fsck freaked out and went into an endless loop when you didnt have an RTC battery (like 99% of the dev boards we support)
<ogra_> that it fixes a wrong RTC setting is just a sideefect
<ogra_> *effect
<oneric> xranby: http://www.omappedia.com/wiki/Prebuilt_ubuntu_binaries
<sveinse> our board just stopped in mid-boot. mountall seemed to hang forever (not fsck)
<ogra_> oneric, http://wiki.ubuntu.com/ARM/OMAP
<ogra_> sveinse, thats weird
<ogra_> mountall itself doesnt even care about timestamps
<ogra_> but it calls fsck which has been fixed since i wrote fixrtc
<ogra_> the loop shouldnt happen at all anymore and fsck should just exit with a warning
<ogra_> (which you dont see due to the splash)
<oneric> i have used this ogra https://wiki.ubuntu.com/ARM/OmapNetbook is correct but restart always configuration system
<ogra_> but in any case if you dont do weird things with your clock, fixrtc should work properly
<oneric> ogra you speak to me?
<ogra_> oneric, start over, i would guess your SD is corrupt somehow
<sveinse> And no or invalid date (including into the future) is the state of the RTC when it comes fresh out of production. If ubuntu is booted on a system with future RTC date, then rootfs is mounted and last mount time is updated with the future, which we're stuck with.
<sveinse> Unless altering kernel params post install then
<oneric> ogra i must reformat SD?
<oneric> i formAT sd like ext3
<ogra_> oneric, just follow the setps from the wiki again
<ogra_> you dont format anything
<oneric> nothing?
<oneric> i only rewrite?
<ogra_> just follow the steps on the wiki, there is no formatting at all involved
<oneric> but i have used 11.10
<xranby> oneric: http://wiki.ubuntu.com/ARM/OMAP use these instructions
<ogra_> right
<oneric> yes
<oneric> no problem with ubuntu 11.10?
<ogra_> nope
<ogra_> has been tested many times and is used by many people
<oneric> but now
<ogra_> just follow http://wiki.ubuntu.com/ARM/OMAP
<oneric> i had format sd ext3
<oneric> can be this a problem?
<xranby> oneric: then you are doing something wrong
<ogra_> and use the instructions for your release
<oneric> xranby now?
<ogra_> just follow the instructions on the wiki
<ogra_> the method there will wipe the ext3 filesystem anyway
<xranby> oneric: for example if your sdcard reader are at /dev/sdX      you should be using the sudo sh -c 'zcat ./ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz |dd bs=4M of=/dev/sdX ; sync'
<oneric> yes yes
<oneric> thanks for help i retry
<oneric> but i moust unmount SD first?
<ogra_> you should, yes
<oneric> ahh
<oneric> i before not unmount,,, can be this a problem?
<shadeslayer> hi,I was wondering, does anyone have instructions on how to setup a ARM VM with qemu?
<sveinse> ogra_ how would you do this in production when the RTC is invalid/has random contents: 1) Boot the system with fixrtc to allow the system to boot, 2) Set the proper date, 3) Remove the fixrtc kernel option
<xranby> oneric: that can cause problems
<infinity> sveinse: Why is (3) required at all?
<sveinse> You see, I'm not too fond of changing critical files during boot, like bootloader setting because it increases the product to fail later
<sveinse> infinity: Because fixrtc ensures that the system clock is the newest of the HW clock or the 'last mount time' from the rootfs.
<ogra_> infinity, because he has users that set their date to 2013
<sveinse> Or the RTC is invalid (future date) from bugus data in production
<ogra_> which on next boot sets the mount time to 2013 ... then if the clock is corrected your mount time is in the future for the next year
<ogra_> so fixrtc will go on to update over and over
<infinity> sveinse: It doesn't actually do that.  But Oli's point is fair.
<sveinse> infinity: I'd like to agree, but I have devices which fails production over this right now
<ogra_> fixrtc indeed functions on the assumption that the last mount time was the install date and is in the past while the clock is updated to a correct date
<infinity> sveinse: Hrm?  I'm looking at the code.  It doesn't pick the "latest", it just sets it to the rootdev's timestamp, full stop.
<oneric> how unmount SD
<sveinse> infinity: yep, that
<oneric> ?
<ogra_> infinity, see bug 947988
<ubot2`> Launchpad bug 947988 in initramfs-tools "fixrtc kernel option always sets system time" [High,Triaged] https://launchpad.net/bugs/947988
<ogra_> i'm about to add that code bit
<oneric> ogra how unmount sd from terminal?
<infinity> ogra_: I think fixrtc should have been named nortc, so it discouraged use in cases other than the one it was written for. :P
<ogra_> heh, feel free to rename it
<ogra_> though i think the check is valid
<ogra_> oneric, sudo umount <path to your SD device>
<ogra_> iirc thats described on the wiki
<sveinse> in our setup the problem is this: 1) our fs image has valid dates when produced, hence "last mount time" is always correct. 2) The RTC may or may not have valid date and/or a date into the future
<infinity> ogra_: The check is reasonable, right up until someone makes a dev board with no rtc that has a default system time of 2020.
<ogra_> heh, who would do that
<oneric> sudo unmount /dev/sdb/ not work
<ogra_> probably people in 2021 ...
<sveinse> The current (before 947988) is not good that either, because it *always* sets the systime from last mount time
<oneric> sudo: unmount: command not found
<infinity> sveinse: But this is a preinstall / factory imaging thing, right?
<ogra_> oneric, read exactly what i typed above
<infinity> sveinse: In your case, you can surely have your installed re-run flash-kernel with a new cmdline as the last step.
<sveinse> infinity: Preinstalled sdcard and then booted in production
<infinity> s/installed/installer/
<infinity> Or is there no "installer", per se?
<infinity> (I assume there's at least something)
<sveinse> No installer. Everything is preinstalled.
<ogra_> you could preseed a late-command in oem-config
<ogra_> (if preseeding would work)
<infinity> If he was using oem-config.
<oneric> ogra you can write command pls?
<infinity> But he did just say "there's no installer".
<ogra_> which remonds me ...
<ogra_> oneric, there is no "n" in umount
<ogra_> well, there is one
<sveinse> We have a oem-config-like system, so we can run something post first-boot
<ogra_> just not in the place you put it
<oneric> sorry
<oneric> :)
<ogra_> sveinse, well, then do that
<ogra_> and remove the fixrtc option
<infinity> sveinse: Right, then it makes sense to use fixrtc on first-boot, and rewrite the cmdline after that.
<sveinse> We are not updating any kernel or initramfs at this stage, so I'd try, for the risk of the product, not to have to mock around with anything related to booting
<infinity> sveinse: I don't see a sane way to make fixrtc guess what it should do.  Either it compares and that's wrong, or it doesn't compare and that's wrong.
<ogra_> you should rewrite it anyway to have a proper root=UUID= entry
<sveinse> I'm considering dropping the use of fixrtc, as is creates more troubles than good, i think
 * ogra_ doesnt think so ... unless someone sets a relly weird date 
<ogra_> but up to you :)
<ogra_> i will add the check anyway
<sveinse> ogra_ you don't want to know: All produced sdcards have the same uuid as this is generated before the card is copied
<infinity> ogra_: Really weird dates are precisely his issue, I think.
<ogra_> oh my
<infinity> ogra_: And I think your check might actually make it strangely worse (or differently broken).
<sveinse> the purpose of the first-boot (oem-config-ish) is to uniquify the product
<ogra_> infinity, well, on the assumption that a user sets the date manually (while ntpdate already set it correctly) to a weird time in the future
<infinity> sveinse: You can set a new UUID during your uniquification process.
<oneric> ogra how can i check for device for my SD?
<oneric> sde1,sde2,sde3?
<ogra_> checl dmesg
<oneric> i must put sde3 or sde?
<sveinse> infinity: yep, exactly
<ogra_> *check
<infinity> ogra_: His issue wasn't about users, it was about the battery-backed RTCs potentially having "weird dates" even before the system is imaged.
<ogra_> infinity, well, the initial start of this discussion was about a user who set a date of 2013
<infinity> ogra_: Which, to be fair, is (way) out of the scope of what fixrtc is meant to deal with.  But yeah, it means your fix will fix the constant re-running, but break that case.
<ogra_> hours ago
<sveinse> Well coming back to our issue at hand: I can't be without some fixrtc in some form as mountall hangs if the RTC date is older than the more correct 'last mount time'
<sveinse> I can't use fixrtc as the RTC date may be into the future, and then 'last mount time' gets updated with the invalid future date
<infinity> sveinse: If Oli makes the comparison fix, I think that's probably correct, in the face of what fixrtc is meant to do, but it does, obviously, fail to fix anything if clocks are in the future.
<ogra_> sveinse, it wont unless your SD write date is even further in the future
<ogra_> as i said several times already
<infinity> sveinse: And, I'm afraid, there's no fix for that.  You can't write something that says "sometimes pick the RTC, and sometimes pick the filesystem, but we can't tell you which without talking to a human or checking a wall clock."
<oneric> ogra: you know LTIB?
<ogra_> oneric, nope
<oneric> i have also another Board IMX53 freescale
<sveinse> infinity: IMHO there is one remedy to all of these issue: Apply Oliver's patch, and then if ubuntu could update 'last mount time' to the system time when umount is called, then that would work I think
<ogra_> oneric, we do have images for imx53 too
<infinity> sveinse: No.
<oneric> it not start
 * ogra_ hasnt tested any mx53 images since i dont own the HW
<infinity> sveinse: Because with Oli's patch, you get the issue that dates set in the future stay in the future forever (or weird pre-imaging RTC dates end up being the true date), which you're arguing you don't want.
<ogra_> the only sane way is use fixrtc with my patch and update the cmdline during sys configuration
<infinity> sveinse: We literally can't fix both issues without human intervention.  Your computer can't know which date is right.  We can either say "pick the biggest one", "pick the smallest one", "always use the RTC" or "always use the filesystem", but we can't mix and match.
<oneric> fist i want start with panda board!
<oneric> ok ogra i have put sd on panda
<sveinse> infinity: No, because assuming the user or NTP changes the system clock while the system is running, hwclock-save will save the correct time into the RTC. If umount also wrote the system time into 'last mount time', then the system would start correctly the next time even with fixrtc
<oneric> board
<oneric> and it start with ubuntu
<infinity> sveinse: Oh, I see what you're saying.  So, even if it's incorrect on one boot, you want it to be forced correct for subsequent ones by rewriting the last mount time.  That solves all but the "RTC is wrong" problem, I guess.
<ogra_> right, we did have that in the past (a hwclock init script on shutdown)
<infinity> sveinse: Of course, it also becomes a complete lie then, and breaks long-running systems.
<sveinse> Yes. If RTC is wrong, then its wrong. Either user or NTP can correct that
<infinity> sveinse: (Last mounted is *meant* to be last-mounted, not "last-touched")
<ogra_> and as i said before, fixrtc was written for the usecase where you actually install ubuntu
<infinity> sveinse: If you have a system up for 400 days, the last-mount time should be 400 days ago, not "Just now, because I rebooted".  If we update it that way, timed fscks never happen.
<ogra_> the time drift you have then wont be big
<oneric> ogra i entered on ubuntu and now i'msetting system configuration
<sveinse> infinity: I totally agree. It's just that we assume in fixrtc that the written timestamp is correct, which it may not.
<ogra_> oneric, did it do the resizing and one reboot properly ?
<infinity> sveinse: No real fix for that.  Like I said, we should probably rename fixrtc to nortc, so people use it for what it was intended, a best-approximation of having no battery-backed RTC. :P
<oneric> resizing?
<ogra_> sveinse, right, as i saidm, it was written for our images where a user installs them manually
<sveinse> I agree that this isn't neccessarily a fix for every ubuntu system out there (the shudown last mount thing)
<ogra_> oneric, yes, the image resizes itself to the full size of the SD and then reboots
<sveinse> I'm considering doing a remount on rootfs on these special occations
<infinity> sveinse: The shutdown last-mount thing is just plain wrong.  It's overloading last-mount to now be a timekeeping service, and breaks its actual intended use.
<sveinse> agree
<oneric> i dont know, now ubuntu is installing keyboard configuration
<infinity> sveinse: Now, doing that on your own images, say, on a product that never does times fscks anyway (and has that set to -1), then go nuts. ;)
<infinity> s/times/timed/
<ogra_> oneric, well, did it reboot once before you got into the setup program ?
<ogra_> else your system may not function correctly
<sveinse> infinity: That's another good point. The image is valid prior to the first boot. Then the RTC is wrong and 'last mount time' is set into the future. Now the image will never be checked (except for mount counts) until this future time is met...
<sveinse> OOI does desktop linux behave the same way? I.e. won't do a full start unless the hw clock is newer than the 'last mount time' ?
<infinity> "desktop linux"?
<infinity> Making Ubuntu what, exactly? :)
<sveinse> natty amd64 using gnome ;)
<infinity> amd64 and armel are no different in that regard.
<oneric> ogra
<infinity> Or in any regard, really.
<oneric> ogra: it work
<oneric> thanks
<oneric> many thanks!
<sveinse> that intersting, because this is the first time I've actually had to struggle with clock settings
<GrueMaster> sveinse: For a test, I took a panda daily image, removed the "fixrtc" from the commandline, and booted with no networking.  The system came up with 1989, which is still more valid than 1970, and it booted through oem config into unity with minor issues (background mainly).
<infinity> Because your amd64 system has a battery-backed-rtc and doesn't use 'fixrtc' on the command line.
<infinity> If an intel/powerpc/whatever system suddenly finds itself in 1970, you have exactly the same problems.  Now, as GrueMaster points out, this has been reduced from errors to warnings in precise.
<sveinse> Our HW system don't work without fixrtc. We're running natty and mountall simply hangs duing boot if the RTC time is less than the last mount time from the rootfs
<infinity> (And possibly oneiric?)
<infinity> sveinse: Yes, this is fixed in newer releases.
<sveinse> That is perhaps and probably a bug, but we haven't time to fix that
<infinity> It occurs to me that natty is EOL, and this discussing (from an Ubuntu perspective) is somewhat moot as a result.
<infinity> Cause we can't "fix it" for you, even if we want to.
<infinity> ie: we can no longer upload to the archive. :P
<infinity> Oh, wait.  No.
<infinity> I can't count.
<infinity> But it's almost EOL! ;)
<oneric> someone know LTIB?
<ogra_> GrueMaster, well, the issue is that he isnt using a panda and that his systems can have really really weird clock settings apparently :)
<sveinse> I'm not asking for a fix either, just advice
 * ogra_ thought we gave the right advice already
<ogra_> use fixrtc on first boot, remove it from the cmdline after system configuration
<infinity> sveinse: My advice would be, perhaps, to install a small shutdown script that does your hackish "set last-mount stamp on shutdown", and combine that with ogra's patch.
<GrueMaster> What type of system?  I'm assuming arm based (otherwise the conversation should be somewhere else).
<infinity> sveinse: But do that if (and ONLY if) you also aren't doing timed fscks.
<ogra_> GrueMaster, no idea :) but yeah, likely arm based since we are in #ubuntu-arm
<oneric> i have freescale imx53
<oneric> but i have problem with ltib
<oneric> i want install ubuntu on my imx53
<infinity> sveinse: And yeah, "use it only on first boot" is also a perfectly valid option.
<infinity> sveinse: I tihnk the paranoia that end users might screw up their RTC is sort of out of your domain.
<sveinse> GrueMaster: omap3 devices. Custom HW for custom application
<GrueMaster> What about preloading the rtc with a semi-sane time from u-boot?  Like the u-boot build timestamp?
<infinity> GrueMaster: This is a battery-backed RTC, it shouldn't need preloading at all.
<ogra_> aww, dont bring more variables into the discussion !
<GrueMaster> This way, your rtc is always in the past, but reasonablly close.
<infinity> GrueMaster: His complaint is that it might be wrong on first boot, not that it will be wrong forever.
<sveinse> infinity: It certainly is. My concern is that production works, not if uses is capable of setting the correct date!
<ogra_> GrueMaster, the prob is that you would have to have u-boot to only do it once
<GrueMaster> infinity: I have x86 systems that have had failing rtc batteries.  I don't rely on that always.
<infinity> GrueMaster: Yes, but resetting the date on every boot when it may have already been correct (and now you've just made it incorrect) is a bit odd too. ;)
 * sveinse is grateful for advice from ogra_ and infinity
<ogra_> and we happily give it :)
<infinity> sveinse: I honestly see no One True Solution to any of this.  fixrtc + running ntpdate as early as possible gets you past most of the big hiccups, though.
<infinity> sveinse: And, at the end of the day, who cares if your last-mount time is incorrect forever?
<infinity> sveinse: I mean, it matters if you're using that feature, but given your willingness to overwrite the date with bogus values, you're obviously not. ;)
<ogra_> it wont be once your rtc is right, fixrtc is gone and you reboot :)
<suihkulokki> fixrtc and running ntpdate before mounting root partition read-write would be quite bulletproof (assuming available network)
<ogra_> suihkulokki, right, and it falls with that assumption :)
<infinity> ogra_: Yes, running once feels right to me, but then he's paranoid about users setting their clocks incorrectly later, and wants to force-fix it again.
<ogra_> yep
<sveinse> infinity: I have never cared about last mount time until mountall stopped working! When the RTC always is newer than the FS, I really don't care about last mount time
<infinity> suihkulokki: There'd be a lot of early boot mangling to do for him to rethink things and bring up the network in time for an initramfs-based ntpdate, I imagine.
<ogra_> mountall not working is worth a bug btw ...
<suihkulokki> otoh if you don't have network, your sense of "real time" is kinda lost
<ogra_> in case i didnt mention that yet :)
<infinity> suihkulokki: Unless he's already booting via a method that gives him a ghetto network (ie: bootp/tftp)
<ogra_> suihkulokki, exactly ... and thats what fixrtc is for
<sveinse> ogra_, I'll do that when I've untied the flock in production
<ogra_> in its current state it just forces the clock to last mount time of the disk
<ogra_> sveinse, thanks !
<ogra_> under the assumption that you used an ubuntu image and wrote it to the disk at some point ... to make sure your RTC isnt set to the epoch... nothing more
<ogra_> (indeed that also fails if the machine you wrote it on has no rtc .... *g*)
<infinity> ogra_: No it doesn't...
<sveinse> ogra_, ubuntu image = debootstrapped ubuntu-minimal with our custom kernel on top? Does that count?
<infinity> ogra_: The last-mount time is from the buildds.
<ogra_> infinity, is it ?
<ogra_> oh, right, it is the filesystem we look at
<infinity> ogra_: Well, unless you make a habit of mounting your SD cards after you zcat/dd them, I don't.
<ogra_> not the device
<ogra_> yeah
<ogra_> i was thinking device ... i usually mount them though to make surer the dd worked fine :)
<oneric> someone can help me pls?
<ogra_> but i'm special and paranoid in that regard
<infinity> oneric: I'm not sure what you need help with.  You said you have an i.MX53 (Quickstart, I assume?), and you want to play with Ubuntu on it?  We have an "mx5" image, and instructions on how to boot it.
<infinity> oneric: https://wiki.ubuntu.com/ARM/MX5
<sveinse> Please let me get this straight: If fixrtc isn't used, the system wont start (in fact mountall hangs, but that's a bug) if the RTC time is older than the FS. If fixrtc is used the system will always start, but the user can never set the time backwards.
<ogra_> only with my recent fix
<ogra_> else you will end up in the condition you had before we discdussed the fix
<sveinse> Altering 'last mount time' may have sideeffects in respect of time based disk checking
<sveinse> yes
<sveinse> I foreseeing that customer services won't be happy because there will be at least one customer which happens to set the wrong date into the future. Neither options are a solution :(
<sveinse> Well, I'm repeating myself. Thanks all for your considerations
<sveinse> I have to think about this. It's apparently not straight forward
<sveinse> when will support for natty be dropped?
<ogra_> in 12 months
<ogra_> all arm releases we had up to now are 18months supported
<ogra_> err, in less than 12 actually
<ogra_> 7 or so
<GrueMaster> Natty will drop off shortly after 12.10 release.
<GrueMaster> November time frame.
<sveinse> As an end-user mfg, we are ultimately responsible for the product we ship. We have a full natty mirror which we froze some time ago to run QA on the system.
<sveinse> The product will be supported by us well beyond when natty is dropped by ubuntu
<ogra_> ouch
<ogra_> that will surely leave you with security holes at some point
<ogra_> unless you backport all CVEs yourself to your mirror
<GrueMaster> sveinse: What is your targeted release date?
<sveinse> Q2, but we are ramping up production now
<GrueMaster> Ouch.  So too late to update to at least Oneiric.
<sveinse> oh, indeed. that's why I'm bothing with natty
<sveinse> Well I have to leave. Thanks all, esp. ogra_ and infinity
<GrueMaster> Will they be field upgradeable?  It isn't too painful to do a kind of firmware reflash a few months after the first production iteration.
<ogra_> enjoy your evening
<GrueMaster> Have a good evening.
<sveinse> GrueMaster: Yes. It's sdcard based. Upgrade is in fact apt-get dist-upgrade.... One of the huge benefits from using debs in a system
<GrueMaster> Ok, so it isn't going to be locked down.  That is good.  Otherwise I would have suggested that once you get this natty based image frozen, start working on a precise image for release mid-late Q3.
<ogra_> you still need an oneiric one ... else you have no upgrade path
<GrueMaster> ogra_: I don't know the project or the design.  I was thinking along the lines of a complete system upgrade, treating the image as a contained firmware set.
<GrueMaster> But open upgradeable is better.
<danboid> I've installed last nights omap4 amhf 12.04 server and the nic isn't working on my pandaboard
<danboid> Any other panda users here having this prob or not?
<danboid> 'usb start' in u-boot sees my network port OK
<GrueMaster> danboid: I haven't tried it yet.  Give me 20 minutes and I can check.
<danboid> GrueMaster, OK, thanks
<danboid> bbl
<AbuDawud> I have a Transformer Prime running Ubuntu 9.10. I'd like to try and get it up to current release but when attempting a distribution upgrade I am getting repo errors for Lucid.
<AbuDawud> Is there a repo I should add before attempting to upgrade the distribution or am I stuck on Karmic for the time being
<AbuDawud> The errors are "W:Failed to fetch http://archive.ubuntu.com/ubuntu/dists/lucid/main/binary-armel/Packages.gz
<GrueMaster> AbuDawud: You are getting repo errors on Armel Lucid?  What kind of errors?
<AbuDawud> it appears the directories for armel do not exist there
<GrueMaster> Ah.  If this is armel, you need ports.ubuntu.com/ubuntu-ports.
<AbuDawud> GrueMaster: Trying that, thanks
<AbuDawud> GrueMaster: should the line be 'deb http://ports.ubuntu.com/ubuntu-ports karmic non-free' ?
<GrueMaster> I use "deb http://ports/ubuntu.com/ubuntu-ports main restricted multiverse universe".  That should get you everything except ppa's and private repos.
<GrueMaster> Oops.  Add "karmic" before main.
<AbuDawud> hm, I guess I have to let my stupidity show a bit, the oldest dist there is lucid, if I am moving from old-releases to ports how to I do that?
<GrueMaster> "do-release-upgrade" ?
<AbuDawud> what I'm saying is I'm transitioning from archive.ubuntu.com to ports.ubuntu.com, if I add the ports repo it still throws an error about not finding the archive repo when attempting to upgrade
<GrueMaster> Hmm.  I'm really not sure what to tell you.  Even Lucid is no longer really supported on arm, it just floats along with the LTS on x86.
<GrueMaster> And I don't ever remember arm being available on archive.u.c.
<AbuDawud> for lucid its not, it stops at karmic -.-
<GrueMaster> Try setting the apt sources to "deb http://ports.ubuntu.com/ubuntu-ports lucid main restricted multiverse universe", then "apt-get update" followed by do-release-upgrade.
<GrueMaster> I meant, I don't remember arm EVER being on anything but ports.ubuntu.com.
<AbuDawud> GrueMaster: looks like thats working, oh well not enough disk space, new problem!
<AbuDawud> thanks though
<GrueMaster> Can't help there, sorry.  :P
<AbuDawud> it looks like its trying to write to the device root instead of the chroot I assigned, man I suck at this
<shadeslayer> Hi, I don't suppose someone could point me to a precise arm kernel that I could use with qemubuilder?
<GrueMaster> shadeslayer: Try the omap kernel.
<GrueMaster> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-3.2.0-18-omap_3.2.0-18.28_armhf.deb
<shadeslayer> GrueMaster: sure, but where is it? Inside this : http://cdimage.ubuntu.com/daily-preinstalled/current/precise-preinstalled-desktop-armhf+omap4.img.gz ?
<shadeslayer> okay
<shadeslayer> uhh
<shadeslayer> GrueMaster: I need a vmlinuz
<GrueMaster> download the deb, run "dpkg -x linux-image-3.2.0-18-omap_3.2.0-18.28_armhf.deb ." and you will have one in ./boot.
<shadeslayer> aha
<shadeslayer> GrueMaster: thanks!
 * prpplague grumbles about the "issues" with firefox on his desktop ubuntu installation after doing an upgrade
<GrueMaster> prpplague: Do you know much about the beagleXM, rev b in particular?
<rcn-ee> just an es core bump over the rev a. ;)
<prpplague> GrueMaster: just general info, i wasn't on the team for that
<GrueMaster> Hmmm.  I'm seeing an issue with the nic not detecting link unless I physically unplug and plug in.
<GrueMaster> Our kernel dev has a Rev A & Rev C, and claims they just work.
<GrueMaster> Ok, nic just sprouted to life.  System was idle at the desktop for ~10 minutes.  Seems like it isn't getting enough power or something.
<rcn-ee> GrueMaster, one of my xM B's does that every once in a while.. seemed kernel dependent..  rmmod smsc95xx /modprobe smsc95xx always seemed to bring it back..
<GrueMaster> interesting.
<GrueMaster> Well, it has been like this since beginning Oneiric.  Odd that it only happens all the time on mine.
<GrueMaster> Fully reproducible.
<GrueMaster> I also found that if I compile smsc95xx into the kernel (instead of as a module), it works consistently.
<GrueMaster> And the Angstrom test image works of course.
<rcn-ee> btw, they are also touching the power rails for smartreflex 1.5, so it could be a power sideeffect..
<GrueMaster> Yea, it feels like a low power issue.  Like a capacitor isn't charging or something.
<ogra_> shadeslayer, http://ports.ubuntu.com/dists/precise/main/installer-armel/current/images/ has a plain kernel
<ogra_> http://ports.ubuntu.com/dists/precise/main/installer-armel/current/images/omap/cdrom/ actually
<shadeslayer> cool! But I already ran qemubuilder, so ... :)
<ogra_> heh, k
 * prpplague grumbles
<prpplague> GrueMaster: after i did an upgrade last week my desktop is acting totally funky
<prpplague> GrueMaster: i think we should just blame ogra_
<ogra_> prpplague, yeah, sorry, i wasnt cautious and broke it ... will fix it with the next update you run :P
<prpplague> hehe
<ogra_> :)
 * prpplague had a cow when looking at travel prices for the next linaro connect
<newtony2> so ummm i need python on and iphone... ummm i found a git but i dont know anything about git... any help?
<infinity> newtony2: That's really way out of scope for this channel.
<newtony2> oh well iphone is an arm processor
<infinity> Is your iPhone running Ubuntu?
<lilstevie> newtony2, you would be better off asking in a iPhone room
<lilstevie> there is python stuff on cydia
<newtony2> kewl thx
#ubuntu-arm 2012-03-07
<janimo`> infinity, one way of solving the ghc issue is by not touching ghc at all, instead making llvm default to float-abi=hard on armhf. I don't know what the downside of that is, besides being Ubuntu specific change
<janimo`> llvm's llc being a cross-compiler always - native being a particular subset - maybe it is good to always have explicit flags for almost everythinh
<micahg> janimo`: you can ask Sylvestre from Debian
<janimo`> micahg, ok thanks
<micahg> janimo`: also, I have another Chromium upload today, so let's hope armhf builds this time
<janimo`> micahg, oh nice, let's hope it does :)
<suihkulokki> This would be nice to get to precise: http://sourceware.org/ml/libc-ports/2012-02/msg00079.html
<micahg> https://launchpad.net/ubuntu/+source/chromium-browser/17.0.963.66~r124982-0ubuntu1/+build/3265949 will be the entertainment for this morning :)
<sveinse> ogra_, infinity : What /is/ the expected behavior on Ubuntu (in general) if the RTC clock has been reset (due to empty battery etc.)?
<ogra_> sveinse, i belive there are various userspace apps that will have issues once you drop back to the epoch
<ogra_> but i cant tell for sure ...
<ogra_> what i know is that for example gdm has probs with autologin once the epoch kicks in, but since we switched to lightdm thats not an issue anymore for us (and i doubt anyone will look into it with much motivation, now that gdm is in universe)
<sveinse> ogra_, I mean, is it expected that the system should start up normally?
<sveinse> E.g. since there was a need for fixrtc in the first place, I mean
<ogra_> no idea, really, i havent tried it .... and on i.e. the pandaboatd the "epoch" was picked by TI and defaults to 1990 ... so we wouldnt have these issues there at all
<ogra_> fixrtc stems from a time where there was a bug in fsck
<ogra_> that bug was fixed post lucid, but we kept fixrtc for the potentially broken userspace issues
<ogra_> its just still around for historical reasons
<ogra_> the initial bug that caused its existance is long gone
<sveinse> yeah, so my mountall (perhaps fsck) lockup is worth investigating -- even on natty
<ogra_> right
<ogra_> though i doubt anyone will invest time into natty unlerss someone sends a patch that can be easily included
<ogra_> simply because its EOL so soon
<sveinse> yes, because the reason I'm bringing this up, is that we have been running with protoypes for over a year now. And we've never seen this lockup before. I can't honestly belive that all of these units have had valid rtc contents.
<sveinse> So it could be a fsck-kernel regression of sorts.
<sveinse> I'll take a look at it since we have to fix it anyways. I'll keep you in the loop
<sveinse> While I'm at it: Our hw is headless, we just have a serial console. Yet I see mountall connecting to plymouth. How can I direct the output (like from fsck) from plymouth out on /dev/ttyO2 ?
<ogra_> you should be able to use the text theme, it should just display on the default console you set on the kernel cmdline
<sveinse> thanks
<ogra_> if that doesnt work, ask the guys in #ubuntu-server, they definitely have experience with headless servers that run fsck on serial
<janimo`> Laney, for ghc I assume you want a clean and properly upstreamable patch for armhf ftbfs not just any fix until upstream fixes it?
<Laney> janimo`: I don't know how long the upstreamable patch would take. I'm quite keen to get it fixed in the distro ASAP so if we need to do it in two stages then that's OK with me.
<Laney> I tried some stuff including using cpp on the Debian porterbox but nothing has stuck yet
<Laney> and the builds take so long which makes it quite frustrating
<janimo`> Laney, worst case is put a sed in debian/rules, guarded by ifdef armhf :)
<Laney> yeah
<janimo`> to append -float-abi=hard in that one .hs file.
<janimo`> evil but matches your ASAP requierement
<janimo`> I looked at what it takes to make it proper(er)
<janimo`> and it needs changes across many haskell files
<Laney> I don't mind that. Or you could have a .patch that is applied and unapplied conditionally
<janimo`> Laney, wait I keep forgetting to ask this. Is there support for debian/patches/foobar.patch.armhf ?
<janimo`> if so, much cleaner than running sed :)
<janimo`> apply a single line patch if armhf
<Laney> no(t that I know of)
<janimo`> ah, shame
<Laney> it would be ifeq(armhf,$(DEB_HOST_ARCH))\n\tpatch ...
<janimo`> and that patch would not be listed in series?
<Laney> indeed, managed separately
<Laney> it's not that nice but it makes the separation cleaner
<Laney> don't know if it's worth it
<janimo`> not vastly cleaner than a search and replace then
<janimo`> true. A bit more declarative
<Laney> anyway this issue blocks the large transition so the sooner it is resolved the better imho
<janimo`> Laney, the sooner is calling sed then. Or I can try coming up with a patch - which if not what upstream would make it is still a patch.
<janimo`> sed would unblock the transition
<janimo`> and we could work on an upstreamable fix in the meantime
<Laney> OK, go for that then
<janimo`> Should I try this an dupload in Ubuntu?
<Laney> yeah, if you're confident it will work
<Laney> i.e. if you don't feel the need to test build on the porterbox
<janimo`> Laney, I test on my panda first just to be sure
<Laney> ok
<janimo`> Laney, I see sed is no stranger to debian/rules in ghc, called a few times already
<infinity> janimo`: Just make sure whatever you do is also undone in the clean target, on the off chance that someone builds the source on an armhf box.
<janimo`> infinity, good point wrt undoing. Not sure I understand what happens though if it is built on an armhf box?
<infinity> janimo`: If you build the source (ie: debuild -S) on an armhf box, the patched bits would stay patched and never get unpatched on, say, armel.
<infinity> janimo`: Hence why clean needs to undo whatever you do.
<janimo`> infinity, if I debuild -S on x86 before uploading is this still an issue in this particular case?
<infinity> janimo`: Not if you never touched it on armhf in that source tree.
<infinity> janimo`: (ie: if the sed/patch never ran, then building the source on x86 would work around debian/rules being incorrect)
<infinity> janimo`: Still, clean should always return you to a pristine source, that's kinda the point. ;)
<infinity> (Not that there aren't plenty of broken source packages for which this isn't true)
<janimo`> infinity, ok. I know clean should clean up, just forgot when I explciitly need to do something about it
<infinity> janimo`: Always. :P
<janimo`> if I upload this change - which is not yet certain, depending on result on panda - it hopefully is a very shortlived hack, just to get other package sunblocked
<infinity> janimo`: But I haven't looked at ghc's debian/rules, it could be a lost cause anyway.  If it's seding the source elsewhere, odds are the clean target's already wrong.
<infinity> (Unless clean very carefully reverses every single one of those)
<janimo`> infinity, it is sedding ony in debian/tmp - that is less evil I guess. various install time changes in .desktop files and such from what I saw
<infinity> Ahh, yeah, that's fine.
<infinity> Since clean will wipe out debian/tmp anyway.
<infinity> Really, the best way to go, if it's a quiltish package, is just to have a patch, but don't have it in the series.
<infinity> And just patch manually iff armhf, and unconditionally (ignoring errors) unpatch in clean.
<janimo`> nah, luckily sedding instead of patching is not a widespread habit. I am not advocating it either, but the cost of coming up in short time with a patch spanning multiple haskell fiels and horrid M4 code seems a bit higher now
<infinity> Heh.
<janimo`> it is 3.0 so I think quiltish
<infinity> Fair enough. ;)
<janimo`> only patching via vi is nastier (chort tied to testicles, etc)
<janimo`> chord
<infinity> No one's stopping you from rgrep | xargs sed && dpkg-source --commit && remove from series.
<infinity> Ish.
<infinity> But anyhow, as you note, it's a short-term hack, doesn't matter deeply.
<infinity> And I guess the real fix needs ghc to take configure flags for float-abi, so it's not just always doing the one (wrong or right, depending) thing for armv7?
<infinity> fpc needs similar pain applied.
<janimo`> right, the real fix would be - AFAICT - adding code to aclocal.m4 to pass a new flag to the build depending on _VFP_ABI (whatever is's called)
<janimo`> and that flag being added in the haskell sources and one of the ARM Arch parameters
<janimo`> or hmm, maybe a configure flag would be indeed easier than changing m4 - did not look at what exaclty that build system does
<janimo`> but still unless the patch to haskell is a hack and piggybacks floatabi flag of AR ISA extensions (such as NEON, VFP) where it does not logically belong
<janimo`> it means quite more than an oneliner in .hs files
<janimo`> every pattern match on ArchARM changed to carry one more param, even if unused in all cases
<janimo`> so I am not very encouraged to come up with a patch knowing almost for certain it should be rethought/rewritten to match upstream's taste and future plans in this area
<infinity> janimo`: Assuming upstream cares at all about the distinction, yeah.
<infinity> janimo`: Many upstream don't seem to.
<janimo`> they have flags for NEON, VFP, VFPD16, preV7 ARM, preV6 ARM. I assume they care :)
<janimo`> which reminds me, I should ping llvm debian maintainer. All this hassle would be avoided if llc just defaulted to hardfloat if called on a hardfloat system.
<janimo`> at the cost of tripping up if crossbuilt from armel sometimes
<janimo`> I wonder if llvm should have different defaults as gcc does in our default installs
<infinity> Probably, but I'm not terribly familiar with how llvm internals work.
<infinity> Individual packages clearly shouldn't have to know or care about what flags they're building with, though.  The toolchain should default to something sane.
<janimo`> micahg, at least chromium did not fail with V8/HARD flag missing this time. gles/egl missing is at least known territory
<ogra_> did it fail again ?
<ogra_> bah
<kalikiana> would it make sense to assume libgles2-mesa-dev [armel] is why it fails?
<kalikiana> ie. use armhf
<kalikiana> I'm not so versed on multi-arch, though
<janimo`> kalikiana, that is exactly why it probably fails indeed
<janimo`> I know I saw that before, not sure why I did not correct it then
<orated> Hello!
<orated> Can anyone  suggest a good board/general resources to start on ARM?
<GrueMaster> Several, depending on budget and what you want to accomplish.  beagleboard.org has decent boards that are supported by Ubuntu, as does pandaboard.org.  Also, Freescale has a similar platform called the Quickstart.
<GrueMaster> All three are fully supported by Ubuntu with images.  Any armv7 platform will run the Ubuntu software load as well, provided you can find a kernel.
<orated> I went through the freescale, what's the difference between all the above you said and reaspberry pi?
<GrueMaster> Main difference:  We don't support the Raspberry PI due to architecture differences (it is not armv7 and would require a top-down rebuild of our arm pool - ~15k packages).
<GrueMaster> We just don't currently have the resources.
<MRSL> Hello. I'm new to Linux and trying to change the mux values in mux.c and mux44xx.c so the expansion ports J3 and J6 on the pandaboard will read GPIO rather than the standard setup. I haven't been able to figure out how to do this. I was in the pandaboard forum and they suggested I come over here for instructions. They said to start by getting a working build environment, but I don't actually know how to do that, as my Linux experien
<orated> GrueMaster:  Well, thanks for the input. I'll find about the other two manufacturer you said
<GrueMaster> beagleboard.org has three different platforms (and three different price points).  Panda is overall the best for most desktop usages (dual core, video acceleration (closed source), BT, wifi & ethernet).
<GrueMaster> Freescale has native SATA.
<GrueMaster> So it really depends on what you want to use it for.
<MRSL> can anyone help me, or point me to where I can get help?
<GrueMaster> It depends on the type of help.  irc is a really big place.
<MRSL> help with changing the the mux setup on linux on the pandaboard.
<MRSL> the pandaboard irc sent me over here
 * GrueMaster goes to look at the pandaboard backscroll.
<GrueMaster> MRSL: Best info I can give you is this:  https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
<GrueMaster> As to gpio manipulation, that is #pandaboard.
<MRSL> okay, thanks
<GrueMaster> You can use your panda to recompile the kernel, but it can take a few hours.  Cross-compiling on my Core2Quad takes ~20 minutes.
<MRSL> how do you cross-compile?
<GrueMaster> Sorry I can't help much more than that.  For Ubuntu kernel specific questions, you might get more help on #ubuntu-kernel.  We can help with the arm environment here.  I know it is a PITA to bounce around IRC like this.
<GrueMaster> The wiki pointer I gave you has specific instructions for the omap4 kernel cross-compile near the bottom.
<MRSL> alright thanks, I'll head there. And, its better than before, when I was absolutely stuck
<GrueMaster> What are you running on your desktop?
<MRSL> Currently the board is running on its own. Ubuntu 10.4 runs on the desktop that I used to originally boot the board
<GrueMaster> One way to get a working cross-compile environment on your desktop is to download http://cdimage.ubuntu.com/ubuntu-core/daily/current/precise-core-i386.tar.gz and use it as a chroot.  That's what I am doing (and I also have Lucid on my desktop).
<MRSL> Okay. On a side note, using the command from the wiki page to get the source gives an error saying that 'You muust put some 'source' URIs in your sources.list'. Do you know what that means?
<GrueMaster> Yes.  You will need to edit /etc/apt/sources.list.  The easiest thing is to copy the lines that start with "deb " and change the copies to "deb-src".
<GrueMaster> Then run "sudo apt-get update"
<MRSL> where is /ect? I tried to access the file and it says the directory doesn't exist.
<GrueMaster>  /etc not /ect.
<MRSL> Bugger. Now I feel thick. Yay for sleep depravation!!!
<GrueMaster> Heh.
<anuvrat> hi
<anuvrat> I am trying to create a custom root fs .. for FriendlyARM Tiny 6410 ... and facing kernel panic ... any direction on where to look will be very helpful
<GrueMaster> Is it based on ubuntu?
<MRSL> Alright, it started to download the source. so thanks again.
<anuvrat> had run the ubuntu image, but given the limited capabilities of the board ubuntu was very slow ... so I was trying to get the simplest setup
<anuvrat> GrueMaster: had run the ubuntu image, but given the limited capabilities of the board ubuntu was very slow ... so I was trying to get the simplest setup
<anuvrat> GrueMaster: is there a way to strip the gui from ubuntu arm ... I mean strip it to tis bare skeleton ... so that my low end board would be able to use it
<GrueMaster> if it is at least armv7, you can use the ubuntu-core image as a start for your rootfs.
<GrueMaster> Or you could use an ubuntu-server image.  They are headless and will even run on a Beagle C4.
<anuvrat> GrueMaster: okay, thanks
<anuvrat> GrueMaster: its arm 11
<anuvrat> http://www.friendlyarm.net/products/tiny6410
<GrueMaster> Ouch.  We don't support anything lower than armv7 in our images.  All binaries are built for this.
<anuvrat> GrueMaster: so I start by downloading the ubuntu-core image
<GrueMaster> It won't run on arm 11.
<anuvrat> so v7 is higher than arm 11
<anuvrat> confusing arithmetic :P ... okay ... anyways .. any workarounds?
<GrueMaster> Arm 11 is armv6 (iirc) architecture.  Arm numbers were very confusing in the past.
<GrueMaster> And no, we can't work around this without a complete rebuild.
<GrueMaster> Won't happen any time soon.  Not enough resources to rebuild & retest.  We are having a hard enough time fixing all the broken packages for our current builds.
<anuvrat> What I have been trying to do is get a system up with just busybox ... and my aim is to run python on the board and be able to use usb dongles for wifi and bluetooth on it
<anuvrat> GrueMaster, any directions on how I should proceed
<GrueMaster> You will probably want to use debian for binary packages.  We simply can't help here.  Beyond that, I have no suggestions.
<anuvrat> Would it be completely crazy to try and build everything from source ... or would such an action drive me crazy via kernel panics ... what do you suggest?
<anuvrat> GrueMaster:
<GrueMaster> If you were to rebuild from source, again you would have to use something like Debian as our source is set to build armel & armhf, both of which are defined as armv7 in our build tools.
<GrueMaster> And at this point you are no longer using ubuntu.  Which is why I suggested debian.
<anuvrat> GrueMaster: where on debian's site exactly do I go looking for its arm port ? I apologize if the intellectual standard of the questions is low ...
<GrueMaster> I don't know.  Try asking in #debian.
<xranby_ac100> anuvrat: if you want a minimal embedded system you should consider using openembedded
<xranby_ac100> anuvrat: if you want to use ubuntu try ubuntu-core
<xranby_ac100> ... friendly arm thats armv5 right?
<GrueMaster> xranby_ac100: ubuntu-core is armv7 only.
<smplman> anuvrat: i installed ubuntu from http://elinux.org/BeagleBoardUbuntu . I then install x11 and use ~/.xinitrc to launch my app when i startx
<xranby_ac100> anuvrat: which friendlyarm board do you got?
<xranby_ac100> i notice that some of their boards are based on a cortex-a8
<xranby_ac100> like the http://www.friendlyarm.net/products/tiny210 this board can run ubuntu-core
<smplman> i know on my xm the precise images boot to initramfs, havent had time to debug yet
<smplman> xranby_ac100: looks like similar hardware specs to the beagle xm
<anuvrat> xranby_ac100: smplman, GrueMaster I have FriendlyARM Tiny 6410 http://www.friendlyarm.net/products/tiny6410
<micahg> janimo`: seems that one of the build-deps of armel only, that should be [armel armhf] as kalikiana pointed out to me, I'll fix for the next upload
#ubuntu-arm 2012-03-08
<bmw> Hello. i have a problem with chromium 17 on armhf. Maybe you know why http://code.google.com/p/chromium/wiki/LinuxPidNamespaceSupport don't work with SUID bit (clone(child_stack=0xbed6345c, flags=0x20000000) = -1 EPERM (Operation not permitted))? I try disable apparmor but have no result.
<anuvrat> hi
<anuvrat> can someone please tell me the meaning of the value of the root parameter passed as kernel parameters Linux-CommandLine = root=ubi0:FriendlyARM-root ubi.mtd=2 rootfstype=ext3 init=/linuxrc console=ttySAC0,115200
<ogra_> anuvrat, where does that come from ? we definitely never used something like that in any ubuntu images
<ogra_> you should better ask the provider of your image about it ;)
<anuvrat> ogra_: okay
<damian0815> hey alls. quick question, i think it's arm-hardfloat related. i'm getting a segfault in sincosf() (/lib/amr-linux-gnueabi/libm.so.6), any way i can debug this?
<damian0815> this is from a user land app, i'm compiling it with -mfloat-abi=hard -mfpu=vfp. ubuntu 11.10
<damian0815> i had to manually install libc6-dev-armhf or g++ complained about missing features.
<Laney> janimo`: how did your build go?
<janimo`> Laney, had to restart it because of stuck panda
<janimo`> so will only have a result later tonigh
<Laney> ok
<ogra_> you didnt feed it enough bamboo ?
<janimo`> enought bamboo but not enough swap
<janimo`> this is a weird panda
<ogra_> with pink spots etc ?
<janimo`> I would not mind having a quad core arm with at least 2GB of RAM
<ogra_> ++
<janimo`> for 'special' packages like this one
 * Laney abused harris.d.o with it a few times :-)
<ogra_> janimo`, well, talk to NCommander if you can help him with doing a stresstest on his magic board ;)
<janimo`> I thought those magic boards were all tied up in stress tests already for server loads
<ogra_> just call it a "build performance" test ;)
<janimo`> and I was not sure they're all that stable either
<ogra_> well, for checking if your build survives a certain point it should be good enough
<janimo`> NCommander, well certain point being 10 hr in the build on a panda :)
<ogra_> that should be 5h on a double fast board :)
<janimo`> NCommander, that was not directed at you. What is directed at you however is if you have such a board available and open to select individuals of good nature like myslef I could from time to time throw large packages at it to build
<GrueMaster> janimo`: He may have one board of such nature here, but I am the gatekeeper.  :)
<GrueMaster> What are you trying to build?
<ogra_> chromium testbuilds
<GrueMaster> Ewww,
<infinity> I thought he was mangling ghc?
<ogra_> oh, i thought chromium ... well whatever :)
<GrueMaster> infinity: bacula works properly now, thanks.
 * GrueMaster wonders how many other apps are broken.
<ogra_> pfft, backups are so overrated
<GrueMaster> Yea, I noticed.  The server use-case survey listed them as 4th highest usage model.
<ogra_> pfft
 * ogra_ wonders why he still sees linux-fsl-imx51 uploads 
<ogra_> i thought we got rid of that crap now
<GrueMaster> It will haunt me forever.
<ogra_> well, did nobody tell them we dont use the HW anymore ?
<ogra_> probably we should :)
<GrueMaster> I still use it.
<GrueMaster> Admittedly, only to test their updates.
<infinity> ogra_: I think there are still one or two in the DC as Linaro buildds or something like that.
<infinity> ogra_: At this point, it's between IS and the kernel team, I've made sure the rest of us don't care.
 * ogra_ curses Xorg instability loudly 
<ogra_> infinity, ah, ok ... i think they are oem builders actually
<infinity> ogra_: That could be it.
<ogra_> *sniff* there goes the meerkat ...
<ogra_> (one of my favorite t-shirts actually, next to the oneiric ones with the nice cat pawns)
<infinity> The ones from Sydney were the best.
<ogra_> heh, true, i still have mine but dont fit in it
<ogra_> i was 20kg lighter when i got it
<robbiew> sure
<micahg> janimo`: it's chromium upload week, I'll try again in a bit :)
<janimo`> micahg, step by step, armhf will build eventually. Do not forget to mention 'attemp' in the changelog somewhere ;)
<janimo`> attempt
 * micahg did hopefully really fix this time :)
 * micahg still wonders why armel builds on precise, but not oneiric /me will check build flags later
<pbuckley> eww armel ;)
#ubuntu-arm 2012-03-09
<smp4488> im trying to install the omap3 sgx drivers on 12.04, here is the output http://paste.ubuntu.com/875606/
<smp4488> obsoleted or only available from another source?
 * micahg hugs janimo`, maybe we'll get chromium and ghc on armhf on the ssame day
<janimo`> would be nice. But until I see them both successfully built I am not celebrating :)
 * janimo` hugs micahg back
<brendand> i guess it's not normal that to get the 'correct' resolution on a pandaboard with a hdmi -> dvi cable you need to boot it with the cable connected to the panda's dvi socket and then switch over to hdmi to get the actual picture
<brendand> if i boot with it connected to the panda's hdmi socket then i get a 'squashed' image
<brendand> and why is it just shutting off after a few minutes?
<ogra_> brendand, how do you power the board ?
<ogra_> should at least be a 3A (better 4A) 5V supply
<brendand> ogra_, 5v straight to the wall
<brendand> ogra_, has always been working fine
<brendand> maybe it's too much? should i switch back to usb power from my laptop?
<ogra_> that doesnt mean much if power consumption changed due to driver changes :)
<xranby> brendand: do your monitor support "p" resolutions?
<brendand> xranby, meaning?
<xranby> brendand: it might be that your monitor only support interlaced resolutions
<ogra_> how many amps does your PSU have ?
<brendand> ogra_, well, it's still a USB cable, but it goes into a wall socket
<xranby> brendand: which of these resolutions do your monitor support? 720p, 1080i, or 1080p
<brendand> xranby, none of those?
<brendand> according to xrandr on my laptop
<brendand> but that's probably not true
<ogra_> then the squashed image might be normal, depending on what exactly the EDID of the monitor supplies to the driver
<brendand> that's just the vga outputs
<ogra_> and if the driver can support that
<brendand> ogra_, oh, the squashed image is secondary - i can get over that
<brendand> ogra_, it's the power off that's bothering me
<ogra_> well, you should find out how many amps your PSu actually offers to the board
<brendand> happens a minute or so after login
<ogra_> below 3A you will get probs if you have any USB devices attached
<ogra_> usually a non Y USb cable doesnt provide enough
<brendand> ogra_, i don't have an ammeter unfortunately
<ogra_> (i think its 500-750mA per USB line ...
<ogra_> )
<brendand> ogra_, the wall plug is definitely 5v
<ogra_> sure, else you wouldnt be able to plug USB directly into it
<ogra_> but whats important is the power
<ogra_> if you power the panda through plain USB i wouldnt even bother to try running any desktop image on it
<ogra_> and even headless will get issues once the kernel powered up all devices
<brendand> ogra_, so here's the full deal. i have a usb cable with one end USB and one end 5v connector
<brendand> ogra_, i also have a wall adapter from a kindle
<brendand> ogra_, which is 5v
<ogra_> the voltage is ireelevant
<brendand> ogra_, so i have two options, one is to plug the usb cable into my laptop, the other to plug it into the wall adapter
<brendand> ogra_, if i plug it into the laptop it stays on
<brendand> ogra_, if i plug it into the wall adapter it powers off
<brendand> so i have got my workarounds now, but things have definitely changed
<ogra_> right, both will not provide enough power, one just stays a bit more stable
<ogra_> seriously, get a proper PSU
<ogra_> powering through USB will have unpredictable sideefects and you wont be able if the issues you see have to do with SW or power
<ogra_> a single USB cable *cant* provide enough power for a panda
<ogra_> s/abel/able to tell/
<brendand> ogra_, you're probably going to smack me down for this, but it is possible the cable itself is not a USB cable but just has a USB connector on one end?
<ogra_> unlikely
<brendand> although you've made it quite clear that the optimal setup is to have a proper 5v PSU, with no hint of usb-ness about it
<ogra_> you can run the board headless with an Y-USB cable, that will just provide enough power to run a headless system without any attached USB devices
<ogra_> if you run a desktop and use a USB kbd and mouse as well as the builtin USB NIC, you *need* more than 2A
<brendand> ogra_, ok, so this is the cusp of the problem. you'll be shocked to know i don't have much electrical training
<brendand> so the wall plug is actually only 0.35 Amps
<ogra_> you dont need any electric training
<ogra_> just make sure your HW fulfills the needed specs
<brendand> ok, i'll rephrase it. i haven't a f*ing clue
<ogra_> let me give you a clue then: buy a >2A 5V power supply
<ogra_> (and note they are expensive, unlikely you get one for less than $15-20)
<ogra_> even your way to power from the laptop wont gain you a stable platform
<ogra_> (even though it doesnt shut off immediately)
<brendand> no, but for now it's working (mostly) until i get a proper PSU
<brendand> which i will
<ogra_> ringht, just dont ask about bugs until you have stable HW
<ogra_> since the low power makes it totally unpredictable if there is actually a SW bug
<brendand> i wasn't aware of the required ampage, so now i know what might cause any strangeness
<ogra_> right :)
<sledges> zyga, I ran the built from sources kernel on imx53 finally
<zyga> sledges, and?
<sledges> s/ran/successfully ran/ :)
<sledges> you need to use identical toolchain
<sledges> to that of the working binary
<sledges> there's also a patch to work with gcc4.6.2 (failed in my research so far, but there are still things to try), 1 moment...
<sledges> https://build.pub.meego.com/package/view_file?file=000-kcflag-mno-unaligned-access.patch&package=kernel-adaptation-n900&project=CE%3AAdaptation%3AN900&rev=9cdc38022e14fe78051a2e799587a375
<xranby> hmm why are this patch not part of the ti omap4 kernel tree? http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7178/1
<zyga> sledges, does sata work for you?
<sledges> yes
<zyga> sledges, I suspect my board is simply broken
<zyga> not soldered right or something
<sledges> I had sata working fine with that kernel - did you try that kernel?:  http://cdimage.ubuntu.com/releases/oneiric/release/ubuntu-11.10-preinstalled-desktop-armel+mx5.img.gz
<sledges> break in uboot and override bootargs with rootfs-on-sata
<sledges> i tried other ~5 kernels from different sources (linaro, ltib, 2.6.35/38), none of them worked (or halting after decompress or not enumerating SATA)
<sledges> so don't give up :) and give it a last shot, zyga
<zyga> sledges, I cannot try right now, that device is production
<zyga> sledges, I'd need a new IMX from linaro
<zyga> this one is personal
<sledges> production? IMX from linaro - you mean HW? I thought Linaro provide only SW BSPs
<zyga> sledges, I mean I'm using this imx to do stuff 24/7 and I cannot tinker with it
<zyga> sledges, linaro as my host/employer so that I can use it for my linaro-work
<sledges> zyga, understood ;)
<sledges> well, good luck and keep in touch!
<zyga> sledges, I need panda es, origen, and imx53 from the last gen lineup
<sledges> wow, smoking! :)
<xranby> jamespage: ping i will try if that patch improves the https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/845158 situation
<ubot2`> Launchpad bug 845158 in openjdk-6 "Frequent java task hang on ARM server" [Undecided,Confirmed]
<xranby> jamespage: this patch applies cleanly http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7178/1 on the ti omap4 kernel tree
<xranby> i am compiling my own kernel using it
<marvin24> any idea if /sys/class/power/battery/current_now is allowed to return a negative value (to show the battery is discharging)?
<marvin24> upower seems to apply abs() to it, but other power daemons seem to assume only positive currents
<marvin24> I failed to find any documentation about the required values (beside that the field is signed int)
<danboid> I've installed 11.10 on my pandaboard but what I think is gdm isn't letting me log into anything but Unity even though XFCE, fluxbox are listed and supposedly chosen
<danboid> I'm choosing 'Other' on the login screen
<danboid> then I pick say XFCE, login - Unity!
<danboid> Have I go to replace gdm with kdm or another display manager?
<ogra_> gdm wasnt used in a while in ubuntu
<ogra_> so that might be a gdm specific bug
<danboid> ogra_, I'm just using the default display manager in 11.10 - I was just presuming it was gdm
<ogra_> no, thats lightdm
<danboid> ogra_, So this looks like a lightdm bug then
<ogra_> and it should just give you the right login (it surely does here)
<ogra_> is your ~/.dmrc not writable or some such ?
<danboid> Its writable
<danboid> I've tried logging into Unity 2D, XFCD
<danboid> XFCE and fluxbox with no luck
<danboid> I'm new to lightdm so
<ogra_> its not different from gdm in behavior
<ogra_> just smaller :)
<ogra_> it checks the available sessions, updtaes dmrc and runs the session from there
<danboid> Maybe I can fix it by editing .dmrc?
<danboid> or how do I force it to update .dmrc? It doesn't list all the desktop/wms in there at,
<danboid> atm
<ogra_> do both (flux and xfce) have sessions in /usr/share/xsessions ?
<ogra_> iirc thats what gdm and lightdem check for nowadays
<danboid> Yeah - I've got 6 files in there now
<danboid> inc ones for XFCE and Flux
<ogra_> check if they have proper Exec lines
<ogra_> and if tehse executables actually exist
<ogra_> you can edit dmrc if you want
<ogra_> Session= needs the name of the .desktop file in /usr/share/xsessions you want to use i think
<shadeslayer> hey guys, just wondering, how do you test build your ARM packages?
<ogra_> like we test build our x86 packages
<shadeslayer> ogra_: pbuilder? But how do you specify you want a ARM pbuilder?
<shadeslayer> I can make x86 and x86_64 pbuilders, and I was trying out qemubuilder last night, but that just refused to work
<xranby_ac100> jamespage: ping
<GrueMaster> shadeslayer: We build our packages natively on arm platforms.
<jamespage> xranby_ac100, hey!
<xranby_ac100> jamespage: hi
<shadeslayer> GrueMaster: right, but what if I don't have one of those? :)
<micahg> janimo`: \o/ chromium on armhf
<xranby_ac100> jamespage: i might have found a fix for the server stalls under heavy load
<ogra_> shadeslayer, i dont use pbuilder but there are knobs and switches iirc to make it run with qemu-arm-static
<GrueMaster> shadeslayer: Not sure what to tell you, other than maybe buy one?  They are fairly cheap.
<jamespage> xranby_ac100, great!  I saw you note earlier - how did that work out?
<xranby_ac100> jamespage: from the limited testing i have done so fair... looks promising.. but i need to run more tests to be sure.. i am using a patched kernel for my ac100 here
<shadeslayer> ogra_: there's a qemu-system-arm
<ogra_> shadeslayer, you want qe,u-user-static
<shadeslayer> oh
<xranby_ac100> jamespage: is there some quick way you can cross compile a kernel using xdeb??
<shadeslayer> ogra_: what's wrong with the former?
<ogra_> that runs a full vm
<xranby_ac100> jamespage: i was really hoping to check if you had had any chance to run any tests
<ogra_> anywayx, i only know there is an implementation in pbuilder that uses it, i have no idea at all how that works or how you use it
<shadeslayer> oh cool
<shadeslayer> I'll look into it
<shadeslayer> thanks ogra_
<ogra_> welcome :)
<GrueMaster> xranby_ac100: What tests are you running that are causing stalls?  I'd like to run them here, as I am working on workload testing on arm server.
<xranby_ac100> GrueMaster: my test are to run the jogamp jogl unittests
<ogra_> cp 1TB file from mmcblk0p1 to mmcblk1p1 :)
<xranby_ac100> GrueMaster: let me give you a link to how to build and run them
<shadeslayer> would probably have been easier if my Transformer had a proper SBK version ... *grumble*
<GrueMaster> That would be great.
<xranby_ac100> GrueMaster:  http://www.trimslice.com/forum/viewtopic.php?p=1804&sid=f05c252a82821fdd7d3924941c1bfb78#p1804
<xranby_ac100> when gluegen and jogl are build then run     sh scripts/make.jogl.all.linux-armv7.sh junit.run
<xranby_ac100> to start the unittests
<xranby_ac100> when i test on my pandaboard running oneiric i can trigger a stall within 10min
<xranby_ac100> a stall means that the process gets stuck in some kernel lock   and    ps ax   also stall when trying to list processes
<xranby_ac100> GrueMaster: my panda dmesg looks like this http://paste.ubuntu.com/875835/
<xranby_ac100> what i hope are that this patch http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7178/1
<xranby_ac100> might fix it.. both the ti omap kernel trees and the ac100 kernel tree are missing this patch
<xranby_ac100> its merged into linus git tree upstream
<GrueMaster> Interesting.  Do we have a bug against the kernel for this?  it should be possible to get it in for precise kernel.
<GrueMaster> (if it isn't there already).
<jamespage> xranby_ac100, I can run some tests that load up things quite well - yes
<xranby_ac100> GrueMaster: we have an old bug not yet pinned to the kernel https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/845158
<ubot2`> Launchpad bug 845158 in openjdk-6 "Frequent java task hang on ARM server" [Undecided,Confirmed]
<xranby_ac100> GrueMaster: i have been looking high and low for a better testcase
 * prpplague grumbles about how buggy his ubuntu desktop has been since it has been updated
<xranby_ac100> GrueMaster: this issue poped up adain frequently when i was testing the opengl-es bindings with the jogamp community
<xranby_ac100> the best test i have are to run the jogamp unittests on a panda
<xranby_ac100> you can also pick one test and run it 100 times in a row
<GrueMaster> xranby_ac100: Looking at our 3.2 kernel git tree, I am not seeing this patch applied.  Oddly, the link says it is in 3.2-rc3 (unless it is the x86 version of the patch only).
<xranby_ac100> GrueMaster: when i checked today its not applied in any ofthe panda 3.1 and 3.2 tree
<xranby_ac100> s
<GrueMaster> I'm always looking for new and interesting tests I can automate.  I'll see if I can get this test scripted and automated.  I'll also file a kernel bug for this patch.
<xranby_ac100> GrueMaster: it are found upstream here http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=history;f=arch/arm/mm/fault.c;h=bb7eac381a8e60f619591e7c80c4ad30cc972d62;hb=HEAD
<GrueMaster> Excellent, thanks.  I'll update my local ubuntu kernel git tree and double check, then if it isn't there, I'll file a bug and add this link.
<GrueMaster> There.  bug 951043 filed.
<ubot2`> Launchpad bug 951043 in linux-ti-omap4 "Port OOM changes into do_page_fault for arm" [Medium,New] https://launchpad.net/bugs/951043
<GrueMaster> I didn't add the ac100 or mx5 kernels.
<xranby_ac100> GrueMaster: thanks a lot, poke me if you for some reason fail to build jogamp
<GrueMaster> Will do.
<pbuckley>  syntax error: unknown user 'puppet' in statoverride file
<pbuckley> i always forget what causes this
<pbuckley> (dpkg)
<infinity> pbuckley: Pretty much exactly as it sounds.  Someone's done a dpkg-statoverride to make something owned by "puppet", but the user doesn't exist.
<pbuckley> probably from the puppetlabs package for puppet.. and apt-get purge didnt clean it
<pbuckley> how do i fix it?
<pbuckley> Can't exec "/tmp/lightdm.config.24521": Permission denied at /usr/share/perl/5.14/IPC/Open3.pm line 186.
<pbuckley> also been seeing this
<pbuckley> maybe its time i start over from a fresh flash
<infinity> Simplest method would just be to create a puppet user before trying to remove those packages that seem grumpy, and then delete it.  Otherwise, you can fix the actual statoverride in question.
<pbuckley> ah good idea
<pbuckley> that seemed to fix the override
<pbuckley> so im assuming that exec issue comes from /tmp being mount noexec
<pbuckley> which i did because it was complaining about mount -o remount,exec
<pbuckley> (and at the time /tmp wasn't a seperate mount)
<infinity> We don't support noexec tmp by default.
<pbuckley> hrmm.. seemed to want it that way at one point
<infinity> (dpkg, as you note above, unpacks various scripts and runs them from tmp)
<pbuckley> ill set it back
<infinity> There are ways to change that, and have dpkg use other directories, I believe.
<infinity> Well, I suppose you could just run apt/dpkg with a different TMPDIR set.
<pbuckley> Updating software catalog...this may take a moment.
<pbuckley> WARNING:softwarecenter.db.update:The file: '/usr/share/app-install/desktop/kde-telepathy-send-file:kde4__ktp-send-file.desktop' could not be read correctly. The application associated with this file will not be included in the software catalog. Please consider raising a bug report for this issue with the maintainer of that application
<pbuckley> all sorts of new errors this morning
<pbuckley> heh
<pbuckley> yeh removing the /tmp mount fixed the issue
<pbuckley> now its just a directory
<infinity> The software center thing is a bug, not your problem. ;)
<pbuckley> \o/
<pbuckley> i like those
<electroglue> can someone tell me if ubuntu-omap4-extras is available for pangolin?
<GrueMaster> electroglue: I don't think TI has pushed them up yet.
<infinity> Most of the bits are in their experimental PPA, but it requires the kernel from the oneiric PPA to work, if I recall.
<infinity> electroglue: ^
<janimo`>  micahg and ghc too \o/
<infinity> janimo`: You've had a fruitful week. ;)
<janimo`> infinity, yes, in hindsight it could have been a fruitful single day had I paid more attention and panda had not locked up
<infinity> janimo`: Meh, hindsight is like that.
<infinity> janimo`: Did you end up going the "mangle ghc" route, or "make llvm have sane defaults" route?
<janimo`> infinity, the sed-patch route. Without the clean rule :D
<infinity> You sick man.
<janimo`> since it is temporary :)
<janimo`> well. If I had touched m4 code I'd just be sicker now, so it was the right choice
<infinity> m4 isn't that painful
<GrueMaster> Neither is pulling nostril hairs with vise grips, but why try.
<infinity> ... I've done that.
 * GrueMaster is the lease bit surprised.
<GrueMaster> *least
<infinity> And s/is/isn't/ ?
<infinity> I think Friday afternoon has taken hold of your fingers. ;)
<GrueMaster> Exactly.  I hear my neighbor mowing his lawn, and see blue sky outside my basement window.  Thoughts lie elsewhere.
<infinity> Swimming in an pool filled with beer?
<electroglue> infinity: so using an oneric kernel really means that the packages aren't available for pangolin correct? I'm looking for hardfp and omap4 extras to be available with the kernel provided by pangolin
<infinity> electroglue: Yeah, as far as I know, that's "soon, but not yet".
<pbuckley> i feel your pain GrueMaster, it is beautiful outside.. blue skys.. i see the ocean outside my window
<pbuckley> really hard to focus on work
<pbuckley> stupid question.. what generates /var/run/motd?
<GrueMaster> Probably motd?
<GrueMaster> (just a wild guess).
<infinity> pbuckley: See /etc/update-motd.d/*
<infinity> pbuckley: Mashed together by pam_motd
<pbuckley> awesome thank you
#ubuntu-arm 2012-03-10
<lilstevie> ogra_, are you about?
<MDesade> hello hello
<MDesade> hello hello
<MDesade> i could use some help here: i am trying to compile a kernel for a mini2440 ARM dev board, and it doesn't want to compile
<MDesade> (i should say i am new to ARM, but have worked with linux for a while)
<MDesade> so, any help here, would be awesome
<MDesade> http://pastebin.com/QMAYRSJw
<gildean> MDesade: isn't the message quite clear?
<gildean> you're missing the toolchain referred
<MDesade> it says it can't find the toolchain
<MDesade> i have downloaded it, and put it in my path
<MDesade> again, i am new to compiling kernels for a different host arch, so the whole toolchain thing is new to me
<gildean> https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/CrossBuildNano
<MDesade> when you download the tarball from friendlyARM that has the toolchain, it puts it in ;/usr/src/opt/FriendlyARM/toolschain/4.4.3/arm-none-linux-gnueabi/sys-root/usr/include/asm-generic/unistd.h
<MDesade> (as an example)
<gildean> ok, but the path referred is /usr/src/opt/FriendlyARM/toolschain/4.4.3/bin/.arm-none-linux-gnueabi-gcc
<MDesade> here is my path statement: PATH=$PATH:/usr/src/opt/FriendlyARM/toolschain/4.4.3/bin
<MDesade> (from .bashrc)
<MDesade> so?? should i add the ".arm-none-linux-gnueabi-gcc" to my path statement??
<MDesade> ok, i just tried that, same result
<danboid> When I've installed Ubuntu previously on my panda it was to the same SD card as the installer was run off, but then it didn't see to give me any partitioning options anyway so how will I go about installing so that / is on a USB HD?
<weasel> so, I'm about to set up a couple ubuntu chroots on my debian armhf machine to build packages that users request.
<weasel> am I missing something or is there so far only an armel port, no armhf port for {lucid,natty,oneiric}?
<danboid> weasel, Yep - armhf is new in precise
<weasel> ok, sounds good.  thanks
<weasel> what's the ubuntu equivalent of debian's locales-all package?
<Snark> weasel, I don't have my ubuntu box up and running to check, but something like language-all ?
<Snark> I remember I had to install some language-fr packages, so "language" is the key word I think
<weasel> ok, will give it a try once the builds are all done.  danke
<MFaro-Tusino> Curious as to which is the best image to use if i want to test ubuntu arm on my N950
<MFaro-Tusino> *bump*
<gildean> hmm, why not try the latest?
<MFaro-Tusino> I want to, but not sure if it will work with the hardware, drivers etc
<gildean> well, i'm not really sure, but i'd think that the drivers etc. are in upstream already
<MFaro-Tusino> okay, may wait till I get confirmation first, thx anyway
#ubuntu-arm 2012-03-11
<MDesade> hello hello, anyone around to help me here?
<MDesade> i need help cross compiling, since i am new to this im sure im missing something stupid
<cdnjay> Hi, did Ubuntu 8.04 support ARMv6?
<micahg> cdnjay: armel support was added in 9.04
<cdnjay> OK, so was 9.04 the only version to support ARMv6 then?
<micahg> cdnjay: and 9.10, both EOL, Debian stable is the best bet for armv6 for an Ubuntu like setup
<infinity> I don't recall exactly when each option was changed.
<infinity> But yes, what micahg said.
<infinity> Installed an unsupported release for ARMv6 isn't a sane option.
<infinity> s/installed/installing/
<micahg> IIRC, Debian stable base arm support is armv4t
<infinity> Aye.
<micahg> cdnjay: http://www.debian.org/ports/arm/ and http://wiki.debian.org/ArmEabiPort for more information
<cdnjay> micahg: OK, thanks. I was hoping an LTS had supported it. I guess I'll have to use Debian for Raspberry Pi.
* infinity changed the topic of #ubuntu-arm to: Ubuntu ARMv7 Discussion & Development | If you have a Pi, try Debian! | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Get Precise beta 1 while it's hot! http://cdimage.ubuntu.com/releases/precise/beta-1/ Includes armhf images! | Logs at http://irclogs.ubuntu.com/
<infinity> cdnjay: Nothing wrong with running Debian.
<cdnjay> infinity: Haha, thanks.
<cdnjay> infinity: I haven't used it much but since Ubuntu is a fork I'm guessing they're somewhat similar?
 * micahg hugs infinity
<infinity> From a command-line, you'll be hard pressed to really notice any major differences.
<infinity> The GUIs we provide are often quite different, but you can't possibly run a full Ubuntu deskop on a Pi anyway.
<micahg> cdnjay: Debian stable has support for about another 18 months or so
<micahg> er..closer to 20
<micahg> Debian's stable releases are supported for ~3 years, ~2 as current stable and 1 as oldstable
<gogasan> Hi everyone! I have a problem with playing videos in totem. So: http://img717.imageshack.us/img717/8930/20120311124553.png : RGB channels are moved from their positions. Is there some specific problem for arms and solution?
<cdnjay> infinity: No, the Pi is a bit short on RAM for that.
<infinity> cdnjay: A "bit"? ;)
<cdnjay> infinity: Well, a lot short for Unity.
<infinity> A lot short for GNOME in general.
<infinity> xfce or lxde might barely squeeze in, but I still suspect you'd swap like made.
<infinity> s/made/mad/
<infinity> I'd likely only use a Pi for CLI programming fun.
<infinity> At which point, Debian and Ubuntu look nearly identical, other than a few little cosmetic bits like the motd.
<micahg> lubuntu might actually run decently on it
<infinity> gogasan: No idea.  You might want to file a bug.
<infinity> micahg: Sure, until you wanted to, like, run applications.
<micahg> at least for basics, not for heavy browsing or video
<infinity> video should be the one thing it doesn't suck at, actually.
<infinity> In theory.
<micahg> I'd just suggest running a browser other than chromium in that small footprint
<infinity> Something webkit-based, ideally.
<cdnjay> infinity: I thought minimum for Gnome was 128 MB? Pi has 256 MB.
<infinity> Which reminds me, I promised Maya I'd package Wildfox for her one of these days.
<micahg> well, aside from Firefox, that's all that's left in the archive ;)
<cdnjay> Hard to take advantage of the 1080p decoding in CLI but yea, that
<infinity> cdnjay: I don't tend to pay attention to stated minimums.
<cdnjay> I the more likely use.
<micahg> hmm, I shouldn't say that, I think we might have imported a browser based on fltk
<cdnjay> I = is
<micahg> dillo might actually run decently
<infinity> epiphany might be alright, but every time they add a new feature to make it suck less, it gets closer to firefox in memory usage, while still being nowhere near in feature parity.
<cdnjay> Anyway, thanks!
<infinity> micahg: Surely, we must have a webkit-based browser in the archive?
<micahg> infinity: firefox is going down in memory usage though, 13 is looking really good WRT memory, it used to use ~5GB resident for me and now is using ~750MB
<infinity> micahg: We can't only be using webkit for embedded browsing widgets...
<infinity> micahg: 13?  I want your crack, I only have 11.
<micahg> infinity: sure, there's midori, epiphany, I was saying the xul based browsers are gone save Firefox and I forgot, Seamonkey
<micahg> infinity: firefox-trunk PPA
<infinity> (But yes, I've noticed that 11 is wildly more efficient than 10 was)
<infinity> Oh, epiphany switched to webkit?  I must have missed when that happened.
<micahg> infinity: https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/
<infinity> Shows how much I pay attention.
<micahg> infinity: epiphany switched to webkit in karmic with 2.28 (upstream still supported gecko for that release, but we dropped it)
<infinity> Well, my ffox 11 is only eating 1.5G right now.  Maybe I should try 13 and see how much gooder it is.
<infinity> It does make me wonder just why it was so awful in 4 through 9, though, if it was this "easy" to find enough low-hanging fruit to cut my usage.
<infinity> I used to be at around 6G on average with this same basic set of tabs.
<micahg> infinity: they've started pouring resources into their memshrink operation
<micahg> infinity: https://wiki.mozilla.org/Performance/MemShrink
<gildean> seems also that 11 already uses a lot less memory tho'
<gildean> i've got about 20 tabs open and just 400MB of usage
<micahg> ah, could be, I've been on trunk for a while
<infinity> gildean: Yeah, that's what I was saying.  I've gone from ~6G to ~1.5G with the same set of tabs.
<infinity> Still, if 13's even better, I'm willing to live on the edge for a bit.
<gildean> infinity: that's pretty good too
<gildean> i didn't test version 10, but between versions 9 and 11 it seems memory usage was cut in about half
<infinity> micahg: Is that MemShrink thing focussing solely on firefox, or all mozilla projects?
<gildean> with a small number of tabs with no heavy web-apps open in them
<infinity> micahg: (Not counting shared code, of course, where they influence other projects by accident)
<micahg> infinity: well, it affects the various parts of firefox which include the gecko core that affects other projects like thunderbird and seamonkey
<infinity> Sure, but I suspect there are any number of Thunderbird-specific inefficiencies with local caching and the like.
<micahg> sure, right, it's not focused on those, just stuff in mozilla-central AFAIK
<infinity> Well, it's a start anyway.
<infinity> And I might give tbird another try at some point.
<infinity> Right now, it only gets opened when someone sends me pretty mail that piping to w3c from mutt can't really make sense of.
<infinity> (The last such mail from from the Linux Foundation... I really need to write back and take issue with the fact that the effin' LINUX FOUNDATION was sending HTML-only email instead of multipart text/html)
<infinity> It's enough to make a grown nerd cry.
<gildean> i used to think that emails should be plain text
<infinity> They should.
<gildean> but then again, html is nothing more than plain text too
<gildean> and i really like html, so i've changed my mind
<infinity> But ever since html email came along, there's been an established standard for sending both in one mail.
<gildean> all emails should be html
<infinity> And the only people who mess up that standard are people writing broken mass-mailing software, generally.
<infinity> Most MUAs get it right.
<infinity> Even Outlook eventually figured it out.
<infinity> So, it's pretty much just lazy web developers who think it's "too hard" to read standards and implement them in their spam scripts.
<steev_> is there an issue with the linaro 4.6.3 compiler on armhf?  if i build a kernel with it, it doesn't seem to boot.  (Sadly I haven't really debugged what's going on, was just testing on a machine I had handy, most of my machines are still packed up as I moved yesterday)
<steev_> infinity: personally i dislike html emails as well, there is one guy in our lug who insists on sending them, so his emails are always in this ginormous text compared to everyone elses.  He also top posts so *shrug*
<lilstevie> html emails are annoying
<RoyK> hi all. is there a precise build available somewhere?
<RoyK> (for OMAP)
<Neko> <RoyK> hi all. is there a precise build available somewhere?
<Neko> <RoyK> (for OMAP)
<Neko> sorry
<Neko> RoyK, the URL is above, http://cdimage.ubuntu.com/releases/precise/beta-1/
<infinity> Or http://cdimage.ubuntu.com/daily-preinstalled/current/ for dailies.
<aerou> hello
<aerou> I am trying to boot Ubuntu Precise image using u-boot and a tegra2 board
<aerou> but after typing the fatload command
<aerou> it hangs
<aerou> I am wondering why in the supplied boot.txt file is the fatload address 0x7000000
<aerou> what does this address mean
<aerou> I was trying to find info on this in the web
<aerou> but couldnt find a proper description
<aerou> While reading guides on how to load different linux images on different arm devices, there was always a different address parameter
<aerou> which makes sense, but what does it define exactly
<aerou> and how do I know to which address should I load the uImage to?
<lilstevie> which device
<aerou> the Tegra2 board is the Colibri T20 from Toradex
<aerou> and I am trying to boot Ubuntu Precise from microsdhc card
<lilstevie> hmm
<lilstevie> maybe try looking at their website, cause I know Colibri mainly focused on getting WinCE on their boards
<lilstevie> not a lot of info about linux
<aerou> exactly
<aerou> They provide and Angstrom image
<lilstevie> have a look at the Angstrom image
<aerou> but no info on getting other Linux images running
<lilstevie> there has to be a boot.scr or boot.cmd or boot.txt in that
<aerou> the boot.* should only contain loading kernel and initrd, setenv paramters and the boot command itself, right?
<aerou> here is the output of "printenv" command in u-boot
<aerou> Tegra2 #printenv
<aerou> baudrate=115200
<aerou> bootcmd=run flashboot; run nfsboot
<aerou> bootdelay=5
<aerou> defargs=video=tegrafb vmalloc=248M
<aerou> fdtaddr=17ef78
<aerou> flashargs=ip=off root=/dev/mtdblock0 rw rootfstype=yaffs2
<aerou> flashboot=setenv bootargs ${defargs} ${flashargs} ${mtdparts} ${setupargs}; echo Booting from NAND...; nboot $loadaddr 0 0x1200000 && bootm
<aerou> ipaddr=192.168.10.2
<aerou> loadaddr=0x408000
<aerou> memargs=mem=372M@0M fbmem=12M@372M nvmem=128M@384M
<aerou> mmcboot=echo Loading RAM disk and kernel from MMC/SD card...; mmc init && fatload mmc 0:1 0xC08000 rootfs-ext2.img.gz && fatload mmc 0:1 ${loadaddr} uImage;run ramboot
<aerou> Is there any info that I can use?
<lilstevie> fatload mmc 0:1 ${loadaddr}
<lilstevie> load the uImage to 0x408000
<lilstevie> with loading the uRamdisk you need to be mindful of where other things are in memoryspace
<lilstevie> I tend to try for ${loadaddr}+uImage+a little extra in case the uImage ends up needing a little more room
<aerou> will try
<aerou> So I loaded the uImage at 0x408000
<aerou> My knowledge here is limited
<aerou> I am loading the image into ram
<aerou> now what with the initrd?
<aerou> I see:
<aerou> ramargs=initrd=0xA1800000,32M ramdisk_size=32768 root=/dev/ram0 rw
<aerou> so should I do:
<aerou> fatload mmc 0:2 0xA1800000 uInitrd ?
<aerou> so I loaded uImage into 0x408000
<aerou> initrd into 0x2408000
<aerou> changed
<aerou> ramargs=initrd=0xA1800000,32M ramdisk_size=32768 root=/dev/ram0 rw
<aerou> into
<aerou> ramargs=initrd=0x2408000,32M ramdisk_size=32768 root=/dev/ram0 rw
<aerou> typed
<aerou> run ramboot
<aerou> and this happened
<aerou> Tegra2 # run ramboot
<aerou> Booting from RAM...
<aerou> ## Booting kernel from Legacy Image at 00408000 ...
<aerou>    Image Name:   Ubuntu Kernel
<aerou>    Created:      2012-03-01   8:00:45 UTC
<aerou>    Image Type:   ARM Linux Kernel Image (uncompressed)
<aerou>    Data Size:    4252072 Bytes = 4.1 MiB
<aerou>    Load Address: 70008000
<aerou>    Entry Point:  70008000
<aerou>    Verifying Checksum ... OK
<aerou>    Loading Kernel Image ...
<aerou> and thats all
<juula> Test
#ubuntu-arm 2013-03-04
<isaias> how do i get my nexus 7 back to normal?
<suihkulokki> is there any plan to put strace 4.7 to raring
<sspiff> hi, can I find a list of supported platforms for Ubuntu's ARM work?
<sspiff> I'm wondering if it would work, with graphics acceleration, on an OMAP 4470 platform
<ogra_> it definitely does on 4460, not sure about 4470
<ogra_> the pandaboard was for years our reference platform
 * infinity has never even seen a 4470...
<infinity> Looks like the big difference is a PVR SGX544 instead of a SGX540.
<infinity> So, entirely possible that the PVR binary blobs in precise wouldn't know about the new revision.
<ogra_> yeah
<ogra_> and since TI put OMAP to death for mobile we likely wont get any updated drivers anymore
<sspiff> infinity, ogra_: I'm asking specifically because I'm looking for a cheap but usable platform to run ubuntu on, and I came across the Archos 101 XS
<sspiff> which seems like a nice match, except for the low RAM. I was only worrying about the SGX544
<infinity> sspiff: Well, I honestly can't say one way or the other.  The last SoC *I* tested on was a 4460, but someone may have played with a 4470.
<sspiff> do the binary drivers for Linux and Android differ greatly?
<ogra_> well, if you would be fine moving to the ubuntu phablet edition (which HW wide depends on a minimal android layer) you should be fine with that HW
<infinity> sspiff: They're completely different, yes.
<ogra_> if you expect to fully natively run ubuntu on it (xorg, ubuntu kernel etc) i would go with a nexus device
<sspiff> infinity: hence the ubuntu phablet architecture leveraging the Android platform
<ogra_> right
<sspiff> ogra_: I considered that, but they're considerable more expensive and no decent good keyboard docks
<infinity> sspiff: The phablet/Android madness is more of a stopgap than an end goal. :)
<infinity> But it works for enablemnet on devices where we'll never see native drivers.
<infinity> For some value of "works".
<ogra_> well, the android layer will stay
<ogra_> it wil; shrink and bits will move into the distro, but it wont go away
<infinity> Erm.  Define "stay".
<infinity> If we get native drivers and have no need for bionic, we have no need for said layer.
<ogra_> infinity, the higher layer is designed to use libhybris and friend and to rely on HAL
<infinity> See above.
<infinity> Nothing depends on hybris, except that some things depend on bionic, thus we need hybris.
<ogra_> well, i doubt we want to go back to "we only support one device"
<infinity> Kill the bits that need bionic (binary blobs), and we don't need any of it.
<ogra_> while we already support over 30 after a week
<ogra_> with the new image
<infinity> The option for the Android layer is always there.
<infinity> The end goal for a branded device isn't that, though.
<infinity> Just sayin'.
<ogra_> android makes porting extremely easy ...
 * ogra_ produced that http://people.canonical.com/~ogra/phablet/i9100/ withing a few hours yesterday
<ogra_> *within
<ogra_> and i have *zero* android experience
<ogra_> i guess the layer might go away for devices we will preinstall on, but not for the unwashed masses
<infinity> I'm not sure I call it "porting", when you're just sucking in device support that's already there.
<ogra_> (if thats even possible with that design, the userspace apps make a lot of use of android bits)
<infinity> Erm, they do?
<ogra_> true, its not actual porting :)
<infinity> The system is glibc-based.
<ogra_> but needs the underlying API to talk to the HW
<infinity> That goes right back to the binary blobs thing.
<infinity> But yeah.
<ogra_> we dont have alsa, there is vold, no graphics stack etc
<infinity> We'll see how it pans out.
<infinity> You're right that for mass porting to unsupported devices, we'll likely keep the hybris/android solution indefinitely.
<ogra_> i.e. my image above has no wifi because samsung decided to have a dalvik based tool to bring up the driver
<infinity> You know, until we replace Android as the #1 phone/tablet OS.
<infinity> In 2023.
<ogra_> so i end up without wlan0 on the device and there is no way from userspace to activate it
<ogra_> i will need to hack something together on the android side for it
<ogra_> the longer that "interim" situation persists the harder it will get to get rid of the android side, community is actively contributing bits that will closer tie us into that
<sspiff> infinity: I understand the fact that it's a stopgap and that it's needed for easy device compatibility
<sspiff> regardless, I'm not in the market for having to create a device branch for an ubuntu phablet, I'm looking for a minimal effort to get an ultramobile notebook-tablet hybrid experience
<sspiff> if I'm going to have to hack support for the device, I know I'll never get around to it, to many hobby projects queuing in the backlog :)
<ogra_> well, we currently support the nexus7 natively
<sspiff> if the 4470 isn't going to work, a nexus solution would give me an inferior keyboard experience and with a decent dock etc the price of a nexus 10 becomes high enough to even consider Intel Core i3 solutions, which have good open source driver support
<ogra_> and the panddaboard for desktop installs, the the future here is blurry .... i would ratrher expect that to die due to lack of drivers
<sspiff> nexus7 is really to small for my needs, I'm looking for 10"
<ogra_> well, we can onlye easily get our hands onto the tegra drivers
<sspiff> yeah I assume the panda will go the way of the dodo soon, it's been removed from the AOSP as well
<sspiff> ogra_: open source tegra drivers? or binary tegra drivers for Linux for a specific distro?
<ogra_> so if you want Xorg, tegra HW is your best bet
<ogra_> binary indeed
<sspiff> I thought tegra/nvidia were completely unsupportive?
<ogra_> GLES isnt well suppported in the open ones
<sspiff> uhu, I really need GLES :P
<ogra_> it might get there (if you belive nvidias marketing)
<ogra_> but surely isnt yet
<sspiff> I do some GLES coding, and the main goal of the device I'm looking for is a tablet testing environment, and a way to do some light coding/compiling/... on the train/plane/somewhere else where my 15" notebook isn't an option
<sspiff> experience learns me to never expect support post-launch
<sspiff> SoC obsolete so fast that you really want on-launch support
<ogra_> well, i know for sure that nvidia works on an update for the drriver for the next Xorg ABI bump
<ogra_> so these devices should be safe for a little while still (if you find an unlockable one like the nexus line)
<sspiff> uhu
<sspiff> the Transformer TF300 would be a Tegra3 based option, but not sure if it's unlocked
 * ogra_ needs to give the cat her insuline shot, brb
<sspiff> huh, I didn't know they did that for cats
<ogra_> re
<ogra_> yeah, they luckily do ...
<ogra_> infinity, one for you :) https://plus.google.com/112266164281670850856/posts/RuPVvyrPBtU
<Zero_Chaos> So, can anyone tell me how ubuntu makes their rootfs.img?
<ogra_> we use live-build with some slight changes that are hidden in the livecd-rootfs source package
<Zero_Chaos> ogra_: do you know if it is possible to make a rootfs.img from a nexus 7 tablet? basically I'm trying to take a functional modified tablet and copy it to another.
<ogra_> zou can either just grab the nexus7 one and modify the tarball inside or start from scratch using an ubuntu-core tarball
<Zero_Chaos> to be honest, I have a fully customized device now that I want to copy, I don't want to start over
<tassadar_> Zero_Chaos: nandroid backup in recovery should be enough in fact, if you can/want use that
<Zero_Chaos> tassadar_: is that a custom recovery or the stock android one? forgive me I'm new ;-)
<tassadar_> custom recovery, it basically does .tar.gz from whole /data partition
<Zero_Chaos> tassadar_: anything that does *everything*? I have a slightly custom android that has a custom ubuntu chroot in /data/local/ubuntu so I really wanted to grab all of rootfs
<tassadar_> well, what do you consider "all of rootfs"?
<ogra_> if you have a custom chroot already, just apt-get what you want
<Zero_Chaos> tassadar_: /
<Zero_Chaos> tassadar_: minus the obvious /dev /proc and /sys
<tassadar_> uh
<Zero_Chaos> that is "rootfs" afterall
<tassadar_> data partition is / for ubuntu
<Zero_Chaos> tassadar_: it's android with an ubuntu chroot right now
<Zero_Chaos> but I know the full ubuntu install has a real nice rootfs that is easy to flash, just didn't know if I could make one from a running device easily
<Zero_Chaos> looks like the answer is "not easily"
<tassadar_> yeah
<tassadar_> damn you, school wifi network -.-
<Zero_Chaos> school sucks
<tassadar_> yeah, and I have to go now, sorry, bye
<Zero_Chaos> tassadar_: thanks for your help
<micahg> Could someone please tell me if this look likes cosmic rays: https://launchpadlibrarian.net/132280468/buildlog_ubuntu-raring-armhf.octave_3.6.4-1_FAILEDTOBUILD.txt.gz
<Zero_Chaos> I don't think I'd blame cosmic rays no matter what that log shows
<Zero_Chaos> so no, it's not cosmic rays
<ogra_> micahg, give it back ... if it doesnt fail the same way its cosmic rays :)
<Zero_Chaos> ogra_: please don't tell people that, most of them are dumb enough to believe you...
<ogra_> ??
<Zero_Chaos> ogra_: it's not cosmic rays
<Zero_Chaos> ogra_: thinking that is just embarassing
<Zero_Chaos> ogra_: we aren't in space, we don't get enough random space radiation to have such issues down here
<ogra_> well, it could be humidity in the datacenter ... or a fly sitting on a chip and shortening two contacts
<Zero_Chaos> ogra_: hardware failure on the other hand is a very common issue.
<micahg> Zero_Chaos: being that the build machines are in a unique case, we refer to cosmic rays as random failures to due HW env
<Zero_Chaos> ogra_: it could be aliens with mind control, but hardware failure is a bit more common don't you think?
<ogra_> it could be cosmic ray induced HW failure ;)
<Zero_Chaos> micahg: if you want to use an insane case to speak about a sane one that is your choice, but I'm still going to watch and assume you are stupid.
 * micahg is really feeling the love in here
 * ogra_ hugs micahg 
 * micahg hugs ogra_ back
 * micahg should probably just break down and create a cross-build chroot
<Zero_Chaos> micahg: I know a lot of people that think "cosmic rays" means "cosmic rays". using stupid terms like that causes more misunderstanding in an already misunderstood field.
<ogra_> that wont get you far on the buildd though
<ogra_> Zero_Chaos, its a commonly used term in here ... and please stop calling people stupid in ubuntu channels
<micahg> ogra_: well, it should tell me if there's an inherent failure in the build, it certainly won't catch all cases though
<ogra_> yeah
<ogra_> do you know if thats a virtualized or a devirtualized builder ?
<micahg> ogra_: using the cross libc, it wouldn't tell me if there were an assembler failure though, right?
<ogra_> could well be a qemu issue
<Zero_Chaos> ogra_: I didn't call anyone stupid, I said I would sit back and assume he was because he is using a term that deliberately breed misunderstanding.
<micahg> ogra_: devirt (archive)
<ogra_> yeah
<ogra_> oh, ok
 * micahg will give back then as he doesn't have the proper hardware to do a test (and the buildds are relatively free)
<achiang> Zero_Chaos: in fact, computers on earth *are* affected by cosmic rays. in early days of one of the supercomputers i worked on, we had to install a large tank of water above the server room to absorb them, to prevent RAM corruption issues caused by random bit flipping due to cosmic rays
<achiang> Zero_Chaos: later on, we improved the shielding on the DIMMs
<achiang> Zero_Chaos: and of course, due to wave/particle duality at the quantum levels, i'd say that it is quite reasonable to use "ray" and "particle" interchangably in this context
<Zero_Chaos> achiang: is this 1962?
<achiang> Zero_Chaos: is that relevant?
<Zero_Chaos> achiang: yes, because "computer's are affect by cosmic rays" is very different from "computer's were affected by cosmic rays 30 years ago before they were properly shielded"
<achiang> Zero_Chaos: this was 2002.
<achiang> Zero_Chaos: so if you could stop calling people stupid, that would be great. thanks.
<Zero_Chaos> achiang: during one of the longest solar minimums in history? I'm... shocked may be the word
<Zero_Chaos> achiang: and again, picking the single least likely scenario is not good practice, and it perpetuates confusion in the industry, and that is stupid, which is what I said.
<ogra_> can we drop thatr off-topic now ?
<Zero_Chaos> achiang: when gcc compile fails over and over, in a different place, I don't say it's cosmic rays, I say it's ram.  And you know what, wrapping the computer in 10 ft of tin foil can't fix what new ram can
<ogra_> there is no computer to wrap ... its all dev boards without any casing
<ogra_> but pretty please stop this topic now
<Zero_Chaos> ogra_: it was my intent to say that using the term "cosmic rays" for seemingly random failures is confusing for new users and should be avoided.  I'm sorry this point confused so many people in here.
<ogra_> https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036776.html
<Zero_Chaos> interesting
 * micahg shows Zero_Chaos the retry build has made it past where it was: https://launchpad.net/ubuntu/+source/octave/3.6.4-1/+build/4325207, hooray for Cosmic Rays :)
<Zero_Chaos> micahg: yeah, random hardware failure does the same thing all the time. especially heat and RAM issues
<Zero_Chaos> micahg: but hey, you are welcome to think whatever you like, I realized long ago that if you don't listen I shouldn't care either
<micahg> if you want people to listen to you, it doesn't hury to listen first ;)
<micahg> s/hury/hurt/
<Zero_Chaos> micahg: I did listen. you think cosmic rays messed up your build. I think it's just as likely that a ghost did it.
<micahg> [09:06] <micahg> Zero_Chaos: being that the build machines are in a unique case, we refer to cosmic rays as random failures to due HW env
<Zero_Chaos> micahg: yeah I read that, and I was trying to say that people reading that assume you mean real cosmic rays not using it as a euphemism for "something failed and I don't know what"
<Zero_Chaos> micahg: thus, causing entropy and stupidity in the general populace
<Zero_Chaos> micahg: and since like three people have "stood up to me" in the last hour to tell me how cosmic ray can actually affect building, I stand by my point.
#ubuntu-arm 2013-03-05
<zorky> Anyone here who can help me? Im trying to setup x2go on an arm based thin client running ubuntu 10.04 but the packages i need is not in the repository, ports.ubuntu.com/ubuntu-ports
<zorky> the arm cpu in working on is armv71
<infinity> zorky: Why 10.04 instead of 12.04?
<zorky> infinity, i have no idea. i got the image from the producer of the thin client
<infinity> Well, if you're looking for x2goclient (I assume?), it doesn't exist in any release earlier than raring on *any* architecture, this isn't ARM-specific.
<infinity> So, you could grab the precise sources and try to backport them to lucid, but no idea how much work that may or may not be.
<ogra_> doesnt x2go include a whole copy of its own X libs ?
<zorky> i need to figure out how to upgrade the thinclient to 12.04 then
<ogra_> shouldnt be hard to backport
<zorky> well i only have around 3 month of experience with linux. im not that good at this. so i dont know how to backport
<infinity> And where I said "raring" up there, I meant "precise".  I'm a bit tired.
<infinity> Ahh, looks like there's an x2go PPA with everything built for lucid.
<infinity> Of course, x86 only...
<infinity> Cause it's a PPA. :/
<infinity> But you could grab the sources and build them locally.
<infinity> https://launchpad.net/~x2go/+archive/stable/+packages
<zorky> ehh, thats the problem. i dont know to to build them
<zorky> so far, the easiest way for me to do this. is to upgrade the thin client to 12.04?
<infinity> Or add that PPA to your sources.list as a deb-src entry and do some "apt-get build-dep $source && apt-get --build source $source" iterations over the packages you want.
<infinity> But if you can make that machine run precise, that wouldn't be a bad idea anyway.
<infinity> You may find that if it has a custom kernel and some fancy drivers, that turns out to be a really bad idea, though. :/
<zorky> i think it has a custom image running on it, but im not completely sure about it either
<zorky> anyone know how i install 12.04 on an armv71?
<ogra_> i think yu mean an ARMv7l
<ogra_> (small L ... not 1)
<ogra_> zorky, and it depends on your device ...
<zorky> ohh
<zorky> it's a chip pc lxd 8541
<ogra_> generally the userspace will just run on any v7 device ... but you need to provide a kernel and bootloader setup yourself (and have a bit experience with arm stuff)
<ogra_> the only installable ubuntu images we currently provide are for toshiba ac100 netbooks, pandaboards and the nexus7 tablet ...
<ogra_> and then there is ubuntu touch (see the #ubuntu-touch channel) which runs on all devices supported by cyanogenmod 10.1 (android)
<zorky> hmm
<zorky> will look into it tom, i sent a mail to the device manufature to ask for a 12.04 image
<sspiff> hi, does anyone know anything about this: http://malideveloper.arm.com/develop-for-mali/drivers/open-source-mali-gpus-linux-kernel-device-drivers/ - has anyone tried using these drivers?
<ania_> hi all
#ubuntu-arm 2013-03-06
<xnox> ogra_: are you around?
<davmor2> xnox: No I'd say ogra_ was more oblong ish
<ogra_> xnox, i'm here now
<Tassadar> chm, that's weird, I'm getting crc error when trying to extract rootfs.tar.gz in Nexus 7's daily image Oo
<Tassadar> ogra_: has the way nexus 7 image is built changed lately?
<ogra_> nope
<Tassadar> then what the hell am I doing wrong Oo
<ogra_> i'll take a deeper look after UDS tomorrow or friday
<Tassadar> okay, thanks
<Kris_CGo> I figure this would be the best place to ask(since people develop on desktop for ES2 devices all the time): What's an easy way to use OpenGL ES2 on ARM and desktop? What OGL version does the desktop need to be to do ES2, 3.0? I'm from the land of OGL1 and D3D9...
<NekoXP> the *easiest* way? install the EGL/GLES2 packages for Mesa and use llvmpipe as the backend.. that is slow as poop, but it'd work.
<NekoXP> most of the desktop composition engines like Compiz use ES2 right now, there's not a good deal of point using ES3.. all it adds is (guaranteed) higher precision shader support and a few extra useful functions that already exist in most ES2 implementations
<Kris_CGo> Well my computer is fast and mobile things are slow... so in a way that works out. I guess I'll stick with ES2 only since a lot doesn't support ES3.
<Kris_CGo> Found mesa-utils-extra , has es2gears, es2_info and es2tri in it , yay it "just werks" I get 850 fps instead of 4800 fps, plenty usable
<NekoXP> anyone here used cdebootstrap --foreign and then something like schroot to get into the filesystem and continue emulated under qemu?
<ogra_> why would we ? there are way better tools (qemu-debootstrap from qemu-user-static)
<NekoXP> well, I have my reservations about qemu-debootstrap as it stands (I usually opencode what it does in a more efficient way, derived from how schroot manages it...)
<NekoXP> I don't like running a VM to do the work, I'd rather do it in a chroot.. and cdebootstrap handles some things slightly better. it's mostly an experiment but the damn thing keels over if you use --foreign for some reason.
<ogra_> what VM ?
<ogra_> it sets up your kernel via binfmt support to be able to execute armhf binaries and then just bootstraps n armhf chroot
<NekoXP> qemu VM.. like build a disk image, run a "real" kernel, then tar up what's inside the disk image kind of thing. Like rootstock did before it got the ability to chroot ;)
<ogra_> nothing to do with VMs
<ogra_> it just gives youz are dir you can chroot into
<NekoXP> btw qemu-debootstrap is about 160 lines too long for what it does
<ogra_> complain to debian :)
<ogra_> the original i wrote was like 4 lines
<ogra_> when they took it they bloated it
<NekoXP> loic seemed to get hold of it. he wasn't "debian" when he did that ;)
<ogra_> well, whatever :)
<ogra_> he pushed it to debian
<ogra_> (saving us the maintenance ... so i'm fine with a 160 line overhead)
<NekoXP> anyway regardless, it's not the copying of the qemu binary into the right place I have a problem with it's that cdebootstrap doesn't seem to work.. probably because nobody uses it. If I do it all native it has a real and measurable performance advantage.. but all the docs say "do --foreign and then run that output on a real system"
<NekoXP> problem is that second step fails by going in via qemu-enabled chroot  AND on a real native system
<ogra_> well, i doubt anyone in ubuntu uses it
<ogra_> so better complain to debian
<NekoXP> I can't imagine it is totally broken because live-build uses it
<NekoXP> I guess I'll go ask the debian guys :)
<NekoXP> btw what's the status on rootstock, I thought it was dead as a doornail but it seems semi-actively developed (there's a GUI!?)
<ogra_> rootstock is long dead
<ogra_> like 2 years or so
<NekoXP> code committed to bzr in 2012 though.. I know you don't touch it anymore I wondered if it was sanctioned or just some guys poking at the old code
<ogra_> i think vanhoof keeps it in zombie state still
<ogra_> i handed it over to him after it was largely unmaintained for a year
#ubuntu-arm 2013-03-07
<xnox> nexus7 charging dock is available, it keeps the usb port free - https://plus.google.com/112773496741623034196/posts/9iyD4fC688i
<lilstevie> thats pretty cool
<twb> An HP t410 "thin client" just landed on my desk, and I want to bypass the HP crap and netboot images a la PXE.  A quick google suggests nobody has jailbroken these yet.  Anybody here heard any diferent?
<twb> Oh look, the menus give you a root shell
<twb> OK, so its existing image is booting off mtdblock, and it's got a 2.6.37-atlas uImage in /boot
<twb> That means it's using u-boot as the bootloader, right?
<infinity> twb: Seems plausible.
<twb> I can see the mtdblockN's but I don't know where I'd find the uboot config file (if there is one)
<infinity> twb: Well, there could be an external config file on the same partition at the u-boot binary, if it's loading in the "first FAT partition" mode, or it could be burned into firmware, and u-boot has no config file, cause you're expected to setenv/saveenv from the u-boot prompt.
<infinity> twb: The latter could prove problematic if there's no way to SEE a u-boot prompt.
 * twb runs blkid on all the block devices he can dfind
<twb> Apparently files.sotmarket.ru/instr/nettopy/hp/manual_hp_t410.pdf confirms that it's uboot
<twb> Can only see a ext3 filesystem and a filesystem.sq inside it
<twb> And yeah, when you boot it up, the screen doesn't appear to turn on until X starts
<twb> (It's a single plastic box with an LCD and an arm computer inside; I haven't taken the housing off yet, so I dunno if there-
<twb> aha, mtdblock5 is a uboot/ppcboot
<twb> no sign of a fat with uboot config file yet
<twb> Sweet, found the uboot config tools -- they are fw_* not u*[bB]oot* which is why I didn't spot them
<darkfader> hi... did anyone find out news about the gps in the nexus7?
<zorky> hey. anyone here who can help me. i just got my  raspberry pi 512mb, and i need to get an os on the sd card. how do i do that? do i need a sd card reader or can i plug the raspberry in the computer with an usb cable?
<mosasaur> 512 mb is maybe a bit small for a modern os
<zorky> it's the model 2 with 512mb ram.. do i really need a sd card reader to install the os with? or can i connect it to the computer?
<infinity> zorky: Ubuntu can't run on the Pi, so this is likely the wrong channel to be asking in.
<infinity> zorky: http://www.raspbian.org/
<infinity> zorky: The answer to your question, however, is that if the Pi doesn't currently have an OS, there's no way to use it to read/write an SD card, so you'd need to do so an another machine, yes.
<infinity> s/do so an/do so on/
<Rjs> memory requirements depend entirely on what you're doing with it - 512Mb is plenty for many uses, including some graphical ones (e.g., my current desktop system uses 123 Mb right now, and an embedded PC I use as a digi-tv recorder uses 42 Mb, and I haven't done anything special to lower the memory use)
<Rjs> but (as far as I've gathered) Ubuntu doesn't particularly target low-memory systems or use cases, so that may be another reason why this is the wrong channel :)
<infinity> Rjs: Memory has nothing to do with it, the Pi is armv6, and Ubuntu literally *can't* run on it.
<ogra_> infinity, do you have any idea whom i should ping about dropping panda desktop images ?
 * ogra_ is rwally not sure who can make such a decision
<ogra_> *really
<ogra_> but it doesnt look like we'll have pvr support in the long term
<ogra_> even mid term
<infinity> ogra_: I'm happy to take that decision, and any fallout from it.
<infinity> ogra_: Technically, Jason Warner "owns" the product, but I doubt he has an opinion.  You can ask to be nice, though.
<ogra_> ok, will do
<xnox> ogra_: if you drop panda desktop, I'm shipping my panda to become a buildd, as nexus7 fully furfills my armhf needs. And panda here was a server / ubiquity-desktop testbed.
<xnox> (server as in always on buildd, but I can totally fiddle with charging nexus7 in a more timely fashion)
<xnox> (or whatever is the best use of an extra pandaboard - live builder / qa test machine / etc)
<ogra_> yeah, well, if you want to do native builds an USB disk on a panda is definitely way better than building on the MMC of the nexus
#ubuntu-arm 2013-03-08
<prpplague> ahh man
<prpplague> the #ubuntu-arm channel has really lowered it's standards
<prpplague> specially when they let people like rsalveti in here
<rsalveti> prpplague: haha, what happened?
<Zero_Chaos> prpplague: hey!
<Zero_Chaos> prpplague: I try to lower the standards here every day
<prpplague> Zero_Chaos: well you succeeded
<prpplague> rsalveti: hehe
 * prpplague jokes with rsalveti 
<Ohad> Hello, anyone knows how to enable autologin in Beagleboards' ubuntu?
<mosasaur> I wonder how I can make alsa use my soundcard, it's an U1YMU823 (on a galaxy note GT-N7000). So far, alsamixer (in a chroot) can control the sound volume of apps started from android, but when I use aplay I get "pcm_write:1710: write error: Connection timed out".
<plars> ogra_: probably pretty late for you, but did you see https://bugs.launchpad.net/ubuntu-nexus7/+bug/1152568
<ubot2`> Launchpad bug 1152568 in ubuntu-nexus7 "Ubuntu Desktop Preinstalled armhf+nexus7 for Raring Daily fails to complete the installation" [Undecided,Confirmed]
#ubuntu-arm 2013-03-09
<jabulmer12> hey
<jabulmer12> looking for a little bit of help if any ones around?
<jabulmer12> any one?
<RoyK> it sucks rather hard that ubuntu won't run on the raspberry pi
<tassadar__> why do you want to run ubuntu there? Oo
<RoyK> because galicaster uses a bunch of things and is built on ubuntu
<tassadar__> are you sure that rPI is even powerful enough to run that?
<liono> hi everyone, I'm thinking about getting a samsung chromebook and using crouton. my only question is: what do the ARM repos look like--can you easily install Pidgin, say, or Skype?
<liono> and is there a list of software available anywhere?
<Zero_Chaos> liono: skype is binary crap, so you almost certainly can't use it on arm.
<Zero_Chaos> hell, it barely works on x86
<Zero_Chaos> liono: but anything open source is easy enough to build if it's not in the repos
<xnox> ogra_: I'm about to demo flashing nexus7 with ubuntu touch/core.
<xnox> do we have working latest images?
<ogra_> http://cdimage.ubuntu.com/daily-preinstalled/last-good-image/
<ogra_> (which is the one from the 4th) ...
<ogra_> todays should just be building
<liono> Zero_Chaos: I'm trying to decide whether to go with the c7 (x86) or the samsung (ARM). I realize that I can build stuff but I'm wondering how often I'll have to do that
<Zero_Chaos> liono: all the basics are definately there. the arm port is reasonably complete. at least the raring one that I was playing with was. I'm guessing the precise one was good too
<ogra_> liono, 90% of the ubuntu archive are available on arm ... no need to compile stuff usually
<liono> oh wow, that's a lot more complete than I thought it would be
<ogra_> indeed, binary x86 stuff like skype isnt available ...
<Zero_Chaos> liono: most of the open source stuff *just works* so it's easy to just recompile
<Zero_Chaos> liono: ie it's already in the repos
<liono> yeah that's fine re: skype, I was just throwing that out there as a 'hard one'
<liono> and it looks like dropbox allows you to compile it from source...this ARM chromebook is looking better every second
<ogra_> if you use a chromebook it has the advantage that you can dual boot ... and for things like google hangouts you just switch over
<ogra_> so there is *some* binary crap working ;)
<liono> :)
<ogra_> (oh and flash indeed)
<liono> I like crouton's way of simul-running distros
<liono> er simul-running chromeos and xubuntu
<liono> dang, it looks like skype offers a .tar.bz2
<ogra_> with x86 binaries, yes
<liono> ha
<liono> I was just getting it to open it
<ogra_> there are even ubuntu packages in the canonical partner repo
<liono> :p
<liono> arm packages in partner?
<ogra_> nope
<liono> dang
<ogra_> there are no arm binaries from microsoft ... at least none that would run on linux
<ogra_> one might be able to rip them out of a cracked surface RT ... but then you would need wine on arm to have support for RT to execute it... which it doesnt
<liono> pretty tricky
<liono> just realized I'm relying on spotify for a lot of my music
<liono> which deffo is not open source and not compiled for arm
<xnox> ogra_: yeah, using last-good and it works. ok.
<liono> well thank you guys so much for your help! I have some thinking to do
<ogra_> heh, FSVO Ok
<liono> catch you later!
<ogra_> xnox, have a keyboard ready :)
<xnox> ogra_: i'm demoing preseeding, so no keyboard needed =)
<ogra_> hehe, youre cheating :P
<xnox> ogra_: i showed them usb-creator flashing nexus7 and everyone loved it.
#ubuntu-arm 2013-03-10
<lilstevie> <ogra_> one might be able to rip them out of a cracked surface RT ... <-- you really wouldn't need it to be cracked, you have full admin access on Windows RT, the only policies are you cannot run unsigned binaries or drivers
<aladdin> hello
<aladdin> chromium 25 build failed because headers missing :(
<aladdin> https://launchpad.net/ubuntu/+source/chromium-browser/25.0.1364.160-0ubuntu1/+build/4358080
<aladdin> v8/src/../include/v8stdint.h:34:19: fatal error: stdio.h: No such file or directory
<aladdin> https://launchpad.net/ubuntu/+source/chromium-browser/25.0.1364.160-0ubuntu1/+build/4358080
<yunfan> hi i came here for asking if there is any plan for supporting ubuntu on samsung's arm chromebook?
<ogra_> ynezz, not officially, but there is a lot chromeboot work from the community and it works flawless with ubuntu
 * ogra_ hugs xnox 
<ogra_> lilstevie, well, then you would need to crack the signature ... carcking would be involved somewhere in the process :)
<lilstevie> ogra_, why would you need to crack the signature, low integrity level code (metro apps) don't have the same code sign integrity, also you could just not worry about checking the sig in wine for arm :p I think the bigger task is trying to emulate the metro APIs
<ogra_> heh, yeah, well, thats a requirement in general for wine :)
<lilstevie> yeah
<yunfan> ogra_: i have installed the chrUbuntu
<yunfan> but that's lack of multi-touch supoport
<yunfan> and its X is reaaaaaly slow while the tty is quite flex
<ogra_> yunfan, using unity ?
<ogra_> (and sorry ynezz)
<yunfan> ogra_: yep, i just wondering if they have some debug code like sleep 99999
<ogra_> haha
<ogra_> no
<ogra_> but there is definitely something wrong with the GLES support for mali ...
<yunfan> everytime when i press the key, i need to wait for the terminal window's response action
<ogra_> gles itself runs fine for me but unity seems ot still do SW rendering nontheless
<ogra_> oh, its not that bad for me
<ogra_> its actually usable ... just not as fast as it could be, did you copy the binary libs from chromeos ?
<yunfan> i heard that ubuntu touch would be run on galaxy note2 which share the same cpu with my chromebook
<yunfan> i didnt , just follow the install step from chrUbuntu
<ogra_> ubuntu touch is based on cyanogenmod
<yunfan> mabybe they did in that shell script
<yunfan> oop
<ogra_> unless someone has chromebook support added to that it wont "just run" with code from another device
<ogra_> and ubuntu touch doesnt use X at all
<yunfan> got it, that's why you have ac100 supporting?
<yunfan> i also own an ac100
<yunfan> which after update to the armHF version, runs very fast
<ogra_> i started the ac100 port several years ago ... there wasnt even a tought for ubuntu touch ...
<yunfan> but the battery life is terrible
<ogra_> and keeping ac100 alive was a constant matter of pain dealing with the binary drivers
<lilstevie> also ac100 is very much a netbook
<ogra_> i still love my ac100 and the 8-9h battery life are definitely unbeaten
<lilstevie> IMO much better suited to a desktop environment though
<yunfan> so the simple answer is there're not an official plan for supporting samsung's chromebook ?
<ogra_> but 512M just hurt
<yunfan> well by using LXDE, i feel the ac100 is just enough , but the battery which is a real problem , i cant accept 1.5 hour
<yunfan> and its powerline is ugly
<ogra_> yunfan, canonical wont support it ... but hrw did already so much packaging work that we could probably build images for it at some point if someone does the work to implement that in the build system
<ogra_> yunfan, your battery is clearly broken
<ogra_> i get 8-9h out of one charge
<yunfan> ogra_: i have send to the factory and they told me its normal :[
<yunfan> ogra_: well another question
<ogra_> and i own three ac100's which all get me that
<hrw> yunfan: you really want to abandon unity/3d in favour of something working
<ogra_> hrw, no, you want to file bug reports and pester daniel van vugt :)
<hrw> ogra_: I dropped opengles driver from ppa
<hrw> ogra_: no redistribution license
<yunfan> ogra_: can you recommend a quick turtorial for my learning arm asm ? i am a python engineer currently, i knew those binary trans 2's complement number things
<ogra_> good move ... better have a howto for people to copy the stuff from chromeos
<hrw> ogra_: will do such
<ogra_> yunfan, so your answer is, no, chromebook will never get official support, but it might come to a level where the ac100 is at some point
<ogra_> (which never was officially supported)
<yunfan> ogra_: that's good if it could arrive the ac100's level
<hrw> yunfan: so far there are nearly no people doing work which ac100 community did
<yunfan> ogra_: what about my secondary question?
<ogra_> building image is a matter of someone investing the time into implementing that in the build system ... for ac100 it was me who did that in his sparetime ... i dont currently have that much of spare time to do it again for a new device
<hrw> I packaged kernel, handled opengles, x11 driver and had fingers in few other places but my time is limited
<yunfan> hrw: yep, but sonner or later , people would do that, its just that device is in really use
<hrw> during Linaro Connect Asia I was fully ARMed - did not took x86 at all
 * ogra_ does that since 3 years :)
<ogra_> but i'm a masochist if it comes to HW :)
<hrw> :D
<yunfan> guys, can you recommend a quickly arm asm turtorial for me plz?
<yunfan> btw, i prefer att syntax
<ogra_> the arm page might have some
 * ogra_ tries to stay away from asm if possible
<yunfan> its not that quick by therir documents
<hrw> asm?
<hrw> why anyone wants to learn asm
<yunfan> yep
<hrw> ~armarm
<yunfan> because i want to port my forth impl on arm platform
<hrw> yunfan: do it in C
<ogra_> use gcc atomics
<hrw> C version will be faster, trust me
<yunfan> which require emmit machine code while doing metaprogramming
<yunfan> hrw: true man wont use c for their own forth  :]
<hrw> C ver can also be tunned for a8/a9/a7/a15/a53/a57/aWHATEVER
<ogra_> even if there is a massive performance advantage over asm ?
<hrw> good luck with hand tuning for a7/a15
<yunfan> its just joking : ] i am intereting of low level things
<ogra_> (and portability across the different arm arches)
<yunfan> but i dont like x86, so what i can choose is mips or arm. consider that i have two arm devices , so i choose arm
<ogra_> well, i'm not touching asm ... and honestly never had to apart from fixing horrid stuff of people that (falsely) thought they need asm in their code to be fast
<ogra_> so i cant point you to a tutorial ...
<yunfan> i am just reading CSAPP the greate book which lead me so interesting of low level things
<ogra_> well, try #linaro during the week, you might find some asm specialists there
<yunfan> no i am not need asm for just be fast, as a python engineer, i knew that most times implments that i wrote in c wont be faster that the python official's
<ogra_> (but i'm pretty sur ethey'll tell you the same)
<lilstevie> the only time we use ASM is for payloads that need to be super small
 * lilstevie doesn't know asm
<lilstevie> :p
<yunfan> i want to learn asm is that i am interesting of it and the low level things made me understand easier by the simple term and less complex
 * ogra_ knows some from his teenager days ... but thats looooong ago
<yunfan> i will try that , thanks ogra_
<lilstevie> that is a single case where asm is probably the better approach though, the whole bootloader situation on x86 is a good show of why doing something in asm is a bad idea
<lilstevie> syslinux or grub would be wonderful on arm
<yunfan> ogra_: as a chinese , i might just acts like your teanager in CS knowledges ,i bought PC when i was in college
<ogra_> lilstevie, there is some arm code in grub ...
<ogra_> just nothing finished ...
<hrw> lilstevie: I saw grub on arm already
<hrw> Linaro is working on it
<lilstevie> hrw, heh yeah, but it is still nowhere near ready from what I've seen
<marvin24> hi, I'm about to add http://paste.ubuntu.com/5602702/ to our version of flash-kernel
<marvin24> it copies the right device tree from /lib/firmware to /boot
<marvin24> so uboot can find it
<marvin24> does this makes sense or is it totally bogus?
<marvin24> ok, it's totally bogus to ask such questions on sunday eve
<marvin24> (install to /etc/kernel/postinst.d, if someone wonders)
<ogra_> marvin24, you mean to your kernel package, not flash-kernel, right ?
#ubuntu-arm 2014-03-03
<pranav> how to install ubuntu from busybox ?
<pranav> i installed ubuntu on my arc-machine.. where can i get a small dekstop manager?
<pranav> *arm
<pranav> hello guys!
<pranav> ok, i tranferred the file system and kernel binaries to my arm-device. it boots busybox. how should i proceed to boot ubuntu dekstop manager (lightweight) ?
#ubuntu-arm 2014-03-04
<pranav> how to list the devices that are connected using terminal. I want to change my stdout to LCD instead of serial console ?
<pranav> i am running kubuntu 12.04 kernel in embedded device using serial console, I want to access LCD. how to approach this ?
<ndec> hi ogra_, it's been a while since i haven't looked at ubuntu/arm (probably since 12.10...). with all the mir stuff that has happened, what will the situation look likein 14.04 for armhf? does unity desktop use mir by default or xorg? if xorg, is it based on egl or glx?
<ogra_> xorg
<ndec> ok, so if we i build an 14.04 image with ubuntu-desktop, it doens't pull mir at all, right?
<ogra_> it still used gles in raring when we did the nxus7 desktop image ... not sure if that still works though
<ogra_> i dont thinnk anyone has tested any xorg stuff on arm since raring
<ndec> where was the egl stuff configured/hardcoded for arm?
<ndec> in which package.
<ogra_> (all UI arm focus is on Ubuntu Touch ... with is 100% Mir)
<ndec> i see.
<ogra_> that was in compiz
<ndec> what happens if i need/want an arm image with 14.04 with unity-desktop. how feasbile (or not) do you think that is.
<ndec> i don't mean an official image from you guys, but something i build.
<ogra_> well, you would have to test if there are any new GLES bugs (or if someone perhaps dropped GLES support from compiz/unity7)
<ogra_> beyond that i wouldnt expect it to be different from 12.04
<ndec> what if i want a GL/GLX solution?
<ogra_> on arm ?
<ndec> yep
<ogra_> you would most likely have to rebuild everything that uses GLES against it
<ogra_> at least for the build time pieces
<ndec> ;-)
<ndec> when was compiz/egl/gles last tested on your side?
<ogra_> during raring
<ogra_> a year ago perhaps
<ndec> ok...
<ogra_> or more
<ndec> ogra_: so, if i make an ubuntu-gnome-desktop image instead it wouldn't pull compiz, but gnome-shell and that would be a GLX/GL not gles, is that correct?
<ogra_> no idea, you would have to check :)
<ndec> i was expecting you would tell me that!
<ogra_> i think back in raring i saw a good bunch of GLES patches to gnome
<ogra_> and iirc it ran quite well accelerated on the tegra on the N7
<ogra_> so i would suspect there is GLES by default on arm builds
<ndec> ok. thanks. i will check this stuff.. i just wanted to have an idea before starting...
<ndec> to deep dive
<ogra_> use Mir :P
<ogra_> so much easier :)
<ndec> ogra_: well, that's a perspective ;-)
<hrw> ogra_: can Mir be used without binary blobs from android?
<ogra_> hrw, on x86 it can ...
<ogra_> it runs on all free drivers and on andrtoid blobs atm
<hrw> but no fbdev? D:
<ogra_> nope
#ubuntu-arm 2014-03-05
<pranav> i installed kubuntu iso for embedded device on my flash. evrything is fine, but ends with a busybox atop of bare kernel.
<pranav> how can i transfer the std i/o to LCD ? please help
<Valduare> hi
<Valduare> I have an mk802 that I'm trying to get picuntu going on
<Valduare> apparently the internet has sped on past me cause all the guides and file links are for mk802 III and IV and all the future versions lol
<Valduare> needing some help
<ogra> Valduare, did you try and picuntu forum, mailing list or channel ?
<Valduare> was not finding a channel
<Valduare> do you know what it is
 * ogra never heard of picuntu ... by the looks of it it seems to be very far from a default ubuntu setup with many hacks
<Valduare> I have an mk802 clone
<Valduare> needs pressed into service to run a label printer
<ogra> well, ask someone from picuntu ... nobody in here knows their installer scripts and hacks
<Valduare> hmm
#ubuntu-arm 2014-03-06
<pranav> i am using using armv7 GNU/Linux, when i use wpa_cli a netgear router doesn't shows up, despite it shows up in all other devices. any possible reason ?
<Valduare> hi guys
<Valduare> I have an mk802_a10s soc
#ubuntu-arm 2014-03-07
<akp> hi, does anyone know of any arm boards with a 16x PCI-e slot?
<hrw> akp: nope
<akp> hrw: how about a PCIe slot in general?
<ogra_> some marvell dev boards have PCI and PCIe
 * ogra_ remembers the dove board had 4 slots 
<hrw> akp: imx6 has pcie x1 and some boards provide it as a slot - but usually as minipcie
<akp> =/
<akp> ok
<hrw> and like ogra_ said - marvell boards have more pci/pcie slots
<akp> i haven't seen any from marvell
<hrw> akp: I did. few years ago - fullsize atx board with plenty of slots, sata ports and ethernets
<akp> well i meant on their site right now
<ogra_> and usually close to a 5 digit price
<akp> ahh
<akp> yeah i can pass on that =/
<hrw> akp: what for yuou need x16 slot?
<akp> i guess it can be 4x or even 1x electrically
<akp> but this card i have is 16x
<akp> i have someone asking me to try something use the cave creek plugin card
<akp> and an arm board
<hrw> 4GbE network card?
<akp> yeah that crazy thing
<akp> http://www.adiengineering.com/wp-content/uploads/2012/10/CPICOnePager-10112012.pdf
<hrw> strange. 4x1GbE requires x16 while 10GbE is fine with x8
<akp> yeah, i guess i could always try to get one of those break out deals
<akp> that will give me an adapter to plugin to mPCIe
<hrw> akp: you know that minipcie is just x1 right?
<akp> yeap
<akp> hello
<akp> i am getting this error when i try to connect to the webserver - java.security.cert.CertificateException
<akp> : No name matching <server> found
<awasj> hi folks, I've got ubuntu (from http://elinux.org/BeagleBoardUbuntu) on a BeagleBoard but struggling to get hold of kernel source, could anybody give me a pointer in the right direction please?
<coreyfro> Hello all. A week ago I was building just fine, but recently, I am having bootstrapping trouble with package libgcc1 (dpkg: dependency problems prevent configuration of libgcc1:armhf: libgcc1:armhf depends on gcc-4.9-base (= 4.9-20140303-0ubuntu2); however:  Version of gcc-4.9-base:armhf on system is 4.9-20140303-0ubuntu3.)
<coreyfro> I think this is a problem with the repo or possibly a problem with libgcc1 package
<coreyfro> This problem exists in both Trusty and Precise
<coreyfro> So, I have a multistrap script and config that used to build my entire debian distro in less than two minutes.  It worked until last week and it broke with the following error: dpkg: dependency problems prevent configuration of libgcc1:armhf: libgcc1:armhf depends on gcc-4.9-base (= 4.9-20140303-0ubuntu2); however:  Version of gcc-4.9-base:armhf on system is 4.9-20140303-0ubuntu3.
<coreyfro> Here is a document will all my configurations, all my scripting, and all of my errors : https://docs.google.com/a/typeamachines.com/document/d/1pELrg7NcrE32-zOaflnsd2fLWZ_IjVI-YfeaHG3hA6k/edit
<coreyfro> This is a script that ANYONE CAN USE to build ANY ARMHF image they'd like...and it was working until last week.
<coreyfro> I think it is an asset to the community, but now, it's not working
<coreyfro> What's going on?  Is this a problem with the repo?
<coreyfro> OK, where do I report this, specific, bug?  To the people behind the PPA?  To the package maintainer?  Where do I get this ball rolling?
#ubuntu-arm 2014-03-08
<xnox> coreyfro: don't use unstable, don't use trusty-proposed.
<xnox> coreyfro: they by definition, can be out of sync like that.
<coreyfro> xnox obviously you didn't read that this is happeing in both precise and trusty
<coreyfro> let me reiterate
<coreyfro> Hello all. A week ago I was building just fine, but recently, I am having bootstrapping trouble with package libgcc1 (dpkg: dependency problems prevent configuration of libgcc1:armhf: libgcc1:armhf depends on gcc-4.9-base (= 4.9-20140303-0ubuntu2); however:  Version of gcc-4.9-base:armhf on system is 4.9-20140303-0ubuntu3.)
<coreyfro> I think this is a problem with the repo or possibly a problem with libgcc1 package
<coreyfro> .,.,.,.This.,.,.,.problem.,.,.,.exists.,.,.,.in.,.,.,.both.,.,.,.Trusty.,.,.,.and.,.,.,.Precise.,.,.,.
<coreyfro> So, I have a multistrap script and config that used to build my entire debian distro in less than two minutes.  It worked until last week and it broke with the following error: dpkg: dependency problems prevent configuration of libgcc1:armhf: libgcc1:armhf depends on gcc-4.9-base (= 4.9-20140303-0ubuntu2); however:  Version of gcc-4.9-base:armhf on system is 4.9-20140303-0ubuntu3.
<coreyfro> Here is a document will all my configurations, all my scripting, and all of my errors : https://docs.google.com/a/typeamachines.com/document/d/1pELrg7NcrE32-zOaflnsd2fLWZ_IjVI-YfeaHG3hA6k/edit
<coreyfro> This is a script that ANYONE CAN USE to build ANY ARMHF image they'd like...and it was working until last week.
<coreyfro> What's going on?  Is this a problem with the repo?
<coreyfro> Where do I report this, specific, bug?  To the people behind the PPA?  To the package maintainer?  Where do I get this ball rolling?
<coreyfro> I just build a new image for precise
<coreyfro> I am testing it under qemu right now
<xnox> coreyfro: precise does not have gcc-4.9.
<xnox> $ rmadison -s trusty gcc-4.9-base ligbcc1
<xnox>  gcc-4.9-base | 4.9-20140303-0ubuntu3 | trusty | amd64, arm64, armhf, i386, powerpc, ppc64el
<xnox> $ rmadison -s trusty libgcc1
<xnox>  libgcc1 | 1:4.9-20140303-0ubuntu3 | trusty | amd64, arm64, armhf, i386, powerpc, ppc64el
<xnox> looks correct to me.
<xnox> coreyfro: but if you use trusty suite with trusty-proposed suite enabled, it's not guaranteed to be installable at all times.
<xnox> coreyfro: ditto precise with precise-proposed suite enabled.
<coreyfro> I don't know if it is getting Proposed, I have my config grabbing main and universe
<coreyfro> source=http://ports.ubuntu.com/; suite=precise; components=main universe ;
<coreyfro> If it is picking up proposed, I need to figure out how to mask that out (to use a gentoo term)
<coreyfro> Precise just ran without changes to my scripts or configs
<coreyfro> Trying with trusty
<coreyfro> Trusty built, testing
<coreyfro> Trusting still having errors, but at least I have precise built
<coreyfro> Who would I report these errors to?
#ubuntu-arm 2014-03-09
<applepi> Hi all..  I'm trying to work out how to get ubuntu onto an ARM system that isn't one of the specific architectures it's already been imaged for..
<applepi> With debian I can debootstrap for armel, however with Ubuntu ARM I only see it for specific flavors (OMAP, imx5, etc)
#ubuntu-arm 2015-03-04
<frobware> Is it realistic for me to boot the vivid 3.19 kernel on trusty (xgene/mustang)?
<genii> frobware: Now to wait ;)
<frobware> genii, hi! Again. :)
<genii> frobware: Is there some issue with your 14.04 kernel? I'm just being curious
<frobware> genii: No especially. However, I'm testing latest kvm and need accompanying fixes in the kernel. The advice was to go to 3.19.
<genii> Interesting.
<frobware> genii: I built 3.19 from source (kernel.org) and booted fine. I tried installing devstack/stack.sh and ran into dpkg errors and thought maybe a more "official" Ubuntu kernel might be in order.
<genii> frobware: Have you looked at https://wiki.ubuntu.com/ARM64/FoundationModel yet?
<frobware> genii: too slow when you have h/w  :)
#ubuntu-arm 2016-03-07
<xcoder> Hi
<xcoder> I want to build my wifi nano adapter for Mate to run on raspbery pi 2
<xcoder> Could anybody tell me which kernel Mate uses
<xcoder> and which toolchain I can use to build the driver ?
<xcoder> nobody is responding
<xcoder> is this a dummy room?
<xcoder> or nobody has required knowledge to reply to my queries
<k1l_> yep
<rbasak> flexiondotorg: ^
<ogra_> i think flexiondotorg uses the linux-raspi2 kernel from the archive ... but xcoder is gone anyway
<flexiondotorg> ogra_, rbasak I use the Raspberry Pi Foundation kernel for Ubuntu MATE.
<flexiondotorg> I'd prefer not to, but this was something the makers I meet with were very keen to see implemented.
<flexiondotorg> I'll be working on alternative images for 16.04 that use the proper linux-raspi2 kernel.
<richieacc> Greetings. I have just installed Ubuntu Mate on my new RaspberryPi 3. It's amazing. I'm loving this combo. I'm trying to program my Arduino from it. In Arduino IDE I'm getting the error, "sudo: no tty present and no askpass program specified." I've figured that I need to add something to the sudoers config file. But I'm not sure what command needs to be added. I've put a tail on /var/log/auth.log, and that shows the authentication att
<caden> Hey, I am having very choppy audio on my Raspberry Pi 2B running Ubuntu Mate 15.10. Help?
#ubuntu-arm 2016-03-09
<zzarr> hello! I'm trying to build Qt 5.5 for aarch64 (arm64), the configuration goes fine "Src/configure -opensource -confirm-license -prefix /usr/local/Qt-5.5/arm64 -xplatform linux-aarch64-gnu-g++"
<zzarr> "make" goes fine as well
<zzarr> but when I run "sudo make install" I get this error: ".obj/home/zzarr/Qt/5.5/Src/qtimageformats/src/3rdparty/libwebp/src/dsp/dec.o:dec.c:function VP8DspInit: error: undefined reference to 'VP8DspInitNEON'"
#ubuntu-arm 2016-03-10
<bgardner> Good afternoon everyone.  I'm working on setting up a rootfs from http://cdimage.ubuntu.com/ubuntu-core/releases/14.04/release/ubuntu-core-14.04.4-core-armhf.tar.gz  My question is, how do I add users to this?  The docs say it comes with no users defined, which makes sense, but while this works: "sudo useradd --root /path username", this does not: "sudo passwd --root /path username"
<bgardner> It replies with "passwd: Cannot determine your user name."  I take this to be because my host is x86_64 and the rootfs I'm trying to build is armhf.  Trying to chroot straight there gives me "chroot: failed to run command â/bin/bashâ: Exec format error", which also makes sense.
<bgardner> So I guess my question is: what is the correct method to add users to an Ubuntu ARM rootfs from an x86_64 dev machine?
<bgardner> If it helps, this system *does* boot all the way to a login prompt.  Without a user it's a useless prompt, of course, but it does appear to work.
#ubuntu-arm 2016-03-11
<bgardner> Just to follow up on my own question (how to add a user to the Ubuntu Core Rootfs), I found a solution that worked great here: http://askubuntu.com/questions/216621/how-to-add-user-to-separate-filesystem-armel
<bgardner> It's technically for armel but worked perfectly for armhf.
<ogra_> you would simply boot and run adduser ...
<bgardner> ogra_: Yeah, nothing 'simple' about it, or wasn't for me anyway.  The Core rootfs doesn't have any users defined.
<ogra_> it has root
<ogra_> without password iirc
<ogra_> thats enough to log in and run adduser
<bgardner> ogra_: Just checked it, root is (as ever for Ubuntu) not possible to log into.
<ogra_> then you just need to drop the exclamation mark from /etc/shadow on the Sd
<bgardner> ogra_: Boy wouldn't that have made me mad if it had worked though...
<ogra_> that should be enough to let you in as root without password
<bgardner> ogra_: The link I mentioned solved it for me, but I'll make a note about /etc/shadow for any future images.  Nothing else should need to be changed?
<ogra_> that should be it ...
<ogra_> you will indeed need to set up your network after first boot and likely want to apt-get a bit of stuff (like vi or nano)
<bgardner> ogra_: Thanks, I'll try it out on a server I'm building next week.
#ubuntu-arm 2016-03-13
<Pepe> Hello guys. I have problem. I bought Odroid-C2, everything it's ok. But I install Ubuntu on it, but lsusb shows nothing. What can I do?
#ubuntu-arm 2017-03-08
<ali1234> is there any way to build a foreign chroot without root?
<ali1234> ogra_: i know you've run into this problem
<ali1234> but 572882
<ali1234> bug 572882
#ubuntu-arm 2017-03-09
<genii> Has anyone seen a LeMaker Cello or HusyBoard yet?
<genii> *HuskyBoaard
 * genii curses his fat fingers and lack of caffeine
<pvl1> what is the relationship between ubuntu arm and linaro
#ubuntu-arm 2017-03-11
<mchasard> hi
<mchasard> strange my lubutu arm for pi3 is down after an update
<mchasard> and no way to boot
<mchasard> it begins at fist to loose settings  from boot .config.txt
<mchasard> i have to reinstall it  ?
<mchasard> the last version is allwaus the 16.04
<WernerWe> Hi, can anyone tell me if I'd need to compile the usbip kernel modules manually or are they supposed to ship with the linux-tools-generic package?
<WernerWe> I'm on 16.04.2 LTS
<WernerWe> on a 64bit armhf sys
<ali1234> WernerWe: try linux-image-extra
<WernerWe> seems theres only packages available for generic 4.8.0-* kernels
<WernerWe> I'm running a quite older kernel it seems: Linux tegra-ubuntu 3.10.96-tegra #1 SMP PREEMPT Wed Sep 28 17:51:08 PDT 2016 aarch64 aarch64 aarch64 GNU/Linux
<WernerWe> guess the simplest way is to just compile the kernel + usbip module
<WernerWe> Well I dumped the current kernel config, added usbip to the config, compiled everything and added the module to the sys. Sadly it complains when trying to load it...
<WernerWe> ERROR: could not insert 'usbip_host': Exec format error
<WernerWe> readelf -h doesnt show anything suspicious. ELF64/Aarch64
<WernerWe> well nvm got it loaded now
<WernerWe> sigh this is really getting depressing ... i got the usb device captured, had to patch the version to make usbip work with the newest (rather old) windows version, got the usb mount there and ....
<WernerWe> the software says: device not detected -_-
<darkl0rd> Hi Guys
<darkl0rd> Question regarding MultiArch in Xenial
<darkl0rd> When I attempt to add (dpkg --add-architecture arm64) and update the sources.list(s) accordingly (ports.ubuntu.com for arm64 and the normal sources for amd64,i386) and then try to install for instance libc6:arm64, apt suggest removing/overwriting libc6:amd64 and all it's dependencies (pretty much the entire system)
<darkl0rd> Using the exact same approach works on Debian Jessie.
<darkl0rd> Reason I'm asking here, and not in #ubuntu is that I figured the crowd here probably has more experience with cross builds / multiarch ;-)
#ubuntu-arm 2020-03-06
<qzio> Hello! I wonder if there's a better xorg video driver for raspberry pi 4 (64bit arm) than xserver-xorg-video-fbdev)
<qzio> https://wiki.ubuntu.com/ARM/RaspberryPi mentions xserver-xorg-video-fbturbo but it seems outdated...?
<qzio> and that ppa is not set up for eoan...
<donofrio> qzio, hu?  What would be better than raspbian stock xorg server?
<donofrio> oh your tryin ubuntu on rpi4b?
<donofrio> nevermind I'm in the ubuntu channel - lol - moar coffee needed for me ;)
#ubuntu-arm 2020-03-08
<archon1> hi there
<archon1> I'm usin kubuntu on a pi 4 B
<archon1> I need to disable pulseaudio because it mess with scummvm and dosbox sounds ...
<archon1> when I disable it I get no sound at all
<archon1> anyone got a clue ?
