#ubuntu-arm 2009-01-22
<ChEx> Hello everyone.
<ScriptRipper> hi,
<ScriptRipper> it got now Jaunty 9.04 with HDMI output on LCD, Keyboard, Mouse, Networking, xubuntu-desktop files installed and xfce login running
<ScriptRipper> on my beagleboard....
<ScriptRipper> using the linux kernel package "linux-image-2.6.27-oer4_1.0hasty_arm.deb"
<ScriptRipper> ogra, persia: are you happy with that?
<ogra> sure, i run the same here :)
<ian_brasil> dunno about ogra and persia but i sure am happy about that
<ScriptRipper> ogra: you use a beagleboard?
<ScriptRipper> ogra: the same image works with QEMU also.
<ScriptRipper> ogra: i only use another kernel for that
<ogra> i have a beagle here among a bunch of other arm hw
<ScriptRipper> ogra: what kind of windowmanager etc. do you use with 128 MB of RAM?
<ScriptRipper> ogra: even xfce is using quite a lot of memory for the beagleboard
<ogra> xubuntu-desktop
<ogra> on a udb disk, with 512M swap
<ogra> *usb
<ScriptRipper> me here: Swap:   658656k total,   100928k used,   557728k free,    24868k cached
<ScriptRipper> swap is on my Flash memory card
<ScriptRipper> which is in fact suboptimal ....
<ogra> yep
<ogra> usb disks are chep
<ogra> *cheap
<ogra> though you need a powered hub ...
 * ogra goes back to dinner
<ScriptRipper> I have a powered hub also running here.
<ScriptRipper> otherwise I could not get Ethernet working...
<ScriptRipper> I was told by the TI people that I should not start without a powered USB hub...
<jkridner> is there a place where I should get the latest build for the beagleboard?
#ubuntu-arm 2009-01-23
<ScriptRipper> jkridner: its the normal build from ports.ubuntu.com, with the "linux-image-2.6.27-oer4_1.0hasty_arm.deb" kernel package.
<ScriptRipper>  jkridner: I bootstrapped it on the mojo hard with debootstrap
<ScriptRipper> jkridner: sorry, i meant: mojo hardy and then some expansive handywork... because the installer is not yet working, and involving lots of waiting due to QEMU
<ScriptRipper> jkridner: maybe we can talk about this tomorrow, because i ll leave now....
<ScriptRipper>  jkridner: and our ubuntu guys here want to have some first 2.6.28 kernel ready soon (or even have already)
<ScriptRipper> NCommander: hi!
<NCommander> hey ScriptRipper
<ScriptRipper> NCommander: http://lists.opensuse.org/opensuse-buildservice/2009-01/msg00292.html   :D
<ScriptRipper> NCommander: what do you think ?
<NCommander> yay for sane support :-)
<ScriptRipper> which of the 3 options you would opt for?
<NCommander> ScriptRipper, I'll tell you once I finish showering
<ScriptRipper> ok....
* ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | <suihkulokki> is there gym excersizes to make ARMs faster? | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch
<ogra> persia, do you think it makes sense to put a link to https://wiki.ubuntu.com/ARM/RootfsFromScratch on https://wiki.ubuntu.com/ARM ?
<persia> Very much so.  I'd add an item to the FAQ, and link from that.
<ogra> col, thanks
<ogra> *cool even
<persia> If you'd like to review the rest of the questions, and make sure they aren't out of date, that'd be grand too :)
<ogra> to sad xubuntu-desktop is brken atm ... i'd put an example log up on people
<ogra> but something seems wront with tango
<persia> Well, if you're into yak shaving, you could just fix xubuntu first ...
<ogra> pfft
<ogra> persia, i thinnk i'll leave that to xubuntu devs like NCommander :)
 * ogra tries an lxde build
<persia> Missing lxtask, at least
<ogra> we'll see
<ogra> i just want to know which builds complete
<ogra> xubuntu used to work last weekend
<ogra> lxde is likely intresting for n8x0 users
<persia> Very much so.
<persia> It's just that some portions of the lxde environment aren't packaged yet.
<persia> Or rather, that the packages aren't in the repo.
<ogra> yep
<ogra> ogra@osiris:/var/build$ ls -lh /var/build/armel-rootfs-200901231724.tgz
<ogra> -rw-r--r-- 1 root root 151M 2009-01-23 18:02 /var/build/armel-rootfs-200901231724.tgz
<ogra> not bad ... lxde desktop ...
#ubuntu-arm 2009-01-25
<Stskeeps> anyone expericing HAL crashes on armel?
<persia> Stskeeps, I haven't seen that.  Can you reproduce with a stock rootfs?
<Stskeeps> mm, things might be a bit special since it's on the nokia tablets, i'll see if i can reproduce in a second
<persia> Stskeeps, If you can reproduce, even on the tablets, with no extra-repo patches to HAL, it's probably worth filing a bug.
<Stskeeps> *nod* we didn't touch HAL whatsoever, so
<persia> In that case, it's probably a valid bug.  While there's no kernel that works on those, it's certainly one of the devices considered for the port.
<ian_brasil> persia: doesn't the maemo kernel work?
<persia> ian_brasil, Sure, but I don't think we can file bugs on the maemo kernel on LP.
<persia> Or at least not against Ubuntu.
<ian_brasil> true
 * Stskeeps unpacks newest rootfs
 * Stskeeps ponders where to find dbg package for ha
<Stskeeps> l
<persia> With debug symbols?
<Stskeeps> yeah
<Stskeeps> not sure there is one :)
<persia> There's a repo for them all at ddebs.ubuntu.com I think.  I'll try to dig up the wiki page
<Stskeeps> we both have the HAL problem (fixable by using older version) on the very-close-to-ubuntu-rootfs and mer, so :P
<persia> https://wiki.ubuntu.com/DebuggingProgramCrash
<Stskeeps> thanks
<persia> Crash is with 0.5.12~rc1-0ubuntu7 ?
<Stskeeps> 0.5.12~rc1+git20090120-0ubuntu1 , most recent
<persia> Oops.  Forgot dpkg version ordering != ASCII sort order :)
 * Stskeeps grabs his trust dbg
<Stskeeps> er, gdb
<persia> You might also try apport, especially if you're filing the bug.  I like it because it automates the extraction of the stack trace post-crash, without needing to run gdb on the process.
<Stskeeps> k, will read up on it
<persia> Needs kernel support though, which may or may not be possible in your environment.
<persia> https://wiki.ubuntu.com/Apport
<Stskeeps> curious, crash in leds_add
<Stskeeps> looking further
<jonpackard> Ogra - I see you've updated your build-arm-rootfs script.. want any help testing it?
<jonpackard> Or if anybody else would like some help testing anything.. I'm fairly experienced with running an arm system with qemu ;-)
<Stskeeps> http://rafb.net/p/Qw09fQ38.html <- occasional HAL crash i'm running into
<jonpackard> Hello. Has anybody had success with X in qemu with Jaunty-armel yet? I'm still getting the problem with no keyboard or mouse repsonse once X starts.
#ubuntu-arm 2010-01-25
<Differentkindof> I have a question about programs
<Differentkindof> If I download the source to pd extended will it build on u-arm?
 * persia checks
<Differentkindof> Sorry I'm seriously daft
<Differentkindof> I just hear all this jazz about stuff not porting well to arm and I was wondering if I was missing something, the program in question only uses c, c++ and tcl supposedly
<persia> Well, puredata seems to be built.  I'm not sure why pd-extended wouldn't.
<persia> But since I'm not finding pd-extended available, I'm guessing it's not already done.
<Differentkindof> So no issues on arm arch
<persia> (but I also don't see it in the build failure report, so I presume it's out-of-archive)
<Differentkindof> There's source and it builds on ubuntu on my desktop
<persia> Which Ubuntu source package?
<Differentkindof> But I'm wondering if it'll build on an sbc Im getting
<Differentkindof> 9.10 I think
<Differentkindof> Oh the package sorry I'm real slow tonite
<persia> Well, http://qa.ubuntuwire.com/ftbfs/karmic.html is the fail-to-build-from-source report for 9.10
<persia> So, if puredata needs a package there, it ought fail, but it appears puredata succeeded, so I suspect it would work.
<Differentkindof> http://puredata.info/downloads
<Differentkindof> Ok cool
<Differentkindof> So the whole portability q I keep seein on this hardware forum is about other stuff
<Differentkindof> I guess I was wondering what issues I might run into just using make etc on the source on an arm setup
<persia> I thought I remembered a pd-extended source package, but I'm not finding it now.
<persia> Most of the issues seem to either be related to upstream being insufficiently portable (for instance, wine doesn't compile), issues with ARM vs. Thumb2, or issues with the toolchain.
<persia> I believe the karmic toolchain to be mostly clean.
<Differentkindof> Groovy
<Differentkindof> Really I just need pd and the gem library
<Differentkindof> Sounds solid now
<persia> pd and gem should be available with apt-get
<Differentkindof> Nice
<persia> Depending on your kernel, you may end up with issues at lower levels, but at the high levels, all is good.
<persia> Making an effects box?
<Differentkindof> Actually just trying to get a smaller computer for generative music and video stuff
<Differentkindof> Also I preordered a pandora
<Differentkindof> I figure in the end I'll rock pandora but maybe angstrom if it wows me
<persia> Well, best of luck with that.  I think you may want a USB audio interface though, if you're looking at input/output.  I don't know of many SBCs that have high-def audio systems.
<Differentkindof> Pandora has enough for what I'm gunna rock
<persia> Cool!
<Differentkindof> Usually our sound guys push the faders up too much anyway
<Differentkindof> Hehe
<persia> heh.  Then it doesn't matter if you have perfect DA converters :)
<Differentkindof> Yeah... This has only made me more excited for my open pandora
<Differentkindof> Thanks a bunch for helping
<Differentkindof> I was pretty sure it would just build but I won't be certain till my hardware is here
<ogra> hmm, so all plymouth error messages are gone with my new babbage install
<persia> \m/
<ogra> reinstall from A2 and dist-upgrade seems to have worked fine
<ogra> i even have suspend/resume working properly
<persia> And is plymouth actually running?
<ogra> i dont think so, let me check
<ogra> the console fonts change during boot so it might be
<ogra> i.e. i see some bold parts in the fsck output
<persia> Could be something else, depending.  I don't know how karmic works, but I do know it's fancy (and different to both jaunty and lucid)
<ogra> hmm, should i see a logfile or something ?
<ogra> i know there is a plymouth-log process usually
<persia> No idea, sorry.
<ogra> well, i'll reboot
<ogra> i dont see any splash ... but
<ogra> i can run plymouthd manually and run plymouth --show-splash and see a moving bar at the bottom of the screen on tty8
<ogra> its odd that X is on tty1 now :(
<ogra> makes my finger memory unhappy :)
<persia> It makes for no VT switch, which is apparently both faster and more appealing.
<persia> But I'm glad to hear it works.
<ogra> well, seems plymouthd defaults to tty8
<ogra> so if it doesnt do a vt switch and stays on vt1 there is indeed no way for me to see it
<persia> hrm.
 * ogra wonders why motd tells him he can update 285 packages
<ogra> i just did a dist-upgrade
<ogra> asac, so plymouth dies because of the console comdline option we use
<persia> The console command line?  The kernel command line?
<ogra> yes
<persia> And if we use a different one, it works?
<ogra> the "moutall: could not connect to plymouth" goes away if i remove "console=ttymcx0,115200 console=tty0" from the cmdline
<persia> And where does console end up?
<ogra> also the plymouth-log error
<ogra> tty0
<ogra> as its supposed to
<ogra> the A2 install i had didnt set console, now that i switched to uboot i have a console entry
<persia> Well then, that sounds like a reasonable thing to fix.
<ogra> if i remove it and make it look like the redboot line we install it works
<persia> Cool!
<persia> That's fancy demo stuff, there.
<ogra> as soon as i enforce a tty by using console= it breaks
<ogra> hmm, let me try tty8 ... probably plmouth runs already but i dont see it
<ogra> 285 packages can be updated.
<ogra> 0 updates are security updates.
<ogra> GRRR
<ogra> liar !!!
<persia> Run update-motd to make it go away.
<ogra> ogra@babbage2:~$ sudo update-motd
<ogra> sudo: update-motd: command not found
<persia> Hrm.  Dunno.  Worked in jaunty.  I haven't played with update-motd in karmic, but I don't see a binary.  Ask mvo or kirkland.
<persia> Last time I found a bug it got fixed within two days.
<ogra> not so pressing now
 * ogra is more intrested in seeing plymoutho
<ogra> -o
<persia> heh
<ogra> so tt8 quitens down even more but doesnt make plymouth work
 * ogra looks at /usr/share/initramfs-tools/scripts/init-top/plymouth
<ogra> printf '\033[?25l' > /dev/tty7
<ogra> /sbin/plymouthd --mode=boot --pid-file=/dev/.initramfs/plymouth.pid
<ogra> /bin/plymouth --show-splash
<ogra> hmm
<ogra> whats that printf ? a clear command ?
<dmart> show (or hide) cursor
 * ogra tries console=tty7
<ogra> nope
<ogra> doesnt work either
<ogra> and i see a cursor :)
<ogra> GAH !
<ogra> my X crashed
<persia> You didn't really need that, did you?
<lool> printf '\033[?25l' > /dev/tty works in a xterm here  :-)
 * ogra slaps persia with a wet towel
<ogra> lool, well, i guess it works on my tty7 too during boot, prob is that i'm on tty0 by default (so i cant see it) and that plymouth doesnt seem to like if i set console=
<persia> Does Alt+Fn7 not switch for you?
<persia> Or can you change the config?
<ogra> sure it does, but way to late :)
<persia> You clearly need to find some way to slow down the boot :)
<ogra> ogra@babbage2:~$ man plymouthd
<ogra> No manual entry for plymouthd
<ogra> BOOO !
<ogra> ogra@babbage2:~$ man plymouth
<ogra> No manual entry for plymouth
<ogra> BOO++
<persia> See, this is why I think we ought to insist on agressive peer review for all new packages.  Even the best of us skip stuff.
<persia> (and this annoys users, like you)
<NCommander> dmart, you around?
<asac_> had to join first ;)
<dmart> NCommander, hi
<NCommander> dmart, I need to poke your brain, I've had some thoughts on the vldr issue we have on ARM, and I was wondering if you can give your input on this
<NCommander> s/ARM/Dove/g
<dmart> sure
<NCommander> dmart, I've been looking at the Marvell kernel fixup for vldr, and I think the issue with it is that the vldr fixup doesn't fire until after the processor sends an alignment fault to the kernle
<NCommander> dmart, (I might be mistaken on this part, I'm not very familiar with kernel code handling alignment)
<dmart> I think that's normal?  User: vldr *boom* -> kernel: fault kandler -> emulate unaligned vldr -> return to userspace following the faulted instruction
<dmart> s/kandler/handler
<NCommander> dmart, right, based on how the kernel handles alignment faults, that was my understanding as well
<NCommander> dmart, the problem then is impossible to fix in kernelspace because the kernel doesn't vet each individual instruction
<NCommander> (or at leas tin this portion of kernel space)
<NCommander> dmart, there are two ways we can work around the faulty vldr instruction, 32 vmov's, or force the processor into ARM mode for the execution, then return to Thumb2 (if the context is appropriate for the switch)
<NCommander> not sure which one is faster
<NCommander> (I'm guessing returning to ARM mode is going to be faster, but I wanted to run that by you)
<asac_> dmart: you can also reply to me ;)
<asac_> ah there he is again
<asac_> nm
<NCommander> ugh, sorry
<NCommander> router decided a lovely time to HCF
<NCommander> What was the last thing that you saw from me?
<persia> Time can7t reach him, but timeouts can :)
<persia> [21:53] <NCommander> (I'm guessing returning to ARM mode is going to be faster, but I wanted to run that by you)
<NCommander> persia, that sounds like it was from a song.
<NCommander> was there a response :-)
<persia> No.
<ogra> ok, the mount error on imx51 boot seems to definately be bootchart
 * ogra removes it 
 * NCommander is looking at his GCC theory
<ogra> mount -t proc none $JAIL/proc
<ogra> hmm, can that be none ?
<NCommander> ogra, yes
 * NCommander uses that all the time
 * ogra always thought it *has* to be proc
<persia> Can be any string.  It's not read.
 * persia usually uses "proc"
<ogra> ok
<ogra> me too
 * NCommander usually uses none or its purpose
<NCommander> proc-hardy on /home/chroots/hardy-i386-android/proc type proc (rw)
<persia> That's why I use "proc", as the context is obvious by $PS1
<ogra> hrm, and it wasnt the error anyway
<ogra> ogra@babbage2:~$ grep mount /usr/share/initramfs-tools/scripts/init-top/*
<ogra> /usr/share/initramfs-tools/scripts/init-top/bootchart:mount -t proc none $JAIL/proc
<ogra> ogra@babbage2:~$
<ogra> but thats the only mount call in init-top
<ogra> weird
 * ogra checks the init script itself
<NCommander> hrm
<NCommander> ok
<ogra> aha
<ogra> mount -t tmpfs -o mode=0755 none /dev
<ogra> hmm
<persia> Did you want $JAIL/dev ?
<ogra> no
<ogra> thats what bootchart wanted
<ogra> which i removed already
<ogra> that line is from init
<persia> Ugh.
<ogra> if ! mount -t devtmpfs -o mode=0755 none /dev; then
<ogra>         mount -t tmpfs -o mode=0755 none /dev
<ogra>         mknod -m 0600 /dev/console c 5 1
<ogra>         mknod /dev/null c 1 3
<ogra> fi
<ogra> to be precise
<ogra> hmm, is devtmpfs a .32 feature we miss in .31 ?
<persia> I thought it was very new: http://blog.steve.org.uk/we_have_to_be_ready_to_do_anything__do_you_hear_me_.html
<ogra> yeah
<ogra> well, it was there for a while afaik but experimental
<persia> Seems first introduced April 2009.
<ogra> right
<persia> So how isn't this devfs, which everyone decided was bad?
 * persia is confused
<ogra> no idea
<ogra> i just want the error to go away :P
<persia> Well, get the kernel built with devtmpfs then.
<ogra> ogra@babbage2:~$ grep DEVTMPFS /boot/config-2.6.31-602-imx51
<ogra> ogra@babbage2:~$
<ogra> seems we dont even have the option
<persia> Does N appear with that?
<ogra> N ?
<persia> Hrm.  Then let's drop it from userspace.
<ogra> its in init
<persia> Stuff neither selected nor modules, especially stuff that only shows up in submenus.
<ogra> and udev uses it massively
<ogra> and beyond that it slows down booting to not have it with new udev
<persia> Then lets add it to the backport list :)
<ogra> right
<ogra> very high up
<ogra> where is cooloney when one needs him :P
<persia> slows down booting?  So putting initial device management in userspace does slow down boot?  Makes me laugh at very old kernel mail threads (back when I actually tried to follow that ML)
<ogra> if you use devtmpfs the initial device tree gets directly populated by the kernel
<persia> Right.
<ogra> else it will be done by udev scripts
<persia> Right.
<ogra> which are slower indeed
 * persia used to use devfs extensively
<ogra> looking at some benchmarks google finds for me it seems it removes about 2sec
<persia> I was convinced that the entire approach didn't scale and was ultimately slower, but at that point I was mostly messing with ACPI anyway, and didn't care that much.
<dmart> NCommander, sorry, I was away for a bit.  What exactly do you mean by "32 vmovs"?
<NCommander> dmart, 32 vmov instructions to emulate vldr
<dmart> yes, but why 32?  (I may just be missing the point)
<ericm_> NCommander, not 32, it could be 2 vmov for vldr or 1
<ericm_> 2 vmov for vldr of double word, 1 vmov for vldr of single word
<ericm_> 32 vmov listed there are for quick expansion
<dmart> Yes, I'd expect ldr+ldr+vmov (double) or ldr+vmov (single)
<ericm_> dmart, you aware of the dove issue right?
<dmart> What is the actual problem on Dove?  Is it that the alignment fault on a vldr in Thumb-2 can't be handled properly at all for some reason?
<NCommander> ericm_, oops, misread the code :-)
 * NCommander has not played much with handwritten VFP ASM
<ericm_> NCommander, I was upset the first time as well
<NCommander> dmart, the fault never comes, and the board hangs.
<dmart> Ah... I see.  So we need the userspace code not to do that?
<ericm_> NCommander, with a latest apt-get upgrade, it looks the system freeze issue has gone, so far no freeze
<ericm_> dmart, the issue happens only when VLDR is executed in Thumb2 mode, an incorrect alignment fault is generated
<NCommander> dmart, pretty much, but we have vldr's all over the place, my first theory just crashed and burned
<ericm_> NCommander, that's what I want to say
<NCommander> ericm_, I'm going to also see if I can isolate what's causing our counters to run backwards on Dove
<NCommander> since it still happens with X0.
<dmart> That would be very useful to find out.
<ericm_> NCommander, and asac told me the python bug invokes the system freeze so not clear if it's caused by this VLDR bug though
<dmart> Do you know where the problem vldrs are coming from in userspace, or are they just everywhere?
<ericm_> but yes, the apt-get showing negative could be related to this
<asac_> atm our dove images work
<asac_> so its not really everywhere
<asac_> for me (without knowning) it just feels like dove doesnt like if something "irregular" happens
<asac_> like a crash etc.
<ericm_> dmart, Marvell has a patch to workaround that bug
<asac_> if all is fine things seem to work
<ericm_> dmart, but we are doubting that fixes all the odds
<asac_> ericm_: where is that patch?
<asac_> already in our kernel?
<ericm_> asac_, yes
<ericm_> asac_, wait
<ericm_> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=1ccfc4f93a746849521afba13ea62aac119c43bd
<dmart> To me, the apt-get counter weirdness doesn't sound like it would be caused directly by the vldr issue... unless the fault handling in the patch actually does something wrong and mis-emulates the vldr
<asac_> ericm_: is that in the archive yet?
<ericm_> asac_, already since several weeks ago
<NCommander> dmart, we've had the issue since before the vldr patch went in :-/
<asac_> right. so we dont doubut ... we _know_ that there are still issues left
<ericm_> dmart, I agree
<dmart> OK, sounds like it's worth digging into the apt-get issue, since something's definitely going wrong reliably in there
<ericm_> NCommander, but those are different issues - without vldr patch - we know those unalignment faults won't be handled
<ericm_> not sure though if this ever happens on imx51
<ericm_> the negative counter issue
<NCommander> ericm_, doesn't happen on imx51
<dmart> Has anyone looked at the compiler output for the dove alignment.c patch?  There are no output constraints on the vmov_single asm (and it's not volatile) so the compiler might no-op it.
 * ogra files bug 512321
<ubot4> Launchpad bug 512321 in linux-fsl-imx51 "please backport devtmpfs to the lucid linux-imx51 kernel tree" [High,New] https://launchpad.net/bugs/512321
<ericm_> dmart, let me check
<dmart> If you have a .o file handy, it'd be interesting to see it.
<NCommander> dmart, I'm fairly sure its not no-op'ed since the vldr patch fixed Xorg
<dmart> Agreed; it's probably working, though it depends on the compiler behaviour.
<ericm_> dmart, they are indeed expanded
<ericm_> a long list of vmov + b, ugly but should work
<persia> Do we have a known, small, sequence of assembly that generates the fault?
<ericm_> persia, just write a simple test.c with double - I'm pretty sure a VLDR instruction will be generated
 * persia doesn't have HW, so wouldn't know if it caused the issue
<ericm_> printf("%d", (int)((double)a / (double)b))
<dmart> ericm_ does vldr _always_ fault in Thumb-2?  Or is it on occasional anomaly?
<ericm_> dmart, always
<persia> But I'd think working from a known, small, test case would be easier than working from the entirety of userspace.
<ericm_> dmart, and Dove X0 fixes this issue
<NCommander> ericm_, it does?
<ericm_> NCommander, no alignment fault ever been seen
<ericm_> NCommander, actually "echo 3 > /proc/cpu/alignment" can reveal all alignment faults on your console
<ericm_> NCommander, never seen a single on X0
<asac_> ericm_: does import uno hang on X0 ?
 * persia wonders more if it's worth fixing in SW if it only appears for some prerelease dev boards
<ericm_> asac_, no X0 at hands
<NCommander> ^- persia
<ericm_> asac_, will have to come to Marvell office for that
<asac_> ericm_: weren't there marvell folks in this channel at some point ;)?
<asac_> can we get them back?
<ericm_> asac_, I think so - but probably not this time :)
<ogra> NCommander, did you ever finish your fix for likewise-open ?
<NCommander> ogra, its unfortunately non-trivial. It gets through 95% of the modules before it blows its brains on the last one
<asac_> persia: its definitly worth fixing in SW imo ... what i see is that this bug consumes huge amount of resources. so if we dont fix it, this will probably happen again and again
<asac_> or we get all new hardware
<NCommander> ogra, I know how to fix the last one, but the proper technique is alluding me
<asac_> thats ok too i guess
<persia> asac_: Consider my statement a suggestion for option (b) :)
<asac_> yeah
<asac_> i will discuss this with david today for sure
<ogra> NCommander, well, you should probably open a bug with your fixes so far and a description of the ramining issue and your idea for a fix so the server team can do the rest
<asac_> ack++
<ogra> *remaining
<asac_> please do
<NCommander> ogra, I take it we got a ping from the server team to look at this?
<ogra> NCommander, nope
<NCommander> oh
<ogra> NCommander, it shows up on the FTBFS list
<ericm_> asac_, NCommander, are we still going to support Z0 BTW?
<asac_> i doubt it
<NCommander> ericm_, we made the call in lucid to drop it
<asac_> for now i want Y1 to work
<ericm_> NCommander, ok
<NCommander> ericm_, the kernel and the bootloader are fubar'ed for it
<ogra> NCommander, its their package, so its fine if they do the rest, but you put work into they should know about
<dmart> ericm_, the dove patch does this: 	addr &= ~3; __get_user(val, (u32 *)addr);
<dmart> This won't correctly emulate a misaligned load?
<dmart> Or is the problem that we fault on an aligned vldr?
<ericm_> dmart, the issue they mentioned is only about VLDR in Thumb2 mode
<ericm_> dmart, I guess the problem is even if it's aligned VLDR, the fault happens anyway
<ericm_> for an unaligned VLDR, the fault is expected to happen right?
<dmart> Yes
<dmart> OK.  It looks like if userspace really does a misaligned vldr, it will silently load the wrong value instead of getting a SIGILL as it should.
<ericm_> Mmm.... actually doubt this can correctly handle those unaligned VLDR
<dmart> That's what I meant.  But there is no handling of unaligned vldr for imx51, and we get no problem there; so I'm not sure whether that situation is happening.
<ericm_> dmart, indeed - esp. since the compiler is smart enough to get rid of this
<dmart> Not necessarily... the common problem is that a library contains a function f(double *a) { do something with a }.  a is aligned, right?  The ABI says it is.  But some caller code built later is munging some freeform data structture: char *p = <some misaligned random location>; f((double *)p).  Strictly speaking that's wrong, but some bits of code may do it.  I'd still expect also to see...
<dmart> ...problems on imx51 if we hit that case though.
<ericm_> dmart, yet I expect the support for such faults should be there in the kernel, lemme check
<dmart> I think the correct think in the patch would if if(addr & 3) goto fault;
 * NCommander hrms
<NCommander> I just copied in an apt-get from karmic into a lucid chroot, and I still get backwards running counters :-/
<ericm_> dmart, I agree - currently the vldr workaround is placed before other unalignment fault handling code
<ericm_> dmart, so your proposal will lead to the VLDR workaround to fix only those aligned faults
<dmart> ...which I think matches the imx51 behaviour
<ericm_> dmart, a good catch - will let Marvell guys know this
<dmart> It's only a problem for wrong userspace code, so it's more an anomaly than a full on bug
<ericm_> NCommander, so that doesn't seems to be related to the VLDR issue
<dmart> NCommander, maybe it's in libc or somewhere?
<NCommander> dmart, or one of APT's support libraries
<dmart> Hmmm, libutil1, libstdc++6, eglibc (libc6, libm6, libdl2)
<NCommander> dmart, theres a libapt-pkg* I didn't replace
<NCommander> let me just fully install the karmic version
 * ericm_ needs some sleep
<asac_> 'night ericm_ ... thx
<dmart> Oops, yes, libapt-pkg-libc6<blah>
<dmart> Thanks.  I think the fixup in do_alignment_thumb_vldr is otherwise correct.
<NCommander> dmart, yeah, that fixed it
<NCommander> hrm
<dmart> Hmmm, so we know which lib it's in
<NCommander> Cool
<dmart> -er- well, it's the same set (deps of libapt-pkg-libc6<blah>)
<NCommander> dmart, actually, its the HTTP handler of APT
<NCommander> dmart, if I use FTP, the problem goes poof
<dmart> Oh right. Is that dlopen'd ? I noticed libdl is linked in there.
<NCommander> -rwxr-xr-x 1 root root 43K Dec 23 16:28 /usr/lib/apt/methods/http
<dmart> Right
<NCommander> Fetched -656298B in 3s (-191066B/s) - this is just getting annoying :-/
<dmart> unless you can make the clock go backwards too :P
<dmart> It is possible to backtract from those printfs and see where the negative answers start to appear...?
<NCommander> dmart, looking
<NCommander> dmart, ugh, its a twisty set of includes, and I'm not sure specifically where's going bust
<dmart> HMM
<dmart> s/HMM/hmm/
<dmart> Z BG
<dmart> argh, wrong window again
<dmart> Are there any other methods that we could try easily?
<NCommander> dmart, well, I found the code formatter
<NCommander> dmart, and I'm testing to see if the number going into that is value or not
<NCommander> at least gives me an idea of where to look
<dmart> Yeah, I guess that's the best thing to do... it it's correct, then we'll need to walk back and see where the number comes from...
<NCommander> contrib/mmap.cc:246: internal compiler error: Illegal instruction
 * NCommander thunks his head on the desk
<NCommander> ARGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
<plars> nice, as suspected dove live image now boots up fine :)
<plars> and plymouth appears to be working nicely as well
<plars> doh, gnome-panel just died though
<dmart> plars, "as suspected": what was the fix?
<dmart> NCommander, were you building on Dove there?
<plars> dmart: there was a new build of python on Friday, I'm not sure what all is different off the top of my head
<dmart> ok, thanks
<plars> dmart: but asac suspected it would help, so I tried with it on Friday and could no longer get pybootchartgui to crash
<plars> dmart: importing uno.py still hangs though
<plars> dmart: but that's just some random thing I discovered while trying to find a simpler testcase... not something that is going to typically be seen during average use
<dmart> Is there any relationship to the OOo bug there?  I remember uno and exceptions being involved, but can't remember all the background now.
<plars> dmart: asac seemed to be indicating he thought there was some connection
<dmart> There might or might not be, the description of the issue just has some similar words ;)
<dmart> (don't understand the details, myself)
<NCommander> dmart, yeah
<dmart> Was that another alignment fault, or something else?
<apw> ogra, about?
<ogra> apw, indeed
<apw> bug #458537
<ubot4> Launchpad bug 458537 in linux-fsl-imx51 "[armel imx51] hibernate does not work" [High,Triaged] https://launchpad.net/bugs/458537
<apw> the current states of the tasks make little sense to me.  if the kernel is correctly reporting that hibernate is not supported then if devkit-power says it is available then its broken
<apw> so it seems to me its tasks should be open for that but, or perhaps anohter bug filed (i guess)
<apw> and the kernel is doing the right thing, its reporting it not available as its not going to be there as its not supported by the platform
<ogra> apw, its all solved ... devkit doesnt expose hibernate to the gui anymore
<apw> so i would normally close the kernel tasks invalid, but you've said you want themj open
<apw> so ... how do we resolve that
<ogra> and suspend/resume works too as of today, so all these bugs cvan be closed. the suspend/resume bug is missing one final test with the uboot bootloader though
<ogra> well, i'D like to still have a reminder to talk to FSL if they cant implement it somehow ... hibernate is a pure kernel thing, there is no HW changes or whatnot required
<NCommander> dmart, not sure, but its another one of those stability is lacking bugs :-/
<ogra> apw, so it would be nice if they added code to support it
<apw> ogra, launchpad doesn't allow us to do what i would like to do, which is close karmic and lucid and leave M open as a reminder ... hrm
<ogra> apw, and it would be nice to have a bug to pÃ¼oint them to ... but if you need it closed, close it :)
<apw> the release team wants it closed as its not a problem per-see
<ogra> why does the release team care for iuntargeted bugs ?
<apw> it is targetted
<ogra> its a general problem of that kernel
<ogra> but its not up to us to fix it
<ogra> i thought i closed all targets
<ogra> oh
<apw> the kernel is still targetted to lucid
<ogra> i removed the milestones :)
<ogra> cant we un-target and leave it as a bug in the package
<apw> if you can untarget it yes, no idea how to do that
<ogra> hmm, doesnt seem like
<ogra> yeah, nothing in the UI
<ogra> just close it then
<apw> and its current state is confused, the linux is targetted and devicekit-power not
<ogra> well, devkit works fine
<apw> and that has three entries, karmic/lucid/ and what would be lucid
<ogra> the comments arent up to date
<apw> and linux only has two ...
<apw> which doesn't seem possible to my mind :)
<ogra> yeah, its weird
<ogra> just close the tasks and dont worry
<ogra> i'm happy tracking the issue on my TODO list on my whiteboard in the office instead :)
<apw> ogra, thanks ... i dispare with launchpad sometimes
<ogra> apw, btw, bug 512321 is untriaged yet (if you are doing bugwork)
<ubot4> Launchpad bug 512321 in linux-fsl-imx51 "please backport devtmpfs to the lucid linux-imx51 kernel tree" [High,New] https://launchpad.net/bugs/512321
<ogra> apw, i wonder how hard it is to backport devtmpfs here
 * apw wonders why we need it
<ogra> the patch didnt look to big
<ogra> bootspeed ?
<ogra> as i understand booting gets slowed down if udev scripts run instead of having a devtmpfs pre-populated
<ogra> and i'm not sure if any userspace apps wont have a requirement for it too before lucid goes final
<apw> ogra, thanks for the heads up
<ogra> :)
<ogra> wohoo, asac is back
<ogra> plymouth works !!
<ogra> \o/
<asac> ogra: i am back ;)
<asac> not sure for how long though
<asac> something is fishy with my server
<asac> even irssi doesnt autojoin all the channels anymore ;)
<asac> ogra: nice ... what was the prob with plymouth
<asac> ?
<ogra> asac, it defaults to the text plugin
<ogra> i dont know why yet, but running plymouth-set-default-theme ubuntu-logo and re-rolling the initramfs fixes it
<asac_> interesting
<ogra> its definately a bug that it isnt set by default
<asac_> what is that text plugin? wasnt plymouth done to not have text anymore?
<ogra> but technically plymouth works as it should
<ogra> the text plugin looks like normal console ... just without a cursor
<ogra> i noticed i get the fsck output in bold
<asac_> ah. ok
<ogra> so it seems to highlight a bunch of text
<ogra> i have to find out why /lib/plymouth/themes/default.plymouth doesnt point to the right theme though ... but i guess i'll have to wait for Keybuk for that
<ogra> no clue what sets it
<ogra> asac_, did david talk to you about uboot ?
<asac_> yes
<ogra> good
<armin76> bye asac :)
<asac_> armin76: bye?
<asac_> :)
<persia> asac_: You're dead.  Does that mean you'll be coming back soon?
<asac_> let me check
<plars> ogra: looks like flashkernel is failing again on ubiquity.  Last time, that seemed to be related to an oversized initrd, but I don't think that's the problem here.  Any ideas?
<persia> plars: output log?
<asac_> persia: dead due to what?
<persia> [02:28] * asac has quit (Read error: 110 (Connection timed out))
<plars> persia: I have the .crash file from ubiquity, but it's a known issue that it fails silently when flashkernel fails
<persia> plars: Have you tried adding set -x to flash-kernel, and then calling it manually?
<persia> (this should give you some output)
<plars> persia: I'll try that
<plars> aha, I think I might see the problem
<persia> Cool.  What's the problem?
<plars> persia: the actual initrd and vmlinuz are missing from the squashfs
<plars> persia: the symlinks are there, but no file that they link to
<persia> Aha!
<persia> Because we don't stuff them into the image because we're using the silly filesystemless kernel method.
<persia> Which means that we need to modify debian-cd to actually place the artifacts in place correctly.
<persia> And then, as long as we continue not to mount the filesystem, we end up wtih duplicates in the images.
<persia> But that's not *too* much extra space.
<ogra> hmm ?
<ogra> sure we put them into the image
<persia> Then why isn't plars seeing them?
<plars> ogra: mount the squashfs from today's image
<ogra> ogra@osiris:~$ ls /media/4B4D-D0D4/casper/
<ogra> filesystem.manifest  filesystem.manifest-desktop  filesystem.size  filesystem.squashfs  initrd.lz  vmlinuz
<ogra> they arent in the squashfs
<plars> ogra: shouldn't they be?
<ogra> and are not supposed to be ever
<ogra> no
<ogra> on no image we build
<plars> ogra: the result is that in /boot on the booted image, it doesn't find them
<ogra> (including non arm)
<ogra> do you have the exact output ?
<plars> and flash-kernel is complaining that it can't find them in / or /boot
<plars> ogra: of what, flash-kernel?
<persia> Oh.
<ogra> ubiquity is supposed to copy vmlinuz to /boot before flash-kernel runs
<persia> So the issue isn't in debian-cd, it's in base-installer
<ogra> no, its in ubiquity
<persia> Because we're using flash-kernel, we're probably not copying the files to /boot
<ogra> not sure if base-installer uses that too
<persia> No, ubiquity doesn't do that.
<persia> ubiquity just controls base-installer, which does that.
<ogra> sure
 * persia discovered this when making lpia work
<ogra> its somewhere in install.py
<persia> It moved?
<ogra> its a while that i looked last
<ogra> but laszt time it was in there
<persia> More recently than I :)
 * persia last looked in intrepid
<ogra> well, around karmic
<ogra> i havent thouched ubiquity in lucid yet
<ogra> but in any case there should be nothing in /boot
<ogra> to save space
<ogra> else you would duplicate the kernel
<persia> Then it needs to copy from /cdrom
<ogra> there is code that copies from /cdrom/casper to /boot
<ogra> right
<persia> Personally, I think we ought have the bootloader mount boot, and not bother with flash-kernel.  Does this really still not work?
<ogra> not with redboot
<ogra> and definately not with our image design
<persia> Works with my redboot.  Would me asking for source help you?
<ogra> (would require a separate /boot partition)
<ogra> not really
<persia> That's what I thought.
<ogra> its one of the reasone we will probably not switch to uboot for
<ogra> *reasons
<ogra> (the requirement of /boot)
<persia> Well, you don't really need /boot for the installer.
<persia> Just load the kernel off /
<persia> And then put it in a /boot partition during install.
<asac_> ogra: what i would like to see is a short list of issues and features we lack so we can forward that
<asac_> then we are off the hook
<asac_> i guess
<ogra> persia, well, the /boot partzition has to live on the SD
<persia> No it doesn't.
<persia> Or rather.  Why?
<ogra> asac_, yes, i assembled that on the weekend as i said, just need to formulate it a bit better
<ogra> persia, the babbage can only boot off the first SD
<asac_> ogra: you can just send it to me and i can fix the wording if you want ;)
<ogra> persia, no matter which bootloader you use
<asac_> just thinking you would be happy to get that off your plate ;)
<persia> It can't boot of SATA?
<persia> s/of/off/
<asac_> "it cant do nothing"
<ogra> persia, it can do exactly as much as redboot can
<persia> My.  That's limiting.
<persia> Well, for some redboots.
<ogra> plus it can read fat and ext2 partitons
<ogra> comparing to the babbge redboot indeed
<persia> Like I said, I have a redboot that boots from two alternate locations, and mounts a partition for one of those boots.
<asac_> (from some devices)
<ogra> yeah, from some SDs
<asac_> if you are lucky ;)
<persia> Yeah.  That's limiting.
<ogra> gah, there he goes again
 * ogra just , mailed him the list 
<persia> That's both of him gone.  He may be reattaching.
<ogra> persia, i think we'll go with what we have on imx51 and not make the move to uboot
<persia> ogra: Given the limitations of the bootloader and hardware, I think that's the right choice.
<ogra> i'm not really eager to have a three partition live image
<persia> I don't think it's how it ought be done, but that's an entirely different matter.
<ogra> persia, its the only choice we have
<persia> No.  A three partition image would be very unfortunate.
<persia> Yes, it seems that way.  I'm not happy about it, but like I said, it comes down to hardware and firmware.
<ogra> non-fs (for uboot), /boot (so we can reformat that later and put the installed initramfs and kernel in place, livefs partition (which needs to stay mounted during install)
<persia> Right.  That would be bad.
<ogra> +thats the only possible design atm
<persia> Right.
<ogra> only way around that would be if we got USB support into uboot
<ogra> then it could work like the dove
<persia> But that's because of the specific board, and the current features available in the current bootloaders.
<persia> Right.
<ogra> right
<ogra> asac, you got mail :)
<persia> (but he has no tail)
<ogra> heh
 * ogra closes Bug 456659
<ubot4> Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,In progress] https://launchpad.net/bugs/456659
<ogra> :D
<asac> ogra: one point as of why its inferior to dove uboot might be good
<ogra> feel free to add points as you like
<ogra> asac, USB support is the actual only drawback, all other points are just results of working around the missing USB support (apart from the slower boot which is a uboot vs redboot design issue)
<ogra> plars, so for your prob i'd first check the installer logs, its very likely that the flash-kernel issue is just fallout of a former error
<plars> ogra: will look through them
<asac> ok
<asac> thanks
<ogra> how did you get to a point where ubiquity actually does something ?
<ogra> i couls fill the forms with yesterdays image but it would never start the second step
<ogra> *could
<asac> ok on the road again for a bit
<plars> ogra: that was on imx51?
<ogra> yes
<plars> seemed to be working alright today, didn't try it yesterday
<ogra> i had trashed my A2 install and wanted to reinstall from a fresh image
<plars> well.. seemed to be working alright up to the end when it tried to flash-kernel
<ogra> in the end i rsynced back to A2 and used that
<ogra> or better i zsynced ... seems cdimage isnt offering rsync anymore
<plars> ogra: ok, odd errors
<ogra> paste ?
<plars> similar to this:
<plars> Jan 25 16:21:53 ubuntu ubiquity: /usr/bin/dirname: line 909: c002bfac: command not found
<plars> but several different binaries
<plars> dpkg-divert, fis, etc
<plars> all with similar errors
<ogra> aha
<ogra> sounds like either a filesystem or a coreutils (owner of dirname) issue
<plars> ogra: but it's not just dirname returning that
<plars> Jan 25 16:22:27 ubuntu in-target: /usr/bin/fis: 163: c05bf666: not found
<ogra> ok, then i'd say filesystem
<ogra> could also be thumb vy non thumb
<ogra> *vs
<ogra> fis was definately not rebuilt yet
<plars> well I was trying to install to USB, but recent updates to that bug are seeming to indicate that there is no problem with it
<ogra> coreutils was rebuilt
<ogra> last upload dec. 12th
<ogra> so not thumb then
<ogra> what is confusing is that your first pasted line is not using in-target while your second one is
<plars> ogra: I'm wondering if it's filesystem and related to bug 499881
<ubot4> Launchpad bug 499881 in linux-fsl-imx51 "usb storage with ext4 does not work in lucid" [High,Confirmed] https://launchpad.net/bugs/499881
<ogra> if it would all be in-target stuff that would point to USB ... but the dirname error above is clearly from the livefs and not running on the target disk
<ogra> plars, not for dirname
<ogra> thats run from the livefs
<plars> ogra: I have a similar error from dpkg-divert, also run from livefs
<ogra> in-target is the wrapper that calls commands on the target disk
<ogra> if the lines are not prefixed with in-target thats points to stuff running from the livefs
<ogra> so probably kernel
<ogra> since it happens on SD as well as on USB
<ogra> plars, for now, bug it and attach all installer logs dmesg and friends ...
 * ogra has to leave now 
<plars> ogra: seeing a lot of this: usb 1-1.1: reset high speed USB device using fsl-ehci and address 3
<ogra> aha
<plars> so I think it almost has to be related to that bug I pasted earlier
<ogra> is that your only USB device attached ?
<plars> ogra: also have keyboard and mouse
<plars> ogra: but otherwise, yes
<ogra> i.e. i have a USB WIFI card that has a fat partition for the driver that shows exactly the same issue
<ogra> silly hybrid HW for windows
<plars> ogra: mouse/kbd go through a hub, usb stick is directly attached to the board
<ogra> right, high speed also indicates its the disk
<plars> yes
<ogra> though note that redboot is pretty outdated ... it might not initalize all HW omn the b3 properly, could be its fault
<ogra> i'll upload a new reboot tomorrow since we're unlikly to go for uboot
<ogra> (we're also still using the karmic binary)
<ogra> anyway, off ...
<ogra> else my GF kills me
<ogra> :)
#ubuntu-arm 2010-01-26
<ogra> cooloney, this is not funny ! everytime i file a bug you already have a fix prepared ... moaning and grumbling isnt fun anymore this way :)
<ogra> j/k indeed :)
<ogra> thanks for the devtmpfs fix, i'll test it later today
<persia> ogra: Consider it an exercise in testing expectations.  The set of solutions may be vast, but you only get that for which you've asked :)
<ogra> heh, yeah :)
<asac> persia: do you know why a bunch of channels like -motu etc. require you to be registered now?
<asac> what incident triggered this ... and is that permanent?
<asac> someone said there was a spambot attack on weekend ...
<asac> but i am sure we had that before ;)
 * persia is laggy because of a meeting, but will post the URL
<persia> http://blog.freenode.net/2010/01/javascript-spam/
<persia> Should be sorted by next week.  tsimpson is monitoring and coordinating.
<asac> ok
<asac> but someone must have followed on our side and set +R on the channel
<asac> was there really a big problem?
<asac> i havent seen it and i was more or less regularly online
<persia> It's been a reasonably large issue in some channels.
<persia> tsimpson has been handling things.
<persia> I haven't set +r or +R here yet because I haven't seen spam.
<persia> But I only track ops stuff in -motu, -devel, and -arm, so I may be missing bits.
 * persia should probably go find out the status of -mobile, and handle that as well
<asac> persia: -devel seems to have the problem too
<asac> e.g. i dont autojoin there somewhat
<asac> anymore
<persia> Yes.  There was vast quantities of spam, and tsimpson made it go away.
<asac> its -devel -motu -bugs -desktop it seems
<persia> The solution is annoying, but like I said, we only need it until the end of the week.
<persia> And -meeting, at least.
<persia> Probably more.
<asac> hmm ok
<asac> -meeting seems to be ok
<persia> The flags get turned on and off depending on how much we get hit.
<ogra> ok, i got hard numbers for uboot vs redboot now:
<persia> You happened to join at the right time.
<persia> Anyway, people are working on it.  I'm watching them work on it.  It will be all over this weekend :)
 * persia goes back to paying attention to the meeting
<ogra> stopwatched to "uncompressing linux" with nearly identical setup (no boot.scr for uboot and the like which adds extra load time)
<ogra> uboot: 23 sec
<asac> result?
<ogra> redboot: 11sec
<asac> yeah. thats ho wit feels
<JamieBennett> :(
<asac> the mmc driver alone takes half of that time at least
<asac> i guess
<ogra> the loading isnt the part thats slowing down most though
<ogra> its the part wheer it unpacks the uimage/uinitrd that seems to add extra time
<asac> JamieBennett: hi ... did you file the final MIRs for launcher?
<asac> i think there is one still missing?
<asac> netbook-launcher-efl
<JamieBennett> asac: should all be there
<asac> ah
<asac> i see it
<asac> bug 512343
<ubot4> Launchpad bug 512343 in netbook-launcher-efl "[MIR] netbook-launcher-efl" [Undecided,New] https://launchpad.net/bugs/512343
<JamieBennett> :)
<ogra> also redboot doesnt separately initialize HW like uboot does ... i.e. the mmc is initialized directly where uboot needs to exec a command
<JamieBennett> asac: now just need to prode someone to review it
<asac> JamieBennett: did the other packages all get accepted now? or are there some with outstanding issues left?
<JamieBennett> asac: all accepted
<asac> yes
<JamieBennett> just need n-l-e then I'll update the seed
<persia> Does it need wncksync?  normal netbook does, which is causing some issues now (needs another MIR)
<JamieBennett> persia: no unless someone changed it without me looking
<asac> ok assigned ... lets see
<JamieBennett> asac: thanks
<asac> if it doesnt go quick (like by tomorrow) let me know
<JamieBennett> will do
<asac> i finally want this to be ready for the flip
<asac> ;)
<JamieBennett> as do I along with the casper stuff I'm doing
<asac> right
<asac> JamieBennett: how is the fix going?
<asac> for caching the db/template?
<JamieBennett> Really close, hope to have something sometime today.
<asac> really cool
<JamieBennett> I think it will shave about 30% off of the live-cd boot time if not more :)
<asac> i hoped for 50% ;)
<asac> j.k.
<JamieBennett> maybe ;)
<JamieBennett> It takes *3 minutes to boot* so knocking that down to 2 minutes helps :)
<JamieBennett> and we have time to improve further
<ogra> asac, so, on imx51 after install the SD still has a vfat partition with the livefs that always gets automounted on the desktop ... we cant wipe it during install because its mounted ... i researched a bit and it seems partitions labeled "RECOVERY" will never be automounted, any objections if we make our livefs partition on the imx51 image a recovery one ?
<ogra> (filesystem still stays as is, it just gets an extra label (one line change in debian-cd))
<asac> ogra: does that have other implications?
<asac> like something offering to recover system from there?
<asac> and then everything gets trashed or something?
<ogra> well, we could provide a script that turns the SD into a install media again :)
<ogra> but by default it simply would not mount the partition
<ogra> i just dont want to have the Sd icon on the desktop all the time after install
<ogra> and the user could happily reformat the partition to actually make use of the space (the label would be gone then)
<ogra> there is nothing that would react on a recovery patition elsewhere
<ogra> so nothing would "offer to recover system from there" or some such
<ogra> (though we could write somethng easily as i said above and sell that as a feature ;) )
<plars> sounds pretty useful actually
<ogra> the recovery option you mean ?
<ogra> or not having the SD mounted all the time
<plars> making use of the recovery partition as both a solution, and an added bonus
<ogra> well, as asac said above its a pretty dangerous feature
<ogra> so it would require some extra thought how to prevent a user to use it accidentially ...
<ogra> for now i just want to prevent mounting ... the idea that we could actually make use of that as a recovery tool just occured to me later
<ogra> though that doesnt even require to label the partition
<ogra> you just need to flash the initramfs from the casper dir into redboot and change the cmdline back to the livefs one
<asac> ogra: how is the RECOVER feature implemneted?
<ogra> thats a three line script
<asac> cant we do the same just for "BOOTFLOPPY" ?
<ogra> asac, udev has a rule to ignore all partitions that are labeled in a special way
<ogra> we dont needf to do that for BOOTFLOPPY
<ogra> it doesnt ahve a filesystem
<ogra> i.e. it doesnt get automounted
<ogra> # recovery partitions (taken from old hal rules)
<ogra> ENV{ID_FS_TYPE}=="ntfs|vfat", \
<ogra>   ENV{ID_FS_LABEL}=="RECOVERY|HP_RECOVERY|Recovery Partition|DellUtility|DellRestore|IBM_SERVICE|SERVICEV001|SERVICEV002", \
<ogra>   ENV{DKD_PRESENTATION_HIDE}="1"
<ogra> thats from /lib/udev/rules.d/95-devkit-disks.rules
<ogra> its just to prevent the vfat/ntfs partitions labeled in a special way to get automounted
<asac> ogra: lets take one step back. i think i dont understand whats this about.
<asac> i was under the impression it was aobut the /boot partition on the liveimage
<asac> we planned to have for uboot
<ogra> no
<ogra> its about the livefs partition we currently use on the imx51 image
<ogra> this is a vfat partition containing casper and the squashfs
<ogra> because it is mounted during install we cant delete or wipe it
<asac> yes. so i would label it LIVEFS then ;)
<ogra> so after install (since you need the SD to boot) that second partition is still there and devkit automounts it on your desktop
<asac> of course we need to ensure it gets still loaded for the live image
<ogra> casper doesnt care for labels
<asac> good
<ogra> that will only affect the automounting after install
<asac> so why not use CASPERLIVEFS or someting ?
<ogra> its a paper cut and a one liner can fix it
<asac> right
<ogra> because then i need to patch devkit
<asac> doesnt feel like a big thing
<ogra> which i'D like to avoid
<asac> using some other label that doesnt match what we do just because we dont want to touch devdisk isnt great either
<ogra> well
<ogra> its essentially is a recovery partition
<ogra> there is just not anything that makes use of it
<asac> a recovery partition is something else in my book
<asac> usually recovery partitions can be check pointed etc.
<asac> oh that is backup
<asac> so yes. if you are sure that a recovery partition would be a casper partition then its fine
<asac> but only if thats really the case ... is it?
<ogra> with a littel script that turns the SD back into a live image it is a recovery partition
<ogra> but indeed that would trash your install (as recovery tools often do)
<asac> what i am wondering is if there already is such a thing like ubuntu recovery partitions
<ogra> i dont think so
<asac> if there is we shouldnt reinvent the wheel
<ogra> i just want to prevent automount for now :)
<ogra> we could use an uglier way though
<ogra> see type 12 on http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
<asac> for me it feels bad to reuse a label that has a meaning
<asac> if its not true
<asac> rather we should really add a new label
<asac> and getting that into udev-disks doesnt sound that hard
<ogra> well, i find it uglier to patch devkit than just adding a pointless label
<ogra> but inventing a new one surely works too ... its just more patching in different places
<asac> the current list of labels in devkit are just added as needed
<asac> at least they look like
<ogra> # special MBR partition types (EFI, hidden, etc.)
<ogra> # see http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
<ogra> ENV{DKD_PARTITION_SCHEME}=="mbr", \
<ogra>   ENV{DKD_PARTITION_TYPE}=="0x00|0x11|0x12|0x14|0x16|0x17|0x1b|0x1c|0x1e|0x27|0x3d|0x84|0x8d|0x90|0x91|0x92|0x93|0x97|0x98|0x9a|0x9b|0xbb|0xc2|0xc3|0xdd|0xef", \
<ogra>   ENV{DKD_PRESENTATION_HIDE}="1"
<asac> i dont see why we cant add UBUNTU_CASPER there
<ogra> thats not as needed
<asac> does casper mount 12?
<ogra> but i dont want to play with the type if there is an easier way
<ogra> casper looks for filesystems
<ogra> so type shouldnt matter as long as its vfat
<asac> so yeah. lets use that
<asac> unless you see a reason against that
<asac> ogra: do bootloaders agree?
<asac> like uboot recognizing that?
<ogra> does uboot matter ?
<ogra> it doesnt use that partition
<ogra> initramfs is the only thing that counts here
<ogra> i.e. casper
<asac> oh
<asac> well. i thought if we used uboot we could boot the initfs and kernel from the casper cd
<ogra> well, you know how uboot works :)
<ogra> it loops over the vfat/ext2 partitions it finds
<ogra> as long as fatload works it wont care for partitioning or types
<ogra> i.e. the FS counts
<asac> ogra: i know that it does that, but i dont know 100% that it doesnt check fs type first
<asac> but if you say it doesnt then i believe you
<ogra> it looks for the fat signature, doesnt care for label or type
<ogra> so both should be fine to use
<ogra> asac, <ogra> but i dont want to play with the type if there is an easier way
<asac> ah
<asac> well. seems we can do everything on our own udev rule ;)
<ogra> i prefer LABEL its less dangerous
<ogra> right, so it doesnt matter :)
<ogra> we can even use an arch specific label then
<ogra> BABBAGE_LIVEFS or some such
<asac> yeah. if that makes most sense, go for it
<ogra> yup
<asac> we can make it more generic if needed
<asac> later
 * ogra looks how to do that from casper without slowing it down with additional bloat
<NCommander> ogra, I thought the goal with imx51 was to have it put its bootloader right into SPI-NOR and remove the need for the boot floppy approach to power up
<ogra> NCommander, with uboot, yes
<ogra> but we're unlikely to do uboot
<NCommander> ogra, what was the major hangup with uboot (sorry, I think I missed part of the conversation here yesterday)
<ogra> you seem to have missed the whole meeting today :P
<ogra> uboot still needs /boot on SD
<NCommander> ogra, oh, right.
 * NCommander is not quite on his A game this morning
<ogra> which would mean we'd need to a) build out images with three partitions and b) still use the bootfloppy
<ogra> and that for losing about 15 seconds bootspeed
 * NCommander puts the dunce cap on and stands in the corner
<NCommander> Oh well, at least we can have a uboot+imx51 spec again for lucid+1, continuing a UDS tradition
<ogra> beyond that it would require awful ubiquity hackery to make ubiquity reformat /boot and all during install on a mounted media
<ogra> i dont think i'll support uboot until USB support appears ...
<ogra> so likely ... never ...
<ogra> i.e. likely no lucid+1 spec
 * ogra dist upgrades his arm chroot to build new redboot
<zenvoid> hello Stskeeps, I see you are everywhere :P
<zenvoid> I was going to ask about the default gcc flags used in karmic build
<zenvoid> I was expecting an improvement of performance over 9.04 on a armv6 device
<zenvoid> but it turns out that it is 50% slower
<zenvoid> specially perl and scripting languages
<zenvoid> I guess it is related to vfp, but not sure
<ogra> shesh ... we'll do a jump from 200938 to 200952 with redboot
<lool> ogra: It's just ww
<ogra> ww ?
<lool> work weeks
<ogra> ah
<ogra> well, i expect some bbg3.0 additions
<lool> I can assure you there wont be a 200953  :-)
<ogra> lol
<lool> So it's effectively 2 months of development or so
<ogra> yeah
<ogra> well, i didnt expect to touch redboot again at all :)
 * ogra grumbles
<ogra> dpkg-source: warning: executable mode 0755 of 'debian/patches/02_freescale_imx51.dpatch' will not be represented in diff
<ogra> why the heck do all patch editing tools create them with executable bit then
<ogra> tsk
<lool> Only dpatch actually
<lool> Because it's a shell script too
<ogra> cdbs-edit-patch too
<lool> Which is why I hate dpatch
<lool> ogra: Really?  never seen that
<lool> ogra: Perhaps cdbs-edit-patch if it's a dpatch
<ogra> no idea, i only usually edit existing ones with it and afterwards i usually get this warning
<lool> cdbs-edit-patch has no chmod or umask calls so I don't think it's the culprit
<ogra> weird
<ogra> ok /me crosses fingers that the build fiup patch still applies and runs debuild -b for redboot
<ogra> *fixup
 * ogra cries 
<ogra> /tmp/ccszJnU4.s: Assembler messages:
<ogra> /tmp/ccszJnU4.s:473: Error: shift must be constant -- `orr r11,r10,r9,lsl r5'
<lool> The warnings are benign anyway; these are only an issue if you actually want the file to have this mode once installed and no tools ensure it does at build time (such as dh_fixperms or dpkg-builddeb)
<lool> That looks like a broken patch
<ogra> no, thats thumb
<ogra> needs -marm
<ogra> i was expecting it (every other bootloader i built did need -marm) but was hoping to save the time
<lool> Hmm I thought lsl was an instruction but it's actually a register
<lool> Hmm no it's definitely an instruction; I wonder what it's doing in your line
<ogra> no idea
<lool> Besides orr is supposed to take two args, bah I don't read arm assembly very well  :-(
<lool> orr r0, r2, lsr #8 is like r0 |= (r2 >> 8)
<lool> and you can't shift by a register in thumb mode apparently
<ogra> right
<ogra> as i said, needs -marm ...
<ogra> like apex does as well as uboot does
<ogra> i'm happy if its only that though
<ogra> root@babbage2:/redboot-imx-200952# chmod a-x debian/patches/*
<ogra> dpkg-source: warning: executable mode 0755 of 'debian/patches/03_build_fixups.dpatch' will not be represented in diff
<ogra> TSK !
<lool> Yeah hug dpatch
<ogra> god, so many warnings
<ogra> the quality degrades with every release ... but it builds
<ogra> dpkg-deb: building package `redboot-imx51-babbage' in `../redboot-imx51-babbage_200952-0ubuntu1_armel.deb'
<ogra> ha!
 * ogra takes a break until conf call ...
<asac> 19:45 < Riddell> asac: just accepted chromium, well done again on a heroic license evaluation feet
<ogra> wohoo '!!!!!
<ogra> congrats
<armin76> what does that mean?
<ogra> that chromium is in the archive
<armin76> oh
<armin76> http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=tree;h=refs/heads/imx_2.6.31;hb=imx_2.6.31 <- from #efika
<lool> armin76: Cool
<ogra> lool, yeah, in case you didnt notice there is http://opensource.freescale.com/git since a few days :)
<lool> Yeah I was looking at that, amazing
<ogra> :)
<lool> Linking to an obsolete uboot homepage :)
<ogra> heh
<lool> ltib -- never heard of that
<lool> Apparently a decently old project
<ojn> yeah, it's freescale's own bsp distro
<lool> Oh it's developed by freescale?
<ogra> yes
<ojn> yeah, they've used it on ppc for quite a while I think
<ogra> its also carrying the linux trees of the BSP patches
<ojn> never really looked at it, we preferred to ship a regular distro instead. :)
<ojn> ogra: in ppc land, those patches were a tall stack of cr*p. :)
<ojn> mostly old versions of patches someone else had cleaned up and merged in newer mainline kernels. seems like their arm side isn't as good. :)
#ubuntu-arm 2010-01-27
<cooloney_> NCommander: sorry, i missed the Mobile team IRC meeting last night,
<cooloney_> NCommander: is there any important thing for me?
<asac> cooloney_: hi
<lool> ogra: Do you manage to run the current versatile lucid linux-image kernel in qemu-system-arm?
<ogra> lool, havent tried yet but i plan to add a download function for the package to the lucid rootstock so i'll test soon
<lool> ogra: Would you mind pinging me when you look into this?
<ogra> will do
<lool> I couldn't get any video output or serial console output from it after Uncompressing linjux
<ogra> do you have probs with it ?
<ogra> oh
<lool> ogra: You don't have the modules for the kernels on your people.ubuntu.com pages?
<ogra> i dont think so
<lool> Sadly your cortex-a8 versatile kernel is missing some modules (not sure which) and mountall doesn't like that
<lool> These are also missing on x86, so they might be purposedly configured as modules in Ubuntu kernels in general
<ogra> right, i'll switch to the packaged lucid kernel for all cortex-a8 variants soon
<ogra> but indeed that requires that it works
<asac> ericm_: apw: dove kernel failed ( i guess you noticed)
<apw> asac, FTBFS ?
<ericm_> asac, 'm lookin into that
<asac> yes
<asac> ftbfs
<asac> thanks ericm_
<apw> ericm_, asac i've already uploaded a fix for it
<apw> https://edge.launchpad.net/ubuntu/+source/linux-mvl-dove/2.6.32-200.6
<ericm_> missing module ecb
<ericm_> command exited with status 1
<ericm_> make[2]: *** [do-binary-udebs] Error 2
<ericm_> make[1]: *** [binary-udebs] Error 2
<ericm_> make: *** [binary-arch] Error 2
<ericm_> dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary-arch gave error exit status 2
<ericm_> apw, thanks
<asac> apw: great. sorry for the noise ;)
<apw> ericm_, np ... just a stupid d-i interaction that we don't test well before upload
<apw> i've tested udeb generation on this one
<asac> sounds good
<ericm_> cool
<apw> asac, np better you tell me and i'm already doing it than not
<cooloney> asac: i am back
<apw> i have a lot of kernels in flight right now
<asac> cooloney: hi.
<asac> cooloney: wanted to touch base with you on NEON status
<asac> cooloney: so dmart pointed out that just exporting diffferent hwcaps based on board revision might not be good enough
<asac> e.g. user space apps could trash the board
<asac> any ideas?
<ogra> asac, hmm ? the patch was already uploaded :)
<ogra> its looking at the board revision number
<ogra> and only enables it on 3.0's
<asac> right. but what does it do
<asac> does it fully disable NEON if board is too old in kernel
<ogra> export the neon flag
<asac> or just tweaks hwcaps
<ogra> it disables the cpu flag
<ogra> -               if ((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
<ogra> +               if (((fmrx(MVFR1) & 0x000fff00) == 0x00011100)
<ogra> +                       && cpu_is_mx51_rev(CHIP_REV_3_0) > 0)
<ogra>                         elf_hwcap |= HWCAP_NEON;
<ogra> hwcaps
<cooloney> ogra: right
<cooloney> asac: ogra is right,
<asac> right. so thats the point
<asac> someone might argue its a security issue (DoS) that user space apps can run NEON instructions without getting a SIGILL on boards that dont support it
<asac> that was the argument made yesterday
<cooloney> asac: generally, there is no 'neon' when you run 'cat /proc/cpuinfo' on TO2 or TO1
<asac> cooloney: yes, but apps can still do it ... e.g. it doesnt cause  a SIGILL
<lool> Worse, it can actually hang the board
<asac> lool: thats the consequence e.g. the DoS i talked about above
<asac> cooloney: how hard would it be to make it so the kernel behaves as if CONFIG_NEON=n if its an old board?
<cooloney> asac and lool, right, probablly
<ericm_> asac, is the gvfs crash issue filed on LP?
<cooloney> asac: if CONFIG_NEON=y, it will enable some assemble code which is hard to do dynamical disable.
<cooloney> asac: but I will check them later
<NCommander> cooloney, what does this code do specifically?
<ogra> cooloney, would you see a prob if we enabled CONFIG_TIMER_STATS and CONFIG_HPET_TIMER on imx51 and dove ? powertop would like to have these
<ericm_> CONFIG_TIMER_STATS has been enabled on Dove
<ericm_> lemme check HPET
<ogra> ah, imx51 seems to not have it
<cooloney> ogra: OK, i will check them on imx51
<ogra> want a bug for it ?
<ericm_> ogra, sure - file both for imx51 and dove so we can check
<ogra> well, probably better since i can link it to the spec
<ogra> right
<ericm_> ogra, not sure HPET_TIMER or HIGH_RES_TIMERS
<ericm_> but HPET_TIMER sounds to me like x86?
<ogra> powertop moans about HPET_TIMER
<ogra> well ...
<ogra> its an inel app :)
<ogra> *intel
<ericm_> right, checked again: arch/x86/Kconfig:config HPET_TIMER
<ericm_> mmm... maybe we need to figure out the dependency of powertop over HPET_TIMER now
<ogra> ok, then we only wasnt TIMER_STATS
<ogra> no
<ogra> its HPET_TIMER is just a suggestion it makes
<ericm_> ok
<ogra> TIMER_STATS is actually needed for it to work
<ericm_> ogra, ok - file one for dove as well so we can check if that's working all right in 200.6
<ericm_> thanks
<ogra> will we have new uploads before next alpha ?
<cooloney> NCommander: those .S code of NEON is in arch/arm/kernel/entry-armv.S
<ogra> else i wont target it to a milestone
<cooloney> NCommander: generally, it will handle some NEON code and call neon version handler for VFP
<NCommander> cooloney, my ARM ASM is a bit rusty, but we should be able to stuff a check in there to dynamically determine if its a TO1/TO2 board, and jump past the NEON access code
<cooloney> NCommander: right, I know that, but still need to find a way to determine that. heh
<NCommander> ogra, is there a way in userland to determine if its a TO1/2 board, or if its a TO3 board
<ogra> NCommander, did you test suspend/resume on the dove =
<ogra> NCommander, /proc/cpuinfo
<ogra> the revision string
<NCommander> ogra, not yet
<ogra> NCommander, would be nice if you did and checked if it works from deskop menu (that would prove the pm-utils scripts work correctly)
<NCommander> ogra, assuming I can even get to the desktop
<ogra> on imx51 there are no issues so i'm inclined to say they work fine but i need confirmation from dove too
<ogra> i thought the desktop works now for a while
<ogra> at least thats what i heard about the recent liveimages
<ogra> if you manage to click before the panel crashes it should work as a test :)
<ogra> NCommander, i see "dove kernel to be uploaded with CONFIG_HIBERNATION set: TODO" on the pm spec, didnt that happen already ?
<ericm_> suspend/resume on dove still have a regression, yet I believe it's because I'm still using a DDR2 DIMM here
<ericm_> NCommander, you have a DDR3 DIMM with you, which you may help test a bit
<NCommander> ericm_, I have DDR2 systems.
<NCommander> I think GrueMaster has a DDR3 Dove
<ogra> ericm_, but was CONFIG_HIBERNATION set in the config ?
<ogra> i see no changelog entry saying so
<ogra> ericm_, Bug #502983
<ubot4> Launchpad bug 502983 in linux-mvl-dove "CONFIG_HIBERNATION needs to be set for dove kernels" [Undecided,Confirmed] https://launchpad.net/bugs/502983
<ericm_> ogra, never succeeded in resuming from hibernation, yet Marvell engineer thought it works
<ogra> well, either say its unsupported and close the bug or lets fix it :)
<ericm_> ogra, same reason - I'd suspect a regression in DDR re-initialization which only valid for DDR3
<ogra> i just want the spec item gone :)
<ericm_> ogra, think I'll fix it
<ogra> ok
<ericm_> anyone knows how to upload the existing crash report to LP?
<NCommander> ericm_, use ubuntu-bug *crash-file*  on the machine it happened
<ogra> apport has some commandline switch to attach to bugs iirc
<ericm_> NCommander, 'k
<ogra> NCommander, for your "[mcasadevall] check cpufreq functionallity on all boards (1 day): TODO"
<ogra> root@babbage2:~# echo powersave >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<ogra> root@babbage2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<ogra> powersave
<ogra> root@babbage2:~# cat /proc/cpuinfo |grep Bogo
<ogra> BogoMIPS	: 159.90
<NCommander> cooloney, you can get the machine_id for an ARM chip with the mrc instruction, or by using the read_cpuid_id function
<NCommander> (in the kernel of course)
<ogra> root@babbage2:~# echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<ogra> root@babbage2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<ogra> ondemand
<ogra> root@babbage2:~# cat /proc/cpuinfo |grep Bogo
<ogra> BogoMIPS	: 799.53
<NCommander> ogra, I assume I need a lucid userland for that?
<ogra> NCommander, can you do the same on a dove
<ogra> yes
<NCommander> ugh
 * NCommander has been trying not to use a lucid userland but a lucid chroot
<ogra> come on, boot a liveimage
<NCommander> ogra, let me grab one and I'll test
<ogra> takes a minute to test that and we're done with the spec item
<ogra> and make asac happy :)
<ogra> lets get below trendline before sprint ! :)
<NCommander> \ooo/
<NCommander> ogra, download in progress
<ogra> download ?
<ogra> you dont have one locally ?
<NCommander> ogra, I need to get a recent live image
<NCommander> I'm zsyncing it
 * NCommander 3> zsync
<ogra> GrueMaster, !
 * NCommander has his ia64 dualbooting Debian and Ubuntu
 * NCommander feels he's playing with powers that should better be left alone ...
 * ogra points NCommander to #ubuntu-ia64 :P
<NCommander> ogra, its lonely there :-P
<ogra> i can imagine
<ericm_> Mmmm...., cpufreq on dove actually turned on by command line "cpufreq_enable"
<ogra> can we turn that on by default ?
<ericm_> ogra, sure
<ogra> in kernel i mean
<ogra> afaik initramfs tries to switch them
<ericm_> yes, it's just controlled by a simple variable
<ogra> to speed up the boot
<ericm_> I'll try to file a bug report and patch for that
<ogra> i.e. we start with performance until the rootfs is up and then switch to ondemand iirc
<ogra> thanks
<ericm_> np
<ogra> ericm_, can you give me the bugnumber if you are done so i can add it to the spec
<ogra> (done filing i mean)
<ericm_> sure
<ericm_> moment
<ogra> thanks :)
<asac> chroot: cannot run command `debootstrap/debootstrap': Exec format error
<asac> still getting that even with binfmt_misc
<ogra> try a distro kernel
<ogra> i'm pretty sure there are bits missing in the vanilla build
<ogra> there is a procps value that needs to be set, vanilla might not allow that
<asac> ogra: you mean the kernel i am running?
<ogra> yes
<asac> ogra: i am running an ubuntu kernel
<asac> Linux tinya 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux
<ericm_> ogra, bug 513254
<ubot4> Launchpad bug 513254 in linux-mvl-dove "[dove] CPUFREQ isn't turned on by default" [Undecided,New] https://launchpad.net/bugs/513254
<ogra> thanks so much !
<ericm_> np
<ogra> asac, so i'd say the pm spec looks a lot better now
<asac> ogra: you updated the items?
<asac> already talked to jk?
<ogra> yes
<ogra> nope
<ogra> just DONE'd the low hanging fruits
<asac> ok i have that on my list still
<asac> great!!
 * asac will upgrade laptop to lucid today he thinks
 * ogra too i want lucid at the sprint
<ogra> but i'm scared a bit
<asac> ogra: i will let you know ;)
<asac> how it works out
<ogra> ok
<asac> have to finish my calls today first
<asac> but then i can risk the upgrade ;)
<ogra> i'm not even on latest karmic though
<ogra> i should probably first enable -updates  and go to the most recent packages :)
 * ogra does that
<asac> for me its really scary because i didnt upgrade that late in the past
<asac> always feels safer to upgrade in small chunks than going for the big jump ;)
<asac> even though the ground might be more solid
<ogra> yeah, same here
<ogra> i usually upgrade during A1
<asac> right. thats what i feel comfortable with too
<ogra> oooouff
<ogra> 287 packages
<armin76> asac: get me a pass for mwc :)
<suihkulokki> armin76: unless you regularry wear a tie mwc is very boring
<armin76> suihkulokki: but i can get boards! :P
<armin76> zumbi: you going to mwc?
<zumbi> armin76: mwc? what is it? i am going to fosdem, btw
<zumbi> suihkulokki: fosdem this year?
<armin76> zumbi: mobile world congress
<suihkulokki> neither..
<suihkulokki> see you both in debconf10 ;)
<zumbi> suihkulokki: we'll miss you then
<NCommander> suihkulokki, ooh, lucky. MWC will be fun
 * NCommander is looking forward to commuting to his second debconf
<zumbi> armin76: i do not think i am going to mwc, but if you get tickets I can partner you, just to kill the curiosity of the newer fancy screen devices
<zumbi> armin76: btw, attending debconf this year?
 * ogra dist-upgrades to see if he can reproduce plars' nautilus crash
<plars> ogra: yes, it's not good.  Trying to see if I can manually get a backtrace right now, but not having much luck finding the right -dbg packages to pull in
<ogra> plars, i definately dont get nautilus in my upgrade
<ogra> http://paste.ubuntu.com/363941/
<ogra> i suspect its rather one of the libs
<ogra> libglib2.0-0 smells like a good candidate here
<ogra> plars, oh
<ogra> plars, can you check the version of libgtk2.0-common vs the libgtk2.0 package ?
<ogra> i think common is arch: all  and gtk itself ftbfs
<ogra> so that could be our issue
<plars> yes, could be
<plars> libgtk2.0-0                          2.19.3-1ubuntu4
<plars> libgtk2.0-common                     2.19.4-1ubuntu1
<GrueMaster> ogra: what?
<ogra> aha
<ogra> GrueMaster, nothing anymore, i wanted to ask you for a quick cpufreq test on dove but it turned out its not yet enabled in kernel
<GrueMaster> ok
 * GrueMaster needs to remember to have a discussion on time zones during sprint.
<ogra> GrueMaster, yeah, i only checked my clock after i pinged, sorry :)
<plars> GrueMaster: I thought we agreed to abolish them?
<GrueMaster> I must have missed that memo (like so many others).
<armin76> zumbi: nope
<armin76> why do i want to go to a debian conf? :P
<zumbi> armin76: to meet NCommander et al., so you can ask for boards more effective
<NCommander> zumbi, you going to be at debconf 10?
<armin76> zumbi: you can ask on my behalf :D
<zumbi> NCommander: probably, i am thinking to get tickets rather soonish than later that it'll be omre expensive. I am unsure if dates are already fixed
<NCommander> zumbi, the dates are fixed to my knowledge
<NCommander> armin76, just wait for the new Sheevaplug ;-)
<zumbi> armin76: they know me, so they do not send me anything.. too slugish.. :-P
<armin76> NCommander: i don't want to!
<zumbi> NCommander: how are new sheevas? do they come with eSATA? or add wifi?
 * zumbi kicks armin76 to NYC
<NCommander> zumbi, I dunno, haven't seem then yet
 * NCommander steals armin76's SPARC and ia64 systems
<NCommander> bahaha
<zumbi> http://www.linuxfordevices.com/c/a/News/Marvell-Plug-Computer-30-and-Armada-300-and-610/
 * zumbi wants http://www.linuxfordevices.com/c/a/News/Mindspeed-Transcede-T4000-and-T4020/
<zumbi> armin76: last processors are shown at mwc. If you persuade somebody for tickets
<plars> ogra: downgrading libgtk2.0-common didn't help anything either
<plars> ogra: in case you missed my last...
<plars> ogra: downgrading libgtk2.0-common didn't help anything either
<ogra> yes, i know
<ogra> see -devel
<ogra> i did that
 * ogra somehow had a complete network breakdown over here 
<plars> ogra: ah, I saw that you had tried glib and gnome-session, wasn't sure about others
<ogra> i i actually upgraded gtk :)
<ogra> manually pulling debs from LP
<ogra> but its surely not get
<ogra> gtk
<ogra> sigh, that focus stealing of update-manager is annoying
<plars> ogra: got it
<plars> ogra: gvfs
<plars> ogra: looks to be probably libgvfscommon0
<NCommander> Apple finally announced a tablet
<NCommander> O_o;
<Stskeeps> it's kinda disappointing.
<ojn> haha
<Stskeeps> and embarassing from a ui invention and technical pov (check their pixel doubling to fit native iphone apps..)
<ojn> stskeeps: what else could they have done?
<ojn> I bet most apps will be updated to handle the new screen, it's just a stopgap thing.
<Stskeeps> ojn: it looks like a cheap copy of moblin.
<persia> Pity they went for such a low DPI.  Historically they've been pretty good at making sure stuff renders sharply.
<ojn> persia: apple has always been low-dpi. they're behind most other PC desktops/laptops on dpi as well.
<ojn> stskeeps: ah, you're a maemo guy. that explains the bitterness. :)
<persia> ojn: Hrm?  That's not been my experience.  Mind you, I went and got the special 300DPI handheld from Sharp back when it came out, but in terms of mainstream stuff they seem to go for higher DPI than other companies.
<ojn> persia: not for laptops. Took them forever to come out with a 1440x900 15" laptop, and they're still at that resolution for those screens. 17" has a highres option though.
<persia> ojn: Hrm.  Strange.  I haven't looked at their laptops in a *long* time, but the marketing materials still talk about high-DPI.
<ojn> everything is relative. It's quite appropriate DPI for most things, I'm not complaining. But thinkpads and some other brands have quite a bit higher resolution screens. Too high for some use, I would say. But nice for programming
<persia> Oh well, I guess the low DPI is in line with other things then :)
<persia> There is no such thing as too much DPI : you just get better rendering :)
<ojn> right, and bigger fonts. and apps that handle that nicely (and that's the catch, not all do)
<persia> Those are bugs :)
<persia> But the fonts should be the same size.  Those are supposed to be defined in ems not pixels.
<persia> Or points, but that's related to ems.
<armin76> rabeeh: get me a pass for mwc2010!
#ubuntu-arm 2010-01-28
<rd> hello
<rd> does any one know where there is some instructions on how to install ubuntu arm on n800?
<neure> hi
<neure> is asm("bkpt"); a good way to cause breakpoint in code?
<asac> o/
<asac> cant believe that my auto joining works again ;)
<asac> even on +R channels
<asac> seems i sent "ident" to nickserv which it doesnt like anymore
<ogra> well, dont reconnect in a way that you get an underscore on your nick
<ogra> thats overly annoying
<asac> attached filtered debdiff for gvfs update (re bug 512959)
<ubot4> Launchpad bug 512959 in gvfs "nautilus assert failure: *** stack smashing detected ***: nautilus terminated" [High,Confirmed] https://launchpad.net/bugs/512959
<dmart> asac: Hi there; unfortunately I had an overrunning meeting, but I'm available now.
<asac> dmart: hi
<asac> cool
<asac> so i started to file bugs ;)
<asac> for main
<asac> added the numbers to the status col
<asac> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
<asac> i am done to gmp
<dmart> Looks good
 * asac wonders if there is a shorthand syntax for lp bugs in the wiki
<asac> i didnt subscribe you to those bugs as you are member of ubuntu-armel i figured
<ogra> asac, i think there is, but i cant remember the syntax, i know persia usually does :)
<asac> universe are so many packages :(
<dmart> dunno... I shoved it though sed... refresh the page
<ogra> yeah
<asac> anyway. getting the logs now
<dmart> I was seeing a lot of false-positives, so it may be relatively quick
<asac> great
<asac> ok got the logs ... (thx wiki) ... now geting a new coffee and then we can lift off ;)
<asac> ok after not visiting that page lets get started ;)
<asac> cacao
<asac> needs a check (by doko)
<dmart> Yes.  I'm not sure why this appears separately from cacao-source; I guess it's basically the same issues
<asac> uses atomics and mov in various places
<asac> cdecl
<asac> false+
<asac> cell-binutils
<asac> wonders what that is
<asac> guess needs to be checked
<asac> various hits ... not obvious what is used where and how
<asac> hmm. where is that?
<asac> i cant even find the source
<asac> !info cell-binutils
<ogra> thats for PS3
<ubot4> asac: Package cell-binutils does not exist in karmic
<ogra> nothing for arm anyway
<asac> !source cell-binutils
<ubot4> asac: Error: I am only a bot, please don't think I'm intelligent :)
<asac> ogra: there are files name "arm" in the source at least
<asac> but ok
<asac> if you say its ps3 then its ok
<ogra> well, its for the cell CPU, but i bet derived from nowmal binutils
<asac> i guess same is true for other cell-*
<asac> like cell-gcc cell-gdb etc.
<ogra> likely
<asac> ogra: ?
<asac> "info cell-gcc
<asac> !info cell-gcc
<ubot4> asac: Package cell-gcc does not exist in karmic
<ogra> heh
<asac> !source cell-gcc
<ubot4> Factoid 'source cell-gcc' not found
<asac> damn bot ;)
<ogra> i think the bot only knows x86 anyway
<asac> !apt cell-gcc
<ubot4> Factoid 'apt cell-gcc' not found
<ogra> !info uboot-imx
<ubot4> ogra: Package uboot-imx does not exist in karmic
<ogra> see
<asac> !madison cell-gcc
<ubot4> asac: Error: I am only a bot, please don't think I'm intelligent :)
<ogra> oh, karmic
<ogra> !info redboot-imx
<ubot4> ogra: Package redboot-imx does not exist in karmic
<asac> !info uboot-imx lucid
<ogra> right, there you go
<ubot4> asac: Package uboot-imx does not exist in lucid
<asac> isnt there a version=
<asac> in the binary?
<asac> i think it just knows binaries
<ogra> not for the source package
<ogra> ah
<asac> !info uboot-imx51-to3
<asac> !info uboot-imx51-to3 lucid
<ubot4> asac: Package uboot-imx51-to3 does not exist in karmic
<ubot4> asac: Package uboot-imx51-to3 does not exist in lucid
<asac> ok
<asac> ubot4: please tell your owner to improve you. thx
<ubot4> asac: Error: I am only a bot, please don't think I'm intelligent :)
<ogra> heh
<asac> ok marked those as PS3
<asac> cpqarrayd
<asac> !info cpqarrayd
<ubot4> asac: cpqarrayd (source: cpqarrayd): monitoring tool for HP (Compaq) SmartArray controllers. In component universe, is extra. Version 2.3-1 (karmic), package size 17 kB, installed size 124 kB
<asac> aha
<asac> ;)
<asac> hmm. that one has parts of the kernel tree in the debian/ directory :(
<ogra> cool !
<asac> bah
<ogra> we should that more often !
<asac> is that normal?
<ogra> definately not
<dmart> ... sorry, distracted ...
<ogra> for that specific package probably ...
<asac> no problem ;) ... we did some bot training ;)
<ogra> it might need headers that the kernel doesnt ship by default or some such
<asac> thats why all the .S files are in there?
<dmart> I'm pretty sure cell-{gcc,binutils,etc.} will be Cell arch specific tools packages; punt those to doko?
<ogra> if he even cares
<asac> grep cpqarrayd * | pastebinit
<asac> http://pastebin.com/f1f093e3a
<ogra> not sure the sell port is still alive
<asac> dmart: i marked those as PS3 only for now
<ogra> *cell
<dmart> OK
<asac> thats what ogra said
<asac> aka nothing to do
<ogra> wow, thats ugly
<asac> ok saying that cpqarrayd needs to be checked ... has kernel tree in debian/
<asac> !info ctypes
<ubot4> asac: Package ctypes does not exist in karmic
<asac> grep ctypes * | pastebinit
<asac> http://pastebin.com/f15603dcf
<asac> needs investigation i would say ...
<asac> uses call_reg macro so might be good for mov
<asac> dmart: the ldr parts are a false-+ for that?
<asac> see paste above
<asac> ok next ...
<asac> grep cxxtools * | pastebinit
<asac> http://pastebin.com/f281dc3f0
<asac> seems to use atomics
<dmart> ctypes - that looks like x87 assembler, so probaby not relevant.  The mov pc, lr stuff seems to be in an embedded libffi, so can we link those two up?
<asac> dmart: so i will comment that hits are probably libffi dupes
<dmart> ok.
<asac> ok dd is false-+
<asac> ddd
<dmart> cxxtools - I agree
<dmart> ddd - agreed
<asac> deal.ii seems to be atomics again
<dmart> deal.ii - agreed
<asac> desmume
<asac> hmm. disassembler
<asac> migt be right.
<dmart> weird, guess we don't care about that
<asac> yes
<asac> dietlibc
<dmart> desmume - Nintendo DS emulator, apparently
<dmart> dietlibc - generally looks like it needs some porting (atomics, low-level asm)
<asac> ack
<asac> disktype
<asac> amiga ;)
<asac> false+
<dmart> yep
<asac> dosbox
<dmart> surely false-+... checking...
<asac> disasm again
<asac> e3
<asac> great package name ;)
<asac> grep e3- * | pastebinit
<asac> http://pastebin.com/feafed1
<dmart> what's this package?
<asac> checkig
<suihkulokki> dmart: some arm eabi support was added to dietlibc but I still didnt manage to get it to compile
<asac> !info r3
<ubot4> asac: Package r3 does not exist in karmic
<asac> !info e3
<ubot4> asac: e3 (source: e3): A very small editor. In component universe, is optional. Version 1:2.71-1 (karmic), package size 37 kB, installed size 120 kB (Only available for i386 kfreebsd-i386 amd64 kfreebsd-amd64)
<asac> hmm ... seems not relevant
<asac> (not supported arch)
<asac> ecl
<dmart> Weird that there is ARM code in there... it looks like someone tried to support it...
<asac> dupe of libatomic-ops i guess
<asac> yeah
<asac> but given what the bot said, the debian maintainer has explicitly marked it for just that arch?
<asac> those archs
<asac>                available for i386 kfreebsd-i386 amd64 kfreebsd-amd64)
<asac> okadded to comment that arm code exists
<asac> and someone might want to finish ;)
<dmart> suihkulokki: ftbfs just for lucid, or generally?
<dmart> asac: ok
<asac> so ok ... i said that ecl depends on libatomic-ops (which we have in main i think)
<asac> hmm ... and gmp ;)
<dmart> Yes, those both look like dupes, can we link them?
<asac> yes
<dmart> I expect we can dismiss the emacs packages (emacs23 in main was false-+)
<asac> well. i added that as comment
<asac> so i can add a task to the other bugs
<asac> yes
<suihkulokki> dmart: debian :)
<asac> (emacs)
<dmart> suihkulokki: so we can judge dietlibc as not Ubuntu-ready then? (Ubuntu is EABI)
<asac> !info etherboot
<ubot4> asac: etherboot (source: etherboot): Bootstrapping for various network adapters. In component universe, is optional. Version 5.4.3+dfsg-0.2ubuntu2 (karmic), package size 20515 kB, installed size 30644 kB
<asac> dfsg/src/arch/armnommu/core/start.S:
<NCommander> dmart, yeah, dietlibc is dead for ARM. There are patches to make it EABI complient, but upstream was stalled last I checked.
<dmart> NCommander, suihkulokki: I guess we don't have specific concerns for Thumb-2 right now then
<dmart> etherboot - bootloader, so we can probably ignore this one
<asac> ok ... i add acomment
<suihkulokki> dmart: unless you want to work on it..
<asac> (to dietlibc)
<asac> falconpl
<asac> !info falconpl
<ubot4> asac: falconpl (source: falconpl): The Falcon P. L. - command line tools. In component universe, is optional. Version 0.9.4-0ubuntu1 (karmic), package size 93 kB, installed size 252 kB
<dmart> suihkulokki: I'll see whether anyone else on my side knows about it :)
<asac> false-+
<asac> faumachine
<asac> !info faumachine
<ubot4> asac: faumachine (source: faumachine): Virtual machine running in user mode. In component universe, is optional. Version 20090512-1ubuntu1 (karmic), package size 1204 kB, installed size 4368 kB
<asac> false positive too
<asac> !info ffcall
<ubot4> asac: Package ffcall does not exist in karmic
<asac> http://pastebin.com/fe0b29f1
<dmart> faumachine - the match appears to be part of a comment, so OK
<asac> needs to be checked for mov's i guess
<dmart> Yes; doesn't look T2-compatible right now
<asac> ffmpeg-php -> false-+
<asac> fpc
<asac> mov and swp
<dmart> !info fpc
<ubot4> dmart: fpc (source: fpc): Free Pascal Compiler - Meta Package. In component universe, is optional. Version 2.2.4-3 (karmic), package size 10 kB, installed size 40 kB (Only available for all i386 powerpc sparc amd64 arm)
<dmart> Hmmm, I guess that needs looking at
<asac> yes. noted as mov and swp porting )
<dmart> !info freesci
<ubot4> dmart: freesci (source: freesci): a portable interpreter for SCI games like Space Quest 3. In component universe, is extra. Version 0.6.4-3 (karmic), package size 595 kB, installed size 1312 kB
<asac> onh
<NCommander> asac, fpc is going to be painful to port
 * NCommander did some looking at it
<asac> freesci needs to be looked at
<asac> not sure if that applies
<suihkulokki> NCommander: looked into fpc 2.4 too ?
<dmart> freesci - agreed
<asac> NCommander: right. its universe, so it comes last :)
<asac> fte -> false-
<asac> +
<asac> gamera
<NCommander> suihkulokki, nope
<asac> false-+, not arm asm
<dmart> gamera - false-+ (x86 asm)
<dmart> gauche-c-wrapper - embedded libffi?  (same implications as ctypes)
<asac> yes
<asac> has macro ... might be safe
<dmart> gcc-4.x -> doko (do we know which ones are actually in use to build stuff in universe?)
<asac> ok gcc stuff is already dealt elsewhere ... yes
<asac> gcj is next that doesnt have a comment
<asac> guess its doko too
<dmart> gauche-c-wrapper - yes, looks like a simple review
<dmart> gcj is gcc
<asac> gcl
<dmart> so doko again
<asac> yes
<asac> marked gcj for doko
<asac> !gcl
<ubot4> Factoid 'gcl' not found
<asac> !info gcl
<ubot4> asac: gcl (source: gcl): GNU Common Lisp compiler. In component universe, is optional. Version 2.6.7-45ubuntu1 (karmic), package size 45862 kB, installed size 152848 kB
<NCommander> gcl is evil in several ways
<NCommander> It has an embedded copy of binutils and gcc :-/
<asac> hmm. plenty of stuff i guess
<asac> ok so
<asac> grep gcl- * | grep -v binutils
<asac> search-arm-mov.filt: ./gcl-2.6.7/gmp3/mpn/arm/invert_limb.asm:	add	r2, pc, #invtab-.-8
<dmart> gcl - just embedded binutils, or is there anything else?
<asac> search-arm-mov.filt: ./gcl-2.6.7/gmp3/mpn/arm/udiv.asm:	mov	pc, lr
<asac> the rest should be covered by binutils
<dmart> embedded gmp3 might be the same as gmp?
<dmart> Probably, looking at our previous review
<asac> hmm
<NCommander> asac, I recommend you check the size of gcl's diff.gz if you want to see why I think gcl is crack
<dmart> !info gcl
<ubot4> dmart: gcl (source: gcl): GNU Common Lisp compiler. In component universe, is optional. Version 2.6.7-45ubuntu1 (karmic), package size 45862 kB, installed size 152848 kB
<asac> !info gclcvs
<ubot4> asac: gclcvs (source: gclcvs): GNU Common Lisp compiler, CVS snapshot. In component universe, is optional. Version 2.7.0-64 (karmic), package size 48061 kB, installed size 175136 kB
<dmart> ugh
<dmart> ;)
<asac> lol
<dmart> anyway, it looks to me like the hits are in imported packages
<asac> NCommander: i didnt say that gcl isnt crack ;) ... i dont know the code
<asac> binutils again etc.
<asac> damn
<asac> same as gcl
<asac> !info gdal
<ubot4> asac: Package gdal does not exist in karmic
<dmart> ok, needs a look in principle, but the problems are probably answered by addressing gmp and binutils (binutils may already be done anyway, depending on the age of the snapshot)
<asac> x86 assembbler
<dmart> For tools packages in general, we should try to find out if they're used to build anything
<asac> hmm. good point
<dmart> Can we tag such packages with a magic word, or collect them somewhere?  Sounds like someone could do a 1-pass review for build-deps later
<asac> not sure ... added that as a comment
<asac> we can decide when filing that bug
<asac> etc.
<dmart> gdal - "Geospatial Data Abstraction Library"
<asac> thats x86 asm
<asac> !gdb-avr
<ubot4> Factoid 'gdb-avr' not found
<asac> hmm. some disasm
<dmart> gdal - agreed
<asac> guess is related to gdb
<asac> will put that on doko plate
<dmart> I guess it's gdb for the avr arch
<dmart> ?
<asac> hmm
<dmart> gdm-m68blah similarly
<asac> there is arm code inside the -avr
<asac> not sure its because its a full copy of something
<asac> ok lets treat that as arch dependent
<dmart> That's probably just be a binutils dump
<asac> geshi
<asac> !info geshi
<ubot4> asac: Package geshi does not exist in karmic
<asac> false-+
<asac> php code
<dmart> "generic syntax highlighter"
<dmart> agreed
<asac> !info ghdl
<ubot4> asac: ghdl (source: ghdl): VHDL compiler/simulator using GCC technology. In component universe, is optional. Version 0.27+svn110+gcc4.3.3+dfsg-1 (karmic), package size 11429 kB, installed size 32804 kB
<asac> hmm. gcc copy
<asac> needs to be checked i guess
<asac> esp. because its 4.3.3
<dmart> ->doko?
<asac> lets say its doko ... yes. marked
<asac> !gimp-gap
<ubot4> Factoid 'gimp-gap' not found
<asac> !info gimp-gap
<ubot4> asac: gimp-gap (source: gimp-gap): The GIMP Animation Package. In component universe, is optional. Version 2.4.0-2ubuntu1 (karmic), package size 2526 kB, installed size 7896 kB
<asac> false-+
<dmart> yes
<asac> !info gnat-4.3
<ubot4> asac: gnat-4.3 (source: gnat-4.3): The GNU Ada compiler. In component universe, is optional. Version 4.3.4-1ubuntu1 (karmic), package size 12284 kB, installed size 55668 kB
<dmart> gnat-3.4 -> doko
<asac> i think we already have gnat
<asac> yes
<dmart> I think it comes out of the GCC tree anyway
<asac> !info gnu-smalltalk
<ubot4> asac: gnu-smalltalk (source: gnu-smalltalk): GNU Smalltalk interpreter and image. In component universe, is extra. Version 3.0.3-2 (karmic), package size 641 kB, installed size 2208 kB
<asac> uses call_reg macro
<dmart> libffi dupe again
<asac> probably ok but needs verified
<asac> yeah
<asac> !info gnuplot
<ubot4> asac: gnuplot (source: gnuplot): A command-line driven interactive plotting program. In component universe, is optional. Version 4.2.5-2 (karmic), package size 1 kB, installed size 20 kB
<asac> os2 ;)
<asac> false-+
<asac> !info google-perftools
<ubot4> asac: Package google-perftools does not exist in karmic
<asac> hmm linux syscall
<dmart> might need a look
<dmart> my guess is that it may not be critical
<asac> yes
<asac> !info gromacs
<ubot4> asac: gromacs (source: gromacs): Molecular dynamics simulator, with building and analysis tools. In component universe, is extra. Version 4.0.5-4 (karmic), package size 3684 kB, installed size 13188 kB
<dmart> false-+
<asac> false
<asac> y
<asac> ok guess gstreamer0.10-ffmpeg is dealt by ffmpeg
<dmart> probably... is that a separate source package?
<asac> hmm. maybe not
<asac> seems so
<ogra> suihkulokki, i get a lot of "unsupported syscall 335" in recent qemu-arm-static, that appears to be utrace, any idea about an existing fix ?
<dmart> embedded ffmpeg - someone should check it.  It may be one of those cases where the upstream project embeds a lib but we use the installed one (ie from the ffmpeg source package)
<dmart> gxemul - emulator - false-+
<asac> yes
<dmart> helix-player - a mov pc, lr; and some swp which might need porting
<asac> helix-player -> uses atomics
<asac> yes
<asac> hol88
<asac> !info hol88
<ubot4> asac: hol88 (source: hol88): Higher Order Logic, system image. In component universe, is optional. Version 2.02.19940316-8 (karmic), package size 9530 kB, installed size 44532 kB
<dmart> scary
<asac> false
<asac> +
<dmart> yes
<asac> !info ht
<ubot4> asac: ht (source: ht): Viewer/editor/analyser (mostly) for executables. In component universe, is optional. Version 2.0.17-1 (karmic), package size 619 kB, installed size 1668 kB
<asac> arm-dis
<dmart> looks like a disassembler
<asac> seems to not apply
<dmart> hurd - also scary :P  has this been ported to arm at all?
<asac> !info hurd
<ubot4> asac: Package hurd does not exist in karmic
<asac> heh
<asac> thats out
<asac> doesnt apply ;)
<asac> !info imview
<ubot4> asac: imview (source: imview): Image viewing and analysis application. In component universe, is optional. Version 1.1.9c-4ubuntu2 (karmic), package size 608 kB, installed size 1560 kB
<dmart> hurd - guess not (or someone else's problem)
<asac> false
<asac> (imview)
<dmart> yes
<asac> !info insight
<ubot4> asac: insight (source: insight): Graphical debugger based on GDB. In component universe, is optional. Version 6.7.1.dfsg.1-10.1ubuntu2 (karmic), package size 1804 kB, installed size 5284 kB
<asac> hmm
<asac> smells like something was copied ;)
<asac> i saw the sim/testsuite at least ;)
<asac> also ./insight-6.7.1.dfsg.1/bfd/elf32-arm.c:
<asac> thats some toolchain stuff?
<dmart> embedded gdb, bfd and stuff ... yeah, bfd comes from binutils
<suihkulokki> ogra: thats pselect6, feel free to implement :)
<dmart> one for doko?  I don't know what the /sim/ stuff is or how must we care
<dmart> suihkulokki, ogra: was pselect6 implemented for arm yet?
<dmart> asac: insighttoolkit - false-+ (x86 asm)
<dmart> ironpython - false-+
<dmart> jamvm - swp-based atomics and native calls with mov pc, lr
 * dmart grabs a sandwich
 * asac too
<ogra> i doubt pselect was implemented
<ogra> well pselect6
<asac> ok did a checkpoint save on wiki
<asac> getting some bread too
 * NCommander grumbles
<asac> ok seems we did a big chunk ;)
<asac> still only half way through :(
<ogra> hmm
<asac> kaya
 * ogra doesnt get why he still sees qemu: Unsupported syscall: 242
<asac> kino
<asac> ogra: i dont get why it doesnt work at all for me ;)
<asac> i am on lucid and plain lucid kerenel
<ogra> according to linux-user/arm/syscall_nr.h thats supported now
<asac> still get the binfmt problem :(
<ogra> weird
<ogra> works flawless here
<ogra> even after the upgrade
<ogra> can you try to run build-arm-choort standalone ?
<asac> i will try to just use qemu-arm-static chroot manually
<ogra> *chroot
<asac> right. thats the idea
<ogra> thats what i just did here
<asac> ruinning
<ogra> to find out if mono started to behave
<ogra> but apparently its not
<suihkulokki> ogra: that doesn't list supported syscalls. it lists syscall numbers.
<ogra> oh, i thought they are only added there when someone implemented it actually
<suihkulokki> read linux-user/syscall.c to find what is really supported
<ogra> ok, that expleins it then
<dmart> asac: did you get my comments up to jamwm?
<ogra> i know there exists a patch for pselect and ppoll somewhere
<asac> yes
<dmart> ok
<asac> dmart: i thought i saved that alradcy
<ogra> but no idea if that was ever applied
<asac> so lets continue
<asac> kaya and kino ;)
<dmart> I didn't read the scrollback very carefully...
<asac> kaya false-+
<dmart> jocaml?
<dmart> jocaml - some assembler with mov pc stuff, probably needs a look
<asac> yes
<asac> thats what is already in there
<asac> skipped it
<dmart> oh yes
<suihkulokki> and no, getaffinity will not help you get mono work in qemu linux-user if that is why you are after 242
<asac> kino seems armv4l
<asac> should be checked
<dmart> cross-ref kino to ffmpeg - it's a embedded ffmpeg (may not be a problem if the system ffmpeg libs are used)
<asac> hmm seems to be fffmpeg
<asac> kompozer -> is a mess
<asac> really old mozilla code
<asac> dont think we can port that
<asac> maybe it should finally get removed from archive
<dmart> !info kompozer
<ubot4> dmart: kompozer (source: kompozer): complete Web Authoring System. In component universe, is optional. Version 1:0.8~alpha4+dfsg+svn163-2 (karmic), package size 7328 kB, installed size 19580 kB
<dmart> hmmm, maybe make a note, but otherwise not too important I guess
<asac> yes
<asac> done
<asac> !info kvirc
<ubot4> asac: kvirc (source: kvirc): KDE based next generation IRC client with module support. In component universe, is optional. Version 4:4.0.0~svn3240-1 (karmic), package size 2976 kB, installed size 9276 kB
<dmart> kvirc - false-+
<asac> ack
<asac> !info libgd-gd2-noxpm-perl
<ubot4> asac: libgd-gd2-noxpm-perl (source: libgd-gd2-noxpm-perl): Perl module wrapper for libgd - gd2 variant without XPM support. In component universe, is extra. Version 1:2.39-2 (karmic), package size 216 kB, installed size 644 kB
<asac> false
<asac> +
<dmart> agreed
<asac> !info libgii
<ubot4> asac: Package libgii does not exist in karmic
<asac> atomics
<asac> !info libnet-dri-perl
<ubot4> asac: Package libnet-dri-perl does not exist in karmic
<dmart> yes, may need a look
<dmart> (libggi)
<asac> false-+
<asac> !info libopenspc
<ubot4> asac: Package libopenspc does not exist in karmic
<asac> other arch it seems
<asac> !info libtk-img
<ubot4> asac: libtk-img (source: libtk-img): Extended image format support for Tcl/Tk (runtime). In component universe, is optional. Version 1:1.3-release-8 (karmic), package size 118 kB, installed size 464 kB
<dmart> libopenspc - might be a snes music chip emulator lib iirc
<asac> also other arch false-+
<asac> yes, last two are other arch afaics
<asac> !info libv8 ?
<ubot4> asac: '?' is not a valid distribution: hardy, intrepid, jaunty, karmic, lucid
<asac> !info libv8
<ubot4> asac: Package libv8 does not exist in karmic
<asac> how did that get in that list? isnt libv8 the v8 js engine of chromium?
<asac> afaik thats only packaged outside of archive
<asac> anyway, needs a check ... generates arm code with mov
<asac> !info lifelines
<ubot4> asac: lifelines (source: lifelines): text-based genealogy software. In component universe, is optional. Version 3.0.61-1 (karmic), package size 967 kB, installed size 2392 kB
<asac> false+
 * dmart acks recent packages
<asac> !info lightning-sunbird
<ubot4> asac: Package lightning-sunbird does not exist in karmic
<asac> ok that one is mozilla code base
<asac> we will move to something based on 1.9.2 branch
<asac> so should be ok once we have the thumb patch landed
<asac> (otherwise we have the patch)
<asac> so: needs bump to 1.9.2 codebase + thumb2 patch
<dmart> I guess we should keep track of all these x has embedded y somehow
<asac> yeah
<dmart> linux-rt  - linux snapshow
<asac> well. we open bugs and since we do it from top down we can add new tasks to the other bug
<asac> yes, linux-rt -> dealt elsewhere?
<dmart> agreed
<asac>  not sure where ;)
<asac> we can assign a bug to cooloney or someone to ack that
<asac> !info llvm-gcc-4.2
<ubot4> asac: llvm-gcc-4.2 (source: llvm-gcc-4.2): C/C++ front end for LLVM compiler. In component universe, is optional. Version 2.6~pre1-0ubuntu1 (karmic), package size 23726 kB, installed size 107388 kB
<asac> doko gcc
<asac> ?
<dmart> I think this is llvm, not gcc; for main we just said to review; we can probably link those together
<asac> ok
<asac> !info ltp
<ubot4> asac: ltp (source: ltp): The Linux Test Project test suite. In component universe, is optional. Version 20090531+dfsg-4ubuntu1 (karmic), package size 51 kB, installed size 360 kB
<asac> false-+
<asac> !info lwp
<ubot4> asac: Package lwp does not exist in karmic
<asac> needes a check
<asac> mov
<asac> hmm
<dmart> ltp - agreed
<dmart> lwp - agreed (dunno what this is)
<asac> !info lyx
<ubot4> asac: lyx (source: lyx): Document Processor. In component universe, is optional. Version 1.6.4-1ubuntu1 (karmic), package size 3093 kB, installed size 7924 kB
<asac> atomics check
<asac> esems to be boost
<ogra> suihkulokki, hmm, there seems to be anold suse patch for 242 http://paste.ubuntu.com/364585/
<asac> marking
<ogra> *an old
<dmart> asac: lyx - agreed
<asac> !info mapivi
<ubot4> asac: mapivi (source: mapivi): Photo viewer and organizer with emphasis on IPTC fields. In component universe, is optional. Version 0.9.7-1 (karmic), package size 426 kB, installed size 1676 kB
<asac> false-Ã¼
<dmart> yes
<asac> !info mapserver
<ubot4> asac: Package mapserver does not exist in karmic
<asac> as well
<asac> !info metacity-themes
<ubot4> asac: metacity-themes (source: metacity-themes): Themes for the Gtk2 metacity window manager. In component universe, is optional. Version 1.0.11 (karmic), package size 384 kB, installed size 1956 kB
<asac> dito
<dmart> mapserver, metachtiy-themes - agreed
 * asac fighting with wiki ;)
<asac> ok
<asac> !info mit-scheme
<ubot4> asac: mit-scheme (source: mit-scheme): MIT/GNU Scheme development environment. In component universe, is optional. Version 7.7.90+20090107-1ubuntu1 (karmic), package size 6662 kB, installed size 18380 kB (Only available for i386)
<dmart> mit-scheme - x86 asm for scheme compiler... false-+
<asac> ack
<asac> !info mlton
<ubot4> asac: mlton (source: mlton): Optimizing compiler for Standard ML. In component universe, is optional. Version 20070826-1 (karmic), package size 10647 kB, installed size 47156 kB (Only available for amd64 hppa i386 powerpc sparc)
<asac> same
<dmart> looks like it
<asac> !info mupen64plus
<ubot4> asac: mupen64plus (source: mupen64plus): plugin-based Nintendo 64 emulator. In component universe, is optional. Version 1.5+dfsg1-7 (karmic), package size 1308 kB, installed size 4288 kB
<asac> hope thats too ;)
<asac> !info mysql-dfsg-5.0
<ubot4> asac: Package mysql-dfsg-5.0 does not exist in karmic
<dmart> mupen64plus - yes
<asac> atomics ... do we already have a mysql one in main?
<dmart> hmmm, I can't find it
<dmart> guess that may need a look
<dmart> !info netsurf
<ubot4> dmart: netsurf (source: netsurf): Small portable web browser with CSS and Unicode support. In component universe, is extra. Version 1.2-1build1 (karmic), package size 416 kB, installed size 1232 kB
<dmart> ...but the matches are in /riscos/, so I don't expect it applies for us
<dmart> openbios-ppc - surely not relevant
<asac> ok netsurf is false+ then with riscos
<asac> !info openocd
<ubot4> asac: openocd (source: openocd): Open on-chip JTAG debug solution for ARM and MIPS systems. In component universe, is extra. Version 0.0+r2403-1 (karmic), package size 1882 kB, installed size 4960 kB (Only available for alpha amd64 arm armel armeb hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 m32r m68k mips mipsel netbsd-alpha netbsd-i386 powerpc sh sparc)
<suihkulokki> ogra: which is buggy. and as I said, wont help with mono.
<dmart> openocd - some kind of embedded hardware debugger?  Probably not relevant for us.
<asac> interesting
<asac> guess that needs a check
<asac> hmm
<dmart> maybe take a quick look, but my guess is that the asm doesn't run on the host
<asac> i dont know how that is run. guess in worst case it can be built with -marm?
<asac> hmm code be
<asac> could
<dmart> Hmmm, yes, I guess the code will get built by something.  Maybe you're expected to install cross tools packages or something.
<asac> !info openser
<ubot4> asac: openser (source: openser): very fast and configurable SIP proxy. In component universe, is optional. Version 1.3.2-3 (karmic), package size 1357 kB, installed size 3856 kB
<asac> i like those "very, very" software ;)
<asac> atomics candidate
<asac> !info oprofile
<ubot4> asac: oprofile (source: oprofile): system-wide profiler for Linux systems. In component universe, is optional. Version 0.9.4+cvs20090629-2.1ubuntu2 (karmic), package size 1365 kB, installed size 5152 kB (Only available for i386 ia64 alpha hppa powerpc sparc amd64 arm armel mips mipsel s390 lpia)
<dmart> openocd - Depends: libc6 (>= 2.8), libftdi1 (>= 0.17), libgcc1 (>= 1:4.4.0), libusb-0.1-4 (>= 2:0.1.12), dpkg (>= 1.15.4) | install-info (not very informative)
<asac> false-+
<dmart> oprofile seems to work (-ish) on lucid, though I do have to unload and reinitialise it between profiling runs.
<asac> dmart: yeah. i marked openocd  package for manual review
<asac> yeah. but there is no real code in the filter logs
<asac> so i think its false-positive for this list
<asac> !info osiris
<ubot4> asac: osiris (source: osiris): network-wide system integrity monitor control interface. In component universe, is optional. Version 4.2.3-3 (karmic), package size 392 kB, installed size 916 kB
<dmart> oprofile - agreed
<asac> atomics ... db4.2 copy
<asac>  dupe
<dmart> yes
<asac> !info palbart
<ubot4> asac: palbart (source: palbart): An enhanced version of the PAL PDP8 assembler. In component universe, is extra. Version 2.4-5 (karmic), package size 17 kB, installed size 80 kB
<asac> false-+
<asac> paraview
<asac> !info paraview
<dmart> hmmm, 60-70% of the way through the list
<ubot4> asac: paraview (source: paraview): Parallel Visualization Application. In component universe, is extra. Version 3.4.0-4ubuntu4 (karmic), package size 43766 kB, installed size 154432 kB
<asac> yes. we can stop soon ;=)
<asac> paraview -> x86
<dmart> :)
<dmart> palbart - agreed
<asac> !info parrot
<ubot4> asac: parrot (source: parrot): A virtual machine for dynamic languages. In component universe, is optional. Version 1.4.0-1ubuntu1 (karmic), package size 205 kB, installed size 728 kB
<dmart> paraview - agreed
<asac> has a mov pc, ip
<dmart> Also in /jit/... guess it needs a look
<asac> yes
<asac> !info pdl
<ubot4> asac: pdl (source: pdl): perl data language: Perl extensions for numerics. In component universe, is optional. Version 1:2.4.3-8ubuntu1 (karmic), package size 4781 kB, installed size 15648 kB
<asac> false-+
<asac> good
<asac> !info perl-tk
<ubot4> asac: perl-tk (source: perl-tk): Perl module providing the Tk graphics library. In component universe, is optional. Version 1:804.028-5 (karmic), package size 2455 kB, installed size 8596 kB
<dmart> pdl - agreed
<asac> x86
<dmart> perl-tk - agreed
<asac> !info petsc
<ubot4> asac: Package petsc does not exist in karmic
<asac> alse false-+
<dmart> agreed
<asac> !info php-apc
<ubot4> asac: php-apc (source: php-apc): APC (Alternative PHP Cache) module for PHP 5. In component universe, is optional. Version 3.0.19-2 (karmic), package size 56 kB, installed size 172 kB
<dmart> swp-based spinlock
<asac> yes
<dmart> needs a look
<asac> !info plt-scheme
<ubot4> asac: plt-scheme (source: plt-scheme): PLT Scheme Programming Environment. In component universe, is optional. Version 4.1.5-1 (karmic), package size 32256 kB, installed size 147924 kB
<dmart> similar
<asac> libffi
<dmart> yes
<asac> and mzscheme
<asac> never heard of that
<dmart> mzscheme?
<asac> ok comment is: "libffi call_reg + mzscheme swp/atomics"
<asac> well ;)  the source file is:
<dmart> ok
<asac> ./plt-scheme-4.2.1/src/mzscheme/gc/include/private/gc_locks.h:
<asac> no clue if that is a third party
<asac> !info postgresql-8.3
<ubot4> asac: postgresql-8.3 (source: postgresql-8.3): object-relational SQL database, version 8.3 server. In component universe, is optional. Version 8.3.8-1 (karmic), package size 5011 kB, installed size 14132 kB
<dmart> yeah, dunno
<asac> guess that needs atomics
<asac> right... same fix we have for 8.4
<dmart>  ./postgresql-8.4-8.4.1/src/include/storage/s_lock.h:           "       swpb    %0, %0, [%2]    \n"
<dmart> yes, link it to that
<asac> done
<asac> !info ptop
<ubot4> asac: ptop (source: ptop): PostgreSQL performance monitoring tool akin to top. In component universe, is optional. Version 3.6.2-1 (karmic), package size 43 kB, installed size 144 kB
<dmart> false-+
<asac> yes
<dmart> python* -> doko?
<asac> python is doko
<asac> !info r-cran-eco
<ubot4> asac: r-cran-eco (source: r-cran-eco): GNU R routines for Bayesian ecological inference. In component universe, is optional. Version 3.1-4-1 (karmic), package size 248 kB, installed size 744 kB
<dmart> r-cran-* - looks like false-+
<asac> false-+
<asac> yes
<asac> (both)
<dmart> !info radare
<ubot4> dmart: radare (source: radare): free advanced command line hexadecimal editor. In component universe, is optional. Version 1:1.4-1 (karmic), package size 596 kB, installed size 1332 kB
<asac> !info radare
<ubot4> asac: radare (source: radare): free advanced command line hexadecimal editor. In component universe, is optional. Version 1:1.4-1 (karmic), package size 596 kB, installed size 1332 kB
<dmart> !
<asac> disassembler
<asac> guess can be ignored
<dmart> a hex editor with an arm disassembler in it?
<dmart> weird
<asac> hehe
<asac> ;)
<dmart> sounds like emacs ;)
<asac> maybe i should try that :)
<asac> !info rlplot
<ubot4> asac: rlplot (source: rlplot): Generate publication quality graphs. In component universe, is optional. Version 1.4-1 (karmic), package size 955 kB, installed size 2440 kB
<dmart> can see how that might be useful
<asac> false
<asac> +
<dmart> yes
<asac> !info root-system
<ubot4> asac: root-system (source: root-system): Meta package to install all ROOT packages. In component universe, is optional. Version 5.18.00-2.3ubuntu2.1 (karmic), package size 26 kB, installed size 72 kB
<asac> x86
<dmart> root-system - x86 asm false-+
<asac> !info rtai
<ubot4> asac: rtai (source: rtai): Real Time Application Interface. In component universe, is extra. Version 3.6.1-1 (karmic), package size 34 kB, installed size 68 kB
<dmart> some arm asm in there... probably needs a look
<asac> whats that? with imx patches?
<dmart> (atomics, pc arith)
<dmart> unless this is a bare-metal thing?
<dmart> Probably imx < imx51
<asac> yeah
<asac> !info scummvm
<ubot4> asac: scummvm (source: scummvm): free implementation of LucasArts' SCUMM interpreter. In component universe, is optional. Version 1.0.0~rc1-1-1 (karmic), package size 3465 kB, installed size 9152 kB
<dmart> (there are some earlier architectures)
<asac> seems it has mov
<asac> search-arm-mov.filt: ./scummvm-1.0.0~rc1-1/backends/platform/ds/arm9/source/interrupt.s:	mov	pc,lr
<asac> ?
<asac> or isnt arm9 what we are doing?
<asac> hmm .. .gues snot
<asac> needs to be checked ;)
<dmart> might need a look... it might be in sound chip cmulation code or something though
<dmart> have to have scummvm working on netbooks though :)
<asac> yes
<asac> !info sdparm
<ubot4> asac: sdparm (source: sdparm): Output and modify SCSI device parameters. In component universe, is optional. Version 1.02-1 (karmic), package size 113 kB, installed size 372 kB
<asac> false
<dmart> yes
<asac> ok seamonkey is mozilla gain
<asac> needs 1.9.2
<asac> etc.
<dmart> ok
<dmart> see - false-+
<asac> !info skyeye
<ubot4> asac: skyeye (source: skyeye): Embedded Hardware Simulation. In component universe, is extra. Version 1.2.5-2ubuntu1 (karmic), package size 239 kB, installed size 700 kB
<dmart> Did we alreay have ser?
<asac> oh skipped ;)
<asac> sorry
<asac> !info ser
<ubot4> asac: ser (source: ser): high-performance SIP server. In component universe, is optional. Version 2.0.0-2 (karmic), package size 1488 kB, installed size 3876 kB
<dmart> some atomics, it does use lrdex/strex but we need to check that is actually used on v7, and that it's smp-safe
<dmart> skyeye - a emulator of embedded arm platforms, guess it doesn't apply
 * dmart scrolls again
<dmart> I can see the end of the table now
<dmart> sm - looks like false-+
<dmart> !info softgun
<ubot4> dmart: softgun (source: softgun): ARM system emulator. In component universe, is optional. Version 0.16-2ubuntu1 (karmic), package size 372 kB, installed size 1096 kB
<dmart> softgun - false-+ (arm instruction decode emulation...)
<asac> sorry got pulled out ;) ... back now
<dmart> I think we had skyeye, softgun since
<dmart> Plus ser if you didn't note that yet
<dmart> spu-newlib - code looks similar / the same as newlib from main.  I guess we can link the two.
<dmart> !info survex
<ubot4> dmart: survex (source: survex): cave surveying and mapping software. In component universe, is extra. Version 1.0.39.1-2.1 (karmic), package size 656 kB, installed size 1700 kB
<dmart> some asm code in /riscos/ ... probably doesn't apply
<asac> softgun, yes.
<dmart> synopsis - embedded libatomic_ops
<dmart> (or very similar code anyway).  Link those?
<asac> eah
<asac> yeah
<dmart> !info systemtap
<ubot4> dmart: systemtap (source: systemtap): instrumentation system for Linux 2.6. In component universe, is optional. Version 0.0.20090613-1 (karmic), package size 851 kB, installed size 3440 kB (Only available for i386 amd64 ia64 s390 powerpc arm armel armeb all)
<dmart> I guess it needs a look... sub <reg>, pc, 4
<asac> yes
<dmart> What does ubot mean by (Only available for [...] all)?
<asac> uboot-imx -> skip
<dmart> uboot-imx - yes
<asac> no clue
<asac> thats a bug
<dmart> Well, I guess it's logically true ;)
<armin76> !info asac
<ubot4> armin76: Package asac does not exist in karmic
<asac> we are really almost done
<asac> like 12 to go ;)
<asac> !info uclmmbase
<ubot4> asac: Package uclmmbase does not exist in karmic
<dmart> looks like false-+ to me
<asac> ack
<dmart> virtualbox-ose - what's this doing with embedded mozilla code?
<asac> dont ask me :(
<asac> needs to be check
<asac> ed
<asac> !info visualboyadvance
<ubot4> asac: visualboyadvance (source: visualboyadvance): full featured Game Boy Advance emulator. In component universe, is extra. Version 1.8.0-5 (karmic), package size 308 kB, installed size 1360 kB
<dmart> visualboy advance - emulator, not relevant I guess
<asac> haha
<asac> yeah
<asac> !info vtk
<ubot4> asac: Package vtk does not exist in karmic
<asac> x86
<dmart> seems to be some x86 asm
<ogra> asac, did your test with build-arm-chroot work ?
<asac> ogra: failed the same way :(
<asac> I: Extracting sysvinit-utils...
<asac> I: Extracting tar...
<asac> I: Extracting tzdata...
<asac> I: Extracting upstart...
<asac> I: Extracting util-linux...
<asac> I: Extracting zlib1g...
<asac> chroot: cannot run command `debootstrap/debootstrap': Exec format error
<ogra> meh
<asac> websvn -> false-+
<ogra> try to reinstall qemu-arm-static
<dmart> wrong arch?
<asac> !info wine
<ubot4> asac: wine (source: wine): Microsoft Windows Compatibility Layer (Binary Emulator and Library). In component universe, is optional. Version 1.0.1-0ubuntu8 (karmic), package size 7359 kB, installed size 54436 kB
<asac> ogra: will do. does that compile something on install?
<asac> false positive (wine)
<ogra> it sets the sysctl stuff for procps
<dmart> I don't expect wine works on arm?
<asac> same for wine1.2
<asac> heh
<ogra> and dumps the binfmt hgandler in place
<asac> would be funny if it did ;)
<ogra> *handler
<dmart> wireshark -+
<asac> ogra: let me finish this ;) ...
<ogra> probably wine-ce :)
<asac> almost dying ;)
<dmart> wxwidgets* -+ (same x86 code as vtk)
<asac> !info wireshark
<ubot4> asac: wireshark (source: wireshark): network traffic analyzer - GTK+ version. In component universe, is optional. Version 1.2.2-2 (karmic), package size 716 kB, installed size 1824 kB
<dmart> (only 6 more)
<ogra> asac, yeah, i see W :)
<asac> ah
<asac> yeah thats fals-+
<asac> and the ex thing too
<dmart> !info xenomai
<ubot4> dmart: Package xenomai does not exist in karmic
<dmart> bah
<asac> !info xemacs21-packages
<ubot4> asac: Package xemacs21-packages does not exist in karmic
<asac> guess emacs is covered
<dmart> yes
<dmart> xenomai has swp-based atomics and other asm
<dmart> probably needs a look
<asac> yeah. lots of stuff in there
<asac> !info xindy
<ubot4> asac: xindy (source: xindy): index generator for structured documents like LaTeX or SGML. In component universe, is optional. Version 2.3-2 (karmic), package size 2245 kB, installed size 3656 kB
<dmart> I predict -+
<asac> it has mov etc.
<dmart> oh
<asac> rte/...
<asac> that looks familliar
<asac> is that a code copy again?
<dmart> clisp-2.43/ffcall
<dmart> I don't think so (can't find it anyway)
<asac> yes
<asac> !info xmp
<ubot4> asac: xmp (source: xmp): A module player supporting AWE32, GUS, and software-mixing. In component universe, is extra. Version 2.7.0-0ubuntu1 (karmic), package size 235 kB, installed size 560 kB
<dmart> some embedded lisp interpreter anyway
<asac> false-+
<asac> !info xulrunner
<ubot4> asac: xulrunner (source: xulrunner): XUL + XPCOM application runner. In component universe, is optional. Version 1.8.1.16+nobinonly-0ubuntu1 (karmic), package size 279 kB, installed size 1020 kB
<asac> -> covered by xul 1.9.2 + patch
<asac> still needed (so a bug)
<asac> !info yabause
<ubot4> asac: yabause (source: yabause): beautiful and under-rated Saturn emulator. In component universe, is optional. Version 0.9.10-1 (karmic), package size 16 kB, installed size 52 kB
<asac> (LAST ONE)
<asac> x86 false +
<dmart> -+ yes
<asac> yessssss
<ogra> whats a saturn emulator
<dmart> The author is modest in the description ;)
<dmart> sega saturn?
<asac> ok saving
<asac> uff
<asac> i think i need a break
<ogra> ah, sega
<ogra> i was wondering about something kosmic :)
<dmart> main() { while(1) be big and round; }
<asac> dmart: did you move the false-positives out to a separte table for main?
<asac> i guess we should do tha tbefore starting to file bugs ;)
<dmart> I made a heading with "Disregarded packages (no further action required)" - the junk is under there.  We can maybe move all that stuff to the end of the page
<asac> yeah
<asac> or to a separte wiki page even
<dmart> For universe, I already made [DISREGARDED], though it is not a proper wiki heading
<asac> to make that page less huge
<dmart> Yes, a separate page would be good
<asac> we should surely add a ToC
<dmart> How do you do that in the Ubuntu wiki?
<asac> one second there are examples
<asac> like on this page: https://wiki.ubuntu.com/MozillaTeam
<asac> so ||<tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; background-repeat: no-repeat; background-position:  98% 0.5ex; margin: 0 0 1em 1em; padding: 0.5em;"><<TableOfContents>>||
<asac> guess just <<TableOfContents>> wrks
<asac> but looks bad
<asac> let me add it
<dmart> okay
<dmart> thanks
<asac> ok its on there
<asac>  a bit huge ;)
<dmart> it works
<asac> hmm. let me remove the width constraint
<asac> thats bad
<asac> ok saved
<asac> its better now
<asac> dont think we need a new page with that
<dmart> ok
<asac> just so that the not so releva nt stuff gets to the bottom or osmething
<dmart> I should write a wiki page with an overview of what sort of action is needed to fix the different kinds of matches, then we can link to if from the bugs raised
<asac> dmart: yes, if you can do that it would be great
<asac> we could also port a few different cases, and then point to the patches as examples
<asac> if thats easier
<dmart> Yes, that would be good.
<dmart> I'm writing some stuff for the wiki now...
<dmart> The "mov pc" type cases, and cases where "swp" is causing ftbfs, are the highest priority things for luci, since these may break function calls.
<dmart> The swp and smp-safety stuff is more for future-proofing and some performance aspects (though we should work through these, time allowing).
<dmart> I'll try to explain this on the wiki...
<asac> 17:13 < seb128> asac, can somebody maybe get a stracktrace?
<ogra> hmm, so sqid fails reliably at the same line with a segfault
<asac> plars: ^^
<asac> thats on nautilus crash
<ogra> *squid
<asac> plars: we are looking at the diff atm.
<plars> asac: this is on the gvfs thing?
<asac> plars: yes
<plars> asac: sure, let me see what I can do
<asac> ogra: we want the -save-temps .ii ... then give that doko
<ogra> ?
<asac> guess needs a local build ;)
<asac> ogra: doko probably will probably want a .ii file for the source that causes the gcc crash
<asac> so build with -save-temps
<asac> in CFLAGS
<ogra> oh, ok
<asac> dmart: thanks.
<asac> i will try to adjust priority for the bugs i file accordingly
<asac> making the mov pc and swp with ftbfs release critical
<asac> ogra: so what do you want from binfmt?
<ogra> i ?
<ogra> you want something from binfmt :)
<ogra> check if /usr/share/binfmts/arm exists
<asac> find /sys/  | grep binfmt | pastebinit
<asac> http://pastebin.com/f63420615
<asac> ok
<ogra> and also check for /etc/sysctl.d/qemu-arm-static.sysctl.conf
<ogra> these are the two files that enable qemu-arm-static
<asac> i have /usr/share/binfmts/arm
<asac> cat /etc/sysctl.d/qemu-arm-static.sysctl.conf
<asac> vm.vdso_enabled = 0
<asac> vm.mmap_min_addr = 4097
<asac> now reinstalling the quem-arm-static
<asac> one second
<ogra> well, thats all looking good
<ogra> do you have /etc/rc2.d/S90binfmt-support ?
<lool> asac: It's in /proc
<lool> /proc/sys/fs/binfmt_misc/arm usually
<asac> ogra: yes.
<asac> cat /proc/sys/fs/binfmt_misc/arm
<asac> enabled
<asac> interpreter /usr/bin/qemu-arm-static
<asac> flags:
<asac> offset 0
<asac> magic 7f454c4601010100000000000000000002002800
<asac> mask ffffffffffffff00fffffffffffffffffeffffff
<asac> looks good too i guess :(
<ogra> lool, last time we checked his machine didnt even have binfmt_misc loaded
<lool> asac: Try running /usr/bin/qemu-arm-static
<asac> yeah. thats loaded now
<asac> (i force it in modules)
<ogra> asac, by running the initscript ?
<ogra> thats wrong
<asac> ogra: no in /etc/modules
<ogra> the initscript wraps a lot of other stuff around it
<asac> guess i need some arm binary
<ogra> check if you have /etc/rc2.d/S90binfmt-support in place
<asac> to test /usr/bin/qemu-arm-static
<asac> what would be a good one?
<ogra> just run build-arm-chroot
<asac> ogra: i have /etc/rc2.d/S90binfmt-support
<ogra> second stage execs in qemu-arm-static
<asac> ogra: well. thats what i ran before ;)
<asac> it failed the same way
<ogra> then i dont get why you have to forcefully load the module
<asac> and since i didnt even change anything i would think it still fails
<ogra> if the initscript runs it should load it
<asac> anyway. i reinstalled the package
<asac> let me try again
 * asac runs
<ogra> i suspect its rather binfmt-support
<asac> build-arm-chroot lucid lucid1
<ogra> than qemu-arm-static
<ogra> +you should really use a local package proxy :)
<asac> what does /usr/sbin/update-binfmts do?
<asac> worth running?
<ogra> it enables the arm binfmt handler
<ogra> it runs from the postinst of qemu-arm-static
<asac> ok reinstalling the -support package
<asac> hmm
<asac> update-binfmts: warning: current package is openjdk-6, but binary format
<asac> already installed by sun-java6  * Enabling additional executable binary formats binfmt-support
<asac> guess thats not a prob
<asac> lets wait if the chroot fails again
<ogra> yeah
<ogra> i dont get why your binfmt module isnt loaded though
<asac> ogra: its loaded atm
<asac> havent checked if it still doesnt get loaded
<ogra> no, i mean by the initscript
<asac> will reboot after the chroot fails
<asac> yeah. i will double check ... maybe its fixed now somehow ;)
<ogra> heh
<plars> asac: wasn't having much luck getting a backtrace with symbols yesterday, but I'm not seeing any -dbg packages for gvfs stuff
<asac> plars: we have -dbgsym
<asac> http://ddebs.ubuntu.com/
<asac> https://wiki.ubuntu.com/DebuggingProgramCrash
<ogra> and -dbg packages should additionally be on LP
<asac> there are the apt lines you need to get -dbgsym for packages that dont have -dbg
<asac> not for all packages
<ogra> usually for all gnome ones
<asac> ogra: none for gvfscommon
<ogra> oh
<asac> plars: so yeah. grab the -dbgsym ... also for glib i guess and gio or whatever is involved
<asac> and libc-dbg
<asac> etc.
<asac> but guess you just lacked the ddeb trick
<asac> ogra:
<asac> I: Configuring libselinux1...
<asac> I: Configuring libstdc++6...
<asac> I: Configuring coreutils...
<asac> I: Configuring makedev...
<asac> that looks good, right?
<ogra> yes
 * asac thinks it didnt get that far last time
<asac> nice
<asac> so reinstall one of the two packages helped
<asac> so seems something with triggers isnt right
<asac> bad packaging ;)
<ogra> i suspect binfmt-support
<asac> guess it doesnt ship any triggers
<asac> but should
<ogra> since the module was missing
<asac> too bad i reinstalled both ;)
<asac> otherwise we would have known it now
<ogra> or its just that lool broke qemu-arm-static with all his repackaging :P
 * ogra hides
<asac> lol
<asac> did anything happen on that front at all?
<asac> thought its still the same somewhat
<ogra> no, we dropped the spec
<ogra> it works, why break it
<ogra> i'D love to see mono support
<ogra> then rootstock wouldnt need a vm
<ogra> but given that this seems close to impossible to fix (its very old and many people tried before) i wont waste my time on it
<asac> ok now for rootstock
<Devils0411> ÃÃ±Ã¥Ã¬ Ã¤Ã®Ã¡Ã°Ã»Ã© Ã¢Ã¥Ã·Ã¥Ã°
<Devils0411> Ã¥Ã±Ã²Ã¼ Ã°Ã³Ã±Ã±ÃªÃ¨Ã¥?
<ogra> Devils0411, english please :)
<ogra> lool, did you get anywhere with the versatile kernel ?
<Devils0411> Offtopic. Who knows, what OS in this device http://www.promise.com/product/product_detail_eng.asp?segment=undefined&product_id=211
<plars> asac: still not having much luck
<asac> plars: how does the backtrace look like?
<plars> asac: http://paste.ubuntu.com/364678/
<asac> plars: post that to the bug and say thats best you can get
<asac> what is signal 6 ?
<plars> asac: sigabrt
<ogra> thats not gvfs
<asac> ogra: the downgrade of libgvfscommon fixes it
<ogra> cant you somehow get a gvfs BT
<asac> could be that its nautilus, but for now it feels its gvfs ... especially since that has a recent update
<ogra> no, i meant the backtrace
<asac> well. nautilus links against libgvfs?
<ogra> i wonder if there is a way to rather get something more diectly from gvfs
<asac> for that we need to find someting else that crashes i guess
<Devils0411> That's what I found! / bin / uname-a
<Devils0411> ----------------------------------
<Devils0411> Eval command:! / bin / uname-a
<Devils0411> Linux nas_storage 2.6.20.21-4600 # 30 PREEMPT Fri Apr 10 12:06:05 CST 2009 i686 unknown
<Devils0411> but what exactly is OS?
<GrueMaster> Devils0411: It could be in-house.  Either way, it isn't arm based.
<ogra> asac, well, apt-cache rdepends gvfs gets quite a bunch of binaries that depend on it
<Devils0411> How to determine?
<asac> plars: do you see crashes in any of those?
<asac> evince
<asac> ekiga
<asac> guess you need to open something throw gvfs
<ogra> i guess deb-gview would be an easy candidate to test from cmdline
<plars> asac: will have to try remotely, as the nautilus issue keeps me from getting into X successfully
<ogra> seems a small thing
<asac> plars: cant you comment it out in gnome-session?
<plars> asac: then I just get a blank desktop, no gnome, just a cursor
<asac> so gnome-panel also dies?
<plars> evince works
<ogra> see the reverse deps :)
<plars> does not crash
<ogra> yeah, here too
<plars> installing ekiga
<ogra> i guess until you open something
<ogra> using a gvfs path
<asac> plars: did you open something from a gvfs location?
<asac> like ssh?
<asac> or just with gvfs path, yeah
<asac> not sure about the syntax though
<ogra> i wonder what gcalctool does with gvfs
<asac> plars: maybe using evince file:///path/to/file.pdf ... would trigger gvfs code paths
<ogra> it doesnt even have a file dialog
<asac> evince?
<asac> wow
<asac> o gcalctool
<ogra> no, gcalctool
<asac> yea. i think its clutter
<asac> -Wl,--as-needed
<asac> missing
<plars> evince still working fine, even with file:// path
<ogra> hmm, opening a file in evince complains a lot about gconfd not running
<asac> ogra: opening with file:// ?
<plars> ys
<ogra> yep
<asac> anyway.
<ogra> or with the file dialog
<asac> so i have to get the code ;)
<asac> the patch alone hasnt enough context
<ogra> brasero works fine as well
<ogra> i can add files etc
<ogra> so its likely the way nautilus uses gvfs
<ogra> oh
<ogra> and i can fire off nautilus --no-desktop through ssh
<ogra> so its nautilus in interaction with something that actually causes the crash
<GrueMaster> Are these problems the reason we don't have daily builds?
<ogra> no
<ogra> gnome uploads arent finished
<ogra> there are out of sync packages
<ogra> (the logs should tell)
<GrueMaster> Any eta?
<ogra> no idea
<ogra> its a development release :)
<ogra> people upload stuff
<ogra> GrueMaster, seems the breaking dove keeps imx51 from building, i manually triggered an imx51 build now
<asac_> plars: so you say just gvfscommon fixes it?
<GrueMaster> yea.
<plars> libgvfscommon0
<plars> downgrading by one level fixes
<asac_> hmm
<asac_> plars: all other gvfs packages are up to date? e.g. gvfs-backends?
<plars> asac: yes
<asac_> and have the same versoin as the crasjing common package i guess?
<plars> asac: yes, all of them at 1.5.2-0ubuntu1
<ogra> ok, all gstreamer bits (including totem) are gone from the ftbfs list
 * ogra wishes the page would be updated more frequently than once a day
<asac> right
<asac> ogra: do you know who owns that?
<asac> ogra: what was the url i had to use for the lucid kernel?
<ogra> asac, which one ? for qemu ?
<asac> ogra: http://paste.ubuntu.com/364787/
<ogra> oh, yeah, thats the jaunty one
<ogra> you try to build lucid, right ?
<ogra> http://bazaar.launchpad.net/~ogra/project-rootstock/trunk/revision/31
#ubuntu-arm 2010-01-29
<balders> Hello, is there any readily available cross compile toolchains for arm?
<balders> i.e. I would like to be able to type something like... apt-get install arm-linux-gcc on my host system and get a recent (4.2 or newer) toolchain
<cooloney> balders: oh, there is no such deb package for apt-get install,
<cooloney> balders: but you can download it from Code Sourcery website
<cooloney> balders: we use their cross toolchains to build kernel just for testing
<balders> ok, is the emdebain sources up to date or are they old?
<balders> deb http://www.emdebian.org/debian/ lenny main
<cooloney> balders: did not tried emdebian toolchain before.
<cooloney> balders: for fsl-imx51 and mvl-dove, we are using 4.4 gcc now
<balders> ok, what is fsl-imx51?
<cooloney> balders: freescale imx51 soc, fsl-imx51 is a branch of our lucid kernel tree
<balders> ahh ok
<cooloney> balders: mvl-dove is marvell dove, which is also a branch of our lucid kernel tree
<cooloney> balders: ok, good luck, has to leave for lunch
<balders> thanks for the tip
<balders> I will check out the code sourcery toolchain
<ogra> cooloney, https://launchpad.net/~lool/+archive/ppa/+packages .... there is a cross compiler
<Spyzer> hello
<Spyzer> hello, I am trying to load up precompiled gpe jffs image and the zimage kernel for arm versatile with the following command <qemu-system-arm -M versatilepb -kernel zImage -hda gpe-image-micro2440.jffs2 -append initrd="noinitrd"> and I get the error <VFS: Cannot open root device "<NULL>" or unkown-block(2,0)> I have no idea as to how am I supposed to boot the jffs image. Let me mention the fact that this gpe image has been compiled for ARM9 Micro2440 and 
<Spyzer> any help would be greatly appreciated
<Spyzer> ............................
<Spyzer> anyone please
<Spyzer> anyone please
<asac> ogra: bug 514215
<ubot4> Launchpad bug 514215 in mono "mono ftbfs with thumb2 on armel" [Critical,Triaged] https://launchpad.net/bugs/514215
<ogra> ah, good
<asac> lets hope i can install all b-d
<asac> on jocote
<ogra> why shouldnt you
<asac> you cannot remove packages ;)
<asac> so if there is a package that conflicts
<ogra> IS can
<asac> then #is is needed
<ogra> right
<asac> apt-get build-dep doesnt work either ;)
<ogra> oh ?
<ogra> i thought it did
<asac> no you have to manually do apt-get install ;)
<ogra> sudo apt-get install ... will now work inside the dchroots on the porter
<ogra> boxes, providing that nothing would be removed.
<ogra> from lamonts mail
<ogra> oh
<ogra> thats not build-dep indeed
<asac> yeah
<asac> just inconvenient ... but not blocking ;)
<ogra> yeah
<asac> ok lets see if that builds ;)
<asac> slow slow slow the boat
<asac> wonder if i really should have run debuild -S ... doesnt finish
<asac> hmm seems i am fighting with doko there ;)
<asac> ok aborted lintian ... thats just tooooo slow ;)
<ogra> heh
<ogra> fighting with doko is never good
<asac> he is building gcc ;)
<asac> i just want mono
<asac> most likely he is even using -j100
<ogra> unlikely, its an arm machine :)
<ogra> do a local build
<ogra> or is your babbage already packed
<asac> fighting with the rootfs from scratch
<asac> ;)
<ogra> oh
<ogra> whats wrong ?
<asac> somehow the kernel .deb didnt get installed :(
<asac> and initrd etc.
<ogra> no, thats deliberate
<asac> i used --kernel-image
<ogra> it gerenates a "rootfs" not a complete image (yet)
<ogra> ouch
<ogra> i should mark that as beagleboard only
<ogra> its from the beagle guys
<asac> so you cannot create a usable image ;)
<asac> nice
<ogra> for their kernel that doesnt use initramfs nor postinst
<ogra> it creates a rootfs
<ogra> nothing more
<asac> right. so one cannot create a working image ;)
<ogra> kernel and initrd is usually completely board specific
<asac> right. thats why i want to specify the .deb i want to run
<ogra> the tool was written for boards we dont suppport :)
<asac> yes, but installing an image is annoying. i want ubuntu-minimal
<asac> i dont have any big storage
<ogra> initially it wasnt inteded for boards for which we have images
<asac> so all space counts
<ogra> alternate ;)
<asac> also i want everything on the same sd
<asac> rootfs + bootfloppy
<ogra> right
<ogra> so use redboot-install for the bootfloppy part
<ogra> then cfdisk to create the second partition
<asac> well ;)
<asac> i have the partition and stuff
<ogra> then dump the rootfs onto the second partition
<asac> what i really neded was a kernel
<ogra> right, buut you need to do the kernel stuff first
<asac> can i chroot into the mounted rootfs?
<ogra> then create the rootfs partition
<ogra> sure
<asac> hmm
<asac> how?
<ogra> https://wiki.ubuntu.com/ARM/BabbageImageFromScratch
<ogra> note its outdated
<ogra> (i.e. kernel and initranfs need to come from elsewhere)
<ogra> and the config changes work better with redboot-cmdline now
<asac> do you have an up to date initram fs?
<asac> etc. at ~ogra?
<ogra> nope
<ogra> use your qemu chroot ;)
<asac> why cant i chroot in to the rootfs?
<asac> with qemu?
<asac> and then install the normal image?
<ogra> oh, indeed you should be able to even boot it from SD with qemu
<asac> ogra: how do i use that qemu chroot? i cannot chroot into it
<asac> i mean ... the rootfs
<ogra> huh ?
<asac> i cannot chroot into it
<asac> what command?
<ogra> mount your SD
<ogra> the just chroot into it
<asac> that doesnt work ;)
<asac> let me try again
<ogra> it should
<ogra> at least if you have qemu-arm-static installed
<ogra> binfmt should just switch the arch
<asac> ok me starts a new rootstock
<asac> lost my other rootfs
<asac> during reboot (/tmp)
<ogra> ouch
<ogra> qemu-arm-static makes no difference on SD or on local disk, it should always work to chroot into an arm root
<ogra> btw, you could test my new redboot build while you're at it :)
<asac> sure ;)
<ogra> http://people.canonical.com/~ogra/arm/redboot-imx51-babbage_200952-0ubuntu1_armel.deb
<asac> anyway. i have the feeling that all the docs should be consolidated ;)
<asac> its all spread apart ;)
<ogra> yes, they need updating
<asac> and nothing on its own is as useful as it could be
<ogra> no, its all in the /ARM namespace
<asac> i didnt find the babbageimagefromscratch one
<asac> but some other babbage thing ... which explained how to flash
<asac> right. i will clean it up after going through it while i still see the problems with the docs
<ogra> https://wiki.ubuntu.com/ARM/BabbageImageFromScratch?action=fullsearch&context=180&value=babbage&titlesearch=Titel
<asac> ogra: hwat is new?
<ogra> second hit if i search for babbage
<ogra> titlesearch
<asac> yes, but not if you search for rootfs ;)
<ogra> heh, indeed
 * ogra wonders where RootfsOnSDForBabbage comes from
<asac> hmm there is https://wiki.ubuntu.com/ARM/RootfsOnSDForBabbage
<asac> that wasnt there yesterday ;) ... at least for me
<ogra> last change 2009-07-20
<ogra> created by dyfet
<ogra> BuildingBabbageRedBoot eek
<ogra> that should vanish
<asac> so it doesnt say anything about the kernel again
<asac> RootfsOnSDForBabbage
<ogra> people should use the packaged binaries
<asac> e.g. again one part missing ;)
<ogra> i'll update BabbageImageFromScratch soon
<ogra> and drop all the old jaunty cruft
<asac> maybe ...
<ogra> its linked everywhere i post babbage instructions
<asac> i think what should really be done is that rootstock can produce images ... or we write a roothouse wrapper  that does that
<ogra> but was written for jaunty and updated for karmic
<asac> yes.
<ogra> right, but rootstock creating full images is rathera L+1 task
<ogra> for now i'm happy if i switch to a plugin system and get the basics from the spec done
<ogra> before lucid releases :)
<asac> i can write the UI if you dont have time ... that should be quick
<ogra> once thats there its easy to write a kernel plugin specific to the board you build for
<ogra> yeah, lets sit down at the sprint for the UI
<asac> right. pure C ;)
<asac> lol
<ogra> the changes i planned below UI are more elementar
<ogra> so these need to be in place first
<ogra> we have a wonderful plugin system developed for ltsp-build-client which essentially does the same as rootstock
<ogra> i want to port rootstock to this
<asac> some build systems just dont get it
<ogra> the plugin system in ltsp enabled it to be distro agnostic
<asac> mono always reconfigures on debuild -nc
<asac> after a build failure
<ogra> yeah
<ogra> mono is evil
<ogra> i maintained back in breezy and hoary
<asac> thats a packaging bug
<ogra> and was really happy to get rid of it
<asac> config.status should be honoured
<ogra> after that the packaging was completely taken over by debian
<asac> yeah
<ogra> and they completely redidi everything
<ogra> i would have expected it to improve
<ogra> but somehow that didnt happen
<asac> as long as we can sync ;)
<ogra> as long as it doesnt ftbfs :)
<asac> haha .. yeah. but this is thumb2 ;)
<ogra> hmm, for creating an initramfs inside a chroot for babbage we need to hack flash-kernel
<ogra> or divert it to /bin/true
 * ogra tries
<asac> argh
<ogra> ?
<asac> so after reboot qemu is broken again
<asac> ;)
<asac> chroot: cannot run command `debootstrap/debootstrap': Exec format error
<ogra> run the binfmt initscript
<ogra> and try again
<asac> seems all this doesnt like different kernels
<asac> ok
<ogra> i never had probs
<ogra> and in karmic i even switched between -generic and -pae all the time
<asac> umount: /proc/sys/fs/binfmt_misc: not mounted
<asac> update-binfmts: warning: Couldn't unmount the binfmt_misc filesystem from
<asac> /proc/sys/fs/binfmt_misc.
<asac> i think i didnt even switch kernel
<ogra> weird
<asac> so guess its not related
<ogra> smells buggy
<asac> now binfmt is mounted at least
 * asac runs again
<ogra> we need to talk to cjwatson at the sprint about that
<ogra> and take a deep look at your system
<asac> if it works everywhere but here, i wont bother too much. probably has something to do with the upstream/init stuff
<asac> upstart
<ogra> well, do you run a different upstart than i ?
<asac> not that i know ;)
<asac> i try to keep my fingers off from that
<ogra> heh
<ogra> well, then it should cause this
<ogra> i could imagine a mountall bug or something
<ogra> that still seems shaky
<asac> hmm. yeah
<asac> but i don really mount much
<ogra> but umount: /proc/sys/fs/binfmt_misc: not mounted somehow indictaes that something went wrong with mounting the binfmt handler fs
<ogra> update-initramfs: Generating /boot/initrd.img-2.6.31-603-imx51
<ogra> /bin/grep: /proc/cpuinfo: No such file or directory
<ogra> mumble
<ogra> asac, http://paste.ubuntu.com/365144/
<ogra> surely not complete but the initrd creation works
<asac> nice
<ogra> and indeed you cant just use the chroot right away, there are a good bunch of config files missing and no user is created etc ... all the stuff rootstock does
<asac> well. i want to use the rootstock fs
<asac> not a manual chroot
<asac> lets see ;)
<ogra> but thate above could easily become a rootstock plugin later :)
<asac> right
<ogra> the prob is that redboot-install needs to repartition the SD
<asac> ok unpacking the rootfs on sd
<ogra> but to run it you need the initrd in advance
<asac> hmm
<ogra> so keep the tgz :)
<asac> yeah
<asac> lets see what happens ;)
<ogra> run the above in the chrooted SD
<ogra> or better tar the chrooted Sd up after running the above steps
<ogra> then run redboot-install, create a new rootfs partition and untar it again
<asac> so redboot-install will wipe all partitions?
<ogra> yes
<asac> ok
<ogra> it needs to create a new MBR
<asac> even if its mounted?
<ogra> and a raw partiton
<ogra> no idea, i guess parted will complain anyway
<asac> will see
<ogra> its a bunch of parted and dd calls
<ogra> and fis
<asac> so i rather should unpack the tgz on a host filesytem
<asac> hmm
<ogra> i should probably add a check that if the first parted call fails it exitst if it doesnt do that already
<asac> nevermind ;)
<ogra> i havent looked at redboot-tools for quite a while
<ogra> but i'll do that during the sprint
<asac> ok mono build continued long enough
<asac> creating diff
<asac> and checking if there are any logical bugs ;)
<ogra> i plan to mostly do redboot, rootstock and powermanagement
<ogra> and at least one build of the uboot git tree to check it
<asac> ack
<asac> nah. lets do uboot after a3
<ogra> well, if its good enough i'D like to upgrade the poackage in the archive to the latest at least
<asac> you can do that after a3 ;)
<asac> plenty of time
<ogra> to have a proper base in case we will need/use it later
<ogra> yes, indeed
<asac> lets try to make release team happy by getting the still important specs done as good as possible
<ogra> uboot doesnt need to be sprint stuff ... but i'd like to check it before release
<asac> and then do more after a3 without a blueprint ;)
<ogra> right
<asac> sure ... do that after a3 .. or even after beta1 .. depending how up-to-date we are
<ogra> right
<asac> argh
<asac> the mono package sucks
<asac> dpkg-source: error:   old version is plain file
<asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/config.guess:
<ogra> heh
<asac> dpkg-source: error:   new version is symlink to /usr/share/automake-1.11/config.guess
<asac> dpkg-source: error:   old version is plain file
<asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/config.sub:
<asac> dpkg-source: error:   new version is symlink to /usr/share/automake-1.11/config.sub
<ogra> fun
<asac> dpkg-source: error:   old version is plain file
<asac> dpkg-source: error: cannot represent change to mono-2.4.3+dfsg/libgc/install-sh:
<asac> trying to produce sources of a half build tree
<asac> so i can get the diff out of the debdiff
<asac> annoying
<ogra> yeah
<asac> cani tell debuild -S to ignore that?
<ogra> i dont think so
<asac> if it was quilt i would have everything done by now :(
<ogra> depends on the packaging system i guess ... there is that cdbs-autotools crap that re-copies these files from the system ... i think that also adds such a check
<asac> they dont use -c for autotools
<asac> so it creates symlinks ;)
<ogra> but it seems to use dh and autoconf, automake directly
<asac> obviously ;)
<ogra> should be possible to edit rules
<asac> well ... non of my business ;)
<asac> just want to get the diff :-P
<ogra> unless there is a debhelper module
<asac> you need to ask the dh7 fanatics ;)
<ogra> well, dont make a debdiff, just make a diff :)
<lool> ogra: I didn't break qemu-arm-static; it worked for me yesterday evening
<ogra> and then ping directhex
<ogra> lool, i was kidding :)
<lool> I didn't do any repackaging recently; only FTBFS fixes
<ogra> i know you didnt break it
<ogra> we all do :)
<ogra> lool, asac's machine soemhow doesnt properly set up binfmt on boot ... no issue with qemu-arm-static at all here
<asac> yeah. we moved that in the "mountall" busted corner for now
<ogra> heh
<asac> hell. i feel like filing a serious bug against mono ;)
<asac> more and more autotools symlinks left over after clean
<asac> debian bug 528090
<ubot4> Debian bug 528090 in mono-gac "mono-gac/mono-runtime: mini circular dependency hell" [Important,Fixed] http://bugs.debian.org/528090
<asac> lol
<ogra> hahaha
<asac> bug 539807
<asac> debian bug 539807
<ubot4> Debian bug 539807 in mono "needlessly executable stack" [Normal,Open] http://bugs.debian.org/539807
<asac> and we have that in main?
<asac> o reported by kees ;)
<ogra> even on the CD
<asac> ogra: http://people.canonical.com/~pitti/workitems/canonical-mobile-lucid-alpha-3.html ... seems the status shows up there
<asac> "blocked on uboot bugs."
<ogra> sweet
<asac> maybe i should maintain the status for the specs properly
<ogra> and we're below trend
<asac> ogra: hmm. i dont think that foreign can be discarded
<ogra> but i still have three todo's on the list
<ogra> for that spec
<ogra> the two bugs and the MIR
<asac> also ... we are posponing all the time ;)
<asac> i am not sure what to do for the bugs
<asac> let me check
<ogra> we need to somehow postpone these three too
<ogra> i think its because they are duplicated under "Work items lucid-alpha-3"
<ogra> delete that section and we should be fine
<ogra> ah, no, the bugs need to be unmilestoned
<ogra> and the INPROGRESS item needs to become POSTPONED
<ogra> then they should be gone
<asac> ok another batch of symlinks removed from mono :(
<asac> guess it would have been faster to copy the .h files i changed
<asac> ogra: i set to wont fix and milestone later for the main task now
<asac> lets see
<ogra> if that works
 * ogra tries to find his ESTA number for his travel notes
<ogra> asac, i'll be at the vet. from 16:15 on, i might be to late for the release meeting (though trying to make it and indeed we're usually up at 17:30 anyway)
<asac> JamieBennett: maybe here
<asac> ogra: thx for heads up. i will survive without you i guess ;)
<ogra> yeah, i guess i'm there anyway, but you never know
<asac> ogra: btw, NCommander said that dove X0 doesnt fix things :(
<ogra> hmm, ericm_ said something different
<asac> when?
<ogra> when he tested at marvell directly
<ogra> he was over there working with a marvell engineer
<asac> right. but the news from yesterday came through NCommander but he said that that was new findings from ericm_
<ogra> bah
<asac> anyway. dont panic ;)
<JamieBennett> I'm here
<ogra> i never panic
<ogra> people just accuse me to
<lool> asac, ogra: I think you guys asked for devtmpfs to be backported; could you tell me who told you that was the only way?  I'm interested in the rationale because I hit this too and I've filed a bug about this, but couldn't find yours
<lool> Also which kernel is this and why isn't it .32?
<asac> lool: for fsl we go for .31
<asac> thats where the backporting effort stems from
<asac> persia: did a website with the items
<asac> guess we didnt open bugs
<lool> asac: What was the rationale for the backport?
<lool> That it didn't boot with mountall/upstart
<lool> ?
<asac> lool: ogra requested it iirc
<asac> let me see if i can find the wiki
<ogra> lool, it did boot, it just boots 2 sec slower if the udev scripts are used instead of devtmpfs and initramfs's init spits out an error on boot
<ogra> lool, Bug 512321
<ubot4> Launchpad bug 512321 in linux-mvl-dove "please backport devtmpfs to the lucid linux-imx51 kernel tree" [Undecided,Fix committed] https://launchpad.net/bugs/512321
<lool> Oh you're using an initramfs too
<lool> That's why it booted
<lool> Ah!  mknod /dev/console and /dev/null; exactly the problem I was hitting
<lool> I'm pretty sure not having the devtmpfs slows down by much more than 2 seconds
<lool> MAKEDEV on so many devices takes two seconds on my x86-64 laptop!!
<ogra> well, 2sec was what i could measure on the babbage using a stopwatch
<lool> In qemu, it's more in the 20 seconds
<ogra> phew
<ogra> was that your issue with the in-archive versatile kernel ?
<ogra> i.e. does it fix it ?
<ogra> we should just enable it in versatile by default
<ogra> since thats .32 there shouldnt be an issue
<lool> I don't know what prevents the in-archive versatile kernel from booting; the biggest issue I have is that it lacks video output
<lool> The config for that is pl110 IIRC
<ogra> well, i still havent tried it and i doubt i'll get to it today, but i'm planning a lot of rootstock work during the sprint so we'll get it sorted there
<lool> pl110
 * asac wonders if its worth adding a configure test for gcc intrinsics to mono ... or just use ith if __thumb__
<asac> #ifdef __thumb__
<asac> what arm/thumb asm reference is good?
<asac> bug 511197
<ubot4> Launchpad bug 511197 in busybox "fails to build on arm lucid (thumb2)" [Undecided,Fix released] https://launchpad.net/bugs/511197
<dmart> asac: Take a look at https://wiki.ubuntu.com/ARM/Thumb2PortingHowto - I'm still writing it, so any comments on whether this is any use / what else we need are welcome.
<asac> dmart: too bad you havent written the swp instructions yet ;)
<asac> could have checked if i did it right
<asac> dmart: do you thin its worth hacking configure to check for gcc atomic builtins?
<asac> or just __thumb__ ?
<dmart> You might be able to pull the atomic builtin check out of glib2.0
<asac> hmm. yeah
<asac> patching configure is always annoying ;)
<asac> packaing wise ... but ok
<asac> bug 456659
<ubot4> Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,Confirmed] https://launchpad.net/bugs/456659
<ogra> fixed
<ogra> why is that confirmed ... hrm
<ogra> oh, the bot reads the karmic info
<dmart> asac: the main issue is people using tools which may not have the atomic builtins support (Debian possibly, and other 3rd parties).  I think pretty much everyone is on a new enough kernel these days (2.6.16?)
<asac> plars: do you have the nautilus crasher at hand?
<asac> the bug id ;)
<asac> chromiums awesome bar is not that great i have to say
<ogra>  Bug 512959
<ubot4> Launchpad bug 512959 in gvfs "nautilus assert failure: *** stack smashing detected ***: nautilus terminated" [High,Confirmed] https://launchpad.net/bugs/512959
<ogra> asac, did your imx SD experiment work ?
<asac> yeah
<asac> did i say yeah
<asac> not to that
<asac> i didnt finish that yet :)
<ogra> ah
<ogra> i noticed the yeah came to fast to refer to that :)
<plars> asac: do you want me to go through and target all of those "port to thumb2" bugs?
<plars> asac: milestone them rather?
<ogra> hrm, my lÃ¶aptop doesnt see its LCD panel anymore
<asac> plars: good question
<ogra> only the external monitor
 * ogra wonders if he should travel with his 24" screen now
<asac> plars: i think so ...
<asac> plars: i think we can mark the mono bug as a dupe
<plars> asac: are you talking about bug 514215 and bug 513736 ?
<ubot4> Launchpad bug 514215 in mono "mono ftbfs with thumb2 on armel" [Critical,Triaged] https://launchpad.net/bugs/514215
<ubot4> Launchpad bug 513736 in mono "[arm] needs porting to thumb2" [Undecided,New] https://launchpad.net/bugs/513736
<asac> plars: yeah
<asac> i documented 514215 in the upload i was preparing
<asac> but i can use the other
<asac> though the other is now on release page
<plars> asac: ok, I'll milestone them all for A3 for now, we can push later if we need to but these might be a good thing to assign out to people and try to hammer them out next week
<plars> asac: np, I'll make 514215 the master and dup the other one to it
<asac> thx
<plars> asac: bug 514252
<ubot4> Launchpad bug 514252 in qemu-kvm "[arm] (might) need porting to thumb2" [High,Triaged] https://launchpad.net/bugs/514252
<plars> asac: qemu-kvm? why are we even trying to build that on armel?
<ogra> plars, lool would like to sse it working and at some point when armel HW is powerful enough it might help with apps that cant be ported
<ogra> *see
<ogra> i.e. wine
<plars> ogra: interesting, so we expect to maybe have kvm support on arm someday? that would be cool
<asac> hmm. not sure
<asac> just made the bugs from the review list
<asac> feel free to move that to medium or something
<ogra> i would have taken it off armel long ago but technically there is no actual reason to do so, lool is right here
<asac> if its currently not runnig at all
<asac> or even low
<ogra> plars, there are roumors about kvm being ported to armel but i have never actually seen any work on it
<ogra> for a start it would have to build even without kvm
<ogra> asac, plars, low feel appropriate
<ogra> *feels
 * ogra tries to get used to his laptop kbd again
<ogra> havent used that for a while
<dmart> plars: Hi - SHouldn't we be cautious about marking the new Thumb-2 porting bugs as duplicates of existing bugs?  The new porting bugs are more general; I'm wondering if there's a risk if addressing only the more specific issues in the pre-existing bug and forgetting about the rest.
<dmart> The new porting bugs are not just about ftbfs; there are also some "may build but might not work properly" and some future proofing issues.
<plars> dmart: I copied over the information from the old bug to make sure that not only the ftbfs was addressed, but also the more general porting issues.
<plars> dmart: asac mentioned to me that he thought it was good to combine the two, perhaps it warrants further discussion though
<dmart> Oh, OK - that's fine.  I hadn't read everything yet, just saw the mails coming in.
<plars> dmart: yeah, sorry for the spamfest :)
<dmart> Yes, I think combining them is sensible
<dmart> No problem about the spam, I started this off anyway :)
<ogra> in cases where ftbfs can only be fixed to full porting work i guess it ok to merg such bugs
<ogra> s/to/through/
<dmart> Anyone interested, please take a look at https://wiki.ubuntu.com/ARM/Thumb2PortingHowto and see whether it looks likely to be useful and understandable, whether it looks like there's anything missing (bearing in mind I'm still writing...)
<dmart> We can link this from the porting bugs (though I don't mind doing that later)
<asac_> err
<asac_> ogra: http://paste.ubuntu.com/365282/ :/
<lool> asac, ogra: Note that qemu-kvm is not only about kvm but also about qemu, and qemu builds on all arches in Debian
<asac> lool: yes. what we found was arm code that wouldnt be thumb safe ... thats all. if you know thats used/not used, fix/invalidate the bug etc.
<asac> also unassign etc. ... whatever you think is ok ;)
<lool> asac: Well I think it's a real bug that our Ubuntu qemu doesn't build on an official arch (armel) when it does in Debian; it didn't build in karmic either though
<asac> lool: anything we can do there?
<asac> remember that there was kind of a tie
<asac> with server team wanting something that breaks us
<lool> I don't remember that
<lool> I know we're not using the exact same upstream as Debian (qemu-kvm !- qemu)
<lool> s/!-/!=
<asac> yeah
<asac> and that was done by server team, right?
<lool> Yes
<asac> so thats what i remember ;)
<asac> why didnt they add a second source package?
<lool> Well my point stands: this program should build on armel, even if it's a slightly different branch
<asac> hmm. they did it seems
<lool> qemu-kvm pulls fomr qemu regularly
<asac> ;)
<asac> yeah
<asac> agreed
<asac> so we have it on ftbfs list?
 * asac checks
<lool> Yes
<asac> ok its not armel only
<asac> thats probably why noone started on that
<lool> I'm just explaining why it deserves to be tracked: it's a real bug and regression over Debian caused by the Ubuntu changes
<lool> The issues are wildly different depending on the arch
<asac> ok the build failure we have atm is atomics
<asac> so covered by the thumb2 bug
<lool> I looked at all Ubuntu arches in karmic and fixed the first issue of each arch, but there was at least one more issue on each arch after each fix
 * asac checks what broke karmic
<lool> And each fix I applied was different
<lool> The current failure is earlier than the karmic one, so it's *another* regression on top of the karmic one, introduced by T2
<asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:289: error: conflicting types for 'elf_greg_t'
<asac> /usr/include/sys/procfs.h:39: note: previous declaration of 'elf_greg_t' was here
<asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:295: error: conflicting types for 'elf_gregset_t'
<asac> /usr/include/sys/procfs.h:46: note: previous declaration of 'elf_gregset_t' was here
<asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1782: error: redefinition of 'struct elf_siginfo'
<asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1788: error: redefinition of 'struct elf_prstatus'
<asac> /build/buildd/qemu-kvm-0.11.0/linux-user/elfload.c:1807: error: redefinition of 'struct elf_prpsinfo'
<asac> yeah
<asac> is linux-user a copy of some other package/source ?
<asac> hmm
<lool> linux-user is the qemu mode used in qemu-arm-static
<lool> It's the syscall emulation mode
<lool> It's copied during the build for all targets
#ubuntu-arm 2010-01-31
<who_> Is there anyone that can talk to me briefly about cross compiling on 9.10(x86) for 9.10(arm)?
<who_> Specifically, I want to know if there's an established toolchain/way to setup the codesourcery toolchain.
<lool> who_: The codesourcery toolchain can be used as usual
<who_> lool: as usual doesn't mean a huge amount to me ;) it's not something I 'usually' do.
<lool> who_: What's your overall goal?
<who_> I have an IGEP2 board (like a beagle). I have made myself a 9.10 rootfs, and I want to be able to compile some apps not in the repositories for it
<lool> I would recommend you do native builds then
<who_> I don't want to have to compile on the hardware and I because of the 256mb mem requirment on qemu (as far as I can see) - it's pretty slow
<lool> I wrote some patches to qemu to be able to use more than 512m
<lool> It's usually enough
<lool> Another route you might follow is using qemu syscall emulation to build under x86; this is very fast, much faster than qemu machine emulation
<lool> In this latter case, you can have as much as your host, but probably limited to 4GB; didn't try it out
<who_> lool: that sounds more like what I'm looking for
<who_> lool: so I could, for example, point it at my rootfs and get it to link against that?
<who_> lool: the packages in the repositories: how are they built?
<lool> We build natively, on real hardware
<who_> lool: out of interest, do the qemu patches need to be applied to qemu and to the kernel I want to use with qemu? and are they in some rcs somewhere?
<lool> who_: You could point at your rootfs and link against that
<who_> lool: sounds excellent.
<lool> If you want to use the patches, these are for machine emulation; they target the realview and versatile boards
<lool> We actually some of the versatile ones to our Ubuntu versatile kernel
<lool> But I didn't get that kernel to work yet
<lool> We actually *applied
<lool> But you don't need any patch for syscall emulation
<who_> lool: okay, I guess I'll try that route first
<lool> The only thing to keep in mind is that it's a very unperfect emulation; stuff might or might not run and your software might detect host features which your target doesn't have
<lool> But when it works it's the best option
<who_> lool: any reason you suggest that over codesourcery?
<who_> or, in fact, some other cross compilation system?
<lool> If you're using karmic, just install the qemu-arm-static package, and copy /usr/bin/qemu-arm-static to your rootfs' /usr/bin, and you're done
<lool> Cross compilation is harder to get to work with Debian/Ubuntu packages
<who_> lool: at first, I will probably be just compiling new code I'm writing or things I'm porting...
<lool> It creates many issues of its own which you wont get without xcompilation, and the output is not identical to native compilation
<lool> basically, cross-compilation adds a layer of complexity and uncertainty and degrades output slightly
<who_> lool: thanks. that makes sense.
<who_> so what _is_ qemu-arm-static?
<lool> A package shipping a static binary of qemu-arm, that's the syscall emulation one
<who_> sorry, I mean, /usr/bin/qemu-arm-static - what is in that file an for what purpose do I need it on my rootfs? I assume it only needs to be there for when I'm running on the x86 machine, not that any applications compiled using syscall emulation actually require it to be there?
<who_> lool: also - can you tell me anything about this supposed xcompile toolchain? http://alone-in-the-light.zenvoid.org/2009/11/cross-toolchain-for-arm-ubuntu-910.html
<lool> who_: It only needs to be there while you're using the rootfs on your x86 host; it's needed for binfmt
<lool> who_: First time I see that link, no idea what's in there
<who_> lool: okie :) I'll have a bit of an explore myself. I'm in that stage where I don't yet quite know enough to assess these things/avoid naive mistakes :S. I'm sure I'll get there
<lool> Try the simple instructions I mentionned earlier, it should get you started immediately
<who_> lool: you're referring to the instructions about copying qemu-arm-static to the rootfs and using qemu syscall emulation? That's what I think I'll try first.
<lool> Yes
<who_> thanks very much for your help :)
<who_> some questions in passing. Are there arm builds for ppas?
<who_> and what hardware do you use for the compilation of the entire repositories!?
<lool> who_: We don't have public armel PPAs; I'm not 100% sure about current hardware, but I think only Freescale i.MX51 based boards are in use ATM
<who_> lool: so I assume then most people using ubuntu-arm 'in anger' are compiling natively and/or using only things int he repositories? One thing I'd like to try on by board but don't really want to have to compile is Chrome (the browser) - know if there are any packages around? google doesn't seem to have helped me.
<lool> who_: https://launchpad.net/ubuntu/+source/chromium
<lool> ISTR it requires NEON though
<who_> that one's a game not a browser "Chromium is a top down fast paced high action scrolling space shooter which uses the SDL libs."
<who_> https://launchpad.net/ubuntu/+source/chromium-browser seems to be built for Lucid though...
<who_> when I get to my desk tomorrow I'll see if it depends on things I don't have...
<lool> who_: Oh sorry
<lool> who_: https://launchpad.net/ubuntu/+source/chromium-browser
<lool> who_: But you can see it's built for x86, x86-64 and ARM
<who_> yea, I found that (see above), hopefully the lucid package will work on Karmic without too much trouble :S?
<who_> lool: otoh, it's not that important - just an experiment really.
<armin76> hahaha
<armin76> lool: so a game, uh? :D
<pdxspork> Hey, I have a couple questions if anyone is around and wants to humor me
<pdxspork> I have a beagle board that I have used rootstock to build a 9.10 image for. Most stuff works pretty well but I need access to GPIOs and UART2 on the expansion connector, the later requiring changing the way the OMAP has the pins muxed. What is the best way to change the pin muxing?
<pdxspork> It looks like my options are to recompile either uboot or the kernel, however it does not seem that the process for building an ARM kernel on my x86 machine is going to be too much fun.
<pdxspork> Secondly, I get a "Permission denied" error when attempting to access the GPIOs (user LEDs to be specific) on the OMAP. Even as root. Is this a kernel issue or am I just doing something wrong?
<lool> pdxspork: You could build the kernel natively; it might be painful once, but if you use ccache the next builds should be ok
<lool> pdxspork: Otherwise, you could build within a qemu-syscall chroot or cross-compile
<pdxspork> lool: Yeah, I'm looking towards using a cross-compile
<pdxspork> I have a lot of x86 horsepower, no reason to wait an eon for the beagle to compile it when I've got a dual xeon box sitting here
<lool> pdxspork: Cross-building the kernel is probably easiest then; just add it to you path and pass CROSS_COMPILE=your-compiler-binaries-prefix- to the build
<lool> e.g. CROSS_COMPILE=arm-linux-gnueabi-
#ubuntu-arm 2011-01-24
<Samae> Does it allow me to tweak the kernel conf ?
<topfs2> you pick a kernel deb you want to base it on, so if you need to tweak the kernel you need to compile it and package it
<Samae> ok
<Samae> and then it outputs a rootfs
<ka6sox-away> topfs2, because its a uimage you can't just use make-kpkg kernel_image
<ka6sox-away> ?
<Samae> Well, I don't use uimage for now, or I'm not aware i'm using it
<Samae> I just discovered that my tablet boots always on a rootfs.img, so i substituted the armel image or ubuntu 10.10 and it ran ok (appart for usb and touchscreen support)
<ka6sox-away> Samae, which tablet?
<Samae> up there ^
<Samae> Archos 101 it
<ka6sox-away> ah, archos.
<ka6sox-away> okahy
<Samae> Ow, I meant I don't use uboot
<Samae> but yeah it boots on zImage or uImage apparently
<Samae> so next step, new rootfs and new kernel with proper modules
<Samae> :)
<Samae> I'll be back
<Samae> gudnite
<rsalveti> ogra: the binary is the same name, but different path
<rsalveti> ogra: the new package for omap3 is x-loader-omap3-beagle
<rsalveti> as we're generating images compatible with beagle by default
<rsalveti> ogra: /usr/lib/x-loader/omap3530beagle/MLO
<cooloney> rsalveti: still around. can you boot up latest 2.6.38-rc2 on panda?
<lilstevie> ok got a different situation here, the board that i am building a rootfs image for only has 320mb for its rootfs, does ubuntu arm support me splitting in to /usr /home /var / et al
<hrw> lilstevie: generate tarball with rootfs and then split it manually into parts
<ka6sox> hrw, does the maverick image use a initramfs?
<hrw> yes, it does
<ka6sox-away> hmmm..okay. I might have to do some playing then to get it to work.
<ka6sox-away> hopefully it uses udev
<lilstevie> hrw: then just make sure the other parts are mounted in the initramfs right?
<hrw> probably
<hrw> I use only / /home + /tmp in tmpfs on most of my machines
<lilstevie> heh problem i have is that i only have 320mb in the available space for /
<lilstevie> and the rest is split on SD cards
<lilstevie> internal 16gb of which i can only flash 1.5GB of ext
<ogra> i doubt loading off /var will gain you enough, you should offload /usr instead
<ogra> as long as you use an initrd adding a line to fstab should be enough, no extra fiddling needed
<lilstevie> ogra: but will that still give me enough space to be able to install stuff
<ogra> well, thats a trial and r thing i guess
<ogra> *error
<ogra> of my installed 4G big system /usr eats 1.9G while /var occupies 350M
<ogra> so sharing out /usr will definitely gain you more
<hrw> 6.3GB /usr 8/2GB /var on my desktop
<hrw> 6.3GB /usr 8.2GB /var on my desktop
<ogra> hrw, apt-get clean ;)
<hrw> ogra: 4GB is pbuilder
<ogra> loading off /var surely gains you a lot too in the running system later
<ogra> (logs, caches etc)
<hrw> but yes, 800MB was apt cache
<ogra> but for initial install if you are short on space /usr should be the first
<ogra> and /tmp in tmpfs is something you should only do with a decent amount of ram
<ogra> at least if you want to run apps like firefox
<ogra> i wouldnt do that on 128M if you want to run any desktop bits
<ogra> (for example)
<lilstevie> I have 512mb ram usable
<lilstevie> the SoIC has more ram but i dont know how to access it
<lilstevie> and this is for arm :p does firefox have an arm port :p
<hrw> port?
<hrw> firefox nowadays just need to be compiled
<lilstevie> heh fair enough
<hrw> I remember days when anything mozilla based required strange patches to get it running
<lilstevie> still trying to grasp how much will run on arm
<hrw> lilstevie: 512MB ram? most will run
<lilstevie> generally what is the best x manager to run in a touch environment
<LetoThe2nd> running firefox on arm is absolutely no problem. compiling locally still is a bit of a strain, though.
<hrw> lilstevie: which arm cpu you have?
<ogra> LetoThe2nd, depends on your hardware ;)
<lilstevie> hrw: yeah it has 512mb ram, and some other ram that is really not known if it is usable
<lilstevie> hrw: hummingbird
<hrw> nice cpu
<lilstevie> yeah :)
<ogra> lilstevie, i use an ac100 here atm, should all work fine
<lilstevie> just hoping to free it from android hell :p
<LetoThe2nd> ogra: adequte relation to HW given, of course. running ff on a pentium133 is also rather pointless.
<hrw> lilstevie: so galaxy s/tab/nexuss?
<lilstevie> for a tablet like device is not nice
<lilstevie> tab
<lilstevie> and i wasnt dumb enough to upgrade to one of the dev releases that has locked bootloaders so it just happily runs unsigned kernel/initramfs combos
<lilstevie> has to be the most open device i have ever had lol
<LetoThe2nd> ogra: on an openrd here ff worked quite good. :-)
<hrw> bb in ~15minutes
<hrw> heh.. someone remind about someone before leaving...
 * hrw uses hummingbird to play youtube videos now.
<lilstevie> lol
<hrw> but on nexus s/android
<lilstevie> the tab is nice hardware
<hrw> lilstevie: tab has 1024x600?
<lilstevie> yep
<hrw> 16GB storage, 512MB ram, netboot resolution... looks like good target for ubuntu
<lilstevie> yeah thats what i though
<hrw> but I do not know would I switch
<lilstevie> only thing I am going to struggle with is the initramfs
<ogra> make sure you have your kernel and modules properly installed in the rootfs
<ogra> then just run update-initramfs -c -v<version of your kernel>
<hrw> lilstevie: on arm devices I just avoid initramfs and boot directly into rootfs
<lilstevie> hrw: that is a tad difficult on the tab
<lilstevie> as the kernel gets the initramfs compiled in
<hrw> as hw is always same, rootfs is same device etc
<ogra> you lose some functionality without initrd
<ogra> (filesystem check, encrypted filesystems etc)
<lilstevie> ogra: update-initramfs from inside qemu or just in the rootfs
<ogra> either will work, it creates a /boot/initrd.img-<version>
<sebjan> ll /mnt/`
<sebjan> oups :)
<lilstevie> SGX535 has full accel on ubuntu yes?
<hrw> ogra: since when fsck needs initramfs?
<hrw> ogra: fsck needs rootfs/ro
<ogra> it happens before / is mounted rw
<hrw> ogra: and for this initramfs is not required
<ogra> well, i dont have fsck on systems where i dont use initrd
<hrw> ogra: maybe thats because ubuntu forces initramfs to be used to fsck
<ogra> might be, i never checked ... since we use initrd by default on all official images anyway
<sveinse> ogra: How can I submit patches to rootstock?
<ogra> sveinse, create your own branch on LP and file merge requests
<hrw> speaking of merging....
<lilstevie> ogra: does the kernel need to be in the rootfs
<hrw> flash-kernel?
<ogra> lilstevie, the modules do
<ogra> i'm not sure update-initramfs checks for a vmlinuz file
<ogra> worst case you can just touch it though
<lilstevie> ok good cause my kernel isnt compiled until after i have the initramfs :p
<ogra> hrw, yeah yeah ... did drop off my TODO, there are just other more pressing things atm
<ogra> *didnt (indeed)
<sveinse> I saw some comments above regarding initrd: What specifically is done in initrd? Because my (rootfs based) system does not use initrd at all, but it seems to work as intended
<sveinse> ...I meant roostock based system
<ogra> sveinse, make sure your users never ever install any filesystem encryption bits, raid or device manager ... all these need initrd
<ogra> beyond that initrd indeed draws the splash and runs plymouth (whithout which fsck will not work since mountall uses libplymouth for communication)
<lilstevie> so ogra let me get this right, best way to do it will be set up fstab, move modules in to place chroot to the rootfs then run update-initramfs
<sveinse> ogra, ok thanks. Quite frankly it good to be without (except for fsck). I have a strict customer requirement of short bootup time.
<sveinse> I see the PID counter is what around 3000, so it does alot at boot even without initrd
<dmart> hi all ... does anyone know how to get verbose log output during bootup, preferably over serial?  I don't really know to to achieve this with upstart+plymouth
<lool> dmart: remove quiet from cmdline and add nosplash?
<lool> might not be enough though
<ogra> no need for nosplash on serial though
<ogra> dropping quiet should be enough (and indeed the right console= args)
<lool> dmart: For serial, it's a matter of listing your serial console last if you want it to be the system console IIRC
<lool> That is, console=ttyS2, console=tty0 will output some kernel messages on both, but /dev/console will only go to last arg, or something like that
<ogra> just make it the only console
<ogra> no need for tty0 if you want serial boot output
<lilstevie> egh is there anthing that stops 32bit linux binaries executing on 10.10 64bit?
<lilstevie> for some reason it keeps telling me file not found for the executable when it is clearly there
<lool> lilstevie: What's the exact message?
<lilstevie> No Such File or Directory
<lilstevie> it clearly exists
<lool> lilstevie: The full message
<lool> lilstevie: Usually, it's missing ld-linux for 32-bits; it's in a separate package
<lool> lilstevie: You want to install libc6-i386
<lool> lilstevie: You can strace your binary to see which actual file is missing
<lilstevie> /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-gcc: no such file or directoy
<lilstevie> directory*
<lool> lilstevie: Ok; that sounds like missing 32-bits ld-linux; run strace -etrace=file /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-gcc
<lilstevie> http://pastie.org/1492398
<dmart> lool: I don't think we're using quiet or splash... this is just a BSP bringup problem.
<lilstevie> lool: installing libc6-i386 fixed :)
<lilstevie> hm, ogra i get an error off that initramfs telling me it is the wrong datatype
<lilstevie> cause it is aparently not cpio
<ogra> its gzipped cpio
<sveinse> Hmm. It seems getting rootstock to use more than "maverick" (e.g. maverick-updates and maverick-security) isn't as trivial as I hoped it would be. It seems debootstrap doesn't do a full "apt-get" resolution of the latest package. It seems to be locked against maverick/main. Objections?
<lilstevie> yeah i figured it out
<lilstevie> i ended up checking it with file
<lilstevie> discovered that it was gzip
<lilstevie> was a bit of a facepalm moment :/
<sveinse> So perhaps it's better to rootstock/debootstrap and then do a apt-get upgrade after installation to get the maverick-security and/or maverick-updates
<ogra> or properly patch rootstock to generate a proper sources.list
<ogra> i.e. by installing and using python-apt
<sveinse> ogra, I've added a --sources option to rootstock where you can provide your own sources.list
<sveinse> However, debootstrap internals doesn't consider anything else than maverick/main
<ogra> sveinse, you could prot rootstock to multistrap ;)
<dcordes> hi
<dcordes> In http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20110123/natty-preinstalled-netbook-armel+omap4.img.gz I get 'No valid session found' after gdm startup. Is it a known problem ?
<dcordes> /etc/gdm/custom.conf has une-efl
<rsalveti> dcordes: yup,algo got this with today's image
<rsalveti> seems that I'm unable to log-in in any session
<ogra> thats weird
<ogra> but i think the whole session handling in gnome changed
<ogra> once unity-2d is the default it should work again
<rsalveti> yup, probably because of the gnome update
<dcordes> rsalveti: any workaround ?
<ogra> well, teeh gnome desktop session should work
<ogra> *the
<ogra> rsalveti, so about that xloader prob on omap3
<ogra> the current build script looks for a package named x-loader-omap
<rsalveti> I'm now trying to at least log-in at the gnome classic
<ogra> and doesnt find it
<ogra> so i assumed the binary package name changed
<dcordes> rsalveti: ok hope it works
<rsalveti> ogra: the package name changed and the mlo path
<rsalveti> but if you didn't change, it should still work
<ogra> right
<rsalveti> as we didn't remove the old package yet
<ogra> hmm
<ogra> weird
<ogra> it doesnt find it
<rsalveti> hm, ok, we should remove just the omap 4 one
<rsalveti> the version changed, but it kind of replaced the old x-loader package
<rsalveti> used by omap 3
<rsalveti> that could be the reason
<rsalveti> dcordes: gnome classic seems to work
<ogra> http://paste.ubuntu.com/557665/
<dcordes> rsalveti: nice. is it 'gnome-desktop' in custom.conf ?
<ogra> thats what i get in the buildlogs
<rsalveti> ogra: yup, saw that when you pointed me the logs yesterday
<rsalveti> dcordes: just select ubuntu classic desktop while log-in
<rsalveti> ogra: you should now get x-loader-omap3-beagle
<dcordes> rsalveti: ok. gdm doesn't use custom.conf any longer ?
<sveinse> ogra, I have to admit I know nothing of multistrapping... :(
<ogra> rsalveti, is there a transitional package ?
<rsalveti> ogra: nops, as this package wasn't installed at any image
<ogra> (though i'm not sure NCommander's way of extracting it would manage this, iirc he extracts the package directly)
<rsalveti> and x-loader-omap doesn't make much sense now, as we also have overo
<dcordes> can somebody recommend a known working qemu kernel for the current (above) natty builds ? I tried some yetserday and ran into illegal instruction problems which I think were NEON related
<rsalveti> and soon have igepv2
<rsalveti> that are all omap
<ogra> indeed
<sveinse> in regards of the igepv2: Are there any efforts on using the DSP from linux?
<sveinse> or more specifically: ubuntu
<rcn-ee> sveinse, it's possible with natty's 2.6.37 kernel, (dspbridge), just need to package 2 git project (dsp-gst, dsp-tools) then package the ti codec's..
<ogra> rsalveti, http://ports.ubuntu.com/ubuntu-ports/pool/main/x/x-loader/ has not a single natty build, did anyone care for getting the newly natty binaries to main yet ?
<rsalveti> ogra: hm, lp says it's published
<rsalveti> or this is something that lp is not yet tracking?
<ogra> published != main promoted
<rsalveti> publish in main
<ogra> that only means it went into the archive
<rsalveti> *published
<ogra> and the source is in main
<ogra> but the binaries werent transitioned
<ogra> http://ports.ubuntu.com/ubuntu-ports/pool/universe/x/x-loader/
<ogra> all of them sit in universe
<rsalveti> hm, ok, sources at main but debs still in universe
<ogra> right
<ogra> an archive admin needs to promote the beagle and panda binaries to main
<rsalveti> do we need to find a bug? or just ask someone?
<rsalveti> yup, at least beagle and panda
<rsalveti> don't know if it's ok for linaro to have overo at universe
<rsalveti> but then they can just ask it if it's a problem
<ogra> pitti promotes for us
<rsalveti> ogra: a lot easier when you ask for it :-)
<ogra> heh
<rsalveti> ogra: thanks anyway, and sorry for the confusion
<ogra> well, all fine now
<ogra> next publisher run we should be fine, i'll adjust the build scripts for the new names and file locations then
<rsalveti> cool
<ogra> ok, scripts adjusted
<rsalveti> ogra: nice, are you firing up another image for it? or just wait until tomorrow?
<ogra> we will have to wait until the promotion is done, i'll trigger an imagebuild later
<rsalveti> ok
<davidm> ogra, you about?
<ogra> davidm, indeed i am
<ogra> sorry, the canonical server kicked me outr
<davidm> Ah was wondering what happened
<davidm> cool
<jcrigby> ogra, can bug #683683 be closed out?
<ubot2> Launchpad bug 683683 in busybox "run-init on omap3, omap4 in natty dies if busybox is built with -marm" [High,Fix released] https://launchpad.net/bugs/683683
<ogra> jcrigby, no idea, ask the toolchain guys
<jcrigby> or is it still a bug but there is a workaround
<ogra> its a toolchain issue
<jcrigby> ogra, ok
<ogra> the other tasks are fix released iirc
<ogra> jcrigby, iirc davidgiluk assigned it to gcc (and doko moved it to gcc4.5 or so)
<jcrigby> ogra, yes I see that.
<ogra> the prob is that compiling with -marm breaks under 4.5 apparently
<ogra> at least for busybox
<jcrigby> ogra, right
<sveinse> does anyone have a 101 for lp/bzr?  i *think* I have created a branch within rootstock, but I'm uncertain how to branch from the main branch...
 * sveinse finally managed to make his own rootstock branch and commit his patch. First time of lp+bzr has quite a learning curve
 * rsalveti brb, late lunch
<rcn-ee_at_work> sveinse, thanks, i like that change, i'll be able to cleanup some of my roostock for debian tweaks.. ;)
<sveinse> yeah, I'm working on a custom HW board, and we use rootstock all the time to generate the rootfs images
<sveinse> so I can't use the official released images
<rcn-ee_at_work> same here. ;)
<sveinse> rcn-ee_at_work: running ubuntu or debian on target?
<sveinse> ..presume ubuntu since you're here ;)
<rcn-ee_at_work> all the above.. ;)  i'm really itching for debian wheezy with armhf.. ;)
<sveinse> oh? how come?
<sveinse> We've selected ubuntu as target OS since this had the best armv7 support when we had to choose
<rcn-ee_at_work> yeah and it's pretty quick.. (lucid->natty)... but it's still using soft floating point...  so it'll be interesting if ubuntu enables hardfp for natty++ (i'm hoping)
<sveinse> *that* I can put my vote to!
<sveinse> is natty particularly faster then maverick? BTW I'm running on omap3 (3530)
<rcn-ee_at_work> i wouldn't run it yet, as it's not even alpha-2, but it's a more patched gcc with the same compiler settings..
<sveinse> wheezy will be targeted for armv7?
<sveinse> I seem to be asking google the wrong questions...
<rcn-ee_at_work> sveinse, it looks like wheezy will have the older "armel" and a new "armhf" for armv7 stuff .. http://wiki.debian.org/ArmHardFloatPort
<sveinse> ah hf=hard float... thanks
<Martyn> natty boots on the pandaboard nicely
<Martyn> not so much on the Versatile Express .. yet
<Martyn> Are there any known issues getting a graphic boot on the pandaboard at the moment?
<ogra> rcn-ee_at_work, sveinse, ubuntu will have hf in about two releases
<rcn-ee_at_work> thanks, ogra cool..
<ogra> probably before wheezy :)
<rcn-ee_at_work> ;) for those that wait for the 'release'.. ;)
<ogra> indeed
<rcn-ee_at_work> probally about 2 years just like squeeze...
<ogra> the current debian hf port uses the ubuntu toolchain i think
<rcn-ee_at_work> yeah it's that linaro/ubuntu gcc-4.5.
<ogra> right
<dcordes> rsalveti: tried out the gnome desktop session and it works
<dcordes> rsalveti: somehow metacity didn't show up once
<rsalveti> dcordes: check bug 707014
<ubot2> Launchpad bug 707014 in netbook-launcher-efl "Ubuntu Netbook Edition 2D fails to launch from gdm by giving "No valid session found"." [Undecided,New] https://launchpad.net/bugs/707014
<GrueMaster> Is this possibly due to a change in jasper-initramfs?
<rsalveti> nops
<rsalveti> gnome-session
<GrueMaster> (I'm just now booting today's image).
<GrueMaster> Hmmm
<dcordes> rsalveti: cool thanks
<dcordes> -Exec=gnome-session
<dcordes> +Exec=gnome-session --session=une-efl
<rsalveti> and a new file
<dcordes> ok
<rsalveti> une-efl.session at /usr/share/gnome-session/sessions
<dcordes> it would be nice to be able to change the gnome-panel in nbl efl
<dcordes> rsalveti: is there a way to do this except for using a converted gnome session? I had bad experience with that with nbl not coming up
<rsalveti> dcordes: why you don't want to use a gnome-session for that?
<dcordes> I'm not sure about how to start netbook-launcher-efl correctly when doing it manually
<dcordes> just putt it in the session startup  before but it didn't come up sometimes
<dcordes> even with large delay
<dcordes> that was in maverick release images
<LetoThe2nd> just giving rootstock a little try. when i follow the guide in the wiki and fire up the image in qemu, it fails with segmentation fault.
<rsalveti> LetoThe2nd: https://wiki.ubuntu.com/ARM/RootStock/KnownIssues
<rsalveti> I think we have the fix for at least 2 bugs, but not yet packaged
<LetoThe2nd> rsalveti: so what to do? checkout trunk and use that?
<rsalveti> bug is not related with rootstock, it's probably qemu
<LetoThe2nd> rsalveti: just built it from scratch... might it be fixed in the ubuntu repos? probably not, i'd guess...
<ogra> rsalveti, before you add that file to /usr/share/gnome-session/sessions talk to didrocks, there is a certain naming scheme that has to be used i was told
<ogra> (great that there is a fix !)
<rsalveti> ogra: oh, ok
<ogra> i think the distro name needs to be in the filename
<ogra> i had to make unity-2d 2d-ubuntu
<rsalveti> could be, let me check with him
<GrueMaster> That will suck.  Not good if people want to try different launchers.
<ogra> ??
<ogra> people will never see that file
<ogra> its just a naming convention for the .session files that gnome put in place
<ogra> wont matter if you call it efl-ubuntu or foo-ubuntu or whatever, you can still select the efl launcher in gdm
<rsalveti> well, just got applied by janimo, but will talk to didrocks once he's on-line
<ogra> thanks
<ogra> with luck i'll kick out efl on wed. :)
<rsalveti> :-)
<ogra> though there might be a MIR blocker ...
<ogra> -2d is currently untranslatable
<ogra> (there is no gettext support yet)
<rsalveti> hm
<ogra> not sure i can get it past the MIR team that way, there are plans for gettext support, but no code or anything
<LetoThe2nd> bottom line - is qemu always segfaults with "qemu: fatal: VS[LR]I.64 not implemented", is there any way to get started with rootstock, or is this just a showstopper for now?
<rsalveti> LetoThe2nd: what qemu version are you using?
<rsalveti> and what ubuntu version
<LetoThe2nd> jd@tabr:~/rootstock$ qemu-system-arm --version
<LetoThe2nd> QEMU PC emulator version 0.12.5 (qemu-kvm-0.12.5), Copyright (c) 2003-2008 Fabrice Bellard
<LetoThe2nd> ubuntu 10.10, amd64.
<rcn-ee_at_work> LetoThe2nd, are you trying to build a 'natty' arm rootfs?
<LetoThe2nd> rcn-ee_at_work: just trying to get started with https://wiki.ubuntu.com/ARM/RootfsFromScratch
<rcn-ee_at_work> LetoThe2nd, just for reference, can you pastebin your full 'rootstock' command..
<LetoThe2nd> rcn-ee_at_work: of course. http://paste.pocoo.org/show/326221/
<rcn-ee_at_work> yeah, your aren't giving qemu any chance with that...  unless you run it on an armel machine, xubuntu-desktop is going to kill qemu...
<LetoThe2nd> rcn-ee_at_work: ok, trying it without seed now.
<LetoThe2nd> rcn-ee_at_work: is there any particular reason why xubuntu kills qemu? or what other packages will have the same effect?
<rcn-ee_at_work> LetoThe2nd, well just something less entensive for the inital install..
<rcn-ee_at_work> LetoThe2nd, it varies on release, some *.deb packages cause issues when installed thru qemu...  Ever since lucid it's been a pain in the rear to track down..
<LetoThe2nd> rcn-ee_at_work: i see.... strange. the message would indicate something missing in qemu's instruction set, so i'd guess it could happen with any package if the compiler only decided to put in that one instruction.
<LetoThe2nd> rcn-ee_at_work: taking away the seed, the emulated system does not segfault, but just stop with a blinking cursor after leaving the kernels boot. :-/
<rcn-ee_at_work> are you dumping any info to the serial console?
<LetoThe2nd> rcn-ee_at_work: no, just stating with the exact example command given on the wiki page.
<rcn-ee_at_work> LetoThe2nd, in your previous message "the emulated system does not segfault, but just stop with a blinking cursor" do you have a serial console for debugging
<LetoThe2nd> rcn-ee_at_work: ok, probably stupid question - where?
<LetoThe2nd> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda qemu-armel-201101242154.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
<LetoThe2nd> qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda qemu-armel-201101242154.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw"
<LetoThe2nd> ohsry for doubleposting.
<rcn-ee_at_work> ah, booting the image with qemu... sorry haven't done that for atleast a year...
<LetoThe2nd> rcn-ee_at_work: for the protocol, i try to start following this: https://wiki.ubuntu.com/ARM/RootfsFromScratch ... hoping that the "demo" commands provide a working starting point.
<rcn-ee_at_work> LetoThe2nd, based on the age of that wiki document, i bet it was with karmic's default, so you need to add "--dist karmic" but that's pretty old..
<TheUni> rsalveti: around?
<rsalveti> TheUni: yup
<TheUni> rsalveti: i've just merged our massive code refactor, i'd like to begin working with you on an evaluation when you get a chance
<TheUni> (xbmc)
<rsalveti> TheUni: awesome, I can try to check this out this week and focus more on next week
<rsalveti> as we moved it to alpha 3
<TheUni> yep, i saw
<rsalveti> TheUni: did you create any release for it? or basically current trunk?
<TheUni> rsalveti: current master. release is still a ways out
<rsalveti> np, will try to check that out
<TheUni> rsalveti: as i've mentioned, you might not target for natty, but we would greatly appreciate some ideas when it comes to packaging. what we've got currently is a monstrosity :)
<rsalveti> haha, np
<rsalveti> let's see what we can at least get for natty
<LetoThe2nd> rcn-ee_at_work: for the protocol: it works with dist karmic.
<rcn-ee_at_work> yeah, karmic's easier for qemu... compile for armv6 vs armv7 + thumb for lucid/maverick/natty...
<LetoThe2nd> rcn-ee_at_work: gotta read up a bit on qemus changes, maybe a more recent trunk might do :-)
#ubuntu-arm 2011-01-25
<Lopi> Is it possible to compile maverick for armv6?
<persia> Lopi, Potentially, although you might have to patch a few things.
<persia> You would have to recompile the entire archive though, starting with the toolchain, which would be a significant undertaking.
<Lopi> I see, I don't have hardware acceleration so unity might not run that great anyway :/
<rcn-ee> who does. ;)
<rcn-ee> Lopi, if you have enough builders, probally take about a month..
<Lopi> rcn-ee: Unfortunately, I'm the only one working on my project at the moment :/
<persia> Then it might take six or more months, depending on how much of the archive you need to recompile.
<persia> You might consider Debian as a better base for your hardware.
<rcn-ee> Yeah, lopi, that'll run Debian squeeze's armel... once you get the filesystem up an running, tweak the libs/packages you need with apt-build..
<rcn-ee> it should get you fairly close to as optimzed to armv6 as possible..  or there's angstrom.. ;)
<Lopi> I'm currently using karmic with lxde. I may consider switching to Debian. I'm having a hard time deciding the future of my project
<Lopi> I submitted a patch to openembedded a month or two ago for my device. I was playing around with the various OpenMoko distributions. I ended up deciding I needed to build something a little more custom.
<Lopi> I'm still fairly new to all of this though ;p
<rcn-ee> which reminds me.. did lool have a ubuntu 'task/brainstorm' for a building distro from custom compiler options?
<Lopi> rcn-ee: what device do you primarily work with?
<rcn-ee> here we go... this may or may not be usefull... https://wiki.ubuntu.com/Specs/M/DerivedArchiveRebuild
<rcn-ee> Lopi, well, today... the craneboard... ;)  mostly omap3/4's.. some mx5's and at91's..
<persia> rcn-ee, There's work going on in Launchpad to define/enable that sort of thing.
<persia> But I think it just means that one can copy source and rebuild in LP, perhaps with additional patches.
<rcn-ee> yeah, it's just an early spec.. ;) i do like the idea of tweaking the gcc setting and rebuilding..  (even thou you'd probally onlyl do it once..)
<lool> oh it's quite advanced actually
<lool> it allows maintaining derivatives easily, with a subset of or a whole Ubuntu
<Lopi> rcn-ee: Ah, I see. All I'm working with a lowly iPhone3G ;p
<Lopi> is*
<lool> I don't know how far the implementaiton is
<rcn-ee> lool, so if for some reason we wanted to reneable armv5 support in natty++  ;)
<lool> rcn-ee: https://dev.launchpad.net/LEP/DerivativeDistributions
<lool> rcn-ee: Eh  :-0
<lool> rcn-ee: I don't expect us to put efforts into it ourselves, but the tools will be there
<rcn-ee> Yeah, i wouldn't see you guys wasteing bandwidth on that.. but for a local farm, rebuilding ubuntu for a custom board would be nice..
<lool> rcn-ee: I also think qemu is also good enough nowadays that you could use it almost like real hardware provided sufficiently fast machines
 * lool => bed &
<rcn-ee> thanks lool  night!
<lilstevie> ohai lool
<lilstevie> er
<lilstevie> Lopi:
<Lopi> hey lilstevie :D
<lilstevie> Lopi: you taken over iX by yourself now?
<Lopi> lilstevie: yeah, been like that for awhile now
<lilstevie> ah, since my 3G blew its display driver i got left behind lol
<Lopi> ah I see, yeah I'm not really sure what to do with the project anymore
<lilstevie> working on getting ubuntu on my android tablet now :p
<lilstevie> Lopi: once oib is ported to more devices :)
<lilstevie> Lopi: the SGX535 is a much more supported GPU so bring on the fun ;)
<Lopi> lilstevie: yeah, I really want to play around with the ipad
<Lopi> lilstevie: getting bored of my 3G tbh
<lilstevie> yerah
<lilstevie> yeah*
<lilstevie> i am bored of iDevices TBH
<Lopi> I know what you mean, I want something open
<lilstevie> once oib works on the a4 i may get debian running on it though
<lilstevie> on my ATV*
<lilstevie> heh thats what i am loving with the galaxy tab at the moment
<lilstevie> the fact that without an exploit i can flash a custom kernel and fs
<Lopi> I can only imagine how awesome that is ;p
<lilstevie> heh it is amazing
<lilstevie> and for being a candidate for ubuntu too
<lilstevie> 1024*600 display resolution
<Lopi> nice, going with unity interface then?
<lilstevie> I guess :p
<lilstevie> i need to get this damn kernel to compile
<lilstevie> the only bad thing with the tab is that the initramfs is compiled in to the kernel
<Lopi> that kind of sucks ;p
<Lopi> better then relying on an exploit though
<lilstevie> well the kernel is opensource as well :p
<ka6sox> the Nook Color pretty much has the same issues
<Lopi> the most fun I have had with my 3G was making Mer work, packages are fairly limited on armv6 for Ubuntu
<Lopi> lilstevie: Have any suggestions for something new to play with on my 3G?
<lilstevie> Lopi: none really
<Lopi> lilstevie: bleh, that's what I was afraid of
<Lopi> lilstevie: I suppose I'll release Ubuntu with LXDE then wait for the a4 ports to be finished :/
<lilstevie> sad to say it but 3G has hit EOL
<lilstevie> thus all remaining armv6 devices are discontinued at apple
<Lopi> some people in the iDroid community suggested making something more custom, but I don't see the point with the 3G hitting EOL
<Lopi> I hate to let iX go inactive for so long, but I'm losing interest :/
<sanket> hii
<sanket> can any know an efficient ARM emulator so that I can ARM based filesystem
<ka6sox> sanket, qemu is the only one I've used.
<lilstevie> blah
<lilstevie> the initramfs is corrupy
<lilstevie> corrupt*
<sanket>  can u help me the installation process of qemu on ubuntu-linux...
<persia> sanket, What host, and which guest?
<sanket> host is i386 and guest is ARM
<persia> apt-get install qemu-kvm-extras should get you the emulator.  From there, boot in your favourite kernel and rootfs.
<persia> I believe that the current set only supports the versatile processor, although I know work has been ongoing for omap and a fast virtual variant.  I don't happen to know the current status of those efforts as reflected in the Ubuntu packages.
<lilstevie> versatile goes well
<persia> lilstevie, Doesn't it still need hacking to have more than 256MB memory?
<lilstevie> persia: i mean for qemu
<lilstevie> what device has less than that these days
<persia> So do I.
<persia> My understanding was that qemu only had 256MB emulating versatile, but could go up to 1GB emulating omap.
<persia> I could be misinformed.
<lilstevie> ah
<lilstevie> i dont bother emulating more
<lilstevie> because an emu inside a vm is not fun
<sanket> I m getting an error while using qemu .... qemu: fatal: Trying to execute code outside RAM or ROM at 0x30008000
<sanket> can anyone help me what is this error and how to solve it?
<lilstevie> i really wish rootstock would cache packages
<sveinse> Why do you get like 70 console-kit-daemon processes?
<ogra> sveinse, are you looking at threads ?
<ogra> you normally dont get 70 of them but there can easily be 70 userland threads
<sveinse> ogra, yes I think they are. They show up in pstree, but not in ps
<ogra> right
<ogra> thats fine
<ogra> 70 processes would be odd
<sveinse> It's the sheer number of processes/threads I'm curious of
<sveinse> I seem to have a HW problem linked to the serial port, as getty ttyO2 keeps respawning. Could it be related to it?
<ogra> every process in userspace is wrapped in CK
<ogra> no
<ogra> that rather smeppls like an issue with upstart
<ogra> *smells
<ogra> what kind of kernel do you use ?
<sveinse> yeah, ok. I'll keep my eyes open then
<ogra> there are certain features udev and upstart need enabled
<sveinse> ogra, custom since its a custom board
<ogra> right
<ogra> dont ask me which features that are (dont know from the top of my head) but if certain features are missing udev and upstart wont work correctly
<ogra> one i remember is signalfd
<sveinse> ogra, which... hahaha, you got ahead of me. I'll take a look the the versatile kernel or something and diff against it. Thanks
<ogra> better take the omap3 or 4 configs
<sveinse> which one is that?
<ogra> from the linux-image-...-omap3/4 packages
<ogra> we ship configs in /boot/config-<kernel version> in the packages
<lilstevie> i am having a bit of fail getting bootup in qemu :/
<ogra> versatile isnt really cared for since lucid iirc ... it wasnt touched by anyone ... and it is likely to go away in natty
<lilstevie> hm
<persia> ogra, Why is it going away?  Does qemu do omap well enough now?
<ogra> there is work going on to merge omap in, yeah
<sveinse> ogra, yes. I'll take a look at linux-image-2.6.35-24-omap.. Think that's closest to our HW. (we're running 2.6.37, so there's some other diffing issues)
<persia> My memory of UDS was that the qemu guys didn't expect to have something ready for natty, and wanted to stick with versatile, and then go for something else for natty+1, but I haven't been following progress.
<ogra> sveinse, natty has a .37 omap kernel
<lilstevie> so for now is it better to just do everything in chroot?
<ogra> persia, afaik slangasek is working on merging it into our branch now, ask janimo_ for details
<persia> Oh, cool.  I'm glad to hear the work made it.
<ogra> lilstevie, ??
<rsalveti> new qemu should be a lot better
<rsalveti> and work with omap 3 kernel
<lilstevie> well i need to set some things up in the image, that i would usually do while it is running in the emu
<ogra> lilstevie, well, qemu (at least the arm side) nor the kernel should have changed much since maverick
<lilstevie> it kinda screws up on boot and just halts
<ogra> if that would be the case rootstock wouldnt work at all
<ogra> and afaik that works
<ogra> so it must be something in your rootfs thats messed up i'd assume
<lilstevie> but i havent changed a thing in the rootfs
<lilstevie> using the instructions on the wiki, versatilepb and cortex-a8
<ogra> well, file a bug, attach the logs
<sveinse> A little off-track question: I created my rootstock branch yesterday, and commited some proposals to it. I planned on submitting a merge request, however I discovered a rather stupid error in the commit message. Would it be important to fix the commit message prior to merge, or doesn't it matter?
<ogra> doesnt really matter
<ogra> i make typos all the time in mine :P
 * ogra is famous for typing teh instaed of the
 * persia notes that bzr supports uncommit in case it's really something one is ashamed to have posted
<ogra> heh, and apparently for mistyping instead
<sveinse> Well, that's typo. I wrote "added --apt-clean option to rootstock" when the real option is --apt-update. Somewhat more significant error IMHO
<ogra> well, as persia said ... you can uncommit
<sveinse> thanks, I'll do that for the correctness of things
<rsalveti> yup, uncommit, commit again and force the push
<ogra> if you have pushed already you need to use --overwrite for the push command
<sveinse> Heh. That was far easier than expected
<sveinse> Uncommit in subversion isn't exactly trivial
<ogra> thats why we have bzr ;)
<janimo_> persia, pm215 from linaro is workiing on selecting omap bits from qemu-maemo and this will be packages with slangasek's help into a new source
<janimo_> which will rpvide binari packages for the current non-x86 binariesm leaveing current qemu-kvm x86 ony and be used by server team
<persia> Excellent.  last I heard was in October, when it was thought to not be possible in time for natty.
<persia> In this case I'm *really* glad to be wrong.
<janimo_> persia, indeed for natty it is still not possible to have omap in upstream - which would be ideal - so a temporary solution is anew source package
<rsalveti> pm215 is doing a quite good work with qemu
<rsalveti> lots of old bugs fixed already
<rsalveti> so we should have a more stable one for natty
<janimo_> persia, but the last details were still beiong discussed at the rally so no wonder the october info is out of date
<persia> new source package?  Ugh.  Oh well.  I suppose, if that's considered less effort than maintaining versatile another cycle (not that versatile is all that useful, really)
<janimo_> rsalveti, indeed he gets the fixes in very fast, the bottleneck and the boring part is getting the packaging (and possibly backports) right
<janimo_> persia, versatile annoys kernel people as it adds extra build time
<janimo_> and it would be better to have qemu support one of our official images - I am not sure versatile runs those?
<persia> Nope.
<sveinse> ok. Now I've created my very first merge request. I presume it's either orga or rsalveti who will review this.
<janimo_> so omap3 as omap4 is not yet nearly functional in qemu
<rsalveti> sveinse: yup, thanks for creating it, will take a look later
<sveinse> sure, np. Just wanted to see if I got things right
<janimo_> is a rename to unity-2d planned?
<janimo_> or a new metapackage of that name added?
<rsalveti> janimo_: hm, why?
<ogra> janimo_, yes, i'm working on that
<janimo_> rsalveti, I seem to remember ogra mentioning it a while ago, and for clearer naming
<janimo_> we have unity already
<ogra> (merging unity-2d-default-settings into the unity-2d source)
<janimo_> having the default-settings package be the top level one seems unusual
<rsalveti> that makes sense, but I don't understand why rename unity-2d
<janimo_> rsalveti,I meant rename an existing package to unity-2d
<rsalveti> if it's just this merge, then ok
<rsalveti> ok :-)
<janimo_> so that gnome-session can Recommends gnome-panel | unity | unity-2d and do not pull in gnome-panel all the time
<persia> The traditional reasoning behind the foo-default-settings packages is that they set defaults for various configuration subsystems that are unique to a selected interaction model, and may not always be appropriate for some specific package.  If unity-2d-default-settings is doing this, it would be better not to merge.
<persia> If it's just setting stuff for the unity-2d package, then it doesn't matter.
<janimo_> persia, makes sense, espcially since those settings are ubuntu addons to upstreams.
<janimo_> anyway a to plevel meta[pavkage with a short and sane name is desired
<janimo_> :)
<persia> Indeed.  For comparison, consider xubuntu-default-settings, kubuntu-mobile-default-settings, etc.
<persia> Maybe.  Depends if it's a flavour or not.
<persia> I'd claim that the right choice would be ubuntu-desktop or similar, to get that experience.
<janimo_> unity on debian or fedora will probably not use our themes or autostart settingd
<persia> Right, which is why -default-settings doesn't belong in that source.
<janimo_> I agree
<janimo_> I thikn the source should contain what the upciek team writes
<persia> (assuming that we seek null packaging, where feasible, in pursuit of automation)
<persia> Excellent.  I'll let you argue with everyone else whilst I sleep then :)
<janimo_> this is a tangent though to what I was askking - to have a clean and final name we can stick into gnome-session Recommends: field :)
<persia> Create some virtual supplied by all unity interfaces, and then control which meets the requirement through seeding, defaulting to "unity"
<janimo_> packages like flash-kernel that in addition to the package source have a bzr trunk in LP need to be changed in both places ?
<janimo_> I did not see it satte that it is mainatined in bzr which makes it more ocnfusing
<ogra> janimo_, change it in the bzr tree and build the package from there
<ogra> change, commit (UNRELEASED), change debian/changelog to natty), debcommit -r, push, bzr builddeb (or manually bzr export) and upload
<janimo_> ogra, thanks. I have not yet built from bzr before.
 * janimo_ misses almost everything from git when working with bzr
 * rsalveti understands janimo_ 
<rsalveti> but I must say I'm quite used with bzr already again
<rsalveti> god how I hate to debug qt
<rsalveti> a simple make takes an incredible amount of time
<rsalveti> that touches just one lib
<janimo_> I hope I'll get used to it again, switching to git 3 years ago was equally awkward I think
<hrw> janimo_: git-bzr-ng provides you one way to get bzr into git (push is broken)
<janimo_> hrw, thanks, I can work with bzr just don;t like it that much anymore
<hrw> my fingers also type git when I work with bzr
<ogra> persia, could you take a look at the control file at http://paste.ubuntu.com/558125/ ?
<ogra> purpose is to merge the -default-settings package into unity-2d source and create a metapackage ... i'm unsure about the conflicts/replaces and also aboutnot the fact if i need a transitional package or
<SaidKLE> Does anyone know how to install ubuntu natively on an arm MID?
<ogra> there is no such thing as "an ARM MID"
<ogra> :)
<ogra> you need to be more specific
<ogra> (SoC model etc)
<SaidKLE> The haipad m701 is an MID that claims it runs android 2.2.  I want to be rid of android completely and install ubuntu on it natively, if that's possible.
<SaidKLE> Here, I'm looking up the specifics...
<rcn-ee_at_work> that's a Telechip TCC8902, one of my buddies has it.. i think it's arm9..
<ogra> ah, no recent ubuntu then
<SaidKLE> Is there an older version, say 9.04 or something, that would work on it?
<ogra> 9.04 would work buut it is unsupported (EOL)
<rcn-ee_at_work> wow, it's actually arm11... (armv6)
<rcn-ee_at_work> so karmic..
<ogra> yeah, that should work then
<ogra> and karmic is actually still not EOL until april
<ogra> so you have three wonderful months :)
<rcn-ee_at_work> SaidKLE, was that the one on woot? about a week ago?
<LetoThe2nd> SaidKLE: hint: ubuntu has a relatively conservative older brother which is still supporting arm9. :-)
<ogra> hey, we strill support arm9 (for three months) :P
<Amaranth> LetoThe2nd: I thought squeeze dropped arm for armel?
<ogra> Amaranth, they did
<ogra> but they didnt go -march=armv7
 * LetoThe2nd is running an openrd here on deb5.0. :-)
<ogra> i think they still support armv5te
<ogra> even with armel
<Amaranth> ogra: Oh, I thought that was the point of changing the port name :)
<rcn-ee_at_work> well the old arm port did armv4..
<ogra> right
<ogra> and no thumb
<SaidKLE> So, I should probably run karmic?  I'm fine with that, but how does one go about actually getting ubuntu onto the device?
<ogra> for openmoko compatibility ;)
<ogra> SaidKLE, you should know everything about your bootloader and kernel
<ogra> then just make them use an ubuntu rootfs (see topic)
<SaidKLE> I don't.  I've tried to figure that out, but haven't managed it yet.
<LetoThe2nd> SaidKLE: there's a manual for the openrd providing a guide to flashing ubuntu. read it, combine it with what ogra said and there you go :-)
<ogra> right, thats the first step as ubuntu doesnt have either for you
<SaidKLE> okay.  I'll be looking that up...
<sveinse> SaidKLE: What HW are you sitting on?
<ogra> your kernel needs to have all options builtin for the udev used in karmic
<SaidKLE> once I know that though, do I just put a certain ubuntu file where the boot loader expects to find it?
<ogra> else it wont work
<SaidKLE> Haipad m701 telechip tcc8902
<ogra> mind you, its usually not a beginner task to get another OS on such devices
<LetoThe2nd> SaidKLE: nÃ¶, its first about getting your bootloader and kernel right, including config and layout on bare flash.
<ogra> and you will likely have to rebuild your kernel etc
<ogra> and know about flashing or how to run the OS off an SD card
<sveinse> from past experience, if you have a bootloader and kernel (config) available, then its a lot easier to get ubuntu up and running
<LetoThe2nd> SaidKLE: if you're a beginner and don't have access to advanced debricking tools (i.e. a good jtag interface) i guess it's advisable to go either hunting for some existing port or leave the thing as is.
<sveinse> all boards I have worked with in the past had a linux demo kit with kernel which I could use with ubuntu
<LetoThe2nd> at the moment we don't even know the bootloader type... :-/
<ogra> nor what kind of kernel is used
<LetoThe2nd> yeah, basically we know - nothing.
<sveinse> I know this is a wrong place for the question, but what is console-kit? If I'm building a system with no interactive uses (only services), can I live without it?
<sveinse> my system is not going to run X -- only a Qt QWS application, and without DBUS
<ogra> persia, updated paste at http://paste.ubuntu.com/558148/
<persia> ogra_, I don't know precisely how the pieces fit together, but I'm opposed to merging a -default-settings package into anything that has code, and don't see the point of metapackages except as expressions of flavours.
<GrueMaster> We may have a problem with images next week.  X is getting updated Friday.  May cause turbulence.
<persia> ogra_, Looking at your changes to control: Please don't call something a "metapackage" if it has content (and isn't in section: metapackages).  The mechanics of replacement look acceptable, although take care with versions (there's no changelog entry in the diff, so I don't see that).
<ogra_> persia, well, how should i call it ?
<ogra_> it depends on the rest of unity-2d but indeed ships gconf bits and postinst
<persia> Hmm.
<persia> Well, there's two ways to do it.  the one I like, and the one you seem to be pursuing.
<ogra_> effectively it does the same a metapackage does
<ogra_> i only do what upstream will do anyway
<persia> The common way is to have a metapackage (which is empty by definition) on a per-flavour basis, and have that pull -default-settings.
<jhobbs> i noticed there is a omap4 ubuntu server daily build now
<jhobbs> where does the package list that goes into that come from?
<persia> jhobbs, Does it work for you?
<ogra_> well, thats exactly what upstream wants to get rid of
<jhobbs> i haven't tried it yet, but i'll let you know
<persia> jhobbs, It's the server stuff from the ubuntu.natty seed
<persia> ogra_, Why?
<ogra_> we are supposed to have a unity-2d as we have a unity package in the end
<ogra_> the prob is that the binaries in unity-2d can be used separately
<ogra_> so there are four binary packages and we need some toplevel that has to be called unity-2d
<ogra_> which depends on the other binaries
<persia> In that case, don't claim to be a metapackage.  unity is "Unity is a graphical interface designed for Ubuntu Netbook Edition".  That's unfortunate, as I heard that Ubuntu Netbook and Ubuntu Desktop were merging, but it's close.
<ogra_> the toplevel is supposed to ship the session and config
<persia> Just have the description say "Unity 2D is a graphical interface providing the Unity experience, but relying only on 2D acceleration" or similar.
<persia> Just stay away from "metapackage", because that means something specific, which this isn't.
<GrueMaster> btw:  The une-efl session bug still exists in today's image.
 * GrueMaster thought it was fixed.
<persia> Which bug is that?
<GrueMaster> bug 707014
<ubot2> Launchpad bug 707014 in netbook-launcher-efl "Ubuntu Netbook Edition 2D fails to launch from gdm by giving "No valid session found"." [Undecided,Fix released] https://launchpad.net/bugs/707014
<persia> Which version of netbook-launcher-efl do you have?
<GrueMaster> 0.3.2-0ubuntu5.  It doesn't appear to have been properly Fix Released.  I don't see a commited entry in the bug.
<persia> It claims to have been fixed in 0.3.2-0ubuntu6, so that's expected behaviour (based on https://launchpad.net/ubuntu/+source/netbook-launcher-efl/+changelog )
<persia> rsalveti forgot to add LP: foo in the changelog, that's all.
<GrueMaster> Still, it should be in the pool.
<GrueMaster> checking.
<persia> It is, from what I see.
<rsalveti> GrueMaster:  Failed to upload on anacardiaceae (armel)
<rsalveti> that's the error I saw here
<persia> Ah, source is in pool.  Binary failed.
<persia> rsalveti, Have you asked the LP folks about that yet?
<rsalveti> not to build, but to upload
<rsalveti> persia: not yet, just saw it
<rsalveti> persia: should I ask for help at the lp channel?
<persia> Fail to Upload usually indicates something wonky with soyuz.  It's almost always worth asking in #launchpad
<rsalveti> or is more related with ubuntu itself?
<persia> No, it's #launchpad.
<GrueMaster> Let me check if an update will pull it.
 * rsalveti asking
<GrueMaster> I'm not seeing anything on lp that indicates fail to publish.
<GrueMaster> Looks like it was just posted after the image build started.  No worries.
<rsalveti> well, I got an email with it
<GrueMaster> apt-get update;apt-get install netbook-launcher-efl has found the updated package.
<persia> Odd, indeed.
<GrueMaster> It'll be in tomorrows image (assuming pool churn doesn't clobber the image build).
<GrueMaster> I am a little worried about A2.  We have a new QT, X stack, and now I find we are getting 2.6.38 kernel.
<GrueMaster> All for A2.
<rsalveti> probably it failed but then soyuz tried to publish it again later on
<GrueMaster> Possible.
<rsalveti> haha, probably lots of new bugs :D
<GrueMaster> yea.
<rsalveti> GrueMaster: did you try latest omap 3 image already?
<rsalveti> I still didn't check to see if the x-loader got into the image correctly
<GrueMaster> btw:  rsalveti:  when you post a bug fix, add (LP: #<bug id>) to the changelog.  Then LP will handle marking the bug as Fix Released.
<rsalveti> I know, I was going to do that after you tested the bug
<GrueMaster> And no, I haven't tried the omap 3 image.  Beagle is put away, and I haven't gotten an XM yet.
<rsalveti> but then janimo pushed my debdiff
<GrueMaster> oops.
<rsalveti> as I created the debdiff before actually opening the bug
<GrueMaster> Ah.
<rsalveti> was planning to update it after the test :-)
<GrueMaster> bass ackwards.
<GrueMaster> :P
<rsalveti> ok, will download latest omap 3 image then
<GrueMaster> whee.  46 upgrades since today's image was built.
<persia> !ohmy > GrueMaster
<ubot2> GrueMaster, please see my private message
<rsalveti> well, omap 3 image seems to be working again
<rsalveti> at least going into resize
<rsalveti> GrueMaster: awesome, omap 3 image seems to be working quite well
<rsalveti> time to activate the console and see the boot messages
<ka6sox> has anyone heard of anybody getting ubuntu-arm booting native on a nook color?
<rsalveti> yup, no issues and no kernel traces
<rsalveti> GrueMaster: so it seems ok, finally :-)
<persia> ka6sox, Are you able to boot arbitrary kernel against arbitrary rootfs yet?
<ka6sox> persia, arbitrary? I have a rebuilt kernel from Android (have the source and have rebuilt it)
<ka6sox> and also have the openembedded.org reference distribution called Angstrom booting
<ka6sox> so thats pretty random
<rcn-ee_at_work> ka6sox, where does it stop booting?
<persia> Well, hardly random, but at least one of your choice.
<rsalveti> if you already have a common distro running on it should be easy to run ubuntu
<persia> Have you tried with an Ubuntu rootfs?
<ka6sox> rcn-ee_at_work, it boots all the way up
<ka6sox> persia, I didn't know about the maverick-omap till later
<persia> ka6sox, So it works for you?
<persia> How is the screen refresh?  Is X behaving nicely?
<ka6sox> rsalveti, the main issue is that we used a no-initrd setup on Angstrom
<ka6sox> persia, x isn't quite there...mostly because they don't seem to have the latest sgx running but we are using FB.
<rsalveti> hm, it'd be good to have initrd to boot ubuntu, but I believe you can make it work with current setup
<persia> Does the nook not support an initrd?
<rsalveti> if you have access to the bootloader, it should be fine
<ka6sox> (funny because the guy who does Angstrom was the guy who worked on beagleboard.
<ka6sox> rsalveti, we don't really...
<ka6sox> its kind of kludgy...
<rsalveti> ka6sox: how are you flashing a newer kernel and booting it?
<ka6sox> 2 partitions on an SD
<ka6sox> 1 vfat with kernel initrd and MLO
<ka6sox> 1 ext2 with rootfs
<ka6sox> shove it in and away you go
<rsalveti> so you alread have an initrd
<ka6sox> an Android one
<ka6sox> ubly
<ka6sox> ugly
<rsalveti> if it's possible to load a valid kernel and initrd, then you can regenerate one for ubuntu
<rsalveti> but then it could have size restrictions
<ka6sox> they are using 2.6.29 for the existingkernel.
<rsalveti> urgh
<ka6sox> I was trying *not* to have to redo the kernel...but I can
<rsalveti> weird that they are still way behind, as it's basically an omap3
<ka6sox> vendor choice as to which version you use...they are stuck on 2.1
<rsalveti> but still, you can generate an initrd for it
<ka6sox> I have a working chroot of maverick on it.
<rsalveti> well, you have the sources, then you can check what they changed for it
<rsalveti> lot of work probably, but still something
<persia> Redoing the kernel is part of the point, I'd think, so that you could have a distributed sourceful kernel package for reliable bugfixing.
<rsalveti> ka6sox: the image for ac100 is also using 2.6.29
<rsalveti> once you got the correct kernel and modules, copy them to the ubuntu rootfs, regenerate the initrd and it should be fine
<rsalveti> if you're booting with correct cmd args
<ka6sox> the biggest problem is that they didn't send nice "patches" or even tell us what they started with before they started *their* patches.
<rsalveti> hehe, usual
<rsalveti> source == big and ugly tarball
<ka6sox> rsalveti, generated on a windows machine (Documents and Files dir was there)
<rsalveti> hehe
<persia> What VCS tools need is a "discover" function, where they compare past revisions against a given source, find the set of commits that appear to have been applied, and construct a virtual history including prior commits (split point + cherrypicks) and then a massive commit including the rest of the diff, which can then be picked apart at leisure.
<ka6sox> okay so what I'll do is unpack the uImage of the kernel and get the modules out of the initrd thats there and put them in maverick chroot...then regenerate teh initramfs.
<rsalveti> yup, or even build the kernel on your own
<rsalveti> and install the modules at a custom path, then you can easily copy the modules
 * ka6sox reprogrammes the LF servers that check for GPL compliance to do that :D
<rsalveti> or just deb-pkg (iirc) that will generate a kernel deb file
<rsalveti> that you can install at your arm chroot
<rsalveti> and regenerate the initrd
 * persia notes that lots of extra points accrue for creating a source package that generates the appropriate binary packages and uploading to the archive so everyone can share
<ka6sox> I've never tried building cross with make-kpkg kernel_image :D
<persia> Could build native.  Would take a bit on the Nook, but not forever.
<rsalveti> make -j 6 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CONFIG_DEBUG_SECTION_MISMATCH=y deb-pkg
<rsalveti> cross compiling
<rsalveti> with any kernel source tree
<rsalveti> just need the proper .config file in place
<ka6sox> okay I have the defconfig that they used and the patched source
<rsalveti> if you're running maverick, just install the ubuntu/linaro cross compiler
<ka6sox> still on lucid
<ka6sox> I'm an infra guy so I generally stay with LTS
<persia> On lucid, you should be able to run `mk-sbuild maverick` to generate a maverick schroot, which you can then use to install and run the cross-compiler.
<ka6sox> kk
<rsalveti> ka6sox: check https://launchpad.net/~linaro-maintainers/+archive/toolchain then
<rsalveti> the backported linaro/ubuntu cross compiler
<ka6sox> okay good.
<persia> Unless you have another reason to install all of ubuntu-dev-tools, you might want to just cherrypick that script from it.
<ka6sox> okay so I'll have to generate the kpkg and have to bust it out though to create the uImage.
<ka6sox> I don't recall mkuImage being able to read a .deb
<rsalveti> generally I just install it, regenerate the initrd and then use mkimage to create the uImage and uInitrd
<rsalveti> all that inside a valid arm chroot
<ka6sox> okay great...thanks.
<ka6sox> the omap3 image should be closest to what we have.
<ka6sox> 3621
<rsalveti> yup, I'd get first a minimal ubuntu rootfs (maverick)
<rsalveti> and try to make that work
<ka6sox> ya, I need rndis and ssh support mostly
<rsalveti> http://people.canonical.com/~rsalveti/lamont/beagle/
<rsalveti> this image should work for you
<rsalveti> is a minimal maverick image
<rsalveti> that I generated for beagle xm
<ka6sox> okay thanks. I'll use that
<rsalveti> guess same one we're using at our xm builders
<ka6sox> I've been playing for years on things like the Slug and Pre but first time I"ve "ported" an OS on a device
<rsalveti> :-)
<rsalveti> would like to buy a nook color to play, but kind of expensive around here
<ka6sox> oh?
<ka6sox> out of country I suppose
<rsalveti> yup
<rsalveti> brazil
<ka6sox> appreciate the help...I'll stop by later with a report...
<ka6sox> we ported what we call "optware"  (linux apps running on Android)
<ka6sox> so we have the tools we need to port this.
<ka6sox> (like chroot)
<ka6sox> later..thanks.
<persia> ka6sox, Good luck.
<rsalveti> cool, later
<tmzt> ka6sox-away: do you have a chroot version of init that works under bionic?
#ubuntu-arm 2011-01-26
<ka6sox> tmzt: if init?
<ka6sox> as in sysV init?
<ka6sox> yes
<tmzt> yeah
<ka6sox> yes, it works
<tmzt> this is what I started on but I couldn't get it to work https://github.com/tmzt/nativenetbook-nativeinit
<ka6sox> tmzt, have you heard of Optware?
<tmzt> yeah
<ka6sox> what happened is we ported optware to work on android
<ka6sox> https://github.com/optware4android/nook-color
<ka6sox> after a few iterations we had something that works.
<ka6sox> so that gave me the ability to use things like ltrace and strace etc to look at porting.
<ka6sox> and chroot
<tmzt> ka6sox: I'm trying to get my X server to work with existing X sessions
<tmzt> but xinit wants to start the server itself and mine runs outside of the chroot
<ka6sox> then only "env" I bring into my chroots are /proc /sys and /dev as bind mounts
<persia> tmzt, Do you mean that you want stuff launched in the chroot to be clients of an X server outside the chroot?
<tmzt> yes
<ka6sox> so nothing outside of that is available
<tmzt> my X server androix.org runs as a native bionic aplication
<tmzt> er, android application linked against bionic
<persia> tmzt, I don't know much about android architecture, but you can usually get that to work if you can connect to the X server over the network or you bind-mount /proc: just export your desired DISPLAY
<ka6sox> riht
<ka6sox> er right
<tmzt> I know, but the issue is I want to launch Xsession and also need things like a dbus system bus
<tmzt> when I tried to do it it failed because it lost the controlling tty or other wise the forked children failed to run
<ka6sox> tmzt, well...we have optware running *alongside* of android.
<ka6sox> so somethings like that are possible.
<tmzt> I'll look at it, I don't think most of the X clients are packaged though
<persia> tmzt, If you need dbus, try bind-mounting /var/run
<ka6sox> okay back to porting.
<tmzt> android doesn't use dbus, so dbus would be running inside of the chroot
<tmzt> anyway, thanks I'll look at this nook stuff and see if there's anything I can use
<ka6sox> if nothing else it shows that you can run linux things with linux libs alongsiide of the android/bionic stuff.
<ka6sox> hardcoded paths are a pain (like /lib/ld-linux.so
<ka6sox> )
<ka6sox> but since their /lib doesn't contain that it doesnt matter.
<tmzt> ka6sox: ah, so you aren't using a chroot?
<ka6sox> for Ubuntu, yes, but optware is NOT a chroot
<ka6sox> it all goes in /opt/
<ka6sox> and we bind mount to the rootfs
<ka6sox> the only thing in the original rootfs is a few things that *have* to be in /lib and a small script that calls sysV init to get the optware services running
<tmzt> that's in the git repo?
<ka6sox> the one I pointed you to..yes
<ka6sox> including sources
<JamieBen1ett> exit
<janimo_> rsalveti, GrueMaster efl launcher I gave back a few hours after I saw it failed to upload. LP does not do that by default, and I am not sure why it failed in the first place
<rsalveti> janimo_: oh, ok, good to know
<ogra> http://www.fit-pc.com/trimslice/
<ogra> nice !
<LetoThe2nd> ogra: heise reader ;-)
<ogra> heh
<ogra> yeah
<persia> Now that's a proper computer, in an appropriately shiny plastic case.
<Homefix1> sorry for the noob question, when starting qemu, is there something i can place in: "qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel ./vmlinuz -hda <whatever you name it>.img -m 256 -append "root=/dev/sda mem=256M devtmpfs.mount=0 rw" " to prevent the decktop from loadind (just give me command shell) thnx
<ogra> between the quotes after append add text as a keyword
<ogra> the login manager checks for that before firing up
<Homefix1> ogra: sorry for being thick, if your talking to me im lost i dont understand what you mean, could you give me an example? and if you were not responding back to me im sorry.
<ogra> change rw" to rw text"
<ogra> in the line above
<Homefix1> ogra thnx: i owe you coffie
<Homefix1> ogra: can i ask you one more thing? My machines hostname is Homefix, after running .img on my phone the promt is "dad@localhost" instead of "dad@Homefix. I have my /etc/hosts file setup correctly "127.0.0.1 localhost Homefix".I have /etc/hostname setup correctly "Homefix" is my problem here in the chroot startup script here:
<Homefix1> echo "Setting /etc/resolv.conf to Google Open DNS 8.8.8.8 and 8.8.4.4"
<Homefix1> echo "nameserver 8.8.8.8" > $mnt/etc/resolv.conf
<Homefix1> echo "nameserver 8.8.4.4" >> $mnt/etc/resolv.conf
<Homefix1> echo "Setting localhost on /etc/hosts "
<Homefix1> echo "127.0.0.1 localhost" > $mnt/etc/hosts
<Homefix1> echo "127.0.0.1 localhost" > $mnt/etc/hosts
<Homefix1> ?
<ogra> localhost always needs to be there
<Homefix1> ok thns
<ogra> adding a line like: 127.0.1.1 Homefix
<ogra> to /etc/hosts should give you the desired outcome
<Homefix1> ok thought i did that try again thnks
<ogra> (note the 1.1 at the end of that IP)
<Homefix1> no i didnt just noticed the 1,0
<Homefix1> 1.1
<Homefix1> ogra I promise only 1 more quest. How come when starting the chroot in my android terminal, i get the promt "root@localhost" the i login as dad and get, "dad@localhost", I start vncserver as dad@..., then sesssion starts, i use vnsviewer set up as dad for "nik", localhost for "hostname", my vnc password then connect. I get to desktop logged in as root and the root desttop. I have setup
<Homefix1> HOME=/home/dad and USER=dad in the startup scripts (that are here:http://forum.xda-developers.com/showthread.php?t=913622)<<<<< those entries are entered as  "root", I changed my entries to "dad" and added export USER=dad to "bootubuntu"............
<Homefix1> ogra: is ther a way to get looged in as dad instead of root?
<ogra> chroot always makes you root in the target fs
<Homefix1> k
<ogra> but you can run "su dad"
<ogra> that should make you dada
<ogra> heh
<ogra> dad i mean
<Homefix1> haha
<Homefix1> i just log in as dad in the chrooted term.
<Homefix1> can i take a rootstock build 1G .img , turn it into a 3G image?
 * persia notes that chroot takes a --userspec argument if one wants to be non-root for some reason.
<ogra> oh, i didnt know that :)
<persia> It's exceedingly rarely useful: primarily only when embedding the chroot call in  some other utility.
<ogra> persia, btw
<ogra> Description: The Unity 2D interface for non-accelerated graphics cards
<ogra>  This package installs a fully usable Unity 2D session and provides the
<ogra>  common configuration files and defaults. Installing this package will
<ogra>  offer the Unity 2D session in your login manager.
<ogra>  .
<ogra>  Unity 2D is designed to run smoothly without and graphics acceleration.
<ogra> thats my final text now
<persia> No.
<ogra> waiting for kaleo to process the merge request
<persia> It expects 2D acceleration, it just doesn't require 3D acceleration.
<ogra> it doesnt
<persia> Try running it on unaccelerated framebuffer and you *will* feel pain.
<ogra> xfbdev doesnt have any 2d accel
<ogra> thats what i'm doing here
<GrueMaster> persia: I do run it on unaccelerated 2D fame buffer.
<persia> Yes it does: it was added to trunk in 2004
<Homefix1> its happened again, i was having problems not getting a "prompt" in the terminal of the chrooted image i made a with rootctock....tried again last night it worked but the image was too small. tried again made it 3G but now no prompt...eGGgghh..... any suggestions why i canot get a prompt in the terminal with one image but not another?
<persia> GrueMaster, Really?  Not xfbdev?
<GrueMaster> Not in VM.
<GrueMaster> It is using the Xsvga driver iirc.
<persia> Oh, indeed.  And the performance there is acceptable?
<GrueMaster> Seems to be.
 * persia is impressed.
<ogra> well, it is very likely that people not having 3d accel end up with fbdev
<persia> ogra, So, three things about the Description then:
<ogra> i think thats our default fallback for cards without any driver
<persia> 1) The short description (after "Description:") should complete the cloze ${package} is a ${short-description}.  Repeating "Unity 2D" is frowned upon (although you've used it a bit differently, so might argue you mean "Unity" and "2D" separate from "Unity 2D")
<persia> 2) The prefatory phrase "This package" is useless drivel, and confusing for package mangagement tools that don't give the user the package name.  Start exciting and juicy.
<persia> (hint: inserting "The Unity 2D interface" may help)
<ogra> i thought there were reasons why these complaints were removed from lintian
<persia> 3) s/and/any/ in the last sentence.
<ogra> uh, yeah
<persia> I thought they were removed to make people like me less picky.
<ogra> i'll change that with the upload after the merge was done
<persia> Heh, sure.  No rush.
<ogra> i dont want to file a new merge request right now
<persia> You can just update them, you know.
<persia> (there's even some handy UI in LP for that)
<ogra> there are other typos in the control file i need to fix anyway
<GrueMaster> wait, there are other people as picky as you, persia?  :P
<ogra> which i planned to do in a subsequent upload
<ogra> GrueMaster, IRS
<ogra> ;)
<persia> GrueMaster, I believe myself to only be in the 92nd percentile of pickiness.
<GrueMaster> heh
<Homefix1> can i turn a 1g rootstock image into a 3G (made filesize too small)
<ogra> persia,
<ogra> Description: Unity interface for non-accelerated graphics cards
<ogra>  The Unity 2D interface installs a fully usable 2D session and provides the
<ogra>  common configuration files and defaults. Installing this package will
<ogra>  offer a session called Unity 2D in your login manager.
<ogra>  .
<ogra>  Unity 2D is designed to run smoothly without any graphics acceleration.
<ogra> better ?
<Homefix1> ogra I fixed it but why would i one image require  "mount --bind  /dev $mnt/dev" in the startup scriptand another made the same way not need it? could it have somthing to do with the programs i install in qemu? I just dont get it?
<ogra> no idea, i dont know who made these startup scripts
<ogra> generally you should bind mount /dev into the chroot to be able to access devices though
<prpplague> ogra: http://www.engadget.com/2011/01/25/compulab-makes-a-tiny-tegra-2-computer-for-the-lilliputian-commu/
<prpplague> ogra: seen that?
<ogra> yep
<ogra> <ogra> http://www.fit-pc.com/trimslice/
<ogra> <ogra> nice !
<ogra> ;)
<prpplague> ogra: man, that looks nice
<ogra> sadly the kernel situation for tegra is very very far from being usable
 * prpplague can't wait to order one
<prpplague> ogra: that will change when people get a trimslice and start doing dev
<ogra> i suspect they will come with a 2.6.29 or 2.6.32 kernel
<ogra> that wont help with the proprietary drm driver or xserver
<ogra> as long as nvidia doesnt work with the community and compiles against some decent kernel or xorg
<prpplague> ogra: ahh wasn't aware of the proprietary drm driver stuff
<ogra> currently to make X work accelerated on tegra you need to apply their overlay FS (a tarball) with ancient xorg versions and libs
<ogra> and their kernel module is only compiled for two or three old kernel versions
<prpplague> ogra: ahh but that is for accelerated, without works right?
<ogra> i wish they would provide a shim so we could use dkms to just build it against the kernel we ship
<ogra> sure, plain framebuffer works fine
<ogra> thats what i use on the ac100
<ogra> but its sad that i cant use the full power of the device due to silly management decisions at the manufacturer
<ogra> their whole sound, powermanagement and cup speed control is done by a proprietary daemon in userspace
<ogra> *cpu speed
<ogra> i really love TI for its openess
<GrueMaster> ogra: I have seen some alsa patches recently for the tegra.  Hopefully they will be in 2.6.38 or 39.
<rsalveti> hehe, I'd say they will get something for 40
<ogra> GrueMaster, wont help, the codecs are binary inside the daemon
<rsalveti> or even alter on
<rsalveti> with luck omap 4 is going to be kind of fine for 38/39
<ogra> GrueMaster, the kernel side only provides hooks for them
<rsalveti> :-(
<ogra> i wouldnt mind all that if nvdidia would at least provide binaries against decent versions of all that
<ogra> but what they offer is massively outdated
<prpplague> ogra: yea omap4 should be pretty robust, just love that trimslice package
<ogra> yup
<GrueMaster> ogra: What I'm seeing is patches in the last few weeks directly from nvidia to alsa.  From what I can tell, they are exposing the gpio's to the codec and tweaking the codec driver as well.
<ogra> right, but the binary bits come from the userspace daemon
<ogra> i have sound devices on the ac100 too ... they just dont route to anything unless i get the daemon running
<ogra> (silence and pules at 100% cpu)
<ogra> *pulse
<GrueMaster> That is the non-alsa driver.  They removed it post 2.6.36.
<pH5> hi, has anybody compiled qt4-x11 with -opengl es2 support yet?
<ogra> pH5, rsalveti works in that
<ogra> not sure there is a ppa with the packages
<rsalveti> pH5: yup, currently debugging that with sgx
<rsalveti> yup, we have, let me get the link
<rsalveti> https://launchpad.net/~rsalveti/+archive/qt-neon-gles
<rsalveti> natty and maverick
<pH5> ogra, rsalveti: ow, great. thanks!
<rsalveti> np
<armin76> nice, it has gigabit
<ogra> the ppa ?
<rsalveti> :P
<ogra> :)
<KC9SJQ> Howdy all
<KC9SJQ> I have some questions about the wireless system
<ogra> ask then :)
<KC9SJQ> I'm attempted to setup a pandaboard as a router, with a bridge between the built in ethernet and wifi
<KC9SJQ> unfortunately, it seems like the wireless isn't supported
<ogra> it is
<ogra> did you install the ti addons ?
<KC9SJQ> when I define it via /etc/networks/interfaces as master
<KC9SJQ> oh, I did, it worked as a client before I start playing with networking
<ogra> ah, i haven used the wlan without NM yet
<ogra> but i suspect you need wpa_supplicant setup or some such
<KC9SJQ> The line that conserns me is "no (wireless) mapping found for key: wireless-mode
<ogra> wait, you said master, you mean AP mode ?
<KC9SJQ> wpasuplicant is installed, and I think I have it set as an open ap
<KC9SJQ> yes, that is correct. master as in ap
<ogra> i know rsalveti provided AP mode to me in dallas through his panda so it definitely works somehow
<ogra> but that might have been through NM as well
<rsalveti> ogra: that was n900
<ogra> the panda network ?
<rsalveti> but using nm at my host
<rsalveti> yup
<ogra> i thought you used the panda for the ap stuff ... ok
<rsalveti> never tried to use the panda wifi chip as ap
<ogra> me neither
<rsalveti> the driver wasn't stable at that time
<rsalveti> lots of kernel panics all around
<ogra> i also dont know if the driver from the ppa is actually built against mac80211
<ogra> then you could use hostapd
<rsalveti> maybe you will get better results with current upstream one
<ogra> definitely
<KC9SJQ> What is that, do you have a link?
<ogra> http://groups.google.com/group/pandaboard/browse_thread/thread/291bf9cbd8c36d15
<ogra> that ppa should have newer stuff
<ogra> sudo add-apt-repository ppa:tiomap-dev/omap-trunk
 * KC9SJQ looks
<ogra> not sure if it already has the new wifi driver though
<ogra> might be that this is only upstream
 * KC9SJQ adds to mirror and updates
<KC9SJQ> I'll let that chug while I get a sandwich.
<KC9SJQ> Thanks for the help.
<ka6sox> okay lets see what explodes when I boot this puppy
<persia> ogra, The new description looks good to me.  Publish it :)
<ogra> persia, heh, to late
<ogra> already sitting in NEW
<ogra> i need to talk kaleo into a new upstream release before i can MIR them though
<ogra> i dont want to have bits in debian/patches for the MIR
<ogra> but thats for tomorrow
 * ogra really likes bzr builddeb --split :)
<persia> --split is *not* the right way to do it.  I forget why, but that was the conclusion from the discussion between NCommander and james_w.
<ogra> persia, --split is what upstream insists to be used, they also insist to have the debian dir in the branch, only tarball releases wont have it
<persia> Dunno.  Talk to one of the folks I listed above.  I just remember hearing it wasn't the right way to do it after that conversation.
<ogra> well, it works great and makes life a lot easier
<persia> It does something messy and bad when attempting to handle coordination between the branch importer and the upstream branch.
<persia> But my understanding of UDD is too weak to know precisely what.
<persia> The key bit is that I believe it blocks direct cherrypick from upstream to the import branch.
<ogra> well, i'll go with upstream if they insist, who am i to complain if it makes my life easier
<ogra> ah, well, there is no import branch
<persia> There will be as soon as it passes NEW.
<ogra> thats the main argument, they want a single branch per project
<persia> Seriously, go get some UDD Kool-Aid.  You'll be in a lot better shape to discuss this with upstream.
<persia> It will be better for you and better for them to take advantage of the import branch.
<ogra> doesnt help me with upstream, really
<ogra> you mean they should merge back from the package branch ?
<ogra> into trunk
<persia> I mean that because bzr doesn't support parallel trees, it won't support operations between the import branch and the upstream branches if you use --split.
<persia> As in an error message with `bzr merge`.  Simply no support for it at all.
<ogra> no, you need to merge the import branch before doing a new upstream indeed
<ogra> hmm ?
<ogra> why shouldnt it merge anymore
<ogra> the content stayed consistent
<persia> You *can't* if you created with --split.  If upstream creates an artifact tarball, it can be done, but with --split, the tarball is semi-random, and the history is unrecoverable.
<persia> But I don't know enough about this: please ask someone knowledgeable.
<persia> bzr doesn't use the content as part of merging.
<persia> Yes, that sounds odd, but it's true.  If you ask the bzr folk, they'll tell, you about the parallel merge problem, and how it's the very first thing they fix after changing the on-disk format of bzr.
<persia> But until the data format is fixed, it's not possible.
<persia> Has to do with inode tracking and other internal complexities.
<ogra> the point is that there are no merges at all happening from anything after the package was uploaded
<ogra> packaging changes are done in a local branch, merged into trunk, then trunk is pulled and built with --split
<persia> Don't argue with me: even if you were capable of convincing me, it wouldn't help.  Talk to someone who understands UDD.
<ogra> UDD isnt involved at all atm
<persia> I just don't know enough to argue with you about this.
<ogra> i dont argue
<persia> Sorry: s/argue/debate/
<ogra> but you tell me the way that is used breaks with UDD
 * persia didn't intend any indication of emotional involvement
<ogra> and i tell you that UDD isnt involved in the current setup
<ogra> so i dont need to talk to UDD people yet :)
<persia> If UDD is used and inherited from upstream history, it becomes easy to cherrypick individual commits, and have those applied as distro-patches, etc.
<persia> Otherwise it's all manual manipulation.
<ogra> thats what it is atm
<persia> Since there *will* be a packaging branch, and since people *will* submit merge requests from their branches fixing bugs, it makes sense to try to make sure that things can be pulled/pushed back and forth.
<ogra> and there are no such things like distro patches given the fact that everything happens in trunk
<persia> Mind you, I'm a fan of manual manipulation.  I tend to use bzr as a way to track the patches I applied, rather than as a VCS, but still.
<ogra> i think upstream will change their mind if the first external distro shows up to use their stuff
<persia> ogra, Saying there are no distro patches implies you have control over the set of folks commiting branches and uploading, which isn't the case.
<ogra> and they have to keep distinct branches for ubuntu and "others"
<ogra> we do have that control atm
<ogra> it wont staxy that way and i didnt want to argue with upstream
<ogra> so i went with what they asked for
<persia> Anyway, talk to the UDD people, just so you see the points.  I can't explain why --split isn't preferred in a sensible way.
<ogra> k
<KC9SJQ> Hmm, update failed
<KC9SJQ> error building module pvr-omap4-kernel
<KC9SJQ> error: 'struct platform_device' declared inside parameter list
<KC9SJQ> any thoughts?
<rsalveti> KC9SJQ: what kernel are you using?
<KC9SJQ> I can't tell anymore, my board now won't boot.
<KC9SJQ> it should have been the official one from the ubuntu arm repositories
<KC9SJQ> I guess I'll have to rebuild the card
<KC9SJQ> It appears to start booting, and then gets stuck with some fsck info on the screen
<rsalveti> hm
<rsalveti> I know the pvr kernel module is compatible with our tree
<rsalveti> as the needed patches are applied
<rsalveti> if you're using a different one, then you need to make sure you get everything
<rsalveti> KC9SJQ: you can easily boot our default kernel by installing it at your sd card
<KC9SJQ> So far, I've been trying to do it via the idiot method, add a repository and update
<rsalveti> using qemu and chroot
<KC9SJQ> Kernel 2.6.35-903-omap4
<KC9SJQ> What is "your kernel" and how can I get it?
<persia> The linux-image-omap4 package should always depend on the latest omap4 kernel in Ubuntu.
<KC9SJQ> That should be the default, and I haven't changed it
<KC9SJQ> yeah, "linux-image-omap4 is already the newest version"
<KC9SJQ> I wonder if I'm missing the headers or something
<KC9SJQ> if the module is missing a unspecified dependancy
<persia> Odd.  It ought just work.
 * KC9SJQ shrungs
<KC9SJQ> does the omap-trunk ppa automatically rebuild on a particular basis?
<KC9SJQ> Maybe it's a legitimate bug which will be fixed soon
<persia> The PPA won't rebuild on a regular basis.  But some of the team that maintains the PPA might upload occasionally.
<persia> There's no way to file bugs on PPA packages, but you might be able to look at the name of the last uploader in the changelog, and find them in this channel.
<NCommander> persia: the reason was --split is braindead. Proper way to do it is pristine-tar
<persia> Right, which requires a tarball.  Anyway :)
<NCommander> persia: at some point I was going to through the 0.1 orig.tar.gz tarball I made via split into pristine-tar
<NCommander> woo
<NCommander> My build finally finished
 * NCommander thinks we have a compiler regression ...
#ubuntu-arm 2011-01-27
<hrw> did someone had keyboard-configuration hang on postinst on panda?
<hrw> sveinse: have a moment to discuss bug 683832?
<ubot2> Launchpad bug 683832 in gcc-4.5-armel-cross "gcc fails to cross compile Qt" [Undecided,Confirmed] https://launchpad.net/bugs/683832
<sveinse> Yes, I do
<hrw> sveinse: did you tried to compile in ARM mode?
<hrw> sveinse: Thumb2 is default
<sveinse> hrw, Yes, that works. However I'm if it has any performance impact
<hrw> sveinse: for Thumb2 mode you need to check ubuntu qt patches
<hrw> there were some for it iirc
<ogra> hrw, console-setup being broken is a known issue and not arm specific
<hrw> as this bug is a bug in Qt not in gcc
<hrw> ogra: ok, but it hangs only on arm for me so thats why I asked here
<ogra> no idea whats the workarouns
<hrw> ogra: rm /var/lib/dpkg/info/keyboard-configuration.postinst ;d
<ogra> if you upgrade to natty you get about 20 requests to configure your kbd
<sveinse> hrw, Yes. Qt does have some fixes for the thumb2 issue which I have also tried
<hrw> ogra: I am on natty
<sveinse> However it fails during early compilation. Let me see if I can find the error.
<hrw> and yes, console-setup is insane
<hrw> anyway... console-setup does not even lists my keyboards ;S
<ogra> hrw, when do you run the keyboard configuration then if you are on natty ?
<sveinse> hrw, The reason I'm mentioning this is I'm suspecting some difference between CSL and Linaro/ubuntu gcc
<ogra> the issue is that some value is missing in /etc/default/console-setup
<hrw> ogra: during "apt-get upgrade"
<ogra> ah, k
<hrw> sveinse: I think that csl defaults to -marm, ubuntu defaults to -mthumb
<ogra> well, thats the same i get when upgrading from maverick then
<ogra> hrw, i think its CHARMAP or CODESET being empty that causes this
<sveinse> hrw, but for your inital question -marm fixed the compilation as such
<hrw> ok
<sveinse> hrw, however my qt compilation relies on sysroot... I haven't figured out how to cross compile without it yet (nor has I investigated how to, so its on me)
<hrw> sveinse: "xapt install lib1 lib2 lib3" + configure + make
<sveinse> hrw, lib1 lib2 lib3 being the libxxx-dev build-depends to the software you're building, right?
<hrw> yes
<sveinse> elegant!
<hrw> works under natty, no idea about maverick
<ogra> hrw, why doesnt xapt-get build-dep <my target source package> work ?
<hrw> no idea?
<ogra> i.e. why doesnt it just stick to apt syntax
<hrw> good question
<hrw> probably fast written tool while waiting for multiarch
<ogra> heh
<lool> hrw: hang > that sounds like very very slow perl, I had that a while ago; maybe it's something else though
<hrw> lool: I just removed postinstall scripts
<hrw> lool: a4tech keyboard which I use do not require extra config. and is not listed in console-setup list anyway
<sveinse> hrw, if I check out qt on the master branch (where qt has fixed the thumb2 issue), the compilation fails in the compilation of the first file:
<sveinse> {standard input}: Assembler messages:
<sveinse> {standard input}:527: Error: thumb conditional instruction should be in IT block -- `strexeq r2,r5,[r6]'
<sveinse> {standard input}:528: Error: thumb conditional instruction should be in IT block -- `teqeq r2,#1'
<sveinse> Now, I dont know if this is related to GCC or if its a qt issue. Is this familiar?
<hrw> familiar
<hrw> moment
<hrw> check bug 675347
<ubot2> Launchpad bug 675347 in gcc-linaro "volatile int causes inline assembly build failure" [Medium,In progress] https://launchpad.net/bugs/675347
<hrw> no, it is rather bug 682742
<ubot2> Launchpad bug 682742 in thunderbird "thunderbird doesn't build on armel in natty (Error: thumb conditional instruction should be in IT block)" [High,Fix released] https://launchpad.net/bugs/682742
<hrw> hm.. not this too
<hrw> there was a bug about it...
<sveinse> :D
<hrw>  bug 490371
<ubot2> Launchpad bug 490371 in qt4-x11 "Atomic operations not safe for ARMv7,Thumb-2 and multicore" [Medium,In progress] https://launchpad.net/bugs/490371
<hrw> also bug 673085
<ubot2> Launchpad bug 673085 in qt4-x11 "Qt/KDE fails to build on ARM without implicit-it=thumb" [High,Fix released] https://launchpad.net/bugs/673085
<sveinse> What is the difference of armv6 and armv7? Because the qt fix in 490371 is agains armv6 it seems
<ogra> there is a new QT coming this week i was told
<ogra> that might fix some of these issues
<persia> Could check the beta, unless it's a fix since then
<sveinse> ogra, we're using git, not the official snapshots/releases
<sveinse> and the armel compilation issue is still present in the head of their branches
<hrw> sveinse: there were no optimizations for armv7 in Qt so armv6 ones are used or sth like that
<sveinse> I'm a little surprised that qt doesn't fix this, armel build for qt must surely be focus area for nokia
<ogra> erm, indeed, our package sets -march=armv6
<sveinse> I think I shall check out the qt source package to see if there are any other relevant qt patches for armel
<ogra> i think there are a bunch
<hrw> probably also check other projects for their patches
<ogra> yeah, checking OE usually makes sense for arm patches
<hrw> ogra: and vice versa ;D
<hrw> ogra: OE has Debian, Ubuntu, Gentoo, Fedora patches
<ogra> well, i wouldnt really care for the armv5 patches of debian or fedora
<persia> Actually, a lot of the armv5 patches *also* help with armv7 (which is part of why we have all of the Debian ones in Ubuntu)
<sveinse> hrw, Do I understand that I should be the one to close bug 683832 ?
<ubot2> Launchpad bug 683832 in gcc-4.5-armel-cross "gcc fails to cross compile Qt" [Undecided,Confirmed] https://launchpad.net/bugs/683832
<hrw> sveinse: I prefer you to be one, or I can mark it as invalid
<sveinse> hrw, done
<hrw> thx
<ogra> bug 684148
<ubot2> ogra: Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/684148)
<lool> LP #684148
<ubot2> Launchpad bug 684148 in unity-2d "[i18n] integrate gettext and use translations from Unity" [High,Triaged] https://launchpad.net/bugs/684148
<lool> Ah
<rsalveti> ogra: did you move the image script for omap4 to get the new x-loader from the new package?
<rsalveti> ogra: then we can request the removal of x-loader-omap4
<ogra> rsalveti, can you check if it actually ends up on the image ?
<ogra> (yes, i did change the scripts)
<rsalveti> ogra: sure, just wanted to ask you first, as I know you changed for omap3
<rsalveti> but don't know for omap4
<rsalveti> will check the logs
<ogra> i changed both at the same time
<rsalveti> cool, so we should be fine
<zul> hi guys i know you guys you did a lot of work in lucid to get arm working on likewise-open do you guys want to take another crack at it?
<apw> ogra, i've got some new kernels previews you might like to test: http://people.canonical.com/~apw/misc/arm/
<rsalveti> apw: why preview?
<rsalveti> what is special about this kernel?
<apw> preview as in the arm kernels take days to build in the archive so won't be in there for at least another 24 hours
<apw> so these are hand built for earlier access
<rsalveti> apw: oh, ok, cool
<rsalveti> will give it a try now
<rsalveti> weee, kernel panic while installing new deb hehe
 * rsalveti is trying again
<hrw> ogra: ac100 has sata internally used?
<ogra> no
<hrw> ogra: emmc storage?
<ogra> yep
<rsalveti> apw: eeek, not good
<hrw> thx ogra
<apw> rsalveti, s'up
<rsalveti> apw: http://paste.ubuntu.com/559064/
<rsalveti> warning but later on failed to start omapfb
<rsalveti> so, no display
<apw> rsalveti, not sure if the warning matters per-see
<apw> not having a framebuffer looks more annoying
<rsalveti> yeah, don't know if they are related atm, need to properly check the code
<apw> rsalveti, yeah
<rsalveti> well, at least some fun debugging time for later today
<apw> rsalveti, yeah :)  we have a couple of days (well two i guess) before we freeze for A2
<rsalveti> apw: ok, ping you back if I get any other news about it
<KC9SJQ> Hey all.
<apw> rsalveti, thanks ... i note there is exactly one commit between v2.6.37 and the tip for omapfb
<KC9SJQ> Going from ubuntu netbook version to ubuntu desktop is just a matter of removing ubuntu-netbook package and installing ubuntu-desktop, right?
<rsalveti> apw: cool, just checkout out the git tree
<apw> rsalveti, ok that warn_on is telling you you  have an erratum
<apw>         if (IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583)) {
<apw> rsalveti, any idea what graphics driver one should have?
<GrueMaster> Wow.  Firefox is using 172% of cpu on omap4, reporting an oem-config crash bug.
<apw> rsalveti, do you have the whole of the dmesg
<rsalveti> apw: not yet, checking the code atm
<rsalveti> apw: sure, 1 sec
<rsalveti> apw: http://paste.ubuntu.com/559074/
<rsalveti> [    0.147460] Unable to get DVI reset GPIO
<rsalveti> [    4.675109] regulator_init_complete: VPLL2: incomplete constraints, leaving on
<rsalveti> [    4.682983] regulator_init_complete: VDAC: incomplete constraints, leaving on
<apw> commit f8362d215549c66066f78e67c033dd370ae50322
<apw> Author: Koen Kooi <koen@beagleboard.org>
<apw> Date:   Tue Jan 11 17:13:36 2011 +0000
<apw>     omap3: beaglexm: fix DVI reset GPIO
<apw> rsalveti, th
<apw> rsalveti, though we _have_ that in the kerenls you are running
<apw> rsalveti, is this an XM or regular
<rsalveti> XM
<apw> rsalveti, i idly wonder if yours is on the other gpio number
<apw> rsalveti, the v2.6.37 based kernel worked on your xM didn't it?
<apw> rsalveti, diffing to there there is no mention of the 129 gpio in the code before
<rsalveti> apw: 37 worked fine
<apw> rsalveti, also i see that things like cpus and swap coming up in the dmesg, were you able to login to the machine remotely?  i suspect other than the display it came up
<rsalveti> apw: yup, login works fine
<apw> rsalveti, i think i might suggest that you try as a first stab making this bit always use 170
<apw> +       if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
<apw> +               beagle_dvi_device.reset_gpio = 129;
<apw> +       else
<apw> +               beagle_dvi_device.reset_gpio = 170;
<apw> as i think in 27 it always used 170 for all beagles
<apw>  static struct omap_dss_device beagle_dvi_device = {
<apw>         .type = OMAP_DISPLAY_TYPE_DPI,
<apw> [...]
<apw> -       .reset_gpio = 170,
<apw> was the old .27 code
<rsalveti> apw: at maverick we have this change, but differently
<rsalveti> but also using 129 for xm
<rsalveti> so it should be fine
<rsalveti> but weird that it worked fine for 37
<rsalveti> if it was only using 170
<apw> rsalveti, welll not necessarily
<apw> static int beagle_enable_dvi(struct omap_dss_device *dssdev)
<apw> {
<apw>         if (gpio_is_valid(dssdev->reset_gpio))
<apw>                 gpio_set_value(dssdev->reset_gpio, 1);
<apw>         return 0;
<apw> as the platform init does that
<rsalveti> on maverick the reset_gpio was struct was set as 170
<rsalveti> but then we had a check at beagle_display_init
<rsalveti> then then set it correctly if it's a xm
<rsalveti> *that then
<apw> but then that other check may occur in time before it or something
<rsalveti> so 37 probably had something similar
<apw> using the diff from v2.6.37 and the tip of natty 129 does not appear with a -
<apw> ie if it was there its still there
<apw> rsalveti, we might also consider putting the failed gpio pin number in the error on failure
<apw> might help know if its an init ordering issue
<apw> rsalveti, hrm how much did you miss i wonder
<rsalveti_> let me check the logs from bip
<rsalveti_> rebooting my host pc, got dead for some unknown reason
<rsalveti_> natty
<apw> hrm
<rsalveti_> still 37 :-)
<rsalveti_> but with btrfs
<apw> :) good
<apw> :( bad
<rsalveti_> yeah :-(
<apw> rsalveti_, so any oppinion as to what debug to shove in, and will you do it, or do you need me to make kernels
<rsalveti> don't worry, I can check this here
<rsalveti> and easily cross build the kernel
<apw> ok cool ... i guess we are at 'have h/w will debug stage' so i'll get out your hair
<rsalveti> ok, ping you back with more results later
<rsalveti> thanks anyway
<ogra> where do you have his hair ? in a drawer ?
 * ogra imagines apw with a rsalveti wig
<apw> rsalveti, :)  thanks
<apw> ogra, with mine yep :)
<ogra> *g*
<apw> rsalveti, do keep me in the loop as i will need to upload pretty soon for A2 as you know and i have some bits for aufs pending which i would batch up with yours :)
<rsalveti> apw: sure, np
<GrueMaster> Hey, maybe we can use these as buildd's.  Quad core Cortex A9, portable (small), what's not to like?  http://games.slashdot.org/story/11/01/27/1432205/Sony-Reveals-the-Next-Generation-Portable-Console
<prpplague> GrueMaster: hehe
<prpplague> GrueMaster: i suspect it isn't going to be quad core
<prpplague> GrueMaster: first versions probably with just be dual core
<GrueMaster> I just saw the article and the mention of quad core Cortex-A9.  I have no detailed specs yet, but haven't looked either.
<ClubPetey> hey all, I'm trying to get the 10.04-server-armel+omap image working with qemu (emulating a beagleboard).  I have it booting to the install script (where you select a language) but the keyboard doesn't work.  I ran a debian image just fine with the same emulator, so I'm starting to think it's not the qemu build.Anyone experience this before?
 * apw wonders how rsalveti is getting on :)
<rsalveti> apw: waiting a build to finish, to properly check what's happening, my host seems quite unstable atm :-(
<rsalveti> had to reboot 2 times already
<rsalveti> apw: how is the 38 testing going?
 * rsalveti thinking about changing to 38
<rsalveti> but heard people were facing lots of issues with it
<apw> rsalveti, ahh how long does it takeing
<apw> my machines here are running .38 based kernels, previews like the arm ones, but i'd not say i was stressing them
<rsalveti> apw: hm, what are you running at your desktop?
<rsalveti> 38?
<apw> this machine is back furhter than that
<apw> my other smaller boxses are on the preview though
<apw> running unity, when it works
<rsalveti> hehehe
<rsalveti> mine is very broken
<rsalveti> using classic desktop atm, with metacity instead of compiz 2d
<apw> so this machine is all uptodate, including the upcoming kernel
<apw> and its holding together mostly, well as long as you remeber to right click to get the menus working
<rsalveti> hehe, cool, maybe will update mine later on
<rsalveti> today
<apw> but i've not got the guts to put it on my bigger machine as i am not yet ready for the paradigm shift
<apw> just about to do an update on a desktop
<rsalveti> something to check later is why it's powering DVI down using 170 as a hardcoded value at omap3_beagle_init
<rsalveti> while when starting up it checks if it's running xm or not, and select the proper gpio pin
<rsalveti> don't know what is connected to 170 at xm
<rsalveti> need to check the hw docs
<apw> rsalveti, this bit you mean:
<apw>         omap_mux_init_gpio(170, OMAP_PIN_INPUT);
<apw>         gpio_request(170, "DVI_nPD");
<apw>         /* REVISIT leave DVI powered down until it's needed ... */
<apw>         gpio_direction_output(170, true);
<apw> looks like it should be using the reset_gpio as well indeed
<rsalveti> yup
<apw> maybe... hard to tell it does use different descriptions
<apw> as if 170 is power and 129 is reset on xm, but both on !xm
<apw> all depends on semantics i guess
<apw> the docs sounds like ones freind here for sure
<apw> rsalveti, the below sounds bad:
<apw> "Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
<apw> GPIOs that have already been claimed with that call."
<apw> as far as i can tell for !xm we would request 170 twice and violate that
<apw> which would lead to that error ...
<rsalveti> hm, makes sense
<rsalveti> on maverick this was remove with commit 8c3818913431c5ae62a7e56a38d38c4ca81ee4a2
<rsalveti> let me check 37
<apw> rsalveti, oh yeah its removed ... hrm
 * rsalveti is still waiting his build to finish
<apw> rsalveti, how long do they take ?
<rsalveti> this is the first one, then I can just make what changed
<rsalveti> but 30 min probably
<rsalveti> apw: if it's faster for you, can you try removing that out and build it again?
<apw> rsalveti, about the same once i've pushed it so you can get to it
<apw>         omap_mux_init_gpio(170, OMAP_PIN_INPUT);
<apw>         gpio_request(170, "DVI_nPD");
<apw>         /* REVISIT leave DVI powered down until it's needed ... */
<apw>         gpio_direction_output(170, true);
<apw> seems it was in there for .37
<apw> which is perplexing
<rsalveti> hm, not from one I'm seeing here
<rsalveti> from Ubuntu-2.6.37-9.22
<rsalveti> let me check again
<rsalveti> git show Ubuntu-2.6.37-9.22:arch/arm/mach-omap2/board-omap3beagle.c
<rsalveti> sounds fine
<apw> yeah
<apw> yep clearly new...
<apw> shall i build without that in parallel ?
<rsalveti> apw: sure
<apw> rsalveti, i can see how that got lost, as we dropped all the omap stuff for XM as it was coming down in spades from upstream ... clearly not all of it
<rsalveti> apw: yup, the same patch that changes to use 129 is the one who removes this piece
<rsalveti> and you got a conflict and probably just removed the patch
<apw> yep thats what i would have done, there is clearly stuff in there saying "added support for Xm" so it would be a simple choice to drop
<apw> rsalveti, heres hoping thats the main issue
<apw> if i had been diffing to a sensible place for .37 i'd have noticed that too ... silly me
<apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre5_armel.deb-2
<apw> rsalveti, stupidly i made it with the same pre5 name ...
<rsalveti> apw: awesome, mine is still building =\
<apw> rsalveti, just tried a new way to copy it ... saved self 15 mins
<apw> avoided a tortuos upload over my adsl
<rsalveti> nice
<apw> rsalveti, just tell me it works :)
<rsalveti> we'll see :-)
<apw> i suspect the testing will be as slow as the build :)  its never easy to get a kernel onto one of those
<rsalveti> yeah, very slow sd card
<apw> "oh no you want to <pause> save a lot <pause> of files to <pause> me ..."
<rsalveti> argh, panic while installing
<rsalveti> rebooting and trying again
<apw> rsalveti, noo
 * apw drums his fingers in agitation
<rsalveti> Linux version 2.6.38-1-omap (root@tangerine) (gcc version 4.5.2 (Ubuntu/Linaro 4.5.1-10ubuntu3) ) #27~pre5 Thu Jan 27 18:53:05 UTC 2011 (Ubuntu 2.6.38-1.27~pre5-omap 2.6.38-rc2)
<rsalveti> still same issue
<apw> thats the rigth timestamp
<apw> poop
<rsalveti> that was the only thing that is actually different at the board-omap3beagle.c from our 37 to mainline
<apw> i would say i tend to concur, there is some odd ordering, but nothing 100% different
<apw> s/odd/difference in
<rsalveti> yeah
<rsalveti> oh god, trashed my sd card :-(
<rsalveti> too many kernel panics while booting
<apw> rsalveti, oh
<apw> -       if (cpu_is_omap3630())
<apw> -               beagle_dvi_device.reset_gpio = 129;
<apw> -       else
<apw> -               beagle_dvi_device.reset_gpio = 170;
<apw> -
<apw>         r = gpio_request(beagle_dvi_device.reset_gpio, "DVI reset");
<apw> is that difference significant
<rsalveti> 37 has an issue with the mmc driver it seems, so sometimes giving i/o errors all around
<rsalveti> but the same logic is applied later on
<apw> yeah but note, that the line after the context uses it
<apw> so is the other place its added, earlier in execution
<rsalveti> beagle_display_init is the last function from omap3_beagle_init
<rsalveti> beagle_twl_gpio_setup is a .setup from beagle_gpio_data
<rsalveti> that gets registered at omap3_beagle_i2c_init
<apw> +       if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
<rsalveti> and probably calls the .setup
<apw> -       if (cpu_is_omap3630())
<apw> and we know those are the synonymous
<rsalveti> that could be another diff, but that would break a lot of stuff for xm
<apw> yeah tend to agree
<rsalveti> only if .setup is not being called before beagle_display_init
<rsalveti> but need to check the callbacks
<apw> rsalveti, perhaps i should just print it in the routine
<rsalveti> apw: that would do it
<apw> you got a testable system if i slam in some dbg ?
<rsalveti> sure
<rsalveti> put some printks all around and lets see
<GrueMaster> Out of curiosity, when will we be seeing a new omap4 kernel?
<apw> rsalveti, ok building a new one with loads of output
<apw> GrueMaster, thats in ti's hands
<apw> (isn't it?)
<GrueMaster> Ah, ok.
<rsalveti> GrueMaster: yup, ti released a new version, but not that well tested
<rsalveti> as I reported at the meeting today
<rsalveti> so they are waiting to add support for es2.2
<GrueMaster> You expect me to actually be awake for that meeting?
<rsalveti> then will probably request us to update it
<rsalveti> :-)
<apw> rsalveti, what was it based on ?
<rsalveti> now for the 38 is a completely different history
<rsalveti> apw: 35 still
<apw> .35 ? thats ... erm ... old
<rsalveti> hehehe
<rsalveti> that's.... ermm.... ti?
<rsalveti> they are building a landing team at linaro to care about pushing stuff upstream
<apw> rsalveti, well thats something ... wonder what chance we have of having a kernel in time ...
<rsalveti> yeah, that's what worries me the most
<apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre6a_armel.deb
<rsalveti> let me try
 * apw whips rsalveti to get a result :)
<apw> rsalveti, there will be much APW noise
<rsalveti> :-)
<apw> rsalveti, ok have to run to the shop to get some food in ... back in 20
<rsalveti> apw: ok
<rsalveti> apw: eeek: APW: beagle_display_init: reset_gpio=-22
<rsalveti> the function that initializes reset_gpio is called later on
<rsalveti> so that's why
<rsalveti> so we need a patch to move this as before and also removing the settings for the hardcoded gpio
<rsalveti> the 170 one
<rsalveti> apw: http://paste.ubuntu.com/559192/ will probably be enough
<rsalveti> just need to build and test
<GrueMaster> janimo_: can bug 697382 be reproduced on other arches now?
<ubot2> Launchpad bug 697382 in pyside "ftbfs on armel" [Undecided,New] https://launchpad.net/bugs/697382
<rsalveti> renatofilho: ^ :P
<janimo_> GrueMaster, yes, it fauils on x86 too
<janimo_> it is a cmake isseu from what I can tell
<GrueMaster> Ok, will tag appropriately.
<janimo_> pyside 1.0 beta4 is out but still not in debian too see if it fixes it
<janimo_> I think doko's archive rebuild should point out if pyside fails on all archs now (if it inlcudes universe)
<renatofilho> GrueMaster, this was fixed some time ago on pyside check bug: http://bugs.openbossa.org/show_bug.cgi?id=415
<ubot2> bugs.openbossa.org bug 415 in PySide "phonon bindings does not build" [Major,Closed: fixed]
<GrueMaster> Ok.  Hasn't hit the pool yet then.
<rsalveti> renatofilho: cool, thanks :-)
<rsalveti> apw: I'm firing up another build, but it'll probably take longer than yours
<rsalveti> apw: can you try rebuilding your deb with the supposed fixes when you're back?
<apw> rsalveti, just back
<apw> rsalveti, ok build in progress
<apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.27~pre6b_armel.deb
 * apw pokes rsalveti 
<rsalveti> apw: sorry, getting something to eat
<rsalveti> installing
<apw> heh no worries
<rsalveti> apw: that error is gone, but still no display
<rsalveti> one less bug at least
<rsalveti> let me get the dmesg for you
<apw> rsalveti, ok cool
<rsalveti> apw: http://paste.ubuntu.com/559224/
<rsalveti> then same messages for omapfb
<rsalveti> hm, I don't like having a warning for an erratum
<rsalveti> just a kernel message saying it would be enough
<rsalveti> let me put more debug at omapfb
<rsalveti> seems it's not getting a proper dss device
<rsalveti> and I just noticed that we have 18 patches against dss at l-o
<apw> yeah WARN is dumb as it will trigger apport etc for no reasdn
<apw> rsalveti, worth looking indeed
<apw> rsalveti, what timezone you in?
<rsalveti> apw: utc-2
<apw> so its near midnight ?
<rsalveti> almost 8 pm
<apw> hrm ok :)  thinking its food time here, but i can provide build services in the AM if thats helpful
<rsalveti> apw: sure, don't worry :-)
<rsalveti> my new build just finished, so it should be ok now
<apw> excellent, speedyier once one is done
<apw> i'll catch you in the morning see how it all went
<rsalveti> ok, thanks!
<GrueMaster> rsalveti: Have you seen the latest patch link attached to the panda MAC bug?  bug 673504
<ubot2> Launchpad bug 673504 in linux-ti-omap4 "Pandaboard chooses a new IP address on each boot" [High,Fix committed] https://launchpad.net/bugs/673504
<GrueMaster> THis would really be helpful for us and for the buildd pool (if it ever gets online).
<rsalveti> GrueMaster: yup, sounds fine, just didn't follow if it's upstream or not already
<Neko> hey guys, any reason why linux-headers does not pull in the plat-mxc/include/* stuff into the headers here?
<Neko> I'm just using make-kpkg and wondering if there is some clever overlay trick to it
<apw> Neko, probabally an oversite as things have moved over time, if there is something needed in there then get a bug filed saying they are missing
<Neko> well what I'd like to do is file a bug and ship a patch at the same time
<Neko> but I am having trouble working out how I'd detect the scenario
<Neko> I can't tell what machine the kernel is built for...
<Neko> only the arch
<Neko> it seems like the whole kernel thing just never ever worked for any arm platforms and this would affect arm on debian too
<Neko> or worse, linux kernel doesn't do it
<rcn-ee> Hey Neko in 2.6.38-rc's the mainline deb-pkg now generates linux-headers, but like make-kpkg it too only seems to generate x86 stuff..
#ubuntu-arm 2011-01-28
<Neko> it copies the asm stuff right but it seems any platform with a plat- and a mach- doesnt copyor link the plat-blah/include stuff into place
<Neko> hmn doesn't do it for omap either
<Neko> kernel bugggggg
<persia> Indeed.  This may explain a number of fail-to-build module reports on armel installs.
<Neko> how would you work out what the parent plat-???? directory is to the mach you're building for though, to fetch the right headers
<persia> Well, linux-image-${target} could depend on linux-headers-${target}, and one could encode the requirements in the specific dependencies for linux-headers-${target} with a lookup table in the package source.  That said, doing it without the packaging sugar would be lots harder.
<Neko> that assumes the target is directly related to the machine
<persia> ah, but ${target} might support several machines?
<Neko> all scripts/headers.sh knows is arch, srctree, and what kind of header build it's doing (check or install)
<Neko> umm no
<Neko> but what if the target is, like in Ubuntu -generic or -server
<Neko> right now there's fsl-imx51 but what about fsl-imx53.. or does it get changed to fsl-mx5?
<Neko> that still doesn't give you a direct indication of the need for the includes from plat-mxc
<persia> They're just strings, and the semantic meaning is weak.
<Neko> isn't what what I am saying? :D
<Neko> I don't want the fix to be a case block in a bash script
<persia> Sure, but in practice, we assign semantics.  For example, the -omap kernels only work on omap3
<Neko> what about -omap4
<persia> makefile, but yeah, there ought be a better way :)
<Neko> seperate kernel?
<persia> Currently, yes.
<persia> If someone is able to make a kernel that boots both cleanly with full support, I'd expect that there would be available headers will the same level of support.
<Neko> currently make headers_install calls scripts/headers.sh arm arm install
<persia> So if someone created -generic for armel, I'd expect that to work for nearly every device (this is probably some years off)
<Neko> or something similar
<Neko> makefile doesn't do much, in the end there's a perl script too
<persia> Most of the packaging sugar is managed by debian/rules, which is traditionally a makefile, which is why I mention make.
<Neko> loops over files and unifdefs them
<Neko> debian headers rules from kernel-package makes some clever changes but it still does not handle it
<Neko> IMO it's a kernel bug not a packaging bug
<persia> Indeed: that's the bug.
<Neko> it's not a packaging bug
<Neko> make headers_install needs to do this as well or the headers are useless
<persia> I agree it's a kernel bug.  It could be masked with a packaging-class fix, but fixing it in the kernel would be vastly superior
<Neko> mach/memory.h comes from plat- on 10 subarches of arm
<Neko> you can't build libc without that file
<Neko> there are google pages for hacks to fix bionic compilation with broken headers like that
<rsalveti> apw: patches sent to our kernel team and linux-omap
<rsalveti> apw: finally working at normal beagle and xM
<rsalveti> spent a lot more time building and testing than actually coding
<rsalveti> recreate the rootfs, etc
<rsalveti> but should be fine now, I'm able to see the console and X11
<ka6sox> rsalveti, what should I expect the rndis ethernet device to show up as in maverick?
<sanket> hii
<bagge> hi :) I'm about to install ubuntu-arm on my phone, but I'm wondering about something... I can only get packages that are made for ARM right?
<Neko> bagge, if you have to ask that I'd say you're not ready to install ubuntu on a phone :D
<bagge> Neko: I'll have to crash my phone to learn ;)
<ka6sox> bagge which phone?
<bagge> ka6sox xperia x10 mini pro (hehe)
<ka6sox> Good Luck...I have no experience with that.
<ogra> hrw, console-setup (1.57ubuntu5) was just uploaded, that should solve all hangs of the keyboard stuff on upgrade/dist-upgrade and install
<hrw> cool
<apw_> rsalveti: yo ... saw your patches, have some kernels building with them applied, will you be about in about half hour to test them?
<rsalveti> apw: yup, lunch is in one hour :-)
<rsalveti> apw_: ^
<apw_> rsalveti: ok cool
<apw_> will get it to you before then :)
<rsalveti> :-)
 * ogra wornders if you can actually make sure that with all these food things around these kernel patches since yesterday you dont leave breadcrumbs and fatty finger prints on the package :)
<ogra> every time i see you guys talking about these patches one of you is busy with food stuff :)
<rsalveti> :P
<apw_> ogra: the kernel always has a bunch of fingerprints all over it :)
<ogra> heh
<apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-versatile_2.6.38-1.28~pre1_armel.deb
<apw> if you could do the honours
<rsalveti> downloading :-)
<rsalveti> apw: the name versatile is right?
<apw> rsalveti, no i've pushed the wrong one cause i am stupid
<rsalveti> ok :-)
<apw> be about 5 mins ... bottom
<rsalveti> np
<apw> rsalveti, http://people.canonical.com/~apw/misc/arm/linux-image-2.6.38-1-omap_2.6.38-1.28~pre1_armel.deb
<apw> silly apw
<rsalveti> ok, installing
<apw> rsalveti, how they looking?
<rsalveti> apw: and we have a winner, using normal desktop :-)
<rsalveti> apw: and tim already applied at master-next
<apw> rsalveti, heh yeah he and i are duplicating work today :)
<rsalveti> :-)
<rsalveti> ok, sounds good timing for lunch
<apw> rsalveti, yep, you are done, thanks muchly
<rsalveti> apw: ping me if you want any test or have any update on the omap side
<apw> rsalveti, will do indeed, i expect there will be a final final a2 kernel on monday to test
<rsalveti> apw: cool
<rsalveti> and it seems that it'll work fine, at least it didn't explode at my face yet
<rsalveti> apw: do you want the patch to remove the WARN_ONCE from the erratum?
<rsalveti> we could just use a simple printk
<rsalveti> I have it here if you think it's worthy
<rsalveti> apw: http://rsalveti.net/tmp/0001-OMAP3630-PM-don-t-warn-the-user-with-a-trace-in-case.patch
<apw> rsalveti, i think it is worth while, send out to the kernel-team list, i recon
<rsalveti> apw: ok, will do
<apw> ogra, i am not sure what you mean about srus being pushed out by securty.  we h
<apw> we haven't done that for the last two months at least
<ogra> apw, well it happens occasionally i dont think its currently the issue
<apw> ogra, ok so what is the issue
<ogra> none, its just that not all SRUs have been tested yet
<ogra>  * Maverick kernel SRU testing is still in progress
<ogra> thats all i said
<apw> <ogra> and we wlao often clash with security uploads
<apw> <ogra> which force the SRU out of -updates
<apw> well you said that which prompted my question
<apw> i think everyone would have taken that as the reason the testing was not done from the context
<ogra> hmm, i didnt mean it like that
<ogra> though its often enough the cause
<ogra> not thins time though
<apw> well its going to be rare now as most security is going in the hopper with the rest of the updates
<apw> as long as we don't have a process issue between us i am happy
<ogra> i think we dont
<ogra> but that would be a question for GrueMaster
<ogra> since he is the one who suffered from it in the past
<ogra> i really didnt mean to blame anyone i just tried to quieten marjo :P
<ogra> sorry if it came across that way
<apw> ogra, no harm no foul, just wanted to make sure we'd not missed something, ta
<ogra> (the phrase above is always in my report since it is nearly always true that there are some SRUs to test)
<ogra> *nobody* ever asked about it :P
<apw> ogra, yep and we are making more now-a-days so it'll be even more true
 * GrueMaster hears his name being mentioned.
<GrueMaster> what kernel in maverick still needs testing?
<GrueMaster> ogra: apw ^^^
<rsalveti> ogra: both images are using the new x-loader package, so we should be ok to remove the x-loader-omap4 one
<ogra> rsalveti, awesome
<ogra> GrueMaster, dunno, i just saw several uploads this week and assumed some would still need testing
<GrueMaster> ogra: I haven't seen anything for omap4.  Until Monday, I can't test omap3 stuff easily, unless I build a stripped down image for my beagle.  Too painful otherwise.
<ogra> GrueMaster, right, i was referring to omap3 rather
<GrueMaster> Well, unless there is a specific patch for omap3 in the main kernel, I'm not too worried.  Security updates usually get pushed through without my help.  It is specific omap3 bug fixes I usually have issues getting tested on time.
#ubuntu-arm 2011-01-29
<lilstevie> is anyone about who knows about troubleshooting initramfs :p
<lool> lilstevie: grep maybe_break /usr/share/initramfs-tools -r
<lool> lilstevie: pass break=top, break=modules etc. on your cmdline, and you're good to debug
<lool> lilstevie: Now you know as much as I do  :-)
<lilstevie> haha
<lilstevie> i actually get stuck at the command line
<lilstevie> and i have no input devices
<lilstevie> i need to find out where my rootfs lays under ubuntus /dev structure :p
<ogra> lilstevie, make sure udev runs or that you have support for your input devices compiled in
<ogra> is that an ubuntu kernel or your own build
<lilstevie> i have nil in the sense of input devices without touch
<lilstevie> and it is a hybrid kern
<ogra> hybrid ??
<lilstevie> well parts of it are for the device, minus the android stuff
<ogra> have you compiled it yourself ?
<lilstevie> yes
<ogra> did you make sure all options needed for a recent udev are enabled (i.e. signalfd comes to mind)
<lilstevie> no i didnt
<ogra> k, that should be the first step you take
<ogra> then make sure that all your modules for your input devices are in your rootfs before rolling the initrd
<ogra> they should end up in the initrd
<ogra> and be automatically loaded by udev
<lilstevie> all of the drivers modules are in place, but i have a lack of input without a touch keyboard
<ogra> ah
<ogra> how about usb ?
<ogra> can you attach a usb kbd ?
<lilstevie> no
<ogra> hmm, tricky
<lilstevie> there is a keyboard attachment but i dont have one myself
<ogra> then i assume its guesswork for the root= cmdline option
<lilstevie> under the android mapping it is /dev/block/mmcblk0p3
<lilstevie> but i have no idea here :/
<ogra> well, if its the same kernel it might end up with the same name
<ogra> else i would just try /dev/mmcblk0p3
<lilstevie> ok
<lilstevie> so are there any specific kernel options that i should be looking for to enable udev support
<ogra> google for it, i dont know all of them from the top of my head
<ogra> signalfd is definitely one
<ogra> syvipc and ipc_ns too i think
<ogra> and sysvipc_sysctl
<ogra> google might be more precise though
 * ogra is out for the day
<lilstevie> later ogra
<lilstevie> and thanks
<lilstevie> i had 1 option in the kernel config that would have prevented udev working
<lool> lilstevie: Which one?
<lilstevie> depreciated hotplug manager
<TheUni> robbiew: ping
<TheUni> robbiew:  mind setting 458637 to verified when you get a chance? It's blocking our bugfix release for xbmc live
#ubuntu-arm 2011-01-30
<lilstevie> ok so i am getting REASON=No init found. Try passing init= bootarg. PS1=(initramfs) /bin/sh -i
<lilstevie> is this because the rootfs is not being mounted or something else that i am missing
<NTU> hey guys
<NTU> where is the source to ubuntu arm packages?
<lool> NTU: It's the same source as Ubuntu packages
<lool> NTU: apt-get source <package name>
<NTU> Ah. And the configure options are the same too? I'm not on an ubuntu system, just wanted to dig through myself and see
<NTU> but if they arent posted on a public server in tarball format, ill just go..
<lool> NTU: Usually they are the same, but debian/rules of each package can decide to use specific options on arm
<NTU> thanks
<lool> "Canonical like.. the Microsoft of Linux."
<lool> I see
<lool> (NTU's /quit message)
<lilstevie> :/
<armin76> haha
<robbiew> TheUni: I cannot set to verified until someone verifies it on 10.04
<TheUni> robbiew: ah, apologies, i assumed that last verification was lucid
<robbiew> TheUni: no worries...heh, if I had a windows box, I'd verify it myself ;)
<TheUni> robbiew: i'm trying hard to get someone to verify.. i don't have a win7 machine around
<mikkelbg> Hi, i'm trying to install ubuntu on my BeagleBoard xM but when using the setup_card.sh script i get the error: Error: Could not stat device /dev/mmcblk0 - No such file or directory.
<mikkelbg> I can't mount the linux partition
<mikkelbg> could that be a problem with the sd card reader?
#ubuntu-arm 2012-01-23
<rbasak> ppisati, infinity: another regression in linux-ti-omap4 I think. panda fails to boot.
<ppisati> rbasak: do you have pvr-omap4 installed?
<rbasak> ppisati: don't think so. I'm doing a preseeded install. The installer runs but then the kernel hangs after reboot
<rbasak> ppisati: no output after "Uncompressing Linux... done, booting the kernel."
<rbasak> ppisati: looking at my proxy cache logs, the installer retrieved linux-image-omap4_3.2.0.1404.4_armhf.deb but nothing matching pvr-omap4.
<ppisati> i know there's a problem with that dkms module
<ppisati> but without it works here
<rbasak> I'm not doing anything special at all
<rbasak> netboot, preseed, install onto panda with external usb disk
<ppisati> what's the content of your boot.scr?
<ppisati> rbasak: ^^
<rbasak> ppisati: once installed?
<rbasak> fatload mmc 0:1 0x80000000 uImage
<rbasak> fatload mmc 0:1 0x81600000 uInitrd
<rbasak> setenv bootargs root=UUID=62d8a5de-83eb-470c-9de6-31eed3621672 ro quiet splash
<rbasak> bootm 0x80000000 0x81600000
<rbasak> fi
<ppisati> there's no console stuff, no wonder you don't see any output
<ppisati> wait
<ppisati> get rid of "quiet splash"
<ppisati> and add "console=tty0 console=ttyO2,115200n"
<ppisati> and if i would be in you, i would add "rootwait" too
<rbasak> well, it used to work
<rbasak> the installer installed that boot.scr
<rbasak> is this something that's broken in the installer?
<ppisati> no no
<ppisati> it's just that if you don't have the "console=" args
<ppisati> the only thing you see is the "Uncompressing Linux... done, booting the kernel."
<ppisati> until you get a console
<ppisati> but since it's a fresh installation, there's no ttyO2.conf
<ppisati> and thus you don't even have the console
<rbasak> I understand why you're saying that I don't have a console
<ppisati> and if X doens't work for some reason, you think tghe kernel hanged somewhere
<rbasak> Oh I see
<rbasak> So not necessarily a kernel issue until I add the console
<rbasak> I'll do that, thanks
<ppisati> yep
<ppisati> here are all the steps i do after a fresh install:
<ppisati> modify boot.scr: delete "quiet splash", and add "console=tty0 console=ttyO2,115200n rootwait"
<ppisati> mount the / and add a ttyO2.conf in /etc/init
<rbasak> That part was definitely there last week
<ppisati> then reboot and see what happens
<ppisati> anyway, try to add that stuff and tell me how it goes
<ppisati> FWIW:
<ppisati> flag@flag-desktop:~$ uname -a
<ppisati> Linux flag-desktop 3.2.0-1404-omap4 #6-Ubuntu SMP PREEMPT Thu Jan 19 14:31:43 UTC 2012 armv7l armv7l armv7l GNU/Linux
<ppisati> this is my panda
<ppisati> i've a dentisti appointment, i'll be back in an hour or so
<rbasak> ppisati: http://paste.ubuntu.com/814182/
<rbasak> ppisati: OK, I'll work on something else in the meantime
<rbasak> ppisati: (this is with http://paste.ubuntu.com/814183/)
<victorp> ing
<ogra_> morn :)
<highvoltage> ogera!
<ogra_> hey highvoltage
<ppisati> rbasak: could you try with this one "ro rootwait elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 root=UUID=$YOURUUIDHERE fixrtc console=tty0 console=ttyO2,115200n8"
<highvoltage> ogra_: how are things?
<ppisati> rbasak: now i'm leaving for real
<ogra_> highvoltage, fine, thanks, and for you ?
<highvoltage> ogra_: doing good
<ppisati> rbasak: did you try with the args i pasted above?
<ppisati> rbasak: ping me when you around
<rbasak> ppisati: sorry, been afk sorting out a wiring harness for my pandas
<rbasak> ppisati: your new args work
<ppisati> rbasak: so you got it working, right?
<rbasak> ppisati: yes, it booted with those args
<ppisati> rbasak: actually the problem is somewhere else
<ppisati> rbasak: it's in the CMA
<rbasak> CMA?
<ppisati> yep
<ppisati> your dmesg said:
<ppisati> DMA: failed to allocate 256 KiB pool for atomic coherent allocation
<ppisati> while i guess now it succeded to allocate that pool
<rbasak> ppisati, you've lost me. What's the CMA? From my point of view, a netboot install of Ubuntu Server on ARM is currently broken, but was working in last week's precise. I don't understand which component is broken. Who do I need to speak to?
<ppisati> rbasak: don't worry, i was just spoeaking with myself
<ppisati> rbasak: did you have the same bootargs last week?
<rbasak> I don't know. I have whatever bootargs the installer gives me.
<uncle_fungus> does the current ubuntu-core armel installation work? I've installed it into a chroot and installing gnome-core with apt-get trashes the chrooted installation (most commands segfault)
<ppisati> rbasak: can you open a bug on lp?
<rbasak> ppisati: sure, against which package? linux-ti-omap4?
<ppisati> rbasak: yep
<rbasak> ppisati: bug 920511 - thanks
<ubot2> Launchpad bug 920511 in linux-ti-omap4 "Regression: netinst on panda armhf fails" [Undecided,New] https://launchpad.net/bugs/920511
<rbasak> ppisati: fwiw, as far as I can determine, boot args have not changed since last week
<ppisati> ok
<GrueMaster> rbasak: I'm trying it here.  Had to recover my mirror (crashed over the weekend).
<GrueMaster> I do see some of the netinstall parameters have changed it looks like.  My systems are now prompting for hostname (they used to get set automatically by dhcp).
<GrueMaster> rbasak: This may take a little longer than I thought.  My mirror server crapped out over the weekend for no documented reason, now it is taking forever to resync with ports.u.c.
 * ppisati -> EOD
<GrueMaster> rbasak: I can fully reproduce this kernel issue on netinstall and on preinstalled images.  The issue is kernel related, and has nothing to do with netinstall (although your lack of serial console is odd - maybe preseed related as mine works).
<rbasak> thanks GrueMaster
 * neels having endless problems with ubuntu 11.04 & 11.10  on beagleboard xM Rev. C -- no usb (and hence no ethernet)
<GrueMaster> neels: Is the usb interface not coming up at all?  What does lsusb produce?
<neels> it shows two usb hubs
<GrueMaster> Nothing else?
<neels> in the boot I get:  Uncompressing Linux... done, booting the kernel.
<neels> [    8.114105] hub 1-0:1.0: unable to enumerate USB device on port 2
<neels> I'll have a screenshot in a minute
<GrueMaster> How are you powering the board?
<neels> AC adapter
<neels> with angstrom, everything works -- the factory supplied angstrom I mean
<GrueMaster> Ok.  I have seen this problem when using the mini-usb port to power.
<neels> I have seen *only* problems when using the mini-usb to power :)
<GrueMaster> I think there was an issue with Natty support on rev c boards (didn't exist).  I know there have been some issues with u-boot on oneiric.
<GrueMaster> Unfortunately, I only have a Rev B board, so I see different issues (mainly enet won't link unless I unplug from the network and wait for ~10 seconds).
<GrueMaster> do you have any other devices on the usb port?
<neels> I was trying my SD card reader, but nothing happens
<neels> lsusb stays unchanged and everything.
<leshaste> is there a list of what is missing for ubuntu arm that you would get in the mainstream ubuntu?
<leshaste> specifically.. is all of texlive available?
<GrueMaster> Not really.  most everything should just be there.
<GrueMaster> Check ports.ubuntu.com for specific packages.  I'm in the middle of an install and can't interrupt it (otherwise I would easily check).
<leshaste> ok thanks
<leshaste> GrueMaster: it's all very mysterious :)
<GrueMaster> Just checked Oneiric.  Lots of texlive packages there.
<GrueMaster> what may be missing, I wouldn't know.
<leshaste> curious arm is not mentioned in http://www.tug.org/texlive/build.html
<leshaste> at the bottom
<infinity> leshaste: Upstreams often don't mention specific arch support.
<GrueMaster> Because we are not "volunteer builders".
<infinity> leshaste: But that doesn't stop Debian from supporting almost everything on 13 arches. :P
<GrueMaster> We're a distro.
<leshaste> infinity: :)
<leshaste> GrueMaster: true but I assume the porting of texlive was non-triviak
<leshaste> non-trivial
<infinity> I don't see why it would be.
<infinity> It's pure C, IIRC.
<leshaste> to give you an indication.. it is said to be "impossible" to port it to android or the ipad
<leshaste> infinity: apparently not
<infinity> Neither Android nor iOS provide a full stdc.
<infinity> (And there's also the question of at what "level" people are referring to porting it.  As an "app", it would need to be Javaish for Android, and ObjC for iOS)
<leshaste> stdc == standard C compiler?
<infinity> leshaste: Standard C library, actually.
<infinity> leshaste: Anyhow, if it runs on a few diffrent unixes, on 64 and 32 bit, on big and little endian, and on Win32 to boot, I'd posit that it's incredibly portable C.
<infinity> leshaste: But, all of those still require a proper libc to be present.
<leshaste> you know I am not sure what  (la)tex is written in.. it used to be in WEB
<leshaste> "nt
<leshaste> The original source code for the current TeX software is written in WEB, a mixture of documentation written in TeX and a Pascal subset in order to ensure portability"
<leshaste> ". As a result, TeX has been ported to almost all operating systems, usually by using the web2c program to convert the source code into C instead of directly compiling the Pascal code."
<leshaste> well there you go :)
<infinity> Yeah.  Hence, C in the end. :)
<leshaste> infinity: http://forum.xda-developers.com/showthread.php?t=1299962 :)
<leshaste> infinity: maybe have glibc just made the job a whole lot easier
<infinity> leshaste: Err, when I talk about "porting to Android", I refer to running things on consumer devices.
<infinity> leshaste: Obviously people can do whatever crazy they want on their own images and builds.
<leshaste> infinity: yes fair enough :)
<infinity> leshaste: (Since, yes, it's just Linux at the syscall layer, mostly)
<leshaste> infinity:  I wonder what the best route would be to port texlive
<infinity> Well, what's the goal?
<infinity> If it's just to say "I run texline on an Android kernel", I can do that right now, in about 20 seconds.
<infinity> If it's to say "I can install texlive bits and use them on a phone with a factory image", that's a whole different ball of wax.
<leshaste> infinity:  it is to have latex working on an android tablet
<leshaste> infinity: it's a silly idea on a phone :)
<infinity> leshaste: If it's rooted, then you just need to build everything it depends on, and install it.  Or, just build is all statically and install it.
<infinity> leshaste: If it's not "rooted" (ie: a pure factory image), well.  I suspect there's no real solution.
<leshaste> infinity: why couldn't you make an app?
<leshaste> infinity: there is NDK for example
<leshaste> but I am not against rooting in any case :)
<infinity> Do they actually let app developers live outside dalvik now?
<leshaste> infinity: sort of http://developer.android.com/sdk/ndk/index.html
<infinity> If so, then I suppose you could do so.  But apps sort of imply also having a UI of some sort.
<leshaste> infinity: sure you need an editor too
<leshaste> infinity: there actually is already one
<leshaste> verbtex
<leshaste> just no backend :)
<infinity> No idea if this ndk would let you, say, build something statically against another libc (might break their pseudo-VM model there), but hey, worth having fun with.
<infinity> Also, wildly out of scope for this *Ubuntu* ARM channel. :)
<leshaste> I have no idea either.. it must be hard
<leshaste> as lots of people say they want it
<leshaste> and no one has it :)
<leshaste> oh yes.. the other route is to chroot ubuntu arm
<leshaste> which is why I am here :)
<leshaste> are there any nice docs on getting ubuntu arm to work in chroot on android?
<leshaste> infinity: unless you think that is also crazy :)
<infinity> leshaste: A chroot should kinda just work?
<infinity> leshaste: Not sure what docs would be needed.
<GrueMaster> leshaste: Kind of out of our scope, but I'm sure you can use our core image as a base.
<leshaste> ok thanks
<leshaste> http://www.youtube.com/watch?v=MErL7FslBjU looks fun :)
<infinity> leshaste: eg, download ubuntu-core, set up /etc/resolv.conf to point at something useful, chroot in.
<leshaste> infinity: thanks.. I think I will give this a go as it looks like a simple and almost sane solution
<julien___> salut
<julien___> il y a quelqu'un ?
<julien___> allo ?
<infinity> julien___: Nous parlons Anglais iÃ§i.
<julien___> infinity: sorry
<julien___> know you linux4tegra ?
<julien___> do you know *
<julien___> sorry for my bad english
<julien___> nobody can help me
<julien___> ??
<infinity> julien___: Sorry, I don't know a whole bunch about linux4tegra.  And I'm not entirely sure how it relates to an Ubuntu channel?
<infinity> (Well, except that l4t is based on Ubuntu 11.04)
<neels> FYI, http://releases.linaro.org/images/11.12/oneiric/nano/beagle-nano.img.gz made my day. it just works! :D
<julien___> i 'm jsute searching the image kernel for compiling ubuntu 11.04 on my toshiba folio 100
<julien___> http://developer.nvidia.com/linux-tegra
<julien___> it's written here we can download that but i don't find them
<julien___> please help me
<infinity> julien___: Not sure how much help we can be here.  I don't think any of us own or hack on Folio 100s.
<infinity> julien___: You could try our AC100 netbook images and see if they somehow magically work on your tablet, but I highly doubt it.
<julien___> that don't work
<infinity> https://wiki.ubuntu.com/ARM/TEGRA/AC100
<julien___> but if you can help me just at finding the kernel in the site of nvidia ,
<infinity> Yeah, well, if that doesn't work, I'm not sure what help we can be.  Without the hardware, I can't say much as to how to mess with it.
<infinity> julien___: nvidia doesn't distribute kernels for each device (or for any devices, I suspect).
<infinity> julien___: But you can re-use the Android kernel that shipped with the tablet.
<julien___> yes but it's says they do
<julien___> but i can't find
<julien___> http://developer.nvidia.com/linux-tegra
<julien___> look at system requirdment
<infinity> julien___: And directly below that are the driver packages they speak of.
<julien___> but this is not kernel source ?
<infinity> julien___: That said, there's still no gurantees that any of their reference kernels will boot on your device.
<julien___> but i'm determinated to try
<infinity> Kay.  Well, I'm not sure we're the right people to ask about it. :P
<julien___> I had make 3or4 irc chanel all people says me that ;)
<infinity> Probably because none of those people (A) work for nvidia, or (B) are working with the device you own. :/
<infinity> So, you get to be a pioneer.
<julien___> ^^
<julien___> i think
<julien___> so, you say the driver package is the kernel source ?
<infinity> I didn't say that, and I haven't downloaded one to look.
<infinity> They claim it contains kernel *images*, not source.
<infinity> But then again, to satisfy the GPL, there's likely a readme in it that tells you were to get the source.
<infinity> One would hope.
<infinity> Maybe.
<julien___> so i can't compil that ?
<infinity> Download it and check it out?  I know as much as you do.
<julien___> i have downloaded
<julien___> but i don't have .h or.c file
<julien___> infinity: no ideas ?
<infinity> julien___: Not so much, no.  Sorry, rather busy here with my own work.
<julien___> infinity: ok :(
<julien___> infinity: can you say me what are the source liste for ubuntu 11.04 arm please i will try an upgrade
<infinity> http://ports.ubuntu.com/ubuntu-ports natty main universe restricted multiverse
<infinity> And then natty-security and natty-updates as well.
<julien___> i should change this before make do-release-upgrade
<julien___> infinity: ?
<GrueMaster> julien___: We really aren't in much of a position to help with this as it is not one of our built distributions.  We can offer package support, but beyond that, we don't know how the image is assembled.
<GrueMaster> Having said that, i am now pulling it down to see what they have.
<julien___> escuse me i'm french and i don't understand all you say
<julien___> sorry GrueMaster
<GrueMaster> Ok, having looked at the base system, if you want the source, add "deb-src http://ports.ubuntu.com/ubuntu-ports natty main universe" to the /etc/apt/sources.list.
<julien___> you think it's that work if i do an upgrade ?
<julien___> you think  that's work if i do an upgrade ?
<GrueMaster> I see you are looking to run on the Toshiba Folio 100.  This is not a platform we support, sadly.
<julien___> why not ?
<julien___> i understand
<julien___> now i am on the 10.10
<julien___> and a upgrade should be possible
<julien___> no ? GrueMaster
#ubuntu-arm 2012-01-24
<twb> lilstevie: do you know if TF has a "multi-channel sound card" ?
<twb> I'm afraid the answer is no, which makes me sad
<twb> I tried using two mpg123 processes at the same time, the second one gave up
<infinity> twb: Try running mpg123 under padsp so it passes through a software mixer?
<twb> infinity: pulseaudio?
<twb> I don't allow pulse on my systems :P
<twb> I was asking because I'm trying to get emacspeak up and running again
<infinity> twb: Heh.
<twb> I can't actually get emacspeak to work at all yet
<jamespage> hello - anyone around who can help me with this armel/armhf build failure - bug 920871
<ubot2`> Launchpad bug 920871 in zookeeper "zookeeper 3.3.4+dfsg1-2ubuntu2 FTBFS on armel and armhf" [High,Confirmed] https://launchpad.net/bugs/920871
<jamespage> not quite sure where to start :-)
<jamespage> (have reproduced locally)
<ogra_> jamespage, does this help https://wiki.ubuntu.com/ARM/Thumb2 ?
<jamespage> ogra_, yes thanks
<rbasak> I'm having bus powered USB disk issues on the pandaboard. Should I just give up? Does this work for anyone else?
<taruti> rbasak: I have an usb disk but it wants external power with the pand
<taruti> *panda
<rbasak> so doesn't work without?
<rbasak> even though it in theory should?
<taruti> not sure why, that is just my experience
<rbasak> I'm giving the panda a beefy enough PSU I think. But perhaps a varying load is causing issues. I get combinations of kernel panics and disk spindowns
<ogra_> rbasak, the PSU TI shipped with my first panda is 5V 4A, what do you use ? i wouldnt go below 3A for hub powered USb disks
<rbasak> 5V 4A, and I also have been trying a 200W AT PSU
<ogra_> well, that should work, whats the issue you see ?
<rbasak> kernel panics
<ogra_> actually USB related ones ?
<rbasak> and sometimes the disk keeps spinning on and off in a fast (maybe 0.8s) cycle
<rbasak> I don't think the panics are USB specific
<ogra_> well why blame the disk then ? :)
<rbasak> I suspect maybe the disk is causing the board voltage to drop, though I've metered it I won't be able to see short interval drops
<rbasak> only this disk does it. my sata/usb docking station which is externally powered does not have the same issue
<ogra_> hmm, well, might even be a driver issue
<ogra_> i think there are plenty people running host powered usb disks on their pandas ... not that i have empirical data though
<rbasak> OK I'm pretty sure it's a power issue. taruti gave me an idea - I connected the second bus power connector to a usb hub powered by my AT PSU instead of into the panda. And powered the panda from the power brick I have. Now it seems to be going OK
<rbasak> Perhaps I need to make a "USB power boost" harness which supplies 5V to those secondary connectors outside the panda
<rbasak> perhaps this particular drive model causes more noise on the usb power affecting the panda?
<rbasak> I just bought the cheapest one
<rbasak> it's an intenso 320GB
<tedg> Hey folks.  I was curious if someone could build the HUD feature for ARM and check to see if it's responsive.
<tedg> It's very much so on my computer, so I haven't spent much time optimizing, but I'd like to ensure that's across platforms.
<tedg> I'm not super worried, but I want to make sure :-)
<ogra_> if it is as responsive as the dash it will take 10-15sec to come up
<tedg> ogra_, On Unity or UnityQt?
<ogra_> can it run in unity-2d too ?
<ogra_> (GLES support for 3D unity isnt merged yet, so we can only run under -2d)
<ogra_> -2d == Qt
<ogra_> :)
<tedg> ogra_, 2d is Qt only until Qt5 is out, then they're all 3d :-)
<ogra_> we only have the Qt version on arm atm until the GLES patches from linaro get merged into unity
<tedg> ogra_, I thought Unity could run on the Pandaboards?  no?
<tedg> ogra_, Is that with the ES patches?
<ogra_> right, they are a) not merged (waiting since the dublin sprint) and b) still have a few bugs
<ogra_> so all we can currently run proper is unity-2d (Qt)
<GrueMaster> rbasak: Most USB powered drives require two USB connectors to get enough power, but unfortunately even then the panda doesn't deliver enough power from the usb ports.  All of my USB<>SATA drives have separate power source, which isn't easy to find on 2.5" enclosures.
<tedg> ogra_, Hmm, okay.  Is that plan updated?  I thought there was a plan to merge those branches discussed in Budapest.  Have you talked to the Unity guys about that since then?
<rbasak> GrueMaster: aha, that'll be my problem then. I've tried connecting the second connector to an external source but that only seem to work some of the time. Thanks!
<ogra_> tedg, once a week, yep. its in the process and hopefully ready by feature freeze
<tedg> ogra_, Cool, I'll leave you to it then!  :-)
<ogra_> tedg, btw, the HUD is public stuff now ?
 * rbasak wonders what to do with this drive that's going spare now
 * ogra_ didnt see any blogpost yet 
<tedg> ogra_, Yup: http://www.markshuttleworth.com/archives/939
<ogra_> ah, k, had no time to follow planet since budapest
<tedg> ogra_, But you're a voracious reader of OMG! Ubuntu!, right?  ;-)
<ogra_> heh, rather planet than OMG :)
<LetoThe2nd> k1l: didn't know you also hang out here ;)
<k1l> ;)
<GrueMaster> ppisati: Any chance of getting the omap4 kernel fixed or at least removed from the pool today?
<rbasak> GrueMaster, AIUI ppisati sent a fix to the list today
<ppisati> GrueMaster: yep, sent, waiting for the upload
<GrueMaster> Ok.
<ppisati> btw, do anyone know why the arguments for the kernel cmdline changed?
<ppisati> dpkg -S /boot/boot.script says it doesn't belong to any package
<ppisati> so it must some hand-crafted stuff coming from the installer
<ppisati> *it must be
<GrueMaster> The boot script is generated during install, not by any packages.  For preinstalled, it is created by jasper.
<GrueMaster> For netinstall, it is generated by f-k-i (I think).
<ppisati> ok
<ppisati> and do we have a changelog of it? why an arg was added/deleted?
<GrueMaster> What arg was added/deleted?
<ppisati> GrueMaster: mem=456M@0x80000000 mem=512M@0xA0000000
<ppisati> GrueMaster: these two are not of boot.script anymore and one of the feature of our kernel (CMA) craps out without it
<ppisati> s/it/them/
<GrueMaster> That arg is only necessary when using the closed source video decoder.  Shouldn't have any affect when running server/headless.
<ppisati> it has with CMA
<ppisati> without these args it doens't initialize the pool at boot, and when the usb ask for some DMA buffers, kaboom
<ppisati> that's what you get yesterday
<ppisati> i sent a revert of this CMA
<ppisati> since it's not mandatory and it's not even in mainline
<ppisati> but the camera driver needs it
<ppisati> so
<ppisati> we either drop the camera driver, or we revert these args
<GrueMaster> Then that is a new change, as I have been running w/o those settings on all headless images since Maverick.
<ppisati> yep
<ppisati> it was bropught in with the last TI bits
<ppisati> btw i had these args since i started working here
<ppisati> that's why i didn't notice CMA panicng at boot
<GrueMaster> As to the netinstall cmdline parameters, they were never added when netinstall was created.  I'd have to look, but I'm not sure they are even in the server preinstalled images.
<ppisati> uhm ok
<ppisati> anyway the revert is on its way
<ppisati> so...
<GrueMaster> Those parameters create a hw memory hole so that a specific hw device can use that address range.  Not sure why it can't be a bit more intelligent and request it on module load.
<ppisati> perhaps because if you don't explicitely say so at boot time, the entire memory would be mapped (and couldn't be reclaimed later) i guess
<GrueMaster> Ok, those parameters are on the server preinstalled (which makes sense as they are hardcoded in jasper).
<GrueMaster> I'll bug NCommander to add them to the netinstaller when he comes online.
<ppisati> no no
<GrueMaster> But as I said, we were told they were only needed for the closed source decoder bits.
<ppisati> i already asked for the revert
<ppisati> these won't be necessary anymore after nex upload
<GrueMaster> But is that what TI wants going forward?
<ppisati> well, CMA is not even mainline
<ppisati> so when it will hit mainline, we'll see
<GrueMaster> If their patches are now enabling it, then we should make sure all images are consistent.
<GrueMaster> (we should make sure netinstall is consistent anyways).
<ppisati> i was wondering why linaro has no such problems
<GrueMaster> They may have that parameter as default on their images.
<ppisati> could be
<ppisati> i tried to ask it to agreen
<ppisati> but he didn't answer yet
<GrueMaster> For now, if that is all that is required for netinstall to work, that is easy to fix (w/o reverting the patch).  Netinstall can be preseeded to include those parameters during install and the netinstall image can be fixed to have them on boot.
<ppisati> yes, that would fix it
<GrueMaster> My concern now is that by reverting it, are we causing issues to TI's development work down the road?
<ppisati> revert the patches?
<ppisati> this is just for 3.2
<ppisati> and since TI won't support it/as, we stay as it is
<ppisati> for 3.3 we will get it, and bunch of new drivers exploiting it (i guess)
<GrueMaster> Then we are better off leaving the kernel as is and fixing netinstall.  Less pain in the long run.
<ppisati> GrueMaster: when you say the binary driver, do you mean the pvr-omap4 dkms?
<GrueMaster> Not sure if it is that one or the gstreamer code (think it was gstreamer though).
<GrueMaster> ogra_ would know.
<GrueMaster> Or ndec.
<ppisati> k
 * ogra_ looks up
<ogra_> ah
 * ndec too
<ogra_> the cmdline is created at buildtime, only the root= parameter is added by jasper
<ogra_> the memory hole is needed for ducati (the multimedia framework)
<ndec> ppisati: GrueMaster: i saw the email on kernel list, i am not sure i understand what the proposed fix is
<ppisati> ndec: the problem is in the new memocry allocator (CMA)
<ndec> does it require the memory hole in bootargs?
<ppisati> this CMA has never been in mailine, but we got it via tilt
<ogra_> GrueMaster, the netinst images should have that cmdline params too, if not, NCommander should add them at build time
<ppisati> because the camera driver needs it
<ndec> yes, it's in tilt because we use it for v4l2 camera driver.
<GrueMaster> ogra_: Ok.  I'll file a bug and assign to him.
<ndec> and later for MM with syslink3.0
<ppisati> since the usb crap was due to this memory allocator, i reverted it and now everything works
<ogra_> GrueMaster, great, if he doesnt have the time, infinity or i can do it as well
<ppisati> dunno why it doesn't init the pool at boot time if we don't pass the args stuff
<ndec> the camera driver should not need it. or there is something else missing.
<ppisati> that's what agreen told me
<ppisati> but i handed a couple of kernels without this cma to rbasak today, he testd it
<ppisati> and all the panicing on boot&c are gone
<ppisati> so i pushed the revert since we are close to kernel freeze
<ndec> i think the memory hole is just helping to hide another issue ;-)
<GrueMaster> ogra_: iirc, we (NCommander and I ) had this discussion last cycle.  Iirc, there was a problem getting others to accept the change.
<ndec> I will look into this, i would prefer we make the real fix instead.
<ppisati> ndec: that's why i don't want it in (i mean the CMA)
<ndec> and our MM stuff with syslink3 will no longer require the memory hole anyways.
<ppisati> but that's 3.3+ and we talking about a P kernel
<ndec> ppisati: no, i think we should keep it, but you might be missing another config somewhere.
<ndec> if you revert this one, you might want to revert the v4l2 camera driver as well, to ensure that nobody will attempt to use it.
<ppisati> let me check one thing
<ndec> on the other hand if you keep it, and if we fix it properly, then all the boards that have a camera (blaze have, and some panda do) will get support for camera out of the box with 12.04...
<ppisati> ndec: does our kernel boot on that boards?
<ndec> yep
<ndec> sebjan maintains blaze support in tilt tree
<ndec> ppisati: let me reply on the mail and let's try to sort it out. you can use the mem hole as a temp workaround. since it's really no longer needed moving forward, i would prefer to get rid of it...
 * ogra_ wouldnt be opposed 
<ogra_> its one hack less we have in the image builds
<ppisati> ok, but then remember to get the memory hole back in place
<ogra_> ppisati, i thought ndec just proposed to get rid of it
<ppisati> ogra_: actually the opposite
<ndec> ;-)
<ppisati> ogra_: he wants to reintroduce it to workaround this problem
<ogra_> ppisati, anyways, we didnt change anything wrt kernel cmdline in precise yet
<ppisati> ogra_: yep
<ogra_> its still there, hasnt gone anywhjere
<ppisati> ogra_: it's just that this cma came via last kernel update
<ogra_> unless you used a netinstall
<ppisati> ogra_: and my default boot.scr has those mem args in it
<ogra_> right
<ppisati> that's whty i didn't notice the panic on boot
<ogra_> you will only see it on netinst since apprently NCommander didnt take them into account when building the image *or* in f-k-i
<ogra_> not sure where they are missing there exactly
<GrueMaster> So, what is going to be the goal here?  a) fix netinstall to include the hole, or b) fix the kernel cma to not need the parameter on the cmdline?
<ogra_> sounds like b) as the final goal and a) as the interim
<ppisati> right
<ogra_> not sure how long b) will take
<ogra_> if its only a few days, changing netinst might be wasted time
<ogra_> GrueMaster, so the answer is "depends ... "
<GrueMaster> Well, we can work around the netinstall issue for now, but I wouldn't recommend it long term.
<GrueMaster> If the kernel can be fixed before freeze, then netinstall workaround is the way to go.
<ogra_> right
<GrueMaster> If not, a more permanent netinstall fix is required.
<GrueMaster> Ugh.  Now I remember why it wasn't in the netinstall (or at least on my testing).  u-boot cmdline is limited to ~256 characters.  I'm getting ready to verify it now, but if that is still the case, it screws up automation in a huge way.
<GrueMaster> Grrr.  And netinstall doesn't seem to care about debian-installer/add-kernel-opts in the preseed.  grumble.
<ndec> GrueMaster: does latest 12.04 image boot on panda and es?
<ndec> i was told (didn't try) it wouldn't boot
<ndec> on es
<GrueMaster> I just booted today's daily-preinstalled desktop image ok.
<GrueMaster> And I have a couple of systems running netinstall now.
<ndec> on panda ES?
<GrueMaster> The desktop is running on my 4460 ES.  Haven't seen any issues.
<ndec> ok. thx
<GrueMaster> I haven't done a "full" test, but desktop is installed and running.  I'm currently sitting in unity2D with an open terminal.  Couple of kernel warnings in dmesg (early during boot), but nothing serious.
<ogra_> bug 920618
<ubot2`> Launchpad bug 920618 in debian-installer "Setting "d-i base-installer/kernel/image none" fails to ignore installation w/o kernel" [Undecided,New] https://launchpad.net/bugs/920618
#ubuntu-arm 2012-01-25
<smp4488> so im trying to CC an arm kernel, http://pastebin.com/r9Ej93GH
<brendand> is it known that the pandaboard is droppping wireless a lot with precise?
<brendand> how do i get my package to build for armhf?
<xranby> TheMuso: hi, I am testing your fix to make openjdk swing applications work in combination with at-spi. I plan to send the patch upstream to icedtea to make the AtkWrapper the default for all distro openjdk builds.
<xranby> TheMuso: all in all, I can get accessibility to work under precise by using the AtkWrapper.
<xranby> TheMuso: i still have some problems getting the atk-wrapper to work under oneiric
<entropia_> Hi, I was trying to boot ubuntu 10.10 on my BB-xm. Keyboard, mouse and moniotr are connected to the board and the board itself is connected with my pc. After inserting the microsd with U10.10 I have a typical output in my console, ending with Uncompressing Linux... done, booting the kernel. After this, I can't do anything, also the screen remains dark. Is there anything I can do to make it work?
<ogra_> use a newer release
<ogra_> might well be that your board revision wasnt supported by 10.10 yet
<ogra_> we often have the case that TI releases HW right around or right after an ubuntu release ... generally you should take the latest release, thats most likely to have all support for your HW
<entropia_> Oh, ok. Thank you.
<rbasak> NCommander, when you see this, what the plan with bug 921137? Do we need another bug for the default to be fixed so that netinstall works again? I use it for my dev multiple times a day and without an automated workaround I'm getting really slowed down
<ubot2`> Launchpad bug 921137 in flash-kernel "Flash-kernel-installer doesn't support d-i debian-installer/add-kernel-opts in preseed " [Undecided,Confirmed] https://launchpad.net/bugs/921137
<ogra_> bug 540645
<ubot2`> Launchpad bug 540645 in plymouth "no fsck messages shown in details mode (no splash on cmdline)" [Medium,In progress] https://launchpad.net/bugs/540645
<sebjan> ppisati: it appears we are missing cpu_freq into the precise kernel config (ti-omap4 branch)
<brendand> ogra_ - ping
<ogra_> brendand, hi
<ppisati> sebjan: right, any preference for the governor?
<ogra_> sebjan, i think the x86 kernels were moved to cpuidle insted of cpufreq, seems that was carried into the arm kernels
<ogra_> (by accident i guess)
<ppisati> actually they are trying to move arm to cpuidle too
<ppisati> but it's no ready yet
<ogra_> right, so we should keep whats working in the distro kernel and leave the crack bits to linaro ;)
<ppisati> agree
<sebjan> ppisati: by default we can select performance. user space will enforce ondemand after a while
<ogra_> right, we have an upstart job for that
<sebjan> yep
<sebjan> ppisati: we also miss some flags for enabling the kernel thermal management
<brendand> ogra_ - is there anything specific we need to do to make a package build for armhf?
<sebjan> we need the changes in this commit: http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=commitdiff;h=c9b8185d6ebb87e4beacd0874dc50a8eca8c39e9
<ppisati> let me see
<ogra_> brendand, the debain/control file should have armhf in it if its not "any" and lists things like armel separately, beyond that it should just build
<ogra_> all "any" packages usually do
<brendand> ogra_ - ours has 'all' (same thing?)
<ogra_> well, no, "all" is usually only built on x86 adn copied over since defining "all" means there arent any arch specific bits in it at all
<ogra_> at least thats how it is done in the archive, i think PPAs work a bit different, not sure though
<brendand> heh, well i was wrong. it is 'any'
<ogra_> ah, k
<ogra_> then it should just build
<brendand> ogra_ - maybe we need to build again. is armhf builds a recent introduction?
<ogra_> we have the arch since two months or so
<ppisati> sebjan: OMAP_DIE_GOVERNOR seems doesn't exist in our tree
<ogra_> what package is that ?
 * sebjan looks
<ppisati> sebjan: neither OMAP_THERMAL
<sebjan> ppisati: you have both, but they depend on disabled flags
<sebjan> (thermal_framework?)
<ppisati> sebjan: right
<ppisati> saw it just now
<brendand> ogra_ - this is a PPA by the way. maybe some change needs to be made to the PPA?
<brendand> i'm just guessing
<ogra_> brendand, oh, indeed, you need to file an RT to get armhf enabled (if your PPA already has armel thats quick and easy)
<brendand> ogra_ - an RT? ok - but how would you do it as a non-canonical person?
<brendand> (i am, so this point is moot, but...)
<ogra_> brendand, we dont allow non canonical people to use arm PPAs yet (security issues that will be solved soon)
<brendand> ogra_ - i see
<ogra_> so this only works for private PPAs atm
<ogra_> of teams that have only canonical people in them indeed
<reisei> hi, all. How can I setup dvi as a default screen? I use ubuntu-oneiric (only kernel, btw, but it doesn't matter)
<ppisati> sebjan: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=commit;h=cd3338daa84b6d891f4d9812b2f545e664b5fa97
<ppisati> sebjan: and http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=commit;h=9beb67b9255a6c7e47a8c12f46f76ad3f74d98a0
<ppisati> i'm building a test kernel right now
<sebjan> ok cool
<ppisati> sebjan: how do i check if the themal/cpu_freq is working well?
<sebjan> ppisati: hum, you can try by loading your pandaES a lot, and monitor the cpu frequency
<ppisati> sebjan: i don't have a pandaES
<sebjan> ppisati: if you can share your .deb, I can git it a try and tell you
<ppisati> sebjan: ok
<ppisati> sebjan: http://people.canonical.com/~ppisati/linux-image-3.2.0-1404-omap4_3.2.0-1404.6~thermalrevcma_armel.deb
<sebjan> ppisati: I'm installing it and will test. I'll let you know then
<sebjan> ppisati: ok, I just tested your .deb. The freqs scale well, and the thermal fwk effectively reduces the freq when appropriate. It's good for me!
<ppisati> ok
<ppisati> thanks for testing
<sebjan> np
<rbasak> NCommander: ping
<rbasak> Gruemaster: ping
<ogra_> there he is !
<ogra_> GrueMaster, soo by reading the kernel ML it seems like ppisati is already pushing the patch for the kernel fis, no need to mangle your preseed stuff for a new kernel cmdline
<ogra_> should be fixed by A2
<ogra_> s/fis/fix/
<GrueMaster> A2 doesn't help today.  Mangling the preseed is easy and immediate.
<ogra_> i'll make sure to drop all mem= args for A2 too
<GrueMaster> And easily reversed.
<ogra_> sure
<GrueMaster> ppisati: What is the fix for the mem= issue?
<ogra_> disabling CMA
<ogra_> as discussed here last night
<GrueMaster> But that will disable a lot more (USB Cameras, etc).
<ogra_> i dont think so
<ogra_> it should just affect the internal camera interface
<GrueMaster> Ok, that means blaze.
<ppisati> just the omap4 camera
<ppisati> v4l i resent a new pull req
<ogra_> and panda ...
<ppisati> with some PM stuff in
<ogra_> (there is a camera interface on the panda too, not that we make any use of it indeed)
<GrueMaster> ok, so this just brings us up to date w/ Ti then I take it?
<ppisati> i didn't even know there was a dedicated camera interface
<GrueMaster> We don't use the camera interface, but community members do.  I have seen some discussions on the pandaboard mailing list about it.
<ogra_> on the socket header
<ppisati> GrueMaster: they can move to Q (or install stuff from the ppa_
<ogra_> right, and in #pandaboard too
<ppisati> at least the kernel
<GrueMaster> Ok.
<ogra_> if they use the camera they probably also want to accelerate the displaying of the movies they take, so the PPA is needed anyway
<GrueMaster> Fair enough.
<GrueMaster> rbasak: In my preseed, I added "sed -i 's/splash/fixrtc console=ttyO2,115200 mem=456M@0x80000000 mem=512M@0xA0000000/' /boot/boot.script;flash-kernel;echo 'ledtrig-heartbeat' >>/etc/modules" to the preseed/late_command.  Worked fine (and I also get the blinken(tm) lights back).
<S0NiC> hi
<GrueMaster> Actually interesting to watch 4 pandas in a stack all blinking in time with daft punk.
<S0NiC> hmm can anyone tell me, why ubuntu(11.10) is so slow on my pandaboard?
<S0NiC> is there any possibility to enchance speed=?
<S0NiC> -c
<S0NiC> +d
<GrueMaster> S0NiC: Are you running from SD?  That is the main issue.
<S0NiC> GrueMaster: yes
<GrueMaster> Not much can be done there.
<S0NiC> hmm shoot...
<GrueMaster> But I see a speed increase of ~6-10x running from USB drive.
<S0NiC> hmm maybe deaktivate unity?
<ogra_> a lot can be done there .... but it starts with changing the SDHC spec ;)
<S0NiC> ogra_: ;D
<rbasak> thanks GrueMaster, I'll try that!
<GrueMaster> ogra_: What is the plan for armel image builds?  How soon can we start phasing them out?  At least for omap/omap4.
<ogra_> we wont
<ogra_> but we will stop testing them after FF
<GrueMaster> If they are available for milestones, they are tested (or I get constant nagging).  That's why I ask.
<ogra_> well, they will still be there for A2
<ogra_> but after that they are "community" images and we explicitly wont test them
<ogra_> as long as we carry armel in the archive we need to give users an install opportunity, even if its untested
<GrueMaster> What's this "we" stuff?  I test all images during milestones (even kubuntu).
<ogra_> and armel wont go away before Q
<ogra_> it was discussed several times in budapest
<S0NiC> is that normal, that i have to wait about 10 seconds till ff starts?
<ogra_> "we" as in paid people working on arm stuff
<ogra_> S0NiC, on SD thats actually pretty fast ... i have seen things like 30sec in the past
<S0NiC> ogra_: ok thx
<S0NiC> maybe it speeds up if i choose gnome instead of unity?
<GrueMaster> S0NiC: If you want a little boost in performance, try the armhf images for precise.
<ogra_> that wont change the speed of your disk access
<GrueMaster> http://cdimage.ubuntu.com/daily-preinstalled/
<GrueMaster> No, but app performance is better.
<S0NiC> thx guys... hmm if i open software center i only get a grey window. maybe iam to impatient? ;D
<ogra_> it also reads from disk a lot
<S0NiC> now i have a touchpannel... i wonder it works out of the box... ;D
<S0NiC> but its not realy precisce
<S0NiC> -c
<S0NiC> maybe i have to high prospects...
<S0NiC> hmm reboot
<S0NiC> brb
<S0NiC> re
<jayabharath> Folks do anyone on this channel knows if the Ubuntu Precise Pangolin daily configure the PandaBoard ES to run @ 1.2Ghz?
<S0NiC> re
<jayabharath> In the 11.10 release it was only configured for 700Mhz.. I dont know if the right patches have been integrated into the Precise Pangolin dailys for ES....
<infinity> jayabharath: Upgrading and testing the kernel is a surefire way to find out.
<infinity> jayabharath: But, AFAIK, precise fully supports the 4460.
<jayabharath> infinity: thx? it used to be supported even in 11.10.. but I was more concerend about speed?
<infinity> jayabharath: Hence why I said "fully supported".
<infinity> jayabharath: In oneiric, I believe it was artificially limited for thermal reasons, and that's been resolved now.  But I don't have a 4460 here to check.
<jayabharath> infinity: Great.. I guess I will give it a spin
<S0NiC> hmm did anyone get a touchscreen to work under ubuntu-arm?
<S0NiC> iam using ubuntu 11.10 and i have a egalax driver. and it works out of the box. but the finger is not there where the mouse is...
<S0NiC> any ideas?
#ubuntu-arm 2012-01-26
<S0NiC> hi
<S0NiC> back again...
<S0NiC> does anyone get eGalax under pandaboard to work?
<S0NiC> it works, but the y-axis is vice versa...
<Zectbumo> where can I find the opcodes for arm?
<K-4U> Hello, I have a beagleboard installed with the latest version of the omap headless edition.. and it just keeps booting...
<K-4U> *rebooting, sorry
<Zectbumo> easy fix is to unplug it
<K-4U> and throw it out the window?
<S0NiC> Zectbumo: who do you mean?
<Zectbumo> S0NiC: for my op code question?
<S0NiC> Zectbumo: ah ok ;) sry
<Zectbumo> K-4U: throwing out the window is not required
<K-4U> ZectBumo: Anyway, my problem somehow fixed itself
<Zectbumo> ah, you threatened to take the power away.  nice move
<K-4U> :')
<Zectbumo> maybe holding it near the window cooled it down
<K-4U> Probably :P
<Zectbumo> does it have fans?
<K-4U> no, it's the beagleboard :P
<K-4U> (xM)
<Zectbumo> what are you going to run on it?
<Zectbumo> or have it do?
<K-4U> Domotics
<K-4U> hmmm, think i am going to unplug it... it resets itself
<Zectbumo> nice, I would like to see that $25 board come out
<Zectbumo> http://www.geeksaresexy.net/2012/01/12/25-computer-hits-production-line/
<K-4U> hm, indeed :P
<Zectbumo> you could put one in every room
<K-4U> do you have any experience with the beagleboard?
<K-4U> FATAL: Could not load /lib/modules/2.6.38-8-omap/modules.dep: No such file or directory
<K-4U> Help.. the setup keeps running and running... the setup restarts itself
<Zectbumo> no, never heard of it. looks cool.  I saw the post where google deleted all of their news
<Zectbumo> it might be heat, try putting a fan on it to see if it lasts longer. if it does, then it's heat issue
<K-4U> hmm
<K-4U> it feels.. a bit warm
<Zectbumo> I've actually once took a zip lock bag of ice water to cool down a device to keep it working from all the heat it was generating
<K-4U> :|
<Zectbumo> you have to watch out for the exterior condensation though.  I used a cloth
<K-4U> hmmmm :|
<K-4U> not going to try that here... it's not my board.. it's from the company where i have my internship :P
<Zectbumo> yeah, desk fan is much easier
<K-4U> Oh crap... this sucks :S
<xranby> hrw: hi
<hrw> hi xranby
<K-4U> on the beagleboard page from ubuntu, it tells you to install a new kernel... but.. the issue is, that the "new" kernel i download, is an older one that comes with the package 11.10
<xranby> hrw: we have a confirmed libav bug in oneiric https://bugs.launchpad.net/ubuntu/+source/libav/+bug/787486 looks similar to the bug you saw last summer
<ubot2`> Launchpad bug 787486 in libav "/usr/lib/neon/vfp/libavformat.so.52: symbol __aeabi_d2lz, version LIBAVCODEC_52 not defined in file libavcodec.so.52 with link time reference" [Low,Fix released]
<xranby> err the new bug are here: https://bugs.launchpad.net/ubuntu/+source/libav/+bug/921621
<ubot2`> Launchpad bug 921621 in libav "mplayer: relocation error: mplayer: symbol __aeabi_d2lz, version LIBAVFORMAT_53 not defined in file libavformat.so.53 with link time reference" [Undecided,Confirmed]
<hrw> xranby: I think that it is yet another package requiring rebuiding
<hrw> I got that on my amd64
<xranby> do you know if the security builders have different toolchains compared to the release builder?
<hrw> should not
<hrw> but #ubuntu-devel would be better place to ask
<K-4U> Any of you got experience with the beagleboard XM?
<xranby> ok, so you can reproduce this on non-arm hardware as well?
<xranby> hrw: ok i will ask in ubuntu-devel
<hrw> xranby: yes, I had it on !arm
<K-4U> on the beagleboard page from ubuntu, it tells you to install a new kernel... but.. the issue is, that the "new" kernel i download, is an older one that comes with the package 11.10
<xranby> hrw: hmm ok i will simply try rebuild that package from source and see if it fix the bug
<xranby> and then propose it for rebuilding
<hrw> thx
<brendand_> ogra_ - are the necessary packages to get unity 3d running available for armhf?
<ogra_> brendand_, nope, they arent even available for armel yet
<ogra_> brendand_, there should be a linaro PPA though
<ogra_> but i dont think they have armhf either
<ogra_> brendand_, https://launchpad.net/~tiomap-dev/+archive/release/+packages also doesnt seem to have armhf GLES drivers yet
<brendand_> ogra_ i think that's the one i was trying
<ogra_> i know ndec plans to have them, but they dont seem to have landed yet
<S0NiC> hi ogra_
<ogra_> hi S0NiC
<S0NiC> re
<rbasak> odd...my relay board has arrived and works from my laptop, but not my panda
<rbasak> USB interface, ftdi_sio driver maps to ttyUSB0
<rbasak> I wonder if the driver's broken on ARM?
<ogra_> works on my tegra, i often use an ftdi dongle on my ac100 to drive the panda
<ogra_> but thats a different kernel
<ogra_> janimo, looks like the tegra issue might be caused by a bad pixman patch (teh guys in #ubuntu-x said)
<janimo> ogra_, so waiting a bit may just make the issue go away? :)
<ogra_> well, reverting to 0.24.0 could fix it, but its not clear if the patch is actually being reverted
 * ogra_ hasnt tested anything yet 
<ogra_> just got told that could be related
<GrueMaster> infinity: Do you think we will have mx5 hf images for A2 next week?
<ogra_> GrueMaster, why do you ask infinity ? ask jcrigby, we're still waiting for a kernel
<GrueMaster> because jcrigby gave him a ppa kernel to test
<infinity> GrueMaster: What Oli said.
<tc_> hey guys, I'd like to disable the automatic onboot switch to vt7.
<tc_> Ok, I just killed that stupid plymouth, now everything works as expected
<aalma_> hello?
<pbuckley> heya, has anyone got airplay working under ubuntu 11.10?
<pbuckley> i've tried the git clone/copying the directory to both ~/.local/share/totem/plugins/airplay and /usr/lib/totem/plugins but totem doesnt seem to see the plugin
<rsalveti> janimo: thanks for cleaning up the bugs
<pbuckley_> not sure if anyone said anything about the airplay thing but my pb died so if you did i lost it :(
#ubuntu-arm 2012-01-27
<S0NiC> re
<S0NiC> can anyone help me with this errormessage? http://nopaste.info/3cda43b7e5.html
<twb> Please reproduce it with LC_ALL=C
<twb> The funamental problem looks like this: 299. trying to overwrite '/usr/lib/gstreamer-0.10/libgstfaac.so', which is also in package gstreamer0.10-plugins-bad-multiverse 0.10.21-1
<twb> It's upset because two packages provide the same file and neither claims to replace the other
<twb> I would try first removing the package under its old name
<S0NiC> twb: iam not so familiar to ubuntu and arm
<S0NiC> which package should i remove?
<S0NiC>   gstreamer0.10-plugins-bad-multiverse 0.10.21-1
<S0NiC> this one?
<twb> Yes I think so
<twb> This is not an arm-specific issue
<twb> It looks like you're trying to upgrade between releases and you're running into the same bug as everyone else
<S0NiC> twb: ok, the problem is i run now alyways into the same error, it says gstreamer0.10-faac wants to update, but is not selected for install... try apt-get -f install
<S0NiC> but this doesnt work
<twb> Are you trying to upgrade to precise?
<S0NiC> twb: no, i only want to update my 11.10. i installt today 11.10
<S0NiC> twb: and i dont know how to get out of this loop
<twb> Huh.  Well, you probably need more hand-holding and I'm ill equipped and disinclined to help.
<twb> I don't even have a desktop
<twb> I recommend you try asking #ubuntu and #ubuntu+1 for help with this
<S0NiC> no problem... ;)
<S0NiC> ok thx
<ppisati> rbasak: did you try the new kernel?
<rbasak> ppisati: I've just been using whatever the archive gives me, but I haven't done a reinstall in a little while
<ppisati> rbasak: it should be the 1405
<rbasak> ppisati: trying now
<rbasak> ppisati: yes, it's installing 1405.7
<rbasak> ppisati: 1405 booted with no special parameters needed - thanks! The installer still needs them though.
<ppisati> rbasak: why the installer needs them?
<rbasak> ppisati: for netinst. I assume the installer isn't using the latest kernel.
<ppisati> rbasak: ah, i don't know. You better probe orga/Grue/ndec aabout it
<ppisati> ogra_: so you have a beagle xm active by now, right?
<ogra_> as my printserver, yes
<ogra_> running lucid
<ppisati> ogra_: which kernel are you running? and do you change the mac addres? (/etc/network/interfaces)
<ogra_> no, its a stock install, i didnt touch the network settings beyond what the installer does
<ppisati> ok
<ogra_> oh, wait, thats a C4, i lied
<ogra_> my XM actually sits in a bag in my office
<ogra_> sorry
<ppisati> ok
<ppisati> because *i think* i met a regression
<ogra_> my XM is a rev A though
<ogra_> very first model
<ppisati> k
<ogra_> ndec, there was an Xorg ABI bump (bumped to 11) would it be possible to get a driver rebuild in the PPA since the current driver wont work with the 11 ABI
<jamespage> hello - any change someone with ARM/Assembler experience could review https://code.launchpad.net/~james-page/ubuntu/precise/zookeeper/arm-ftbfs-fixes/+merge/89940 for me
<jamespage> ?
<ndec> ogra_: you mean for O or P?
<doko> jamespage, you don't need ARM experience to *remove* ARM code ;-P
<doko> looks ine
<doko> fine
<ogra_> ndec, for P indeed, we didnt update xorg to a new ABI in O ;)
<ndec> ok
<ndec> we will rebuild, but likely will only support armhf, is that okay?
<jamespage> doko: good - I know it works on armel/armhf and for x86 - but wanted someone who might actually understand why!
<jamespage> ta
<ogra_> ndec, but i think rsalveti is already mailing xavier about it
<ogra_> ndec, fine with me
<doko> ogra_, janimo: please could you install 'deb http://ppa.launchpad.net/ubuntu-toolchain-r/glibc/ubuntu precise main' and run this for a while on your arm machine(s)?
<ogra_> doko, what packages are that ? just libc ?
<ogra_> doko, installed, anything i should look for after i reboot ?
 * ogra_ reboots and will blame doko if the system doesnt come up again
<ogra_> doko, booted fine, so what am i looking for now ?
<xranby> doko: during installation i see a warning locale: /lib/arm-linux-gnueabi/libc.so.6: version 'GLIBC_2.15' not found (required by locale)
<xranby> ah.. it have not been installed yet
<ogra_> likely because the new libc isnt running while it generates the locales
<xranby> thats correct dpkg are Setting up libc6 (2.1.5... now
<ogra_> yep
<xranby> 2.15
<ogra_> bah, it doesnt fix my graphics issues !
<xranby> heh
<ogra_> :)
<xranby> you should have benchmarked before the upgrade
<xranby> things might be faster
<ogra_> pfft
<ogra_> whats the actual change ?
<ogra_> if i would be after speed i wouldnt use ac100 as my main work machine :)
 * ogra_ only sees a reversion in the changelog that could be relevant 
<rbasak> is anyone else's panda netinst falling over today? with the same preseed I was using yesterday, I'm getting "!! ERROR: No root file system" and then "No root file system is defined." at the partition stage. I've tried the externally powered disk I was using weeks ago, and hopefully reverted everything else I've changed.
<rbasak> jamespage, GrueMaster: ^^?
<xranby> ogra_: basically looks like we are testing the 2.15 release http://sourceware.org/ml/libc-alpha/2011-12/msg00085.html
<xranby> doh.. i though that statement want out yesterday
<xranby> its a 1 old month news entry
<doko> ogra: please just run it for a while
<doko> a week or so
<doko> xranby, yeah, I need to fix this, dependency issue, but the locales get regenerated later anyway
<doko> well, there are some neon optimized string operations like {str.mem}{cpy,mov,cmp}
<ogra_> doko, well, i'm running on my ac100, NEON wont actually gain me much i think, is it still worth the test for you ?
<jamespage> rbasak, not tried since I had to manually hack mine yesterday
<jamespage> have been watching hadoop crash :-)
<doko> ogra_, yes, just to know any issues with 2.15 vs. 2.13
<ogra_> k, no prob then, i'll keep it running ans scream and shout if it breaks :)
<GrueMaster> rbasak: I'll try it here and see if it fails.
<rbasak> thanks
<GrueMaster> rbasak: I think it isyour settings.  I'm well past the partitioning, and into the base installer section now.
<GrueMaster> Although it looks like a kernel meta was updated before a new kernel was released into the pool.
<ogra_> the kernel was released around tuesday or so
<ogra_> not sure d-i has been uploaded to use the new kernel yet
<GrueMaster> turns out it was a different (but odd) issue.  netinstall was failing to resolve my mirror sewrver when installing the linux-headers packages.  very odd.
<ogra_> aww
<rbasak> GrueMaster: ok, thanks for testing
<GrueMaster> rbasak: I am still experiencing issues.  Not what you are seeing, but very odd behavior.
<rbasak> GrueMaster: I have been getting various panics, though that may be a power problem
<GrueMaster> I'm seeing that too.  Trying to capture a log now.
<jeremiah> Is David Duffey here?
<GrueMaster> What I'm seeing is it fails at the kernel installation.  Log shows issue resolving my mirror.  Kicking it moves forward, but fails again with a failure to create /etc/resolv.conf.  Then segfault.
<infinity> GrueMaster: You may want to bring it up with stgraber.  He's been mucking with fixes from resolvconf fallout.
<GrueMaster> http://paste.ubuntu.com/819007/ is the segfault.
<stgraber> GrueMaster: Colin just fixed a similar issue in ubiquity
<GrueMaster> interesting.  Odd that this only just started happening yesterday.
<infinity> Yesterday was when the overrides got fixed to get resolvconf in important (and, by extension, in ubuntu-minimal)
<infinity> So, that timing seems right.
<infinity> Before said change your netinsts wouldn't have been installing resolvconf, I imagine.
<rbasak> I just tried armel oneiric with exactly the same config, preseed, kernel opts etc, and it has gone past the problem partitioning stage with no issues.
<rbasak> I think perhaps the panics I've been seeing over the last few days aren't a power issue as I thought, but a kernel issue
<rbasak> There are a few different points where I seem to get different types of panic (from observation, I've not been logging)
<rbasak> So something causing what appears to be pretty non-deterministic behaviour/failures
<GrueMaster> Mine falls over exactly the same way on 2 different systems.  Both well past the partitioning though.
<rbasak> I quite often get a panic straight after the kernel loads, at around the point syslogd (?) starts
<infinity> janimo: Regarding bug 922558, are you actually suggesting LP collect current package info for every buildd and publish that, or did you mean to file that as an RT?
<ubot2`> Launchpad bug 922558 in launchpad-buildd "Page listing Ubuntu and kernel versions on ARM builders" [Undecided,New] https://launchpad.net/bugs/922558
<stgraber> GrueMaster: I'm running an amd64 netinstall now to confirm it's broken, then will look at a fix (after schroot, lxc, LTSP and ubiquity are fixed)
<infinity> janimo: (Note that indivudual build logs contain exactly the info you're looking for...)
<GrueMaster> ok
<rbasak> I don't know why it didn't occur to me to try an oneiric armel install to test my setup before. Now I can take my power hacking out of the equation
<GrueMaster> stgraber: We wouldn't want you to get bored.  :P
<stgraber> GrueMaster: at least we only got install/build time problems, nobody reported breakage for existing systems :)
<GrueMaster> Oooh, I haven't tried breaking my running installs.  Thanks for the suggestion.  :P
<stgraber> :)
<rbasak> I think I was stressing this kernel on a running install fairly hard the other day, and it didn't break
<rbasak> not the latest kernel though
<rbasak> or maybe it was
<rbasak> that's not really any use is it?
 * rbasak shuts up
<rbasak> Just found a USB power injection lead: http://linitx.com/product/12849 - similar to what I made up, but I don't know if it keeps the host connected on 5V or not.
<rbasak> "Cannot allocate irq_descs @ IRQ16, assuming pre-allocated"
<rbasak> http://paste.ubuntu.com/819067/
<rbasak> Is this important?
<GrueMaster> Nice.  I'll bet they have feedback diodes to prevent power pull to host.
<rbasak> I've ordered one, will receive Tuesday
<GrueMaster> That failure looks like what I am seeing.
<rbasak> http://paste.ubuntu.com/819072/ is the most common failure I'm getting right now - no changes, just another run. No panic.
<rbasak> A different type of panic: http://paste.ubuntu.com/819082/
<rbasak> Only changed was that I add DEBIAN_FRONTEND=text
 * rbasak brushes up on the english language
<rbasak> Only change was that I added DEBIAN_FRONTEND=text
<rbasak> This time I seem to have a random hang after "Starting system log daemon: syslogd, klogd."
<rbasak> Another panic, looks like the same as one of the previous ones: http://paste.ubuntu.com/819098/
 * rbasak gives up for now
<rbasak> EOD. Enjoy your weekend when it starts!
#ubuntu-arm 2012-01-28
<scientes> what type of support is there in linux for the graphics in the ARMADA 500 (d2plug)
<scientes> and can i do multiseat with it
<janimo> infinity, yeah a RT request would probably make more sense. Just to know when some kernels are new enough so some patches can be dropped from packaging.
<janimo> infinity,  I associate RT with internal stuff, whereas this should be public info imho, in the case community members want to fix said packages
<infinity> janimo: Like I said, the build logs have the kernel versions in them.  And as I commented on the bug, the days of buildds with many different kernels should be numbered.
<nOStahl> hows it going guys
<nOStahl> anything new?
#ubuntu-arm 2012-01-29
<scientes> anyone know if there is full OpenGL drivers for the ARMADA 500?
<scientes> or just OpenGL ES 2.0
#ubuntu-arm 2013-01-21
<dholbach> good morning
<mvt007geek> hey guys please help me/. i wrote ubuntu on sd card but panda doesn't boot it.and serialport shows nothong
<mvt007geek> i mean pandaboard
<V155> mvt007geek: do you also copied the kernel image into the bootsector? On my arm platform (but not panda board) this is needed
<mvt007geek> all i did to sdcard was this: dd if=ubuntu-12.04-preinstalled-desktop-armhf+omap4.img of=/dev/sdb
<V155> mvt007geek: perhaps you will find your answer here: http://www.eewiki.net/display/linuxonarm/PandaBoard
 * [mbm] has seen issues before where people try to use mobile phones and other linux devices as sd card writers, ends up mangling the write
<Ethernin> Hey all you awesome devs in here, the latest raring build for the nexus7 seems to be pretty broken...
<Ethernin> after flashing with fastboot, the installer is pretty fubard...
<Ethernin> the display behind the installer is totally whacked white multi-colored
<Ethernin> and once you get to the user setup things constantly freeze especially when you try to type a user name...
<Ethernin> bueler?
<Ethernin> :P
 * xnox is sad, because I couldn't find my ac100 charger over the weekend =(
<ogra_> xnox, i think thinkpad chargers work for the ac100, iirc infinity used that in the past
<xnox> ogra_: i don't own thinkpads.... but my housemate does.... i think I know the culprit that stole my charger now.
<xnox> thanks a lot =)
<ogra_> haha
<ogra_> yay, so i have a working implementation of a rotation daemon in shell
<sveinse> What is the logic of dpkg triggers? I have a set of packages where each activates the update-initramfs trigger. However I see that update-initramfs is run multiple times. Isn't this what triggers should prevent?
<ogra_> janimo, fyi ... i just uploaded http://paste.ubuntu.com/1555763/ as an interim solution
<ogra_> (ubuntu-devel mailed as well)
<janimo> ogra_, excellent thanks!
<ogra_> it is far from perfect, eats quite some CPU
<janimo> if it is dash it may not even have such a large mem footprint
<janimo> but I did not check except with an empty dash script in a loop
<ogra_> "read" is slighly lighter than using $(cat ...) ... whgich spawns a subshell
<janimo> meanwhile I am discussing and looking into g-s-d to see if it is feasile to have it there in C
<ogra_> but still far from what a simple read from C would do
<ogra_> i found it more important to get something out to the user though so this will do for a start
<janimo> I agree
<ogra_> i guess we need to step on some compiz devs toes though
<ogra_> the rotatin is so sloooow
<ogra_> *rotating
<ogra_> it gets a bit better if i change the sleep to .3 or .5 .... but that costs a lot more CPU
<janimo> slow as in noticable latency?
<ogra_> slow as in ... as slow as your GO variant
<janimo> or the redrawing?
<ogra_> yeah
<ogra_> i'm pretty sure thats compiz
<janimo> but the redrawing is not helped by making more freequent wakeups
<janimo> that's why I was not clear what you meant
<ogra_> ah, k
<ogra_> yeah, changing the sleep value wont fix the redraw slowness
<ogra_> but makes it feel more responsive
<ogra_> anyway, while it is cool that we can use portrait now, not having input doesnt rellay help :(
<janimo> ogra_, completely broken input in unity in all but the default rotation you mean right?
<ogra_> right
<janimo> ogra_, in lubuntu redraws seem a bit faster
<ogra_> heh, for sure
<janimo> and input works too
<ogra_> i thought so
<ogra_> janimo, why did you mark bug 1077062 as fix released ?
<ubot2> Launchpad bug 1077062 in ubuntu-nexus7 "upower says battery is charged when it is not" [Medium,Fix released] https://launchpad.net/bugs/1077062
<ogra_> i still see massive power manager issues here
<ogra_> i frequently get something like "Only 7min of battery life left (100%)"
<ogra_> and if it is actually at a low level after a few hours i get the "will suspend soon" message constatly flashing on and off
<janimo> ogra_, IIRC the issues I think we see were not the ones actually mentioned in that bug
<ogra_> oh, ok
<janimo> at least not what the subject says
<janimo> I know there are a few power related bugs
<janimo> but they need to be separate and specific and I thinkg a few still remain open
<ogra_> well, the fun is that i didnt see any such bugs in quantal
<ogra_> i wonder if there are kernel config issues
<ogra_> two devices for the same thing or some such
<ogra_> hmm, upower -d shows me a /sys/devices/platform/tegra-i2c.4/i2c-4/4-0055/power_supply/usb ... as well as an "ac" device
<ogra_> i wonder if the usb one was there in quantal
<Guest61343> Asking simple questions and getting a simple answer from search engines seems a thing of the past but would anyone know if ubuntu was installed on a raspberry pi would only packages designed for the pi work?
 * Tassadar erases the answer he just wrote and shakes his fist angrily at Guest61343
<AmEv> Back for more.... Got a working rootfs for sure.
<AmEv> Any kernel thoughts lilstevie?
<AmEv> Or anyone else...?
#ubuntu-arm 2013-01-22
<dholbach> good morning
<jodh> I've updated the wiki with details of dual-booting with MultiROM: https://wiki.ubuntu.com/Nexus7/Installation#Details_of_installing_MultiROM_and_Modified_Recovery_to_Enable_Dual-Boot. Would be great if someone could "test" this section (and maybe add screenshots ;-)
<dholbach> jodh, I made a tiny few little changes to the doc: https://wiki.ubuntu.com/Nexus7/Installation?action=diff&rev2=28&rev1=27
<dholbach> jodh, trying to boot raring-preinstalled-deskto give me "Error - Kexec-hardboot support required to boot this ROM. Use kernel with kexec-hardboot support. Touch anywhere to close"
<dholbach> booting "Internal" seems to work though
<jodh> dholbach: sounds like you forgot to flash the kexec kernel (step 25).
<dholbach> weird - let me retry
<jodh> dholbach: you can go back and do that now if you boot into the bootloader, then into recovery and select MultiROM.
<dholbach> let me try
<dholbach> jodh, that made it work - perfect
<jodh> dholbach: great! :)
<dholbach> ogra_, looks like the background is still corrupted during oem-config - also onboard was hidden by the wifi dialog, so I couldn't enter anything in there
<dholbach> hum, I can't enter anything at all?
<ogra_> dholbach, both known issues, i wonder if we should switch back to metacity
<ogra_> a reboot fixes the input issue
<dholbach> do we have bug reports for both?
<ogra_> i think so
<dholbach> can't find either of them
<ogra_> bug 1093050
<ubot2> Launchpad bug 1093050 in ubuntu-nexus7 "OnBoard doesn't work on text boxes during initial setup" [Medium,Incomplete] https://launchpad.net/bugs/1093050
<ogra_> is the input one
<dholbach> ah yes, I must have overlooked that one
<ogra_> bug 1080437 is one incarnation of the other issue
<ubot2> Launchpad bug 1080437 in ubiquity (Ubuntu Raring) "no background during the 13.04 daily install" [High,Confirmed] https://launchpad.net/bugs/1080437
<ogra_> or bug 1088692
<ubot2> Launchpad bug 1080674 in cairo "duplicate for #1088692 [QEMU] Corrupted desktop screen for raring desktop installation in QEMU guest (Cirrus graphics). Affects KVM but not VBox." [Medium,Confirmed] https://launchpad.net/bugs/1080674
<dholbach> ah ok, I was just looking at https://bugs.launchpad.net/ubuntu-nexus7 nevermind
<ogra_> or it could be bug  1081260
<ubot2> Launchpad bug 1081260 in ubiquity (Ubuntu) "/usr/lib/ubiquty/wallpaper crashes after boot of livecd" [Undecided,Confirmed] https://launchpad.net/bugs/1081260
<ogra_> not sure about that one, but it is cosmetic anyway
<ogra_> the input one is worse
<ogra_> jodh, be very careful about the dual boot images, afaik the userspace has some very heavy hacks, i'm not sure we can accept bugs from such an install
<xnox> I managed to get a wallpaper to work - instead of wallpaper use gnome-settings-daemon to paint the wallpaper, which doesn't help derivatives =(
<ogra_> jodh, in fact i would prefer if we would not have any instructions on the wiki that make them look official and just have the XDA link instead so people grok it is some modified third party image
<ogra_> xnox, well the input stuff is more worrying than shiny wallpapers :)
<ogra_> (which we could just call modern art :P )
<jodh> ogra_: feel free to remove them if you wish. I appreciate there are risks, but I thought I'd share as imho it might encourage more to explore Ubuntu on the Nexus if they could keep the existing image.
<dholbach> yes, we had a number of requests already
<dholbach> what kind of "heavy hacks" were you referring to?
<jodh> ogra_: added to which, the existing instructions on dual-booting that I'd found on the web were confusing at best ;)
<jodh> ogra_: just a thought - if we keep the instructions, is there any way we could have apport detect that the Ubuntu image was booted via kexec and thus flag any bugs raised as "potentially tainted" (particularly useful for kernel bugs I guess).
<ogra_> dholbach, look at the xda thread
<ogra_> i havent inspected them
<ogra_> until someone has i wouldnt recommend that image on the official install instructions
<reisei> hi, all! Can I access the Nexus 7 accelerometer from Ubuntu? I need to get the values,
<Tassadar> reisei: take a look at http://bazaar.launchpad.net/~jani/+junk/nexus/view/head:/nexus.go
<Tassadar> accelerometer is used in there to rotate the screen
<reisei> Tassadar: but I need just the values :)
<Tassadar> that's why I said take a look, there is the path to accelerometr data in there
<Tassadar> this looks like it's folder: /sys/bus/iio/devices/iio:device0/
<ogra_> Tassadar, long outdated
<ogra_> the images already have accel support
<Tassadar> well yeah, I just wanted to show him how to access the data, and it is pretty easy to see in that code
<ogra_> reisei, make sure to have the latest ubuntu-defaults-nexus7 package installed, it ships accelerometer support
<ogra_> in /usr/bin/acceld is the very simple shellscript that reads the values
<Tassadar> oh, okay
<ogra_> i'll add something similar for the ambient sensore the next days
<ogra_> *sensor
<reisei> ogra_: thanks!
<reisei> Tassadar: thanks too!
<plars> ogra_: hi, around?
<plars> ogra_: we talked last week about having a fully installed image for n7, is that available now?
<ogra_> plars, sorry, i'm a bit behind but working on it
<plars> ogra_: no worries, any ETA?
<ogra_> but you wouldnt have any fun with it anyway until we have images again ...
<ogra_> seems the livefs builder park is moving or so, the last three image build attempts failed and #is couldnt give me an ETA
<plars> ogra_: ah, I saw there is no image since 20th, but wasn't sure what was wrong
<ogra_> plars, i plan to have the code ready and uploaded tomorrow during my day, but you will need the stuff built into the image to use it
<plars> ogra_: ok, sounds good
<ogra_> with luck they are back again tomorrow, i'll make sure you get an image with the bits inside once they are
<jragon> Hi
<ogra_> achiang, bug 1103000, do you remember why we dropped that patch ? i forgot why, i just remember many things were broken when we tried
<ubot2> Launchpad bug 1103000 in ubuntu-nexus7 "Need to charge from USB hub with power connector" [Undecided,New] https://launchpad.net/bugs/1103000
<achiang> ogra_: hm, i think it caused hangs
<achiang> ogra_: like it broke the rest of USB
<achiang> ogra_: but janimo would know for sure
<ogra_> oh, right, i remember now, yeah, it broke the whole USB stack
<ppisati> how do i tell flash-kernel to install my $dtb?
<ogra_> ppisati, i doubt it has any DTB support at all yet
<ppisati> ah
<ogra_> apart from kernels where you cat'ed the dtd at the end
 * ppisati wonders again why we updated flash-kernel...
<ppisati> ogra_: attached dtb is not an option for multiplatform
<ogra_> ppisati, indeed
<ogra_> ppisati, file a whishlist bug ... some code how you would do it manually would also help
<ogra_> i'll try to get to it
<ppisati> ogra_: i'll do once i push my fist multiplatform kernel (probably tonight or tomorrow)
<ogra_> k, thx
<ogra_> ppisati, and we updated because the former version was even more painful
<ppisati> ogra_: the previous version had more stuff hardcoded, but it had DTB support
<ppisati> ogra_: i just decided to update my im6x to latest flash-kernel to try it out
<ppisati> ogra_: and it was a bad decision :)
<ogra_> i could have told you :P
<ppisati> anyhow
<ppisati> it i like the /usr/share/flash-kernel/db/
<ppisati> s/it//
<ppisati> */usr/share/flash-kernel/db/ thing
<ogra_> yeah, thats the biggest benefit the upgrade brought us
<Tassadar> ogra_: should I add ubuntu-nexus7 as affected project to bug 1089038? It is relevant mostly to nexus 7, and now it is just sitting among all other bugs in initramfs-tools package
<ubot2> Launchpad bug 1089038 in initramfs-tools (Ubuntu) "[PATCH] Add support for booting from subdirectory in root" [Undecided,Confirmed] https://launchpad.net/bugs/1089038
<ogra_> well, its a pretty generic initramfs feature, i dont thinnk its nexus7 related
<Tassadar> okay, I just felt like I should try to push things a bit from time to time
<ogra_> well, the review team is subscribed, no need for making noise
<ogra_> it will be in the sponsoring/reviewers queue
<ogra_> though your chances are likely higher to get it in if you send it to debian, it adds additional delta to debians initramfs-tools
<ogra_> which ubuntu will have to maintain
<Tassadar> I've sent it to ubuntu because I use it in my multi-boot tool, but it also needs the loop option (mounts image as root), which is only in ubuntu
<ogra_> yes, still, its a burden ubuntu would have to carry
<ogra_> having it in debian will get it us for free
<Tassadar> maybe I could send both to debian....
<ogra_> right, that surely makes things easier on the ubuntu side
<sim590> Anyone's got an idea why a partition table would just disappear?
<sim590> I just booted my TF101 today and my partition table was gone..
#ubuntu-arm 2013-01-23
<dholbach> good morning
<czajkowski> ogra_: I hate to be apain but - http://ubuntuone.com/3Hmktiws4Z1qhaXs35B5PL
<czajkowski> have rebooted it 4 times still stuck here any ideas?
<ogra_> czajkowski, have you checked the a11y settings ?
<czajkowski> ogra_: I cant get the dash up
<ogra_> use the ceg
<czajkowski> when I click on the big ubuntu bittn it just gives the icon text dash home so cant change any settings
<czajkowski> ceg?
<ogra_> use the menu on the top right :)
<ogra_> the gear
<czajkowski> all frozen :(
<czajkowski> each reboot still leaves it on the page to enter in my wifi code
<ogra_> try to cancel the wlan dialog, could be that it grabs the focus
<czajkowski> narp :(
<ogra_> you mean it doesnt take any input there either ?
<ogra_> (for the cancel button)
<czajkowski> nope wont cancel it
<czajkowski> nothing seems to want to close for me
<ogra_> that sounds like a completely frozen xserver
<czajkowski> indeed
<czajkowski> bit of a pita :(
<ogra_> when was that installed ?
<ogra_> recent images have a serial console running on the usb port
<czajkowski> few months back
<czajkowski> before xmas
<ogra_> hmm, not sure when i added that
<ogra_> you could try to plug it into a PC and check demsg for creation of something like /dev/ttyUSB0
<czajkowski> ok cheers will do when I get a lull in work
<czajkowski> thanks ogra_
<czajkowski> need to fix it by fosdem times as dont wnat to lug laptop
<ogra_> with the working rotation and todays xorg fix its nearly usable
<janimo> FYI the Tegra3 Technical Reference Manual seems to be available in the nvidia dev zone/tegra dev programme. I just noticed today, it may be old news
<janimo>  the realtek sound codec on the nexus7 has no public datasheet though
<czajkowski> something hates me :( http://ubuntuone.com/0S97eFdCGOGC1Dk6mEeFlZ
<ogra_> janimo, well, there must be something in pm-suspend that makes it work, i wonder if some sub modules are unloaded and re-loaded ...
<ogra_> havent found the time to inspect what the scripts do
 * ogra_ just uploaded onboard changes ... we now have proper docking in place
<ogra_> and the power button will suspend by default
<ogra_> janimo, did you upgrade to latest xorg already ? it makes input work in portrait
<janimo> ogra_, did not upgrade yet today, looking forward to test the new x stuff though
<ogra_> the "button 1 gets stuck" issue is still there
<ogra_> but portrait works the same way as landscape now
<janimo> I have been looking at the sound/suspend issue yesterday, no progess though, just seeing the different register values, comparing to android and staring at the code
<janimo> ogra_, the button stuck issue is our showstopper
<ogra_> well, i'm busy adding the preseeding stuff to the installer ... once i'm done with that i'll take the time to look into what pm-utils does
<ogra_> i think it unloads many of the snd_ modules
<ogra_> if we could mimic that behavior on first boot it might or might not work :)
<ogra_> eeek, MS buys dell !
<lilstevie> hm
<lilstevie> ogra_: nasty
<RaYmAn> isn't it only rumors still? And probably only a relatively small part
<ogra_> i just read news that it was a done deal
<RaYmAn> got a link?
<ogra_> only german
<Rjs> I noticed some touchscreen&grab-related patches in the xorg-devel list a few days ago, I wonder if they would be enough to fix the "button gets stuck" issue? (I don't know enough of the details to know...) http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/34653
<ogra_> RaYmAn, happy google translate :P http://www.golem.de/news/windows-lizenzen-microsoft-will-milliardenanteil-an-dell-kaufen-1301-97090.html
<marvin24> " ... licenses for future tablets" ?
<marvin24> I though Dell announces to quit tablet and smartphone business
<marvin24> *thought
<lilstevie> marvin24: android tablet
<marvin24> ah, we failed in a booming market - let's try some dead end one?
<marvin24> janimo: I started to package a 3.8 kernel for tegras
<marvin24> how do I add modules to the ABI ?
<janimo> ogra_, our sound is not modular, so unlikely it is due to module reloading
<janimo> marvin24, adding modules? Does it error on build?
<marvin24> (sorry for the dumb question)
<marvin24> janimo: yes,
<marvin24> it compares module file from old abi
<marvin24> and fails, because new abi has different modules
<janimo> marvin24, you should just add an ignore.modules or modules.ignore (I always forget) file
<janimo> let me check
<marvin24> I think this is defined already, but I'll also check again
<janimo> I wish there was a global 'Never check ABI GTFO' option on kernel builds
<marvin24> there is a ignore.abi
<janimo> and always just bump ABI by default, as it is the case almost always in my experience
<janimo> touch abi/3.5.0-17.27/armhf/ignore.module
<janimo> but use the actual current ABI dir
<marvin24> janimo: ok, thanks - will give it a try
<janimo> I am here if you have further questions and glad you work on this. It would be great to have a 3.8 tegra kernel in the archives
<janimo> and switch ac100 to it
<marvin24> well, it should run on any tegra2 or tegra3 device
<marvin24> if you tell u-boot the correct device tree
<janimo> right, but test on ac100 first as we have the device and the developer :)
<marvin24> sure ;-)
<marvin24> janimo: btw, is it possible to build a kernel package on launchpad - I read something about a 4 hours limit ...
<janimo> marvin24, it should be possible but I don't know if there are public armhf builders
<janimo> I know I used to test on an internal PPA
<janimo> ogra_, ^ ?
<marvin24> well, I already build some packages for arm ...
<ogra_> czajkowski, ^^^
<marvin24> he he, that's done already
<janimo> ah ok then. I did not know about time limit, although 4 hours usually was enough for panda and ac100 kernels AFAIK
<marvin24> https://launchpad.net/~ac100/+archive/ppa
<czajkowski> ogra_: you pinged
<marvin24> I just don't want to fall from grace
<janimo> nice.
<marvin24> czajkowski: all ok
<czajkowski> grand
<marvin24> czajkowski: is it ok to build a kernel package on armhf
<janimo> marvin24, neh just try and if there's a limit we should bump it up instead of penalizing the uploader
<janimo> there may be limits so the ppa is not hogged but a kernel build is a desirable use-case
<marvin24> I was told not to upload package which run more than 4 hours, that's why I ask
<czajkowski> marvin24: it's not on my list of not to enable - but as long as it's not more than 10 builds and greater than 4 hours
<janimo> marvin24, https://launchpad.net/ubuntu/+source/linux-ac100/3.1.10-6.10/+build/3962084
<janimo> slightly over 2 hours
<czajkowski> https://dev.launchpad.net/CommunityARMBuilds
<marvin24> janimo: that's not a complete kernel I think
<janimo> you mean not completely configured ubuntu kernel?
<marvin24> yes, maybe many modules missing
<janimo> right, ac100 does not have full ubuntu configs
<marvin24> it takes one hour on my dual core 2.6 GHz machine
<marvin24> I just used the omap config ...
<janimo> maybe a ti-omap4 build is more relevant
<marvin24> and also enabled PCI (which omap doesn't have as it seems)
<janimo> czajkowski, does that mean the ARM builds are not automatic based on a dput but need to be manually requested for each upload?
 * marvin24 still doesn't get why we need to enable all possible modules instead of all useful ones
<janimo> https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4046784
<janimo> yes over 4h
<janimo> the PPA builder you linked to currently builds an origen kernel and it is past the 3 h mark. So building kernels should be doable there
<marvin24> janimo: AFAIK, the ppa needs to be enabled one time
<janimo> marvin24, if a module is really unlikely to get used on the ac100 feel free to disable
<marvin24> I meant in general
<janimo> we started with minimal but a lot of USB and network options are required for various people's corner cases
<marvin24> e.g. you don't need all the regulators and mfd which are specific for each soc
<janimo> and since it is a module it does not affect those who do not used them, just build time
<janimo> right, if some options do not make sense they should not be there indeed
<janimo> hw support for impossible setups
 * marvin24 didn't count how many kWh he wasted already for building useless modules where the packaging failed in the end
<xnox> ogra_: do we have serial number patters or device models ids for nexus-ses to destinguish 8/16/3g models?
<ogra_> xnox, yeah, ask vanhoof or mfisch, i think they figured them out for the zenity installer
<xnox> ogra_: ok. I'll just poke the source then ;-)
<ogra_> you can request info via fastboot
<mfisch> xnox: vanhoof did all that magic, but I think he used the partition info
<xnox> mfisch: sounds about right.
<xnox> http://paste.ubuntu.com/1563337/
<xnox> ogra_: mfisch: fastboot getvar all output for my nexus7
<ogra_> right, just grab the userdata partition and de-hex the size
<mfisch> yep
<ptl> hello :)
<Wing_Z> Hi all
<Wing_Z> eny body could please lend me a hand obout pinmuxing on omap4?
<thoomaas> hello
<vhadil> hello
<thoomaas> i have problem with playing mp3 in raspbian
<thoomaas> omxplayer work but nothing else
<XorA> raspbian is not ubuntu
<thoomaas> i know but no body answer to me in another rooms
<XorA> I dont know the answer, dont have a Pi
<Noskcaj> are there install instructions for ubuntu on nexus somewhere?
<Tassadar> Noskcaj: https://wiki.ubuntu.com/Nexus7/Installation
<Noskcaj> thanks
#ubuntu-arm 2013-01-24
<dholbach> good morning
<ogra_> janimo, heh, i have what i think is the worst workaround i ever found ... for the sound init
<ogra_> an upstart job with: rtcwake -u -s 1 -m mem
<janimo> I am also looking into it
<ogra_> costs 1sec boot time and makes the screen flash once during boot
<janimo> and it works if I enable HDA_INTEL
<ogra_> (its a 1sec suspend)
<janimo> but volume if off on start
<janimo> I need to see how to turn that on by default on boot,
<ogra_> that should be solvable by a ucm setup
<janimo> I tried amixer calls and to no avail
<janimo> only from control center
<janimo> but it looks like INTEL_HDA should be on (it is in Android) even if the hw does not seem to have HDMI connectors
<ogra_> you need to unmute the left and right channel of the speaker control separately i think
<ogra_> why did we switch it off again ?
<ogra_> i remember diwic asked for it to be off
<janimo> right, I tried sudo amixer -c 1 cset numid=1,iface=MIXER,name='Speaker Playback Switch' 1,1
<janimo> no idea, the whole ALSA stack confuses me
<janimo> what are controls and simple controls, are they both neede, is controls a superset?
<janimo> so many ways to set alsa (alsactl restore, amixer, alsamixer, control-center)
<janimo> the fact there are 140+ controls is of great help as well :)
<ogra_> yeah, thats awesome, isnt it ? i bet you could turn the nx7 into a recording studio if you could attach the right peripherials :P
<janimo> no idea what those things do, or why are they all exposed.
<janimo> and I thought the ac100's sound options were complicated
<ogra_> haha
<janimo> I'll send a config patch to kernel devel and then see how to debug further but should hopefully only be some alsa config file tweaking
<janimo> and the card becomes the second, as hda will be card0
<janimo> as in Android
<janimo> never heard of rtcwake before, good to know
<ogra_> check the chanelog first, there was a reason why diwic wanted it off
<janimo> yes, he just said it is useless as we do not have HDMI
<ogra_> hmm, k
<janimo> but it is on in Android and seems to be needed for suspend
<ogra_> as long as it doesnt cause mad wakeups etc
<janimo> it was just pruned as poart of simplifying config
<ogra_> yeah, then switch it on again
<ogra_> oh, btw i uploaded an ambient light script as well yesterday
<janimo> it is probably just a tegra hw bit that needs to be poked for proper audio suspend even if not connected to anything
<janimo> great
<ogra_> only GPS and camera missing :)
<ogra_> oh, and BT needs another deep look
<janimo> yes, camera is looked at by nvidia (not sure of the status but I am talking to the dev - our own Bryan Wu)
<janimo> is cyphermox on BT and GPS? (and NFC) ?
<ogra_> hehe
<ogra_> do we have NFC ?
 * ogra_ wasnt aware
<janimo> yes the device has it, fw in the blob collection
<ogra_> and no idea about cyphermox, but we will have some -desktop attendance on friday
<janimo> not too important I'd say, webcam is the real important one
<ogra_> right and the xinput bug
<janimo> yes, the webcam sensorwise, xinput overall showstopper
<ogra_> its not that bad, if you make sure to actually leave time between taps
<ogra_> i get through for a whole evening if i tap really carefully
<ogra_> i wonder if we could somehow just turn down the sensitivity to work around it
<sveinse> How is the update-initramfs triggers supposed to work? When installing precise on my armel target, I see a few packages that "update-initramfs: deferring update (trigger activated)" like it should. But after the kernel has been setup, all packages installed which triggers update-initramfs all makes update-initramfs run. Many times. Is this how it should be?
<ogra_> depends, packages can force a trigger execution
<sveinse> What can I do to debug this thing?
<ogra_> well, read about triggers i'd say :)
<sveinse> Well I don't see any difference in the triggers in the packages that run and defers and those which runs it immediately
<sveinse> If I do remember correctly, the kernel runs /etc/kernel/(pre|post)(rm|inst).d/ and thus forces update-initramfs to run. Could this be altering the behaviour of the triggers somehow?
<sveinse> I'm not enlightened by the dpkg-trigger documentation.. But you haven't seen that update-initramfs is run multiple times during installation on your systems?
<infinity> sveinse: I generally only see it run multiple times when an apt run gets split into several dpkg runs to break loops or satisfy pre-depends, etc.
<infinity> sveinse: A good indicator of that is often seeing the "Reading dpkg database... " stuff in your terminal backscroll.
<infinity> sveinse: Triggers can't carry between dpkg invocations (for, I hope, obvious reasons), so you'll sometimes get more than one trigger from the same package in an apt run.
<sveinse> infinity: No, I dont think my runs are between dpkg invocations. It's all in the "Setting up ..." section
<infinity> If it's a big long string of postinsts, yeah, I'd probably have to see it to debug what's happening.
<infinity> It could be a dpkg bug, or it could be initramfs-tools' trigger is goofy.
<infinity> Or it could be postinsts of certain packages calling it wrong.
<sveinse> How does dpkg decide when to run a trigger?
<infinity> (The kernel forces it to run triggerless, but that's a different story)
<infinity> Normally, it runs them at the end of a dpkg invocation, based on registered interest or delayed triggers (the latter, in the initramfs-tools case).
<infinity> Anyhow, not going to get into this at 3:30am.  But if you have some terminal logs that show the offending behaviour in action, feel free to reference them in backscroll, or file a bug and reference that or some such.
<infinity> Just don't be offended if I decide to close it as invalid after looking into it. ;)
<sveinse> What it seems in my case is that a few packages triggers it, then dpkg runs the trigger. One more or sometimes two triggers it, dpkg runs the trigger once more.
 * janimo just managed to get something that sounds like a drunk and angry R2D2 out of the nexus7 by randomly toggling things in alsamixer
<janimo> need a way to turn it off, it persists across reboot
<sveinse> infinity: Well, I'm more like grateful. I've been struggling with this for a while now
<dmart> janimo: you want to be careful with that ... I know someone who literally melted his chromebook by toggling alsamixer switches...
<janimo> dmart, yes, I had read hrw's account
<janimo> for a moment I had feared I may damage the speakers too
<hrw> janimo: ucm profiles for chromebook are present in raring and in sru queue for precise/quantal
<janimo> but it's back again now
<janimo> hrw, I have no chromebook, it is the nexus7 that I was toggling alsa settings on
<hrw> ah
<dmart> hrw: Are the ucm profiles purely a userspace thing?
<hrw> yes
<dmart> janimo: really, it feels like the kernel should police any settings which can actually damage the hardware...  but I don't know enough about alsa to know how to do that.
<dmart> hrw: ^
<hrw> I need to update kernel as some fixes went to kernel
<janimo> dmart, I agree, but maybe some hw can be broken in so many ways the kernel cannot catch all cases. No idea really
<janimo> this may have been a simple bug/oversight, hrw?
<dmart> It's possible I am missing some fixes ... I haven't updated for a bit
<janimo> just like one could fry monitors with VGA poking, there may be root-only things that can damage modern hw
<hrw> janimo: they fucked up "ASoC machine" source
<dmart> janimo: sure, but that's still a bug in my view.  I thought the ucm profiles were more about presenting the mixer settings in a more intelligible way, since the hardware-specific mixer config can be pretty complex
<janimo> I know little about ALSA too, learned some the past two days but am still bewildered by the large number of concepts and config options
<hrw> so you can connect wrong parts of audio chip to output
<dmart> hrw: My guess was that the likely problem is that the hardware mixer allows you to connect two SoC outputs to the same analog sink
<hrw> dmart: and one of them is digital iirc
<dmart> hrw: oh!
<dmart> hrw: I wondered if bad things could be made to happen by, say, connecting the left and right DAC1 channels to a single channel of the speaker.  But I didn't really want to try that...
<hrw> dmart: check my blog for exact steps
<hrw> dmart: now my left speaker can only generate heat cause it is unable to generate sound anymore
<dmart> hrw: on the plus side, you can now use /dev/heat to make a novel user interface...
<hrw> dmart: but /dev/heat is symlink to /dev/stinkysmall
<hrw> dmart: but /dev/heat is symlink to /dev/stinkysmell
<sveinse> I have a custom deb package which installs a hook into initramfs. This hook relies on a file from /etc. Now when I install this package the hook is put into the filesystem early (when unpacking), yet the /etc file is put in late (when setting up I guess). However, update-initramfs is run by other packages in between these two steps and that makes update-initramfs bork since its missing the...
<sveinse> ...file from /etc. How should I deal with that?
 * xnox has just flashed nexus7 using... usb-creator
<pfui> what's the state of ubuntu on the samsung chromebook?
<pfui> any chance we'll have working video acceleration anytime soon?
<xnox> pfui: hrw does samsung chromebook stuff.
<pfui> xnox: hmm... seems to have a few relevant posts on his blog. thanks!
<reisei> hi, all! I need connect nexus 7 with ubuntu under Windows via terminal, but the system asks for driver... Which one  I need?
<Rjs> reisei: i'm quite ignorant about windows so not sure if this is up-to-date, but the linux kernel source has documentation at http://kernel.org/doc/Documentation/usb/gadget_serial.txt (search for "Windows")
 * ogra_ has no idea 
<ogra_> on ubuntu you can just run screen with the right args in a terminal ... or minicom, surprising that win needs actual drivers for a serial USB port
<Tassadar> you'll probably need to write your own, since nexus 7 has it's own vid and pid
<Tassadar> (meaning you'll have to write definiton file, which tells windows to use it's generic driver)
<ogra_> there is no generic usb serial drive in windows ?
<ogra_> *driver
<Tassadar> yes, but you'll have to tell windows to use it on that vid/pid - that's what windows calls "driver"
<Tassadar> it is in that doc Rjs linked
<Rjs> (I'm still ignorant but guessing:) the windows inf file that the documentation talks about is at http://kernel.org/doc/Documentation/usb/linux-cdc-acm.inf and seems to contain vendor and product IDs, so I guess you could change them there
<ogra_> ah
<Tassadar> yeah, should be as easy as that, had to do that for one ACM USB thingy already
<Tassadar> funny how that is "driver" for windows)
<Rjs> that file talks about something called usbser.sys, so I guess that inf file is really a configuration file for the generic driver named usbser.sys (I presume that's included in windows, since the doc doesn't speak about having to download it)
<Rjs> hmm, does the ubuntu nexus7 really have its own vendor/product IDs? as far as I can tell from my syslog, the vendor and product IDs in the inf file I linked to appear to be correct: vid 0x0525 and pid 0xa4a7 so I'm guessing that inf file should work as it is
<Rjs> my syslog has "New USB device found, idVendor=0525, idProduct=a4a7" from the time I still used the standard ubuntu kernel (I have later switched to the combined ethernet+serial gadget which has a different product id)
<Tassadar> maybe it doesn't, that vid is "0525  Netchip Technology, Inc." and pid is "a4a7  Linux-USB Serial Gadget (CDC ACM mode)"
 * Tassadar goes to look at that driver's source
<reisei> That's so opposite to linux simpicity...
<Tassadar> I don't get why they don't just use USB device class to find driver like Linux does
<Tassadar> yeah, the vid/pid is hardcoded
<Tassadar> apparently they donated some pids, "Thanks to NetChip Technologies for donating this product ID."
<Tassadar> then you can just use the driver as is :)
<wooy> Hi, I was recently thinking about getting an ARM device as my home server (irc, ftp, bittorrent, small http, etc). Cubieboard and some ODROID boards looks promising, but I even got as wild as thinking about Nexus 7.
<xnox> Rjs: those look different to mine.
<xnox> 484	+    'ID_VENDOR_ID': ('18d1',),
<xnox> 485	+    'ID_MODEL_ID': ('4e40', 'd001',),
<xnox> Rjs: ^^^^ for nexus7's i saw around.
<xnox> and that's just standard google / nexus7 id's.
<ogra_> dont mix up kernel and bootloader though ....
<xnox> ah!
<ogra_> the nexus reports different things in the different bootloader modes
<XorA> how dumb is that :-(
<ogra_> and kernel wise it matters what is actually bound to the gadget setup
<Tassadar> the pid is also different if you turn on/off the debug mode (adb)
<ogra_> XorA, not dumb, that whay the other end knows if it is in flash mode, media player mode recovery (with adb) etc etc
<ogra_> indeed under the assumption that you have a udev rule (or windows driver) that can handle that state
<Tassadar> and the g_serial driver has the pid/vid hardcoded in drivers/usb/gadget/serial.c, if you wanna take a look
<XorA> ogra_: there has to be a better way, making that sort of mess has no real justification
<XorA> ogra_: other devices work fine with constant ids
<ogra_> tell that to android
<ogra_> i dont think thats actually nexus7 specific
<ogra_> at least for the bootloader side
<XorA> its probably more a function of which lazy engineer did the integration
<ogra_> wooy, go with a board, the nexus7 would be a waste in such context
<ogra_> xnox, hrm, that upstart job is quite uglz
<ogra_> *ugly
<ogra_> xnox, and it will be executed for every USB device you ever plug in
<xnox> ogra_: well, very soon now we will have upstart user session.
<xnox> ogra_: then the job will move and run in the user session, if usb devices are plugged in.
<ogra_> yeah, still
<xnox> ogra_: the alternative I had was: udev-rules with RUN+=
<ogra_> i think having a udev rule that triggers something in the user session would be better
<xnox> apart from that cannot "spawn", if usb-creator is started the udev rules processing is blocked until usb-creator exits.
<xnox> another option is to have: udev rules which does "start usb-creator" to launch the upstart job.
<xnox> ....
<xnox> but that's like two hacks instead of one.
<ogra_> yeah, no, well ...
<xnox> ogra_: the trouble is that, udev runs at system level. And the hops to get DISPLAY & $uid are ugly =/
<xnox> ogra_: by the way upstart job is quicker to launch usb-creator than udev rule + shell wrapper
 * xnox has no idea why.
<ogra_> less subshell calls probably
<ogra_> still, i dont like to idea to fire off that job every time you insert a usb device
<ogra_> there must be a more elegant way
<ogra_> i wonder if there isnt a more fine grained way to use the event .... i.e. some kind of filtering
<xnox> =/ yeah that would be nice
<xnox> ogra_: anyway, I did ask james hunt to review it and see if he can offer something better.
<xnox> Note the bottom on upstart-udev-bridge manpage "This is a temporary tool until init(8) itself gains the functionality to read them directly; you should not rely on its behaviour."
<ogra_> yeah, well, we could have a udev rule that emits an event
<ogra_> so you filter on the lower level, and the upstart job just reacts to "nexus7-added" events
<ogra_> a udev rule with ... RUN+="initctl emit --no-wait nexus7-added"
<ogra_> we have that rule file already anyway
<ogra_> (or at least we should, for setting the udev-acl stuff to not need root access)
<janimo> marvin24_, is your 3.8 ac100 kernel working well?
<infinity> janimo: Thinking of updating raring to something modern?
<janimo> infinity, sure, if it works. marvin24_ said he's working on a 3.8 port
<marvin24_> janimo: yes, 3.8 works fine
<marvin24_> but building a kernel package takes weeks ...
<marvin24_> I hope I can upload something on the weekend or so
<janimo> marvin24_, great. Same gitorious repo?
<janimo> weeks really?
<janimo> do you have errors building it?
<marvin24_> janimo: it's still the kernel in my old repo
<marvin24_> https://www.gitorious.org/~marvin24/ac100/marvin24s-kernel/
<marvin24_> some modules failed, yes
<marvin24_> so I need to disabled them
<marvin24_> then I got abi errors
<marvin24_> turned out I need to specify "-eskipmodules"
<marvin24_> after several tries
<marvin24_> and each one is two hours and I'm doing it in my free time ...
<janimo> marvin24_, I used debuild with -nc
<janimo> so it does not clean the tree
<janimo> before rebuilding
<marvin24_> well, I use ccache (with --prepend-path=/usr/lib/ccache)
<janimo> marvin24_, do you know if nvidia keep some sort of wiki or updates on what is mainlined and what is pending for tegra2 and tegra3? An overview of sorts
<marvin24_> janimo: not that I know of
<marvin24_> I think they have an internal list
<marvin24_> but what's getting done, is mostly in a random order
<marvin24_> in fact, the most painful stuff missing is suspend/resume
<marvin24_> and more powermanagement stuff
<marvin24_> also some simple stuff just takes very long
<marvin24_> e.g. backlight support
<janimo> did graphics support land already?
<janimo> DRM
<marvin24_> yes, it's included in 3.8
<marvin24_> but without backlight, only hdmi works
<janimo> funny
<marvin24_> I think the backlight code is discusses for nearly one year now
<marvin24_> and still no conclusion
<janimo> do you know whether tegra2 or tegra3 is more completely supported in mainline?
<janimo> so you carry the backlight code in your ac100 branch?
<marvin24_> I think they are pretty inline
<marvin24_> yes, I just one of the discussed implementations
<marvin24_> but that's already outdated
<marvin24_> in fact, now they wait for some generic framework
<janimo> they have working 3.8 code for all things just not mainlined though?
<marvin24_> yes
<marvin24_> the way it needs to be integrated into kernel is, well, complicated
<janimo> ok, thanks. Checking your branch out now
<marvin24_> in fact, you just need to program some gpios
<marvin24_> but there is no generic interface for this yet
<marvin24_> and upstream does not like soc specific backlight ...
<marvin24_> very long, sad story
<janimo> marvin24_, does the 3.8 kernel require uboot or is the defautl ac100 bootloader enough?
<marvin24_> janimo: both should work, but need different configs
<marvin24_> fastboot needs cmdline from kernel and u-boot needs kernel command line from u-boot
<marvin24_> but I don't plan to support 3.8 kernels with fastboot
<marvin24_> 3.1 supports both
<marvin24_> janimo: http://tinyurl.com/b55syst
<marvin24_> this is what I have for now
<marvin24_> against raring 3.8 kernel
<marvin24_> ac100 specific patches are still missing
<marvin24_> but compiles at least
<janimo> marvin24_, nice. How many ac100 pacthes are there?
<marvin24_> well, my linux-ac100-3.8 branch contains 25 patches, mostly nvec specific
<marvin24_> but in fact, mainline also boots without any patch, but you will get no backlight ...
<janimo> this patch changes a few other arm flavour's config files, probably a side effect of using the config updater scripts
<marvin24_> yes, kernelconfig editconfig ...
<janimo> I think it would be cleaner as a first step to have a dedicated tree, not based on the current kernel source
<janimo> as it is unlikely they will take patches for this
<marvin24_> I don't expect ubuntu to take patches for tegra
<janimo> so a new linux-tegra package without any other flavours
<marvin24_> because they cannot support it
<janimo> right, just mentioning the resulting kernel would be cleaner than this patch suggests
<janimo> if we had this kernel in raring would we need to use uboot on the ac100 then?
<marvin24_> yes
<marvin24_> I need to patch the debian dir anyway
<janimo> isn;t that complicating the installer besides adding one other package to maintain?
<marvin24_> and most is because of the abi stuff
<janimo> I understand preferring to work with uboot but is fastboot support complicated?
<marvin24_> yes, because I don't have the source ...
<janimo> I'd like us to use this in raring but will need to speak to ogra to see whether it is a lot of effort to adapt to uboot
<janimo> cannot whatever 3.1 does be emulated in 3.8 without knowing what fastboot does?
<marvin24_> https://launchpad.net/~ac100/+archive/ppa/+packages has u-boot package already
<marvin24_> janimo: well, I prefer minimal patches
<marvin24_> why do you want fastboot?
<janimo> marvin24_, oh just so 3,8 is a drop-in replacement for 3.1
<janimo> so we do not need any extra testing or image work
<janimo> and not introduce a new uboot flavour for the ac100 only
<marvin24_> it also causes extra work to support fastboot
<janimo> nothing against uboot per se, just keeping changes minimal as you say :)
<marvin24_> I'm not sure how to adapt 3.8 to make it woking with fastboot
<janimo> and to make installation similar to previous cycles
<janimo> would this also be nvflash of a bootimg and boot it?
<marvin24_> (except chaning the krnel config)
<marvin24_> no need to flash, as we planed to use tegrarcm
<marvin24_> in fact, once ogra said that he won't put more work on the ac100 port
<marvin24_> we decided to restart from something clean
<marvin24_> I know this causes more pain for users, but less for us
<marvin24_> also u-boot needs a new partition table because otherwise it cannot load the kernel
<marvin24_> and this disables nvflash
<marvin24_> because fastboot expects some proprietary partition table
<AmEv> Now, to get Ubuntu on the Toshiba A*T*100.. haha
<AmEv> I've got a fully-functional FS. No working kernel...
<AmEv> Do know how to kill the Android GUI stuff to get X working, via ADB shell, but a pure native way would sure be nice...
<AmEv> Wait, do I need U-boot to boot Ubuntu? Or is a Fastboot-based system OK?
<questionguy> hey, yo, where do i find like a this thing: http://packages.ubuntu.com/ but exclusive to arm
<questionguy> anyone?
<questionguy> is there even an apt repository for arm devices?
<achiang> questionguy: http://ports.ubuntu.com/
<questionguy> thanks a ton!
<infinity> questionguy: It's a longstanding bug/misfeature that packages.u.c doesn't list ports, but you can see that the same packages exist on all arches by going to, say, launchpad.net/ubuntu/+source/<package>
<questionguy> infinity: yeah i literally thought that i would just find it by clicking around, and its completely inexcellent that it's so well hidden
<questionguy> but it's simple enough to remember, having seen it
<AmEv> Heh, should've known that....
<infinity> questionguy: Of course, if you have an Ubuntu armhf system installed, 'apt-cache search' is your friend.
<questionguy> yeah, i'm of course aware of that functionality, but i don't have one setup, and trying to see if this is a suitable distro, and indeed, it is
<mjrosenb> hey all, I've been told that 13.04 is supposed to work nicely on the arm-based chromebook.  Is there a better way of installing 13.04 than installing the hacked-shell-script-12.04, and upgrading? (I've tried to upgrade before, that went poorly to say the least)
<AmEv> So, where's the best place to get kernel help?
#ubuntu-arm 2013-01-25
<AmEv> Well, I've got a near-chroot method working.
<AmEv> *chroot method near-working...
<AmEv> Now I've figured out how the Ubuntu for Android guys did it... haha
<AmEv> Any ARM Xorg guys on right now?
<slangasek> ogra_: so my 'ssh hangs hard when I try to connect to my nexus7' bug is still here, even after repeated reinstalls
<wingze> hi
<wingze> i'm trying to cross compile a kernel on my desktop for a panda board but i get an dependency error
<wingze> but the dependencys are met and i still get that error
<mjrosenb> wingze: what error?
<dholbach> good morning
<highvoltage> good morning
<wingze> dpkg-checkbuilddeps: Unmet build dependencies: libelf-dev libnewt-dev binutils-dev libdw-dev libgtk2.0-dev | gtk2-devel
<wingze> i have all that installed but still get the error
<wingze> this is crazy
<wingze> ok got it working it was a build dependency error it needed gcc-arm-linux-gnueabi
<sveinse> I have a headless target which plymouth is not installed, and I'm missing some of the logs from initramfs, even when I have console= console= in the kernel commandline. Is it possible to get this log out on the console, or do I need plymouth even on a headless system?
<xnox> sveinse: plymouth has text-mode plugins & can run fine on headless and output text.
<xnox> sveinse: i dunno how to do this without plymouth.
<asiekierka> is there any reasonably priced 10" tablet that can run Ubuntu well
<asiekierka> bonus points for Flash support in any way, shape or form (for livestreams that don't HTML5)
<sveinse> xnox: Hmm. plymouth is installed after all (dep'd by mountall). But for some reason nothing appears in the console during initramfs. I have another device (another kernel) also with the console= console= bootcmd construct, but here it does work.
<sveinse> Kernel config perhaps. Don't remember seeing any config related to that (since the initial printk of the kernel is output properly on the console)
<lilstevie> asiekierka: flash is a no go with ubuntu-arm
<lilstevie> asiekierka: for 10" tablets I don't really know of one that runs it "well", especially at a reasonable price, it runs fine on the tf201 but that isn't reasonably priced, and while fine I wouldn't call it "well"
<marvin24_> lilstevie: do you have a device tree for tf201?
<ogra_> janimo, hmm, your HDA trick doesnt work if i build the HDA driver as module
<ogra_> :(
<janimo> well we build it in I suggest
<janimo> most our hw stuff is built-in anyway
<janimo> as we know it is there
<ogra_> well, i'm *extremely* short on bootimg space
<janimo> ah I remember
<janimo> how much more can fit there?
<ogra_> so modular would indeed be preferred if we add any stuff
<ogra_> -1M
<ogra_> :P
<janimo> ohm that should fit fine then for a while :)
<ogra_> the boot is slow enough that it justifies to have plymouth in the initrd
<ogra_> which i cant do atm
<janimo> I did not look closely at what we have modular or built-in
<ogra_> everything is builtin
<janimo> I think the majority of settings are as in the original android kernel
<ogra_> well, nearly at least
<ogra_> vmlinuz is 4.5M
<ogra_> (ac100 is 1.2 or so)
<janimo> I say when we hit that limit, we take out non-essential hw stuff (maybe all the USB peripherals)
<ogra_> you dont get it ? we are about 1M above
<janimo> and high-level networking and fss
<janimo> ah, aboce? I thought 1M to go
<ogra_> it currently only works due to some evil hacks and diversions i add
<janimo> that - 1M confused me
<ogra_> well, you asked how much more :)
<janimo> well I thought you said dash 1M not minus 1M
 * ogra_ is neadly done with a set of quietening patches for the boot
<ogra_> *nearly
<janimo> well anything not strictly tegraSoC hw could be modular IMHO
<ogra_> theoretically
<ogra_> sadly practically that will fall over in many places
<janimo> well FSs that are not ext4, TCP, and other bits Asus/Google did not modify should be fine I think
<janimo> Iknow battery and some other bits don't work as modules
<ogra_> all the non std drivers that are woven into android stuff usually require to be builtin
<janimo> right, but the big space consumers are network,fs and the rest of the code
<ogra_> battery, wlan, bluetooth, i bet the accelerometer and all other sensors too
<janimo> so if we can make those modular it should fix the bootimg size issue
<janimo> right, but those are all relatively small footprint  i bet
<ogra_> well, wlan would really help
<ogra_> we could drop all network bits to modules that way (protocols etc)
<ogra_> wlan itself wont gain us much, but firewall, protocols etc
<janimo> ogra_, do we have a nexus meeting today?
<ogra_> yup
<ogra_> GRRR !
<ogra_> i just had the boot quiet ...
<ogra_> enabling HDA gets me another message on the screen
<ogra_> why cant people use pr_info for info messages instead of pr_err
<ogra_> grmbl
<janimo> ogra_, is onboard not working when the gksu dialog after apport pops up a known issue?
<ogra_> yes, gksu is supposed to go asap
<janimo> I seem to have seen lots of onboard related bugs filed but am not sure which are still relevznt
<janimo> what replaces gksu?
<ogra_> pkexec, since about 4 releases now
<janimo> I keep getting an apport dialog on each session start, but cannot send the report due to this
 * janimo never heard of pkexec
<ogra_> yet you use it all the time :)
<janimo> so by asap you mean a couple weeks or a couple more cycles? :)
<ogra_> its part of policykit/consolekit
<ogra_> i mean this cycle
<ogra_> there are two apps left that need porting, then we can unseed gksu
<ogra_> one is update-notifier (which is the apport bit you see) and the other is xdiagnose
<janimo> I don't know what makes up the 'January-2013 Linux Plumbing stack'
<ogra_> where does that come from ?
<janimo> I can only assume it is different from 'December 2012 Linux Plumbing stack' and 'February 2013 Linux Plumbing stack'
<ogra_> oh, you mean wrt pkexec :)
<janimo> wrt the whole moving thing which keeps getting in the way of actually writing features
<janimo> half-joking
<ogra_> yay, completely quiet boot !
<janimo> everything from kernel up until the login manager
<ogra_> if we now just could have plymouth in initrd
<janimo> ogra_, what happened to the no initrd at all attempt?
<ogra_> i got stuck at the console-setup race
<ogra_> and was told bootspped isnt a prio anymore
<ogra_> *speed
<ogra_> so for now i just care about it having bling :)
<lilstevie> marvin24_: nope
<lilstevie> marvin24_: probably should work on that
<infinity> janimo: Who's on armadaxp SRU duty right now?  You or Ike?
<janimo> Ike I guess
<infinity> Kay.  We have a rushed revert in master that needs a quick rebase for derivatives.
<janimo> I was told I'd be doing non-SRU stuff last December, so my last armadaxp thing was the B0 enablement in Precise
<janimo> but if I misunderstood I can be convinced otherwise
<janimo> infinity, or if there's an emergency I can of course try handling it
<ogra_> what happened to NCommander ?
<ogra_> doesnt he do any server kernel work anymore ?
<janimo> ogra_, not on armadaxp at least
<infinity> janimo: I'll ping Ike.
<ogra_> janimo, btw, compiling HDA in or as module doesnt get me any sound working (suspend/resume still does)
<ogra_> are you sure your HDA stuff isnt just a red herring ?
<janimo> ogra_, very strange. I got that repeatedly after enabling it
<janimo> well I am not 100% sure, it just worked in my testing
<janimo> ogra do you have the volume turned on at boot?
<ogra_> no, it is muted
<ogra_> but unmuting doesnt get me any sound
<janimo> that sucks
 * ogra_ tries another reboot
<janimo> could it be i accidentally set some alsa configs which made it work? I'll dump my alsa state and paste it
<ogra_> now that rotation works wutomatically, we should probably consider to just boot in portrait
<janimo> ogra_, alsa store gives me this: http://paste.ubuntu.com/1569919/
<janimo> ogra_, I agree with portrait booting. needs to drop the fbcon rotate cmdline arg too
<ogra_> it also doesnt seem to make any difference if HDA is card 0 or 1
<janimo> ogra_, so reboot and still no sound?
<ogra_> janimo, and i think yoiu did a hack to the touch driver to switch to 1280x800 from 800x1280
<ogra_> i guess we need to drop that too
<ogra_> janimo, right, but sound after resume
<janimo> ogra_, right, I tested with that dropped this week
<janimo> will need the matrices shuffled in the rotate scripts
<ogra_> great, telly me once it entered the kernel and i'll adjust the cmdline
<janimo> but better that way so portrait is the 'normal' one
<janimo> and we drop that needless delta vs the android kernel
<ogra_> right
<ogra_> and getting plymouth inoto landscape seems impossible anyway
<janimo> ogra_, btw the cmdline could be altered separately no? Isn't that only affecting the fbcon (so bootup messages) ?
<ogra_> separately from ?
<janimo> from the rotate script and kernel stuff
<ogra_> the cmdline has two parts, first is hardcoded in the bootloader ...
<ogra_> second is from abootimg
<ogra_> the abootimg part can be altered
<janimo> right, abootimg fbcon rotate=1
<ogra_> yeah
<janimo> which is only about display in console mode
<ogra_> i'll drop that from the builds as soon as the kernel fix is there
<janimo> the kernel bit is only about touch input
<ogra_> janimo, http://paste.ubuntu.com/1569980/
<ogra_> thats the diff to my automatically stored asound.state file
<ogra_> (yours is +)
<ogra_> seems you played with all the controls :)
<ogra_> i wonder if you probably stil have sound working if you now disable HDA in your kernel
<janimo> ogra_, can you try this .deb? http://people.canonical.com/~jani/linux-image-3.1.10-8-nexus7_3.1.10-8.21_armhf.deb
<ogra_> sure
<janimo> I freshly rebuilt with the HDA and the axes inversion changes
<janimo> it works for me if I set the volume up (it is again off at boot)
<ogra_> bah, the noise is back at boot :P
<ogra_> nope
<ogra_> no sound
<ogra_> janimo, how exactly do you test btw ?
 * ogra_ just relies on the plop plop from the volume control applet
<ogra_> (when adjusting with the buttons)
<janimo> ogra_, canberra-gtk-play --file=/usr/share/sounds/gnome/default/alerts/glass.ogg
<ogra_> geez, complex
<ogra_> ergh
<janimo> well, I have no media to play, and this is a simple thing to test via ssh
<ogra_> and indeed the touchscreen is totally screwed now
<janimo> with export DISPLAY=:0 of course
<ogra_> well, i just press vol-up/down
<ogra_> makes an event sound if audio works
 * ogra_ reboots back to a sane kernel that likes my touching :P
<janimo> ogra_, so no sound with this deb?
<ogra_> janimo, right
<ogra_> well, after resume i had it
<ogra_> as with my kernel
<ogra_> well, lets have a meeting :)
<janimo> ogra_, well with this kernel I get sound without having to do suspend
<janimo> ogra_, http://paste.ubuntu.com/1570120/ the matrices changed around to have rotation work with this deb
<janimo> to be uploaded once we have the kernel change
<janimo> xnox, Bus 001 Device 067: ID 04e8:6866 Samsung Electronics Co., Ltd
<janimo> Galaxy Nexus
<xnox> janimo: thanks.
<janimo> anyone else with a nexus 7 willing to test the deb I linked above to see if it fixes the no sound on boot problem?
<Tassadar> yeah, why not, tell me what to do
<Tassadar> just install and reboot I guess)
<ogra_> right, like we discussed in the meeting :)
<janimo> Tassadar, yes, install and reboot but make sure you have ssh enabled or a keyboard or mouse
<janimo> as the touchscreen will be messed up :)
<janimo> via ssh then export DISPLAY=:0
<janimo> and  canberra-gtk-play --file=/usr/share/sounds/gnome/default/alerts/glass.ogg
<janimo> or any other sound playing app you wish
<Tassadar> okay, I'll just update my installation first
<janimo> for me this works on boot without having to issue a suspend
<janimo> but you may need to turn the volume on
<Tassadar> hmm, it does not work for me
<ogra_> Tassadar, does it work after a suspend cycle (as it did before)
<Tassadar> yes
<AmEv> Anyone got some initfs advice for me? I'm trying to get Ubuntu to run natively on the Toshiba Thrive.
<Tassadar> just to make sure it is right kernel, my /proc/version looks like this:
<Tassadar> Linux version 3.1.10-8-nexus7 (jani@parapapio) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-19ubuntu1) ) #21 SMP PREEMPT Fri Jan 25 16:55:55 EET 2013
<Tassadar> so I think it is the right one
<Tassadar> yeah, it is, the touch screen is messed up
<AmEv> I was able to get into a chroot Ubuntu, but the X server never displayed anything. I know it had access to the framebuffer because there was garbage on the display before I started it.
<Tassadar> it doesn't need any modules or cmdline params during boot or something like that, does it? You said it is built in the kernel, right?
<janimo> Tassadar, yes it is the right kernel - especially since the touchscreen handling is broken right
<janimo> Tassadar, indeed no extra boot params
<janimo> Tassadar, thanks for testing
<janimo> I am building anothe deb now without the messed up touch now
<Tassadar> theres one hda-codec message if that's any help, "hda-codec: No codec parser is available"
<janimo> Tassadar, I have that too in dmesg
<AmEv> Would I need to set a custom cmdline when I make the boot image on mine? If so, what?
<janimo> Tassadar, btw I put a new deb at the same URL, this time without the messed up screen
<janimo> did you test with the canberra command line ?
<janimo> ogra_, did you test with that canberra line btw?
<janimo> that works for me but playing an mp3 in rhythmbox is silent
<janimo> or rather it plays crack. I think I'll soon do a test-reinstall :)
<ogra_> well, we dont ship any mp3 codecs
<ogra_> rebooting to your latest kernel now
<janimo> ogra_, well I installed mpg123 and rhythmbox installed its own
<janimo> my alsa settings are likely broken now
<janimo> not sure how the gtk player just works
<ogra_> anyway, no change with the kernel from the ML
<janimo> volume up?
<AmEv> Hmmm... Sound works perfectly, but I'm not getting anything to display.
<ogra_> and yes, i used the canberra methid too
<ogra_> *method
<AmEv> You and I are in completely opposite sides of the spectrum... haha
<ogra_> volume is indeed up
<janimo> AmEv, does sound not work for you with the regular kernel unless suspending first?
<AmEv> I'm actually on a Tegra 2 device in a Android-to-Ubuntuchroot.
<AmEv> I have absolutely zero speaker issues.
<AmEv> My problem is that I can't get anything to display.
<ogra_> what do you want to display ?
<ogra_> android doesnt ship an X server
<Tassadar> janimo: no, no sound until suspend/resume
<ogra_> right, same here
<AmEv> I've got Ubuntu on an SD card.
<Tassadar> but touchscreen works)
<AmEv> Chroot.
<ogra_> AmEv, but you are aware that ubuntu apps use X ?
<AmEv> Yes.
<janimo> Tassadar, mine is a 16G model if that is any help but I doubt it has to do with the model
<Tassadar> mine too
<AmEv> I'm trying to start X, but nothing's displaying.
<ogra_> android doesnt ship an X server, you cant display anything
<ogra_> janimo, i really think HDA is a red herring ...
<ogra_> janimo, but i also think you must have something that makes it work :)
<janimo> ogra_, could well be
<janimo> yes, so I should not just wipe and reinstall
<janimo> I may have a gem here somewhere
<janimo> :)
<ogra_> we should consult diwic again
<AmEv> I've built an X-compatible kernel. I've been able to get Zygote, Surfaceflinger, Media, and DRM stopped, then chroot into Ubuntu, and start X.
<AmEv> My final goal is to get a working native, zero-Android solution.
<AmEv> Kernel source is https://github.com/Thrive-Hackers/tostab3-gnu-linux-kernel
<janimo> ok, indeed it now works with the stock kernel
<janimo> sigh
<janimo> my nexus just got fixed and I don't know how
<AmEv> In the meantime, I'm trying to esssentially shut down Android and shut down Ubuntu.
<Tassadar> both bohdi and plasma have sound working without suspend, but I don't see jeff here right now :/
<AmEv> *start up Ubuntu
 * janimo wonders whether bodhi and plasma are applications or people
<Tassadar> distributions)
<Tassadar> bohdi is based on debian and plasma active on MER (it is "kde on tablet" project), but both use ubuntu's kernel
<AmEv> Still, if someone does want to try remoting in, I'm willing to.
<AmEv> Almost in...
<AmEv> Hmmm... WiFi module isn't loaded.
<AmEv> Okay, this is new... X is segfaulting.
<AmEv> Wall of text coming in...
<AmEv> root@localhost:/# startx
<AmEv> startx
<AmEv> xauth:  error in locking authority file /data/.Xauthority
<AmEv> xauth:  error in locking authority file /data/.Xauthority
<AmEv> X.Org X Server 1.11.3
<AmEv> Release Date: 2011-12-16
<AmEv> X Protocol Version 11, Revision 0
<AmEv> Build Operating System: Linux 2.6.38-1209-omap4 armv7l Ubuntu
<AmEv> Current Operating System: Linux localhost 2.6.39.4-gnu-v0.01-g49f5e55-dirty #6 SMP PREEMPT Thu Jan 24 18:24:20 MST 2013 armv7l
<AmEv> Build Date: 05 April 2012  02:47:41AM
<AmEv> xorg-server 2:1.11.4-0ubuntu10 (For technical support please see http://www.ubuntu.com/support)
<AmEv> Current version of pixman: 0.24.4
<AmEv>         Before reporting problems, check http://wiki.x.org
<AmEv>         to make sure that you have the latest version.
<AmEv> Markers: (--) probed, (**) from config file, (==) default setting,
<AmEv>         (++) from command line, (!!) notice, (II) informational,
<AmEv>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
<AmEv> (==) Log file: "/var/log/Xorg.0.log", Time: Fri Jan 25 09:59:34 2013
<AmEv> (==) Using system config directory "/usr/share/X11/xorg.conf.d"
<AmEv> Backtrace:
<AmEv> Segmentation fault at address 0x4
<AmEv> Caught signal 11 (Segmentation fault). Server aborting
<AmEv> Please consult the The X.Org Foundation support
<AmEv>          at http://wiki.x.org
<AmEv>  for help.
<AmEv> Please also check the log file at "/var/log/Xorg.0.log" for additional information.
<AmEv>  ddxSigGiveUp: Closing log
<AmEv> Server terminated with error (1). Closing log file.
<AmEv> xinit: giving up
<AmEv> xinit: unable to connect to X server: No such file or directory
<AmEv> xinit: server error
<AmEv> xauth:  error in locking authority file /data/.Xauthority
<AmEv> root@localhost:/#
<AmEv> Ouehy..... I'm on 2.6.39.....
<AmEv> Might that be what's happening?
<AmEv> Well, anyone know how to set up a initfs properly, and the proper cmdline?
<AmEv> I should probably mention that I was using http://blog.rot13.org/2012/08/x11-running-on-nook-color-without-android-stack.html as a basis for a lot of what I was doing...
<slangasek> ogra_: hmm, any idea why modem-manager in raring takes over /dev/ttyACM0 when I connect my nexus7 to my raring laptop?
<ogra_> nope, thats a qerustion for cyphermox i think, we noticed other modemmanager issues as well, might be the same bug, not sure
<ogra_> *question even
<slangasek> ah, it apparently opens the port several times and takes a long time to probe it, but eventually lets go
<ogra_> yeah, it sends AT commands
<ogra_> seems it does that for the serial gadget connection too
<ogra_> which can confuse getty a bit
<ogra_> slangasek, btw, make sure to upgrade to the latest, there were a ton of fixes this week
<slangasek> this was installed yesterdy
<ogra_> well, we didnt have images for the whole week :)
<slangasek> we did yesterday
<ogra_> oh, i missed that, only saw that todays failed
<ogra_> perfect then :)
 * ogra_ goes for dinner
<AmEv> Yep. My audio device is tegra8903. Perfect sound in Ubuntu.
#ubuntu-arm 2013-01-26
<will3032840> Hello!
<will3032840> Hello?
<cobalt60-ac100> Is there any device that is similar enough to the Nexus 7 that Ubuntu will run on it using the same image/install instructions?
<jpastore> hola anyone here have experience with motion? I have a webcam hooked up to a beaglebone and I want to record jpeg snapshots to the disk. I do not want to stream
<cobalt60-ac100> jpastore IIRC motion has a great man page
<jpastore> cobalt60-ac100: yea the man pages weren't isntalled. thanks. I'll google.
<scientes_> anyone run 12.10 on the chromebook
<scientes_> when i upgraded it would hang at plymouth terminal != void*(0) error
<scientes_> from 12.04
<scientes_> i really need multiarch stuff that is in 12.10
<moofree> compiling seamonkey cause there are no precompiled armhf builds
<moofree> shame on you people! ;)
<IamTrying> I had OLife installed in my Android tablet. This is 3rd time it crashes the Tablet.
<IamTrying> Why??
<IamTrying> Why its not showing any boot screen now at all?
<IamTrying> Its always black screen
<IamTrying> power off/on
<IamTrying> always showing black screen
<lilstevie> cause you either did something wrong or let the battery go dead
<IamTrying> lilstevie, right now the usb from Android Eee Pad is connected to my laptop and `lsusb` does not show anything at all when i plug in or out
<lilstevie> so flat battery
<IamTrying> lilstevie, i have connected adapter now, and i see OLife Boot screen to fail mode like all those boot lines
<IamTrying> lilstevie, do you know if there is any new release of OLife i was using ages old one.
<lilstevie> no newer version
<lilstevie> others have done alternatives, and my interest in tf101 is minimal
<IamTrying> lilstevie, http://lilstevie.geek.nz/ports/OLiFE-Prime-Edition.tar.gz  - those files are empty????? is it removed???
<lilstevie> where are you opening the link from?
<lilstevie> hm
<lilstevie> IamTrying: and if you try download it from http://lilstevie.geek.nz/downloads/
<lilstevie> new system probably broke the old links
<IamTrying> lilstevie, old links are broken but this works now thank you. http://lilstevie.geek.nz/downloads
<lilstevie> IamTrying: you can blame the people who decided to adify my links for that
<IamTrying> OK :)
<IamTrying> https://tari.in/www/eng/articles/transformer/
<IamTrying> lilstevie, after downloading from your new link i get this now? https://gist.github.com/4642079
<IamTrying> lilstevie, i again downloaded the file but its not running OLife your download is broken? Is there any alternative?
<IamTrying> lilstevie, after dong the FLASH why it turns of the Tablet it does all the installation and then it never turn it on.
<IamTrying> In the terminal it shows its formating and all done but in the Tablet its always black screen.
<IamTrying> lilstevie, here its doing nothing http://i.imgur.com/hzdKv3o.png
<IamTrying> Putting device into Nv3P Phone Update mode  > Nvflash started  and it does nothing else...
<IamTrying> lilstevie, how do i exit APC mode? after doing flash and update it always remain in Black screen.
<lilstevie> hold the power button for >10sec
<IamTrying> lilstevie, i did not 10sec, 20sec, 30sec no result. Then i connect USB and lsusb shows its still in APC mode.
<IamTrying> Right now i have the power button on hold. But still i have black screen. Once i go to OLife and again use option 2 or 3, i can see the screen turns on for showing update status
<IamTrying> But holding power button >10sec or more is not booting or rebooting nor existing the APC mode.
<IamTrying> lilstevie, what can i do in such situation? Its completely remain on APC mode, nothing happening when i do power off/on >10sec etc
<lilstevie> Sun Jan 27 02:29:53 EST 2013
<IamTrying> I think your download release version is conflicted one. It was working before when you had old links.
<IamTrying> Can you please give me the old link files?? Your current files from download is conflict it has something strange causing it.
<lilstevie> the files are the exact same
<lilstevie> no different
<IamTrying> lilstevie, i am very sure it is wrong, because i remember i had that file and i can work with it but the recent new files gives me this: https://gist.github.com/4642079
<lilstevie> the difference is literally mv ports/OLiFE.tar.gz protected/path/OLiFE.tar.gz_version_md5sum
<lilstevie> IamTrying: seriously don't tell me what you are very sure is wrong
<lilstevie> I know what I did
<IamTrying> lilstevie, but your old files all was perfectly working, now it does not.
 * lilstevie facepalms
<IamTrying> when i do option 3. in past it was saying "Nvflash started [resume mode]"
<lilstevie> check the md5sum
<lilstevie> IamTrying:
<lilstevie> $ openssl md5 OLiFE*
<lilstevie> MD5(OLiFE-Prime-Edition.tar.gz_1.2a_TF101_767779ccfa200e5e00b2f1e33a3d73a9)= 767779ccfa200e5e00b2f1e33a3d73a9
<lilstevie> MD5(OLiFE.tar.gz_1.2a_TF101_c30263fd8271a23bb211fd9fdd69fa45)= c30263fd8271a23bb211fd9fdd69fa45
<lilstevie> that is what is currently on my server
<lilstevie> http://forum.xda-developers.com/showpost.php?p=16101612&postcount=3
<IamTrying> OK lilstevie thank you trying it now.
<lilstevie> md5sums are the same as in that post that hasn't been edited since nov 2011
<IamTrying> OK - strange let me show you something what is happening right now.
<lilstevie> I'd rather go to sleep
<IamTrying> lilstevie, http://imgur.com/WDGG0Su,dTX4m74   - after doing the option 3 > 2 > 2 i have this screens
<IamTrying> And it in past, was rebooting , and now if i hold power off button >10sec then it again goes to APC mode and remain in black screen
<lilstevie> you do have images in the images/ folder rightr
<lilstevie> -r
<IamTrying> YES i do have yes
<IamTrying> root@sun-M14xR2:~/Downloads/OLiFE/images# ls
<IamTrying> bootloader.bin  transformer.bct  uboot-part.img
<IamTrying> lilstevie, ^ those what i have
<lilstevie> yeah, so you don't have images in the images folder
<lilstevie> read the readme
<IamTrying> OK - lilstevie.
<IamTrying> I loaded now the images
<IamTrying> root@sun-M14xR2:~/Downloads/OLiFE/images# ls
<IamTrying> bootloader.bin  system.img  transformer.bct  uboot-part.img  ubuntu.img
<lilstevie> IamTrying: you are still missing a boot.img
<IamTrying> lilstevie, YES - but where can i find it. i have no boot.img file no where for this ASUS Eee Pad
<IamTrying> boot.img is it the image of Android?
<IamTrying> or is it supposed to be coming from OLife?
<lilstevie> android
<IamTrying> lilstevie, https://developers.google.com/android/nexus/images - i can only take the boot.img from Nexus 7?
<IamTrying> there are several files on there link
<IamTrying> boot.img, recovery.img, system.img, userdata.img
<IamTrying> bootloader-grouper-4.13.img
<IamTrying> image-nakasi-jop40d.zip has (boot.img, recovery.img, system.img, userdata.img)
<IamTrying> Which one i should take for OLife?
<Tassadar> ogra_: bluetooth on Nexus 7 is not working because of problems with firmware loading, and it is not specific for nexus 7, but to all Broadcomm chips, right?
<ogra_> well,yes and no
<ogra_> this chip has some specialities yhat require some changes in userspace
<ogra_> we'll ne working on that next week
<ogra_> *be
<Tassadar> okay, thanks
<IamTrying> lilstevie, i have the image boot.img but still same
<IamTrying> root@sun-M14xR2:~/Downloads/OLiFE/images# ls
<IamTrying> android-info.txt  boot.img  bootloader.bin  recovery.img  system.img  system.img1  transformer.bct  uboot-part.img  ubuntu.img  userdata.img
#ubuntu-arm 2013-01-27
<marvin24_> mmh, is there some rule where to install device trees for a multi-board kernel and how to name them?
<marvin24_> /boot/devicetree-<machine>-<kernelver>.dtb?
<marvin24_> if you install more than one kernel, there will be lot of these devicetree files ...
<ogra_> marvin24_, ask ppisati tomorrow
<marvin24_> arrr, always these weekend hackers ...
<ogra_> je is just working that out for ubuntu kernels
<ogra_> *he
<marvin24_> well, kernel package could be clever to detect the machine and install only the desired one
<marvin24_> but all need to be packaged
<ogra_> that's what he works on
<ogra_> afaik
<marvin24_> ok, great
<Phosphate> Does anyone have experience with 13.04 on a Nexus 7? Is it possible to use the soft keyboard during setup or do you need a micro usb host adapter for a keyboard?
<solarcloud_3srcn> no
<Tassadar> you can use software keyboard
<Phosphate> Tassadar: Thanks. Is there something you need to do to make it work? I get the keyboard on screen when I focus on a text box but nothing shows up in the textbox as I type.
<Tassadar> I'm afraid that is a bug - try to reboot the tablet
<Phosphate> Ah ok thanks. Will give that a shot.
<Phosphate> Tassadar: Thanks, it worked on the second reboot.
#ubuntu-arm 2014-01-20
<hrw> http://marcin.juszkiewicz.com.pl/2014/01/20/the-story-of-qtaarch64-patching/
<ogra_> hrw, hmm, i think we have 5.2 in the archive already .... just not using it yet
<hrw> ogra_: https://launchpad.net/ubuntu/+source/qtdeclarative-opensource-src lists 5.0.2
<ogra_> (since there is still the qreal vs. float and double discussion open)
<ogra_> hrw, well, ask Mirv, might be he prepared it in a PPA ... it will become default before feature freeze and i know there are already packages in heavy testing
<hrw> ogra_: I spoke with him some time ago about it already
<hrw> ogra_: and I had more patches then he though he had ;D
<ogra_> heh
<hrw> qtwebkit was missing in ubuntu due to build issues
<ogra_> we might not use it at all ...
<ogra_> (though it will surely live in universe)
<hrw> sure, but would be nice to provide
<ogra_> yeah
<hrw> ogra_: how arm stuff goes in ubuntu nowadays?
<ogra_> well ... depends how you look at it
<ogra_> arm desktop is pretty dead ...
<hrw> ogra_: is there any arm devices supported?
<ogra_> Ubuntu Touch rocks the world
<hrw> I do not count nexus4/10 for utouch
<ogra_> but in #ubuntu-touch ... not in here
<hrw> I would ignore #ubuntu-touch
<hrw> already too many channels
<ogra_> beyond that ubuntu arm on server indeed lives happily too
<hrw> good that I dropped #python-dev and #ruby
<ogra_> uh, why the heck would anyone want to be in #ruby
<hrw> ogra_: calxeda and marvell?
<hrw> ogra_: E2BIG issue in test suite on arm64?
<ogra_> hrw, dunno, i dont even find the time to look over the fence nowadays
<hrw> issue which ubuntu ignored ;D
<ogra_> no idea what the server team does atm
<hrw> ogra_: you do touch stuff now?
 * ogra_ is drowning in phones and tablets :)
<ogra_> and wrangling more with testing procedures than anything else
<ogra_> (though i still do a good bunch of plumbing work in ubuntu touch)
<hrw> ;)
<hrw> ogra_: does Canonical has corporate license agreement for Qt? or you rather do not upstream any patches?
<ogra_> hrw, ask Mirv, i only touch Qt for playing with QML :)
<hrw> ;)
<ogra_> i think he upstreams it to debian and to upstream from there or some such
<ogra_> no idea about details here :)
 * ogra_ is happy to just be a consumer
<hrw> ;)
<hrw> I was too
<hrw> now I am upstreaming more
<hrw> for xulrunner/firefox I have 87KB patch...
 * ogra_ simply is upstream for mmost bits and pieces he does)
<hrw> ogra_: so you write code.
<hrw> I write packaging and patches
<ogra_> well, i write glue
<ogra_> :)
<davmor2> ogra_: that sounds sticky (badumtish)
<ogra_> :)
#ubuntu-arm 2014-01-21
<snkt> hello
<snkt> can someone  help me how to find physical memory address for kernel?
<grant__> how can I figure out which bootargs were passed with ubuntu-12.04-preinstalled-desktop-armhf+omap4?
<grant__> without booting it
<rbasak> grant__: so you have it booted now, and you don't want to reboot it? Or you don't have it booted at all, don't want to boot it, but want to know what was used in the past?
<grant__> rbasask: don't want to boot it
<rbasak> I guess you could look at the uEnv.txt or boot.scr or whatever it uses.
<ogra_> as i said in the other channel, chekc the first (fat) artition
<ogra_> *partition
<ogra_> right, its either uEnv.txt or preEnv.txt
<ogra_> hmm
<ogra_> in 12.04 it could even be that there still was a boot.scr
<ogra_> (uboot changed a lot around that time)
<grant__> how can I grab those files without formatting an SD card?
<ogra_> you could unzip the img, and loop mount the partition (needs an offset)
 * ogra_ guesses just dd'ing is faster than fiddling with that ... but up to you indeed :)
<grant__> I'm downloading ubuntu-12.04-preinstalled-desktop-armhf+omap4.img.gz now and then extract, and mount the resulting img?
<ogra_> no
<ogra_> you mount the first ppartition of it
<grant__> OK, how can I figure that offset?
<ogra_> google :) there are tons of howtos for that
<grant__> ok
<ogra_> "mount image partition with offset"
<ogra_> or some such
<grant__> looks like: start sector * size of a sector in bytes from fdisk
<ogra_> yeah, something like that
<grant__> brb
<grant__> I grabbed everything from the boot partition.  There is no uEnv.txt and there isn't anything interesting in boot.scr but I can at least try to boot Gentoo with these boot files and see what happens.
<grant__> The issue I'm having is xf86-video-omap segfaults with the ti-omap4 kernel.  It looks like ubuntu instead used xf86-video-omap though, and Xorg does start that way successfully but there is no output to the screen.
<grant__> The point of all this is to load pvr-omap4 under the ti-omap4 kernel since it doesn't compile under the latest kernel.
<grant__> I meant to say ubuntu instead used *xf86-video-fbdev*
<infinity> setenv bootargs vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 fixrtc quiet splash
<infinity> grant__: ^-- That's what the precise boot.scr contains.
<grant__> infinity: thanks, I saw that and it's not as enligtening as I hoped :)
<grant__> how can I make x86-video-fbdev utilize the pvr-omap4 module?
<grant__> the module compiles and loads and Xorg starts but I still can't use XV
#ubuntu-arm 2014-01-22
<ppisati> doko: iirc you are the "toolchain" guy, aren't you?
<ppisati> doko: this thread on lkml catched my eyes, and i thought you might be interested - http://www.spinics.net/lists/arm-kernel/msg302315.html
<doko> fixed in trusty
<hrw> doko: finally took xulrunner
<doko> hrw, ?
<hrw> doko: xulrunner patch
<doko> ahh
#ubuntu-arm 2014-01-23
<hrw> https://bugzilla.mozilla.org/showdependencytree.cgi?id=962534 - xulrunner update for AArch64
<hrw> http://marcin.juszkiewicz.com.pl/2014/01/23/xulrunneraarch64-on-a-way-to-upstream/ as a summary
<hrw> doko: hi
<doko> hrw, thanks. did you see any linker errors?
<hrw> doko: it built for me always with this patchset
<doko> ok, will have to recheck. maybe not this week
#ubuntu-arm 2014-01-25
<Starwind> Has anyone here used ubuntu with one of the Utilite computers?
<sloppycode> evening people
<sloppycode> gentleman ladies and others
<sloppycode> anybody awake ?
<sloppycode> thats a no then
<ogra_> most of us jusr wait til an intresting question gets asked ...
<ogra_> bah
<k1l> most of us wait until someone without patience leaves before one can answer ;p
<ogra_> heh
<jnumm> hi, can anyone help with https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/1264531
<ubot2`> Launchpad bug 1264531 in inkscape (Ubuntu) "Segmentation fault on arm64 with command line SVGâPNG export" [Undecided,Confirmed]
<jnumm> what can be done about it?
#ubuntu-arm 2014-01-26
<CEO_007> good evenin
#ubuntu-arm 2015-01-19
<sveinse> After upgrading our OMAP product to 14.04, I have problems logging in via the serial console port. I enter the username, but as soon as I write the first key of the password, it sais "login incorrect". Anything familiar?
<sveinse> The kernel is exactly the same between 14.04 and 12.04. I notice that plymouthd is running and apparently using /dev/ttyO1. Need to stop it I think.
<sveinse> What /is/ plymouth doing? I.e. does it do anything else than user feedback?
#ubuntu-arm 2015-01-20
<jja2000> Hello everybody!
<jja2000> You guys still alive?
#ubuntu-arm 2015-01-21
<ndec> hi ogra_ ! long time ;-) i was reading about the snappy thing for arm. are there instructions/wiki to create my own snappy images for a custom board? i haven't followed closely the recent 'core' changes, so i might not be familiar with how images are built now.
<ogra_> ndec, not yet, i'm workin on that
<ndec> ogra_: ok. good. do you know what 'format' or output we will be able to generate for a custom board? could i build a rootfs and use that only?
<ogra_> no,  you cant modify the rootfs easily
<ogra_> you use the pre-created rootfs with your own kernel,dtb and modules dir
<ndec> i don't need to modify it, just want to be able to use it with my board.
<ogra_> right
<ogra_> http://people.canonical.com/~ogra/snappy/ninjasphere/README
<ndec> ah, nice. do these commands work from a container (systemd-nspwan) or chroot?
<ogra_> i'm working on a scriopt that allows ypou to easily hand over a kernel, dtb, modules dir and uEnv.txt to it which will then spit out a working device tarball that you can use with the process from the README
<ndec> well i don't even have uboot on my boards ;-0
<ogra_> oh, then it wont work
<ogra_> we dont have support for other bootloaders yet
<ogra_> only grub and u-boot
<ndec> what do you need from bootloader?
<ogra_> izt needs to be able to switch the root target back and forth, as well as the storage dir of the kernel and initrd
<ogra_> for the rollback functionality
<ogra_> (and upgrades etc etc)
<ndec> izt?
<ogra_> to achieve that it also needs to be able to touch a file and read from another file
<ogra_> *it
<ndec> ;)
<ndec> ogra_: can i at least 'get' the rootfs without making an image?
<ogra_> well
<ogra_> the whole magic to atually create an image lives inside ubuntu-device-flash
<ogra_> you can indeed pull the rootfs from systzem-image.ubuntu.com but that wont get you anywhere i fear
<ogra_> *system-image
<ogra_> ubuntu-device-flash essantially does all the snappy specific magic when merging rootfs and device tarball
<ogra_> like the dual partition layout, writable and readonly bits, bootloader setup etc
<ogra_> does your bootloader support something like uEnv.txt ?
<ogra_> (and setting/reading variables ... and touching or writing files)
<ndec> ogra_: ok. i will try to use the BBB image and see what i can do with it...
<ndec> thanks!
#ubuntu-arm 2016-01-27
<Matthias01> hi everybody
<Matthias01> i have a question
<Matthias01> can i run ubuntu touch on a elephone p7000 smartphone is this possible?
<ogra_> if you have the android 4.4 source and all the binary blobs for it you could attempt a port
<ogra_> (also #ubuntu--touch is the phone channel)
<ogra_> err
<ogra_> #ubuntu-touch
<ogra_> (one dash)
#ubuntu-arm 2017-01-23
<Guest55973> i am seeking help for my ubuntu snappy
<ogra_> Guest55973 try #snappy
<ogra_> ;)
<nicomachus> haha, ogra_ I just sent him here. my bad.
<nicomachus> from #ubuntu
<ogra_> well, np ... we're talking in #snappy now :)
#ubuntu-arm 2017-01-24
<nicomachus> I have a rpi set up as a network "gateway" so that I can SSH into a few different machines. Previously, I was using a desktop PC for that with full Ubuntu (12.04 through 16.10). With the full ubuntu machine, I was able to reboot the pc remotely (which would drop connection) but I could SSH back in after it rebooted, without having physical access to log the machine in. Now, with the rpi running
<nicomachus> Mate 16.04, if I reboot remotely I lose connection and SSH back in until I physically log into the rpi from local. What's the difference there? Can I fix it?
<nicomachus> CAN'T SSh back in*** on the rpi
#ubuntu-arm 2017-01-25
<merimus> raspi 3 with ubuntu-mate, any attempt to debug a program in gdb resulst in Program received signal SIGSEGV, Segmentation fault.
<merimus> 0x76fd9822 in ?? () from /lib/ld-linux-armhf.so.3
<merimus> any ideas?
#ubuntu-arm 2017-01-27
<zzarr> hello!
<zzarr> I have a development board running Ubuntu 16.04
<zzarr> I have a connection through the debug UART and ssh through a WiFi interface
<zzarr> so, the dhcp works like it should
<zzarr> but even when I write echo "nameserver 8.8.8.8" > /etc/resolv.conf I can't run apt update
<zzarr> there's no ping command and no nslookup
<zzarr> when I run 'nmcli device show wlan0 | grep IP4.DNS' I can see that the dns is 192.168.0.1 which is my router
<zzarr> (same dns as this computer uses)
<ogra_> ubuntu uses resolvconf ... have a look at amn resolvconf
<ogra_> *man
<ogra_>  /etc/resolv.conf is usually just a symlink to the generated resolv.conf
<zzarr> thanks ogra_ I will have a look
<zzarr> it looks like this for me 'resolv.conf -> /var/run/NetworkManager/resolv.conf'
<zzarr> the resolvconf directory only contains update-libc.d which only contains some avahi related file
<zzarr> when I run apt update it tries to connect to 192.168.0.14 which do not exist in my network
<zzarr> '0% [Connecting to 168.168.0.14 (168.168.0.14)]'
<zzarr> it's a beta version of Ubuntu 16.04 for Firefly Rk3288 I'm running (from the eMMc on a Firefly Rk3288 Plus)
<pvl1> hey all, im running a pcduino3b. can i upgrade the kernel and ubuntu nand, while running ubuntu from nand?
<pvl1> i know i can do it with a microsd card...
#ubuntu-arm 2017-01-29
<pvl1> hi everyone. im running kernel 3.4.79 for a pcduino3b, which uses an all winner a20, its armv7l. can i add repos for newer kernels and not mess things up?
<pvl1> oh the current release is precise
#ubuntu-arm 2018-01-25
<Vanta> Hey. I'm running a xenial arm64 installation on my phone in chroot (connecting through vnc). I'm trying to get software opengl working. I have mesa and libgl1-mesa-glx installed, but even when trying to use with LIBGL_ALWAYS_SOFTWARE=1, glxinfo says "Could'nt get RGB GLX or fbconfig"
<Vanta> I tried many other distibutions and it works out of box on fedora and in debian jessie with libgl1-mesa-swx11 package
<Vanta> From my understanding this package is not necessary to run via software mode, because LIBGL_ALWAYS_SOFTWARE provides better perfomance and was favored instead of swx11 package
#ubuntu-arm 2018-01-26
<ChunkzZ> can anyone recommend a web browser for ubuntu arm that's fast? not chromium or firefox...
<ChunkzZ> I did want to use palemoon but it's not on ubuntu 16.04.03 with arm64 :(
<k1l_> its not even in the repos for x86
<ChunkzZ> yeah, I see. still need a good web browser though :(
<ogra_> w3m ...
<ogra_> lynx
<ogra_> :)
<ogra_> though ... simply use armhf instead of arm64 and firefox/chromium shoul do well (arm64 binaries use about twice the amount of ram by design ... you wont have much fun with it if you have less than 4GB)
#ubuntu-arm 2020-01-23
<meonkeys> on http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ , why are there specific builds for rasberry pi 2, 3, snapdragon, etc? (as opposed to only arm64, i386, armhf OS builds). (crossposted in #ubuntu ... they directed me to this channel)
<meonkeys> never mind, moved to #ubuntu-discuss
