#ubuntu-arm 2010-04-19
 * Martyn swears loudly at the tegra2 board
<Martyn> this chip has the oddest frigging bottlenecks in performance!
<persia> So, I've got this source that hardcodes "armv4l" in ./configure, and fails to build for any other `uname -m`.  Anyone have a good suggestion on the safest way to patch that?
<Martyn> right now, I'm trying to improve streams performance .. and do you know where I found the bottleneck?
<Martyn> I can't make memcpy() fast.
<Martyn> DMA is fast as all getgo
<Martyn> mem copy?  Slow.  Slow as dog
<persia> What!
 * persia can't imagine how to implement something that would have that particular combination of performance metrics.
<Martyn> __aeabi_memcpy4
<Martyn> is what is being used .. aligned memcpy ...
<Martyn> it _should_ be fast.
<Martyn> I'm going to try to force it to use __aeabi_memcpy instead
<Martyn> persia : Any ideas?
<persia> None, sorry.
<persia> I don't really understand that low-level stuff.
<Martyn> There is no NEON on the tegra2, so I know the GNU optimizer won't try for that
<Martyn> (saving a potential 50 cycle penalty)
<Martyn> Well .. what I think I'll do is use PLD, ldm/stm about 32bytes to match the cache line size, and keep things aligned
<Martyn> but it SUCKS that I need to do that.
<Martyn> write my own memcpy()
<DanaG> hmm, say, those Marvell 1.2GHz ARM CPUs... how do they compare in desktop usage (i.e. firefox page-load, and such) to a 1.6GHz Atom, or to a 1.6GHz Athlon XP?
<persia> You can't really compare directly.
<DanaG> hmm.
<DanaG> How would you compare them, then?
<persia> Generally, you want to find some repeatable workload, and then run it on different hardware.
<persia> Depending on the available hardware features, you'll get varying performance.
<persia> But there's a huge set of dependencies on the actual workload.  Just being fast at one workload as no relevance whatsoever to being fast at another workload.
<DanaG> I'd find it interesting to put a radeon on an ARM processor's PCIe slot.
<persia> And lots of hardware has accellerated features for certain workloads or subsets, *especially* in the SoC realm.
<persia> I know folks have done that with some success in the past.
<DanaG> Speaking of ARM... I keep seeing Flash for Arm on Android... but what about every other ARM system?
<persia> MInd you, it's only interesting if you have workloads easily accelerated with a GPU...
<persia> Flash is available for just about any ARM system.
<DanaG> Compiz is my biggest GPU-usage thingy on any platform.
<persia> But I don't believe it's free.
<DanaG> Price, or source?
<persia> Both.
<DanaG> Dang, that sucks.
<persia> It's very definitely not free-as-in-speech, but I think it's also not free-as-in-beer.
<persia> Consider it an incentive to 1) improve gnash or 2) not use flash formats.
<DanaG> Right.  Flash sucks -- that's not news on any platform.
<hrw> morning
<XorA> hey hrw
<hrw> XorA: you had a problem to discuss
<XorA> hrw: touchscreen with Xorg, I beleive you did some work on making them just work (tm)
<hrw> what is a problem?
<XorA> hrw: the fact by default Xorg thinks they are touchpads
<hrw> never had such problem
<hrw> or moment...
<XorA> ah you never ran Angstrom without the nasty hack?
<hrw> show me modalias of it?
<XorA> hrw: I would if I knew how :-)
<hrw> XorA: cat `find /sys/class/input/eventX -name modalias`
<hrw> "input:*-e0*,3,*a0,1,*18,*" is regexp for touchscreen usually
<XorA> input:b0000v0000p0000e0000-e0,1,3,k102,14A,ra0,1,10,11,18,1C,30,32,35,36,mlsfw
<hrw> looks like ts for udev
<hrw> tslib works with it?
<XorA> hrw: yes in Angstrom
<XorA> ah lack of tslib in default lucid might not help
<hrw> try evdev driver in angstrom first
<XorA> well thats a secondary task, I need to get back to what Im supposed to be doing :-)
<ogra> tslib is available in ubuntu ... just not in any default install
<XorA> ogra: is what I just said
<ogra> you should be able to just install it (though it might miss config or patches for your specific board)
 * XorA is always wondering if evdev should just learn about touchscreens
 * ogra tries out the begale netinst image ... 
<XorA> tslib seems a bit pointless on modern kernels
<ogra> XorA, it knows about them
<ogra> XorA, but it ignores all that dont use the usbtouchscreen kernel driver
<XorA> ogra: which is stupid
<ogra> so make your LCD use that driver and it will work
<XorA> most touchscreens not being USB
<hrw> ogra: no shit
<ogra> well, most new ones in the x86 world are
<hrw> ogra: I have Atmel devboard which is fine with evdev driver
<XorA> x86 is probably >1% of touchscreen market
<ogra> and indeed development is focused in these shiny new touchscreen convertible x86 laptops :P
<hrw> bug 2.0 will work with evdev driver rather then with tslib one too
<XorA> hrw: in OE?
<XorA> hrw: so we can steal the magic
<ogra> the kernel driver needs to export some specifics (i forgot which) so evdev picks it up
<hrw> XorA: at91sam9263ek
<XorA> but its very unlikely usb touch will ever take off in arm world
<hrw> XorA: basically write xorg.conf part for input device with driver 'evdev'
<XorA> hrw: the trick is to do it without an xorg.conf
<XorA> hrw: which means udev magic
<hrw> XorA: and then check does it work. you can be forced to swap axes (option for evdev driver)
<hrw> XorA: first test does it work at all with evdev
<hrw> XorA: otherwise you will lose time
<XorA> it works as a touchpad
<hrw> XorA: ok
<hrw> relative not absolute position?
<ogra> XorA, well, its just some flags the kernel needs to set ... i'm sure you can make other drivers work with evdev, its just that none but usbtouchscreen export the right stuff yet
<XorA> so relative movements and no mouse clicks
<hrw> XorA: check drivers/input/touchscreen/ads7846.c - at91sam9263ek uses it
<hrw> iirc
<XorA> hrw: cool, will do
 * ogra sits in excitement watching d-i installing on the beagle 
<hrw> C4?
<ogra> yep
<ogra> http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/
<ogra> starting with that one
<ogra> if it works i'll test -server
<ogra> -desktop will need another image respin until it works
<ndec>  ogra: hi! so i't s working better now?
<ogra> ndec, it should be installable but hasnt been tested yet
<ogra> i'm half way through
<ogra> the bootloader stuff only entered the archive on friday and while all bits work they havent been tested inside the installer yet
<hrw> ogra: does it support hub connected to OTG?
<ogra> hrw, nope, amitk didnt manage to get proper testing from anyone with usable HW before kernel freeze
<ogra> we'll surely push an SRU kernel poist release though, if we can get enough tests from users that have OTG cables with the shortened pins that patch might go in
<amitk> hrw: do you have OTG HW?
<amitk> I don't have access to the special cable nor do I have time to solder one until after release...
<hrw> amitk: so far no luck with my cable
<hrw> amitk: beagleboard C3 has a jumper near otg to force host anyway
<ogra> C4 too ?
 * ogra sees a jumper next to OTG on his C4
<Sleep_Walker> hi, was anyone successful with kexec on 2.6.28-araneo?
<hrw> ogra: that one
<ogra> well, i might try it later then
<ogra> i cant risk to damage the board before all images are 100% sure to work
<amitk> hrw: good to know, now I only need a mini-to-mini cable
<ogra> but i have proper mini-> normal adapters to actually do the testing if OTG switching works
<hrw> amitk: you need usbA<>usbA female-female adapter
<hrw> btw - how many of you go to UDS?
 * lool is considering it
<ogra> heh
 * ogra wonders if we'll all be europeans there ... arriving by train or car this time round 
<ogra> given the flight situation
<lool> hrw: FYI https://wiki.ubuntu.com/UDS-M/Attendees and https://launchpad.net/sprints/uds-m/ have some lists of people too
<hrw> I know
<hrw> got mail from Alice about it
<amitk> hrw: all of us?
<amitk> (assuming the volcano is doused by some water)
<ogra> amitk, well, take a ferry :P
<amitk> ogra: actually not a bad idea. I've got a ferry to Rostok...
<hrw> ogra: I hope for plain - 12h in 2 trains is a bit too much
<ogra> amitk, yeah, rostock->bruxelles might make a nice train ride ... though all german trains are painfully full atm
<ogra> hrw, especially when sitting on your suitcase for the whole ride :)
<lool> ogra: rootstock -> bruxelles!!
<ogra> hahaha
<lool> Build a rootfs while taking the train
<ogra> i would be feared the hang inpacts the train though :)
<ogra> *fearing
<ogra> *impacts
<hrw> ogra: please... I once returned from London with having to stay still in overloaded night bus for 5h
<ogra> sigh, i need new fingers !!
<hrw> lool: to build rootfs in train power outlets are needed ;(
<ogra> hrw, all german trains have them
<amitk> what good is a train w/o power outlets...
<ogra> yeah
<ogra> some even have WLAN but not all of them yet
<hrw> amitk: come to Poland - here trains even have some power outlets but I would not put anything other then multimeter there
<asac> ogra: on ICEs you dont have power everywhere ... just by coincident from my experience on some seats
<ogra> asac, all ICEs have power between the seats
<ogra> i havent seen one without ever
<asac> i have ;)
<ogra> so everybody cross your fingers ...
<ogra> beagle d-i install finished without errors ... pray it boots !
<ogra> hmm, it boots but / is mounted ro
<ogra> sigh
<ogra> ext4 fs errors
<ogra> ogra@beagle:~$ lsb_release -a
<ogra> No LSB modules are available.
<ogra> Distributor ID:	Ubuntu
<ogra> Description:	Ubuntu lucid (development branch)
<ogra> Release:	10.04
<ogra> Codename:	lucid
<ogra> wohoo
<ogra> though i had to do two manual fsck's
<ogra> not sure thats the kernel or my USB key
 * ogra repeats the install and installs to SD this time
<Sleep_Walker> amitk: sorry to disturb you directly - is kexec on 2.6.28-araneo broken somehow?
<Sleep_Walker> amitk: or - do you know, who is aware of that?
<andruk> im trying to get the mcspi4 controller working on my beagleboard using the kernel sources here: https://code.launchpad.net/~beagleboard-kernel/2.6-stable/   but, i dont know which files to edit, as there looks to be many ways to implement spi.  should i just set the pinmux (arch/arm/mach-omap2/mux.c), or should i setup spidev (arch/arm/mach-omap2/board-omap3beagle.c)?
<ogra> ndec, so http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/ definately works ... (you need a NIC thats supported by the ubuntu kernel, i use an asix here ... create a vfat on SD, put the three files on it and just boot into the installer)
<ndec> ogra: thx. this is cool!
<ogra> install took about 1h here
<ndec> ogra: install on SD ?
<ogra> but pulls everything from network so speed varies based on net connection
<ogra> my test install was to USB key, but SD is supposed to work too, i'm testing that now
<amitk> Sleep_Walker: I am not working on araneo, please talk to AceLan in #ubuntu-kernel
<ndec> ogra: where on SD. you need to create a separate partition first?
<ogra> ndec, no, the netboot installer lives in ram after boot, you can just wipe the media you just booted from ;)
<ogra> it actually offers you the mmc in the partitioner
<ndec> ogra: this is great. where do you put the uImage?
<ogra> ndec, you mean after install ?
<ndec> ogra: yes. so that it finds it after reboot
<ogra> ndec, it turned out to be easier to overwrite NAND for now, so initrd and kernel live in NAND
<Sleep_Walker> amitk: thank you!
<ndec> ogra: K. i see. so when kernel is updated it goes to NAND as well. is it possible to keep a FAT boot partition for kernel ?
<ogra> ndec, we surely need to revisit that for 10.n+ but time was very short to get anything going
<ndec> ogra: yes, for sure. we might have boards without NAND as well!
<ogra> ndec, as i said we have to come up with something, /boot on fat isnt possible in itself since dpkg tries to create hardlinks during package upgrades for the vmlinuz file, what we will likely do is to have a /boot/uboot partition that we treat like flash ors something similar in later releases
<ogra> ndec, or better something thats mounted during flash-kernel phase or some such, i discussed several models with lool last week, for beagle C4 the NAND variant is the best one for now
<ogra> s/mounted/mounted temporary/
<ogra> and especially for the short time i had to create an image it was the only achievalbe thing
<ogra> *achievable
<ogra> all future images can change and there is a lot room for improvement :)
<ndec> ogra: ok. we can talk on that after 10.04
<ogra> ndec, yes, we have to
<ogra> its on my list for things we will have to improve
<ndec> ogra: and we want to as well ;-)
<ogra> yeah :)
 * ogra goes for a coffebreak, install to SD is a lot slower 
<XorA> amitk: I have OTG cables that are known to work
<amitk> XorA: I'll push out a kernel with OTG enabled for your testing pleasure (probably tomorrow after some release-related work)
 * XorA has zero omap3 devices with EHCI ports
<hrw> XorA: no C2-4 beagleboard even?
<XorA> hrw: C3 EHCI is broken :-(
<hrw> ok
<XorA> hrw: it was working for about an hour, then it just died and works no longer
<hrw> welcome in cruel omap3 world
 * hrw -> out
<ogra> https://wiki.ubuntu.com/ARM/BeagleNetInstall
<ogra> everybody: feel free to enhance :)
<Kamondelious> I just finished following this with pretty good success (so far) http://elinux.org/BeagleBoardUbuntu
<Kamondelious> https://wiki.ubuntu.com/ARM/BeagleNetInstall seems like a better place to have good docs though
<ogra> well, one is community built, one is using an official ubuntu image
<Kamondelious> I understand that
<ogra> https://wiki.ubuntu.com/ARM/BeagleNetInstall is for the image we will release with ubuntu arm this month
<Kamondelious> just thinking might be a good place to help with adding to the official docs initially
<Kamondelious> cool
<ogra> http://elinux.org/BeagleBoardUbuntu is definately more flexible and uses its own kernels which might have additional features over the ubuntu kernel though
<ogra> we will also have a netbook and a server installation image
<Kamondelious> cool
<Kamondelious> I'll be following the arm progress for sure
<Kamondelious> my beagleboard needs an OS and I'd prefer to keep with something familiar  ;)
<ogra> thats why we build the images :)
<Kamondelious> indeed
<ogra> yay
<ogra> so install to SD works as well
<ogra> amitk, i see an opps, seems OTG related
<ogra> ogra@beagleC4:~$ lsb_release -a
<ogra> No LSB modules are available.
<ogra> Distributor ID:	Ubuntu
<ogra> Description:	Ubuntu lucid (development branch)
<ogra> Release:	10.04
<ogra> Codename:	lucid
<ogra> :D
<ogra> ogra@beagleC4:~$ mount |grep 'on / '
<ogra> /dev/mmcblk0p1 on / type ext4 (rw,errors=remount-ro)
<ogra> \o/
<Kamondelious> sweet
 * ogra files bug 566639
<ubot4> Launchpad bug 566639 in apt-setup (Ubuntu) "omap install ends up with security.ubuntu.com urls in sources.list after install (affects: 1)" [Undecided,New] https://launchpad.net/bugs/566639
<ogra> plars, GrueMaster ^^^ can you check if thats also the case under imx51/dove ?
<plars> ogra: the imx51 install I did on Friday did not have security.ubuntu.com
<ogra> plars, cool, can you comment on the bug that you dont see it on imx51 ?
<ogra> amitk, bug 566645 for you
<ubot4> Launchpad bug 566645 in linux-ti-omap (Ubuntu) "doing a netinstall to SD card results in OTG related oops on first boot (affects: 1)" [Undecided,New] https://launchpad.net/bugs/566645
<plars> ogra: will do
<ogra> thanks :)
<ogra> plars, also https://wiki.ubuntu.com/ARM/BeagleNetInstall ... happy installing :)
<plars> ogra: woo!
 * ogra goes to test the server image now 
<ogra> -netbook still needs a respin with the latest ubiquity
<hrw> re
<hrw> 7Mbps usb ethernet suxx
<prpplague> there an easy way to configure the auto mount to not open a window on the desktop every time it automounts a device?
<dmart> prpplague: yes, though there's no user-friendly menu config option for it.  Instead, run gconf-editor, and disable apps -> nautilus -> preferences -> media_automount_open
<ogra> ugh
<ogra> indeed there is a config option for it
<ogra> its in the nautilus preferences
<dmart> Really? Oh well, do that then :)
<prpplague> dmart: thanks
 * prpplague tries that
<ogra> just open a nautilus window ... edit->preferences ...
<ogra> in the devices tab
<prpplague> ogra: hmm, i don't see a devices tab
<ogra> might be called differently, german installation here :)
<ogra> prpplague, you are on lucid, right ?
<dmart> There's Media -> "Browse media when inserted" which is probably what prpplague wants
<ogra> media, yeah
<prpplague> ahh found it
<dmart> I often want to disable automount completely, which you can only do through gconf-editor :/
 * prpplague tests
<ogra> there is also "dont perform any action ..." here
<prpplague> dmart: yea i hate auto mount
 * ogra loves it 
<ogra> i rely on it for all my SD stuff
<dmart> Depends what you're trying to do :)
<ogra> lets you get very lazy though
<prpplague> and eject doesn't seem to work as expected in ubuntu
<ogra> ??
<ogra> it removes the device
<ogra> its a kernel feature
<ogra> there is a separate unmount function in the context menu if you want to keep the device node of an USB device
<prpplague> ogra: yea, normally i would expect that if you have /dev/sdb1 and /dev/sdb2 mount, you could issue the command: eject /dev/sdb and it would unmount /dev/sdb1 and /dev/sdb2 and eject the removable device
<ogra> ah
<prpplague> ogra: on ubuntu it fails
<dmart> Was eject ever that clever?
<ogra> well, there were some upstream kernel changes in that area, not sure thats ubuntu specific
<prpplague> dmart: works fine on fedora and debian
<dmart> ok then
<ogra> it definately removes all device nodes if you klick the little eject thingie in nautilus
<hrw> have a nice rest of day
<prpplague> hrw: later
<prpplague> ogra: i'll have to dig into that, possible the syntax has changed
 * ogra goes back to TV to watch snooker champoinship while the beagle server install runs ... watching d-i work is tiring 
<prpplague> ogra: fun fun, thanks for the info
<prpplague> dmart: you too
<ogra> ndec, hmm, smells like there are additional changes in the omapbf package needed
<ogra> *omapfb
<ogra> your log definately shows that the loading works correctly
<rcn-ee> laughs, flash-kernel works a little too great... but the omap kernel works good on my Bx beagle..
<ogra> ok, server install on beagle works fine as well !
<ogra> \o/
<ogra> two happy images already
<rcn-ee> sounds great ogra.. ;)
<ogra> rcn-ee, what dont you like about flash-kernel ?
<rcn-ee> laughs, it's overriding my external kernel.. ;)  I'm trying to add a /etc/flash-kernel.conf override shortly after debian-install creates the partition.. ;)
<ogra>  /etc/flash-kernel.conf isnt used
<rcn-ee> But i discovered the omap kernel works great on a Bx, otg/dvi etc..
<ogra> edit /etc/kernel-img.conf or flash-kernel itself
<rcn-ee> yeah, that one.. sorry was looking at both...
<ogra> or even uninstall flash-kernel
<ogra> since you would also have to edit update-initramfs otherwise
<rcn-ee> i have it echo "you are using the community kernel, remove this file to use ubuntu's" then it calles exit, which works...
<ogra> safest is to just apt-get remove it
<rcn-ee> Yeah, that would be the safest.. Except i decided to hack into the NetInstall... ;)
<ogra> ah, heh
<rcn-ee> ps: i put your wiki link here: http://elinux.org/BeagleBoardUbuntu#NetInstall so you shoudl get more users, i didn't know what else to put other then the http link...
<ogra> awesome, thanks !
<ogra> i'll also blog about it once i have all images tested
<ogra> though netbook is still building and its my turn with cooking today
<rcn-ee> that's going to be a fun week, I'll be in esc so i'm going to miss all the thursday/friday release fun..
<ogra> so i'll call it a day now ...
 * ogra has to cook a trout ... never done that ... will be intresting
<Martyn> Hey, ogra (or anyone else) .. who made a server armel image?
<Martyn> where is it hiding?
<Martyn> (I'm sitting in an office with Rob and Dustin)
<rcn-ee> I don't know if he uploaded it yet, he used the NetInstall methiod..
<ogra_cmpc> http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/
<Martyn> thanks for the link
<chrismurf> I'm new to ARM development.  I have a proprietary library (camera driver) that "has EABI version 0" and I am trying to compile it with an "EABI version 4" toolchain.  Or at least I think that's what my console is telling me.  Can somebody point me in the right direction on what it means and how to resolve this?
<XorA> I think its more likely its an OABI binary
<chrismurf> entirely possible - can you give me the short version of what that means?
<chrismurf> how I could determine that?
<chrismurf> I guess what I'm trying to determine is which of the following is true:
<chrismurf>  * I can "wrap" the proprietary library somehow and link it against other code.
<chrismurf>  * I could install an older version of linux/compilers/etc. and make everything the same version as the library.
<chrismurf>  * I'm up a creek unless I can get a different version of the library.
<XorA> chrismurf: up the creek is the safest estimation, you can make an OABI chroot, but that depends on ubuntu kernel fully working with OABI
<chrismurf> XorA, what if I went back several versions of ubuntu/debian/whatever?  I'm happy to do that if it would fix the problem.
<XorA> we had similar issues with GPS chip in OpenMoko and it was always pain
<chrismurf> or does Cortex-A8 mandate the EABI?
<XorA> chrismurf: pre armel version of debian should work
<chrismurf> okay
<chrismurf> and I'll just see decreased floating point performance and what have you
<XorA> chrismurf: the main issue is no-one is doing it so support rapidly rots
<chrismurf> duly noted
<chrismurf> the evils of proprietary libraries
<chrismurf> sadly sometimes we don't have choices in these matters
<XorA> could try sending ubuntu dudes to chat with the vendor
<chrismurf> we just shot the vendor an email
<chrismurf> they've been decent folks in the past, maybe we'll get lucky
<chrismurf> suspect they just haven't had call for a recent ARM version
<XorA> Ubuntu is the current buzzword for PHB so just mentioning their stuff doesnt work might be enough
<chrismurf> duly noted ;-)
<Martyn> re
<Martyn> After meeting with Dustin and Rob, we've got a good idea now for what blueprints Smooth-stone will be working on for UDS-M
<axisys> anyone run ubuntu on dockstar ? it is an arm chip
<axisys> http://ahsoftware.de/dockstar/
<axisys> it says you can install ubuntu .. but not in much details
<axisys> http://ahsoftware.de/dockstar/
<axisys> this page says debian does not support seagate freeagent dockstar
<axisys> http://www.cyrius.com/debian/kirkwood/sheevaplug/plugs.html
<axisys> is that mean ubuntu arm won't compile in here ?
<Martyn> axisys:  Ubuntu Lucid ( and M ) will not work on the sheeva based device
<Martyn> because sheeva is arm version 5 code, and lucid/M are compiled thumb2 which requires arm version 7 code
<Martyn> you can, however, use debian if you like\
<DanaG> Dang.
<axisys> how about karmic ? will sheeva based devices work with karmic ?
<rcn-ee> nope karmic is armv6
<axisys> looks like jaunty will work
<axisys> armv5t
<tormod> the sheeva is shipped with Jaunty isn't it
<persia> Kinda.  It's shipped with a custom derivative of jaunty.
<axisys> tormod: oh ok
<axisys> persia: thanks
#ubuntu-arm 2010-04-20
<DanaG> Bummer.  Are there any Marvell ARM thingies that WILL run lucid?
<DanaG> I'm still wanting an ARM with PCIe slot. =Ã¾
<Martyn> DanaG : Dove
<Martyn> and an ARM with a PCIe slot -- is a tegra2
<Martyn> two PCIe 1x slots in fact
<Martyn> (Mini PCIe)
<DanaG> Hmm, but that already has a video card... a non-open one.
<DanaG> Interesting adapter: http://www.hwtools.net/Adapter/PE4L.html
<persia> Doesn't mean you have to use it.
<Martyn> well, pcie doesn't have a lot of bandwidth, when you're using just one lane
<Martyn> DanaG : But even if it's not open, that doesn't mean there aren't open source DRIVERS for it
<Martyn> 2D is well supported
<persia> WIth nouveau?
<Martyn> why would nouveau even work?
<Martyn> the technology in use on the tegra2 has nothing in common with the nvidia GPU's
<Martyn> it's made by nVidia..
<Martyn> that's about it
<persia> Ah :)
<Martyn> 2D is supported by it being a bog-standard framebuffer
<persia> Which drivers then?
<Martyn> fbcon
<persia> Oh.  That make sense.
<Martyn> persia : And I even disabled /that/
<Martyn> since it steals memory that I want for appliations
<persia> heh.
<Martyn> servers don't need memory, so instead of having nearly a gig, I had barely more than 600meg
<Martyn> servers don't need VIDEO rather
<persia> Right.
<persia> I'm down 512MB on one of my servers for similar reasons, and thinking about fixing it (although with 4G, it's a little less painful)
<DanaG> hmm, I can't find much about Marvell Dove.  No boards easily findable.
<Martyn> They aren't easy to get, no.
<Martyn> DanaG : Frankly, if you're patient, there is a new OMAP44xx board coming out soon
<Martyn> and that is a DUAL CORE cortex a9
<Martyn> more than powerful enough
<Martyn> or you can spend $300 and get into the tegra2 program
<DanaG> I'm not in any rush to buy anything... I'm just eyeing stuff and thinking "ooh, that looks interesting." =Ã¾
<Martyn> well, closer to $400
<Martyn> it's a great board though, and we have ubuntu working now
<DanaG> Hmm, is there info about that board, publicly available?
<DanaG> heh, I can't find even a _picture_ of the Marvell Dove boards.
<DanaG> http://swik.net/Gentoo/Planet+Gentoo/Ra%C3%BAl+Porcel:+ARMv7+SoCs:+Freescale+i.MX51+Babbage,+TI+OMAP3,+Marvell+Dove%2FArmada,+Qualcomm+Snapdragon%E2%80%A6/do9pt
<DanaG> ah
<DanaG> I see... it's all very new stuff.
<Martyn> DanaG : There's even a public FORUM for development of tegra2
<Martyn> http://developer.nvidia.com/tegra/forum
<Martyn> I am prevented from photographing it due to NDA, but it's neat
<DanaG> Can you say if it's a mobile form, or a desktop-ish form?
<DanaG> Desktop-is as in, openrd-base counts as that.
<Martyn> mobile, about 15cm on a side, square
<Martyn> embedded memory, two PCIe slots, three USB, one USB OTG (used to load firmware), etc..
<DanaG> Spiffy.
<DanaG> Hmm, is there an expiration date on that NDA?  Or is the date itself... under NDA?
<persia> Martyn: Are you allowed to describe the embedded memory?  raw NOR, raw NAND, uses FTL, etc.?
<persia> (and how much?)
<Martyn> persia : There is 1GB of 667MHz DDR2 ram
<Martyn> I honestly don't know how much flash there is, but there is quite a bit
<Martyn> there is no NOR that I'm aware of, but I have a SPI nor chip attached (8mbit) for my own use
<Martyn> I know they also have some kind of SPI EEPROM
<persia> Thanks.  I'm mostly interested in flash, as I like the idea of / on NAND, but that can wait for retail :)
 * persia is mostly happy to wait for retail, but kinda wishes things would move a little faster sometimes
<Martyn> http://developer.nvidia.com/tegra/tegra-devkit-features
<Martyn> They released a devkit picture and overview!
<Martyn> No more NDA for me then
<Martyn> 512MB SLC nand
<persia> Nifty!
<Martyn> it's a droolable board, and they are just now out of stock too
<Martyn> more stock coming around May 1
<persia> Oh :(  512MB isn't quite enough.
<Martyn> It's PLENTY for a boot/root filesystem
<Martyn> you can put /usr on something else
<persia> Yeah.
<Martyn> persia : Consider for a moment, that ALL of android fits in 64MB
<Martyn> 128MB on th eoutside
<persia> My preference is / on NAND, and /var, /home on rotary (as I churn that), but that's just me.
<persia> I only consider Ubuntu, which wants ~2GB for the base install.
<Martyn> doens't need to be
<Martyn> I've gotten the base down to 384M
<persia> Depends on the install.  servers can be a lot less.
<Martyn> base is -very small-
<Martyn> everything else on top of it is big
<persia> Right.
<Martyn> but my tarball of base is 276mb right now
<Martyn> uncompressed
<persia> My armel buildd chroot is 304MB uncompressed.
<Martyn> that's about right
<Martyn> and if you do tasksel server, it increases to ~380
<persia> (base+build-essential+vim-tiny+less)
<Martyn> yeah, you need GCC in there
<persia> For my buildd?  Yeah :)
<persia> But it gets *lots* bigger when you install all the Desktop/Netbook stuff.
<Martyn> depends what you install
<Martyn> I have basic browser, and support files, coming in at ~780m
<persia> Oh, did you ever get a chance to dig into eucalyptus-nc and make it work for headless managed servers, rather than just KVM?
<Martyn> no
<Martyn> that's our new blueprint for UDS-M
<Martyn> one of three that we've decided on
<persia> Oh, cool.
<persia> What are the other two?
<Martyn> eucalyptus + LXC is one
<Martyn> arm-server image without kernel/initrd
<Martyn> so that more people can just download the .img and get working
<Martyn> (because other than kernel/initrd .. all armv7 images are the same)
<persia> I'm philosophically opposed to that, because I think separating the kernel from the rest of it is poor design, but yeah, that's probably best until we can *fix* the issues with ARM kernels.
<Martyn> yep.
<persia> Actually, do you have a working qemu target for your board?
<Martyn> but the kernel --is-- separate .. there's no reason you shouldn't be able to get a .img of an ext4 filesystem
<Martyn> no.  We are not going to do QEMU of our board
<Martyn> we're not in the business of building simulators
<Martyn> by not doing so, we'll get to hardware that much faster
<persia> Fair.
<persia> Means no chance of changing the qemu kernel target though :)
<Martyn> plus the performance of qemu of multicore architectures -sucks-
<Martyn> much less of quad core
<persia> Yeah :)
<Martyn> much less one with 4GB of ram
<persia> But I argume the kernel isn't separate: it inherently depends on the toolchain, and is interrelated.
<persia> The initrd is even more not separate, since it's constructed based on the filesystem.
<persia> And the filesystem contains all the kernel modules, etc.
<Martyn> but the initrd is mostly -not used- by ARM targets
<persia> But that's all well-known, and it doesn't make the situation better for folks stuck in the embedded model.
<Martyn> in fact, Dustin and I use monolithic kernels
<Martyn> right
<Martyn> so, if you ignore it (and you can .. ) things get easier
<Martyn> plus you can build the initrd after completing the install with a monolithic kernel if needed
<persia> Well, I won't ignore it, but I'm willing to take a longer term view, and let folks work around it for now :)
<persia> For some classes of install: the d-i installer is based inside the initrd, for example :)
<persia> Which installer is the one used by the server installs.
<persia> But I'll attend the session: some of this can be worked around.
<persia> And what can't can probably be scripted in some way.
<persia> So, what's the third spec?
<Martyn> that's private for now
<Martyn> but just for a week or so while the guy working on it gets it completed
<Martyn> it's something around cluster control
<Martyn> (aka cloud control)
<persia> OK.  From your first comment I worried that you'd forgotten that UDS is incredibly public (sessions are icecasted, specs are on the internet, etc.)
<Martyn> No, I just don't want to say what I don't know :)
<persia> That's as much detail as I sought.  Makes sense, given the vision from your webpages.
 * DanaG sticks with ubuntu.  Angstrom is a pain.  Ubuntu on my beagle matches my host system's development environment perfectly. =Ã¾
<DanaG> hmm, is the GPU on that a PCI device, or a "platform" device (a.k.a. not PCI)?
<DanaG> And can it run compiz? =Ã¾
<DanaG> hmm, which of the two slots is "external" MMC/SD?
<persia> It's times like this that one wishes vendor spec sheets came with dmesg output and lspci -vvn and lsusb -v :)
<DanaG> yeah.  I'd hardly call that too much to ask.
<persia> I think we need generic booting kernels first.
<persia> Most of the other architectures have them, so now we just look silly.
<persia> Mind you, powerpc seems to be moving in the multi-kernel direction, but I hope that's just a short-term thing.
<DanaG>  error: expected type-specifier before âboostâ
<DanaG> ARGH
<DanaG> er, wrong tab... off-topic for this channel.
<ericm> who can point me a cross compiling friendly debian package as an example?
<lool> ericm: You mean to cross debuild it?
<lool> ericm: You could try the x-loader or u-boot packages in lucid, I fixed them to be cross-buildable
<ericm> lool, thanks - I'll take a look
<ericm> lool, are they tracked with bzr?
<lool> ericm: All packages are nowadays  :)
<lool> well almost all
<lool> ericm: try bzr branch lp:ubuntu/x-loader
<ericm> https://launchpad.net/ubuntu/lucid/+source/x-loader, I'm seeing it might be managed with git?
<lool> ericm: the git you see there is in the version because it's coming from git upstream
<lool> So the version mentions this is a git snapshot
<ericm> lool, ok - so it's actually managed by git and synced on lp with bzr?
<lool> ericm: The way to retrieve exactly what's in the archive locally is "apt-get source", when you actually want to commit to the *packaging* vcs of some package, you can check whether the package has Vcs-* headers, or simply use "debcheckout" which will checkout the relevant Vcs (or just apt-get source if no Vcs was found)
<lool> ericm: *Upstream* uses git
<ericm> lool, ah I see
<lool> ericm: For instance, I uploaded a snapshot of valgrind 3.6.0 from SVN and used:  Version: 1:3.6.0~svn20100212-0ubuntu4
<lool> Just to reflect that I took the snapshot on 20100212
<ericm> lool, so the bzr only tracks the snapshots, not exactly sync'ed with upstream in full history?
<lool> ericm: We have automated imports of what reaches the archive into bzr
<lool> ericm: So the history is only that of the Ubuntu uploads
<ericm> lool, btw - it looks to me x-loader/debian/rules is strange, no binary target?
<lool> ericm: we have another import for the debian upload, and these are done in a compatible way so that you can merge between them
<ericm> and dh_auto_build seems to do the magic of cross compiling?
<lool> ericm: However if we were to track upstream history (which we do relatively rarely), we'd have to setup a git import in Launchpad first
<lool> ericm: That's the new style "dh" rules, it basically say "do the standard thing unless I write an override"
<lool> ericm: You could try cross-building zlib
<lool> it's more standard-style
<ericm> lool, ok let me take a look
<hrw> hi
<lool> hi
<ericm> lool, well it looks like zlib doesn't specify --host in its configure, just with a CC assignment before ./configure, which will work in most cases?
<lool> ericm: zlib is not using autoconf IIRC
<lool> ericm: So its configure doesn't support --host and --build
<lool> ericm: Yes, the package should cross-build, I cross-built it recently
<ericm> and CC="$(DEB_HOST_GNU_TYPE)-gcc" doesn't work with codesourcery toolchain and others
<lool> ericm: To cross-build it, try something like DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -B -us -uc -aarmel -d
<ericm> might need some way to specify the toolchain if it's not using the standard gcc naming convention
<lool> ericm: Yes, that's the first problem you'll encounter
<lool> ericm: then your package will also fail to build near dh_shlibdeps because codesourcery doesn't include debian specific shlibs information
<ericm> lool, :-(
<lool> ericm: I'm afraid it's not possible to switch triplet, many many upstreams expect $triplet-gcc
<hrw> lool: OE has patch to make zlib more autotools
<lool> ericm: What you need is debian/ubuntu cross-building training  :-)
<lool> hrw: Wont help dh_shlibdeps I'm afraid
<ericm> lool, yes - any references?
<ericm> lool, I'm a slack
<lool> ericm: Let me email you the slides
<ericm> lool, that will be nice
<hrw> we remove configure, makefile.in and place configure.ac + makefile.am + zlib.pc.in
<hrw> lool: probably not
<lool> ericm: You're not going into safe and nicely working territory, this is pushing the limits of our current systems a bit  :-)
<nosse1> lool: Would it be possible to gain a copy of those slides?
<nosse1> lool: We are working with the same issues here.
<lool> ericm: sent
<ericm> lool, thanks
<lool> nosse1: It would, but I'd have to strip them slightly and double-check internally
<nosse1> lool: Please do. I'd be grateful.
<lool> nosse1: Sorry, what's your real name again?
<lool> nosse1: will check
<nosse1> lool: My name is Svein Seldal
<lool> nosse1: People who I need to check with are sleeping still; I'll check later today, if I forget, please remind me
<ogra> lool, time for an #ubuntu-classroom session ;)
<nosse1> lool: FYI I've finally installed Lucid on AM3517 eval kit from TI. And I'm using the CS toolchain to cross the kernel, qt and our application while running "mainstream" ubuntu on the rest
<lool> ericm: I'm afraid you'll miss the '[ DEMO ]' parts  :)
<lool> ericm: xbuild.txt has notes on what I'd actually be typing there
<lool> nosse1: Nice
<ericm> lool, I went roughly through the first several slides, and decided to native build in my chroot :-)
<lool> ericm: lol
<lool> ericm: I think you're doing the right thing
<lool> ericm: For people with very slow hardware, or generally resource-constrained hardware or no hardware I'd advocate trying qemu-user
<lool> I think I should fix our cross-build tool to not care about build-dep loops when converting pre-built packages from the archive
<ericm> lool, indeed
<nosse1> Since it is possible to mix host and target binaries in a chroot environment I played with the idea to inject the CS cross compiler into the chroot env to use host native tools for building.
<lool> If I were to fix it, we'd have a single tool one step way of cross-building any package which can be cross-built *if* you have a dpkg-cross compatible toolchain
<nosse1> I don't know if it's even possible or if it's just an crazy idea... :o
<lool> nosse1: It's definitely possible, I cover this in my slides, well I mention the idea
<lool> nosse1: it's possible in three ways
<lool> nosse1: a) real hardware + icecc to move the actual compilation from your slow hardware to a remote intel host running a cross toolchain
<lool> b) QEMU machine emulation (emulating hardware), just like a)
<nosse1> Point is target native compilation, qemu/chroot is all very slow. That is the one reason you would want to use the CS cross compiler
<lool> c) qemu-user emulation or sb/sb2 like emulation and actual intel binaries in your chroot; "croco" which suihkulokki maintains upstream on gitorious does this
<lool> nosse1: the compilation isn't the only slow point though
<lool> that's typically the case for large C++ apps like Qt, but there are other issues
<nosse1> lool: You asked about my name. Here's my lauchpad profile: https://launchpad.net/~sveinse
<ogra> wow, the netbook installer looks really nice
<lool> nosse1: Yup found it googling your name
<persia> lool: Are you planning to drop clean croco support into maverick?
<lool> persia: drop?  you mean provide/upload?
<persia> Yes.
<ogra> drop into :)
<lool> persia: I'd love to
<nosse1> lool: I need to go to a meeting. I'll remind you later if doesnt hear anything ;)  Thanks!
<persia> Lovely.  Will this be something that has to be installed on both the chroot and the host, or just the chroot?
<lool> persia: Just the chroot
<lool> persia: it's qemu-user style emulation
<persia> So how does it get to the non-chroot binaries, or does one have to install both architectures in the chroot?
<lool> persia: exactly
<persia> Oh :)
<lool> There are various approaches to this kind of hack; in croco, you have a croco.map file which is used when intercepting exec() calls
<persia> I don't suppose there's some way we could adjust the binfmt-misc wrapper to catch some stuff and execute that natively without adding to the chroot, is there?
<lool> not really
<lool> I mean, the kernel/binfmt will do the right thing and run the proper binaries
<lool> That is, it will see that's for intel and just run them without qemu-arm-static
<lool> or see it's for arm and run them with it
<persia> RIght.  I was kinda hoping for a way to get croco acceleration out of a Souyz chroot, but I don't think that's feasible.
<lool> What the kernel doesn't do is remap what you really want to run depending on the path
<persia> Needs a special crocoised chroot.
<lool> I personally think security tools might be a better fit for this, but I'm not technical enough to look into it yet
<lool> persia: Well you typically want your apps to run chroot-ed as to limit their view on files to the ones you have in your build env
<lool> If they run chrooted, then you need chrooted binaries and their libraries; you could run them from the outside and then chroot, but many of them fork() to run other apps
<lool> such as gcc calling cc1 or so
<persia> Oh, certainly.  I just wanted to reuse the same chroots for native and non-native.
<persia> But I don't think that this will work with croco.
<lool> persia: That works
<ogra> binfmt should catch that
<ogra> but you will effectively end up with two full environments in one
<lool> persia: When you enter the chroot with croco turned on, it intercepts calls to e.g. /usr/bin/gcc, but if you enter it normally, it doesn't
<lool> ogra: Not related to binfmt really
<persia> ogra: Indeed, and it works well, so I can just `pull-soyuz-chroot lucid armel; sbuild -d lucid-armel-soyuz foo.dsc`, but that's not as fast as it could be.
<persia> lool: Right, but the chroot needs to be multi-arch for croco to work, which the soyuz chroots aren't (and shouldn't be).
<lool> persia: What do you mean multi-arch?
<persia> having e.g. i386 *AND* armel binaries.
<lool> persia: What I mean is that once you've included croco in your chroot (currently in /croco) you can still use it as before
<persia> Right.
<persia> So we can have a script that adds croco to a chroot, but we can't expect to install something on the host that automatically does croco-acceleration for all chroots.
<lool> persia: Well unless you make it part of your build tool, e.g. mount --bind /host/croco /build-chroot/croco
<persia> And all the native stuff would live under /croco ?
<lool> Yes
<persia> Oh, suddenly that looks a lot nicer.
<persia> Right.  I think I have an idea how to do that, at least for schroots.  pbuilder will require more investigation.
<persia> (or rather pbuilder-dist integration: pbuilder has hooks that make it easy for folks that know how to use pbuilder)
<ogra> #define DEFAULT_DEVICE "/dev/fb"
<ogra>  /* FIXME: We don't really want to do it like this... */
 * ogra grumbles about the omapfb xserver 
<ogra> they could at least have picked fb0
<persia> So, XorA suggested we could (temporarily) ship a udev rule in the xserver package that would add the symlink.
<persia> XorA also suggested that he expected to be directed to fix it in the near future.
<ogra> well, given that we're in hard freeze it wont happen for lucid anyway
<ogra> and for maverick we should just fix it properly
<lool> Can't we fix this omap specific package instead?
<lool> How does Debian do it?
<ogra> lool, thast what i was saying :)
<ogra> fix it properly by adding a routine that detects the device instead of hardcoding it
<lool> ogra: switching to fb0 would be good enough for lucid
<ogra> sure
<persia> It's not terribly difficult to fix, but if XorA plans to fix it, I'm not sure of the value of trying to fix it before him.
<lool> persia: Having the package in lucid work?  :)
<persia> That's trivially done by shipping a udev rule to create the node the software wants.
 * ogra checks the other omapfb package as well ... i bet it uses the same hack
<persia> Could add a s/fb/fb0/ patch, but I had the impression from the discussion this weekend there was some reason this was complex.
<lool> .BI "Option \*qfbdev\*q \*q" string \*q
<lool> The framebuffer device to use. Default: /dev/fb0.
<lool> From man/fbdev.man
<lool> apparently this is a xorg default for options named "fbdev" -- couldn't find any actual default in xorg-fbdev
<ogra> persia, given that we only support one board atm and in the light that fb0 is usually the default i think its safe to just take fb0
<ogra> for maverick we should add some detection code though
<persia> XorA|gone: When you get back, please explain why this is a good/not good idea in some detail.
<lool> fbdevHWInit(pScrn,NULL,xf86FindOptionValue(fPtr->pEnt->device->options,"fbdev"))
<persia> ogra: My fear is that the hardcoding is more complex and deeper than you think.
<ogra> persia, not really
<ogra> but i'll test it as soon as this netbook install is done
<ogra> (if that finishes before the volcano stops spitting ash :P )
<persia> OK.  All I can advise is to check the weekend backscroll.  If it trivially works, go ahead.  If it doesn't, let's work around it for lucid.
<lool> persia, ogra: So apparently, xorg-server/hw/xfree86/fbdevhw/fbdevhw.c does the default on fb0
<lool> It can be overriden with FRAMEBUFFER in the env
<lool> or in the config obviously
<ogra> yeah
<ogra> so omapfb should just do the same
<persia> lool: Indeed.  THis is an omapfb-specific bug.
<persia> (and known to be a bug)
<lool> fbdevHWInit() calls fbdev_open() which open()s the fbdev, and that's pretty much it; I think src/omapfb-driver.c could do the same
<lool> Uh plus it checks for fd > 0 ohw ugly
<persia> There's some trickiness in omapfb because it makes assumptions that certain fbX devices have certain special features/functions.
<persia> And this needs massive cleanup (upstream), which is why I believe the lucid-timeframe answer is a udev rule.
<ogra> these are in different source files
<ogra> xv has its separate source and uses fb1
<ogra> root@babbage2:/xf86-video-omapfb-0.1.1# grep -r /dev/fb *
<ogra> src/omapfb-driver.c:#define DEFAULT_DEVICE "/dev/fb"
<ogra> src/omapfb-xv.c:#define OMAP_FBDEV1_NAME "/dev/fb1"
<ogra> in that light src/omapfb-driver.c should just be hardcoded to fb0
<cooloney> plars and GrueMaster, could you please guys to help look at bug #567157
<ogra> unless lool wants to add the proper fbdev_open() calls :)
<ubot4> Launchpad bug 567157 in linux-fsl-imx51 (Ubuntu) "regulators enabled at boot and also print error messages at boot. (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/567157
<lool> ogra: I'll do it in my CFT
<ogra> CFT ?
 * ogra wonders what C means
<lool> copious free time
<ogra> ah
<eggonlea> hi, anybody knows about netbook-launcher-efl? Would the XV window get damage info again after it redraws application GUI (e.g. totem)? Now it seems destroys the colorkey background so video cannot be shown correctly.
<ogra> bah, crap flash-kernel fails in ubiquity
<lool> eggonlea: Sorry no idea
<lool> Who's maintaining netbook-launcher-efl here?
<lool> JamieBennett: is that you?
<JamieBennett> lool: mterry
<persia> Isn't mterry upstream?
<JamieBennett> persia: he is now but not the original upstream
<lool> eggonlea: Try pinging mterry on #ubuntu-devel or so, he's upstream and is easter time
<lool> *eastern
<JamieBennett> he is looking after n-l-efl
<eggonlea> lool: great, thanks!
<persia> Yeah, well, teams have member turnover, but an upstream contact is an upstream contact :)
<JamieBennett> persia: :)
<nosse1> lool: I hope I wasn't rude or anything about requesting the presentation earlier on. I was kind of in a hurry, so I threw myself into the discussion
<lool> nosse1: Oh not at all
<lool> nosse1: I wouldn't have mentionned it here if there was no chance of publishing it
 * sveinse got his beloved old nick back. *nosse1* is now known as *sveinse*
<sveinse> Is #ubuntu-arm logged anywhere?
<rcn-ee> sveinse, http://irclogs.ubuntu.com/ but usually an hour behind.. ;)
<ogra> irclogs.ubuntu.com
<sveinse> rcn-ee: np, I'm looking for something weeks old
<rcn-ee> ogra, so i was playing around with different methods...  The NetInstall really doesn't like it when i force nand to read only.. ;)
<ogra> indeed
<ogra> file a bug on flash-kernel so we can cancel the installation properly with a clean error message
<rcn-ee> i will, after some more testing..  its weird since early in the flash-kernel script it calls the one /etc/flash*.conf so it shoudl exit. (well it works on an already built image) but the NetInstall still runs it..
<ogra> while its sourced, the omap code doesnt use anything from it
<ogra> actually we only introduced it for imx51 since that has an awful setup
<rcn-ee> yeah i saw that, awful bootloader mess you had to work thru...
<ogra> after using it for three releases i really like redboot more than uboot
<ogra> :)
<hrw> ogra: can you tell more about that 'awful setup'?
<rcn-ee> the easy thing, would be a variable in that config to please leave the nand alone
<ogra> hrw, abusing your install media as "bootfloppy"
<hrw> ah
<ogra> truncating it at the end of the install ...
<ogra> the babbage board can only boot from SD
<ogra> but you cant easily install to the installation media you run from
<ogra> so babbage requires you to install to USB and to keep the SD you installed from as boot media, carrying a special non-data partition that holds redboot, kernel, initramfs and the redboot config (simulating a flash)
<hrw> ough
<persia> sveinse: Did you find what you needed in the logs?  They are (up to) an hour out of date, but they should go back to within a couple weeks of when I opened the channel.
<sveinse> persia: yes, thank you
<sveinse> Anyone here with openocd and kernel debug experience?
<hrw> I use openocd only to reboot sheevaplug
<NCommander> ogra: when you use a non-hacked up u-boot, your opinion will likely change
<ogra> NCommander, nope
<ogra> i like fast boots ...
<NCommander> ogra: ouch.
<ogra> uboot cant achieve that
<ogra> by design
<NCommander> ogra: u-boot can do raw reads just like redboot.
<NCommander> I just like having a filesystem for my files
<NCommander> But thats just me.
<hrw> ogra: what you use for that 'fast boot'?
<hrw> nand read?
<lool> NCommander: redboot supports filesystems as well
<NCommander> lool: upstream does, but no vendor fork of Redboot I've seen has it :-/
<lool> It's not really a problem with redboot though, but with the vendors   :-/
<NCommander> lool: indeed. If we had a modern redboot, I suspect my ability to complain about imx51 booting would be severaly reduced
<ogra> indeed i like its flexibility
<ogra> it still needs to convert from uImage to raw, no ?
<ogra> and copy it around in ram
<NCommander> ogra: u-boot can do XIP
<sveinse> Do you know if there a host graphical debugger (ddd or insight) which can debug arm code for target? (Probably it's a generic host for the GUI part and gdb-arm for the target)
<NCommander> sveinse: ddd should be able to use a cross-debugger, but its been awhile since I tried it
 * NCommander just got used to using gdb directly; less painful
 * sveinse is about to embark on some kernel driver development, and need eyes into the running kernel...
<ogra> hrw, redboot ... fast boot paid with zero flexibility
<sveinse> I'm going to use JTAG tool + OpenOCD, but I need a GUI frontend for gdb on host
<ogra> ******* reminder ubuntu mobile meeting in 5 min in #ubuntu-meeting *******
<slapin> hi, all!
<slapin> I try to rebuild gtk+2.0 on my SheevaPlug, and it uses -mfpu=vfp for it, is it ok? I could'nt find that Sheeva supports any floating point unit...
<lool> slapin: We require vfp nowdays
<lool> in Ubuntu that is
<slapin> where could I change that globally in my build environment?
<lool> slapin: You'd need to rebuild all of Ubuntu
<lool> slapin: This is encoded in the toolchain defaults
<slapin> lool: is there some automated way to build all ubuntu (at least base system plus some packages)?
<slapin> lool: I mean cross-compile
<lool> slapin: Cross-compile, not really
<lool> there are various tools available to rebuild Ubuntu as a whole, but they are not too clever, so you might have to do that multiple times
<slapin> lool: what device is used to build lots of packages reasonably fast for ARM architecture?
<slapin> lool: I think it is ok with me, I just want to know which tool is mainstream one
<slapin> lool: and what setup is needed.
<lool> slapin: We currently build continously
<lool> slapin: using real ARM hardware
<ogra> using launchpad/soyuz as builder system on top
<lool> We tried using both dove and imx51 boards, but I think our build system is mostly imx51 atm
<slapin> is it possible to build locally?
<lool> slapin: Yes
<lool> slapin: In theory you can setup launchpad, albeit that's heavy, or you can use the Debian tools such as wanna-build and dak, but these are a bit hard to setup as well; finally there are some ad hoc rebiuld tools like rebuildd
<slapin> lool: 'heavy' is fine with me, is there any docs on how to set up launchpad?
<persia> slapin: There's some (limited) docs as a side effect of https://dev.launchpad.net/Getting
<slapin> thanks a lot!
<plars> ogra: omap image didn't build last night, I assume because of RC (which it is not really included in at the moment).  Any way to force just that one to rebuild?
<ogra> plars, we need the livecd-rootfs fix anyway, so i prefer to wait
<plars> ogra: ok
<ogra> assuming you refer to netbook
<plars> ogra: yes
<sveinse> lool: Thanks! If you are interested, I can keep you posted on how we solve cross compilation into Ubuntu. Currently it seems that apps built in the cross compiler works directly on target, but I think that's a coincidence that both libc and libstc++ has the same version on the cross and on the native system.
<lool> sveinse: Correct; I don't expect too many incompatibilities there, because we try hard to have working binaries, but it's bad for other reasons (you actually want to know aganst what piece everything is built, and wihch features it uses -- toolchain flags and such)
<sveinse> lool: Where is the default compile flags (for the native compiler defined)? In the spec file?
<lool> The toolchain default to what you compiled it with
<sveinse> Ah right, so it adopts its CFLAGS automatically
<dmart> NCommander: does OOo build at the moment?  I've been trying to get a build tree for a few days, but I've hit problems
<ogra> dmart, it should
<lool> dmart: Yes I think so
<lool> dmart: Well it's *building* I think
<ogra> and it did as well before that minor change upload
<NCommander> dmart: in theory.
<ogra> after NCommander fixed it
<ogra> there was one finished build afaik
<NCommander> ogra: you mean blundened it
<lool> It's definitely building ATM
<ogra> yeah, there was a recent upload
<NCommander> dmart: we forced it to -marm. Not a real fix, but works for now
<dmart> http://pastebin.ubuntu.com/419326/
<dmart> I always get this, whether the -marm workaround is present or not.
<dmart> My filesystem should be up to date
<lool> ../unxlngr.pro/bin/makedepend: symbol lookup error: ../unxlngr.pro/bin/makedepend: undefined symbol: cppsetup
<lool> hmm
<ogra> dmart, how far into the build was that ?
<ogra> https://edge.launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0-7ubuntu3/+build/1698510 says its running since 19th
<dmart> Pretty early - no more than 1h in
<dmart> Incorrect build-deps (or my filesystem in a mess)
<dmart> ?
<dmart> This is a lucid chroot running on top of Jaunty in babbage1
<ogra> heh
<ogra> thats a pretty unpredictable env
<ogra> our buildfarm is completely bbg3 on lucid now
<persia> I've encountered a number of odd failures running pbuilder in jaunty to build lucid: I've had significantly better success with using qemu-user mode (although that's not a good basis for this specific issue)
<ogra> surely not for OO.o, no :)
<dmart> OK, maybe I ought to be careful about this
<persia> I've been presuming it's due to missing thumb2 support int he jaunty kernel, although I have no basis for this presumption.
<dmart> I have loads of babbage1 doing not much :/
<persia> dmart: Can you get a 2.6.32 kernel running on them?
<dmart> persia: the jaunty kernel should support Thumb-2, but there might be some unfixed issues
<persia> if so, you have the basis of a lovely build farm :)
<ogra> persia, bbg1 was pre-production HW
<dmart> I can maybe run the build on babbage3 and use the babbage1s as distcc slaves
<ogra> there can be plenty of silicon issues
<dmart> a pretty dumb board can run distccd
<ogra> yeah, for distcc that might work
<ogra> or icecc
<dmart> icecc?
<ogra> next gen distcc :)
 * dmart googles
<dmart> oh, right :)
<ogra> NCommander had a setup for his OO.o tests
<dmart> For massive C++ compiles distcc can provide quite a boost
<NCommander> ogra: dmart: icecc doesn't help much, since then it tries to parallize the things that icecc doesn't do, and the then it goes bad
<ogra> ??
<ogra> which of the icecc should be distcc now ?
<NCommander> ogra: basically, theres no way to tell OOo you only want to parallize the building only the C/C++ builds
<NCommander> so it works great for C/C++ modules
<NCommander> it gets really bad when it gets to running javac
 * ogra still doesnt get what things icecc does that icecc doesnt do 
<ogra> that sentence made no sense
<NCommander> ogra: oh, I fail
<NCommander> ogra: basically, the OOo build system is stupid, and can't properly parallize the build so only the C bits are build in parallel
<suihkulokki> ofcourse, distcc/icecc don't parallilze javac. just c/c++
<ogra> right
<ogra> i got *that* part
<ogra> the initial sentence was just very confusing
<prpplague> ogra: ping
<XorA|gone> hey guys is UDS still going ahead as planned considering the chances of airflight being allowed by then seem to be minimal?
<lool> XorA|gone: minimal?  according to whom?
<XorA|gone> lool: the volcano doesnt seem to be emitting any less ash
<lool> Actually it does
<XorA|gone> lool: not according to news this afternoon when scotland closed again
<lool> I heard at lunch that ashes emissions went significantly down
<prpplague> XorA|gone: hey bud
<persia> XorA|gone: So, isn't that why the chunnel was dug?
<prpplague> XorA|gone: ugh, saw the new dr.who last saturday :(
<prpplague> XorA|gone: very disappointed
<XorA|gone> persia: yeah thats easy enough for me, I just dont want to be the only guy there :-)
<persia> Those of us from far away can fly to somewhere within train distance one way or another
<XorA|gone> persia: just checking people are still planning to attend and not move to somewhere more reliable like spain
<XorA|gone> as Ill need to book tickets ASAP
<lool> it's definitely still planned  :-)
<persia> We did spain too recently to repeat
<XorA|gone> BBC news if quite defineate on increasing volcano ash again today
<persia> (and actually, twice: once andalucia and once catalunya)
 * XorA|gone thinks we need an Edinburgh to Holland tunnel
<sveinse> The airspace here in Norway has been reopened today. And according to the news, the volcano has gone over to a lava-production phase where the ash production is significantly reduced
<Martyn> sveinse: Thank goodness
<Martyn> sveinse: But unfortunately the second volcano is starting to swell .. so we're likely going to see a second blast
<NCommander> eggonlea: you around?
<hrw|gone> XorA|gone: going for UDS?
<hrw|gone> XorA|gone: would be great to see at least one known face ;D
<ogra_cmpc> hrw|gone, we're not *that* ugly, don't be scared :)
<ogra_cmpc> prpplague, hey
<ogra_cmpc> (just here for a few mins)
<hrw|gone> ogra_cmpc: I did not said that.
<ogra_cmpc> though all the hugging might scare you probably *g*
<hrw|gone> ogra_cmpc: but when I will arrive at ~21:00 on sunday it would be easier to just call xora and go for a beer then catch someone on irc and then wonder which of guys in lobby was that one
 * ogra_cmpc doesnt actually knoe when he arrives (driving by car) but i'm surely up for a beer then :)
<hrw|gone> ogra_cmpc: during uds I will meet some familiar faces but connecting faces to irc nicks etc takes time
<ogra_cmpc> indeed
 * ogra_cmpc knows what you mean
<ogra_cmpc> and XorA|gone is easy to memorize :)
<hrw|gone> guadec 2007 was great for me - I finally met OpenedHand people after working with them for nearly half year
<ogra_cmpc> you will meet some again at UDS
<hrw|gone> ogra_cmpc: I first met him in 2006 iirc
 * ogra_cmpc met him about a month ago in nice
<hrw|gone> ogra_cmpc: so far I do not see ex-OH people on list
<hrw|gone> but there is still time - I am not on a list yet too
<hrw|gone> waiting for some mails first
<ogra_cmpc> not sure they did their paperwork yet ...
<hrw|gone> bts got my papers yesterday
<ogra_cmpc> but i'm sure neil is coming
<prpplague> ogra_cmpc: hey bud
<NCommander> asac: so libgphoto2 successed in public devirtualized PPA
<NCommander> asac: care to sponsor?
<crimsun> I can if you pass me the dsc url
<NCommander> asac: crimsun: https://bugs.edge.launchpad.net/ubuntu/+source/libgphoto2/+bug/567422
<ubot4> Launchpad bug 567422 in libgphoto2 (Ubuntu) "ARM FTBFS fix for libgphoto2 on lucid (affects: 1)" [Undecided,New]
<asac> NCommander: could you check with -release ... i guess this wont be before RC?
<NCommander> asac: already did check with release yesterday on fixing this problem this way
<NCommander> asac: not sure on uploading it now though
<NCommander> asac: we're in pre-release freeze now though, so you can upload now, and if its problematic, it will just sit in the queue until after RC
<asac> NCommander: ok. let me test build at least ;)
<Sayag_Samuel> hello
<Sayag_Samuel> I'm trying to set an USB camera on the beagle board and I have some problems
#ubuntu-arm 2010-04-21
<hrw> morning
<saeed> persia: ping
<persia> saeed: ?
<saeed> persia hey
<saeed> does hibernate work for you on dove?
<persia> I don't have a dove board, so both "yes" and "no" seem like the wrong answer to that :)
<saeed> anyway, I noticed that sound settings are not restored after hibernate
<JamieBennett> persia: saeed: going by what was said in the meeting yesterday, no would be the right answer
<persia> saeed: Which sound settings?
<saeed> volume, mute, etc
<saeed> I mean hw settings
<persia> Ah, hrm.
<persia> ericm_: Any ideas?
<saeed> which part of the system should restore those settings after hibernate resume?
<hrw> saeed: add "/etc/init.d/alsa start" to after-resume scripts?
<saeed> hrw: where are those scripts located?
<persia> /etc/pm/sleep.d/ but I don't see any on my lucid installs, making me thing there is another solution somewhere
<hrw> saeed: no idea - I do not have any machine running ubuntu
<lool> hrw: Let us limit discussions to Ubuntu approaches here though  ;-)
<hrw> monday will be funny day - working on ubuntu/arm without having usable machine for it
<lool> hrw: Eh, you don't have any laptop/desktop running Ubuntu?
<hrw> lool: Debian on desktop, Debian on laptop
<XorA> if does is an ASoC board then ASoC layer should restore sound exactly as is
<XorA> dove
<lool> hrw: I personally dual boot Debian on my laptop
<lool> With a shared /home
<hrw> lool: with 80GB hdd I have dual boot Debian/winxppro
<hrw> considering buying asus ul30 as new platform so kubuntu will land there rather
<persia> XorA: so `/sbin/alsa --force-reload` shouldn't be required?
<saeed> XorA: the dove has two sound cards (AC97 and i2s), both of them are asoc
<kaouthia> lool: Do you use Ext2fsd?
<XorA> persia: no, the machine/codec driver should restore
 * XorA doesnt have a dove or even know what it is
<lool> kaouthia: No
<persia> That explains the lack of /etc/pm/sleep.d/50alsa in lucid.
<XorA> but I did used to maintain ASoC
<lool> never heard of it
<kaouthia> How do you access your /home from your windows partition?
<lool> kaouthia: I dont use windows
<XorA> hrw: I do my ubuntu work on fedora here :-D
<lool> it's a dual boot of debian and ubuntu
<kaouthia> lool: Ah okay
 * lool needs to disappear for an hour
<hrw> lool: both reside on same crypted lvm?
<persia> XorA: How does that work?  I didn't know most of our development scripts were available for Fedora (or do you work in a chroot/VM)?
<persia> hrw: No reason they couldn't, given appropriate bootargs
<XorA> persia: VM combined with native on zoom2 board
<persia> XorA: ah, yeah, VM is plenty sufficient.
<persia> Is the Zoom2 fast enough to use for development directly?  I was under the impression it was a bit RAM-low.
<saeed> XorA: can you explain how should machine/codec restore settings after hibernate?
<XorA> persia: I recompiled xf86-video-omapfb with no real issues, havent tried kernel yet
<XorA> saeed: look at the drivers in sound/soc/*
<persia> No need: that you are using it for that indicates it's sufficient :)
<saeed> XorA: what I'm missing, is how can the driver get those parametes from?
<XorA> saeed: because the driver wrote them to the codec
<XorA> saeed: it remembers themk
<saeed> XorA: but after hibernate, the driver will be loaded as from reboot
<XorA> saeed: Im not very familiar with ubuntu on arm, I work on a different distro where we dont power down the chips
<saeed> XorA: but hibernate usually powers down the system, right?
<persia> Indeed.  That's the usual difference between "suspend" and "hibernate".
<saeed> XorA; please note the resuming from standby (suspend to ram) works fine to me
 * XorA has never hibernated an arm in that case
<saeed> XorA: I think it's the same on x86
<hrw> hibernate as susped-to-disk-and-power-off?
<saeed> yes
<hrw> never did that on arm either
<saeed> actually mainline kernel doesn't support that, we have added that functionality
<persia> On boot, we seem to use /sbin/alsa-utils to restore state with alsactl.
<XorA> hrw: ever feel we have walked into a strange new world :-)
<persia> Might need support for that around hibernate in pm-utils
<persia> saeed: Do you know if it works on x86? with Ubuntu?  You might be hitting a general bug.
<persia> (or powerpc)
<saeed> persia: no
<hrw> XorA: life without new challenges starts to be boring
<persia> https://help.ubuntu.com/community/SoundTroubleshooting definitely has notes on working around hibernation issues.
<hrw> XorA: I returned from fosdem with devboard which I did not even connected serial yet
<XorA> hrw: hehe
<hrw> XorA: thinking about giving it for a friend as a gift
 * XorA is just trying to fix the zoom2 kernel so serial is not needed
<hrw> nice improvement over arm7tdmi which are high tech at his company ;D
<ogra> XorA, have you seen bug 567260 ?
<ubot4> Launchpad bug 567260 in xf86-video-omapfb (Ubuntu) "xserver-xorg-video-omap* fail due to no /dev/fb (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/567260
<XorA> ogra: thats what I fixed
<ogra> we have another two days for a fix
<persia> saeed: Do you also lose settings on reboot?
<XorA> ogra: I can post patch to bug
<ogra> so it if it goes into archive tomorrow or friday we can have it in final
<saeed> persia: no
<XorA> its a one liner
<ogra> XorA, cool, please do so
 * persia looks for another bug
<XorA> gimme a few mins to replace kernel on zoom2 to extract bug
<hrw> oneliners are usually the most amazing changes
<hrw> I remember curses of one developer after his 4 hours of attempts to solve build error which I solved with oneliner for makefile
<ogra> persia, you want a bug ? i have plenty
<persia> ogra: Do you have one about sound and hibernate?
 * persia is looking for a *specific* bug
<XorA> ogra: that bug is already detailing my one liner
<persia> saeed: Try adding /etc/pm/sleep.d/50alsa as indicated at https://help.ubuntu.com/community/SoundTroubleshooting#Getting%20ALSA%20to%20work%20after%20suspend%20/%20hibernate and see if that works.  If not, it might give some hints on a path to resolve it.
<ogra> persia, nope, but since i joined the installer team yesterday i can provide you with 100's of installer bugs if you are desperately in need for a bug :P
<suihkulokki> hrw: one particularry fun online fix that took one day to locate..
<suihkulokki> -char foo;
<suihkulokki> +signed char foo;
<persia> ogra: I have code that generates lists of unfiled bugs on a regular basis already, if I'm just hunting bugs :)
<ogra> haha
<saeed> persia: I'll try
<XorA> OTG working on boot awesome
<persia> saeed: If that doesn't work, please file a bug (`ubuntu-bug audio`)
<ogra> XorA, which kernel ?
<XorA> ogra: it works on all linux-omap kernels
<XorA> ogra: specifically on my zoom2
<ogra> XorA, not ubuntu then
<XorA> ogra: you guys could add it
<ogra> XorA, out kernel team uses mainline only on omap
<ogra> tahst why the omap kernel is actually .33 and not .32 like the rest of ubuntu
<persia> (except fsl-imx51)
<ogra> yeah
<XorA> ogra: your not allowed to patch at all?
<hrw> ogra: so torvalds tree instead of linux-omap tree?
<persia> Oh, and -rt
<ogra> persia, which is why i said omap :)
<ogra> hrw, right
<ogra> XorA, we are
<persia> ogra: "rest of ubuntu" was my picky point
<ogra> amitk, backports/cross ports bits and pieces
<hrw> XorA: Debian policy was: mainline kernel + backports from mainline. probably same/similar for ubuntu
<saeed> persia: it didn't work, I'll fill a bug
<hrw> XorA: pain for omap
<persia> saeed: Thanks.
<ogra> hrw, well, whatever is maintainable, if amitk decides a certain patch from -omap is valuable that will also be pulled in
<ogra> its up to our kernel maintainer ...
<ogra> i'm only a consumer and tester ;)
<XorA> ogra: http://git.openembedded.net/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/0042-musb-allow-host-io-without-gadget-module.patch
<NCommander> eggonlea: you aorund?
<amitk> XorA: the idea is to further the mainlining of omap by using mainline kernels. I've talked to Tony about this and he agrees. linux-omap is more like a buffer to mainline.
<XorA> amitk: I know this, linux-omap diffs have rapidly decreased over mainline
<eggonlea> NCommander: yes.
<amitk> and yes, i need to find time and pick out the right patches from 34-rc or linux-omap to unbreak OTG
<XorA> amitk: see patch above :-)
<amitk> XorA: thanks, I shall
<XorA> amitk: Im unsure of the pushed to mainline status, but Ajay is the TI USB guy
<hrw> amitk: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/ is worht checking anyway
 * XorA really hopes ubuntu speeds the mainlining of zoom2/3 patches
<ogra> zoom and beagle hopefully
<hrw> ogra: beagleboard needs first really stable working version
 * amitk disappears for lunch
 * ogra lols about XorA's patch for omapfb
<ogra> XorA, i tought you had added any kind of autodetection
<ogra> i know asac tries to add that before final
<XorA> ogra: I may code that up one day, but for now I just need lucid running
<lool> hrw: ecryptfs actually
<shashi> ogra: do you know why omapfb instead of fbdev is used as reported in 567260?
<hrw> lool: it crypts files but not filesystem - right?
<lool> hrw: It's a filesystem on filesystem
<lool> so it crytps filesystem objects in filesystem objects
<lool> e.g. a dir to a dir and a file to a file
<hrw> ok, I prefer crypted lvm - handle also swap so I do /boot + crypto-lvm(/ + swap)
<ogra> shashi, its not used by default atm, only if you install the omapfb package
<shashi> ogra: ok thanks....i was inputing some comments/ thoughts in 567260
<ogra> shashi, thanks :)
<hrw> ok, tickets for uds bought/booked
<ogra> clap clap clap
<ogra> looking forward to meet you there :)
<hrw> same
<rcn-ee> hrw, i was looking at the musb host/device patch, haven't tested it yet, but how's it working for you?
<hrw> rcn-ee: I did not updated my beagle to this kernel yet
<ericm_> saeed, could you update your resume from suspend status to bug 551491?
<ubot4> Launchpad bug 551491 in linux-mvl-dove (Ubuntu) "BSP update for Marvell Dove kernel LSP 5.1.0 (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/551491
<ogra_beagle> WOHOO+
 * ogra_beagle wipes this install and starts over with the latest image hoping all is fine now
<hrw> (II) XINPUT: Adding extended input device "bmi-lcd-ts" (type: TOUCHSCREEN)
<hrw> ;D
<ogra> congrats
<hrw> other omap3 board
<amitk> hrw: what board is this?
<hrw> bug 2.0
<hrw> prototype
<amitk> standard image?
<amitk> or custom kernel?
<hrw> no ubuntu
<hrw> amitk: I am returning device on days so no ubuntu tests for it
<amitk> ogra: you said something about the new image allowing me to install to sd itself?
<ogra> amitk, the netinst one, yes
<amitk> how do i put a custom kernel on those?
<ogra> amitk, pos-install
<ogra> *post
<ogra> you cant do it in the image
<amitk> right
<ogra> d-i is closely built with the kernel
<saeed> ericm_: done
<zumbi> amitk: http://wiki.debian.org/DebianInstaller/Modify/CustomKernel
<amitk> zumbi: ?
<ogra> zumbi, heh, thats ancient
<zumbi> amitk: are not you asking how to use d-i with custom kernel?
<ogra> from a time where d-i was still on two floppies
<amitk> zumbi: ohh right. :) thanks, i'll take a look
<ogra> amitk, d-i changed completely ... thats even pre-ubuntu
<zumbi> amitk: ogra is right, looks old
<ogra> its for 2.4 kernels :)
<zumbi> ogra: do you know a more up to date doc?
<ogra> no
<amitk> hehe lol
<ogra> and its a hell lot of work even if i knew a doc
<zumbi> amitk: i would like to have efikamx (iMX51) in mainline kernel
<hrw> 2.4...
<zumbi> ogra: using kernel-wedge?
<amitk> zumbi: want to submit patches? pointers to git tree? pointer to someone that has hardware?
<ogra> installing the existing image and just issuing dpkg -i linux-image .... *.deb is definately easier and a lot faster
<zumbi> amitk: i have hardware, the bad thing is they use freescale SDK
<amitk> zumbi: that is fine if you don't mind wiping it over ;)
<zumbi> ogra: right, for efikamx, i wanted to add it to flash-kernel which hooks kernel-package
<zumbi> ogra: then use somethin similar to rootstock
<ogra> flash-kernel hooks kernel-package ??
<ogra> flash-kernel is really only to set up the bootlaoder
<ogra> you shouldnt abuse it for other stuff, rather create a new tool that flash-kernel can call
<zumbi> flash-kernel (debian version) calls mkimage on vmlinux and initrd
<ogra> yes
<zumbi> I thought that was the best way to do for porting a new device
<ogra> but it doesnt do anything with kernel-package
<zumbi> kernel-package provides me with a vmlinux and initrd, then flash-kernel could get me the right thing I need (uBoot format)
<ogra> and i dont think we even support kernel-package in ubuntu
<ogra> i might be wrong though, amitk might know better
<zumbi> kernel-package is a great tool
<ogra> but i guess it doesnt properly hook into the ubuntu infrastructure
<amitk> -ENOkernel-package
<zumbi> uhm.. that's sad
<zumbi> you don't even need a debian_dir, it creates it for you
<ogra> yes, thats the scary part
<amitk> zumbi: it might work for mainline kernels, but not for 'managed/supported' kernels.
<amitk> but it is something the kernel team plans to look at in our sprint next week
<zumbi> amitk: it works for efikamx, kirkwood sheevaplug, and some others
<amitk> (whether we should support it or not)
<ogra> zumbi, FSVO works
<zumbi> what is FSVO?
<amitk> zumbi: sure, but we don't support that HW, so why would we care? (to be blunt)
<ogra> zumbi, as rootstock "works" to create an image
<ogra> you will never get the same as you have with a real install with rootstock ...
<ogra> and you will never get a proper ubuntu kernel package with kernel-package
<ogra> so its "some system that looks like ubuntu" in the end
<amitk> zumbi: though I would love for our kernel to support multiple boards with a single kernel tree.
<ogra> zumbi, FSVO -> for some value of
<zumbi> well, I would like to find a way to have an embedded-installer which suits ubuntu and debian
<zumbi> which handles all this bootloader, kernel details
<zumbi> but it seems hard to find a consensus
<ogra> you cant do it with the concept of a distro
<ogra> you can only get close to it
<ogra> i.e. like rootstock
<ogra> but effectively you will always have a bunch of differences to the real thing
<zumbi> yes, it is hard to be generic.. :-/
<persia> zumbi: At least in Ubuntu, we explicitly say we aren't building "embedded", so want d-i to just do the right thing.  This approach happens to be viable for a huge volume of hardware that others may consider "embedded".
<persia> zumbi: Rather than building a new embedded installer, what might be helpful is improving the image modification tools in a way that one can easily swap the installed kernel.
<persia> And improving the kernel packaging scripts to make it easy to convert an arbitrary git tree into a packaging tree.
<saeed> NCommander: ping
<asac> ogra: what is different compared to ubuntu if you go for a properly seeded rootstock fs and combine that with the kernel/bootloader packages?
<persia> asac: All the base config stuff.
<asac> persia: baseconfig like oem-config?
<ogra> asac, debconf
<ogra> rootstock surely doesnt seed all of debconf properly yet
<asac> ogra: what pieces are missing there?
<persia> asac: So, the base-config package went away, and the installer handles that.  I ended up spending many months fixing a million little issues with moblin-image-creator and we determined it was easier to make ubiquity work for MID than to continue tracking down all the special cases.
<asac> ogra: so its a matter of tweaking seeds?
<ogra> asac, no idea, i never made an effort to check that
<persia> asac: No, base-config like the *REALLY OLD* debian package.
<ogra> its a matter of integrating rootstock better with debconf
<asac> persia: right. but thats now oem-config?
<ogra> and using d-i modules instead of scripts
<persia> asac: Not at all.  There is no relation between those packages.  oem-config does *some* of the configuration post-install.
<asac> ogra: how do we know that d-i and ubiquity do all the same?
<ogra> thats the reason why i switched to oem-config by default
<zumbi> persia: i agree on improving the kernel packaging scripts, but which ones? (debian, ubuntu, kernel-package, kernel-wedge,.. just reate yet another one)
<persia> But oem-config expects a d-i base install.
<ogra> it does a good bunch of that using d-i modules
<asac> for me it feels like there is deviation anyway, though you would call both systems "ubuntu"
<ogra> persia, it brings it
<ogra> and removes it after it ran
<persia> zumbi: Ummm.  I'm going to have to defer to the #ubuntu-kernel folks at this point :)
<ogra> asac, right, but target has to be to minimize the deviation
<persia> ogra: No, it runs *some* d-i components.  Some stuff never gets run in oem-config.
<ogra> asac, which the step to oem-config did for example
<asac> ogra: right. just wanted to point out that quite a lot of details are probably not relevant for "ubuntu"
<asac> ogra: yeah. for me a rootfs + oem-config is ubuntu ;)
<ogra> yeah, might be
<asac> thats how we ship stuff to production somewhere too, isnt it?
<ogra> nobody researched yet if/what additional pieces are missing in a rootstock install
<persia> asac: In terms of use of the "ubuntu" term, no, but we expect there to be a large number of small bugs with a rootstock-based install (just as there are many known bugs with vm-builder installs, or any other tools that aren't d-i)
<ogra> asac, not sure, thats something only OSG can answer
<persia> asac: Nothing called "Ubuntu" ships without a d-i installer to my knowledge.
<ogra> right
<persia> I know of specialised remixes that use other installers (the one for the Netwalker is an example).
<ogra> and the proper approach for rootstock might also be to run d-i with a preseed file for the second stage
<hrw> guys: if I boot x86-64 from 10.04b2 cd can I make bootable pendrive?
<ogra> instead of the script it uses atm
<persia> Doing that makes it just a normal install.
<persia> hrw: Sure.
<asac> persia: i would like to see those bugs ;)
<asac> at least one example
<ogra> asac, as i said, nobody actually researched the differences
<persia> hrw: You might have to play some games to tell usb-creator to make the pendrive based on the cd in your drive though.
<persia> asac: I'll dig up a URL.
<ogra> asac, you would have to diff the debconf DB between a real install and a rootstock one
<ogra> i'm very sure there *are* differences ... just dont knwo which
<persia> asac: http://www.sharp.co.jp/support/ex-data/recovery.sh.tar.gz
<persia> asac: http://www.sharp.co.jp/support/mit/doc/install.html has instructions with screenshots (in case you don't read Japanese)
<asac> i wouldnt be able to follow that instruction ;)
<hrw> asac: http://translate.google.com/translate?u=http%3A//www.sharp.co.jp/support/mit/doc/install.html&hl=pl&langpair=auto|en&tbb=1&ie=Shift_JIS
 * hrw hails JS menu in bookmarks toolbar
<persia> heh, cool.  Japanese->English translation with polish controls
<persia> P
<hrw> bookmarklets saves lot of time
<hrw> persia: s/hl=pl/hl=en/?
<persia> hrw: If I didn7t already know what the buttons did, yeah :)
<hrw> persia: before google translate I used "Excite Japan" translator
<hrw> it was like 'put url', select 'shelf->something', press button
<persia> Oh, if you skip the hl= bit entirely, it chooses your default once.
<persia> hrw: Excite Japan does a slightly better job with the text, but is less good for web pages.
<hrw> time passed, less to do with japanese websites, so google is enough for me
<hrw> ~curse sharp
<plars> GrueMaster: hmm, I may have spoken too soon on the dove suspend/resume.  The first few times it worked for me but seem to be hitting a problem now
<persia> The Netwalker is actually a nice bit of kit.
<persia> And they seem to be supporting it some.
<persia> No idea if it sells well enough to keep that (likely needs more overseas orders to justify worldwide release)
<hrw> netwalker is ugly...
<persia> Yeah, it's a bit large, and it doesn't convert, and the A key is in the wrong place, but other than that, it works.
<hrw> and it is imx...
<persia> Well, I guess.  I'm more interested in something I can actually put in my pocket and use than which is the best technology inside.
<hrw> I have big aversion to xMB kernel patches
<persia> As long as all the other SoCs aren't available as 4-5" handhelds, how cool they are isn't so important.
<persia> I just use the stock kernel, and keep hoping someone will package a newer kernel.
<hrw> persia: I have n900 for playing
<persia> hrw: You don't even want to get me started about the shortcomings of that device :)
<persia> Nice internals though.
<hrw> persia: I just hope that netwalker team does not have anyone from zaurus teams
<persia> I've no idea.
<hrw> 2.4.18-crappix (OE/OZ internal name for 2.4.18-embeddix) was total disaster from sharp
<persia> Dunno.  It ships a kernel that works with Ubuntu, which is all I require in a kernel.
<hrw> 2.4.18 + arm + pxa + others + bunch of others + wext updates + irda updates + bunch of fixes + bunch another ones
<hrw> and only first 4 parts were from sharp
<persia> For this one, amitk said he managed to upstream most of the patches.
<hrw> cool
 * amitk looks up
<zumbi> amitk: where is imx51 mainline branch?
<amitk> zumbi: in linus's tree? :)
<amitk> *linus'
<zumbi> amitk: we have efikamx stuff http://gitorious.org/efikamx/linux-efikamx
<zumbi> amitk: i do not see any mach-mx5 in linus' tree
<amitk> 2.6.34-rc?
<zumbi> 2.6.33 was looking via lxr
<amitk> it went in in 2.6.34
<zumbi> oh! ok, sorry
<ogra> amitk, argh !
<ogra> amitk, read error on /dev/mtd2: cannot allocate memory
<ogra> thast where ubiquity dies now :/
<persia> That's flash-kernel-installer
<amitk> ogra: i thought you got mtd write working...
<ogra> amitk, it works with d-i
<ogra> amitk, worst is that i dont actually read at all
<amitk> ogra: is dd able to read/write?
<ogra> amitk, seems its fw_setenv thats failing to write
<ogra> yes, its dd able
<ogra> but mtd2 holds the uboot config
<lool> ogra: Are you passing fw_setenv a mtd or a mtdblock device?
<ogra> i only dd to ntd3 and 4
<ogra> echo "/dev/mtd2 0x0000 0x20000 0x20000" > /target/etc/fw_env.config
<ogra> lool, ^^^^
<lool> sounds good
<lool> ISTR the u-boot tools are using mtd calls for io
<lool> which would fail on mtdblock
<ogra> i wonder if i need to wipe it like the other ntd devices before writing
<ogra> i dont zero it out at install time
<ogra> which i do with mtd3 and 4
<persia> ogra: Have you looked for smarter tools in mtd-utils than dd?
<persia> dd isn't precisely eraseblock aware.
<hrw> flash_eraseall + nandwrite -p?
<hrw> first cleans mtd, second writes with padding
<lool> ogra: Oh you're dd-ing to mtdN?
<lool> ogra: To write kernels and initrd, you'd better write them directly to mtdblockN
<persia> hrw: Yes, that was what I was thinking, assuming it's NAND.
<ogra> lool, i'm just doing what all other arches in flash-kernel do
<hrw> persia: I do not remember when last time I used NOR
<hrw> mostly NAND or OneNAND recently
<persia> hrw: My netwalker has redboot on NOR, but I don't have any interest in changing it, since the behaviour is sufficient for me.
<ogra> lool, flash-kernel was minaly a copy/paste job with some adjustments
<ogra> *mainly
<ogra> i can reliably reproduce fw_setenv breakage though
<ogra> andi suspect it is because uboot-envtools was never recompiled
<persia> ogra: copy&paste of dd against NAND isn't best, even if it's the same as something else.
<ogra> persia, it is the same code for *all* platforms in flash-kernel
<ogra> persia, rewrite flash-kernel if you feel it behaves wrong :)
<persia> Then I say it's all dangerous at best, and likely bad.
<persia> Maybe, after I deal with other things.
<ogra> i'm just using the existing functions in there
<ogra> and flash-kernel isnt my problem
<persia> But dd against NAND significantly reduces NAND life.
<ogra> my problem is flash-kernel-installer
<ogra> http://paste.ubuntu.com/419902/
<ogra> anyone having an idea ^^^^ ?
<ogra> amm
<ogra> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512589
<ubot4> Debian bug 512589 in uboot-envtools "fw_setenv: Cannot malloc -131072 bytes: Cannot allocate memory" [Normal,Fixed]
 * ogra is desparate
<ogra> lool, any idea ?
 * ogra doesnt get why it works in d-i 
<ogra> i have done about twenty netinst installs now and never hit it
<ogra> and three -server
<ogra> (alternate)
<ogra> persia, btw, looking at the code, flash-kernel translates /dev/mtd to /dev/mtdblock at some point
<ogra> so the writing goes to mtdblock
<ndec> hi. i'd like to be mount the daily .img file on my desktop, instead of using dd to write to SD card, e.g. I want to update the kernel in the .img file. i tried mount -t vfat -o loop xxx and it does not work.  how can i do that?
 * persia is slightly mollified
<persia> ndec: You need to use losetup and kpartx: there are multiple partitions on the image
 * persia digs up a reference
<ogra> there arent
<ogra> there is just one
<ndec> ogra: that's what I thought...
 * persia is confused
<ogra> but hwat persia said is still true ... either mount with offset or use kpartx
<persia> ndec: http://blog.dustinkirkland.com/2008/10/mounting-kvm-disk-image.html
<ndec> ogra: what is the offset? what is the right command?
<ogra> you need to use an offset that omits the MBR
<persia> ogra: Ah, so there's only one partition, but it is a partition.  That makes sense.
<ogra> i think something like -o offset,512 or some such
<ogra> or offset=512
<lool> ndec: use kpartx
<persia> Oooh, `kpartx -av foo.img` is supposed to just work.  That saves effort.
<ndec> ogra: thx. sudo mount -t vfat -o loop,offset=512 is working!
<lool> Yes
<persia> (remember to use `kpartx -dv foo.img` later)
<ogra> mount -o loop,offset=512 imagefile.img /mountpoint shoudl work
<lool> You have to losetup it first
<amitk> ogra, why don't I see omap images here? http://cdimage.ubuntu.com/netboot/lucid/
<persia> lool: Not according to the comments on kirkland's blog
<ogra> amitk, because they are ports and not officially supported in lucid
<lool> persia: actually it works, but you can't tell what name it will have
<ndec> amitk: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/
<lool> persia: so it's inconvenient in scripts
<persia> amitk: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/
<ogra> persia, is right as usual :)
<persia> ogra: That's not a good reason.  The issue is that someone in cdimage (hint) needs to add the links to the template script.
<persia> ogra: I'll dig you up a patch tomorrow if you're stuck (we can't land it until post-RC anyway)
<amitk> ndec: looking for netboot images, not netbook ;)
<ogra> persia, well, if i'm allowed to, i'm not sure what the status on supportability is here
<lool> amitk: these are in the archive directly
<persia> ogra: omap is *already* on cdimage.
<lool> amitk: we dont copy them to cdimage anymore
<persia> ogra: The issue is that they aren't likely to get to release
<amitk> right, just found out lool
<lool> amitk: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/
<ogra> persia, i'm currently more worried about the fs_setenv bug that i cant solve
<lool> oh right
<ogra> i have no idea whats wrong
<persia> ogra: Go fix that.  I'll give you a patch once the cdimage freeze lifts.
<ogra> and that it works flawless in d-i doesnt help
<ogra> persia, i'd love to, but i have no idea whats going on there
<persia> amitk: Could you file a bug against ubuntu-cdimage about the missing netboot links?
<ndec> ogra: if I want to change the bootargs in boot.scr, do I just edit the file with emacs or do I need to regenerate something?
<asac> ndec: usually i remove the stuff from top, and then run mkimage ... again
<asac> after editing
<asac> that works quite well
<plars> GrueMaster, saeed: are either of you able to reproduce the suspend/resume problems I just updated the bug with on dove?
<GrueMaster> plars: bug #?
<asac_> hey. had reconnect
<plars> GrueMaster: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/551491
<ubot4> Launchpad bug 551491 in linux-mvl-dove (Ubuntu) "BSP update for Marvell Dove kernel LSP 5.1.0 (affects: 1) (heat: 8)" [High,In progress]
<asac_> if something was written i didnt get it
 * ogra had a OOM on his laptop
<ogra> sigh
<ogra> lucid sucks
<asac_> ogra: hmm. i didnt hear that ;)
<ogra> https://bugs.edge.launchpad.net/bugs/565981
<ubot4> Launchpad bug 565981 in xorg-server (Ubuntu Lucid) (and 1 other project) "[KMS] gem objects not deallocated (affects: 15) (dups: 2) (heat: 96)" [Critical,Confirmed]
<ogra> pitti just mailed -devel about it
<GrueMaster> plars: What do you mean by "enable audio"
<asac_> ouch
<ogra> yeah
<ogra> i have to reboot once a day and see a lot of sad faces in chromium every day
<asac_> ogra: chromium != lucid ;)
<ogra> asac_, so with the fw_setenv bug i doubt we can have netbook for lucid
<asac_> (intentionally)
<ogra> asac_, chromium is just fallout
<ogra> in the end my whole desktop dies
<plars> GrueMaster: unmuting the hp jack
<plars> GrueMaster: so that audio works
<GrueMaster> Ok, might want to clarify that in the bug report.
<plars> GrueMaster: not sure that it's related, but I think it's about the only thing I did between the time it worked, and stopped working
<GrueMaster> Otherwise it sounds like audio is disabled by default (it isn't).
<plars> GrueMaster: not truly disabled, no, you just can't hear anything til you do that
<GrueMaster> Yes, you can if you have the right hookup.
<ogra> asac, another reconnect ?
<GrueMaster> I have a 2 RCA-to-mini female cable for just this purpose.
<GrueMaster> Just because the platform is designed with different audio jacks than normal desktops doesn't mean audio is disabled or not working by default.
<GrueMaster> Babbage has a special connector for laptop speakers and defaults to that (I'm still looking into the HP jack single channel issue on it though).
<hrw> have a nice rest of day
 * ogra has a screwed rest of day now :( after realizing the netbook image wont work 
<asac> ogra: no i was connected through a second irc client until i was able to get my new ip ;)
<ogra> ah
<plars> GrueMaster: oh, ogra resolved that this morning
<GrueMaster> resolved what?
<plars> GrueMaster: use the hdphone jack instead, make sure it's set to audio output stereo
<plars> GrueMaster: on imx51, the single channel problem
<GrueMaster> ok, I'll try it here.
<ogra> GrueMaster, HDSET -> mono phone headset, HDPHONE -> headphones (my guess)
<ogra> you could probably take a look in the docs though to confirm that
<plars> GrueMaster: seems that there's no good way to get input though
<GrueMaster> plars: Why not plug a headset into the imx51 and try it that way?  I have one here I can try.
<GrueMaster> oops, different plug.
<plars> GrueMaster: hmm? I'm not following.  I did try it and it worked for me
<GrueMaster> I was referring to the input.
<plars> GrueMaster: I tried it briefly without success, but admittedly have not had much time to spend on it yet
<GrueMaster> If that is a headset jack, then it should be able to work with a standard phone headset (proficed the plug is the same size).
<plars> GrueMaster: ah, no I was just trying with a normal mic
<GrueMaster> normal mic might be wired wrong for this.
<plars> ogra: based on your previous comments, I assume the FlashKernel errors from Ubiquity on omap are still to be expected?
<GrueMaster> plars: I can get recording working on my babbage using the mic from my babbage 1 plugged into the internal connector.
 * Martyn has audio working on the tegra2 .. but using a USB adapter
<Martyn> I'll need to keep hacking away at the linux driver for the SoC based hardware
<GrueMaster> Martyn: USB audio is a completely different driver set.
<GrueMaster> Still alsa, but not soc audio.
<Martyn> GrueMaster: Yep!
<Martyn> GrueMaster: But I needed it to work temporarily :)
<Martyn> so it was a good interim solution
<Martyn> I nearly have the tegra2 built in audio working.. there's an issue with the buffer I'm trying to solve
<Martyn> but I definitely have the mic input working now
<ogra_cmpc> plars, yes and i have no idea how to fix it :( http://paste.ubuntu.com/419902/
<ogra_cmpc> it doesnt occur in d-i installs at all
<plars> ogra: something, probably in ubiquity, is trying to grab a huge chunk of ram it seems
<plars> ogra: any chance we could fiddle with the compcache percentages and make it happier?
<ogra_cmpc> plars, well, at that point there is even real swap available
<plars> ogra_cmpc: but order 5 is 128M right?
<plars> ogra_cmpc: that is clearly going to fail under our current setup
<plars> no matter how much swap we have
<ogra_cmpc> ubiquity calls swapon dirctly after partitioning
<ogra_cmpc> we use 128M compcache, right
<ogra_cmpc> i wonder if we need it at all now that we run in only-ubiquity mode
<ogra_cmpc> RAM should be sufficient to get through to the installer
<ogra_cmpc> err
<ogra_cmpc> partitioner
<plars> ogra: ram only? or back to 25% compcache?
<ogra_cmpc> plars, if you want to test that you could swapoff ramzswap after partitioning on tty
<ogra_cmpc> or even before
<ogra_cmpc> i wonder if we probably hit a general compcache issue here
<plars> ogra_cmpc: yeah, will give it a try.  Is swapoff enough to make it let go of that memory?
<ogra_cmpc> rmmod probably too
<plars> ogra_cmpc: ok, I did the swapoff and rmmod early (right after booting) and still got a couple of page_alloc failures early on, but I was able to complete the install!
<ogra_cmpc> plars, dang ... not sure how to special case that in a nonintrusive way that slangasek accepts
<ogra_cmpc> i'll think about it we cant do anything before RC anyway
<plars> ogra_cmpc: I'd like to experiment a bit... I'm wondering if we could tone down the 50% to something like 35% and get away with it
<ogra_cmpc> plars, thanks a lot for the test !
<plars> ogra_cmpc: at the very least, we have a cumbersome workaround
<ogra_cmpc> sure, play if you like
<ogra_cmpc> yeah
<ogra_cmpc> very good work !
<plars> ogra_cmpc: I'll open a new bug against casper on this, rather than recycle the old one, unless you feel different?
<ogra_cmpc> yeah, do that
<plars> I think circumstances have changed enough that just tacking it on and reopening the old one would be confusing
<ogra_cmpc> indeed
<ogra_cmpc> though the question is if slangasek will allow it or not
<ogra_cmpc> and i also think it might really be specific to the omap kernel
<ogra_cmpc> i.e. .33 obviously has a new compcache implementation, there is very likely a reason for that
<ogra_cmpc> would be intresting to see what a babbage board does in the same case if you boot with mem=256M
#ubuntu-arm 2010-04-22
<DanaG> mountall: Plymouth command failed
<DanaG> ... repeated about 1000 times.
<amitk> DanaG: are you using LVM?
<DanaG> Nope.
<DanaG> And I do dislike how plymouth refuses to show splash if a serial console is present.
<amitk> yeah, that is a known plymouth bug
<amitk> I hate it too, first this I disable is plymouth
<amitk> s/this/thing
<hrw> morning
<DanaG> Nice thing: watchdog.
<DanaG> Makes it so that omapdss reboot crash makes it still reboot anyway, instead of just dying.
<sveinse> I'm about to do some kernel debugging on ARM target. Do you know of an decent GUI for gdb (-arm) which can run on host?
<saeed> ogra: ping
<ogra> hey saeed
<saeed> hey ogra
<saeed> the uboot on dove takes too long time to read the kernel image and initrd
<saeed> the uboot sata driver is optimized (using DMA, upt to 128 sectors requests)
<ogra> hmm, sounds like a case for ericm and NCommander
<saeed> it looks to me that for some reason those files are too mush scattered on the disk
<ogra> which installer is that ? GUI or text mode ? (the files live in different subdirs in either one)
<saeed> GUI
<saeed> the files under /boot/ dir
<ogra> so the live in /casper/uI*
<ogra> no, the live installer holds uImage and uInitrd in the /casper dir
<ogra> though i know NCommander worte a rather complex uboot script that scans all devices before loading, do you install from USB or SD card ?
<ogra> i think USB is scanned first, so using that should speed up the probing
<saeed> I installed from USB
<ogra> hmm, then the probing shouldnt have any effect i think
 * ogra looks at the script
<saeed> ogra: I problem that I notice is that when the script reads the images from the hdd, the read process takes too much time, maybe 10 seconds just to read ~3MB image
<ogra> http://paste.ubuntu.com/420270/
<ogra> hmm, the script seems to scan all devices regardless
<saeed> right know I don't have a problem with the scan process of the uboot
<saeed> the thing is that it takes too much time to read from sata hdd
<ericm> saeed, still I guess it's a sata drive issue, as usb loading is pretty fast
<ericm> either booting from /casper/ or any other image I wrote later to the USB disk
 * ogra wonders where ${fs} ${interface} and ${device} come from for the first if in that script
<ericm> I believe scatter status is no better from usb disk perspective
<saeed> ericm: yes
<ericm> maybe other part of u-boot introduces some delays?
<saeed> I think also with ssd that won't be an issue
<ogra> saeed, oh, you were talking about post-install ?
<ogra> sorry, i didnt get that
<saeed> ogra: yes
<saeed> do you know about a method for allocating the kenrel and initrd images so they can be contiguous on the hard drive
<ogra> oh, wait, the same script is used in inistalled systems
<saeed> yes
 * ogra looks at the flash-kernel source
<ogra> and it definately initializes USB and IDE first, probes USB fat, then USB ext2 and only *then* switches to probe IDE fat and *last* it probes IDE ext2
<ogra> imho the order is totally wrong here if we always expect the install to live on IDE ext2 it should be the other way round
<ogra> so that gets probed first
<ogra> have you monitored a boot in serial console to see what uboot actually does ?
<ericm> ogra, saeed is seeking a way to contiguously write uImage and uInitrdto the hard drive
<ogra> ericm, right, but still we use several seconds before the loading even starts
<ericm> saeed, I guess the kernel strategy to write out a file (if not interrupted) is to write it as contiguously as possible
<ericm> ogra, yeah - but that's something we can fix maybe, the loading speed of uImage/uInitrd binary - only Marvell can fix that :-)
<ogra> its likely an additional issue i see here but it might cost valuable extra time in the boot
<saeed> orga: yes ,I think the first "if" will be taken here
 * ogra has no dove hardware to actually test or confirm anything sadly
<saeed> ogra: see http://paste.ubuntu.com/420275/
<ogra> yeah, line 1-41 are pointless on an installed system
<ogra> (apart from initializing IDE actually)
<ericm> saeed, the first part of the script is actually within u-boot
<ericm> to look for a boot.scr
<ogra> ericm, look at the paste
<ogra> it scans everything before doing any load
<ericm> ogra, yeah I'm looking
<ericm> ogra, I guess we could move ide to first place as that's mostly used
<saeed> ogra: why do you think the IDE is re-initialized?
<ericm> installation is less frequently happening
<saeed> ogra: are you talking about installation process?
<ogra> saeed, no, about your serial capture
<ogra> saeed, line 18-41 in your paste clearly show that the full script is executed before anything gets loaded at all
<ogra> ericm, there is no difference between the installation boot.scr and the boot.scr after installation, they are identical
<saeed> ogra: this the uboot default boot command
<ogra> which costs a lot of extra scan time for nonexisting USB
<ericm> ogra, I'm not talking about the installation boot.scr, I mean the u-boot builtin boot.scr
<ogra> ericm, they appear to be identical
<ericm> ogra, right so the improvement can be done to both version
<ogra> the builtin boot.scr should bail out the moment it doesnt find USB
<ogra> (as the installation one should)
<ericm> ogra, right - and the builtin boot.scr should scan ide first as that's more commonly used
<ogra> instead of trying to probe vfat and then ext2 additionally
<ogra> ericm, no, then you cant install
<ericm> ogra, ah well - that's the problem
<ogra> it *should* check for USB ... but if it doesnt find a device it shouldnt try to fatload/ext2load
 * ericm feels stumped
<ericm> ogra, that's correct
<ogra> currently it goes on trying to load stuff from a nonexisting device
<ogra> which is nonsense and wastes a lot of time
<saeed> ogra: if you need the uboot from usb disk if connected, then the flow is ok
<ogra> saeed, it shouldnt try to load if there is no device
<saeed> ogra: but maybe the sata disk connected, and it have proken kernel
<saeed> broken
<ericm> saeed, which means if "usb reset" returns failure, "fatload/ext2load" can be skipped
<saeed> ericm: does usb reset fails if no usb device is connected?
<ericm> ogra, ah - it seems fatload/ext2load combines the probing and reading all together unless you have a way to separate them into two commands
<ogra> yes
<ericm> saeed, nope
<ogra> (though its "usb start"
<ericm> saeed, sorry I over looked
<ericm> ogra, yeah it is usb start and it takes a lot time for unknown reason, ide reset is fast enough
<ogra> you could have something like  "if usb start; fatload/ext2load .... fi"
<ogra> so it will not try to load if there is no usb device
<ericm> ogra, but we are not sure if the current implementation of "usb start" returns what
<ogra> test it :)
<ogra> (i dont have the HW )
<ericm> ogra, hope it's returning the number of usb storage devices found
<ogra> well, the hush shell "if" will look if it exits 0 or nonzero
<ogra> no matter what it returns
<ogra> if usb start; .... fi should work fine as a wrapper for the load commands here
<ogra> the prob with the existing script is that it is one big loop
<ogra> it should be split into multiple conditional loops instead
<ericm> ogra, it doesn't work with a quick test, we may need to modify "usb start" to return 0 if there are any storage devices, otherwise non-zero
<ogra> if test -n usb start; then ... fi
<ogra> try that
<ericm> usb reset seems to return a true condition here whether a usb disk is plugged or not
<ogra> err, hmm
<ogra> -n wont help
<ogra> but you should be able to use test properly here
<ericm> ogra, only if it returns different value depending on how many storage devices are attached
<saeed> ogra: usb start taked 5 seconds, and accessing usb does't take noticable time if no device found
<ericm> ogra, and the "usb start" is really slow, which should be avoided during normal running (but then we need a way to tell uboot it's in installation mode and run 'usb start')
<ericm> saeed, right - the most time consuming thing is "usb start"
<ericm> but the problem is we don't do this automatically and everytime, installation isn't possible unless we tell u-boot explicitly
<saeed> guys, I think that should be handled in productions systems, for example, the user shoud press on some button so the uboot will try boot from usb
<ericm> like F12 in IBM thinkpad to tell BIOS to boot from CDROM
<ericm> saeed, exactly what I'm thinking
<ogra> saeed, ++
<ericm> the problem is that: there is only the power button :-)
<ericm> or the reset button ??
<ericm> or introducing the keyboard (USB/HID) support in u-boot, which is super fantastic :-)
<saeed> ericm: thats is not straightforward
<ericm> saeed, I'm joking :-)
<saeed> :)
<ericm> saeed, a kexec -based soft loader, though, may really be helpful to solve this issue
<ericm> esp. kexec seems rather stable on dove
<saeed> yes
<ericm> and it's loading uImage/uInitrd quick enough
<saeed> ericm: yesterday I tried to use it, but it didn't work
<saeed> the next boot the system complains that it can't find the initrd on address 0
<saeed> where does the kexec allocate the initrd?
<ericm> saeed, ah well - that's because you are still using the old kexec binary
<ericm> which needs to be patched (a single line though)
<saeed> mmm
<ogra> ericm, if we have kbd support we only need to add framebuffer !
<ericm> the uImage will decompress itself into some place in initrd, by placing initrd far away behind, it can be solved
<ericm> ogra, that's right
<saeed> can I just update it ?
<ericm> saeed, it's not in repo yet, wait
<ericm> saeed, check http://people.canonical.com/~ycmiao/kexec/, copy kexec and kdump to overwirte the original copioes
<saeed> ericm: it didn't work!
<ericm> saeed, .....
<saeed> # kexec  --version kexec-tools: 2.0.1-git released 13th August 2009
<ericm> saeed, let me re-upload my local version
<saeed> ok
<ericm> saeed, try again
<ericm> saeed, btw bug 509006 - hibernation resuming failure, I was able to track that to swsusp_arch_resume() where when restoring pages on "restore_pblist", it caused data abort
<ubot4> Launchpad bug 509006 in linux-mvl-dove (Ubuntu Lucid) (and 1 other project) "[dove] hibernation failed to resume (affects: 4) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/509006
<saeed> ericm: kexec works, thanks alot
<ericm> saeed, no problem
<ogra> ericm, now get it working on omap and imx51 and we can actually make use of it :)
<ericm> ogra, it should be working - but you remind me to put the patch to lp, which I should have done long time ago
 * ericm is a slack
<ogra> afaik kexec on imx51 breaks a bunch of currently working stuff
<cooloney> ogra: really?
<ogra> i cant remember what exactly but i think cooloney said suspend/resume
<cooloney> kexec breaks many things?
<ogra> oh, cooloney there are you :)
<ogra> didnt you say it broke suspend ?
<cooloney> ogra: hehe, actually, i did not found the root cause of the suspend/resume regression
<ogra> iirc that was before you fiddled with fec
<cooloney> ogra: it should be ok after the kexec patches
<ogra> and suspend worked before you added the kexec patch
<saeed> ericm: the fact that the system hangs at swsusp_arch_resume() doens't necessarly mean that the it's a kernel bug
<ogra> ok, then i misunderstood
<cooloney> ogra: and one patch fixed the suspend/resume issue from jk, who introduce that regression in the leds bug fixing
<ogra> yeah
<ogra> i remember that one
<cooloney> then after that, the candidate should be me my fec driver
<ogra> yup
<cooloney> now i fixed that, it can suspend,
<cooloney> but cannot resuem
<cooloney> currently, my babbage board was dead totally,
<cooloney> it cannot power on now
<ogra> cooloney, btw, what became of the regulator disaster with your board ?
<ogra> ah
<ogra> snap
<cooloney> ogra: i think i will fix them soon
<ericm> saeed, yeah - but it's really weird that if hibernation resume is done earlier then it works all right
<cooloney> ogra: the report from plars about the regulator testing kernel is reasonable
<ericm> saeed, basically the initramfs does the resume by writing to /sys/power/resume and trigger the hibernation resume explicitly
<saeed> ericm: if your swap on usb, then the resume will not be done earlier, and it should work
<ericm> saeed, why is that - resume will not be done earlier?
<saeed> ericm: because usb disk get discovered only at later point
<ericm> saeed, the difference is that - one is done in rootfs_initcall() , the other is done in early user space
<DanaG> how are you even supposed to wake an omap (beagle)?
<saeed> ericm: sotware_resume is done from late_initcall
<saeed> ericm: both methods should work
<ericm> saeed, I expect so ... but the initramfs version just doesn't work :-(
<saeed> ericm: iirc, beta2 succeeded to resume from initramfs, when resume= added to command line. can you please try that version?
<saeed> you don't need to install it, you can try the usb live
<ericm> saeed, I was able to resume with "resume=" I can confirm that
<saeed> you meam the early resume, no the initramfs resume, right?
 * saeed brb
<ogra> ndec, im blazed ! (just had fedex here) :)
<ndec> ogra: congrats!!!
<ogra> its sooo sexy !
<ndec> ogra: later today, I need to give you instructions to get the right kernel...
 * ogra will put it under his pillow at night :)
<ndec> ogra: but I am a little busy for now
<ogra> yeah, no urgence before lucid anyway
<amitk> ogra: just don't slobber all over it :)
<ogra> i need to concentrate on the beagle image
<ogra> amitk, hard to do :)
<ndec> ogra: i am sure you will want to see it running, even before lucid ;-)
<ogra> heh, indeed
<ogra> ndec, what i love most is that it has the same color as one of my porsches ... how did you guys know that ? :)
<amitk> show off!
<ogra> nice bordeaux red :)
<ogra> amitk, you know my porsche, dont you ? http://people.canonical.com/~ogra/2CAF65BCd01.jpg
<amitk> i do, seen it in barcelona i think
<ogra> (though thats the one sitting in the garage, i drive another one atm)
 * amitk is so confused about UDS'
<ogra> no, the one ion barcelona was the more powerful one :)
<ogra> it'll take me to brussels too this time ... and its more loke firengine red
 * ericm wonders how many porsche ogra has
<ogra> ericm, two
<ogra> which gets me regular stress with my GF :)
<amitk> ericm: as I said - show-off :)
<ericm> amitk, yeah indeed
<ogra> amitk, hmm, so it seems we have issues with compcache on omap
<ogra> if i swapoff and remove the two compcache modules my install finishes properly
<ogra> if i dont, i end up with stuff like http://paste.ubuntu.com/419902/ in dmesg
<ericm> ogra, amitk, possible to get a beagle and get it reimbursed? I'm thinking about getting another arm-v7 SoC for testing purpose
<lool> ogra: Hey
<lool> ogra: Did you reproduce the qemu-maemo beagleboard issue yesterday?
<ogra> lool, what issue ?
<lool> ogra: The kernel hang after uncompressing linux
<ogra> no, i dont have qemu-maemo here, still fighting with the compcache issue on the netbook image
<amitk> lool: the link you sent was regarding fw_setenv
<lool> amitk: was not?
<lool> ogra: Ok, nm, just confusion
<ericm> ogra, amitk, or you guys have spare one that I borrow at UDS?
<lool> ericm: Did the kexec issue affect dove?
<ericm> lool, not dove specific
<ericm> saeed, weird - JTAG stops at data abort when restoring page at 0x81044000 (with a copy at 0x98f00000), I'm seeing no speciality of this specific page
<ericm> the weirdest thing is data abort happens in the middle of page restoring, which is unusual
 * ericm be right back
<lool> ericm, cooloney: Is one of you sending this bug upstream in kexec-tools?
<cooloney> lool: oh, i think ericm is working on this
<DanaG> oh yeah, random thing: I get spew of "Mountall: Plymouth Command Failed" at boot.
<DanaG> It uses 100% of one cpu core on the HOST system when watching the serial console.
<lool> Gah dpatch
<lool> DanaG: strace it
<lool> DanaG: might be https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/567964 ?
<ubot4> Launchpad bug 567964 in mountall (Ubuntu) "mountall keeps on running (affects: 2) (heat: 12)" [Medium,Confirmed]
<lool> just hit this this morning on my laptop myself
<DanaG> How do I strace it during boot?
<lool> DanaG: It's only during boot?
<DanaG> Yeah.
<DanaG> And it stops spewing after a while.
<lool> DanaG: Ok; what's your image?
<DanaG> Or perhaps it's spewing just after boot.
<DanaG> Image as in file system, or as in picture?  Since I'm using serial console, it gives me no splash screen.
<DanaG> Same thing happens on my host system (AMT serial console).
<DanaG> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/557161
<ubot4> Launchpad bug 557161 in mountall (Ubuntu) "mountall: Plymouth command failed (dup-of: 559761)" [Undecided,Confirmed]
<ubot4> Launchpad bug 559761 in mountall (Ubuntu Lucid) (and 1 other project) "mountall needs to flush plymouth message queue before emitting upstart events (affects: 26) (dups: 2) (heat: 152)" [High,Fix committed]
<DanaG> anyway, bedtime now.
<DanaG> I commented on a bug about "no splash as soon as console= is present", as well.
<DanaG> Thu Apr 22 02:42:15 PDT 2010
<ogra> it could also be bug 563618
<ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
<ogra> in combination with bug 516825
<ubot4> Launchpad bug 516825 in plymouth (Ubuntu) "plymouth doesnt show any splash as soon as a console= commandline option is used on boot (affects: 2)" [Medium,Fix released] https://launchpad.net/bugs/516825
<ogra> i think the latter one breaks in worse ways than at the time it was reported
<NCommander> ~~~~A;2~
<NCommander> sorry, cat
<NCommander> saeed: ogra_cmpc: uboots abaility to be scripted is incredibly poor
<saeed> NCommander: hey
<NCommander> saeed: hola
<saeed> are you talking about adding the if "usb start"
<NCommander> saeed: theres no way to check if usb sstart ran successfully or not; it returns no error code nor is there a way to see how many devices were found
<NCommander> saeed: I'd like to add such functionality as part of an optimization if I ever got the time, but the biggest holdup is just raw read speed
<saeed> NCommander: anyway, I don't think that it will save a noticable time
<saeed> NCommander: what do you mean by the raw read speed?
<ericm> NCommander, since kexec is now available - we might want to speed up the softloader project
<NCommander> saeed: if you look at the boot time, 10-20 seconds are just spent at ext2load ide
<saeed> NCommander: yes, I agree
<NCommander> ericm: maybe for 10.10, but dove ends with 10.04 :-/
<saeed> NCommander: mayeb defrag of the boot partition could help
<NCommander> saeed: hasn't beofre. the issue seems to be a lack of DMA on reading from SATA
<NCommander> saeed: but I haven't looked at the code extensively to confirm
<saeed> NCommander: the uboot ide driver is ok
<NCommander> saeed: then I have no explination on the speed
<saeed> just try "ide read 0x2000000 0 0x10000" and you will see that it completes very fast
<saeed> the ide driver support DMA and requests up to 128 sectors (64K)
<saeed> it could be unoptimized ext2 implementation
<NCommander> saeed: that could be it
<NCommander> saeed: the question is what can be done about it?
<saeed> NCommander: I've had ssd disk, and the uboot read of images was fast
<NCommander> saeed: not so much here, when I used a sata ssd, it wasn't much of a speed improvement
<saeed> mabye writing the images are row date on known partition :)
<NCommander> saeed: huh?
<saeed> I mean to write the kernel image on /dev/sda1, then uboot will load the image from sector 63
<saeed> without fs
<lool> ericm, cooloney: Sorry, kept crashing hard a couple of times; will look into kexec-tools
<ogra> stop crashing !Q
<NCommander> saeed: we do tha tfor imx51, but its too late/difficult to change the behavior now for 10.04
<NCommander> saeed: with a little luck, softbootloader will materialized for 10.10 and we'll have a GRUB like booting experience
<ogra> well, there is also change that we actually get grub proted to ARM
<ogra> *chance
 * ogra still has that on this plate to make sure the grub guys get the HW they need
<ericm> lool, no problem
 * cwillu_at_work grumbles about usplash not building from source
<lool> cwillu_at_work: Seriously?
<lool> cwillu_at_work: What's the error?
<cwillu_at_work> sec
<cwillu_at_work> it's an asm constraint thingie
<lool> cwillu_at_work: I dont see it on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi at least
<cwillu_at_work> in the svgalib included
<lool> ah on arm
<lool> indeed we dont test rebuild armel ATM
<dmart> lool, asac, ogra: can anyone with a dove do a quick test for me?
<lool> dmart: I dont have one
<dmart> Relates to bug 567956
<ubot4> Launchpad bug 567956 in linux-fsl-imx51 (Ubuntu) "ARM: Incorrect prefetch abort handling can cause a spin instead of SIGSEGV (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/567956
<hrw> saeed: what is 'softloader project'?
<lool> saeed ^ dmart is looking for testers with dove hardware
<lool> hrw: mukluk
<cwillu_at_work> lool, did you still want the error message?
<lool> hrw: https://launchpad.net/mukluk
<lool> cwillu_at_work: Yes, file a bug actually
<lool> cwillu_at_work: we have some binaries available for it https://launchpad.net/ubuntu/+source/usplash/0.5.51 but it's not rebuilt with latest toolchain
<cwillu_at_work> lool, .../usplash-0.5.49/src/libvga.h:275(and294): error: impossible constraint in 'asm'
<dmart> saeed: would you be able to do a qkick test for me?
<lool> cwillu_at_work: Probably a thumb2 porting issue
<lool> cwillu_at_work: Please do file a bug with the log
<cwillu_at_work> lool, ya, I can't use the binaries;  I'm trying to hack out the /dev/.initramfs
<lool> cwillu_at_work: thing is, we moved to plymouth and usplash is now in universe, so wasn't on our radar
<saeed> dmart: hey
<lool> it's pretty much being phased out I'm afraid
<cwillu_at_work> lool, this is in karmic still, but ya
<dmart> saeed: Hi there
<lool> cwillu_at_work: Quick fix: try building with -marm in CFLAGS
<saeed> dmard: sure which test
<hrw> lool: like kexecboot from OE guys
<cwillu_at_work> if lucid would install in qemu, I'd be on it already :)
<lool> hrw: eh
<cwillu_at_work> k, I'll give that a shot
<dmart> saeed: I added the test case in bug 567956
<ubot4> Launchpad bug 567956 in linux-fsl-imx51 (Ubuntu) "ARM: Incorrect prefetch abort handling can cause a spin instead of SIGSEGV (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/567956
<lool> hrw: like other existing bootloaders, yes
<dmart> saeed: you're running 2.6.32, yes?
<lool> hrw: google for it and you should find a spec for it where this was discussed
<saeed> yes
<cwillu_at_work> ugh; how do I file a bug without using ubuntu-bug again?
<amitk> cwillu_at_work: ubuntu-bug <package-name>
<dmart> If you can try the test case, you should get a segfault, indicating that the bug isn't present in the dove kernel
<cwillu_at_work> amitk, your reading comprehension leaves something to be desired :p
<hrw> ok
<amitk> cwillu_at_work: indeed :)
<saeed> dmart: I just got Segmentation fault
<dmart> saeed: cool, that's what I wanted to hear :)  Thanks for testing
<cwillu_at_work> https://bugs.launchpad.net/ubuntu/+source/<packagename>/+filebug?no-redirect
<saeed> dmart: the "ARM: 5728/1: Proper prefetch abort handling on ARMv6 and ARMv7" is applied into my kernel
<dmart> saeed: I think it was merged into mailline 2.6.32
<dmart> ...so that's what I expected
<saeed> I see
<dmart> Just wanted to make sure
<dmart> thanks
<cwillu_at_work> lool, adding -marm to CFLAGS in debian/rules didn't affect it
<cwillu_at_work> lool, https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/568337
<ubot4> Launchpad bug 568337 in usplash (Ubuntu) "usplash fails to build from source (armel, karmic) (affects: 1)" [Undecided,New]
<dmart> cwillu_at_work: can you add gcc version details to your bug report?  A source snippet of the relevant lines might be handy, but I expect the source won't change that rapidly...
<cwillu_at_work> done
<dmart> Thanks
<dmart> Out of curiosity, are vga.c, libvga.h applicable to arm at all?
<dmart> aH
<dmart> We seem to be trying to build x86 inline asm here...
<dmart> http://pastebin.ubuntu.com/420366/
<NCommander> dmart: what do you need tested on dove?
<dmart> NCommander: it's OK, saeed did it already
<NCommander> dmart: oh good
<dmart> cwillu_at_work: Maybe there's some wrong config or #ifdefs somewhere, or perhaps we shouldn't build those files on ARM--- normally graphics means X or framebuffer or nothing
<cwillu_at_work> so, wrong backend?
 * ogra_cmpc finds all that a bit weird, we definately shipped usplash on arm in karmic 
<ogra_cmpc> in both platforms
<cwillu_at_work> yep, I'm using it right now
<ogra_cmpc> i dont get why you cant recompile it then
<ogra_cmpc> since it definatly built successfully in the archive back then
<ogra_cmpc> i think it also should default to use bogl on arm, weird that it chooses vgalib
<cwillu_at_work> debian/rules doesn't make any reference to bogl
<cwillu_at_work> what is bogl?
<ogra_cmpc> the other backend
<cwillu_at_work> ...work via? :p
<ogra_cmpc> no idea, i would have to dig in the code, i think plain framebuffer
<cwillu_at_work> okay; trying to rebuild against that
<ogra_cmpc> https://edge.launchpad.net/ubuntu/karmic/armel/usplash all karmic versions built
<lool> dmart: You could check the build log for the version in lucid
<lool> dmart: (of usplash)
<lool> dmart: ISTR we're using the fb backend of usplash to draw; there's an embedded svgalib IIRC
<ogra_cmpc> the last lucid build was before we changed the toolchain defaults though https://edge.launchpad.net/ubuntu/+source/usplash/0.5.51/+build/1373831
<ogra_cmpc> but if you use a karmic toolchain that shouldnt matter
<lool> ogra_cmpc: Yes, but it shows which files were built
 * cwillu_at_work points out that the error is in the embedded svgalib
<ogra_cmpc> in the buildlog it seems to ignore svgalib and only build bogl
<cwillu_at_work> build completed with BACKEND="bogl"
<ogra_cmpc> right
<ogra_cmpc> but the package should select that automatically based on the arch
<lool> cwillu_at_work: You build the package with dpkg-buildpackage, right?
<lool> Not ./configure + make etc.
<cwillu_at_work> lool, debian/rules binary
<ogra_cmpc> hmm
<lool> cwillu_at_work: That changes CFLAGS/LDFLAGS, but I wouldn't expect a big difference
<cwillu_at_work> debian/rules has a check for i386 amd64 lpia, which sets BACKEND = "BACKEND=svga"
<cwillu_at_work> the other branch sets it to BACKEND =
<lool> ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),i386 amd64 lpia)) BACKEND = "BACKEND=svga"
<lool> else BACKEND =
<lool> cwillu_at_work: ack
<lool> endif
<cwillu_at_work> lool, and for the crowning touch:  when I set backend to bogl, I did it in the i386/amd64/lpia branch, _not_ the else
<cwillu_at_work> and that built successfully
<lool> cwillu_at_work: So it should just build the bogl code on armel, not svga
<cwillu_at_work> ifeq ($(DEB_HOST_ARCH), $(findstring $(DEB_HOST_ARCH),i386 amd64 lpia)) BACKEND = "BACKEND=bogl"
<cwillu_at_work> is what I changed it to
<lool> GAH
<lool> nothing sets DEB_HOST_ARCH
<ogra_cmpc> heh
<lool> cwillu_at_work: You should REALLY use dpkg-buildpackage!
<lool> cwillu_at_work: The bug is that the rules don't set DEB_HOST_ARCH properly, but dpkg-buildpackage always sets them
<cwillu_at_work> so it's a lintian'ish thing
<lool> It's a packaging bug, but one which will only affect people running debian/rules binary  :-)
<cwillu_at_work> well, now you know :p
<ogra_cmpc> and which it unlikely to be fixed at all ... since usplash will vanish
<cwillu_at_work> it's disappearing from debian too?
 * ogra_cmpc doubts anyone will put any time in that package
<ogra_cmpc> debian uses it ?
<ogra_cmpc> i thought they preferred splashy anyway
<cwillu_at_work> well it's in universe
<cwillu_at_work> it's not native to ubuntu is it
<lool> cwillu_at_work: Pushed to bzr
<ogra_cmpc> it was
<lool> cwillu_at_work: Ubuntu is the upstream
<ogra_cmpc> not sure if they pulled it into debian or not
<lool> hence the abuse of native packaging
<lool> It's definitely pulled in Debian
<cwillu_at_work> ah, k
<ogra_cmpc> ah
<lool> for the same reason, it wont affect Debian too hard
<lool> anyway, fixed
<cwillu_at_work> <3
<lool> ericm: I pushed a test package; would love if you could answer to the questions I asked on the bug
<lool> as to have a test case documented by someone else than me
<ericm> lool, ok - you updated on LP?
<lool> ericm: Yes
<ericm> lool, I'll take a look
<lool> ericm: https://launchpad.net/~canonical-arm-dev/+archive/marvell-dove-public/+build/1702324
<ericm> lool, ok - guess I could download the deb directly instead of adding the ppa to my dove
<lool> ericm: Yes
<lool> that's why I pointed you at this URL, and also because the PPA publishing might take up to 20 minutes
<ericm> lool, no problem, I'll give it a run and update the LP
<ericm> versatile & beagleboard, I'm afraid there are several kernel patches needed
<ericm> https://bugs.launchpad.net/adana/+bug/517841
<ubot4> ericm: Error: Bug #517841 is private.
<lool> ericm: These didn't make it to the kernel?
<lool> These are from March
<ericm> lool, not in .32 I guess
<ericm> lool, but should be sitting there if versatile&beagle kernel are built from latest
<lool> What prevented them from being merged into our various ARM trees!?
<lool> I dont see these commits in our master tree at least (from which versatile is built)
<lool> nor in ti-omap, which is -33 based
<ericm> lool, that's the problem, we are currently maintaining different branches for different ARM SoC so these patches do just get into each other branch
<ericm> s/do/don't
<lool> ericm: I've seen patches from master propagate into the other trees though
<ericm> lool, but yeah - this is common and should go into master instead
<lool> ericm: Do you mind if I make the bug public and affecting Ubuntu arm kernel branches?
<lool> except fsl-imx51 which has the fixes of course
<lool> in fact mvl-dove has them as well
<lool> so linux-ti-omap and linux
<ericm> lool, no problem, it should have been made public
<NCommander> saeed: eggonlea you around?
<saeed> NCommander: yep
<asac> saeed: see msg
<asac> or talk to NCommander ;)
<lool> ericm: Could you help track / test it in other kernels?
<ericm> lool, no problem
<lool> asac: Would you put that on your SRU radar as well?
<lool> will flag as stable updates candiates
<lool> ericm: it's confirmed as needed for versatile and omap, right?
<ericm> lool, btw - current kexec-tools has support for uImage right?
<asac> lool: which?
<lool> ericm: Dunno
<lool> ericm: never tried uimage
<asac> (sorry on call ... didnt read backlog)
<lool> ericm: let me know :)
<lool> asac: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/517841
<ubot4> Launchpad bug 517841 in linux-ti-omap (Ubuntu) (and 2 other projects) "KEXEC support broken (affects: 2) (dups: 1)" [Undecided,New]
<ericm> lool, we do need that for versatile and omap
<lool> ericm: Ok thanks
<ericm> lool, guess I need a beagleboard somewhere
<lool> ericm: You should get one
<lool> ericm: There are plenty of people here to test in the mean time
<asac> lool: so assign to amitk? or ericm?
<asac> and yes, its on SRU radar as its now targetted ;)
<asac> feel a bit reluctant about fixing this in linux in SRU ... is that a safe patch`across the board?
<ericm> asac, I think we should make the kexec work back into master - so every ARM branch will have it once rebased
<ericm> including OMAP
<asac> ericm: can you change your patch attachments to text/plain? my browser doesnt like text/x-diff ;)
<asac> (not importnat)
<asac> ericm: yes, but will this patch be good enough for lucid SRU? i see this for maverick for sure
<ericm> asac, I was originally sending attachments in text/plain, but later found the checkbox that "The Attachment is a patch", I cannot resist to leave it unchecked :-)
<ericm> asac, I don't think so, we don't have any existing user land stuffs, -M is a go as we move to soft bootloader
<asac> ericm: heh. the patch i edited didnt hav that checkbox checked ;)
<ericm> that really depends how quick NCommander is able to come up with it, NCommander ?! :-)
<asac> still it was text/x-diff ... but i will survive
 * NCommander reads backscroll
<ericm> asac, .... yeah I know, with pain
<ericm> NCommander, are we bringing forward the soft bootloader to -M?
<asac> ericm: TBD
<NCommander> ericm: softbootloader has working prototype. It might actually land for 10.10 at this point as kernel support landed for imx51 and dove
<NCommander> ericm: we'll have yet another UDS session on it
<ericm> NCommander, cool
<NCommander> I mean, it won't be UDS without an ARM softbootloader session
<asac> NCommander: we will have? i dont think one is scheduled and given that we had a bunch already, do you really think we need a session?
<ericm> NCommander, hehe :-)
<NCommander> asac: its traditional!
 * ericm lol
<asac> right. lets break traditions this cycle and get it actually done instead ;)
<asac> rather than the tradition to just talk ;)
<NCommander> asac: ouch.
<ericm> NCommander, no worry - I'll see if I can help on that if I have time
<ericm> :-)
<NCommander> ericm: time is something that is always in short supply I find.
<asac> ericm: so you cannot test kexec without a softbooloader? is that what you meant by being blocked on NCommander ?
<ericm> asac, no I can test kexec with kexec-tools, that's fine
<ericm> asac, I'm not blocked
<ericm> NCommander, indeed
<asac> ericm: great ;)
<asac> ericm: so can we aim for an sru for linux-omap for lucid, but keep the "linux" fix for m?
<ericm> asac, sure - just assign amitk then, I'll let him know this
<ericm> lool, it's weird - I'm seeing no uImage support in kexec-tools source but the binary in the package does support uImage loading
<ericm> lool, can you point me a URL for the source or bzr branch name?
<ericm> for the exact package you built
<lool> ericm: apt-get source kexec-tools will always give it to you; it might be in a patch in debian/patches/
<lool> ericm: bzr branch lp:ubuntu/kexec-tools will give you the history of package uploads
<amitk> lool: fsl and mvl are or different kernel version in lucid (re: propagating from master)
<amitk> *on
<lool> amitk: But you dont review the linux patches for the other trees?
<amitk> lool: we try, but given the number of patches it is very hard to keep up.
<lool> amitk: Ah I thought there was some kind of process to ensure no patch is lost
<amitk> lool: you live in a perfect world :)
<lool> amitk: Eh, I'm assuming you folks are reaching for the sky!!  ;-)
<amitk> different people working on each of the branches, different deadlines, etc.
<lool> amitk: I wish there would be some process to ensure we do fix issues in all trees   :-/
<amitk> lool: if you come up with something, that will scale across different kernel versions, release deadlines, kernel configs, debian packaging, different people, different time for branching, I am sure we're all interested in following it.
<amitk> :)
<ogra> amitk, you forgot "different flavours of beer/wine"
<amitk> :)
<hrw> btw - is there a list of ubuntu/arm sessions for uds-m?
<ogra> hrw, not yet, lool is a slacker !
 * ogra hides
<lool> hrw: an out of date one is public
<lool> but we kind of suck on this front ATM
<ogra> NCommander, how is gphoto doing ? already uploaded to the queue ?
<dmart> asac: I see there's a fix committed for the firefox scrollbar bug now.  Did you get anywhere working out which object is getting miscompiled?
<asac> dmart: far away from finding the module. i wanted to first see which optimization causes this
<asac> dmart: but that dropped off the radar a bit because building everything -Os didnt evn build and then i got dragged into other stuff.
<dmart> OK.  Well, let me know if you get any ideas ;)  if there is a miscompile somewhere it'd be good to track it down
<asac> dmart: my opinion is that its probably not good to test non default optimizations in firefox
<asac> dmart: its kinda understandable that none -O2 has issues
<dmart> Do you think it may be a firefox issue instead?
<asac> if we want to get toolchain stabilized for other optimizations we should think about starting with base packages and then work up
<dmart> Yeah, I guess
<asac> dmart: hard to say. given that we dont see it anywhere else, i doubt it
<asac> also it goes away with -O2 and goes away when doiung a debug build
<asac> so far only the mozila mix of different optimizations for different subtrees triggers it
<asac> they use -O3, -Os and -O2 mix
<dmart> interesting... there shouldn't be any ABI issues
<asac> its not ABI i would think. it doesnt crash and is stable
<dmart> well, don't worry about it right now, I guess
<asac> just something with math is broken ;) ... my guess
<NCommander> ogra: it should be in the queue, I haven't seen a reject or accept email
<dmart> NCommander: I retried the OOo build on babbage3+lucid and got the same failure as before:
<dmart> ../unxlngr.pro/bin/makedepend: symbol lookup error: ../unxlngr.pro/bin/makedepend: undefined symbol: cppsetup
<dmart> any thoughts?
<NCommander> dmart: er, that looks like a new one
<NCommander> dmart: but my gut reaction is: OOo sucks?
<dmart> The build always falls over this way, I haven't been able to get it any further for at least the last week or so...
<NCommander> dmart: how are you building?
<dmart> debian/rules build
<dmart> But dpkg-buildpackage -B produced the same result previously
<NCommander> dmart: odd ... that should work. It works on Dove I think
<NCommander> dmart: i thought OOO was fully built though
<dmart> Yes, that's why I'm confused.
<NCommander> dmart: does it do it in a pbuilder instance?
<dmart> This build was with the -marm workaround turned off, but I get the same failure either way.
<dmart> This is not using pbuilder, just a manual build
<lool> ericm: Please let me know when you test the kexec package and update the bug with a test case!  :-)
<NCommander> dmart: it possible something in the build environment is breaking OOo. a clean chroot may be the way to go
<ogra> NCommander, great !
<lool> ericm: I see the test case actually now
<ogra> asac, do you still plan to work on xserver-video-omapfb ? else i'll just upload the quick fix
<dmart> NCommander: guess so.  I have the build-deps up to date, but it's a huge fs--- something else might be causing problems
<ericm> lool, it doesn't actually have a test case indeed as you now see :)
<asac> ogra: is archive open again?
<ogra> asac, will open soon
<ericm> lool, the binary from the package actually works
<ogra> i think steve is in last stages for RC
<NCommander> dmart: I can kick a build, or give you a shell on a Dove board
<ericm> weird thing is it looks to me no uImage is supported yet it does work with uImage
<NCommander> ogra: its there: https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=
<asac> ogra: your patch is probably ready and tested?
<dmart> NCommander: it's not urgent.  Basically I wanted a build tree demonstrating the build-time segfault so I can poke at it.  Probably best if I try and reproduce it myself
<asac> ogra: give me 3 hours ... if i dont give anything by then to test etc. go ahead
<NCommander> dmart: well, if you want to rule out hardware, my shell on BBG 2.5 or Dove stands
<dmart> Do we know whether it builds on dove?  It could be worth firing off a build there if not
<NCommander> dmart: it should with -marm, thats where I did all my test builds.
<lool> ericm: Which binary?
<dmart> I mean with -mthumb
<lool> ericm: the kexec one?  Cool
<NCommander> dmart: no, it segfaults
<dmart> Ah right, so it's not buildd-specific...
<ericm> lool, wait - let me make sure I'm using the correct binary first, will get back to you later
<dmart> A shell could be useful, though I won't be working on it right now.  I'll ping you later if I need access to something.
<ogra> asac, my patch adds a 0 to /dev/fb (or XorA's patch now, since he committed it to the bug)
<ericm> lool, it doesn't work - we may need to add uImage into kexec-tools
<ericm> lool, or we may generate a kernel package with zImage or even vmlinux
<ericm> NCommander, why don't we preserve zImage after flash-kernel?
<NCommander> ericm: we do /boot/vmlinuz-*
<ericm> /boot/vmlinuz-* == zImage?
<NCommander> ericm: yeah
<ericm> NCommander, got you
<NCommander> that's why its vmlinuz
<NCommander> decompressed images are traditional vmlinux
<lool> ericm: Can you test with zImage?
<ericm> lool, ok
<lool> ericm: I think I saw the same as you did: vmlinuz doesn't work but vmlinux does
<lool> ericm: I converted the file with a helper I wrote here
<lool> http://people.canonical.com/~lool/vmlinuz-to-vmlinux
<asac> ogra: well. go ahead ... i turned out to be busy most of the rest of the day ;)
<NCommander> dmart: do you have IPv6 by any chance? :-)
 * ericm is seeing mountall: Plymouth command failed printed out like crazy
<dmart> NCommander: probably not...
<NCommander> dmart: sudo apt-get install miredo will setup IPv6 over UDP. Then you can SSH into my boards if you need them
<ogra> asac, ok, will do
 * dmart makes a note
<ericm> lool, vmlinuz seems all right
<ericm> lool, both vmlinuz and converted vmlinux worked
<ericm> the converted vmlinux has no decompressing, which should be slightly faster
 * ericm needs some sleep
<lool> ericm: Cool
<lool> ericm: So we can push these kexec patches it seems
<mopdenacker> Hi, I'm booting my Beagle with the LL image on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ . However, because of the "only-ubiquity" boot option, it doesn't start the live CD but directly the Ubiquity installer. Bug or feature?
<lool> ericm: Pushed the pacakge to lucid; pending approval
<lool> mopdenacker: that's intended
<lool> ogra: ^
<mopdenacker> It could be a bug because the Beagle has enough RAM to run the live CD (at least my rev C2). Could it be made for Rev A and B boards? Did they have 128 MB?
<lool> mopdenacker: In theory they do, but apparently compcache support breaks this; ogra has the details
<ogra> right
<mopdenacker> lool: thanks! I don't see compcache in the kernel messages though...
<ogra> compcache has issues on the beagle we couldnt solve anymore so it still causes OOM
<mopdenacker> Ah, right.
<ogra> you should see compcache with swapon -s
<ogra> well, ramzswap
<ogra> though we still saw malloc errors with that setup
<ogra> the next image will not use compcache at all anymore
<ogra> i just committed a fix and a new image build should happen as soon as initramfs-tools is in the archive
<ogra> mopdenacker, i would suggest to use the netinst image though thats the text installer indeed
<mopdenacker> ogra: thanks! Hope we will manage to make ramzswap work in the next release. That sounds attractive.
<ogra> we will
<ogra> the prob is (i suspect) that we use an old compcache implementation that was originally written for 2.6.28 ...
<mopdenacker> Cool!
<ogra> with 2.6.33 a rewrite entered staging but that requires a changed userspce handling
<ogra> the omap image came in very very late in the cycle, so we couldnt rewrite the userspce bits in time and just took the old implementation
<ogra> which is likely causing the different issues we see
<ogra> for 10.10 we'll have a lot more time to make everything smooth and sort out all bugs
<mopdenacker> Great, that's good to know that everything should be all right with mainline.
<plars> mopdenacker: I've had some success installing from the netbook image by removing the swap on ramzswap0 and unloading ramzswap and xvmalloc, but certainly the d-i based image is going to be a more memory friendly install
<cwillu_at_work> but what will I run on my arm-based server then?
 * cwillu_at_work demands perfection from his lts
<ogra> cwillu_at_work, the ubuntu-server image
<ogra> cwillu_at_work, http://cdimage.ubuntu.com/ubuntu-server/ports/daily/current/
<cwillu_at_work> "<ogra> for 10.10 we'll have a lot more time to make everything smooth and sort out all bugs"
<ogra> oh
<ogra> heh
<cwillu_at_work> and then I was kinda making fun of the concept of using an arm board as a server
<cwillu_at_work> despite the fact that I'm actually in that business :p
<mopdenacker> Is there documentation for installing 10.04 on the Beagle besides the http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ page? I'd like to help writing doc about this.
<ogra> cwillu_at_work, yeah, i guess smoothstone would disagree about the joke part :)
<mopdenacker> ogra, thanks for the tip for ubuntu-server! I plan to use it on my IGEPv2 board, with a home made kernel. That's a perfect board for a home server.
<ogra> indeed
<mopdenacker> Back to the Beagle install, my board doesn't automatically load the boot.scr file, while it did with someone else's board. Probably because I have my own U-boot in NAND flash.
<mopdenacker> The documentation should tell which U-boot image to download and how to install it in NAND.
<mopdenacker> That's why I propose to write this doc if it doesn't exist yet (I already have all the instructions).
<cwillu_at_work> mopdenacker, the documentation should tell you which distribution to use, and how to install it
<ogra> https://wiki.ubuntu.com/ARM/BeagleNetInstall
<ogra> mopdenacker, ^^^
<mopdenacker> cwillu_at_work: right! Do you know if such documentation exists somewhere, or should I create it?
<mopdenacker> ogra: great, many thanks!
<ogra> beyond that i'll create a page on the ubuntu wiki explaining how to get the ubuntu uboot-omap package, extract it and flash it to NAND
<ogra> but if you already have *something* in NAND the above should get you going
<ogra> (will work with all ubuntu images, they all use the same boot.scr (just different cmdlines))
<saeed> NCommander, ogra
<ogra> here
<saeed> the slow read from sata seems to happen only on dove
<saeed> I tried to read the same file on another arm board and it was fast
<ogra> hmm, uboot issue ?
<saeed> I'll check the boot
<saeed> yes
<ogra> seems a lot boards have issues with ext2 support in uboot
<NCommander> hey saeed
<saeed> which boards?
<NCommander> saeed: if thats the case, we can look at using vfat over ext2 for the next release cycle of Dove, but when I tried fat, it wasn't much better
<NCommander> saeed: vfat is also vey fragile :-/
<ogra> saeed, omap beagle definately ...
<ogra> saeed, and i had probs on imx51 too but we dont use uboot there
<ogra> just when testing it
<saeed> which uboot version?
<ogra> relatively new ones
<ogra> i need to look up the versions
<ogra> 2009.01 for imx51
<ogra> omap is 2010.3 (plus some omap specific git checkout)
<NCommander> saeed: I know filesystem support in u-boot has been vastly expanded since 1.3.4
<saeed> mm
<saeed> I don't recall that this issue occured in early uboot versions of dove, do you?
<NCommander> saeed: although it would be a downright pain to port a newer u-boot to Dove, won't it :-/
<NCommander> saeed: I remember the speed sucking from day 1 unfortunately. Its possibly gotten worse just because our initramfs grew
<Martyn> Oh boy
<Martyn> Today is ARM rumor central ...
<Martyn> Apple aquiring ARM?  Pffft .. neer
<Martyn> never
<ogra> Martyn, sure, you ddidnt hear that ?
<Martyn> The industry wouldn't -let- that happen ...
<ogra> will happen right after smoothstone aquired apple
<Martyn> Freescale, Marvell, and others have direct stake in ARM .. and they would lose out if Apple locked out the industry
<Martyn> So, I think it's just that .. speculation, rumor, driven by Apple's purchase of intrinsity .. no way would they spend >20% of their cash reserves
<Martyn> ogra : Yep.
<ogra> my suspicion is that they wanted to have something up against google buying Agnilux so they spread that roumor
<NCommander> saeed: BTW, it seems the newest gstreamer-plugins-marvell we got FTBFS :-/
<Martyn> maybe
<saeed> NCommander: please make sure Li know about it
<NCommander> saeed: will do, just happens our timezone skew really really sucks
<GrueMaster> lrg: Ping.  I was told you are working on alsa bits for freescale and marvell.
<NCommander> argh
 * Martyn is twiddling with the tegra2
<hrw> which image gives x11 on beagleboard?
<persia> hrw: have you tried either of the omap netbook variants?
<hrw> only when it did not support usb
<persia> Well, either try again, or use an image you know works, and install some desktop environment (e.g. apt-get install ^ubuntu-netbook)
<hrw> desktop rebooot time
<hrw> /nick/
<lrg> GrueMaster: yes
<GrueMaster> If you get a chance, do you think you could enable jack detection?
<GrueMaster> Not critical for Lucid, but would be nice to have,
<lrg> GrueMaster: on which platform ?
<GrueMaster> babbage 3 and dove.
<lrg> I have niether
<lrg> it's simple to add
<lrg> grep for jack in sound/soc
<lrg> there are quite a few examples
<GrueMaster> Ok, that's what I thought.
<GrueMaster> Thanks.
<lrg> and there is still time before the next merge window :)
<GrueMaster> It would have to go into an sru release.
<GrueMaster> But if I get time, I'll look into it.  Thanks.
<persia> GrueMaster: lrg: If it's only nice-to-have for lucid, it's still best to get it done, and pushed in this merge window, so that when the kernel team pulls for maverick, it's already there.
<lrg> persia: I agree, although I have not free time for implementation, but I will review and upstream if GrueMaster can provide a patch.
<GrueMaster> What is the time window?  I have a convention I am leaving for tomorrow, and won't be back until Monday.
<lrg> GrueMaster: well we are at 2.6.34-rc5 atm, so I'd say another few weeks
<GrueMaster> Ok.  I can probably work on it late next week.
<GrueMaster> This could be interesting.  I've worked on HD Audio side of alsa before, but not the SOC or AC'97 stuff.
<Martyn> plus one of the whole points of the new LTS system, is that it allows for real kernel updates
<Martyn> which is a nice changed policy
<persia> Well, kinda.
<persia> There's issues with that, and how far it can go,etc.
<persia> We'll see how it works, but *don't* expect that new upstream kernel releases will all magically drop into 10.04.x
<Martyn> persia : That it was accepted at /all/ is a good thing
<Martyn> because LTS releases are few and far between, they must be able to update and roll with the times
 * GrueMaster stopped using Redhat after 7.2
<GrueMaster> (before they said there was no future in Desktop Linux).
<hrw|gone> I use Debian since 1999
<jc_> hi
<persia> Hey.
<jc_> so is apple going to buy arm or not?
<jc_> i hope it doesn't stiffle any dev on ubuntu and arm....
<DanaG> Frankly, I don't trust Apple.
<DanaG> \][p
<DanaG> [iuaA-]
<DanaG> P-P
<DanaG> er
<DanaG> sorry, wiping keyboard.\
 * persia suspects there are better forums for speculation
<DanaG> though P-P looks like a funky smiley.
 * persia also suspects that it's unlikely that corporate ownership will significantly affect the ISA in the short term.
<videorechner> Mhm I like the idea, mac minis with arm cortex a9 MP, low power consumption and ubuntu can still be installed
<persia> Maybe.  There's issues related to that specific implementation of GPT in lucid, although they may be fixed in the future.
<asac> bug 561874
<ubot4> Launchpad bug 561874 in f-spot (Ubuntu) "NULL Reference exception in F-Spot (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/561874
<sveinse> Is there any here now who happens to have worked with JTAG against TI OMAP?
<persia> Anyone know if there is an existing bug number for both desktop-webmail and evolution being on ubuntu-netbook/armel ?
#ubuntu-arm 2010-04-23
<persia> Any core-dev's about?  bug #568736 would benefit from being approved for lucid, and milestoned.
<ubot4> Launchpad bug 568736 in netbook-meta (Ubuntu) "Having Evolution installed along with Desktop-Email is pointlessly redundant (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/568736
<cwillu_at_work> persia, this is an arm specific bug? :p
<persia> Yes, because desktop-webmail is only installed for armel by default.
<persia> One could safely argue that it makes sense for it to be default on all architectures, but that's a different discussion.
<DanaG> weird... neither networkmanager nor wicd will connect with my rtl8187.
<persia> That's unexpected.
<DanaG> X11 connection rejected because of wrong authentication.
<DanaG> Trying to run ssh-with-X.
<persia> Hrm.  It generally works for me if I ssh out of my X session into somewhere else, with the appropriate .ssh/config bits to pass X, and then run an X app.
<persia> Dunno if that's precisely how you're doing it.
<DanaG> I have forwardx11 and forwardx11trusted in .ssh/config
<DanaG> (capitalized properly there.)
<persia> Ought do it, really.
<DanaG> hmm, it's not working for me.  Weird.
<persia> Indeed.
<DanaG> oh, "no space left on device"
<DanaG> No wonder.
<DanaG> Would've been nice if ssh had told me that.
<persia> Heh.  That explains it.
<DanaG> Need bigger SD card -- 2 gigs is tiny.
<persia> We recommend 4G of available storage for a running system.
<persia> (or more).
<persia> It can (barely) fit in 2G, but one usually runs into issues.
<DanaG> hmm, what read and write speeds is the beagle itself capable of?
<DanaG> For example, why bother with a "class-10" card if it can't do class 10 speeds?... =Ã¾
<DanaG> weird... blueman won't let me use the pulseaudio plugin.
<DanaG> ValueError: invalid literal for int() with base 10: '21-63-gd3efa-dirty'
<persia> File a bug.
<persia> That *should* just work.
<persia> (and not working is a clear port failure)
<DanaG> https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/535446
<ubot4> Launchpad bug 535446 in blueman (Ubuntu) "[lucid] Blueman Pulseaudio plugin cannot be loaded (affects: 4) (heat: 24)" [Undecided,Confirmed]
<persia> Does the patch work for you?
<persia> Nifty.  Looks like I can upload that.  Tell me the patch works, and I'll put it in lucid.
<DanaG> I just edited the file manually, rather than patching it.
<DanaG> The patch seems to be for something different.
<DanaG> Now I just need to remember which audio port was line-out on the beagle.
<DanaG> I'm getting no audio on either port.
<persia> But your traceback matches the one in that bug?
<DanaG> Yes, the invalid literal for int()
<persia> Oh, xax200's traceback?
<persia> I think the patch is for mmbossoni's traceback
<persia> No, I'm confused
 * persia reads the bug again
<DanaG> Looks like the bug partly got highjacked?
<persia> By the original reporter, which makes it complicated.
<persia> "I noticed another problem" is the key phrase one never wants to see in a bug report.
<persia> xax200 seems to recommend small changes to lines 115 and 218 (comments 3&4).  Does that work for you?
<DanaG> I just changed the first one mentioned.
<DanaG> 115.
<persia> Right, which is a bit different than the patch in comment #5, which seems to be a different bug.
<DanaG> hmm, is there any way to get blueman to run without an X server?  Or a dummy X server?
<persia> xvfb?
<persia> Mind you, it might be tricky to press the buttons that way :)
<DanaG> Or I suppose I could run a real X server with just a blueman-applet.
<DanaG> argh, too dang many mixer controls...
<DanaG> now is it headset, or earpiece?
<DanaG> ah, maybe I do need that other bit of "int" change.
<DanaG> argh, pavucontrol over ssh controls the client's pulseaudio, not the server's.
<persia> heh.  pavucontrol is too smart :)
<DanaG> Dag-blast it, I need this PPA in armel:
<DanaG> https://launchpad.net/~blueman/+archive/blueman-dailies/+packages
<persia> apt-get source, sbuild -d lucid source.dsc
<persia> If that doesn't just work: `mk-sbuild lucid` should get you a nice clean buildd chroot.
<persia> And since we never managed to fix the command-not-found bug, install ubuntu-dev-tools to get mk-sbuild.
<DanaG> great, I'm tight on space as it is..
<persia> Well, you could build with qemu.
<persia> Do you have a lucid x86 system available?
<persia> (or can you make one)
<DanaG> I do have lucid (amd64, rather).
<DanaG> It's easier just to go out and get a bigger SD card.
<DanaG> =Ã¾
<persia> IF you like.
<persia> Installing ubuntu-dev-tools, sbuild, and qemu-extras-static on your amd64 machine lets you run `mk-sbuid --arch=armel lucid` which generates an emulated lucid chroot for building stuff.
<persia> You can then run `sbuild -d lucid-armel foo.dsc` to generate lucid armel binaries on your host.
<persia> I've had a couple issues with some mono packages, but most stuff seems to just work.
<DanaG> oooh, I got bluez to segfault.
<DanaG> what's a really, really tiny window manager (just needs to be able to change focus and move windows)?
<DanaG> tinywm
<DanaG> oh guawd, bluetooth audio streamed to the beagleboard works hilariously poorly.
<DanaG> Picture taking an audio stream, chopping it into tiny bits, then chipmunkifying and looping those bits.
<DanaG> Changing the resampler to speex-fixed-0 seems to have worked.
<persia> Oh my.
<DanaG> Interesting... changing it to speex-fixed-0 worked so well, in fact, that it works better than when I try to do the same between two x86 systems.
<DanaG> On those, I get an assertion failure, and pulseaudio aborts.
<persia> file a bug :)
<DanaG> Can't do it with apport. =Ã¾
<persia> Why not?
<DanaG> Upstream ticket, by the way: http://www.mail-archive.com/pulseaudio-tickets@mail.0pointer.de/msg02912.html
<DanaG> Apport "does not support" reporting assertion failures.
<persia> Ugh!
<DanaG> oh yeah, better than speex-fixed-0 is src-linear
<DanaG> ...maybe.
<persia> You'll find it eventually :)
<DanaG> Okay, linear is the only usable one.
<DanaG> well, that, and fixed-0.
<DanaG> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/358831
<DanaG> old
<ubot4> Launchpad bug 358831 in pulseaudio (Ubuntu) (and 1 other project) "[ARM] Pulse Audio eating up to much CPU" [High,Invalid]
<persia> Are you running a distro kernel?  If so, please file a new bug.
<DanaG> interesting... speex-float-1 works.
<DanaG> Surprisingly well.
<persia> That old bug got marked invalid because someone filed with with random vendor HW and random vendor kernel, and it's not clear if the issue can be replicated in Ubuntu.
<DanaG> Yeah, I figured as such.
<DanaG> Wow, float-1 works really well.
<DanaG> 55% CPU usage, though.
<DanaG> And granted, bluetooth is an extreme use case. =Ã¾
<persia> That needs a bug.  Might or might not get a fix, but if it's replicable on known HW/kernel there's a chance that someone can work on it.
<DanaG> Network streaming with pulseaudio native works really well with the default resampler.
<persia> Not really.  Lots of folk have made noises about running Ubuntu on an N900 or similar, where bluetooth is a common function.
<cwillu_at_work> those resamplers would benefits from being rewritten for neon if they aren't already
<persia> cwillu_at_work: Feeling bored today?  Want to dig in?
<persia> :)
<cwillu_at_work> persia, I've been at work for 20 hours today :p
<persia> That would be "no" then :)
<cwillu_at_work> on the other hand, my sd cards _almost_ boot on c3, c4 beagles and overos :p
<persia> What bit doesn't work?
<cwillu_at_work> the bit where it boots :p
 * persia thought the standard images just worked on C3/C4
<cwillu_at_work> I'm not using standard images
<persia> Oh, what are you changing?
 * persia is wondering how much of the standard-image-build-stuff can be leveraged
<cwillu_at_work> the overo is the source of my grief, and it looks like I fried something on the serial level shifter
<persia> Ouch!
<DanaG> persia: my use case is not streaming from ARM to a headset... but the other way around...
<DanaG> streaming from one computer to the beagle over BT.
<cwillu_at_work> I've got a hacked up rootstock, so it's basically just a standard deboostrap + extra scripts
<persia> DanaG: Do you expect that pulse performance differs based on the direction of the stream?
<cwillu_at_work> I can see the uboot prompts, but it sends garbage constantly, so I can't get _past_ the uboot while serial is plugged in
<DanaG> I'm not sure... my only regular non-PC headset device is my FreePulse headset... and the power button on it has failed.
<persia> And you can't see what you're doing when serial isn't attached.  Yeah.  That makes it hard.
<cwillu_at_work> and I only have two sd card readers, and they're both tied up writing out btrfs images at ~50kb/s
<DanaG> icantbelieveitsnotbtr?
<cwillu_at_work> DanaG, already saved my ass a couple times; I really really hate sd cards, and I really really hate driving four hours to replace one
<cwillu_at_work> checksumming + metadata mirroring ftw!
<DanaG> Hmm, how stable is the on-disk format for btrfs?
<cwillu_at_work> pretty much completely
<DanaG> Can you convert from ext4 with extents?
<cwillu_at_work> the occasional forward transition, but they're not mucking with it
<cwillu_at_work> yep
<cwillu_at_work> there's still a bunch of corner cases you have to be aware of though
<DanaG> For now, I've been using ext4 with data=journal, since I value data integrity and the ability to recover from just plain unplugging... over the lifespan of SD cards.  At least, that's true of this 2-gig card.
<cwillu_at_work> i.e., determining how much free space is non-trivial, and it behaves fairly badly if you run out
<cwillu_at_work> see, journalling doesn't get along with sd cards
<DanaG> Hmm, I may stick with ext4 for now... though a good point: I should make a DD image, if nothing else, of the card.
<cwillu_at_work> and let me assure you that fsck does more harm than good if the journal goes kabloiee
<DanaG> hmm.
<DanaG> So am I better off with no journal?
<cwillu_at_work> you're better off with a keen understanding of how filesystems work and how crappy sd cards handle corner cases :)
<cwillu_at_work> but yes, no journal is preferable
<cwillu_at_work> At least, unless you're sure that your particular card behaves reasonably well regarding wear levelling (although they're all crappy, these aren't ssd drives) and power loss
<DanaG> Ah.  Hmm, then I need to find what tune2fs option to set...
<cwillu_at_work> specifically, most/many/some cards handle things _really_ badly if they lose power while they were writing; it's not the clean case that a journal handles, you can lose data that you weren't even writing to
<DanaG> Ugh.
<cwillu_at_work> hence my current love of btrfs:  it can tell you if things are corrupted and exactly how corrupted they are
<DanaG> Login incorrect.
<DanaG> Give root password for maintenance
<DanaG> (or type Control-D to continue):
<DanaG> I press ANYTHING ... even ctrl-d, it loops back to there.
<persia> How did you get there?
<ogra> did you have an fsck ?
<persia> Yeah, you have to have a password.
<DanaG> I think I did have one.
<cwillu_at_work> you guys haven't fixed that yet?
<ogra> cwillu_at_work, release managers are hard to convince sometimes :)
<DanaG> I'd been trying to get the udisks-over-ssh working... but it kept giving "stdin: is not a tty"
<persia> cwillu_at_work: Fixed which?
<ogra> still working on it
<ogra> persia, bug 563618
<ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
<persia> Oh, that one.  Yeah.
<cwillu_at_work> persia, the arm images having the root account locked rather than simply a deleted password like the rest of ubuntu's archs
<cwillu_at_work> passwd -d root
<ogra> (it doesnt always result in reboots)
<ogra> cwillu_at_work, they dont
<cwillu_at_work> DanaG, passwd -d root the next time you're in to make it work right :p
<DanaG> Thanks.  I'm just doing fsck on my host, for now. =Ã¾
<ogra> cwillu_at_work, dont mix up "arm images" with rootstock built rootfses
<persia> cwillu_at_work: I have disabled password on amd64/powerpc.  Are you sure?
<cwillu_at_work> ogra, my bad;
<ogra> ;)
<cwillu_at_work> hence my hacked up rootstock :p
<ogra> cwillu_at_work, and you still havent filed a bug :)
<persia> Take care with that: there's no guarantee that rootstock generates a policy-compliant install.
 * ogra will happily pull that into an SRU
<cwillu_at_work> pretty sure I did actually :p
<ogra> https://bugs.edge.launchpad.net/project-rootstock/+bugs https://bugs.edge.launchpad.net/ubuntu/+source/rootstock ... neither has it
<DanaG> http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=12454&prodSeriesId=4063703&prodNameId=4063704&swEnvOID=4030&swLang=13&mode=2&taskId=135&swItem=vc-78398-1
<DanaG> HP actually uses Debian on some Marvell thingy.
 * cwillu_at_work checks his bug list
<persia> Doesn't surprise me much.  HP used to ship a live Debian CD as their rescue environment back when I did server farm management.
<DanaG> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/566238
<ubot4> Launchpad bug 566238 in linux-ti-omap (Ubuntu) "wlan0 "Interface doesn't support scanning." -- CONFIG_CFG80211_WEXT is not set (affects: 1) (heat: 6)" [Undecided,New]
<DanaG> Heat?
<cwillu_at_work> hawt
<persia> It's a new metric the LP guys added to help identify which bugs are interesting.  So far, I haven't seen it provide interesting information, but I understand they are tuning the algorithm.
<lool> It's the number of times the page is loaded
<lool> It's a very often used metric amongst web developers
<lool> The number of heats of a page gives a good idea of its popularity
<persia> It's more complex than that.  It takes into account *who* loads it, etc.
<persia> And who files it, what status it is, etc.
<persia> (or else someone gave me wrong information)
<lool> persia: I was kidding actually  :)
<lool> hit versus heat
<lool> I did fail at making it sound like a joke it seems!
<persia> But it's one of those rare jokes that's funny *after* it's explained :)
<persia> (but I'm in end-of-day mode, and so a bit humour impaired just now)
 * ogra_beagle waves from a successful netbook install 
<persia> \o/
<ogra_beagle> only the clock issue left
<ogra_beagle> and htop shows a moderate 174M being used
<ogra_beagle> (only xchat, one terminal and desktop up though)
<cwillu_at_work> which clock issue?
 * cwillu_at_work strongly recommends buying the lithium battery for the beagle
<ogra> cwillu_at_work, bug 563618
<ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
<cwillu_at_work> ogra, keep your computer plugged into the network :)
<ogra> cwillu_at_work, by default the board comes without, i want the images to work on a default config ... fsck needs fixing and will get fixed but that wont happen for lucid
<cwillu_at_work> or do what I do (on the boards that don't yet have lithium batteries):
<ogra> network wont help
<cwillu_at_work> use a filesystem that doesn't have a working fsck :)
<ogra> network isnt up when fsck is run
<ogra> nah, we will fix it properly
<ogra> for now it has to be a workaround though
<ogra> but i'm still waiting for release manager approval
<ogra> ted tso already agreed on fixing it right in fsck
 * ogra thinks he earned some breakfast before setting up the installation wikipages 
<ogra> bbl
<amitk> ogra_cmpc: what address in the nand do you write the boot.scr, kernel, initrd to? (sd install)
 * cwillu_at_work jumps
<cwillu_at_work> first image finished umounting!
<cwillu_at_work> now if only I knew which reader was sdh and which was sdd so I don't panic the kernel removing the wrong one :p
<ogra> amitk, ??
<ogra> amitk, i write to mtdblock devices
<ogra> no special addressing
<amitk> ogra: if i wanted to change the boot.scr, how would I do that?
<ogra> after install ?
<amitk> yes
<amitk> to get rid of the POS splash and get back serial console
<ogra> sudo fw_printenv and fw_setenv
<amitk> ogra: ah, nice
<ogra> sudo fw_setenv bootargs "your boot args"
<ogra> similar to redboot-cmdline
<amitk> nice integration! perhaps too simple :)
<ogra> heh
<ogra> asac, welcome to the "league of old farts" and ******** H A P P Y   B I R T H D A Y ! ! ! ! ! ! ! ! ! ! *********
<DanaG1>  /dev/disk/by-id is useful.
<DanaG1> or /dev/disk/by-path
<NCommander> eggonlea: you around?
<dmart> ogra: hi there
<ogra> hey
<dmart> Just saw your comment in https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/563618
<ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 5 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged]
<ogra> yup
<ogra> its still not approved :/
<dmart> How would I set up a branch with the extra code to test?
<ogra> and the longer it takes the less likely it will be we'll get it in
<ogra> branch from my branch, edit the script file i added, copy hook and script in place on your board, run update initramfs and try it
<ogra> (and indeed make sure the clock is wrong and mount time of the disk is in the future :) )
<dmart> Er, what's a branch?  Are we talking bzr or launchpad here, or something else?
<ogra> i linked a bzr branch to the bug
<ogra> lp:~ogra/initramfs-tools/initramfs-tools-fixrtc
<dmart> Unfortunately, I don't really know how to use bzr yet...
<dmart> My suggestions were "nice to have"â we could skip those if it's a problem.
<ogra> https://code.edge.launchpad.net/~ogra/initramfs-tools/initramfs-tools-fixrtc says at the top what to do
<ogra> bzr branch lp:~ogra/initramfs-tools/initramfs-tools-fixrtc
<ogra> cd into the newly created dir ... cd to scripts/local-premount ... edit fixrtc
<ogra> if the change is good: bzr commit -m 'your commit message'; bzr push lp:~dmart/initramfs-tools/initramfs-tools-fixrtc and add the branch to the bug
<dmart> Does the bzr push create a new branch owned by me?
<persia> If you push to that location, yes.
<persia> IF you push to an existing branch (to which you have write permission), no.
<dmart> so lp:~dmart/initramfs-tools/initramfs-tools-fixrtc gets made if it doesn't exist yet?
<ogra> the hook needs to go into /usr/share/initramfs-tools/hooks and the script into /usr/share/initramfs-tools/scripts/local-premount before calling update-initramfs -u (make sure both are executable)
<persia> RIght.
<ogra> right
<dmart> ok... I will have a go
<ogra> oh, indeed ~dmart needs to be your LP id
 * ogra just noticed its not dmart :)
<dmart> I should maybe change it sometime, but yeah.  I can probably work that one out :)
<ogra> :)
<persia> No need to change it: just make sure your nick is registered on LP, and folks can find you from launchpad.net/people
<persia> Also, once you start publishing branches and having a PPA, changing the name is hard.
<dmart> ogra: is scripts/local-premount/fixrtc sourced or exec'd ?
<ogra> exec'd
<ogra> (thats why it has a shebang)
<dmart> (doesn't always follow)
<dmart> Is it worth quitting the script if we didn't find root= ?
<ogra> heh
<dmart> (though it's unlikely)
<ogra> if we dont find root= we have bigger probs
<dmart> true - probably not worth it yet
<dmart> ogra: Do we have e2fsck.conf in the initramfs?
<ogra> nope
<ogra> and it wouldnt help anyway
<dmart> Just wondered if we could default to the fixrtc behaviour if the broken rtc option is set.
<ogra> no
<dmart> But this is a hack anyway...
<dmart> so it doesn't matter too much
<ogra> right, you would need to create an e2fsck.conf and set the parameter etc
<ogra> well, its the right fix once we have an actual option in fsck
<ogra> if thats there in maverick i'll make the installer create an e2fsck.conf
<ogra> but with the existing option not working its moot
<dmart> Can the e2fsck.conf be grabbed from /etc when making the initramfs?  That way whatever the admin configures would be used
<ogra> i think thats happening already
<ogra> if not i'll make sure it happens in maverick
<ogra> in any case the option needs to be fixed first
<ogra> we'll have to wait for upstream to fix that
<dmart> What happens if this script terminates with non-zero exit status?
<persia> Make it not do that.  Use ||true if necessary.
<dmart> I want to use set -e, since if dumpe2fs fails or something else goes wrong, we may accidentally set the clock to junk...
<persia> I believe it dumps when it fails.
<persia> Is it possible to do sanity checking and set the clock to the epoch if we can't get useful data?
<ogra> depends what you mean by epoch :)
<dmart> What kind of sanity-check do you suggest?
<ogra> the beagle epoch is 01-01-2000 ... i'm not sure if you could even set the clock to an earlier date
<persia> dmart: e.g. make sure the date is set to something between 1970 and 2038.
<ogra> dont put so much effort into that hack
<ogra> and dont make it to big
 * persia doesn't want set -e + the hack to make systems unbootable
<ogra> s/big/complex/
<dmart> date --set will barf if the supplied textual date won't fit in time_t
<ogra> persia, they are unbootable already
<dmart> so we just give up (which may be the best thing)
<dmart> We shouldn't make any otherwise bootable cases unbootable
<ogra> and if you want to not use the fix, just drop fixrtc from the cmdline
<persia> Fine.  I don't like it because it's not elegant, but I agree it makes sense to do it right later.
<ogra> right, the hack is temporary anyway
<dmart> This is a bodge in advence of the real fix (which is to make e2fsck less picky about the clock)
<ogra> exactly
<ogra> and upstream is aware and agreed to fix it already
<dmart> The other way to work round the issues is mount -o remount,rw / ; mount -o remount,ro /
<dmart> (but this is obviously not a great idea if the root fs might be damaged)
<ogra> i think that will slow down your boot significantly
<persia> Not "less picky", but rather "handle the case where the clock has been reset"
<ogra> i was already hitting a race with setting the date to the proper time and needed to add a minute if you mount and remount you will likely have to add sleeps
<ogra> or at least wait until mount is done
<dmart> iiuc, ext[2-4] fs filesystem integrity does not depend on the integrity of the clock.  I think e2fsck has some clock-based heuristics for sorting out filesystem errors, but that's only an issue if the filesystem is actually broken
<ogra> right, the prob is that fsck doesnt handle the case properly
<dmart> dmart: but we should let upstream have the final say, of course
 * dmart is talking to himself now...
<ogra> heh
<ogra> dpkg-buildpackage: host architecture armel
<ogra>  /usr/bin/fakeroot debian/rules clean
<ogra> debian/rules:39: *** atlas doesn't build on arm, not terminating on the buildd.  Stop.
<ogra> dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules clean gave error exit status 2
 * ogra shakes his head
<ogra> i wonder if the packager every heard of the Yrchitecture field :P
<ogra> *Architecture
<dmart> ogra: can you take a look at http://pastebin.ubuntu.com/420963/
<ogra> dmart, looks fine, tested already ?
<dmart> I have tested "by diff" -- replacing $(cat /proc/cmdline) with $(echo) and prefixing the date and hwclock commands with echo to check that they are run at the right times and with the expected arguments
<dmart> is that enough?
<dmart> otherwise, how to I set up the initramfs?
<ogra> well, i'd like to hear that a boot succeeds with different root= cmdline options on a system that exposes the issue
<ogra> <ogra> the hook needs to go into /usr/share/initramfs-tools/hooks and the script into /usr/share/initramfs-tools/scripts/local-premount before calling update-initramfs -u (make sure both are executable)
<dmart> OK, I'll try it
<ogra> (and you need to set fixrtc on the cmdline indeed)
<dmart> yeah
<dmart> thanks, I probably would have forgotten ;)
<ogra> heh
<dmart> blaargh, guess what?
<dmart> (forgot fixrtc)
<ogra> lol
<dmart> ogra: hi there
<ogra> hey
<ogra> works ?
<dmart> I think it mostly works
<ogra> mostly ?
<dmart> But dumpe2fs and its libraries appear to be missing from the initramfs
<ogra> did you copy the hook in place before running update-initramfs -u ?
<ogra> needs to go to /usr/share/initramfs-tools/hooks and needs to be executable
<dmart> Ah, hold on a minute --- what is "the hook"?
<ogra> http://bazaar.launchpad.net/~ogra/initramfs-tools/initramfs-tools-fixrtc/revision/182
<ogra> hooks/fixrtc
<dmart> ah, oops
 * ogra kicks the wiki
<dmart> right, updating the initramfs again...
<dmart> ah, better
<dmart> Well, we still have the issue that if the clock is only intermittently corrupted across boot, we always break it (by resetting it based on the last mount time)
<dmart> But since this is only for broken systems anyway, that's probably OK
<dmart> The clock should never be seen to go backwards
<dmart> And ntp should patch things up
<ogra> right
<ogra> and you wont need it at all if you never pull the power plug :)
<ogra> ok, if it works fine, please note that on the bug and point to your branch (and link the branch to the bug (top right there is an option))
<dmart> When bzr committing, how to I get the committer name and email right?
<dmart> I'm working on a dev board, so those are garbage
<dmart> ...or will launchpad patch it up?
<persia> bzr launchpad-login will help
<persia> bzr whoami will do the rest of it
<persia> LP won't get it right based on your ssh keys, for complex reasons (you might be pushing someone else's commits, etc.)
<dmart> ok, done
 * dmart 's ignorance has decreased
<dmart> (slightly)
<dmart> thanks for the pointers
<persia> That's why we're here.  Thanks for helping work on the bug.
<dmart> I'll know for next time... lp+bzr is still rather a mystery for me ;)  Are there any good docs floating aroung?
<dmart> around
<dmart> ogra: done (in case you didn't see)
<ogra> i did
<persia> Docs?
 * persia digs some up
<ogra> thanks a lot !
<persia> dmart: https://help.launchpad.net/Code isn't a bad place to start.
<dmart> cool, thanks
<ogra> https://wiki.ubuntu.com/ARM/Beagle
<ogra> finished :)
<ogra> anyone who wants, feel free to improve/enhance
<persia> You know we have a Qt/plasma variant as well, right?
<persia> Has anyone installed that?  Does it work OK on the Beagle?
<ogra> no idea
<ogra> i dont think we build it
<rcn-ee> quick, glance it looks good ogra...
<persia> http://cdimage.ubuntu.com/kubuntu-netbook/ports/daily-live/current/lucid-netbook-armel+omap.img
<ogra> oh, we do build it
<ogra> yeah, just saw that
<ogra> no idea, i wont have the time
<ogra> s/have/take/
 * persia tries to find out if it passed RC testing
<ogra> i'll put info that it exists in the blog post i'll write soon
<ogra> probably someone in the community wants to test it
<ogra> (if the KDE ubiquity doesnt OOM anyway that is :) )
<persia> Yeah, didn't get into the RC testing, so there's no record if anyone tried it.
<persia> That's my thought.
<ogra> omap didnt get into the RC testing at all
<persia> I know it works for dove/imx51 (it passed RC testing)
<persia> But those have more RAM.
<ogra> its fully voluntary even for release for 10.04
<persia> I didn't think it was even schedued for formal release, but just that we'd have cdimages.
<ogra> right
<persia> Anyway, I don't have a Beagle, so I can't know.  Anyone with a Beagle up for seeing if that image boots?
<ogra> given there is no EFL launcher for kubuntu-netbook i really doubt it will work
<ogra> qt-ubiquity will probably run though
<persia> plasma-netbook is designed to be lightweight though.
<ogra> not as light as efl though
<ogra> and even that is close to the edge on beagle
 * persia refuses to argue about toolkits
<ogra> heh, that wasnt my intention :)
<suihkulokki> xaw3d xaw3d!
<ogra> yeah !
<ogra> thats a 3d toolkit that works everywhere at least !
<persia> Isn't Beagle specs similar to n810?
<ogra> persia, well, kubuntu is still at 20.1 that wont work anyway
<suihkulokki> beagle is more powerful than n810
<ogra> it needs a build from 22
<ogra> else the flash-kernel fixes are missing
<persia> Oh.
<persia> Are image builders still on manual?  They should probably get turned on for the weekend.
<ogra> i think they might stay on manual
<ogra> ask steve
<NCommander> lool: why'd you upload kexec-tools to ~canonical-arm-dev/marvell-dove-public?
<lool> NCommander: for testing
<lool> NCommander: Because I needed public armel builds before pushing to the arcihve
<lool> NCommander: can be dropped now
<NCommander> lool: fair enough. I just didn't expect to see it there
<lool> NCommander: I checked with other people before doing it -- note that it affected dove too
<NCommander> lool: not a problem, was just curious
<lool> removed
<ogra> lool, https://wiki.ubuntu.com/ARM/Beagle
<ogra> feel free to test :)
<lool> Favoriten
<lool> lol
<lool> BÃ¼ro!
<ogra> yeah, i need to add an english screenie once i have an english install :)
<ogra> will do that before final :)
<lool> Should be Software-Zentrum!
<ogra> LOL !
<lool> ogra: You want the bootloaders links I guess
<ogra> i havent written that yet
<ogra> you mean how to install uboot to nand etc, right ?
<ogra> or put MLO on your fat
<ogra> i'll do that over the weekend, for now i wanted to have the general pages ready
<ogra> since i want to blog it to get some attention
<lool> ogra: I mean links to working bootloaders
<lool> ogra: how to flash them etc.
<ogra> yes
<lool> ogra: because people might be stuck if they don't load boot.scr
<ogra> havent got that yet
<ogra> its all on the elinux wiki and i assume beagle users know that
<ogra> they will survive over the weekend :)
<ogra> or come here and complain ;)
<rcn-ee> lool, boot.scr's are pretty much the default on the beagle elinux land .. ;)
<lool> ogra: netbook install points at server image
<lool> "Get the lucid-server-armel+omap.img image"
<ogra> rcn-ee, but you could have changed your uboot setup (which is why i have the "how to load a boot.scr from serial prompt" part in all the installation pages)
<lool> fixed
<ogra> thanks :)
<ogra> oops
<ogra> luckily the link was ok
<rcn-ee> yeap..  as long as you go over how to flash u-boot and change things, that'll cover those issues...
<ogra> right
<ogra> i still have a week to shake out all the docs
<lool> ogra: Ideally, but together a SD card image with just x-loader + u-boot and a default config which just flashes the board
<lool> So that people basically boot with it, and it flashes their NAND as appropriate
<ogra> thats just a start, i'm sure questions will come up that show wheer we need additional documentation
<rcn-ee> lool, like https://code.launchpad.net/~beagleboard-kernel/+junk/omap-flasher ;)
<ogra> haha
<ogra> rcn-ee, i'll link that on the flasher page :)
<lool> ogra: https://wiki.ubuntu.com/ARM/BeagleEditBootscr is awful
<rcn-ee> oh great... i got tired of doing the commands my self.. so i scripted it..
<lool> ogra: can't we just ship boot.script in the image?
<ogra> lool, what dont you like about it ?
<lool> the dd
<ogra> lool, i wont change debian-cd anymore now
<rcn-ee> yeah the dd is different.. i never thought about doing that.. but it works...
<ogra> we can ship it in 10.++
<ogra> lool, there is a lot of awful stuff about that image that needs to improve
<ogra> its a first hit
<ogra> created in a week
<ogra> dont expect shiny :)
<persia> Rather, expect shiny, because that's interface, and shared, but don't peer under the sleek shiny cover too much.
<rcn-ee> It look's fine and will work for most people...  the others always do what they want anyways..
<ogra> rcn-ee, there are a lot of things i could have done better and i know lool will die if he looks into details :)
<ogra> but there is always 10.++
<ogra> which will fix that
<rcn-ee> laughs, i just hope he doesn't look into my Netinstall hack..  Probally cringe and never look at any of patches.. ;)
<rcn-ee> and we'll have the XM for 10.10 ;)
<persia> Don't get too excited: that just means we have that much more work to do to create a boot script that can somehow boot on more platforms.
<rcn-ee> well my script, currently boots Bx, Cx and my proto Xm.. ;)  if only the kenrel didn't bomb on the xm... I'm hoping enough kernel bits for the Xm hit mainline that omap can share the ubuntu kernel..
<persia> Well, there's currently a special omap kernel in Ubuntu, but yeah, extra points for getting into the "normal" ports kernels.
<rcn-ee> just for reference, the XM uses a new omap3 similar core, DM3730 but the kernel bits are in a ti staging repo...
<lool> rcn-ee: public?
<rcn-ee> yeap.. as i dig for the link...
<lool> rcn-ee: it's good
<lool> just knowing it's public is enough
<rcn-ee> http://arago-project.org/git/people/sriram/ti-psp-omap.git?p=people/sriram/ti-psp-omap.git
<rcn-ee> *okay heads to work, but will be back, i enjoy half fridays.. ;)
<ogra> http://ograblog.wordpress.com/2010/04/23/unleash-the-beagles/
 * ogra had some issues to get the utf-8 right on lool's name :)
<lool> rcn-ee: Do you know what comes with the digikey beagleboard?  cant figure whether it has power adapter
<ogra> ndec, http://ograblog.wordpress.com/2010/04/23/unleash-the-beagles/
<gduarte> hello ogra
<ogra> gduarte, hey
<gduarte> :D ogra, do you know where i can download (if exist) a pre-compiled qemu-arm image to use directly with qemu
<gduarte> ?
<gduarte> I'm trying for 3 days without success
<ogra> nope, but if you follow the https://wiki.ubuntu.com/ARM/RootfsFromScratch page you can create one
<gduarte> yep
<gduarte> I've tried it, no success
<ogra> what was the issue ?
<gduarte> I'm trying it right now http://people.canonical.com/~ogra/arm/qemu/README
<ogra> oh, thats ancient
<gduarte> but don't know if it is the same thing
<ogra> dont use that
<gduarte> ahhh
 * ogra needs to clean up his homedir
<ogra> what did not work with https://wiki.ubuntu.com/ARM/RootfsFromScratch ?
<gduarte> my problem is when I try to log in into my emulated system
<gduarte> i type my login, but it's no recognized
<gduarte> never
<gduarte> and followed by filesystem issues
<ogra> what is your host system ?
<gduarte> Ubuntu 9.10 amd64
<ogra> hmm, ok
<ogra> you can install qemu-arm-static there and chroot into your image to fix it up
<gduarte> ok :D I'll be able to compile my programs there?
<ogra> yes, but it is as slow as a VM
<gduarte> no problem ;) thank you ogra
<ogra> after you installed qemu-arm-static, loop mount the image and cp the qemu-arm-static binary into <mountpoint>/usr/bin/
<ogra> then you can just chroot
<gduarte> ok ok,  I'll do it
<persia> GrueMaster: Did you get a chance to test kubuntu-netbook on imx51/dove?
<GrueMaster> I'm just now loading it on imx51.  Already hit a few minor issues.
<asac> ogra: plars: GrueMaster: persia: NCommander: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
<asac> dyfet: ^
<persia> OK.  freeflying and Riddell were wondering if it got tested in #kubuntu-devel, and I misread "netboot" as "netbook" on the kubuntu page before, so had the wrong information :(
<asac> maybe check out if i missed something in the summary that you want to have there
<gduarte> ian_brasil : are a ARM developer from Brasil?
<gduarte> **are you
<NCommander> asac: looks good.
<persia> fpc moved to SRU :(
<ian_brasil> well i am from Brasil :)
<NCommander> persia: sorry, I didn't get to that >.<;
<ian_brasil> well strictly speaking I am not Brazilian but i live in Brazil
<asac> persia: thats a really old bug. no progress. if we had a fix today we can resurrect it for final maybe
<persia> NCommander: No worries.  THe issue is that it only doesn't work for the folks that are able to bootstrap.  Works for the folks that wanted it to happen :)
<ian_brasil> ah, he left
<persia> asac: It's an old bug because doko decided to hijack the powerpc bootstrap bug to bootstrap armel.
<persia> (not that I'm complaining, because it made powerpc get bootstrapped, but ... )
<ogra> asac, looks all good to me
<persia> asac: You might want to beg again for bug #538736 if you don't like the current answer
<ubot4> Launchpad bug 538736 in vm "Filename encoding for external viewer inconsistent (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/538736
<persia> NO.
<persia> bug #568736
<ubot4> Launchpad bug 568736 in netbook-meta (Ubuntu Lucid) (and 1 other project) "Having Evolution installed along with Desktop-Email is pointlessly redundant (affects: 1) (heat: 12)" [High,Won't fix] https://launchpad.net/bugs/568736
<ogra> asac, slangasek promised to review bug 563618 right after the meeting, we should make sure to tickle him so he doesnt forget again :)
<ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 5 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
<asac> ogra: its on the list
<asac> ogra: e.g. on the list of still final targetted bugs
<ogra> yeah, saw that
<cwillu_at_work> rcn-ee, poke poek
<cwillu_at_work> question for ya :)
<cwillu_at_work> http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/revision/57
<cwillu_at_work> which of your kernels is that patch in?
<gduarte> ogra: sorry for annoying you again
<gduarte> but
<ogra> shoot
<gduarte> I'm having this problem
<gduarte> I: Creating temporary Image
<gduarte> I: Mounting temporary Image
<gduarte> I: Running first stage
<gduarte> sudo: unable to cache gid, already exists
<gduarte> I: First stage install done
<gduarte> /usr/bin/rootstock: 572: cannot create /tmp/tmp.x3pBJdpxDE/tmpmount/etc/fstab: Directory nonexistent
<gduarte> in another machine
<ogra> can you pastebin the logfile somewhere ?
<ogra> it should have cerated one on exit and tell you where that lives
<gduarte> ok
<ogra> and the version of rootstock to use as well as the complete command you call to run it would also help
<gduarte> it's not creating a log file
<ogra> s/to use/you use/
<gduarte> sudo rootstock --fqdn ubuntu-arm-dev --login ubuntu --password ubuntu --imagesize 2G --seed xubuntu-desktop
<gduarte> this is the command
<ogra> that should be fine
<ogra> could it be that your disk is full ?
<gduarte> yes, but isn't working
<gduarte> no, i'ts not full
<cwillu_at_work> gduarte, do you have a million loop mounts showing up if you type "mount"?
<ogra> right, that was my next question
<gduarte> I'll check
<gduarte> no, no loop devices mounted
<ogra> and its directly going from "I: Running first stage" to "I: First stage install done" just with that one line inbetween ?
<gduarte> no
<gduarte> I'ill past at pastbin
<gduarte> I'll*
<gduarte> **paste
<gduarte> http://pastebin.com/Su3gmYEB
<gduarte> there
<gduarte> saw?
<ogra> gduarte, so how did you install rootstock
<gduarte> apt-get
<gduarte> sudo apt-get install rootstock
<ogra> hmm, weird
<gduarte> this way
<gduarte> :(
<ogra> is debootstrap installed ?
<ogra> i dont get why it doesnt seem to run it at all
<gduarte> ye, it's installed, is downloaded together with rootstock when run apt-get
<ogra> right
<ogra> but it isnt executed at all
<ogra> thast very weird
<ogra> *that's
<gduarte> unlucky
<ogra> qemu-kvm is installed as well ?
<gduarte> yes, it's also installed together with rootstock
<ogra> right, and qemu-img seems to run fine since it shows I: Mounting temporary Image
<ogra> but your first stage does definately not run
<ogra> (which is debootstrap)
<gduarte> :S
<gduarte> I really need it, because I need to compile and package to ARM
<ogra> might be an amd64 issue in karmic
<gduarte> it's my exam to be hired to canonical :(
<ogra> try the following: "sudo debootsrap --arch=i386 lucid $HOME/lucid-i386" that will give you a lucid i386 environment
<gduarte> ok
<ogra> chroot into that and you shopuld be able to install rootstock and run it under i386
<gduarte> it's retrieving packages
<ogra> yeah
<gduarte> would be nice if would exist a default image to everybody download and modify
<ogra> we might provide something like that in maverick
<ogra> though the tools got a lot better in lucid already
<ogra> i know there were qemu related issues in karmic
<ogra> on amd64
<gduarte> :(
<orbarron> hey all... I was thinking about registering a blueprint for a Mobile Ubuntu user interface (mo-buntu). The main idea would be creating a better mobile experience for "phone like" devices. Does anyone know if something like this is in the works for lucid? -- any feedback?
<ogra> orbarron, there is some QT based work ian_brasil works on iirc (not sure how much phone based that is)
<ogra> might be somewhere between netbook and phone rather
<ogra> beyond that i dont know whats planned for UDS
<ian_brasil> we will integrate ophono
<ian_brasil> so it will be phone based
<ian_brasil> obarron..look at https://blueprints.launchpad.net/ubuntu/+spec/mobile-liquid
<orbarron> ahh thanks...
<ian_brasil> orbarron: there are likely to be some discussions at UDS about this - how to sanely break down kdelibs mainly if you are interested
<lool> ian_brasil: ofono :)
<ogra> haha
 * ogra read that typo somewhere today already
<lool> yep, asac
<asac> ian_brasil: cool. can we have a call on your ofono experiences etc.?
<asac> not today. but next week?
<asac> or we can chat, but my hands are getting lamer every day i continue to do that ;)
<ogra> asac, thats the raising age :)
<ogra> (i wished you a happy b-day this morning in case you havent seen it)
<asac> ogra: i saw ... i tried to ignore it for obvious reasons. thanks for spreading it to the world ;)
<ogra> lol
<asac> but its over soon enough ;)
<ian_brasil> asac: let me ping some people then
<asac> and /me will get off now for a bit anyway
<asac> ian_brasil: cool. lets talk on monday?
<ogra> yeah, enjoy your evening
<asac> (i am mostly out)
<asac> thanks!!!!
<ogra> and stay away from the kbd !
<asac> i will i will
<asac> ogra: remember to submit your blueprints against ubuntu-arm ;)
<ogra> if i could rememebr the blueprints i had done it already ... i need to look them up
<ian_brasil> asac: cool
<ogra> but i'm waiting for slangasek anyway
<gduarte> ogra: I got it!!!!!
<ogra> wonderful
<gduarte> it's basic, no gcc, no X,  some few FS issues but works
<ogra> good
<gduarte> I can make it avaliable to others?
<ogra> you can do what you like with it :)
<gduarte> i know
<gduarte> but, to other that do not want to download and buid it, get a pre-compiled image
<gduarte> we could make it avaliable at that page
<ogra> sure, if you have space to host it you can make it available
<gduarte> ok
<gduarte> I'll improve that, install gcc and some other dev stuff and make it avaliable if i could
<ogra> gret
<ogra> *great even
<gduarte> :D
<gduarte> :D
<gduarte> thank you for helping me!!!!
<ogra> welcome, if you have other issues, dont hesitate to ask here (even if i'm not around there are surely people who can help)
<gduarte> surely ;)
<gduarte> thank you again!
<DanaG> http://www.bit-tech.net/news/hardware/2010/04/23/samsung-plans-own-netbook-chips/1
<samuel_Sayag> hi, I need to add FireWire support to the Ubuntu-ARM linux kernel. do i must recompile the whole kernel for that ?
<tractor> No doubt this has been asked before so apologies in advance. I am looking at the arm9 and wondering if Ubuntu is available for it.
<tractor> Anybody there?
<Meizirkki> tractor,
<Meizirkki> http://wiki.ubuntu.com/
<tractor> Excellent, thanks. Let me check that.
<Meizirkki> err..
<Meizirkki> wth is wrong with my clipboard -.-
<tractor> I only know it is an arm9 processor, I don't have any further details than that unfortunately
<Meizirkki> I meant https://wiki.ubuntu.com/ARM
<tractor> Oh, I see, thanks for the correction
<Meizirkki> Lucid probably doesn't work on arm9 machines
<Meizirkki> hmm, not Karmic either is seems
<samuel_Sayag> I have error while loading shared libraries libraw1394.so.8: cannot open shared object file problem ... though all my lib files are linked correctly
<samuel_Sayag> any ideals?
<samuel_Sayag> should I link them to usr/include ?
<tractor> Thanks Meizirkki, just looking through it now.
<rcn-ee> cwillu_at_work, pong.... rev 57 would be anything 2.6.32.10-l10.0 ++++
<cwillu_at_work> and in the karmic kernels as well?
<cwillu_at_work> [    1.412597] omapfb omapfb: no displays
<cwillu_at_work> [    1.416442] omapfb omapfb: failed to setup omapfb
<cwillu_at_work> [    1.421203] omapfb: probe of omapfb failed with error -22
<rcn-ee> yeah, exactly...  one user said it worked on their overo... looks like it's broken...
<cwillu_at_work> does it have an associated config item?  I'd like to prove to myself that it's actually included
<rcn-ee> it relies on a combined defconfig, so the same defconfig as the beagle..
<rcn-ee> cwillu_at_work, i'd actually test the lasted in the 2.6.32 series, as i had to tweak that patch in rev 65
<rcn-ee> which would be 2.6.32.11-x13
<cwillu_at_work> http://rcn-ee.net/deb/kernel/beagle/karmic/v2.6.32.11-x13/
<rcn-ee> exactly..
<rcn-ee> in that diff, look for: diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c is the dss2 patch
<rcn-ee> basicly pulled from sakoman's overo tree
<cwillu_at_work> I see a penguin
<cwillu_at_work> should I see that change in http://rcn-ee.net/deb/karmic/v2.6.33.2-d8/patch-*.diff, for example?
<rcn-ee> Nope, two different patchsets... 2.6.33 is still only in my 2.6-dev tree, (that's what the 'd' is)  I've been stress testing it on my gcc test farm, I'm thinking of moving 2.6.33.3 to stable after esc...
<cwillu_at_work> ah, that's my problem then
<cwillu_at_work> I'm on 2.6.33 as btrfs is significant more stable there
<cwillu_at_work> so now that I know what to beg for
 * cwillu_at_work begs for a 2.6.33 with the overo dss2 patches :p
<cwillu_at_work> I could just build it myself, but where's the fun in that?
<rcn-ee> actually it's rcn-ee, get your ass in gear and move 2.6.33 to stable. ;)
<cwillu_at_work> rcn-ee, indeed, and while you're at it, start getting 2.6.34 ready too :p\
<rcn-ee> hehe.. actually it's in pretty good shape... (other then dss2 on overo..) ;)
<cwillu_at_work> yep, I've been on .33 for a long'ish while now
<rcn-ee> i know.. i moved my x86's to 2.6.34-rc's as 2.6.33 just fells too old.. ;)
<cwillu_at_work> just got some old overo boards back that I want to get running more up-to-date images, and boom, no video :p
<cwillu_at_work> I'm anxiously waiting 2.6.35, as there's a bunch of btrfs stability stuff that should be landing there
<EvaLuaTe> hello
<EvaLuaTe> I have a mobile phone with a ARM processor. Is there any way I can find out if it supports ubuntu?
<rcn-ee> EvaLuaTe, maybe... which phone?
<EvaLuaTe> rcn-ee: it's an LG GT500. It's originale OS sucks, so I'm just looking to see if there's an alternative :p
<samuel_Sayag> can I compile the ubuntu arm kernel on the beagleboard ?
<rcn-ee> samuel_Sayag, yes i do it all the time... with alll modules 5 hours.. ;)
<samuel_Sayag> okay ... can you plase help me :) rcn-ee
<samuel_Sayag> I'm looking for the right kernel to download
<rcn-ee> define: right?  are you looking for a specific feature? or just something that works?
<samuel_Sayag> due the fact that the offical http://www.kernel.org/ doesnot get compiled :(
<samuel_Sayag> I just need a kernel with firewire support
<samuel_Sayag> to do it I need to compile a preprepared kernel for the arm ( i guess )
<rcn-ee> 2.6.32 works just fine if you build omap3_beagleboard_defconfig..
<rcn-ee> dss2 support needs patches...
<samuel_Sayag> okay ... how do i begin ? how can i find the first foot grip in all this ?
<rcn-ee> btw... how are you adding firewire to the beagle?
<samuel_Sayag> thank you very much by the way rcn-ee
<samuel_Sayag> I don't, I have a wird cemra interface that need it
<samuel_Sayag> http://tldp.org/HOWTO/libdc1394-HOWTO/install.html
<samuel_Sayag> the cemra name is FireFly MV by PG
<samuel_Sayag> very nice pice of hardware
<rcn-ee> interesting... well the problem, the beagle only has usb2.0, that's why i ask...  but to build something that just works, take a look at: https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-stable  it's my stable branch with scripts to build a stable workign kernel..
<samuel_Sayag> I been there :) (BTW) I didn't find how to add this flags    1.
<samuel_Sayag>       OHCI-1394 support
<samuel_Sayag>    2.
<samuel_Sayag>       OHCI-1394 Video Support
<samuel_Sayag>    3.
<samuel_Sayag>       OHCI-1394 DVI/O Support
<samuel_Sayag>    4.
<samuel_Sayag>       RAW IEEE1394 I/O Support
<rcn-ee> they require hardware firewire... the beagle doesn't have it, so it never shows up on the menuconfig..
<samuel_Sayag> :(
<samuel_Sayag> So I'm just lost :(
<EvaLuaTe> rcn-ee: so, do you have any idea if my device might support ubuntu? :) I've read that it sports a 93 Mhz ARM processor with 128MB or RAM memory btw...
<rcn-ee> EvaLuaTe, i've been searching for it.. I think it's an armv5 core which woudl mean jaunty only...  it's kinda too slow, you might not like the experience..
<alextisserant> hi all
<EvaLuaTe> ohh. Seeing as the 'reflash' with the original firmware isn't a pain in the ass though, I might think about trying it out. Is it hard to install?
<alextisserant> I'm trying to get an arm ubuntu image working thanks to the rootstock script
<rcn-ee> EvaLuaTe, it's not so much as reflash the rom with an ubuntu install, you need a Kernel for your device, the blob for your phone interface and tehn the rootfs...
<alextisserant> it works well with default settings, but I can't get the --seed option to work correctly
<rcn-ee> alextisserant, what are you sending to '--seed'
<alextisserant> (with lucid dist)
<alextisserant> a file with a list of packages
<alextisserant> at first I had a bunch of them, but now I'm just trying with mousepad
<EvaLuaTe> rcn-ee: so, if there isn't a kernel for my device, i'd have to compile one myself, right? also, I've no idea what a blob is :p
<alextisserant> then I do --seed `cat packages | tr '\n' ','
<alextisserant> so actually the script is just "stuck" while "Unpacking ttf-dejavu-core"
<alextisserant> when I had my long list of additional packages, it was actually stuck on Unpacking libc6-dev
<rcn-ee> EvaLuaTe, exactly, and a lot of these 3rd party phones it's almost impossible to find...
<alextisserant> my CPU is still working, but after a whole night of unpacking, I guess this is not totally normal :-)
<rcn-ee> alextisserant, lucid?
<alextisserant> so the script does not die, but it just seems to loop on this unpacking...
<alextisserant> yes
<rcn-ee> welcome to bug 56639
<ubot4> Launchpad bug 56639 in acpi-support (Ubuntu) "Thinkpad R40 Fn-F7 should switch active display in software" [Undecided,Invalid] https://launchpad.net/bugs/56639
<rcn-ee> crap, bug 566639
<ubot4> Launchpad bug 566639 in apt-setup (Ubuntu) "omap install ends up with security.ubuntu.com urls in sources.list after install (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/566639
<alextisserant> hmm
<rcn-ee> I give up: this bug: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/532733
<ubot4> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 4) (dups: 1) (heat: 34)" [High,Incomplete]
<EvaLuaTe> rcn-ee: ohh, ok then. You know any other nice OS for such a mobile device that might be easier to install/try?
<alextisserant> rcn-ee: did anyone try with other versions of qemu?
<rcn-ee> I've tried Debian Squeeze & Sid's...
<rcn-ee> Dustin and Loci are the ubuntu qemu guys..
<alextisserant> ok
<rcn-ee> It's one of those disapointing things...  If you have a beagle, the best method to build an SD card is the NetInstall..  I'm planning to make that work for the overo and igepv2, but after ESC...
<alextisserant>  yes, but I'm trying to get a ready-to-use final image for the Touch Book
<alextisserant> at least I can indeed do a netinst and pack the image afterwards
<samuel_Sayag> okay, I see my camera under the lsusb :)
<rcn-ee> alextisserant, that's exactly what i'm planning for my x11 images on rcn-ee.net for the beagle.. build native, copy...
<alextisserant> yup
<alextisserant> just need more time :)
<samuel_Sayag> But still when I'm trying to take a photo I get "err libdc1394: Failed to initialize libdc1394" odd...
#ubuntu-arm 2010-04-24
<Gestahlt> Weeeee
<Gestahlt> Hi!
<Gestahlt> Ive got my hands on an old Skye SL
<Gestahlt> Now big question
<Gestahlt> How do i get ubuntu on it?
<persia> I presume you don't mean http://brickwell.com/product/10-trek-skye-sl-57861-1.htm : do you have a link to specs?
<Martyn> Somehow, I expect not
<Gestahlt> Yepp, its a rather rare device. I found some info and also tried out his Linux
<Martyn> it would be interesting to try to install ubuntu on gears on a device
<Martyn> Ubuntu, bike edition
<Gestahlt> http://scholbert.homelinux.org/SkeyePad.html
<Gestahlt> there you go
<Gestahlt> maybe its too classic
<Gestahlt> but it would be just so cool
<Gestahlt> that WinCE 3.0 is giving me shivers
<Martyn> "skeye" is quite different
<Martyn> checking
<Martyn> no, ARM on that one is too old.  You might be able to get debian on it
<persia> Debian will run fine.
<Martyn> It's an SA1100 .. should run Debian fine
<persia> Jaunty might even install, but would run vey slowly.
<Martyn> Jaunty won't install .. its an arm v4
<persia> Oh, right.
<Martyn> and the memory map and driver map for that device is cwazy
 * persia is often confused by the various extensions in the SA1110 and needs to hardwire the brain to say "Cannot run Ubuntu"
<Martyn> http://scholbert.homelinux.org/SkeyePad_stuff.html
<Martyn> OOOOllld hardware
<Gestahlt> aye
<Gestahlt> but still a very robust build
<persia> Gestahlt: So, you should have good kernel support, but you likely have to make your own kernel.  Getting it to boot directly (rather than chain-boot out of WinCE) may be a bit tricky.
<Gestahlt> i want to pimp it up
<Martyn> I hate to say it, but it won't be very "pimp" able
<Martyn> it has very little memory
<Martyn> And when I say very little .. I mean a TINY amount of RAM
<Martyn> Samsung SDRAM 2x32MB (K4S561632-TC75) @ 103MHz
<Gestahlt> Computers wont need ever more than 640kb of RAM
<persia> Isn't that 64MB?
<persia> Should be fine, for careful use.
<Gestahlt> Actually
<Martyn> Worse, it has even less -storage-
<Martyn> Intel NOR Flash 2x16MB (28F128J3A-150)
<Gestahlt> i need it for RDP / VNC Streaming and Tux Paint
<Martyn> 32MB of storage.  That's it ...
<Gestahlt> and maybe seamonkey
<Gestahlt> Well
<Gestahlt> there is a CF card
<Martyn> getting a basic linux install squeezed in there, is going to be a bitch
<persia> Zaurus has 64MB, and later Zauri were known to run Jaunty.
<persia> That said, I wouldn't try to compile boost on it :)
<Martyn> Yes, Zaurus had more storage though
<persia> Depends on the model.  SLC-1000 has no NOR.
<persia> Err, -3000.
<persia> 3000 *ONLY* had CF storage.  Mind you, two CF, one pre-installed with a microdrive, but still.
<Martyn> That's because it had a -hard disk-
<Martyn> yeah
<persia> So?
<persia> Stick a microdrive or a bundle of flash in the CF slot, and who cares.
<persia> CF-ATA is all sorts of well supported.
<Martyn> true
<Martyn> could be interesting
<persia> Gestahlt: But, yeah, your first steps are figuring out how to build the right kernel, and getting it to boot that kernel.  Once you can do that, putting a Debian 5.0 filesystem on the CF card shuold be trivial.
<Martyn> Zaurus ã¯å¸¸ã«ï¼ä»ã¾ã§ï¼éå¸¸ã«ãã£ããé ããããã¼ãã¦ã§ã¢ã§ãã
 * Martyn mangles japanese with the best of 'em
<Gestahlt> Persia, that scholbert guy already build an running kernel (2.4.x but still better than ce 3.0) with GPE
<persia> In the beginning, this was true.  Not so much these days :)
<persia> Gestahlt: You really want a 2.6 kernel these days :)
<persia> Probably at least > 2.6.13, really.
<Gestahlt> I know...
<XorA|gone> persia: none of the zaurus had nor, all of them have nand
<persia> Ah, right.  My mistake.
<persia> 3000 still didn't have either :)
<XorA|gone> persia: 3000 had 128M of NAND
<XorA|gone> persia: so your still wrong :-)
<persia> What?
<XorA|gone> all zaurus had NAND
<persia> I thought that was precisely the difference between the 3000 and the 3100, and specifically didn't get a 3000 because of this understanding.
<persia> It was reputed to boot slow because of this.
<XorA|gone> it only had 16M
<persia> OK.  That I can believe.
<XorA|gone> 3100 had 128M
<XorA|gone> but the rom and bootloader was always in NAND
<persia> Ah, right.  So 3000 had kernel in NAND, and full FS on CF-ATA, whereas 3100 had the base FS in NAND also.
 * XorA|gone has spent too many years of life hacking on openzaurus
 * persia was only ever a Zaurus user, and no longer (the 3100 died, and the Netwalker has left the 3200 to gather dust)
<XorA|gone> persia: yeah something like that, couldnt tell you the exact layout of a 3000 as I never owned one, but its flashing script is identicle to 3100
<persia> Earlier models have just given up (no longer charge or boot)
<persia> Makes sense, and simplifies internals to have the 16M for booting.
<persia> (that said, I'm still happy to have never been a 3000 owner)
<XorA|gone> Ive had 5500, 5600, 6000, c860, 3200
<XorA|gone> only got 5500 left
<persia> I've had J1M1,760,860,3100,3200, and only the 3200 still works.
<persia> J1M1 isn't directly comparable, of course, running an entirely different OS :)
<XorA|gone> anyway Im off to bed its well late here :-)
<persia> Sleep well :)
 * NCommander needs Marvell :-/
<NCommander> ogra_cmpc: BTW, have you ever caught a stray cat before?
 * NCommander has one that recently showed up in town, and I'd like to trap it, get it neutered, and release/put up for adaption
<cwillu_at_work> mmmmm, segfaultilicious
<cwillu_at_work> debootstrap'ing lucid in qemu now results in segfaults instead of hangs :p
<kblin> segfaults.. C's way of reporting errors to the user :)
<cwillu_at_work> if it's actually segfaulting instead of hanging, I'm happy :p
<cwillu_at_work> if it's just segfaulting before it gets to the point at which it used to hang, I'm not so happy
<cwillu_at_work> segfaults:  C's way of saying "I love you"
<cwillu_at_work> "spend more time with me"
<cwillu_at_work> "why don't you ever call anymore?"
<kblin> :)
<cwillu_at_work> I was about to draw a bunch of parallels between c and one's psycho ex-girlfriend, but it might be hitting too close to home
<kblin> dunno, my experience is on the C side only
<kblin> and I think I'm fine with that
<samuel_Sayag> Hi, I don't understend, there is no way to compile the kernel with OHCI-1394 support? that is strange ...
<samuel_Sayag> is it true for all the beagleboard distro ? or can I find one with this modules on the kernel ?
<DanaG> hmm, how do you propose to get firewire on a beagle?
<ogra> lost of soldering ?
<ogra> *lots
<cwillu_at_work> wouldn't be all that much, no?
<cwillu_at_work> I'm sure dlp has a nice easy to use module
<cwillu_at_work> er, ftdi
<ogra> well, i'd use some USB adapter
<ogra> likely the easiest
<ogra> and probably evan already supported by the ubuntu default kernel
<ogra> if not, dkms is your friend ;)
<DanaG> USB to firewire?  there's not such a thing.  Or at least, not one that can do general-purpose firewire.
<ogra_cmpc> DanaG, http://www.usbfirewire.com/Parts/rr-527950.html
<ogra_cmpc> oh, he's gone
<DooitzedeJong> Hello all
<cwillu_at_work> he'll be back
<cwillu_at_work> ogra_cmpc, was that you I was talking to the other day about lucid not installing in qemu?
<ogra_cmpc> cwillu_at_work, if i talked about it then only in connection with rootstock, i guess it was rather lool, he does std. installs in qemu
<ogra_cmpc> though he focuses on aemu-maemo atm afaik
<ogra_cmpc> *qemu-maemo
<samuel_Sayag> Hi, what do i need for lan connection via the usb?
<sveinse> I'm trying to be able to login as root on my system, but after changing the root's password, I get "You are required to change your password immediately (root enforced)"
<sveinse> Then I (by mistake) changed the password for the ordinary user, and the same message appears for that user
<persia> samuel_Sayag: You need a USB LAN device.  Your life will be easier if it is known to be supported in Ubuntu (but this is hard to discover: you probably want to make sure it's supported in the upstream kernel)
<persia> sveinse: You hit the clock bug.  Set the system clock to something closer to real time.
<sveinse> It happens when the target system clock is out-of-sync with the real clock
<sveinse> persia: Yes, so I figured
<samuel_Sayag> persia, Thanks
<persia> I believe it only happens when the system clock is set to some time prior to the timestamp of the shadow file, but then again, my knowledge of that bug comes from listening to a couple people talk about it in a hotel room many months ago :)
<persia> That said, because of the some-systems-don't-have-battery-backed-clocks-and-can't-get-network-to-get-real-time-until-post-login issue, it's worth tracking down the bug, and investigating what other options are available to address the reason the check is present without cauing it to happen for everyone who has a failed/incorrect RTC.
<sveinse> persia: It is a good theory for my system. You see, I use NFS as rootfs, so the files will probably be timestamped with the host time. When the arm target is living in the 1970s you get these kind of errors
<persia> If possible, prefer boards with battery-backed RTCs :)
 * persia believes this to be a hardware issue, but is amenable to software workarounds.
<lool> wee plymouth SEGV
<lool> wow adding text + nosplash actually turns on the output
<lool> persia: Turns out it's not the kernel turning graphics on!
<persia> lool: What does it then?
<persia> Does plymouth reprobe directly?  Is that why it build-deps on libdrm?
<lool> I didn't find out yet, but init=/bin/sh doesn't turn it on
<persia> Cool.  That makes it easier.
 * NCommander waves
<lool> except I'm still fighting to get any sort of console
<lool> Gah, the cloud*.conf scripts were hanging
<suihkulokki> eero heinÃ¤luoma on kÃ¤ynyt kaivamassa isoisÃ¤n urlimuseosta kommenttia joilla kosiskella nuivia Ã¤Ã¤nestÃ¤mÃ¤Ã¤n sdp:tÃ¤
<suihkulokki> "ne vie meidÃ¤n tyÃ¶ttÃ¤mien tyÃ¶paikat"
<Stskeeps> that's a lot of finnish
<Stskeeps> :P
<suihkulokki> oops, wrong channel :P
<armin76> lol
#ubuntu-arm 2010-04-25
<gduarte> ogra: are you there?
<gduarte> someonte interested in a pre-built VM  of Ubuntu karmic to compile/build/whatever your projects?
<gduarte> *someone
<gduarte> :S
<gduarte> if someone wants it
<gduarte> there is http://w3.impa.br/~gabrield/data/ubuntu-arm-development-rootfs.tar.bz2
<gabrield> enjoy
<ojn> Nice work on getting beagle going, guys.
<ojn> Since OMAP can handle multi-board kernels, are there any plans on enabling some of the other options? ZOOM2/3 and gumstix are the ones that come to mind.   And/or who should I hassle about defconfig updates on those? :)
<ojn> s/on those/for those/
<Martyn> ojn : You back in town?
<Martyn> _and_ are you going to Brussels?
<ojn> Martyn: I am out in CA and no, I don't think I am going to Brussels.
<Martyn> crap
<Martyn> Well, perhaps I'll get lucky and get a hold of a lange debug cable out at UDS
<ojn> I'll be back on Friday. When is UDS?
<Martyn> Yes .. I'm _still_ trying to reflash that damned lange board, even though I have three tegra2 boards, and more Cortex-A9 action than a small manufacturer
<Martyn> I'll be out in europe from May 6 - 17th
<ojn> 'k. I can probably drop something off (in NORTH austin) on the weekend. I don't know if I'm just home over the weekend or for the week yet. Too hard to plan much right now, given recent events
<ojn> Martyn: Why are you picking up competitor's boards, btw? I thought you guys were developing your own SoC? Or have you switched to a plan B?
<Martyn> Because I hack them apart, and turn them into what I need
<Martyn> and I learn from them, of course
<Martyn> Making linux better, faster, harder.
<Martyn> (and in our case, much more power efficient on servers)
<Martyn> nVidia is the first good example (tegra250) of a low power consumption A9 .. in a good process (45nm)
<Martyn> I also recently got a quad-core A9 board from (undisclosable company)
<ojn> Yeah, ok. It's just been my experience in the past that competing vendors are less than excited to sell you eval boards if you're going to compete. I guess you're aiming for different markets so they might be less restrictive.
<Martyn> and that thing was made at Global Foundries .. in the 28nm process.   I think thats the way ARM chips will have to go.   2Ghz
<Martyn> yeah, they don't care
<Martyn> Or care much.  Also there are strategic alliances between our company and ARM that smooth the way
<ojn> Yeah, it's a bit different than the PPC landscape
<ojn> more small players too
<ojn> etc
<saeed> NCommander: ping
<saeed> orga: hey
<persia> saeed: Unless it's a private matter of some sort, you might ask a question generally.  No promises anyone can answer, but maybe :)
<saeed> persia: hey
 * saeed recalls what I wanted to ask 
<saeed> persia: I've prepare cofnig file for the fw_printenv
<saeed> for dove db
<persia> And you want to share it in hopes it gets into Ubuntu?
<persia> I'd recommend filing a bug and attaching it.  That's usually the best way to track that sort of thing.
<saeed> ok
<saeed> peria: the fw config file is board specific
<saeed> does the ubuntu loads the proper file depending on the board it runs on?
<persia> I don't know offhand, but I suspect it can be made to do so.
<persia> If it doesn't already, I'm unsure if the release managers would let it be made to do so for release in geneal, but it may be possible to do something special for just the dove image.
<saeed> ok
<saeed> btw, I fixed the slow ext2load in uboot, now it can load image + initrd in just 2 seconds
<saeed> from sata
<persia> Cool!
<persia> I was looking at QNAP's server lineups yesterday, and building greater and greater anticipation for something that does ARMv7 :)
<lool> saeed: ATM, we generate a config file during installation
<lool> saeed: fast ext2load > cool!
<saeed> lool: great, I'll upload the dove db config file
<lool> saeed: apt-get source flash-kernel, see debian/flash-kernel-installer.postinst
<lool> that's what it does for beagleboard ATM at least
<saeed> lool: how should I report a bug for the flash-kernel? in launchpad it's said theat flash-kernel does not use Launchpad as its bug tracker
<gabrield> ogra: did you see the changes at ARM/RootfsFromScratch?
<lool> saeed: You need to report it against the Ubuntu package
<lool> saeed: From an ubuntu system with flash-kernel, "ubuntu-bug flash-kernel"
<persia> saeed: You need to use flash-kernel (Ubuntu): https://launchpad.net/ubuntu/+source/flash-kernel/+bugs.  The easiest way is probably `ubuntu-bug flash-kernel`
<NCommander> saeed: pong
<samuel_Sayag> hi,
<samuel_Sayag> I'm looking for consol image displayer
<samuel_Sayag> is there such a program ?
<persia> Not really, on the raw console.
<persia> svgalib can do some stuff like that.
<persia> But that's accessing the framebuffer, rather than the console, as such.
<samuel_Sayag> and what if i only load the X, can I then load just an Image ?
<samuel_Sayag> I remmber that on the dos i had some image viewers ...
<DanaG> mplayer can access framebuffer.
<persia> vlc has an svgalib plugin as well.  zgv seems to be a dedicated image viewer.
<jkridner> I finally tried the beagleboard netbook install today.
<jkridner> I need to run to get a flash drive still.
<persia> jkridner: How did it work for you?
<jkridner> Despite the warnings, I tried to partition the installation disk (SD card) with the installer, but it complained about not being able to unmount /cdrom.  I thought it might stop me, but in creating the layout, but it didn't fail until the actual install attempt.
<jkridner> Going to see if I can find a nice USB flash drive now to use.
<jkridner> not sure exactly how that will work.
<jkridner> since u-boot doesn't currently read from USB flash drives.
<persia> No, it lets you shoot yourself in the foot to enable careful aim for large shoes.  If you happen to have partitioned the SD card in a way that has an *extra* partition separate from the area used for the installer, you can use that for data.
<persia> The common method seems to be to boot from SD card with boot options that mount / on a USB drive.
<jkridner> it seemed to let me specify one, but the install failed.
<persia> rotary drives work too, if you're just playing around.
<jkridner> if rotary drives were smaller, that'd probably be the way I'd go.
<jkridner> just that I'm on the road.
<persia> The install to your install-SD bit might still be a bit buggy.  I'm not sure many people use it, and I think only one or two people are looking at it (and not very agressively).
<persia> Yeah, if you're travelling, flash is nice and compact :)
<persia> I did an install once to one of the USB in-plug microSD readers, which worked, which almost looks like you don't have something attached.
<persia> (although that was on a different board, but similar situation)
<jkridner> know anywhere to pick one up near the San Jose Convention Center?
<persia> Sorry, no.
<DanaG> san jose?  isn't there a "fry's" around there somewhere?
<jkridner> there is.
<jkridner> just wanting something in walking distance
<DanaG> ah.
<DanaG> you could ask google-maps for electronics stores.
<persia> Doesn't have anything within 30 minutes walk (already tried that)
<DanaG> Dang.
#ubuntu-arm 2011-04-18
<ndec> ogra_: hi
<ndec> ogra_: have you seen the messages on pandaboard google groups? some folks report that headless image don't work with 8Gb or 16Gb, but work with 4Gb?
<ogra_> ndec, whats the bug number? and did they attach the jasper.log ?
 * ogra_ hasnt heard of any errors with 8/16G cards yet
<ppisati> qemu + u-boot = fail
<lool> ppisati: Nah
<lool> ppisati: Which u-boot?
<doko> ogra_, janimo: shrink-wrap came up again on today's linaro call. looks like it should be disabled for the natty release, or at least for -updates
<ogra_> shrink-wrap ?
<lool> doko: michaelh submitted a branch to disable it by default
<lool> doko: In gcc-linaro
<lool> doko: Not sure you will have the chance to integrate this though
<lool> https://code.launchpad.net/~michaelh1/gcc-linaro/disable-shrink-wrap/+merge/58055
<doko> lool: it's already in gcc-4.5 for all archs but armel
<lool> doko: Okay
<ogra_> doko, well, throw it in if you can, if you cant throw it in updates :)
<ogra_> (as if we had a choice :P just do it :) )
<janimo> doko, sounds fine
<janimo> doko, not sure what other packages are affected and will remain so without a rebuild
<doko> janimo: right, but you can't rebuild everything :-/
<janimo> sure, disabling is better then leaving the optimization on, I was just wondering aloud :)
<ogra_> we can rebuild in -updates if needed i think
<ogra_> in case we run into other issues
<janimo> sure. The more serious issues are identified as bugs already, the remaining ones are less used universe packages
<ogra_> yeah
<ogra_> btw, what was with that banshee bug ?
<ogra_> tobin said we need to disable something to make it eat less cpu
<ogra_> is anyone on top of that ?
<janimo> ogra_, no idea re banshee
<ogra_> hmm
 * ogra_ digs his bugmail
<janimo> I remember rsalveti noticing much higher CPU usage than with rhythmbox and mpg123
<janimo> but I have no other info
<janimo> 20% 10% and 3% CPU IIRC
<ogra_> yeah
<ogra_> there was an option that you can disable but i cant find a bug
<janimo> I know!! Let's allow mono to take advantage of dual cores. It should make that CPU usage better :D
<janimo> disable what? Does it do something extra for mp3 which is optional?
<janimo> does it not use gstreamer?
<ogra_> there is a lib or something you can disable that significantly drops the cpu usage
<ogra_> lets wait for GrueMaster or rsalveti, i think they already looked into it
<janimo> LDFLAGS -= -lbloat
<ogra_> lol
<ogra_> the discussion sounded more like a runtime thing
<janimo> banshee has a lot of plugins linked in (lots of configure options anyway), could be one of those
<ogra_> yep
 * ogra_ goes back to bang his head against pulse
<ogra_> life was so easy when we only had esound :P
<hrw> esound? I had artsd
 * ogra_ curses
<ogra_> so adding the one missing patch to pulse breaks everything again
<ogra_> thats just depressing
<ndec> ogra_: no LP report, just discussion on google group: http://groups.google.com/group/pandaboard/browse_thread/thread/c2287d603dc325e0
<ogra_> ndec, well, i cant do much without logs, we didnt have any such errors when testing with various cards
<ndec> ogra_: ok. i just wanted to make sure you've seen this. at least 2 persons have had this problem and reported on the panda mailing list.
<ogra_> that guy definitely trashed it by rebooting in the middle of the resize process
<ndec> ogra_: well he said he waited 1 hour before rebooting
<ogra_> well, i need the jasper.log, cant say anything without
<ogra_> it might well be that there was a regression in the dailies, he should definitely try the beta2 instead
 * ogra_ sighs ...
<ogra_> really doesnt look like that sound stuff will work at all
<ogra_> :(
<ogra_> ndec, do you know if your sound people actually use the ubuntu kernel ?
<ndec> ogra_: yes. at least this is what i ask...
<ogra_> weird
 * ogra_ doesnt get why it doesnt work then
<lool> ndec: I took today's OMAP preinstalled image and dd-ed it to three files of sizes 2 G, 4 G and 8 G, and started qemu-linaro with -M beaglexm -m 512 -sd <file> on all three; both the 2G and 4G instances booted up to d-i (after resizing and rebooting), I'm waiting on the 8G still (no error so far); this is not enough to conclude that there is no problem though, as physical cards don't have exact multiples of Gs, but relatively random sizes
<ndec> lool: i am sure the images work most of the times... my point was just to highlight to ogra_ that sometimes they don't... that might very well be 'local' issues..
<lool> ndec: it might be local, or it might be partitioning logic with specific input sizes
<ogra_> well, it might take longer on bigger cards
<ogra_> i must admit that i didnt test with more than 8G though my 8G card behaved fine
 * ogra_ hopes btrfs images in oneric will make our life easier here
<lool> You decided to go with btrfs?
<ogra_> we will investigate
<lool> Did you try it out so far?
<ogra_> afaik the big probs left wrt btrfs are bootloaders
<ogra_> which doesnt affect us
<ogra_> lool, not yet, but we have spec plans for it
 * ogra_ is to busy with release to try out new stuff atm
<lool> I wouldn't have too high hopes that it will help
<lool> Performance on a panda + btrfs rootfs has been terrible here, much worse than extN
<ogra_> its like a deja vu ... last release i spent the last weeks on omap4 sound ... this release too
<lool> and I had to fix some issues in natty before that would even boot without error
<ogra_> lool, even if you aling properly and use the ssd option ?
<lool> Yes
<ogra_> *align
<ogra_> hrm
<ogra_> i would love nilfs2 ... but it has no resize function yet
<ogra_> so far it was far beyond all other FSes on SD in all comparisons i have seen
<ogra_> on the ac100 it seems to double up the access speed
<lool> ndec: FTR, the 8 G image also booted up to the config screen
<lool> Now it would be interesting to try with uneven sizes, but QEMU might not be ideal for this
<rsalveti> morning
<rsalveti> ogra: janimo: bug 760902
<ubot2> Launchpad bug 760902 in banshee "Banshee's Library Watcher should be disabled by default in Ubuntu 11.04" [Wishlist,Incomplete] https://launchpad.net/bugs/760902
<ppisati> kexec is really broken :(
<janimo> rsalveti, so it is not arm specific
<rsalveti> nops
<ogra> ah, i thought you only saw it on arm
 * ogra_ goes for his 3rd pulseaudio build today
<lil_pete> lol
<GrueMaster> Morning.  I see rsalveti posted the banshee bug.  I actually didn't see much improvement w/o the libarary watcher, but I was only able to test on my beagleXM.
<ogra_> GrueMaster, well, its fine, its not armel alone so i dont care much
<ogra_> i thought it was arch specific
<ogra_> rsalveti, can you point phh to the compiz gles stuff ?
 * ogra_ forgot where it was, some upstream git tree iirc
<phh> (the sources, i'm still on maverick.)
<ogra_> or Amaranth ^^^
<Amaranth> http://git.compiz.org/~amaranth/mobilebling/
<Amaranth> Still working on the plugins
<ogra_> its just to test it on tegra graphics
<Amaranth> Ah, ok
<phh> Amaranth: just tell me some features that are supposed to work :p
<ogra_> drawing windows and frames :P
<Amaranth> so compile and install that then run `compiz --replace composite opengl move resize decor` to get a basic window manager running
<Amaranth> Although all the plugins that get compiled in there should work
<phh> ok
<Amaranth> The plugins-main pack is still being worked on, I thought I had it done then discovered weird things were happening
<Amaranth> The plugin pack is still compiling against regular GL and when running if it tries to make a regular GL call that function just gets skipped
<Amaranth> Weirdest thing ever, I would have expected a symbol error
<ogra_> blame the toolchain :P
<Amaranth> So I haven't published it yet, even though most of it actually works
<Amaranth> I've got the build system putting the proper defines in the pkg-config file now at least but the plugin pack seems to ignore that anyway
<phh> Amaranth: would you mind adding a vendor string matching for image_pixmap extension ? nVidia doesn't declare it, even though they have it
<Amaranth> phh: ?
<Amaranth> nvidia doesn't report supporting the standard one but only their own version?
<phh> no
<phh> they don't report anything concerning this thing
<phh> but they do support the extension
<Amaranth> *headdesk*
<phh> :)
<Amaranth> phh: Do they at least properly report support for GL_EXT_texture_format_BGRA8888 or should I add a workaround for that too?
<Amaranth> I need to add one of those for the efika anyway, the current workaround only works if you compile on the efika with their headers
<phh> they report GL_EXT_texture_format_BGRA8888
<Amaranth> phh: What are the EGL_VENDOR and GL_RENDERER for that system?
<phh>     GL_VENDOR:     NVIDIA Corporation
<phh>     GL_RENDERER:   NVIDIA Tegra
<phh> Amaranth: so, compiz doesn't crash, but no alt-tab (I guess I'm missing some missing files), and I've got double buffering problem (like on kwin)
<phh> basically, when there are updates, only part of the buffer are updated and only on the current buffer, the second buffer doesn't get the update
<ndec> cd
<lool> ndec: ~
<ndec> rm -rf /
<lool> ndec: rm: il est dangereux d'opÃ©rer rÃ©cursivement sur Â«/Â»
<lool> rm: utilisez --no-preserve-root pour inhiber cette mesure de sÃ»retÃ©
<Amaranth> phh: alt-tab doesn't work because you didn't load a plugin for it :)
<Amaranth> I'll have to see what was done for kwin as far as the other problem, I remember seeing something about it
<phh> iirc it hasn't been fixed yet :s
<Amaranth> Hmm, I could have sworn jazh had a fix committed for it
<phh> in screen.cpp, line 1268, doing mask=COMPOSITE_SCREEN_DAMAGE_ALL_MASK works
<phh> but hum.
<phh> Amaranth: loadign switcher is supposed to work ?
<phh> compiz (core) - Error: Plugin 'compiztoolbox' not loaded.
<phh> compiz (core) - Error: InitPlugin 'switcher' failed
<phh> compiz (core) - Error: Couldn't activate plugin 'switcher'
<phh> compiz (core) - Error: Plugin 'compiztoolbox' not loaded.
<phh> ah I have to load it by hand before switcher ?
<Amaranth> Right
<phh> ok. fine.
<phh> interesting.
<Amaranth> That's not the normal switcher we use but it should work
<Amaranth> Although I think I may have broken the icon loading, I need to go back in and put a proper RGBA->BGRA conversion in
<phh> what switcher should I use ?
<phh> I agree it's kind of buggy :p
<Amaranth> The normal switcher is in plugins-main
<Amaranth> Which I've spent about a week fighting cmake over
<phh> ok
<Amaranth> I basically have to somewhat drastically change the plugin build system in order to get plugins-main to pick up on the fact we're using GLES
<phh> so, the bugs I have, two out of 3 windows are overbrightnessed or something like that
<phh> (could be because of the hack I just added)
<Amaranth> Which hack?
<phh> mask=blabla
<Amaranth> panda and efika don't have such a problem (although I suppose it's hard to tell with efika considering the other issues there)
<phh> alt-tab has black windows, until windows are refreshed
<Amaranth> Weird...
<phh> icons are black too
<phh> all these problems could be because of my hack :D sec I test without it.
<Amaranth> The icons are expected
<phh> ok, still same bugs without my hack
<phh> Amaranth: would it sounds stupid if it does the sum of the two last frames ?
<Amaranth> I can't think of why that would happen
<Amaranth> That doesn't sound like something I'd do accidentally, anyway
<phh> only app that isn't disturbed is the terminal which uses alpha channel ...
<GrueMaster> Looks like do-release-update May be a bad idea for our images.  Took 3 days (largely due to user prompts for config file overwrites) and X fails to come up afterwards.  Looking into the issues now.
<GrueMaster> Also, this will fail to get any x-loader & u-boot updates.
<GrueMaster> (which is why I recommend that they be installed as packages).
* GrueMaster changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch |  cross build ? http://42.pl/u/2u8U | Natty Beta 2 at http://cdimage.ubuntu.com/ubuntu-netbook/releases/natty/beta-2/| Ideas for Oneric | https://wiki.ubuntu.com/ARM/OneiricObjectives
<GrueMaster> Hmmm.  I had two pandas running do-release-upgrade over the weekend.  My 8G failed for unknown reasons (looks like it may have had the pvr drivers for maverick installed prior to upgrade).  The 16G SD upgraded fine.
<GrueMaster> Although the partition label for the boot partition was deleted.
#ubuntu-arm 2011-04-19
<ppisati> anyone with a beagle xm around?
<ppisati> i want to rule out a hw issue
<diwic> ogra_, what's the output of "alsaucm listcards"?
<ogra_> ogra@panda:~$ alsaucm listcards
<ogra_> Im setting defaults
<ogra_>   0: SDP4430
<diwic> ogra_, that "Im settings defaults" is annoying. I'm sure that if we just correct "Im" to "I'm", sound will start to work ;-)
<diwic> what's the output of "alsaucm list SDP4430"?
<ogra_> lol
<ogra_> ogra@panda:~$ alsaucm list SDP4430
<ogra_> Im setting defaults
<ogra_> alsaucm: error failed to get list SDP4430: No such file or directory
<diwic> ogra_, how about "alsaucm list _verbs" or "alsaucm list _enadevs"?
<ogra_> http://paste.ubuntu.com/596013/
<ogra_> ogra@panda:~$ alsaucm list _enadevs
<ogra_> Im setting defaults
<ogra_> alsaucm: error failed to get list _enadevs: Invalid argument
<diwic> alsaucm set _verb HiFi
<ogra_> ogra@panda:~$ alsaucm set _verb HiFi
<ogra_> Im setting defaults
<diwic> pasuspender -- speaker-test -c 2 -t sine -D plughw:SDP4430
<diwic> any sound?
<ogra_> hmm, that needs me to be near the board and listen, right ?
<diwic> right
 * ogra_ is remotely logged into the board, i need to move over to the office, one moment
<ogra_> i see it doing stuff on the cmdline though
 * ogra hugs diwic 
<ogra> works !
<diwic> ogra, great :-)
<ogra> so its the alsaucm set _verb HiFi we need ?
<ogra> let me reboot the board and see if it persists
<diwic> ogra, likely needs to be set on every boot - might persist a reboot but not a complete power-off with capacitors unloaded etc
<ogra> hmm, i will test that too
<ogra> it wouldnt be a prob to have a one time call of it in our first boot config tool
<ogra> putting it in place for every boot is more effort
<diwic> ogra, the point is that the PA UCM stuff should make it possible to set these verbs from PA.
<ogra> aha, after reboot the UI only has HDMI again
<ogra> hmm, no
<diwic> ogra, does the other verbs in the list make sense to you?
<diwic> voice low power etc
<ogra> yep. omap4/panda is a mobile development platform
<ogra> all the verbs make sense there
<ogra> i'm trying a reboot with "alsaucm set _verb HiFi" in rc.local, lets see what comes out there
<diwic> ogra, so question is if "HiFi" is the correct one to set at boot (if we should set anything at all at boot)
<ogra> seems pulse isnt picking it up without a restart
<ogra> we want to default to headphone on boot, so hifi is fine
<ogra> the prob is that people wanting to use HDMI sound will have to hack it up
<ogra> else we reset their sound every boot
<diwic> is HDMI going through the SDP4430 as well, or is it something separate?
<ogra> not sure, i think its going through the same chip
<diwic> aplay -l
<ogra> http://paste.ubuntu.com/596025/
<diwic> ogra, looks like HDMI is on a separate sound card, probably not using UCM at all, and should not be affected by the "_verb HiFi" stuff
<ogra> k
<ogra> ok. adding the line to rc.local (and actually writing hifi with a capital F) gets me working sound OOTB
<ogra> diwic, so do you think its safe to pull in the pulse package with the patches ? i can care for addint an upstart script or some such that sets the default (or a udev rule)
<diwic> ogra, I'm not following, pull to where? The main ubuntu archive?
<ogra> diwic, well, the pulse packages with the TI patches werent uploaded yet
<ogra> and we only have two days left to do so
<ogra> ... getting sound to work this time is kind of important since we already failed with that last release
<diwic> ogra, a udev rule sounds like a good solution for setting the default verb
<ogra> k
<diwic> ogra, well, before we pull them in, we should get them working - do you think they are working?
<ogra> i got sound, thats enough imh ;)
<ogra> *imho
<ogra> with the rc.loacl entry at least
<diwic> ogra, yeah, but that does not need the PA patches
<diwic> alsaucm is at the alsa-lib level
<ogra> are you sure ?
 * ogra reverts to the archive pulse version, gimme a few min
<diwic> hmm, good question :-)
<ogra> gar
<ogra> now i rteinstalled pulse on my laptop :P
<ogra> grmbl
 * ogra whacks apt over the head
<diwic> oh, trying to downgrade PulseAudio?
<ogra> well, it has a ~ppa version
<ogra> apt should respect that
<ogra> sigh
<diwic> ogra, see your email, got it from Conor who had managed to downgrade pulseaudio after several rounds in the padded cell
<diwic> ogra, that's what he had to do - you should probably skip the modules you do not use
<ogra> grmbl, it complains about packages i dont even have installed
<ogra> bah, sigh, a version for every single package ?
<diwic> ogra, guess you could make a shell variable
<diwic> for the version number
<ogra> yeah
<ogra> k, that seems to work
<ogra> will take a while ... slow SD card
<ogra> diwic, in any case i think the pulse patches are important for UI exposure, you wont be able to select if you want HiFi or HDMI output without them
<ogra> but we'll see
 * ogra scratches head ... why the heck does pulse trigger update-initramfs ?
<ogra> diwic, ok, seems it works without the patches too
<diwic> ogra, how does it look in pulse now? One soundcard or two?
<ogra> the default selected output in the UI is HDMI though
<ogra> two cards
<diwic> great
<ogra> sound playing from headphone ...
<ogra> but if i open the UI it shows HDMI as the selected output device
<diwic> how are you playing the sound?
<ogra> if i switch back and forth and leave HDMI the default, sound is dead
<ogra> if i switch back to SDP its fine then
<ogra> i'm hitting back in the terminal to hear the kbd bell
<ogra> and i use the test speakers button in the UI
<diwic> ok
<ogra> i'll try banshee too later, but i dont think we'll have issues there
<ogra> a udev rule should live in alsa or pulse though
<ogra> (i can indeed add one as a hack but i would prefer not to)
<diwic> ogra, I wasn't exactly following what the "sound is dead" thing was
<ogra> by default the UI shows HDMI as selected output device
<ogra> while its using SDP
<ogra> if i switch the radio button to SDP and back to HDMI, sound on the headphone is dead
<diwic> hmm, that's strange, I'm assuming you haven't messed around with pavucontrol?
<ogra> nope
<ogra> its just showing a wronmg default on first start is what i meant to say
<ogra> banshee works fine
<diwic> ok, that would be my conclusion as well
<diwic> but I don't recognize that problem from anywhere else, seems strange
<ogra> well, a bug we can surely release with
<diwic> you might want to make sure recording is working as well
<diwic> that might need an additional verb...?
<ogra> hmm, the UI doesnt offer me *any* input devices
<ogra> i have mono and stereo outputs for SDP and a stereo output for HDMI
<diwic> could you tell me what physical inputs and outputs there are on this card?
<ogra> only a mic jack ...
<ogra> i'm not sure there are additional inputs on the expansion header though
<ogra> but getting the mic jack to work should be enough
<ogra> there seems to be a recod verb
<ogra> aha
<ogra> alsaucm set _verb Record
<ogra> that gets me duplex support in SDP
<diwic> ogra, question is if they are exclusive, so "HiFi" turns off record and vice versa
<ogra> they arent it seems i constantly listen to radio from banshee
<diwic> cool
<ogra> let me try a reboot and add it to rc.local
 * ogra reboots
 * ogra hears login sound
<ogra> hmm, record doesnt seem to use the mic
<diwic> how are you checking the mic?
<ogra> i have my headset plugged in ... checking the meter in sound prefs and testing sound recorder
<ogra> i have set it from record to Voice_Call now, lets see
<ogra> instead of Record
<ogra> still have a login sound it seems
<ogra> hmmk
<ogra> doesnt get my any input device at all
<diwic> It's interesting that the verb affects what devices show up in PA.
<ogra> well, no matter which one i set, i dont seem to be able to get input
<ogra> i would be willing to live without though, if we dont find a solution
<ogra> only Record actually gets me duplex support
<ogra> but it seems to not be routed to the mic jack
<ogra> or its muted on alsa level
<diwic> alsaucm should unmute the relevant things...but everything can be buggy of course
<ogra> yeah
<ogra> well, having playback at release is a massive improvement already
<ogra> is there any reason why alsaucm requires these ugly underscores ?
<diwic> ogra, No idea - I just figured them out by reading the source code...
<diwic> could you give me the output of arecord -l ?
<ogra> http://paste.ubuntu.com/596061/
<diwic> ogra, hmm, from what you know about this board, would you suspect the mic jack is at "9 DMIC capture" or "11 Analog capture"? I'm suspecting 11 as the "D" in "DMIC" might suggest a digital mic is needed
<ogra> right, i would say that too
<diwic> was recording working with the init scripts we had in maverick?
<ogra> no
<diwic> ok
<ogra> and we never really had the full implementation in maverick
<ogra> only parts of it
<diwic> what is the output of "amixer -D hw:SDP4430"?
<ogra> http://paste.ubuntu.com/596064/
<diwic> ogra, hrm, you'll almost need the datasheet of the SDP4430 for that to make sense...is that available?
<ogra> ndec, sebjan ^^^^ ?
<ogra> do we have one for the sound chip ?
<ogra> i know there are several papers but i'm not sure the sound is covered
<diwic> ogra, found something on google, claiming it's connected to a TWL6040 chip, is that correct?
<ogra> i think there was 6040 in one of the pastes
<ogra> http://paste.ubuntu.com/596025/ yep
<diwic> right that's on channel 11 as well
<diwic> the twl6040 has one "Analoc mic" and one "Headset mic". Can you verify which one you have connected your mic to?
<ogra> heh, not really
<ogra> there is nothing printed on the jack
<ogra> on the PCB it just says headphone
<ogra> which might or might not be the headset mic
<diwic> it seems to be the headset mic
<diwic> from looking at the schematics ;-)
<ogra> :)
<diwic> assuming you have the "record" verb fixed, could you try this command
<diwic> pasuspender -- arecord -D plughw:SDP4430 -f cd -d 10
<diwic> sorry
<ogra> prints garbage
<diwic> pasuspender -- arecord -D plughw:SDP4430 -f cd -d 10 /tmp/test.wav
<diwic> and then speak into the mic for 10 seconds
<ogra> papplay only revels silence
<ogra> *reveals
<diwic> ok
<ogra> and i have overrun!!! (at least 16.473 ms long)
<ogra> twice
<diwic> hrm
<diwic> I think you should talk to TI about what verb you should use for recording from mic and then try my above command to record
<ogra> k
<diwic> My time is about up
<diwic> But at least we got some playback :-)
<ogra> well, can we add the udev rule to at least get HiFi in ?
<ogra> i guess that should go into alsa or pulse
<diwic> if so, alsa - not pulse
<ogra> right
<diwic> if you get the mic working on alsa level, we can consider the pulse stuff, but if it ain't working on the alsa level, it won't work on the additional pulse layer either.
<ogra> right
<diwic> good you called upon me for this, I thought it was all okay.
<ogra> i thought you had the bug on your radar
<ogra> but i somehow assumed the same for the TI devs
<ogra> i'm babbling on the bug since a while with my unsuccessfull findings
<diwic> but if you ask me, I'm happy for having a udev rule added
<diwic> such a rule should be trivial and non-invasive
<ogra> k, i'll try to come up with a one liner until tomorrow morning
<ogra> that should be enough to make the release
<ogra> given that hiFi is enough for now
<diwic> you can probably match against ATTRS{id}=="SDP4430"
<ogra> yeah
<diwic> yeah and see if you can get the mic working with the help of the TI folks
<ogra> ATTRS{id}=="SDP4430" IMPORT{program}="alsaucm set _verb HiFi"
<ogra> should that work ?
<GrueMaster> ppisati: I saw your call earlier for a beaglexm, what's up?
<diwic> ogra, I would have tried this, but I'm not a udev expert: ATTRS{id}=="SDP4430", RUN+="alsaucm set _verb HiFi" ?
<ogra> ah, right, RUN
<ogra> IMPORT will hand over the return value to the caller
<diwic> ok, let's talk more tomorrow, gotta go.
<ogra> diwic, i think we'll keep recording for a possible SRU if i dont find a way to make it work tonight, should i attach the one liner to the bug ?
<diwic> ogra, yes and preferrably as a debdiff against the relevant package
<ogra> ok, will prepare everything
<diwic> ogra, and maybe poke TheMuso about it if he's awake when you are
<ogra> GrueMaster, something to test for you, add: ATTRS{id}=="SDP4430", RUN+="alsaucm set _verb HiFi" to /lib/udev/rules.d/60-persistent-alsa.rules before persistent_alsa_end and reboot, see (hear) if you have sound then on panda
<ogra> diwic, will, do, many many thanks for the help !!!
<GrueMaster> ogra: Any other changes/packages to install first?
<ogra> GrueMaster, no ! thats the awesome bit :)
<ogra> we already have working sound since ages, UCM is just not initialized
<ogra> well, your panda should be up to date indeed :)
<GrueMaster> Trying now on yesterday's image.
<ogra_> did you try headless since beta btw ?
 * ogra_ hasnt and has a suspicion that the ppa stuff breaks jasper on headless
<GrueMaster> ppa stuff?  I haven't had a change as my pandas were doing Maverick -> Natty upgrade tests (not recommended on SD BTW).
<ogra_> yeah, there was a fix to the ppa handling in jasper added after beta
<ogra_> i think it might fail if the target dir doesnt exists (which it likely doesnt without any desktop packages)
<ogra_> dont worry, i'll test myself tomorrow and fix if my suspicion is true
<GrueMaster> No sound here.
<GrueMaster> Panda 2.0
<ogra_> really ?!?
<GrueMaster> Lower jack, right?
<ogra_> yes
<ogra_> do you see the SDP4430 in the sound prefs ?
<GrueMaster> no
<ogra_> sigh
<ogra_> try calling: alsaucm set _verb HiFi
<ogra_> from a terminal (close the sound prefs first)
<ogra_> and killal pulseaudio
<ogra_> then start the sound prefs again
<ogra_> see if that changes it, probably udev initializes it to late
<ogra_> if i add that line to rc.local here, it makes output work fine
<GrueMaster> rebooting.  Typo in udev rule.  (oops).
<ogra_> phew
<GrueMaster> pulseaudio is crashing now.  Need to look into it.
<ogra_> hrm
<ogra_> does alsaucm list _verbs get you a list of use cases ?
<ogra_> (it should spit out 8 use cases)
<ogra_> also alsaucm listcards
<ogra_> whould list the SDP4430
<ogra_> *should
 * ogra_ doesnt get why it works flawless for him
<ogra_> GrueMaster, oh, there was a kernel upgrade i havent installed yet, i wonder if something went wrong with the tree merge wrt alsa/ucm
<GrueMaster> Do you have the pulseaudio from the ppa installed or the base image stuff?
<ogra_> all archive
 * ogra_ fires off a dist-upgrade 
<GrueMaster> pulseaudio is crashing here with main.c: Daemon startup failed.  Going to dive in and see why.
<GrueMaster> What is your image based on?  Beta2?
<ogra_> well, what do you get from the alsaucm commands ?
<ogra_> yes, its my peta2 test install
<GrueMaster> alsaucm is fne.
<GrueMaster> fine
<ogra_> so you get the list and also get the soundcard listed ?
<GrueMaster> (caffeine is building up)
<GrueMaster> yes
<ogra_> weird
<ogra_> pulse shouldnt crash
<GrueMaster> But pulseaudio is segfaulting.
<ogra_> check syslog
 * ogra_ goes to get coffee before the call 
<GrueMaster> which call?
<GrueMaster> Linaro?
<ogra> yep
<GrueMaster> I'm skipping out.  QA CoP meeting in :30
<ogra> k
<diwic_afk> ogra, might want to try  pasuspender -- arecord -D plughw:SDP4430,11 -f cd -d 10 /tmp/test.wav
<diwic_afk> as an option to the previous command
<ogra> will do (my mic is occupied by a meeting atm :) )
<ndec> ogra: there are problems on panda with the input mic. prpplague might know more than me on that.
<prpplague> ndec: the audio input is actually configured as a mono line-in currently
<ogra> ndec, ah, ok, should the Record usecase be the right one then ?
<prpplague> you should be able to record using it as a line in
<GrueMaster> ogra: Not seeing an issue with headless on omap4.
<ogra> k, thanks
<GrueMaster> ogra: On my panda audio, I am seeing good indicators for asoc early in the dmesg log, but later on I am getting asoc:  machine hw_params failed followed by a series of specific asoc failures.
<ogra_> weird, i dont have such issues here
<ogra_> the alsaucm call should definitely set up everything for you
<GrueMaster> I even removed that line from udev.  Still getting it.  Not sure why.  See http://members.dsl-only.net/~tdavis/syslog.gz
<ogra_> your syslog looks fine
<GrueMaster> I may have a theory.  Let me check something.
<ogra_>  asoc: no valid backend routes for PCM: SDP4430 Media should actually go away if alsaucm was initialized
<ogra_> i have that as well here until the card is properly initialized
<ogra_> the others are not errors
<GrueMaster> Do you still have /usr/share/alsa/init/omap4?
<ogra_> no
<ogra_> that was dropped from alsa
<ogra_> do you ?
<GrueMaster> Ok, because you said you were on the beta 2 image.
<ogra_> it shouldnt be there
<GrueMaster> It is in beta 2, not yesterday's image.
<ogra_> upgarded to whatever was recent on monday
<ogra_> and just upgrading again
<GrueMaster> Check if the file is still on your system please.  Upgrading doesn't delete it necessarily.
<ogra_> it has to, else that would be a massive dpkg bug :)
<ogra_> but for your convenience ...
<ogra_> ogra@panda:~$ ls /usr/share/alsa/init/omap4
<ogra_> ls: cannot access /usr/share/alsa/init/omap4: No such file or directory
<ogra_> lool, ping
<ogra_> GrueMaster, did you recently upgrade the kernel on your panda ?
<GrueMaster> I just did.  This is yesterday's (20110418) image now rebooting with kernel & other updates.
<GrueMaster> (forgot to run flash-kernel after updating).
<ogra_> ??
<ogra_> the postinst runs that
<GrueMaster> Yea, sure it does.
<GrueMaster> (not on mine).
<ogra_> UGH !
<ogra_> do we have a bug for that ?
<GrueMaster> Kernel was released last night.  I just upgraded and (5 minutes ago) saw that the new kernel was installed but not in the u-boot partition.  Simple answer - NO.  Give me some time.
<ogra_> but flash-kernel ran fine when you executed it manually ?
<GrueMaster> Ok, pulse is happy now with the new kernel.
<GrueMaster> Yes it did.
<ogra_> weird, i didnt have the new kernel here but it worked
<GrueMaster> I was running 38-1207 when I was seeing the error, after manually running flash-kernel I am now on 38-1208 kernel.
<GrueMaster> And audio is happy (so far - testing actual output next).
<GrueMaster> works now.
<ogra_> wohoo
<GrueMaster> I'm starting over with yesterday's image to see if I can pinpoint the issues, especially with the kernel update.
<ogra_> yeah
<GrueMaster> (the joys of having two systems).
<ogra_> i have seen an umount error in flash-kernel during my tests, thats why i brought it up
<ogra_> doesnt happen anymore though
<ogra_> i wonder if we should change umount to umount -l in the script
<GrueMaster> not sure.
<GrueMaster> Script is getting an overhaul though.  May not be necessary.
<ogra_> GrueMaster, btw, you are aware that we have an --update-bootloader function on flash-kernel ?
 * ogra_ remembers you saying something about bootloader updates
<GrueMaster> That was either Karmic or Lucid on babbage.
<GrueMaster> I could look up the bug if you like.
<ogra_> ah, no, dont care :P
<GrueMaster> Bug 365053
<ubot2> Launchpad bug 365053 in flash-kernel "On armel (Babbage platform), kernel image upgrading breaks if Ubiquity is instructed not to install a bootloader" [High,Triaged] https://launchpad.net/bugs/365053
<GrueMaster> (I had the list open)
<ogra_> ah, that one
<ogra_> ancient crap
<ogra_> must have been karmic
<ogra_> no babbge in lucid iirc
<GrueMaster> yes there was.
<ogra_> hrm
<ogra_> right, we dropped it in maverick
<GrueMaster> Babbage & dove.  omap was an after-sprint bringup.
<ogra_> yeah, "tech preview image" and totally unsupported :)
<GrueMaster> Which reminds me, I had a notice in my inbox that ppsati was working on a Lucid omap bug.  Can you tell hime to not care?
<GrueMaster> Bug 588243
<ogra_> ppisati, stop caring !
<ubot2> Launchpad bug 588243 in linux-ti-omap "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! " [High,Confirmed] https://launchpad.net/bugs/588243
<ogra_> :)
<ogra_> i saw the bugmail too
<GrueMaster> I'm marking it as won't fix.  Lucid was a demo release on omap anyways.  I don't think we are on the hook for it, as it only supported Beagle C4.
<ogra_> yeah
<ogra_> good move
<ndec> ogra: on which package should we report bugs on the installer?
<ogra_> depends, when does your issue occur ?
<ogra_> everything after first reboot is ubiquity ... everything before first reboot is jasper
<ndec> ogra: ok. that answers it... i am just answering to someone on pandaboard ML,and wanted to ask to report bugs on LP...
<ogra_> the jasper package is actually jasper-initramfs
<GrueMaster> Yea for undecipherable ubiquity failures.  My oem-config crashed hard for some reason.  Probable a fs error, but no real indication.
<GrueMaster> Ah there it is, two pages up in syslog:  mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00
<GrueMaster> grmbl.
<ndec> ogra: just fyi. http://groups.google.com/group/pandaboard/browse_thread/thread/aa46ddf46df2d946
<GrueMaster> ndec: That looks normal, but I have been seeing some odd SD failures lately.  Not reproducable, just seemingly random.
<GrueMaster> Usually flashing SD over a different image will cause this (i.e. if I had kubuntu on there previously).
<GrueMaster> reflashing seems to clear it up.
<lool> ogra_: "pong"
<rsalveti> jcrigby: ogra_: tested the u-boot fix on B5 and it's now working fine with all beagle revisions
<rsalveti> jcrigby: so I believe we should fix this asap, if still possible for natty
<rsalveti> ogra_: do you know if we can we still upload package fixes?
<jcrigby> rsalveti, if ogra_ could do the upload that would be great
<jcrigby> or we can ask some other person with upload rights
<rsalveti> ogra_: janimo: NCommander: anyone? ^
<rsalveti> need someone to sponsor an u-boot update, that has a fix for beagle b5
<janimo> rsalveti, link?
<janimo> I'll get around to it in the next few hours unless someone else grabs it
<rsalveti> bug 760350
<ubot2> Launchpad bug 760350 in u-boot-linaro "2011.03 doesn't boot anymore on Beagle B5" [High,In progress] https://launchpad.net/bugs/760350
<rsalveti> code https://code.launchpad.net/~jcrigby/ubuntu/natty/u-boot-linaro/new-
<rsalveti> proposed-2011.04.2
<rsalveti> jcrigby: is this the one to merge?
<janimo> so basically needs a merge to main u-boot tree in LP?
<janimo> then upload a package?
<jcrigby> https://code.launchpad.net/~jcrigby/ubuntu/natty/u-boot-linaro/new-proposed-2011.04.2
<jcrigby> yes
<janimo> were there deps tested as well?
<janimo> jcrigby, debs I meant
<GrueMaster> Gahhh.  oem-config has crashed 5 times now on 3 different SD cards (different brands, sizes, & speeds).  This is getting very frustrating.
<GrueMaster> And it is only the netbook image that crashes.
<janimo> GrueMaster, core dumped?
<GrueMaster> And not always.
<GrueMaster> No
<jcrigby> rsalveti, its new-proposed, the old proposed was deleted
<rsalveti> janimo: yes, I tested the produced debs with my beagles and panda
<GrueMaster> I wonder if this is causing the problem:  ubiquity: debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable
<GrueMaster> Hmmm.  /var/log/Xorg.0.log.old:  Segmentation fault at address 0x1be
<GrueMaster> Beyond that, I am not seeing anything tangable.
<rsalveti> GrueMaster: is this with panda?
<GrueMaster> yes.
<rsalveti> GrueMaster: do you know if you're always getting the seg fault at the xserver?
<rsalveti> or it breaks randomly?
<GrueMaster> No.  Sometimes I get SDIO errors.  This was the first time I saw the sxerver segfault.  I'm not sure where the issue is, as it is random.
<GrueMaster> Watching oem-config run is like watching water boil.
<GrueMaster> It would be nice if there was a log level that could be tweaked to show each stage in the log.  Might be easier to track down that way.
<GrueMaster> The symptom I am seeing is after oem-config takes user-input, it starts configuring things.  Next time I glance over (5 monitors remember), it is back at the start of oem-config.
<rsalveti> GrueMaster: any error or warning at the kernel log for this time you got a crash at the xserver?
<GrueMaster> Nope.
<GrueMaster> At least not this last time.
<rsalveti> GrueMaster: which image are you testing? will try to run the installer with different sd cards to see if I can reproduce this problem
<GrueMaster> Yesterdays (20110418).
<GrueMaster> But I saw it (less frequent) with beta 2.
<rsalveti> ok, will give it a try
<rsalveti> urgh, 27kB/s
<GrueMaster> Copying installation logs...and fail.
<GrueMaster> So right around where it goes to uninstall.
<NCommander> rsalveti: can't easily sponsor at the moment (GPG smartcard support is hosed on my machine), unless its an absolute priority
<jcrigby> rsalveti, if ogra is gone for the day and there is no one else that can merge/upload the uboot fix then slangasek can do it
<GrueMaster> rsalveti: Trying yet again.  This time with debug-oem-config.  It usually just passes with this setting, but we'll see,
<rsalveti> jcrigby: sure, let's wait to see if janimo can help us, then we can ask slangasek later if needed
<janimo> rsalveti, jcrigby I just came back
<rsalveti> GrueMaster: still downloading here...
<jcrigby> ok, thanks
<janimo> I'll do the merge now
<jcrigby> janimo, great! thanks
<janimo> argh
<janimo> ssh key issue.
<janimo> I need to fix this now (I was hoping failing pushes to github were transitory, but apparently LP does not work either)
<janimo> phew, ssh-add and it works. No idea why the agent got confused
<FatTire> anyone else having regulatory domain issues in 11.04 on pandaboard?
<GrueMaster> Hmmm.  It worked...sort of.  With debug-oem-config, it gets to the same failure point (copying configuration logs) and restarts X, only this time it booted into unity-2d.
<FatTire> no?  Wifi works for everyone?
<GrueMaster> oem-config is still installed (as is all of the other packages that it usually removes).   the oem-config.log indicates errors with dbus setting up gconf.
<GrueMaster> ubiquity-dm may have been the cause of the segfault.  Not sure.  /var/log/installer/dm is very vague, as is Xorg.0.log.old.
<GrueMaster> And no filesystem errors or sdio errors.
<GrueMaster> It may be related to Bug #758910 but I have no crash logs to determine with.
<ubot2> Launchpad bug 758910 in ubiquity "oem-config-remove-gtk crashed with SIGSEGV in gdk_window_enable_synchronized_configure()" [Undecided,New] https://launchpad.net/bugs/758910
<rsalveti> could be
<GrueMaster> Hmmm.  Looking at the changelog for the next release:* GTK frontend:
<GrueMaster>     - Avoid a crash if the automatic partitioning page is never displayed.
<GrueMaster> All this time wasted just to try to reproduce an issue with the linux-image update not running flash kernel.  What a PITA.
<GrueMaster> That's what I thought.  Been on this now for 6 hours straight.
<GrueMaster> And my original mission has just been reproduced:  updating kernel still does not run flash-kernel.
<janimo> merged, but having issues with packaging (after all these years)
<janimo> confused by u-boot-linaro having debian/ inside and having to create orig tarball by hand
<janimo> jcrigby, rsalveti package uploaded and waiting for approval
<rsalveti> janimo: awesome, thanks a lot
<janimo> rsalveti, you're welcom
#ubuntu-arm 2011-04-20
<GrueMaster> so, NCommander stepped in to help and see what the problem with the installer was.  And it didn't fail.  Nothing changed, I reflashed with the same image & same cmdline to the same SD card.  Booted on the same panda.
 * GrueMaster is very frustrated.
<iceberg303> I'm having an issue booting 10.10 on a pandaboard, but the nightly build of 11.4 boots but isn't stable. Anyone have any ideas what might be going on?
<diwic> ogra, any news about omap4 sound?
<ogra_> diwic, well, ndec told me yesterday that capture doesnt work yet, seems the jack is configured as mono line in, so mics dont work.
<diwic> ogra_, and we're unable to reconfigure in software?
<ogra_> apparently
<diwic> ogra_, fair enough, do you have a possibility to test the mono line in then?
<ogra_> i'm not sure if/how my mp3 player would work on it and i need to find a matching cable first
<diwic> ogra_, line out connections are optimal to loop into a line-in, but headphone outs suffice as well.
<ogra_> well, that still requires a cable ;)
<ogra_> i know i have one but dont know where
<arun_> with the natty images, is hdmi audio on  the pandaboard expected to work?
<ogra_> i dont think anybody has had the ability to test that yet
<ogra_> we are currently focusing on getting analog audio to work
<ogra_> diwic, cable found, i can record mp3's just fine playing them from my phone
<ogra_> diwic, so HiFi and Record are the verbs we want
<ogra_> diwic, udev rules tested too
<diwic> ogra_, so we have working recording also? Great! Will you attach the udev rule patch (preferrably as a debdiff) to the bug and poke TheMuso to upload it?
<ogra_> diwic, well, the soundcard rules are all in udev not in alsa
<ogra_> i just pinged pitti about it in -devel
<diwic> ogra_, in fact if you make your own udev rule file you can put it in any package you want
<ogra_> i think adding the two lines to /lib/udev/rules.d/78-sound-card.rules is the right thing to do
<ogra_> diwic, my prob is that i dont have any arch specific package i could put it in
<diwic> ogra_, ok
<diwic> ogra_, so now we have realized we can have working playback and recording without the PA patches. So then the question is, what do we gain from having the PA patches in?
<diwic> ogra_, (especially if the PA patches can't even set a verb correctly...)
<ogra_> diwic, heh, you are behind, see the bug :)
<ogra_> i already commented about that, pulse can wait for O or go into a SRU if anyone has a plausible explanation why we need them
<ogra_> pitti says the udev rules need to come from alsa :/
<ogra_> (since it ships alsaucm and the rules exec that)
<diwic> ogra_, yeah, I agree
<diwic> ogra_, I'd try 90-alsa-restore.rules
<diwic> that ships with alsa-utils
<ogra_> ah, i was thinking to actually have 90-alsa-ucm.rules
<ogra_> from scratch
<diwic> that works just as well for me
<ogra_> smells cleaner to me
<diwic> yep, go for it
<diwic> although that add/change logic of the soundcard initialization is mindboggling.
<ogra_> i'm trying a file with just the two lines
<arun_> ogra_, gotcha. thanks for the info.
 * ogra_ twoddles thumbs while the panda reboots
<ogra_> yup, works fine
<diwic> ogra_, as for the HDMI audio, you don't have an hdmi-audio capable monitor for testing?
<ogra_> i have to re-arrange my whole setup to have the panda on my tv
<diwic> ogra_, ok, and I have to go in 30 mins :-)
<ogra_> and HDMI can well be an SRU
<ogra_> if there is even one needed
<ogra_> hmpf, how does alsa-utils install the rules file
<ogra_> diwic, do you mind if i just put the file in the debian dire and cp it in place from debian/rules ?
<ogra_> *dir
<arun_> i can give it a shot. my panda's connected to my tv.  i'd have to re-image my sd card though. i was playing around with various linaro images.
<diwic> ogra_, I'm trying to figure out how the udev rule file gets there
<ogra_> seems the restore file is handled by autotools, i really dont want to add complexity
<ogra_> its in the Makefile of alsactl
<diwic> right
<diwic> yeah, I guess an "install -d" in debian/rules would do
<ogra_> right, no extra autofoo run :)
 * diwic is going to add a AC_MESS_UP_FOR_DISTRO_MAINTAINERS macro in autoconf. It is not difficult enough to get it right
<ogra_> heh
<ogra_> bah, sigh ... tetex is a build dep to even roll the source package
<diwic> ogra_, hmm, as an option you could submit a merge proposal against lp:~ubuntu-audio-dev/alsa-utils/ubuntu.natty
<ogra_> doe sthat look ok ? http://paste.ubuntu.com/596500/
<diwic> ogra_, hmm, missing specification of desired file mode perhaps
<diwic> i e permissions
<ogra_> like that http://paste.ubuntu.com/596504/ ?
<diwic> ogra_, hmm, it doesn't exactly look like what I'm used to but probably it's correct anyway
 * diwic has to go
<ogra_> well, it ends up in the right place
<ogra_> with the right perms, i just did a testbuild
<ogra_> diwic, would you mind if i uploaded ?
 * ogra_ would love to have the bug closed 
<diwic> ogra_, oh I see now, you are not filtering out subsystem, add/change etc in the udev rule
<ogra_> well, there will only be one device with that ID
<diwic> ogra_, I'll be back in 2-4 hours or so
<ogra_> but i can add the headers that are used in the soundcard rules
<ogra_> ok
<ogra_> do you want add/change etc ?
 * ogra_ adds the lines from the other rules fine and tests 
<diwic> ogra_, reviewed your merge proposal, please fix
 * ogra_ checks
<ogra_> weird
<ogra_> diwic, hmm, i dont have any such changes in my local branch and http://bazaar.launchpad.net/~ogra/alsa-utils/746023/revision/75 doesnt show any of the bits you mention
 * ogra_ wonders if he used a wrong master branch 
<diwic> ogra_, please remove the ENV{SOUND_INITIALIZED} in 90-alsa-ucm.rules
<diwic> In best case, it's superfluos :-)
<diwic> or maybe I could just do that for you and merge it into the alsa-utils branch :-)
<ogra_> new branch pushed, indeed i didnt pull originally from the right branch
<diwic> been there, done that :-/
<ogra_> http://bazaar.launchpad.net/~ogra/alsa-utils/746023/revision/89
<diwic> ogra_, I removed one more line, could you verify it's still working? See https://code.launchpad.net/~diwic/alsa-utils/ubuntu.natty
<ogra_> will do, that takes a moment though since i'm just verifying a bug on the headless image
<ogra_> look sane though
<ogra_> *looks
<ogra_> grr
<ogra_> so after trying to boot an omap headless image for 20 min on the panda i found that the omap MLO doesnt work on omap4 :P
 * ogra_ shakes his head about wasting his own time
<GrueMaster> heh.
<ogra_> well, at least we know now :P
<ogra_> GrueMaster, when you had that flash-kernel issue, did that happen when you manually upgraded a linux-image package or was that a regular dist-upgrade
<GrueMaster> Both apt-get install & dist-upgrade.
<ogra_> hmm
<ogra_> might be the old "flash-kernel isnt run when update-initamfs -c is used"
<GrueMaster> I thought that we were told that it needs to come from the kernel?
<ogra_> GrueMaster, for now i only have bug 746023, bug 747229 and 766764 on my release radar
<ubot2> Launchpad bug 746023 in alsa-utils "No sound on omap4" [High,In progress] https://launchpad.net/bugs/746023
<ubot2> Launchpad bug 747229 in debian-installer "weird color change during oem-config debconf package removal step in serial installs" [Medium,Incomplete] https://launchpad.net/bugs/747229
<ubot2> Launchpad bug 766764 in linux-ti-omap4 "flash-kernel not run during kernel upgrade" [Undecided,New] https://launchpad.net/bugs/766764
<ogra_> am i missing anything important ?
<GrueMaster> Which type of beer to bring me to UDS.
<ogra_> GrueMaster, the kernel package wasnt changed in natty, i added a spec idea for exactly that prob
<ogra_> so -c still doesnt work
<ogra_> but that should actually only affect release to release upgrades
<GrueMaster> That is bug 701698.
<ubot2> Launchpad bug 701698 in boot "update-initramfs -c does not update the bootloader" [High,Triaged] https://launchpad.net/bugs/701698
<ogra_> yep
<ogra_> that requires massive redesign of the whole arm bootloader handling
<ogra_> which is why i want to make it a spec
<GrueMaster> Go for it.
<ogra> diwic, works fine, go for it
<diwic> ogra, TheMuso, ok, I've test-built and test-run it on my machine here, and it didn't seem to have destroyed anything, so pushed to lp:~ubuntu-audio-dev/alsa-utils/ubuntu.natty - upload at will.
<ogra_> wohoo
<ogra_> diwic_afk, TheMuso, uploaded, thanks
<ogra_> GrueMaster, just dist-upgraded a beta2 image to todays archive, no issues with flash-kernel
<GrueMaster> I think there are other packages that force update-initramfs -u.
<ogra_> might be
<GrueMaster> Try installing everything that dist-upgrade recommends, except the kernel.  Then do dist-upgrade.
<ogra_> to late :)
<GrueMaster> I'll try it here to verify in a little bit.  Currently wiping/reformatting my SD.
<ogra_> \o/
<ogra_> alsa-utils is in
<ogra_> and python-apt too
<ogra_> so sound and sources.list should be fine now
<GrueMaster> cool
<GrueMaster> Now if we could just get another daily image to build...
<ogra_> we only have the serial colors left (which is really minor cosmetic) and the Ã¼possible flash-kernel thing
<ogra_> archive is messed up due to the last minute fixes
<ogra_> that will settle until tomorrow
<iceberg303> I have the 10.10 ubuntu on a 4G sd for pandaboard(omap4) and things were ok till I did an update. Things started taking forever to boot and to log in, then I installed the ti omap extras and now it takes about 15min to boot and 30+min to log in.  I can wipe the card and go back no problem but every time I get the same results.  Is there a list of things that should not be updated?
<jayabharath> ogra_: there have been a few reports on natty beta's not working on pandaboard's are there any known major issues that you are aware of... before I go give it a run
<billfarrow> Hey, is anyone using the genesi efika mx smartbook ? are you happy with it ?
<billfarrow> I was looking for a new netbook, and this looked interesting since I am already developing for an i.mx processor at work.
<davidm> jayabharath, as best I know we are good to go on B2
<davidm> jayabharath, it's quite late in ogra's neck of the world
<GrueMaster> jayabharath: The only thing I really am aware of is random issues with the SD cards.  Sometimes I'll get SDIO errors during oem-config, other times oem-config will just crash mid-install.  Nothing to indicate why.  Reflashing usually clears it up.
<GrueMaster> I am working on a theory, but since the issues I am seeing are so random and hard to reproduce, it is harder to have a good testcase.
<jayabharath> GrueMaster: davidm I see.. thanks
<jayabharath> let me look up the recent thread on pandaboard ml for reference
<GrueMaster> http://groups.google.com/group/pandaboard/browse_thread/thread/aa46ddf46df2d946
<GrueMaster> Already commented on it.  :)
<jayabharath> GrueMaster: u r faster .. yeah this was one...
<GrueMaster> I had it open.
<jayabharath> let me then try b2 image and see if it works ok for me.. thanks!!
<TheMuso> ogra_: Thanks.
#ubuntu-arm 2011-04-21
<dcordes> 19:15 < ogra_> archive is messed up due to the last minute fixes
<dcordes> 19:15 < ogra_> that will settle until tomorrow
<dcordes> is this discussion about natty netbook images ?
<Neko> hey guys, anyone know off-hand what spec the builders are?
<Neko> trying to figure if it took 2 hours to build something on a buildd for the main repo, how long it'd take on an MX53....
<GrueMaster> dcordes: yes.
<GrueMaster> Neko: The buildds are MX51 mostly.
<GrueMaster> But the new systems will be omap4.
<dcordes> GrueMaster: I'm looking to test latest natty omap4 build on my phone. Is it a good moment to download an image ?
<GrueMaster> Latest daily is 20110418.  Should have a new one later tonight assuming the pool churn has settled.
<dcordes> Pool churn :) ?
<GrueMaster> Won't know for a couple of hours.
<dcordes> I will check back after CET night nap. Do you have a URI for me ?
<Neko> hmm so.. almost exactly the same time to build on an Efika MX then.. well shit, 2 hours still isn't bad.. I have an hour to go ;)
<GrueMaster> Whenever a package is updated in the pool and it has dependencies that rebuild, the image build will die due to dependency failure.
<dcordes> Ah seems familiar from the openembedded workflow.
<GrueMaster> dcordes: http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/
<Neko> is there some magic documentation on "how to make a buildd for ubuntu"?
<Neko> I mean apart from the debian stuff
<GrueMaster> Not sure.  I have just installed pbuilder and all of its dependencies.
<GrueMaster> I would recommend a minimal image to begin with.
<Neko> well dropping a minimal image and pbuilder on a system is the easy bit :]
<GrueMaster> Yep.
<Neko> hang on
<dcordes> GrueMaster: Thanks!
<dcordes> bbl
<GrueMaster> If you are looking for an automated buildd environment, I can't help.
<Neko> well my main point of curiosity is, how on earth do I submit jobs, because I can't find that bit..
<Neko> in theory it should just magically use the chroot, pull in a ton of packages from the archive and go build it and report back, right?
<Neko> but where do I "click to start"? :D
<GrueMaster> Are you looking to create your own buildd automated environment or just to rebuild a few packages?
<Neko> where a few amounts to about 50 which may take a few days, yes
<GrueMaster> If the latter, pbuilder will do it quite nicely.
<Neko> I'm just at the point that I don't want to build them by hand
<GrueMaster> First, use it to generate a chroot tarball.  Then you can build packages.
<Neko> consider that done
<Neko> as if I have like 20 boxes here all networked and happy and "ready"
<GrueMaster> For the distributed build environment, I believe we use soyuz (part of launchpad).
<GrueMaster> And I don't know how it works.
<Neko> so how does debian do it
<GrueMaster> Not sure.  I just do QA and sometimes I do FTBFS debugging.
<GrueMaster> You might look at apt-cache search buildd.  There are tools in the pool for building a build environment.
<GrueMaster> Not sure if it scales to multiple systems.
<GrueMaster> Hmm. Buildbot may be what you are looking for.
<prpplague> OT: 555 timer contest winners are being announce live now - http://www.nymphs.org/Jeri/
<ogra_> Neko, the ubuntu buildds use launchpad and soyuz, pull their source and find how to set them up and you have ubuntu buildds ;)
<ppisati_> ogra_: does your panda board reset when you press the reset button? mine seems to die and the only way to revive it is to pull the power plug
<ogra_> mine resets fine
<ppisati_> doh
<ppisati_> Texas Instruments X-Loader 1.4.4ss (Mar 18 2011 - 14:14:59)
<ppisati_> U-Boot 2011.03-rc1 (Feb 09 2011 - 01:46:42)
<ppisati_> yours?
<ogra_> ppisati_, whatever is in the archive
<ppisati_> ogra_: uhm, tried older X-loader/u-boot and actually didn't change
<ogra_> right
<alf_> Hi all! I am getting a segfault while running ldconfig on panda. Is this something known?
<alf_> The interesting thing is that it happens only if I run it when I am root... with sudo it runs fine.
<alf_> Hmm, I just rebooted after a dist-upgrade and I am getting "(stk) :line disc installation timed out" and some other messages and the board is not booting :/
<alf_> it is booting after all but only to a console, no X...
<ogra_> sounds like a corrupted Sd or some such
<alf_> ogra_: I think I am done with sd cards... Does the ubuntu kernel support booting the rootfs over nfs?
<ogra_> it should
<ogra_> needs an initrd though, since i think the NIC driver is modular
<ppisati_> ok, kexec is broken on ti-omap4 too
 * ogra_ wouldnt have expected any differently
<ppisati_> fine, i have my new toy :)
<ppisati_> ah!
<ppisati_> if i press the reset button, the board goes into this "dead state"
<ppisati_> then if i take out and put in again the sd card
<ppisati_> it restarts normally
<ppisati_> weird
<alf_> ogra_: I am going to follow the instructions in https://help.ubuntu.com/community/DisklessUbuntuHowto to get rootfs over nfs for panda? Any better ideas?
<ogra_> alf_, looks a bit outdated, and indeed you need kernel and initrd locally (tftp wont work for either)
<alf_> ogra_: yes, I will keep those on the sdcard first partition
<ogra_> (that doc is like 3 or 4 releases old ... or even older)
<alf_> ogra_: well, I only really care about the initramfs part. Is this still valid?
<ogra_> you only need BOOT=nfs ... but you can set that as boot=nfs on the kernel cmdline
<ogra_> no need to re-roll your initrd for that
<ogra_> and you need to set nfsroot= to point to your server and rootfs path (also on cdmline)
<ogra_> boot=nfs root=/dev/nfs nfsroot=<serverip>:<path>
<ogra_> that should work
<ogra_> not sure the root= is actually needed though, boot=nfs should take care
<alf_> ogra_: ok, so the plan is (please correct me) 1. Flash new ubuntu image 2. Boot, get past resizing and first config 3. copy rootfs to nfs export dir 4. fiddle with kernel params in boot.scr to load from nfs
<ogra_> sound right
<ogra_> at least thats how i would do it
<alf_> ogra_: great, thanks! I will try it and keep you posted.
<ogra_> great, i have a thin client spec for next release, i'll treat your work as first test for that *g*
<alf_> ogra_: excellent, I am going to be the lab rat :D
<ndec> alf_: http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#I_want_to_install_Ubuntu_on_external_USB_hard_disk_instead_of_sluggish_SD_card that might help.
<alf_> ndec: thanks!
<ndec> alf_: that what I use, and it's really a good setup. very fast, very reliable so far. you need to keep the SD in the slot because it is still the boot partition. flash-kernel works fine too
<alf_> ndec: do you think it is going to be faster than nfs?
<ogra_> its at least a good stress test for your usb controller :)
<ogra_> (and likely faster, yes)
<ndec> alf_: i don't really know.
<ogra_> i guess it depends on your network
<alf_> ogra_: direct connection from panda to desktop ;)
<arun> i'll have to give the usb drive a shot.
<spikebike> I wonder if the panda board will work with a sdhc uhs-i card
<alf_> ogra_: I am getting this http://paste.ubuntu.com/596949/ . Any ideas? (/etc/fstab is: http://paste.ubuntu.com/596952/)
<ogra_> i dont see a rootpath
<ogra_> try specifying rootserver and rootpath separately instead of nfsroot
<ogra_> also did you try to ping the board from the PC once it is at that point, to make sure the net connection works ?
<alf_> ogra_: so, I added no_root_squash to the NFS export options and at least I am not getting any errors now. Unfortunately it is still gets stuck after "Begin: Running /scripts/init-bottom ... done"
<alf_> ogra_: an wireshark dump shows that it can access the nfs fine, but just stops after a while
<ogra_> strange
<alf_> ogra_: I have set eth0 and wlan0 to manual in /etc/network/interfaces in case network-manager messes things up but I don't think it gets that far
<Neko> ogra, reverse engineering launchpad vs. reading documentation? no thanks
<Neko> I put the rookie on it instead..
<ppisati_> GrueMaster: bugs https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/758961
<ubot2> Launchpad bug 758961 in linux-ti-omap4 "WARNING: at /build/buildd/linux-ti-omap4-2.6.38/drivers/tty/tty_mutex.c:31 tty_lock 0x30/0x4c()" [Medium,New]
<ppisati_> GrueMaster: what did you do to get this one?
<GrueMaster> Nothing.  Just booted.
<GrueMaster> Haven't seen it since then though.
<GrueMaster> You do see my comment on the bug, right?
<ppisati_> GrueMaster: there's only #3 as comment
<ppisati_> GrueMaster: anyway, if there's no way to reproduce it
<ppisati_> GrueMaster: better if i look for something else
<iceberg303> 'm having an issue. I am using the image "ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img.gz" After I do an update it gets low, then when I install the ti omap4 extensions when I click my login it locks up before I can type a password
<Flipo> Hello, on a pandaboard I'm able to get audio through HDMI but not the normal audio jacks, is there  a workaround ? Thanks
<GrueMaster> Flipo: Which image are you using?
<GrueMaster> Fixes for audio went in this week and will be in 11.04 final.
<Flipo> GrueMaster: I'm using the suggested build for the pandaboard
<GrueMaster> iceberg303: What size SD card are you using?
<iceberg303> GrueMaster: is there a non netbook build of 10.10 and 11.4 for the omap4 pandaboard?
<iceberg303> it's a sandisk extreemIII
<iceberg303> 8GB
<iceberg303> I also have a patriot
<GrueMaster> For 10.10 there is only the netbook image.  For 11.04 we have introduced a headless minimal image.
<iceberg303> 8G as well
<Flipo> I might just wait for that then
<GrueMaster> Flipo: I have no idea what the suggested image is that you are referring to.  Either 10.10 (Maverick) or 11.04 (natty).
<Flipo> GrueMaster: the suggested image is 10.10 netbook edition
<GrueMaster> If 10.10, you should be able to get audio working with updated packages.
<Flipo> (site seems down right now)
<Flipo> I have it working fine over hdmi but the built-in soundcard doesn't seem to work
<GrueMaster> I think the audio works in the updated kernel & alsa-utils packages.
<GrueMaster> They didn't make the 10.10 release.
<Flipo> if I do a normal system update via gui will I get the updated kernel or do I need to do further steps ?
<GrueMaster> I think you should be able to get all the updates through update-manager.
<rsalveti> Amaranth: are you planning to merge the gles support upstream? or did you send the merge proposal already?
<rsalveti> just to understand better the current status of the port
<sewardj> is it possible to run the 11.04 beta on QEMU ?
<sewardj> as a guest, on qemu-system-arm, i mean
#ubuntu-arm 2011-04-22
<Amaranth> rsalveti: All the plugins need to be ported before i can get it merged
<rsalveti> Amaranth: oh, ok
<ndec> ogra_: rsalveti: i am going to be late for today's call.
<ndec> maybe by 30min.
<ogra_> ndec, i wouldnt mind skipping today, its a public holiday in brazil and germany ... and david is on the road
<ndec> ogra_: ok. let's skip then. that makes my agenda much simpler too ;-)
<ogra_> cool ! :)
<ogra_> ndec, first shot of the final images is already on cdimage btw
<ogra_> (todays dailies are the first candidates)
<ndec> ogra_: ooh! earlier than for maverick ;-)
<ogra_> yeah, we have a new release manager, she is very cautious ... and the easter weekend kind of gets in the way too
<ogra_> thats also why we have no release candidate but two betas this time
<miru_> Hi, the latest ubuntu natty omap4 headless image (daily build) gets stuck during installer. After the "Where are you?" "Is your clock set to UTC?" the installer jumps back to the language selection dialog.
<miru_> I need some help on how to help out. How do analyze the issue and does it make sense to submit a bug-report. if yes, where?
<GrueMaster> miru_: I'm just rising from the dead.  As soon as I get my coffee, I'll take a look and see where the problem is.  Couple things you can do is after the system crashes, pull the SD and check the logs from your desktop/laptop.  Also, you could add debug-oem-config to the bootargs in the boot.scr on the first partition.
<GrueMaster> (if you'd rather not get into all that, give me a few minutes and I'll be up to speed).
<miru_> I'm new to the Pandaboard, so please be patient with me ;) I will try to set the parameter in the boot.scr (will be my first time)
<dcordes> Hi
<dcordes> GrueMaster: you gave me some advise on natty arm image recently. Is it a good point to download now or should I still wait ?
<GrueMaster> dcordes: The latest daily images are the first candidates towards final release.  There may be some glitches, but for the most part they should be very stable by now.  Jump in, the pool's warm.  :)
<GrueMaster> miru_: No problem.  What do you have for a desktop system?
<miru_> Ubuntu 10.10
<dcordes> GrueMaster: http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20110422/ ?
<GrueMaster> perfect.  Install the uboot-mkimage package and you can use it to make boot changes to your image.
<GrueMaster> dcordes: Yes, also  http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/20110422/ if you want to run a minimal image.
<miru_> OK, done
<dcordes> GrueMaster: I'm particularly interested in trying the new desktop enironment on my small screen device to test it vs gnome
<GrueMaster> dcordes: What is the base hw?
<dcordes> GrueMaster: htcleo aka HTC HD2 with qsd8250 SoC (cortex-a8) wvga screen
<GrueMaster> I have no idea if our images will work with that.
<dcordes> they do
<GrueMaster> I don't know if there is a kernel for that soc.
<GrueMaster> Oh, cool\
<GrueMaster> miru_: I've gotten to that point of failure, and am looking at the logs now on my desktop.  var/log/oem-config.log has an interesting failure in it.
<miru_> OK. Everything gets slowed down today because pandaboart.org is down :(
<dcordes> GrueMaster: I tested maverick extensively on the device
<dcordes> GrueMaster: even including multitouch which is documented on lp
<GrueMaster> I think we now have support for multitouch in the natty images.  Let me know how it works.
<dcordes> GrueMaster: then my timing to join the pool party is good :)
<dcordes> GrueMaster: I will let you know but it will take a while. first the image needs to pass the dormitory network..
<GrueMaster> heh
<miru_> Is that the right way to call the mkimage command: mkimage -A arm -T script -O linux -a 0 -e 0 -n /media/sde2/boot/boot.script -d /media/sde1/boot.scr boot.scr
<miru_> It seems I got it right, There is a file /var/log/oem-config.log with some Python exceptions.
<miru_> GrueMaster: with interesting failure you mean "locale.setlocale failed: unsupported locale settting (LANG=de.DE.UTF-8)"?
<GrueMaster> Here's what I do.  To edit the boot.scr, "dd bs=72 skip=1 if=mnt/boot.scr of=boot.script".  Then edit the file and save it.
<GrueMaster> To put it back into the uboot partition, use "sudo mkimage -A arm -O linux -T script -C none -d boot.script mnt/boot.scr"
<GrueMaster> miru_: What I am seeing in the oem-config.log with debug-oem-config is mostly the same as without debug.  But I think it is a locale issue.
<miru_> ok. Do you have an idea how to work around this issue?
<miru_> The actual problem I was investigating is that my USB devices were not enumerated/detected
<miru_> I was hoping that the latest image might fix the issue
<GrueMaster> This is the first time I have seen this issue.  I'll try an older daily though to see where it started showing up.
<GrueMaster> (I mirror the daily builds from release to release).
<miru_> Hm, but no. When I run dmesg, I still see the error: "ehci-omap ehci-omap.0: detected XactErr len 0/8 retry 16"
<GrueMaster> If you need to get up and running, try the Beta 2 image in http://cdimage.ubuntu.com/ubuntu-headless/releases/natty/beta-2/
<GrueMaster> Then once you are running, apt-get update;apt-get dist-upgrade.
<miru_> ok, I will try that
<miru_> :( same issue with the beta2. USB does not get detected and because the USB ports and the ethernet port are somehow related it seems as if the network does not come up either.
<miru_> [    1.569946] usb 1-1: new high speed USB device using ehci-omap and address 2
<miru_> [    1.710571] usb 1-1: device descriptor read/64, error -71
<miru_> [    1.952789] usb 1-1: device descriptor read/64, error -71
<GrueMaster> That's strange.  My network works just fine here.
<GrueMaster> You may need to configure networking manually.
<GrueMaster> miru_: How are you powering your panda?
<miru_> I have a 30W (5V/4000mA) power supply.
<GrueMaster> Ok.  *should* be enough.
<miru_> But the whole USB/network jack seems to be without power. No network LEDs are blinking.
<GrueMaster> Check your cable.
<miru_> The same cable works on my notebook
<GrueMaster> Are you plugged into a switch or are you going system to system?
<miru_> a switch
<GrueMaster> Hmmm.
<GrueMaster> Beginning to sound like a bad board.
<miru_> :(
<GrueMaster> I tried earlier images here, and with the 20110418 image (same kernel) I am not seeing any usb errors.  Networking is fine.
<GrueMaster> Oh, and I may have a solution to the oem-config issue.  Reflashing now to test.
<miru_> maybe the power supply spec is wrong.
<miru_> OK, I need to get something to eat now. Thanks a lot for your help!
<GrueMaster> I'll be here for a while.
<GrueMaster> miru_: Bug #769081 filed.
<ubot2> Launchpad bug 769081 in ubiquity "oem-config-debconf crashes on armel headless due to undefined attribute." [High,Confirmed] https://launchpad.net/bugs/769081
<LetoThe2nd> miru_: double/triple check the ethernet check is actually really _completely_inserted and contacting, maybe by applying constant tension wirth your hand. mine also behaved like this concerning ethernet with a good cable. seems the jack manufacturer is a bit inconsequent on specs.
<Keripo> Hi, I was just wondering whats the expected boot time of 10.10 on a beagleboard-xM. I downloaded and zcat'd the preinstall image (from https://wiki.ubuntu.com/ARM/OMAPMaverickInstall ) to my 8GB SD card, put the card into my beagleboard, hooked up a USB keyboard and HDMI video, and powered the beagleboard on
<Keripo> I've been waiting for 10 mins so far but my monitor's still getting no HDMI signal (Angstrom booted fine on the beagleboard-xM)
<GrueMaster> There is a two-step boot process.  The first step resizes the rootfs to fill the SD card, then it will reboot into X with oem-config for you to make timezone, language, and user info.
<GrueMaster> Are you seeing any output on the screen?
<GrueMaster> Keripo: ^^^
<Keripo> GrueMaster: no, not at all, but I poked around and apparently there's a DVI issue for 10.10 for Beagleboard xm Rev A3 and B
<Keripo> dont know what revision my board is, but I'll try the patched files and see what happens
<GrueMaster> Yes, follow the instructions at https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
<GrueMaster> The problem is that the BeagleXM was released the week after 10.10, and they had a change in how DVI is enabled.  They didn't tell us until after release.
<GrueMaster> Also, we are testing 11.04 final images today.  Pull http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/current/ and give it a whirl.
<Keripo> GrueMaster - thanks, I'll check it out! Hope the packages that I'll be installing (Kinect stuff) will still be compatible ; )
<Keripo> GrueMaster: the prebuilt images for Natty are "headless", but do they still contain the normal video/mouse/keyboard drivers or will it terminal only?
<GrueMaster> It is setup to go through a serial console, but they do support keyboard video and mouse.  You will need to use the serial port to run through the initialization though.
<GrueMaster> And the oem-config is currently broken.  Bug 769081
<ubot2> Launchpad bug 769081 in ubiquity "oem-config-debconf crashes on armel headless due to undefined attribute." [High,In progress] https://launchpad.net/bugs/769081
<GrueMaster> If you want to try the headless image out immediately, use the beta 2 release.  it is fairly close to final.
<ScottK> GrueMaster: Speaking of which, can you grab the updated Ubiquity .deb and verify the issue is resolved?
<GrueMaster> I can look at the change that was updated.  Not easy to update an image before running oem-config.
<GrueMaster> Looking at the changelog, the changes made fix the issue.  I tested them manually.  I'll pull the package and see that it is changed there as well, but without an image respin...
<ScottK> OK.  We can just wait then.
<ScottK> I thought Ubiquity would update itself during install if the install was with Internet.
<GrueMaster> oem-config doesn't have that option on either the desktop or the headless images (doubt it is able to do that on any platform).  We don't use ubiquity in full.
<GrueMaster> Also, the headless image doesn't configure the network until the last step (after this failure has already occurred).
<ScottK> Right, forgot about the not using Ubiquity in full bit.
<GrueMaster> Heh.  We like being different.  :P
#ubuntu-arm 2011-04-23
<iceberg303> anyone using the 4/18 build of 11.04 and not seeing the wlan device show up?
<iceberg303> on a pandaboard
<GrueMaster> iceberg303: Try the 20110422 image.  It is closer to final, and it works on both of my panda's.
<iceberg303> ok, thanks
<iceberg303> I hadnt realized the 4-20 had been uploaded, the pandaboard and omap sites are down
<GrueMaster> You can get it direct from us here:  http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/
<iceberg303> yea but I dont check the images reguarly
<iceberg303> and I was just looking to see if there was anything after installing the extras I needed to get wifi up
<iceberg303> uuhf it took almost 15min to dl, my net is so slow tonight
 * dcordes is praying oem-setup gui got on screen keyboard
<miru_> Hi, can someone provide an excerpt from the boot.log on a pandaboard? I miss output of the smsc95xx and thus the ethernet does not seem to work.
<lilstevie> dcordes: me too
<dcordes> lilstevie: then I have bad news: it doesn't
<dcordes> a pity my bug report was ignored
<dcordes> I motivated to add onboard in the oem config setup
<dcordes> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/626055
<ubot2> Launchpad bug 626055 in smartphone "oem-config: make on-screen keyboard available" [Critical,Confirmed]
<dcordes> the menu bar has heavy glitches on my device with xf86-video-fbdev
<arune> davidm: whats the status of the pandaboard-ppa-cluster?
<lilstevie> dcordes: damn it,
<lilstevie> dcordes: what do you do for your images
<dcordes> lilstevie: I connect remotely via usb and run 'DISPLAY=:0 onboard' after the oem-config gui started
<dcordes> lilstevie: may I ask what hardware you have ?
<lilstevie> Galaxy Tab
<dcordes> ah I just held that in my hands in my provider's shop
<dcordes> did you boot a natty rootfs already ?
<lilstevie> sorta
<lilstevie> had probelms with the touch driver
<lilstevie> so I abandoned natty
<dcordes> ok
<dcordes> I also faced a problem
<lilstevie> but now I solved it at a kernel level I am almost ready to shoot forward again
<dcordes> so you have been using maverick before ?
<lilstevie> I use maverick daily
<dcordes> ok
<dcordes> I have also been using it frequently on my hardware
<lilstevie> I have a HD2 in my draw :p
<lilstevie> I followed your work up to magloader
<dcordes> ok :)
<lilstevie> I don't have baseband which sucks :(
<dcordes> so you are aware of the documentation at http://htc-linux.org/wiki/index.php?title=Ubuntu/Leo ?
<lilstevie> yeah :D
<lilstevie> I got my bluetooth working using some of thqt
<lilstevie> that*
<dcordes> cool I'm always glad to hear that there is a use of writing everything down
<dcordes> it would be nice to refer back to the wiki so others using your work can further improve it
<lilstevie> oh btw I don't know why it doesnt work for you but using that brcm_patchram_plus on the tab works
<lilstevie> it also solved my problem with why network-manager wasnt working
<dcordes> also feel free to add comments or a new seperate page with references to your device. there are other non-htc things documented in htc-linux.org wiki as well
<lilstevie> just out of curiosity was it the driver or the firmware that is causing that issue
<lilstevie> cause the Xoom uses the same wifi chip but it is id'd differently
<lilstevie> oh thats cool :)
<dcordes> you just have to register and beat captcha because we are spam plagued
<lilstevie> I have been piggybacking on meego wiki cause one of the meego porters and I share resources
<dcordes> meego to galaxy tab porters ?
<lilstevie> yeah
<dcordes> that makes senese
<ogra_> is there public kernel source for the galaxy ?
<dcordes> if you go from android to non-android on an android devices many steps are the same with varying userspace
<lilstevie> ogra_: yes
<ogra_> with all drivers ?
<lilstevie> ogra_: including pvr yes
<lilstevie> well minus rild
<ogra_> sweet
<ogra_> so you can run ubuntu natively (non chroot)
<ogra_> ?
<dcordes> guys I have to run :)
<dcordes> have fun
<dcordes> lilstevie: I will be back later. it would be nice to do some in-depth knowledge on the natty porting
<dcordes> kowledge exchange
<dcordes> bye
<lilstevie> ogra_: have been for a while
<ogra_> sweet
<ogra_> i might get one then
<lilstevie> few patches required to get native booting
<lilstevie> and working on writing direct to moviNAND to make installation easier
<ogra_> to the kernel you mean ?
<lilstevie> yeah
<ogra_> ah, well
<lilstevie> but I am working on reducing them too
<lilstevie> touchscreen needs to be fucked with hardcore
<ogra_> galaxy has only 512M, right ?
<lilstevie> ram?
<ogra_> yes
<lilstevie> yeah
<ogra_> hmm
<lilstevie> but at 1.4GHz it is good :p
<lilstevie> yet again that is a patch
<lilstevie> but works well
<ogra_> well, 1.4GHz doesnt help mugh if you start swapping :)
<ogra_> *mush
<ogra_> bah
<lilstevie> heh
<lilstevie> I have no swap
<lilstevie> i dont trust the FTL enough
<ogra_> so you let your browser just crash after the 20th tab ?
<lilstevie> haha
<lilstevie> I don't open that many tabs
<lilstevie> is there anything that utouch is expecting to go multitouch
<ogra_> proper kernel drivers i guess
<lilstevie> heh I am working on that part
<lilstevie> android spec is so far from x
<ogra_> there is #ubuntu-touch or so
<ogra_> or #ubuntu-multitouch, not sure
<ogra_> but the touch team definitely has an IRC cannel
<lilstevie> #ubuntu-touch, just joined
<iceberg303> I am trying to use the latest 11-04 build with a pandaboard and the wlan device does not show up at all, and I have nothing in dmesg about it
<iceberg303> anyone else have any issues or know anything?
#ubuntu-arm 2011-04-24
<GrueMaster> It works fine here.  I have it working in the netbook image and in the headless image after installing wireless-tools.
<iceberg303> GrueMaster:  mine does not wireless-tools are already installed, the complete omap4 extras are installed and still Im unable to get any wireless functions. On top of that the wired LAN changes mac addresses every time the thing goes to sleep or is reset.
<iceberg303> pandaboard.org and omappedia.org seem to be back up for now
<dcordes> lilstevie: ping
<lilstevie> dcordes: pong
<dcordes> lilstevie: did you experience graphical problems with unity ?
<dcordes> lilstevie: the menu bar in the left of the screen glitches heavily on my hd2
<lilstevie> I have no 3D
<lilstevie> still working at adapting that
<lilstevie> installing natty at the moment
<lilstevie> still trying to figure out how I am going to step through oem-config
<dcordes> ok then I understood you wrong
<dcordes> I thought you ran natty already.
<lilstevie> I had, but not in a usable form
<dcordes> what's wrong with 'DISPLAY=:0 onboard' in oem-config ?
<lilstevie> is there a script that I can add that to?
<dcordes> why not running it manually via ADB ?
<lilstevie> cause my usb gadget is fucked
<lilstevie> the samsung proprietry init binary tickles the kernel driver
<dcordes> can you pastein the .config ?
<lilstevie> yeah
<dcordes> what is samsung proprietry init binary ?
<lilstevie> http://pastebin.com/4Q605Y1g
<lilstevie> init in the android ramdisk
<lilstevie> it is not opensource
<dcordes> initramfs ?
<dcordes> (aka initrd)
<lilstevie> /init
<lilstevie> in the initramfs
<dcordes> I assume you can't flash your own initramfs ?
<lilstevie> it gets embedded in the kernel
<lilstevie> that isnt the problem
<lilstevie> the init binary does the work
<lilstevie> the init binary does a lot
<dcordes> embedded in the kernel.. are you talking about the android flash tools mkboot etc ?
<dcordes> fastboot
<lilstevie> we have none of that
<lilstevie> the initramfs gets compiled into the kernel
<dcordes> lilstevie: any further reading on that & kernel etc in glaxy ?
<lilstevie> theres the threads on XDA-dev
<lilstevie> devs*
<lilstevie> the kernel is similar the the galaxy s
<lilstevie> and the kernel source is available from opensource.samsung.com
<lilstevie> and my mods included are https://github.com/lilstevie/linux_kernel_galaxytab
<phh> rsalveti: i've been told that you somehow worked on xbmc/gles, has that been packaged ?
#ubuntu-arm 2012-04-16
<delinquentme> so beagle boards run ubuntu ... how does one take a beagleboard and begin putting specific code on it? is it a USB connection?
<delinquentme> and its run in the linux environment right?
<scientes> delinquentme, yeah it has a RW sd card
<scientes> delinquentme, but binaries have to be compiled for ARM, x86 binaries wont run
<delinquentme> and this can be written in any language that can compile to ARM?
<scientes> correct
<scientes> or any interpreted language, that has interpreter support on ARM
<delinquentme> and how about the operation ... that code simply polls over and over ?
<scientes> and to be apecific armv7, which is what ubuntu targets
<scientes> delinquentme, linux is "tickless"
<delinquentme> its running *inside* the ubuntu operating system right? much like any language I run on my laptop ubuntu system
<scientes> so it only wakes up to meet the next deadline, if it doesn't get an interrupt
<scientes> yes it is the same ubuntu you run on your laptop, but recompiled for arm
<scientes> debian GNU/Linux did most of the porting work/troubleshooting
<delinquentme> and the code would be automatically read from the SD card?
<scientes> but armv7 hardfloat transition has been helped by ubuntu
<scientes> delinquentme, its just ext4 filesystem like you use on your hard drive
<scientes> so it has files just the same, and with the same layout
<scientes> delinquentme, you can actually run the beagleboard software on your laptop, using qemu-arm
<scientes> or qemu-arm-static
<delinquentme> so If i've got a desktop which connects to the beagleboard via ethernet ... and I want the beagle to issue machine commands to MCs that branch off of it
<scientes> " machine commands to MCs that branch off of it"
<scientes> i have no idea what you are saying here
<delinquentme> the beagle runs whatever compiled arm and would then issue commands via that beagleboard software to those branch MCs
<scientes> you can run all the same server software on e arm that you can run on x86
<scientes> postfix, dovecot, postgresql, etc
<scientes> now, the beagleboard is not the fastest arm board
<delinquentme> basically the beagle controlling a number of attached MCs
<scientes> what is a MC?
<delinquentme> microcontroller
<scientes> specifically.....?
<delinquentme>  ( sorry ) but yeah I'm trying to use the beagle to run steppers and the like
<delinquentme> been looking at this one : http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/DM00037955.pdf
<delinquentme> ~ 13 of those
<scientes> well that has yet another arm cpu inside of it
<scientes> however it has too little ram and flash to run linux
<delinquentme> oh yeah im not trying to run linux on those
<delinquentme> those are what controls the steppers and the sensors etc
<delinquentme> which then geed information back to the beagle
<delinquentme> geed = feed*
<scientes> is that black on the bottom audio?
<scientes> and the top usb is just the power (5v)?
<scientes> "one audio DAC" yeah, audio
<delinquentme> i think theres also a 5v in
<scientes> seems to me that you use the "SWD" to communicate to it
<scientes> "digital accelerometer and digital
<scientes> microphone, one audio DAC with integrated class
<scientes> D speaker driver, LEDs and push buttons and an
<scientes> USB OTG micro-AB connector.
<scientes> "
<scientes> so i guess that is what it does
<delinquentme> how to check if it can run communications over the micro usb
<scientes> well since it says that all that is needed, it probably can
<scientes> what do you want to do with it?
<delinquentme> make a liquid handling robot
<delinquentme> it has a number of modular cores
<scientes> that thing seems to be audio-oriented
<scientes> microphone and mono audio out
<delinquentme> yeah I'm not really sure how the MC industry works
<scientes> "digital microsoft" (does that mean it has a ADC ?)
<delinquentme> like it can send signals and thats all I really need
<delinquentme> i could probably go much simpler TBH
<scientes> gcc supports compiling firmware IIRC
<scientes> its the arm-non-gnueabi target for armv5+
<scientes> *none
<delinquentme> but I dont have the capability to design printed circuit boards ... so i need to buy something thats already assembled
<scientes> and it only has one usable button
<delinquentme> so yeah just write come C code .. compile it with GCC stick it on a MC like that and let it poll for commands from the beagle
<delinquentme> yeah I don't really see myself using anything other than a reset button
<scientes> well, event-based would sure be nicer
<scientes> delinquentme, you can do that without any MC
<scientes> you can do that with a seial port
<scientes> or even a usb keyboard/mouse
<delinquentme> well for programming it I can attach it however
<scientes> but yeah that board is designed for audio uses, it doesn't seem applicable for you
<delinquentme> how does one go about finding a good board for an application?
<scientes> all the IC vendors have huge lists
<delinquentme> ( i'm kind of expecting there to be a tool like new egg where there are drop downs and I select the chips and things I want on it
<scientes> freescale, marvell, broadcom
<scientes> newark
<delinquentme> and these are all programmed effectively the same way?
<scientes> well im still not sure what youwant/are trying to do
<scientes> arduino is pretty hot these days
<delinquentme> true but they're also super costly
<scientes> so is the beagle board
<delinquentme> ahh yeah that might help :D  .. I've got 2 steppers, 1 linear string pot, 1 linear actuator and 2 physical switches
<scientes> compared to, like, the rasberri pi
<scientes> delinquentme, how about this: http://www.st.com/stonline/stappl/productcatalog/app?page=productSelectorPage
<delinquentme> oooooo
<scientes> http://www.freescale.com/webapp/sps/site/application.jsp?code=APLSTEMOT
<delinquentme> DSC ?
<delinquentme> Digital Signal Controller
<delinquentme> actually I should totally be able to email customer support @ these places and just be like
<delinquentme> "this is what I need"
<delinquentme> does u have?
<delinquentme> also!
<delinquentme> these are all chips .. is there a name used for the units when they're already attached to a board?
<scientes> yeah ive come across that prob too
<scientes> i dont really have an answer for you
<delinquentme> haha im glad im not nuts :D
<delinquentme> scientes, what do you do with all this coolness
<delinquentme> specifically ubuntu arm chips?
<scientes> well i actually dont have a armv7 comp yet
<scientes> i only have the sheevaplug
<scientes> which is armv5, running debian
<scientes> but i really want a armv7, or better yet armv8 + quad core
 * scientes wants to experiment with big.LITTLE too
<delinquentme> OOo the sheevaplug
<delinquentme> thats like mischief no?
<scientes> its kinda old now
<delinquentme> is this like PHD research scientes ?
<delinquentme> you can basically hook that sheevaplug up to something and just let it sniff away at wireless packets
<scientes> the one i have doesn't have wifi
<scientes> but considering its size and power consumption that sort of use would certainly be feasable
<scientes> and a good fit for the device
<scientes> it also has gigabit ethernet, so you could access it remotely at high speed
<pnphi> configure: error: "PAM libraries not found"
<pnphi> how to fix ?
<pnphi> configure: error: "PAM libraries not found"  how to fix ?
<scientes> pnphi, what piece of software?
<pnphi> i'm building the package gdm
<twb> This error is coming from ./configure ?
<pnphi> no , dpkg-buildpackage -aarmel
<scientes> pnphi, could be systemd-logind's pam module
<scientes> try turning off systemd
<pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
<pnphi> and this problem
<twb> pnphi: pastebin the full transcript
<pnphi> detail ?
<infinity> I assume you're missing libpam-dev.
<twb> infinity: I thought dpkg-buildpackage would, like debuild, bitch about missing dependencies before getting to that point
<infinity> It does.
<twb> So he's doing something silly.
<twb> And the pastbin will tell us what
<infinity> But he may well either (A) have built with -d, or (B) be building sources with bad build-deps.
<twb> Nod
<infinity> (When you call debuild, it's dpkg-buildpackage that's bitching; debuild is only a very thin wrapper around it)
<pnphi> checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2
<pnphi> I don't know to fix this problem
<pnphi> !!!
<scientes> pnphi, PASTE
<pnphi> checking for pam_start in -lpam... no
<pnphi> configure: error: "PAM libraries not found"
<pnphi> make: *** [debian/stamp-autotools] Error 1
<pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
<pnphi> E: Failed autobuilding of package
<scientes> pnphi, did you install libpam-dev?
<pnphi> yes
<scientes> pnphi, paste dpkg -L libpam-dev
<pnphi> libpam0g-dev is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<scientes> pnphi, paste dpkg -L libpam0g-dev
<twb> infinity: I realize that; I just don't remember which bits are still debuild-specific
<pnphi> yes
<pnphi_> so what else ?
<pnphi_> dpkg -L libpam0g-dev
<pnphi_> usr/share/doc/libpam0g-dev
<pnphi_> usr usr/share usr/share/doc usr/share/doc/libpam0g-dev usr/share/doc/libpam0g-dev/examples usr/share/doc/libpam0g-dev/examples/vpass.c usr/share/doc/libpam0g-dev/examples/modules usr/share/doc/libpam0g-dev/examples/modules/pam_secret.c.gz usr/share/doc/libpam0g-dev/examples/modules/Makefile usr/share/doc/libpam0g-dev/examples/xsh.c.gz usr/share/doc/libpam0g-dev/examples/check_user.c usr/share/doc/libpam0g-dev/examples/agents usr/s
<twb> pnphi_: http://paste.debian.net
<pnphi_> what is it ?
<twb> pnphi_: you put your text there, hit "submit" and copy the resulting link here, rather than pasting the original text here
<twb> This is called a "pastebin", it stops us going insane
<pnphi_> ok
<pnphi_> paste.debian.net/163365/
<pnphi_> http://paste.debian.net/163366/
<pnphi_> Log of build and result of "dpkg -L"
<scientes> <pnphi> checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2
<scientes> specifically -lpam
<scientes> there is no pam.h....doesn't -lpam require pam.h?
<pnphi_> i don/t understand
<janimo`> ogra_, hi, which packages needed to be touched to get unity-3d gles working? nux, compiz+unity?
<janimo`> I'd like to to do a GLES rebuild for x86 and touch the minimum numer of packages locally
<ogra_> nux, unity, compiz and compiz-plugins-main
<ogra_> just grab the packages in precise, they are ready
<ogra_> you will need to change the arch checks etc
<janimo`> ogra_, and all of them need an extra config option passed, none do runtime detection right?
<ogra_> right
<janimo`> ogra_, thanks!
<ogra_> talk to alf_ for a different patch set
<janimo`> ogra_, for now the ones in precise are fine if they actually work with gles
<ogra_> iirc the new one they have in linaro can run with GL and GLES enabled
<ogra_> not sure when you have to select or if its automatic at all though
<janimo`> ogra_, ah they already hae packages for that, I'll ask him then
<LetoThe2nd> infinity: ping
<infinity> LetoThe2nd: pong?
<LetoThe2nd> infinity: ogra told me ask you:
<LetoThe2nd> any ideas why http://paste.pocoo.org/show/582316/ goes bi***ing about some dependency issues concerning linux-libc-dev:i386 and linux-libc-dev in a clean 12.04 chroot, and if you just re-run it, everything is fine? dependency solver problem?
<infinity> LetoThe2nd: Temporary annoyance with a transition.  If you add precise-proposed to your sources.list, it'll be happy.
<infinity> LetoThe2nd: Should be resolved in ~5 hours when gcc-4.6 is built everywhere, and I can promote gcc and eglibc to release.
<LetoThe2nd> infinity: ahkay. nothing urgent, so will probably be sorted out soon?
<LetoThe2nd> i see, thx then.
<ogra_> infinity, compiz-plugins-extra (universe) is FTBFS on all arms with the new GLES compiz, should we leave it that way, or upload a package that has the arm arches dropped for final release ? (i dont think anyone ever cared in a port to GLES for these plugins)
<infinity> ogra_: Ugh, really?  Is it not a simple fix?
<infinity> rsalveti: Hey, wake up and come be helpful.
<ogra_> i dont think linaro ever touched that package (not needed for unity) and afaik all GL->GLES switches need heavy patching
<infinity> ogra_: Dropping the arches isn't necessary, but fixing it would be nice.
<ogra_> (more than just a config option)
<infinity> Needs heavy patching for plugins?  That seems wrong.
<ogra_> well, even in our normal compiz build on arm we have to disable more than half of the plugins
<ogra_> because the functions arent patched yet, i doubt its fixable in time for release and i also doubt linaro will ever care for these plugins
<infinity> Letting it be FTBFS is fine.  As you note, it's universe.
<infinity> We just need to remove the stale binaries.
<ogra_> right, and makes SRUing a possible fix easier
<infinity> And wow, compiz-plugins-main-gles2.patch is extensive.
<ogra_> i still try to catch alf_ or rsalveti to find out if they ever plan to fix that
<ogra_> right
<infinity> What an awful architecture compiz is...
<ogra_> well, compared to the compiz patch its still small :)
<infinity> The GNOME people really got this right with cogl.
<ogra_> well, we should just switch to Qt
<ogra_> unity-2d ftw
<ogra_> but i promised kaleo to not rave about that for a year :)
<infinity> Heh.
<infinity> I prefer 2d anyway.
<infinity> To each their own, though.
<ogra_> yeah, and it shouldnt be to hard to get all the functions in that 3D has
 * ogra_ completely reinstalled his ac100 this weekend from ubuntu-core 
<ogra_> using lxde now
<ogra_> so much more free ram !
<ogra_> (needed a reinstall to switch to hf)
<ogra_> using -core as a base it a big pain in the butt though ...
<infinity> Well, yes.
<infinity> It has no installer. :P
<ogra_> yeah
<ogra_> well, and getting the bootloader setup working by hand isnt really fun
<LetoThe2nd> <3 debootstrap
<infinity> I'd suggest feeding core to linaro-image-tools (which works really well), but I assume they have no ac100 target.
<ogra_> LetoThe2nd, -core is essentially debootstrap --minbase
<ogra_> iirc
<ogra_> yeah, ac100 is spethial
<LetoThe2nd> ogra_: ah yea.
<infinity> I don't mind my ac100 with unity-2d, but the RAM starvation does hurt.
<ogra_> the prob with the ac100 is to get it to a point where you can use the wlan for further install ... thats a real PITA starting from core
<infinity> I had some builds failing on it because of that.
<ogra_> right, with lxde my system now uses 75MB with the idling desktop
<infinity> ogra_: Hahaha.  Yeah, my first ac100 install was from core, and involved a whole lot of wgetting and dpkg -i, and head-scratching.
<ogra_> thats half of what unity-2d uses
<infinity> I don't really know what posessed Toshiba to only put 512MB on the thing.
<ogra_> adnroid
<infinity> If they wanted to be competitive with crappy Atom netbooks, they all have 1G.
<fhilly> Hi All
<ogra_> i dont think that was the plan with the ac100
<infinity> Yeah, I suppose it was Android-specific.
<infinity> But even Android breathes more easily with 1G.
<ogra_> its more like a POC of using android on netbooks
<ogra_> well, it is using 2.1 in the original setup ... that doesnt need much ram ... and has not many apps :)
<infinity> It's the one thing I'd change about my phone, if I could (and the only reason I might look for upgrades)
<fhilly> anyone have detailed documentation on the architecture and packages on Ubuntu core rootfs?
<LetoThe2nd> hrhrhrhr
<ogra_> theer should be a manifest file in the download dir
<infinity> Is there?
<ogra_> that has the packagelist
<ogra_> infinity, if there isnt ... it *should* :)
<infinity> Oh look, I do publish the manifest.
<infinity> Go me.
<ogra_> (there is)
<ogra_> fhilly, http://cdimage.ubuntu.com/ubuntu-core/daily/current/ ...
<ogra_> and http://cdimage.ubuntu.com/ubuntu-core/releases/ for released images
<fhilly> thanks ogra, I assume there is detailed information in there?
<ogra_> fhilly, well, there are the manifests and you can see which arches it is built for
<fhilly> how about rootstock? is it still maintained?
<ogra_> no
<fhilly> thanks ogra
<ogra_> hmm, that remonds me i should probably file a removal bug for the package
<fhilly> ok, if I want to get involved in the building process of the Ubuntu core rootfs, is there any specific root advised?
<ogra_> we use live-build (config files for that are in livecd-rootfs) to roll it
<ogra_> just take a look at the source of these
<infinity> ogra_: I'll happily remove rootstock right now, no need for a bug.
<ogra_> infinity, go for it !
<infinity> ogra_: But I think you should do something about the LP project too.
<ogra_> yeah, i'll kill it
<fhilly> ok thanks a lot
<ogra_> or at least mark it inactive or so
<ogra_> there are some good code snippets in rootstock i wouldnt like to lose
<ogra_> (the fifo to serial interaction with qemu for example to do stuff scripted inside a VM)
<fhilly> well, I have tried ubuntu-core rootfs on x86, however I believe there is "sudo" package missing, as the user will not be able to install anything including "sudo" unless unlock the files system as sudo or su user
<ogra_> fhilly, thats on purpose
<ogra_> ubuntu-core is to *build* images on top (or as an easy to use base for a chroot), not actually to use it as an install base ...
<infinity> sudo would be kinda useless given that there's also no user.
<infinity> rootstock | 0.1.99.4-0ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc
<infinity> rootstock-gtk | 0.1.99.4-0ubuntu1 | precise/universe | all
<LetoThe2nd> infinity: one could make an alias called "medo" that root himself can use.
<infinity> ogra_: ^--- That rootstock?
<ogra_> the typical usecase is for something like embedded IVI systems (car entertainment) where you wont even have a user account  thats accessible by the ednuser
<ogra_> \o/
<ogra_> infinity, yeah
<ogra_> funny, i didnt know we built it for armel/armhf ...
<fhilly> forgive my ignorance but can you tell me why? as in the short explanation of it, it says after you finish you can use pat-get, how can we use apt-get if we don't have sudo? I am new to community stuff and I am trying to get involve so I know I am asking too much
<fhilly> ok I see
<LetoThe2nd> ogra_: haven't you noticed all the people in #pandaboard who asked about starting from -core because the sound of the name suggested a more minimal image to them?
<infinity> And it is a minimal image.
<infinity> It just also has no installer.
<fhilly> lets say I want to build Ubuntu distro for ARM (beagle board) can I do it based on Ubuntu -core rootfs, or there is a better way of doing things?
<ogra_> well, it is
<ogra_> but you need to do a ton of things manually depending on your usecase
<infinity> ogra_: Removed, should be gone in the next publisher run.
<ogra_> fhilly, well, i would just use one of the official beagle images from ubuntu for that
 * ogra_ hugs infinity 
<fhilly> is there any detailed documentation about it? guys I see you know everything about it, instead of me asking you, I could just read and get back to you if I have any questions
<ogra_> if you want a minimal install on your beagle, use the server image
<ogra_> see https://wiki.ubuntu.com/ARM/OMAP for instructions etc
<ogra_> if you want even more flexibility, use the netinstall SD card image
<fhilly> orga_ I am trying to get as much information as I can, as I would liek to be part of the community at one point, and contribute. it is not about the BeagleBoard only
<ogra_> (falsely called netboot on that wikipage) ... but nore that you nedd a network connection wired up for thet indeed
<ogra_> well, just hang out in this channel ... thats already a good step to being involved in the community ;)
<LetoThe2nd> fhilly: and, hint: tabcompletion for nicks works in any sane IRC client :)
<fhilly> ok thanks LetoThe2nd
<fhilly> it works
<fhilly> as a starting point for me, where can I start contributing? in terms of anything I could do?
<LetoThe2nd> oO( purge errors out of omappedia/elinux *duckandrun* )
<ogra_> http://qa.ubuntuwire.org/ftbfs/ ... you could for example have a look at all packages that only fail on armel/armhf
<ogra_> or weed through launchpad and look for bugs that the ubuntu-arm team is subscribed to
<fhilly> then try to fix it, and report back?
<ogra_> if you have HW you can help testing images right before milestone (or final) releases
<ogra_> right
<fhilly> ok
<fhilly> I have BeagleBoard XM rev: C4 and BeagleBone
<fhilly> any testing procedures?
<janimo`> infinity, !! I started using a caching proxy and it's great! apt-cacher-ng
<janimo`> which year are you welcoming me into?
 * ogra_ uses approx 
<janimo`> I just picked this one as at one point in one of the mailing lists it was mentioned it more or less works out of the box
<janimo`> and it indeed does, besides putting a line in apt.conf
<ogra_> approx as well and i find it easier to configure for special cases like ports.u.c
 * infinity just has a local Ubuntu and Debian mirror.
<infinity> ... running on an i.MX53
<ogra_> http://www.grawert.net:9999/ubuntu-ports ... :)
<ogra_> thats my laptop
<janimo`> ... uphill
<ogra_> (as long as i dont take it with me indeed (which i really rarely do since i have the ac100))
<fhilly> how can I test the images before release? where can I get them from? can I subscribe to get notifications?
<LetoThe2nd> fhilly_: they're all up on the servers
<LetoThe2nd> fhilly_: http://cdimage.ubuntu.com/daily-preinstalled/current/ for example
<morphis> LetoThe2nd: you know with which tool the images are build? live-build?
<LetoThe2nd> morphis: no idea.
<morphis> infinity: you know how they are build?
<infinity> Which images?
<infinity> But yes, we use live-build to create live/preinstalled filesystems.
<morphis> infinity: the images you can download from here: http://cdimage.ubuntu.com/daily-preinstalled/current/
<ogra_> fhilly_, for testing you can subscribe to teh images you want to be notified about on http://iso.qa.ubuntu.com/
<infinity> morphis: live-build to create the filesystem, and then some hackery on top of that to make it bootable.
<morphis> infinity: means installing system dependent files (fstab,kernel-modules, ...)
<ogra_> kernel modules come from the kernel package ... fstab and HW sepcific bits usually come from the installer
<infinity> And creating a FAT filesystem, and populating it with a bootloader and kernel, and...
<fhilly_> ogra_, LetoThe2nd thanks
<morphis> infinity: ok
<fhilly_> what do I have to do? just install them? do something specific? run scripts? or just work as normal?
<djszapi> Hey! Is it okay if the daemon part of my project is started automatically by an upstart job put into the /etc/init/ folder with the ubuntu desktop version ? Is there a better interface for that like we had /etc/init/apps on Harmattan ?
<pnphi> i don't know to fix this problem
<pnphi> checking for pam_start in -lpam... no configure: error: "PAM libraries not found" make: *** [debian/stamp-autotools] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2
<ogra_> pnphi, just add the right dependency to your packge (or if you dont build a package, make sure to have the right -dev package installed that gives you the pam headers
<ogra_> )
<pnphi> detail ?
<ogra_> djszapi, i dont know /etc/init/apps, but upstrart is surely a proper way to start daemon processes
<ogra_> pnphi, well, its your project, you should know what deps you need to build whatever you build there
<djszapi> ogra_: start on runlevel [23] or [12345] ?
<pnphi> so...i install deps of package
<pnphi> !!!
<ogra_> well, usually runlevels are moot anyway :) all debian and ubuntu systems default to 2
<pnphi> what runlevel ?
<ogra_> (so [2 3<9 should be good)
<ogra_> err
<ogra_> [2 3]
<pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
<pnphi> what the err ?
<ogra_> read your build log it should say
<djszapi> ogra_: runlevel 5 means for instance "Start the system normally with appropriate display manager. ( with GUI )"
<ogra_> djszapi, it doesnt
<djszapi> ogra_: http://en.wikipedia.org/wiki/Runlevel#Typical_Linux_runlevels
<ogra_> (nmot sure where you got that line from, but on debian based systems runlevel 2-5 are identical)
<ogra_> 1 is singleuser, 6 is reboot
<ogra_> (and 0 is halt)
<djszapi> read the link.
<pnphi> configure.ac:3: warning: AC_INIT: not a literal: http://bugzilla.gnome.org/enter_bug.cgi?product=gdm if [ -e ./Makefile.am ]; then cd . && automake-1.11  ; fi configure.ac:3: warning: AC_INIT: not a literal: http://bugzilla.gnome.org/enter_bug.cgi?product=gdm data/greeter-autostart/Makefile.am:10: `%'-style pattern rules are a GNU make extension automake-1.11: cannot open < gnome-doc-utils.make: No such file or directory make: *** 
<pnphi> oh my god
<djszapi> and I have the desktop version of ubuntu on my pandaboard.
<ogra_> how would reading thge link change anything ?
<djszapi> the linux runlevels are defined in there...
<ogra_> no, they arent ... someone wrote up how the runlevels on his fedora box look like i guess
<ogra_> first of all, runlevels are moot, upstart is event based and only retains the runlevel concept for backwards compatibility ... if you develop something from scratch i would rather tie to an even than to a runlevel ....
<ogra_> and second, i onlycan repeat (for the last time now) runlevels 2-5 are identical on debian based systems)
<djszapi> what would you recommend to me, if my goal is to run my binary during the bootup ?
<ogra_> rsalveti, poke ... seems compiz-plugins-extra FTBFS with the new compiz
<djszapi> that is the trigger event.
<rsalveti> ogra_: oh well, let me check
<ogra_> rsalveti, well, i didnt expect anyone to have a patch or so, just wanted to make sure i'm right
<ogra_> its a universe package etc etc blah blah ...
<rsalveti> plugins-main is the one needed, this extra might not be useful in the end
<ogra_> djszapi, well, what does your daemon do ? i.e. for a network based service i would tie to a network-up event for something related to HW i would tie to a udev event
<djszapi> start on runlevel [23] stop on runlevel [!23]
<djszapi> I had the impression I should do something like that for this goal.
<rsalveti> janimo`: there's a runtime detection for unity for gles as well
<ogra_> rsalveti, yes, thats what i thought, just wanted to look if you guys possibly have a patch
<djszapi> ogra_: listening to the serial port, and act accordingly for the incoming data.
<djszapi> so prolly udev.
<rsalveti> janimo`: /usr/lib/nux/unity_support_test -p
<rsalveti> ogra_: I'll check
<ogra_> djszapi, well, either use the runlevel or take a look if there is a udev event when the serial device shows up
<pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
<pnphi> @ @
<ogra_> read the log, find the error, fix it :)
<janimo`> rsalveti, yes, ran that already and works fine, still unity still crashes on logon
<djszapi> ogra_: I am unsure if there is an udev event for that.
<smplman> are there any updates on SGX for omap3?
<ben_> Out of interest.
<ben_> Does the l-cache actually destroy back to back compatibility with prior programs?
<ben_> Because it forces ARM into a modified Harvard Architecture...
<ben_> Take for example the case where you write over and instruction, but the l-cache keeps a prior version and then executes the prior version.
<ogra_> djszapi, so just take [23]
<ben_> You have to force the cache to clear...
<djszapi> ogra_: might fail if udev is not up yet
<djszapi> since connecting to the serial port depends on the udev
<ogra_> udev comes up in initrd
<djszapi> so it is guaranteed my binary would be run later ?
<ogra_> and i think also before the runlevels start
<ogra_> ogra@horus:~$ grep "start on" /etc/init/udev.conf
<ogra_> start on virtual-filesystems
<djszapi> so ?
<ogra_> yup ... udev comes up with /proc, /sys and friends
<ogra_> way before anything cares for runlevels
<djszapi> fine :-)
<djszapi> does the kernel care about the proper respawning ? Say, I open the serial port while launching the daemon, and I would ideally close the serial port while stopping.
<djszapi> what if the daemon dies, and there is a respawning ?
<djszapi> there is a proper serial port close and then open again ?
<ogra_> no, not the kernel ... init does (well upstart in our case)
<djszapi> ogra_: is "stop on runlevel [!23]" fine for stopping ?
<recur> is there an arm equivalent to dmidecode ?
<infinity> recur: That would imply there was such a thing as device tables on ARM.
<recur> Hi infinity
<recur> ah, so I'm completely out of luck then :)
<infinity> Pretty much.
<recur> I wanted to programmatically get my hardware serial, but I've used dmidecode for that in the past.
<recur> thanks for the info!
#ubuntu-arm 2012-04-17
<electroglue> hey guys can someone point me to a ubuntu how to for beaglebone. Seem I'm not using the right image
<rsalveti> infinity: ogra_: bug 983555
<ubot2> Launchpad bug 983555 in compiz-plugins-extra "compiz-plugins-extra FTBFS on ARM" [Medium,Confirmed] https://launchpad.net/bugs/983555
<rsalveti> and attached a debdiff containing the patch that disables the plugins that are gl-only compatible
<electroglue> can someone tell me if http://cdimages.ubuntu.com/releases/oneiric/release/ubuntu-11.10-preinstalled-server-armel+omap.img.gz is the right image for beaconboard?
<electroglue> I mean beaglebone
<infinity> rsalveti: \o/
<infinity> electroglue: Other than the part where I'd strongly recommend using precise/armhf instead of oneiric/armel, yes.
<electroglue> infinity: armhf performance is much better than the soft one?
 * twb perks up - ubuntu has a solid armhf now?
<infinity> Better performance, plus we're dropping support for armel.
<infinity> twb: Hrm?
<infinity> twb: Where have you been for the last 6 months?
<twb> infinity: last time I looked, which was months- asleep
<electroglue> thanks infinity
<twb> wrt ubuntu arm I well and truly have my "user" hat on and my "dev" hat off :P
<infinity> I have a few too many dev hats.
<infinity> rsalveti: So, I'm guessing no Linaro folk got around to taking gnat off markos' plate?
<infinity> rsalveti: Also, uploaded that compiz fix for you.
<rsalveti> infinity: I thought SteveMcIntyre was looking at it, need to ping folks to check
<rsalveti> let me write down an email about that
<rsalveti> infinity: thanks
<infinity> rsalveti: Unless someone magically produces a compiler in the next few days, we're pretty much officially "too late" anyway.
<rsalveti> yeah =\
<infinity> Thankfully, no one actually uses ADA... Right?
<rsalveti> well, there are always some weird folks that might be using it, but afaik not that many at least :-)
<infinity> Well, the pet hobby language of the month seems to be haskell.
<rsalveti> yup
<infinity> I'd still love it if we got ghci working for those folks.
<infinity> But at least ghc works.
<rsalveti> cool, and do we have any issue with other haskell related packages?
<rsalveti> I remember they were always a bit of a pain go get all in sync and building for arm
<rsalveti> issues with builder and such
<infinity> haskell-src-exts was having OOMing issues, that was fixed.
<rsalveti> cool
<infinity> So, it's only ghci that needs love.  And I'm told that porting ghci to a new arch is a lot of Not Fun.
<infinity> Which is why upstream only supports two arches. :/
<rsalveti> oh, ok, so will probably take time then
<infinity> But I know, for instance, that CompSci classes teach interactive ghc usage, etc, so to many people, ghc without ghci is "useless".
<twb> infinity: GHC struggles on "second class" archs because it has to compile to C first, then run a C compiler
<infinity> Something to ponder spending time on for Q anyway.  Maybe.
<twb> infinity: last time I looked upstream GHC team didn't support arm at all, that was all Debian
<twb> infinity: if they want GHCI they can bloody well ssh into the student shell server :-/
<infinity> twb: Yeah, most of the porting effort with GHC has been Debian, and the Debian maintainer's awesome, but he's also a limited resource. :P
<twb> I used to maintain Darcs in Debian, from 2.0 up to about 2.4 or .5
<infinity> Hrm, Uploaders gets filtered out by dpkg-gencontrol, doesn't it?
<infinity> So I can still fix this source without rebuilding the binaries.
<infinity> Shiny.
<scientes> you you guys saying alot is broken with armhf?
<infinity> scientes: Other than gnat, no, it's just as broken (or slightly less) a armel. :P
<infinity> s/a armel/than armel/
<scientes> cause i ran into the opposite with firefox
<scientes> to run on armv5 you have to turn off the JIT or you get segfaults
<twb> Meh, ff is always a problem child
<micahg> scientes: you'll want Debian's build if you're using armv5
<scientes> twb, ever try to build ff?
<twb> Yes
<scientes> micahg, yeah that is what i was using
<twb> Although nowadays it's separate from xulrunner so the heavy lifting happens there
<scientes> micahg, it works except it doesn't turn off the jit by default for some reason
<micahg> twb: AIUI in Debian xulrunner and Firefox are built from the same source now
<twb> oh.
<scientes> the 2GB for libxul linking sure caught be off gaurd
<twb> grumble grumble
<scientes> <micahg> twb: AIUI in Debian xulrunner and Firefox are built from the same source now
<scientes> correct
<scientes> i like that
<twb> scientes: hey man you can't even CHECK OUT emacs from bzr unless you have 800MB of RAM
<twb> Let alone compile it
<scientes> well that a bzr problem
<twb> Yeah I know ;-)
<scientes> which is not exactly something i care about
<infinity> Checking out emacs seems more like a personal problem.
<scientes> haha
<twb> infinity: it's a communicable disease
<infinity> This is right up there with "I find it really difficult to masturbate to rotting corpses".
<scientes> i just dont see why in bzr explicit renaming support is touted as a "feature"
<infinity> The obvious response being "don't do that, then."
<scientes> the content-centric approach of git seems much better
<twb> scientes: it's better enough that Darcs adopted it too
<scientes> > its cancer enough that darcs adopted it too
<scientes> FTFY
<scientes> infinity, so are you guys going to maintain some sensible armel multiarch so that broken packages can still be installed as armel?
<twb> If you analyse the Î of typical operations in a traditional delta-store backend vs. a content-oriented database, the latter is a clear win for VCS
<infinity> scientes: We do support multiarch, yes.
<scientes> so you will have a armel and armhf repo like debian, just not support the armel for primary arch?
<infinity> We have both for now.  We'll have both for the life of precise.  I can't say if we'll have both forever.
<infinity> (really, probably not)
<scientes> well then they cant accuse your of breaking stuff that doesn't work on armhf, they can install the armel packages, and port it if someone cares
<scientes> sounds perfectly reasonable to me
<twb> I thought not all of the multiarch ducks were lined up yet
<twb> Like, it's in dpkg now, but not in apt yet
<infinity> I have a fine collection of ducks here.
<infinity> It's been supported since oneiric...
<scientes> haha, yeah there is alot of gui lack, and i've seen bugs in aptitude
<infinity> We shipped with multiarch on by default for amd64 in oneiric.
<infinity> aptitude is buggy, yes.
<scientes> but ubuntu has had it for a while unlike debian
<infinity> But who cares, it's aptitude. :P
<scientes> infinity, I use it!
<micahg> aptitude is better in precise, but still needs help
<twb> infinity: oooh, so you did biarch while waiting for Debian to solve the general case?
<scientes> i use apt-get and aptitude
 * micahg would like apt-getitude
<scientes> i use to use synaptic, but now heavily dislike it, along with software-center
<infinity> twb:
<infinity> twb: Err, what?
<infinity> twb: No, multiarch in oneiric was multiarch.
<twb> So I could add precise armhf to my existing oneiric/precise armel sources.list, and it should Just Work?
<infinity> Well, to precise/armel, sure.
<scientes> twb, if you have armv7 hardware, yes
<twb> Is there a howto wiki page somewhere?
<infinity> Given that multiarch needs package versions to match, oneiric/precise won't exactly work.
<infinity> And it's not added in sources.list at all.
 * scientes uses [arch=amd64] in sources to make downloads faster
<twb> infinity: what I mean is I'm currently using oneiric and cherry-picking things I care about from precise
<infinity> twb: echo "foreign-architecture armhf" > /etc/dpkg/dpkg.cfg.d/multiarch && apt-get update
<infinity> twb: Congrats, you're multiarch.
<scientes> ^^bingo
<twb> Thanks
<scientes> and you can also change the primary arch to armhf
<infinity> twb: I'd recommend having an armhf base, though, and cherry-picking in the other direction if absolutely necessary.
<infinity> (Which, unless you really like ADA, it shouldn't be)
<scientes> armhf can bring like 25% performance improvement
<micahg> infinity: pascal as well
<twb> I'm currently running a random wacky android .36 kernel.  Do I need that to be compiled with specific options for armhf to work, and if so, how do I check those options?
<scientes> and even more on VFP-intensive stuff
<infinity> micahg: I'm still pondering a 0-hour pascal transition.
<twb> scientes: yeah I was going to put Debian armhf on this box but my previous box died and I was in a rush :-(
<scientes> twb, i think it even works with a armel kernel
<infinity> twb: The kernel doesn't give a hoot about VFP.
<twb> That's what I thought, thanks
<infinity> No such thing as an "armel" or "armhf" kernel.
<scientes> but you can compile your kernel with VFP support, but there is very little FP in the kernel
<twb> Hm, I can't see apt-get update pulling down armhf entries yet...
<scientes> the option is there
<scientes> in make nconfig
<twb> http://paste.debian.net/163468/
<twb> I guess because it hasn't got to the precise one yet, and there isn't one for oneiric?
<infinity> There's no armhf in oneiric, no.
<twb> Yep, there's the armhf dl now
<scientes> upgrade!
<twb> SHINY
<twb> The main thing is to avoid bricking it in any way, because this is my main / only workstation
<infinity> You're as bad as ogra...
<twb> So-rry
<infinity> ;)
<twb> If this was a normal server I wouldn't be worried about the userland bricking it because I can deal with that
<scientes> twb, then use even more shiny like me and switch to btrfs :P
<twb> But this stupid thing can't exactly just boot off a USB live key atm :P
<twb> scientes: how do you think my last laptop died
 * infinity slams his head on the desk.
<infinity> I need to alias git/bzr/svn all to one wrapper that checks for .git, .svn, bzr and DTRT.
<twb> Not to worry tho, my scratch VM is still btrfs all the way
<twb> infinity: http://cyber.com.au/~twb/.bin/twb-get
<infinity> So sick of running the wrong commands in the wrong projects.
<twb> infinity: or you could use Emacs which does exactly that ;-)
<micahg> infinity: debcheckout/debcommit?
<twb> micahg: mm, that too
<infinity> micahg: In this case, it was "bzr diff" in a subversion checkout.
<infinity> Last night, it was git merge.  Because I can't imagine merging without git.
<infinity> But then I realised I had to.
<infinity> Etc.
<scientes> <infinity> I need to alias git/bzr/svn all to one wrapper that checks for .git, .svn, bzr and DTRT.
<scientes> i feel you
 * scientes wishes it was all git
 * scientes uses the git mirror of mozilla-central
<infinity> I miss the fix-it-yourself appeal of RCS/CVS.
<infinity> Of course, they also sucked.
<scientes> hahahaha
<infinity> A lot.
<infinity> But, still.  If I wedge a repository for any of the new shiny VCSs, it's over.
<twb> infinity: hey hey I still use RCS - for evil
<twb> http://paste.debian.net/163469/
<twb> gpg + rcs = version-controlled, encrypted netrc files
<twb> http://paste.debian.net/163470/ is the manpage, since that sh code is pretty obtuse
<scientes> why did ubuntu switch to statically linking libxul into firefox?
<scientes> esp when they switched to shipping thunderbird by default
<scientes> seems you could save a few MB of ram for nothing
<infinity> You could, but the pain of keeping the world in sync was awful.
<infinity> And when you're running firefox and thunderbird, "a few MB" is laughably nothing.
<scientes> true....
<infinity> My Firefox is happily dining on 3G of RAM.
<scientes> it use to crash at 2GB all the time
<scientes> no that that is fixed there is no end in sight
 * twb sighs
<twb> I know RAM is cheap, but "it's cheaper to add ram than code an O(logn) algorithm instead of an O(n) one" is like fingernails on a blackboard to me
<scientes> well, xml is neither fast nor ram-sensitive by its very nature
<twb> The problem XML solves is not hard, and XML does not solve it well.
<scientes> xml only creates problems
<scientes> yes, it is context-free which is nice
<scientes> but so is json, which is much better
<twb> So are sexprs, a better solution to the problem that existing in *1959*
<scientes> are there any 100% xml-compatible binary representations
<scientes> that we could support in browsers?
<twb> Who cares
<twb> The browsing public doesn't give a shit about anything except stupid shiny web apps
<scientes> it would be easier to parse
<twb> Personally I avoid 90% of the problem by using w3m for everything except the odd broken site
<scientes> thats pretty extreme
<scientes> i mean even noscript and adblockplus gets you pretty far
<twb> adblockplus is a clusterfuck; that code belongs in DNS
<twb> afk food
<scientes> thats what people say, but adblockplus works much better IMHO
<scientes> cause it actually removes the elements from the DOM
<scientes> and they are never rendered at all
<scientes> or requested
<twb> I wouldn't know about that, I was pulling its data files and putting them into squid and polipo
<scientes> and it works better than simple host forging
<twb> I haven't actually used ff since about 1.5
<twb> Since webkit has slightly less bloat
<scientes> well adblockplus is ported to chromium
<scientes> but i use firefox cause its the only browser than you can coaxe into slightly keeping your privacy
<micahg> twb: you should give Firefox 13 a go, much smaller memory footprint
<scientes> and much faster javascript
<scientes> and also video support
<twb> are you serious?  They're up to 13 now?
<twb> micahg: well I was running it over X so I didn't have to pay the footprint penalty on my local netbook
<twb> TBH the video stuff annoys me because now I can't opt out by not installing flash
<micahg> noscript should help there
<twb> If I want a video I'll fucking well fun mplayer, I don't want it loading without asking inside a browser, any more than I want geocities "background music" in a web page
<twb> micahg: so instead of taking stuff out, I have to add more stuff to stop the first stuff from doing anything?  Yuk
<micahg> 13 is current in the aurora channel which is ~7 weeks from release (1 week till beta migration + 6 week migration cycle)
 * micahg thinks noscript is sensible in any event for browsing
<twb> IMO if you have js in a browser it should be off by default
<twb> It's absurd to me that you need a third-party module to make that the case
<micahg> twb: if you saw how many bugs we get because people disable stuff, you'd understand why :) (Mozilla probably gets more)
<twb> But then, that's why I use w3m and I'm not an arsebook weenie
<scientes> twb, you can in firefox settings
<twb> micahg: yeah I grant you moco has to deal with a lot of fuckwits
<scientes> noscript just lets you set it on a per-domain basis
<scientes> whic is more useful
<scientes> same with cslite
 * micahg loves permablocking the ad sites
<twb> scientes: I think if I was building it, I'd just have a keychord that said "toggle js in this tab"
<twb> micahg: I do that in hosts(5) ;-)
<scientes> twb, yeah i was looking for a way to only have ajvascript run in current
<scientes> but firefox actually does that by default now
<twb> infinity: btw with both oneiric and precise enabled, apt-get whinges because it can't find oneiric/armhf
<twb> http://paste.debian.net/163476/
<infinity> twb: Yeah, cosmetic bug worth fixing at some point, but it's not exactly a common use-case.
<scientes> twb, infinity already said, oneric doesnbt have armhf
<infinity> (ie: how often do we add ports, and have people attempt cross-series multiarch?)
<twb> infinity: okey dokey
<pnphi> make[1]: *** [stamp-conf-lite] Error 1 make[1]: Leaving directory `/home/ty/LuanVan/icewm/icewm-1.3.7~pre2' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2
<twb> I am ninja enough to ignore an error from apt-get ::P
<pnphi> i can't fix this err
<twb> pnphi: pastebin full transcript please
<pnphi> make[1]: *** [stamp-conf-lite] Error 1
<pnphi> make: *** [build-stamp] Error 2
<pnphi> dpkg-buildpackage: error: debian/rules build gave error exit status 2
<pnphi> 2 days , i can't  fix this err
<twb> ubot2: pastebin
<ubot2> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<twb> pnphi: put the whole transcript, all those 100s of lines, into a pastebin
<pnphi> ok
<pnphi> http://paste.ubuntu.com/933470/
<twb> pnphi: what is the version (first line) reported by iconv --version?
<pnphi> must install iconv ?
<twb> If iconv is not installed, that is probably the problem.
<pnphi> http://paste.ubuntu.com/933473/
<pnphi> iconv --version
<pnphi> have iconv
<twb> There is something wrong with your system, because an earlier version of iconv (2.11, from lucid) passes that test:
<twb> echo foo | iconv --from iso-8859-1 --to UCS4//translit ==> foo
<pnphi> yes
<infinity> pnphi: Are you developing on maverick?
<pnphi> yes
<infinity> You realise it's EOL, right?
<pnphi> yse
<pnphi> yes
<infinity> Of course, maverick's iconv *does* work, so I'm sure your problem is local.  But still.  You might want to use a newer release.
<pnphi> newer...ok
<scientes> yeah iconv works...
<pnphi> must upgrade
<pnphi> i'm very tried, 2 days with the err
<pnphi> build by "dpkg-buildpackage -a<arch>" and "xdeb" , the same err
<pnphi> i must upgrade into 11.04
<pnphi> 11.04 is natty
<pnphi> how using dpkg-cross
<rsalveti> infinity: wooot, jockey worked fine from first boot :-)
<infinity> rsalveti: Crazy talk.  You must have done it wrong.
<rsalveti> ;-)
<infinity> Also: \o/
<infinity> I mean, it would be more "\o/" if the drivers were just free, but whatever. :/
<rsalveti> yeah
<rsalveti> hopefully some crazy dudes will reverse engineer it soon ;-)
<infinity> I'm still waiting for some clever young kid with too much free time to make nouvea work on Tegra.
<twb> Or you know, the vendor gets a fucking clue
<rsalveti> would be awesome if robclark would be allowed to do that
<infinity> rsalveti: That might represent a SLIGHT conflict of interest for him.
<rsalveti> robclark: did you look at the tegra support before doing the work for the other driver?
<infinity>  - ARM Fast Models as builders
<infinity> rsalveti: ^-- You hate me, right?
<rsalveti> infinity: oh yeah :-)
<rsalveti> start crying ;-)
<infinity> On it.
<infinity> On the one hand, it would be nice to have the port ready before there's any GA hardware.  On the other hand, OH GOD NO.
<rsalveti> lol
<rsalveti> we're using it for big.little, and yeah, it's a pain
<robclark> rsalveti, I didn't really look at tegra.. although that was more to do w/ hw I have access to.. :-P
<rsalveti> infinity: ^ just need to get a tegra board to robclark ;-)
<infinity> robclark: I'll mail you some Tegra kit.
<robclark> heheh, well, I think I'll be busy for a while ;-)
<infinity> Actually, in all seriousness, we might have some spare ac100s floating around the company, I could ask around.
<robclark> although find some nouveau folks, send 'em tegras :-P
<infinity> I just have a gut feeling that making nouveau do tegraish things would be dangerously close to "trivial" for someone who understands the architecture.
<infinity> Since the Tegra GPU is, by all account, just a slightly crippled Geforce.
<infinity> Sadly, once it's made to work "just like the desktop GPUs", then someone needs to make it do GLES instead. :/
<robclark> I'd heard somewhere that some nouveau folks thought it would need a different driver, but I'm not sure how much that has to do w/ command stream and shader ISA's, vs UMA vs vram..
<robclark> I'd have to guess there is at least some family resemblance ;-)
<infinity> It's the nose.  It's always the nose.
<robclark> heheh
<infinity> Honestly, we suffer along fine with ati/nvidia binary drivers on the desktop, and I think I've mostly come to terms with it.
<infinity> It's the part where ARM SoC vendors are a bit less organised that makes it more painful.
<twb> I don't suffer
 * robclark used nouveau on old laptop (now have intel gfx)
<infinity> (So, the omap4 + jockey thing is great news)
<twb> I outright refuse to use anything but intel GPUs on the desktop
<robclark> nouveau supported gles nicely thx to gallium
<robclark> (gles also works well on new laptop)
<infinity> twb: If Intel ever caught up in 3D performance, I may take that stand, but I still like my fancy video games.
<twb> I have never once had a proprietary video game work properly under wine
<infinity> (I hear that this year's crop of Intel GPUs are at least "not crap", compared to one generation removed for ati/nvidia)
<twb> Even with non-intel (ATI) GPUs
<infinity> twb: I used to play WoW in wine, worked fine.
<infinity> On both ATI and nvidia.
<twb> cube and tremulous worked OK tho
<twb> infinity: the two I can remember are KOTOR and SMAC
<rsalveti> infinity: and after reboot, unity 3d running :-)
<rsalveti> janimo`: with today's image unity-3d is working after installing the pvr driver
<rsalveti> janimo`: what issue did you get exactly?
<rsalveti> can you also start just X and call unity by hand to see if you get any useful logs?
<infinity> rsalveti: Huzzah!
<infinity> I really need to test all of this on my Panda and see it in action.
<infinity> The poor thing's been on fire with toolchain builds all week instead of playing with shiny things.
<infinity> But, once this gcc-4.6/eglibc upload for Debian is done building, it's free again.  Finally.
<rsalveti> hm, seems a bunch of gnome-related changes just landed, running dist-upgrade now
<rsalveti> yeah
<scientes> twb, i've had games work
<scientes> infinity, i couldn't get a framerate over about 3 with ati
<scientes> i also got a nasty corruption issue (which i managed to fix)
<infinity> scientes: Ow.
<scientes> nvidia +wow always worked fine however
<twb> I know it seems to be JUST me
<twb> everyone else seems to have wine work fine for everything
<twb> Although I suspect that's mainly nvidia customers, not the ATI r250 I was using at the time
<scientes> nvidia certainly is the strongest 3d driver for linux
<scientes> but nouveau and radeon are certainly coming along
<scientes> ..however nvidia just broke for me is some way on precise...
<scientes> since last few kernels
<ogra_> bug 983555
<ubot2> Launchpad bug 983555 in compiz-plugins-extra "compiz-plugins-extra FTBFS on ARM" [Medium,Fix released] https://launchpad.net/bugs/983555
<nimesh_accenture> has anyone tried running the ubuntu Oneric 11.10 rootfs over android kernel 3.01 in ICS?
<scientes> nimesh_accenture, there is no such this as "android kernel 3.01"
<scientes> AFAIK
<scientes> each device has a differn't kernel, which is part of the way ARM currently works
<twb> or doesn't work, as the case may be :P
<suihkulokki> tsk, tsk, CONFIG_INIT_PASS_ALL_PARAMS is still not merged mainline?
<nimesh_accenture> scientes: Android has its own patches over the standard linux kernel , which had not recently been upmerged , until 3.3
<scientes> nimesh_accenture, indeed, however most embedded devices use more than just android patches
<scientes> nimesh_accenture, and as 3.3 doesn't have wakelocks booting android on it will eat your battery alive
<scientes> only a select few boards work with upstream kernels, even with non-android
<twb> nimesh_accenture: are they all/mostly in, in 3.3. then?
<twb> Last I heard was "RSN, honest"
<nimesh_accenture> twb: i'm not sure , but I read an article a few weeks back that android patches have been ypmerged into the std linux kernel , not sure if all had been merged
<twb> shiiiiiiny
<nimesh_accenture> scientes: what i'm basically trying to do is create a new rootfs using chrooot in android ICS and then include ubyntu packages and the glibc and the std libc in that root to run applications like g-streamer
<scientes> nimesh_accenture, that should work just fine, however what does uname -a say
<scientes> nimesh_accenture, also, see if you have /proc/config.gz
<scientes> also, bind mount /dev
<nimesh_accenture> i'm currently on my desktop
<nimesh_accenture> panda hasn't been booted yet
<scientes> nimesh_accenture, https://play.google.com/store/apps/details?id=com.galoula.LinuxInstall&hl=en
<scientes> thats debian
<scientes> oh if you have a pandaboard just use the ubuntu pandaboard images
<scientes> should have said you have a more open device
<nimesh_accenture> ya but the ubuntu panda board images contain the kernel et. all , i'll have to separate that out from the image and create a new rootfs
<nimesh_accenture> i mean i've not done it before
<nimesh_accenture> that is waht i assume
<scientes> nimesh_accenture, are you trying to dual boot?
<scientes> whats wrong with the ubuntu kernel?
<janimo`> rsalveti, wat I tested was an x86 wit pvr not panda, so likely oter issues
 * janimo` needs to fix te h key
<nimesh_accenture> nothing is wrong. I want the Android front end , but the ubuntu back end for apps like g-streamer , which dont run on android root
<nimesh_accenture> so both will coexist. not dual boot.
<twb> gstreamer isn't an app
<nimesh_accenture> an engine i ment
<twb> I wonder if anyone has filed an ITP for dalvik
<twb> That would be one of the obvious prerequisites
<nimesh_accenture> not bothered much abt ITP's at the moment ...
<nimesh_accenture> guys ... I have a question about rootstock.... does rootstock download packages from the web or does it include it from the local machine?
<janimo`> nimesh_accenture, from the archives. not the local machine
<nimesh_accenture> so what do I do if i want to crreate a root fs from my local machine root files?
<nimesh_accenture> i basically have the server image of oneric and i want all the packages that are included in that package
<janimo`> nimesh_accenture, I don't think you can reuse your serer image iso from rootstock
<spych102> i am having package problems with enabling my pandaboard, in 11.10 and 12.04
<nimesh_accenture> ok...
<nimesh_accenture> one more thing , what does "--seed linux-image-omap" actually do?
<nimesh_accenture> and do we actually need to give that option?
<spych102> what is the best sdcard image to start with and is there a version of omap extras to use
<janimo`> nimesh_accenture, I think with --seed you specify extra packages to be added to the image which otherwise are not in the default rootstock image
<janimo`> kernel must be seeded as that is specific to the platform you are building for
<janimo`> if you add --seed ubuntu-server it may add all dependencies of that metapackage too. I am not sure though I rarely used rootstock and een then I did not understand exactly how it worked
<LetoThe2nd> isn't rootstock largely outdated? there was even talk about removing it.
<nimesh_accenture> i dont need the kernel, as i'm trying to chroot on top of Android kernel
<janimo`> LetoThe2nd, yes it is. I don't know if there's a similarly easy way to build custom images though
<janimo`> live-build is less straightforward
<LetoThe2nd> janimo`: no idea, i usually just use debootstrap
<nimesh_accenture> i basically need to chroot as i need libc and glibc .. so does --seed linux-image-omap , include the kernel in the rootfs tarball?
<LetoThe2nd> well then whats the matter with debootstrap? set arch, pick the ports mirror, done.
<nimesh_accenture> i didn't know abt debbootstrap ... i'll check it out
<nimesh_accenture> thx guys!
<janimo`> LetoThe2nd, rootstock is debootstrap + adding kernel + initrd basically I think
<LetoThe2nd> janimo`: me thinks the same.
<LetoThe2nd> quit
<nimesh_accenture> so then rootstock "is" debootstrap
<janimo`> nimesh_accenture, yes, a wrapper around it
<ogra_> rootstock didnt (yes its dead and gone from the archive) do anysthing wrt kernel or initrd
<ogra_> its essentially debootstrap+apt-get install $seed+a lot of initial setup for the rootfs (creating users, groups and all default configs the installer would normally doetc)
<ogra_> and also rootstock was more a wrapper around qemu than around debootstrap (it indeed used debootstrap but that was only a minor part of it)
<LetoThe2nd> not an adult part? *SCNR*
<ogra_> heh
<nimesh_accenture> ok...
<nimesh_accenture> so if i dont need the kernel in rootstock , what do i do?
<nimesh_accenture> or is it included by default?
<ogra_> what kernel ?
<ogra_> for which target arch
<ogra_> s/arch/board/
<nimesh_accenture> i'm going to do a chroot from the android kernel , but the ubuntu server oneric rootfs
<nimesh_accenture> pandaboard
<ogra_> why do you do that ?
<ogra_> you will have to apply very heavy hacks to userspace to even get networking to work with an android kernel using it in a normal linux distro
<nimesh_accenture> i want to run gstreamer on the chrooted rootfs, i cant run it on android
<ogra_> ah, so you will run a full android and only chroot into the ubuntu rootfs ?
<nimesh_accenture> yup
<ogra_> good luck with that then
<ogra_> for a chroot you can easily just use ubuntu-core as a base
<nimesh_accenture> thx! but will rootstock include the kernel by default?
<ogra_> no and i wouldnt count on it to work properly at all, its unmaintained since over a year
<ogra_> and has never gotten support for noewer distros ... so its a matter of luck
<ogra_> *newer
<ogra_> use ubuntu-core instaed
<ogra_> and if you want to transfer package selections from oeniric-server to it, use dpkg --get-selections on the server install and dpkg --set-selections in the chroot
<ogra_> (and apt-get dselect-upgrade iirc)
<nimesh_accenture> ah! ok... so no root stocking! thx ogra_!
<sveinse> For how long will the armel Natty repos live? I don't mean how long its supported, but when will the deb repos disappear?
<ogra_> they move with the EOL announcement
<sveinse> Oct 12 I suppose then?
<ogra_> likely
<sveinse> thanks
<ogra_> dunno whats the exact date
<ogra_> but around that timeframe should be right
<sveinse> I'm collecting license/copyright info for a Natty system. I find some packages without any copyright file, e.g. debconf-i18n, fuse-utils, klibc-utils, libgcc1. Do I have to fetch the sources to get their respective licenses? I thought it wasn't possible to publish a deb without copyright.
<ogra_> it isnt, there must be one
<sveinse> Well these don't
<janimo`> sveinse, dpkg -L fuse-utils show that is has a copytight file
<janimo`> not much else actually. This is on precise
<sveinse> I'm reading none in fuse-utils_2.8.4-1.1ubuntu4_armel.deb
<sveinse> which is the latest in Natty I believe
<ogra_> libgcc1 is indeed weird
<sveinse> Neither in amd64 nor i386. Neither in oneiric either
<sveinse> The complete list of packages missing copyright is: debconf-i18n, fuse-utils, klibc-utils, libgcc1, libnih-dbus1, libpython2.7, libstdc++6, ntfs-3g, openssh-server, openssl, vim-tiny
<sveinse> This is from our small embedded system without any GUI
<ogra_> sveinse, check /usr/share/doc, some dirs are symlinks ;)
<ogra_> (to save space)
<sveinse> Yeah ok. That's good that they aren't missing
<sveinse> Sorry for the confusion
<ogra_> well, i knew it was a symlink somehow, thanks for asking else i handt looked :)
<ogra_> oh !
<ogra_> cute !
<ogra_> http://www.solid-run.com/products/cubox
<lilstevie> ogra_: that thing is nice
<ogra_> it is !
<ogra_> and it has eSATA ...
<lilstevie> great step on the developer support by offering bootrom level recovery
<lilstevie> and more to the point offering it as a feature
<pnphi> http://paste.ubuntu.com/933970/
<pnphi> help me
<LetoThe2nd> pnphi: then try to start with a meaningful error description instead of coughing up random output snippets, maybe? ;)
<ogra_> looks like you dont have all dependencies your build needs
<LetoThe2nd> yeah, but whatever that build is/needs...
<pnphi> so..i have full deps
<pnphi> http://paste.ubuntu.com/933970/   help me
<pnphi> i can't fix this err
<LetoThe2nd> no new information, hence no new help is possible.
<pnphi> http://paste.ubuntu.com/934066/
<pnphi> the err , i can't fix
<ogra_> what error ?
<ogra_> (there is none in that log, its a successfull build)
<pnphi> so,i don't see result
<ogra_> it isnt in the pbuilder output dir ?
<pnphi> where is the pbuilder output ?
<pnphi> \var/cache/pbuilder/results
 * ogra_ has no idea, i dont use pbuilder
<pnphi> var/cache/pbuilder/results --> i don't see the resulr
<pnphi> var/cache/pbuilder/results --> i don't see the result
<pnphi> what do you use ?
<ogra_> just a clean chroot
<rsalveti> ogra_: suihkulokki got one cubox at connect
<rsalveti> quite nice indeed
<pnphi> detail ?
<ogra_> pnphi, google :)
<pnphi> chroot
<pnphi> xdeb ?
<ogra_> i'm using a chroot on a pandaboard or on a toshiba ac100
<pnphi> how to build package armel from source ubuntu ?
<pnphi> i use pdebuild
<ogra_> yes, thats fine
<pnphi> what the way to good ?
<nimesh_accenture> i'm trying to follow instructions at: http://omappedia.org/wiki/OMAP_Ubuntu_Core , specifically "Chroot configuration on the Linux PC " . However when I try to chroot , it crashes out giving this error : qemu: fatal: cp15 insn ee1d7f70
<ogra_> make sure to have the proper qemu-lianro package installed
<ogra_> *linaro
<ogra_> (and ask in linaro if you run into issues with that, they maintain it)
<nimesh_accenture> im not using an sdcard, but I have the rootfs on a seperate folder... will that make a diff?
<ogra_> shouldnt
<nimesh_accenture> the instruction asks me to copy qemu-arm-static to my new rootfs's usr/bin
<ogra_> yes
<nimesh_accenture> so i did that step
<ogra_> thats fine
<nimesh_accenture> so what additional linaro package do i have to install?
<ogra_> make sure to have the proper qemu-lianro package installed
<ogra_> *linaro
<ogra_> bah, using history doesnt help if there is a typo :P
<nimesh_accenture> so how do i know which is the proper package ? apt-get install qemu-linaro ?
<ogra_> ask in #linaro
<ogra_> i cant answer that ... i dont use any cross tools
<nimesh_accenture> oki
<ogra_> infinity, hmm, seems also ac100 users see the /init not found issue
<infinity> Everyone would, yes.
<infinity> I'm working on it.
<infinity> Shh. :P
<ogra_> heh
<GrueMaster> The "/init" issue affects all arm as far as I can tell.  I am able to reproduce it on Panda with a preseeded netboot install and we are seeing it on armadaxp.
<GrueMaster> The initial bug is lp:984007
<ogra_> right, i just didnt see it mysefl since i didnt generate any initrd recently
<ogra_> but there are plenty people in #ac100 since yesterday that have fallen over systems
<GrueMaster> So, what package should that bug be filed against for tracking?
<ogra_> eglibc i think
<ogra_> but it should be fixed today
<ogra_> i wouldnt bother with bugs
<GrueMaster> Bug is already filed, just not against the right package.
<ogra_> yes, we discussed it in #arm for the last two hours
<GrueMaster> elibc in LP brings up purelibc.  Is this correct?
<ogra_> eglibc
<ogra_> or search for "infinitys home" in LP :P
<ogra_> GrueMaster, looks to me like bug 984007 has all the packages right already
<GrueMaster> Not sure why it was targeted at d-i.  Not sure how they correlate, as the install works, just post install boot that doesn't.
<ubot2> Launchpad bug 984007 in initramfs-tools "netinst d-i fails on armhf" [Critical,In progress] https://launchpad.net/bugs/984007
<GrueMaster> When I first cracked it open, only "The Eilt Project" was listed.  Which is why I asked about the package.
<ogra_> ah
<GrueMaster> Multiple fingers in the pie.
<ogra_> well, as i said, the eilt team kept us busy discussiong it for the last 2h :)
<GrueMaster> Yes, I know.  I saw the scrollback.
<ogra_> (until infinity showed up and said "yeah, i broke it" ) ;)
<GrueMaster> And was also asked to reproduce it here.
<ogra_> oh my
<ogra_> howb about they start discussions in the right place so it doesnt need someone to carry over the transcription :P
<GrueMaster> This issue appears to have been discussed in 4 separate channels then.  2 on our servers, #ac100, and here.
<GrueMaster> So, define "The Right Place".
<ogra_> here
<ogra_> unless there is highly confidential info to be tossed around :P
<spych102> i can't install omap extras because the graphics and multimedia packages don't install properly, is there another way to install the omap extras manually?
<pnphi> pbuilder-satisfydepends failed
<pnphi> what the err ?
<djszapi> ogra_: hey
<djszapi> for some reasons, my binary is not executed after reboot even after installing the relevant upstart job. :/
<pnphi> http://paste.ubuntu.com/934294/\\
<pnphi> http://paste.ubuntu.com/934294/\
<pnphi> http://paste.ubuntu.com/934294/
<pnphi> i cant fix this err
<ogra_> LetoThe2nd, bug 984007
<ubot2> Launchpad bug 984007 in initramfs-tools "netinst d-i fails on armhf" [Critical,In progress] https://launchpad.net/bugs/984007
<LetoThe2nd> hm, after netinstalling on the panda, how to fixup the locales? dpkg-reconfigure locales regenerates things, but does not offer me to change them
<rcn-ee> LetoThe2nd, i usually "sudo update-locale LANG="en_US.UTF-8" LANGUAGE="en_US.UTF-8" LC_ALL="en_US.UTF-8"" or whatever you want..
<LetoThe2nd> rcn-ee: basically i just want to change the encoding to something sane. for messages and everything else, "C" is totally fine.
<scientes> FUUUUUUUU
<scientes> "ThatÂ´s the case of the FlexCAN interface, the i.MX53 Support it, but the QSB Board does not have access to this interface. I apologize for this inconvenience.
<scientes> "
<scientes> -freescale email
<jimerickson> just did an update and rebooted pandaboard and all i get is a kernel panic. going to re-image card with todays image and try again.
<LetoThe2nd> jimerickson: https://bugs.launchpad.net/bugs/984007
<ubot2> Launchpad bug 984007 in eglibc "netinst d-i fails on armhf" [Critical,In progress]
<jimerickson> ok thanks at least they know about it.
<LetoThe2nd> jimerickson: looks like initramfs-tools is/was broken
<jimerickson> so i should wait on any updates after i re-image the card
<LetoThe2nd> jimerickson: bugtracker says fix released...
<jimerickson> ok thanks LetoThe2nd
<GrueMaster> jimerickson: I would wait until tomorrow's images are built.  The current ones are broken.
<scientes> jimerickson, or you could fix it up with qemu-arm-static and the specific fixed versin
<avinashhm> Hi , has any one used alsamixer in linaro-nano OR linaro-developer .. after installing alsamixer, when i launch, i get strange characters on the screen .. may be something related to color packages .. but not exactly sure .. has anyone tried alsa mixer on -nano OR -developer .. pls do give any pointers
<avinashhm> I am getting o/p like - http://paste.ubuntu.com/934710/
<jimerickson> GrueMaster: yes. broken. waiting...
#ubuntu-arm 2012-04-18
<ncharles> anybody know the default username/password on the 11.10 omap install?
<infinity> ncharles: There isn't one until you install it.
<infinity> ncharles: At which point, it's the one you set up.
<ncharles> this is with the armel minimal image
<ncharles> I found it, it was ubuntu/temppwd
<twb> You're probably still in the oem phase then
<infinity> Err.
<infinity> Or not an actual ubuntu image at all.
<ncharles> it was the r0 image I had floating around
<infinity> "r0"?
<ncharles> ubuntu-11.10-r0-minimal-armel
<infinity> Yeah, that's not an ubuntu image.
<infinity> Not an official one.
<infinity> As in, not built by us.
<ncharles> oh ok, it was the one i could get the ethernet working with
 * infinity isn't sure how much he trusts rcn-ee.net
<infinity> But okay.
<ncharles> what is the prefered image for a beagleboard-xm?
<infinity> desktop or server?
<ncharles> server
<infinity> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/current/
<ncharles> ok well maybe I'll try that image then
<ncharles> does that work well with the beaglebone?
<infinity> Not sure, don't have one.
<infinity> I haven't heard excessive complaints, though.
<ncharles> i have one coming tomorrow so i'll have to give it a shot
<ndec> ogra_: hi... need an advice on ubuntu/debian pkg ;-)
<ndec> we have several flavor of our MM firmware, and I thought we should use update-alternatives to manage them all.
<ndec> is that a good idea?
<ndec> in the first place?
<infinity> ndec: Oh, speaking of packaging.
<ndec> infinity: hi!
<infinity> ndec: You guys are really going to want to rebuild your binary drivers with our latest toolchain.
<ndec> why that?
<infinity> ndec: The mali folks just discovered yesterday that not rebuilding caused them pain when they tried to package.
<ndec> i don't get it.
<infinity> ndec: dpkg-shlibdeps can't handle binaries with the old linker path.  And, frankly, I don't care enough to mangle it, because in every non-binary-blob case, dpkg-shlibdeps (obviously) is operating on freshly-built binaries.
<ndec> what kind of problems? you uploaded new gcc and it breaks something?
<ndec> argh...
<infinity> ndec: Oh, you missed the drama, I guess.
<infinity> ndec: Linker path for armhf got bikeshedded to death, I was awake all weekend re-tooling.
<ndec> actually, no. i enjoyed reading the emails every day ;-)
<infinity> ndec: Your old packages still work fine.
<infinity> ndec: But rebuilding them will break.
<infinity> ndec: (As in, rebuilding the Debian packages will break, because of the blobs)
<infinity> ndec: So, just a quick rebuild of the blobs with the current toolchain, and life's good.
<ndec> when you say the old package works, did you try any application or just libs?
<infinity> Oh, it all works.
<infinity> All old binaries work fine.
<ndec> ok.
<infinity> This problem is isolated specifically to dpkg-shlibdeps, and my unwillingness to "fix" it for a use-case that I don't think matters. ;)
<infinity> So, you've been warned.
<ndec> is the new toolchain in the archive now?
<infinity> If you need to rev the Debian package, you'll need to rev your binaries first, that's all.
<infinity> ndec: Yeah, the archive is all good to go.
<ndec> ok. thx.
<infinity> ndec: Same for Debian, if you build for them too, I dunno.  I got Debian all fixed up yesterday/today.
<infinity> (Though, I'm guessing you build your binaries in such a way that they'd work on both distros, but I've never taken a close look)
<ndec> infinity: we never really tried them on debian...
<ndec> and to be honest, we never explicitely tried to make sure they would work on debian... so if they work, it's pure coincidence...
<infinity> Fair enough.
<infinity> Well, if they link dynamically with glibc, they definitely won't work on Debian right now.
<lilstevie> glibc abi break?
<infinity> lilstevie: Eh?  Well, we're ahead of Debian, that's all.  2.15 versus 2.13.
<infinity> So, if their build accidentally picks up any 2.14/2.15 symbols, no workie on Debian.
<infinity> Not a big deal.
<lilstevie> ah
<infinity> Maybe if I find some spare time post-release, I'll wrangle Debian to 2.15 as well.
<infinity> But I don't look forward to making sure all the weird (k*bsd, gah) patches forward-port cleanly.
<lilstevie> lol, yeah that does not sound fun at all
<lilstevie> by the way have you looked at the universal kernel thing at all for tegra?
<infinity> Haven't had any time to play, really. :/
<infinity> It obviously won't happen for precise, with release being 1.5 weeks away. :P
<lilstevie> heh yeah sure
<lilstevie> more for future
<lilstevie> gives time to work on a proper solution
<lilstevie> we have some hacks in the tf201 kernel that may help expand it out a bit though
<lilstevie> https://github.com/EnJens/kernel_tf201_stock/commit/cbdf1403453c6a6304c25df94b4f371d229b9030
<rbasak> What's the easiest/recommended way of telling armel and armhf apart from ubuntu userspace?
<rbasak> I know of dpkg-architecture but that needs it to be installed
<rbasak> ldd /bin/sh or something perhaps?
<infinity> rbasak: dpkg --print-architecture.
<infinity> rbasak: Anything else could be a false positive, due to multi-arch.
<rbasak> awesome, thanks!
<infinity> rbasak: (but if it's not a multi-arch system, testing for linkers and such works, yeah)
<infinity> rbasak: I would have assumed you'd already know of dpkg --print-architecture :P
<rbasak> I knew that dpkg knew the answer, just didn't know about that flag.
<infinity> Don't tell me that people are using uname hacks or something to determine i386/amd64.
<infinity> Which is, again, wrong.
<rbasak> They probably are
<rbasak> dpkg isn't cross-distro!
<infinity> Err, no, but you use the right tools on the right targets.
<infinity> userspace and kernel arch don't relate at all. :/
<infinity> I really don't want to look at cobbler and maas and all that, do I?
<infinity> I'll just end up crying.
<rbasak> :)
<rbasak> cobbler is quite RH biased.
<nimesh_accenture> how do I put the pandaboard in fastboot mode? i'm basically stuck on :  out/host/linux-x86/bin/fastboot oem format , it says waiting fro devices
 * ogra_ thinks thats better asked in an android channel :)
<lilstevie> infinity: I have used the tag off uname in my installer shell script for ubuntu for the transformer cause I couldn't find a better way
<lilstevie> that works cross-platform
<ogra_> lilstevie, not cross platform, but cleaner: use archdetect
<lilstevie> ok :)
<lilstevie> well to be honest when I get some time to tackle Qt being a PITA I will be migrating over to a GUI anyway
<infinity> lilstevie: Why would you need uname for a device-specific installer?  It'll always be the same, surely? :P
 * ogra_ thought he had seen infinity say good night a while ago in a differnt channel ... 
<ogra_> :)
<infinity> ogra_: I failed.
<ogra_> as usual ...
<lilstevie> infinity: there is an executable that will only work in its flavor (i386 or x86_64)
<infinity> lilstevie: So, I can't install to transformer from my PPC machine?  Sad.
<infinity> lilstevie: But yeah, uname's the wrong answer for that.  I could have an x86_64 kernel and an i386 userspace, and the binary would still fail.
<lilstevie> true
<lilstevie> and no, you cannot because there isn't an nvflash for ppc
<xranby> how about using qemu-user and a i386 userspace on the ppc to run nvflash?
<lilstevie> well that could work
<lilstevie> however an upcoming program should handle that
<lilstevie> we have spent the past few months reversing the protocal
<xranby> how nice of you,  setting up qemu-user are quite a pain :)
<xranby> i have mostly used it to run some of the android sdk binarys on my ac100
<lilstevie> heh
<lilstevie> it doesn't help that there are 2 very different versions from HC to ICS though
<djszapi> ogra_: Hey, interesting that, ubuntu does not have /usr/include/linux/leds.h for the pandaboard
<ogra_> did you look under /usr/include/arm-linux-gnueabihf/ ?
<ogra_> and do you have the necessary -dev packages installed that contain the headers
<djszapi> root@linaro-ubuntu-desktop:~# find /usr/include/arm-linux-gnueabi/ -name \*led\*
<djszapi> root@linaro-ubuntu-desktop:~#
<djszapi> find /usr/include/ -name \*led\* -> returns nothing
<djszapi> interesting patch from the near past:
<djszapi> http://lwn.net/Articles/492249/
<djszapi> http://us.generation-nt.com/answer/patch-arm-omap4-pandaboard-turn-phy-reference-clock-at-init-help-201703292.html -> linux/leds.h should exist, but it does not apparently exist for some reasons. :/
<ogra_> it definitely exists in some package
<ogra_> install apt-file and search for it ;)
<djszapi> I would hope for its availability by default on the pandaboard...
<ogra_> not if its in i.e. linux-ti-omap4-dev or some such
<ogra_> we dont install dev packages by default
<djszapi> uncool on a dev board
<ogra_> well, we do, but only a selected minimal set
<ogra_> we also dont special case our images for "dev boards" :)
<ogra_> thats something linaro does
<djszapi> well, it is a linaro-ubuntu-desktop after all.
<ogra_> well, if you used a linaro image, ask them about the header ;)
<djszapi> #linaro ?
<ogra_> ubuntu just tries to build as close to the other areches as possible if it comes to images
<djszapi> hmm, apt-file update downloads a lot of stuff...
<ogra_> its like apt-get ... carries its own db though
<ndec> ogra_: hi. is 12.04 LTS for ARM?
<ogra_> only on server afaik
<ogra_> havent heard any final words about LTS yet though
<ndec> ok.
<ndec> btw, what does 'only server' mean? you can install any package even on server, no?
<ogra_> sure, but only packages in the server set will be cared for during the 5 year period in that case
<djszapi> ogra_: the newest packages are "linux-headers-3.0.0-17" and "linux-headers-3.0.0-17-omap".
<ogra_> desktop gets updates from the x86 uploads indeed, but nobody would look into arm specific issues after 18 months
<djszapi> ...and I am having this: uname -r
<djszapi> 3.1.1-26-linaro-lt-omap
<ogra_> djszapi, you look for omap4
<ogra_> and *not* a linaro kernel (unless thats what you currently use)
<djszapi> I do ?
<djszapi> linux-headers-3.0.0-1208-omap4 -> this is the newest I found.
<ogra_> yeah, that sounds right
<ogra_> though there might be a 3.2 one as well
<ogra_> or should
<djszapi> not after apt-get update
<ogra_>  linux-ti-omap4 3.2.0-1412.16 was the last upload to 12.04
<djszapi> it is oneiric...
<ogra_> oh, then that could be right
<ogra_> infinity, https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2012-April/013579.html did that accidentially change ?
<gsnedders> Hey, is 12.04 going to be LTS on ARM?
<GrueMaster> gsnedders: That is the working theory, except it will probably only apply to the pool, not to any specific platform image.
<gsnedders> GrueMaster: k, thx!
<ogra_> gsnedders, only server packages will be LTS on arm
<ogra_> and only on omap4 (though that doesnt matter much for userspace)
<ogra_> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest
<gsnedders> ogra_: I guess things like libGL aren't server?
<ogra_> right
<jimerickson> todays image works. updated and installed pvr sgx driver. all is well.
<pnphi> How to build package for ARM in chroot ?
<smplman> jimerickson: what hardware>?
<jimerickson> oh sorry the pandaboard ES
<pnphi> ARM ubuntu
<smplman> jimerickson: i can't get sec working on my beagle board xm
<smplman> sgx*
<nimesh_accenture> ok guys.. so i've succesfully managed to chroot ubuntu-core 11.10 on android ICS 4.03 ... gtg now ... and thx for helping me out!
<ogra_> smplman, please file a bug ... i think we missedf to add autodetection support to jockey for omap3 ... while omap4 landed (so you get the sgx driver automatically after first boot)
<ogra_> (file it against the "jockey" package)
<smplman> how are you all pulling the binary bits from TI?
<ogra_> they hand them to linaro, linaro prepares a package, some ubuntu dev uploads to the ubuntu archive
<pnphi> How to build package for ARM in chroot ?
<djszapi> ogra_: Hey! Is it normal if the Status Led 1 still keeps blinking after running a "sync(); reboot(LINUX_REBOOT_CMD_POWER_OFF);" from my application so the board is essentially powered off.
<djszapi> ogra_: what twl6030 power features have you put in there ?
<djszapi> this is the "uname -a" output: Linux linaro-ubuntu-desktop 3.1.1-26-linaro-lt-omap #26~lt~ci~20120325001352+1332635991~4f6ec49b-Ubuntu SMP PREEMPT  armv7l armv7l armv7l GNU/Linux
<GrueMaster> djszapi: This is probably best asked on #linaro, as it is their kernel, not the stock Ubuntu kernel.
<ogra_> yeah, thats not our kernel
<djszapi> perhaps not
<infinity> ogra_: --as-needed has been the default since oneiric.  Not sure where this person got "a few days ago".
<micahg> hehe, we even fiddled with it during the natty dev cycle and reverted at the last minute
#ubuntu-arm 2012-04-19
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<syria|> Ø§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ±ÙÙØ§ÙÙØ±Ù ÙØ
<StevenK> jbroome: Thanks!
<jbroome> np
 * jbroome Whooshes!
<pangolin> that should fix that
<pangolin> if there is anymore issues please feel free to join #ubuntu-ops and let us know :)
<twb> I'll try to remember that in future; I asked #freenode
<scientes> does anyone know what that means? (yes i tried google translate)
<twb> Is it arabic or persian?
<scientes> google translate said arabic
<scientes> but it didn't manage to translate it to any word that made sense
<twb> libtranslate-bin says "Shit Vrivialqrv" (the latter word repeats)
<scientes> yeah thats what i got to
<twb> Which makes sense; the second word repeats in the original text also
<scientes> i just dont know what "Vrivialqrv" means, and im a native english speaker
<scientes> so translation obviously didn't succeed
<scientes> (for me at least)
<twb> It's probably a transliteration
<twb> i.e. it's an arabic word using roman letters
<scientes> yeah
<LetoThe2nd> howdy! tried the armhf netinstall for omap4 today - Restarting system. is the last i see. then it's stuck.
<LetoThe2nd> created partition 1 with 72M, fat32, flashkernel obviously also found it
<LetoThe2nd> the boot.img-fat.serial i used was this:http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/ so should be the updated, fixed version
<LetoThe2nd> just tried again.
<LetoThe2nd> fact: pandaboard does not boot anymore after finished netinstall hf.
<LetoThe2nd> ogra_: ping ^^^^ (who might know about?)
<ogra_> LetoThe2nd, hmm, infinity did the last d-i build i think
<ogra_> can you see anything on serial ?
<LetoThe2nd> nothin. it obviously doesn't even find MLO/uboot
<ogra_> also best file a bug and attach the syslog
<LetoThe2nd> what log... :(
<ogra_> (and possibly partman.log)
<ogra_> well, /var/log/syslog from your install :)
<LetoThe2nd> hmkay. to be found where on the sd card? are those files persistent?
<ogra_> yep
<LetoThe2nd> ok, will do.
<ogra_> the installer copies all logs at the end of the install
<ogra_> i assume its either one of the recent linker changes (unlikely) or the partitioning thats messed up (more likely)
<ogra_> did you pick guided partitioning ?
<LetoThe2nd> ogra_: partitioning was done manually as suggested.
<ogra_> ah, k
<LetoThe2nd> part1 is 72MByte FAT32, bootable flag set
<ogra_> and your former test install worked iirc
<LetoThe2nd> shame on me, i realized later that it was armel.
<ogra_> i dont think the flag matters
<ogra_> but you did the armel install with the same partitioning scheme ?
<LetoThe2nd> yep.
<ogra_> k
<ogra_> so it *shouldnt* be partitioning :)
<LetoThe2nd> one could guess that.
<ogra_> also, did you check the SD ? does it actually have the partitions, are MLO and friends where they should be etc
<LetoThe2nd> did after the last install. will do again in a few minutes, just need my sd reader otherwise.
<LetoThe2nd> then i can also look into the logs.
<ogra_> k
<fhilly_> Hi all
<fhilly_> is there any work on Ubuntu to work on allwinner a10 ARM chipset?
<ogra_> not atm, there might be community people working on it, but if so, they didnt show up here yet
<LetoThe2nd> ok, now i've got the logs ready. first partition looks basically good, MLO, u-boot.bin, uImage, uInitrd and boot.scr are all there.
<fhilly_> ogra_, regarding testing Ubuntu images on beagleboard, is there and test cases to be run for testing the images, or just install and use it will be sufficient?
<ogra_> fhilly_, testcases should be linked from the omap image entry on http://iso.qa.ubuntu.com/
<ogra_> http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage (disregard the outdate link to the old install instructions in point 1)
<ogra_> LetoThe2nd, weird
 * ogra_ was hoping for something obvious
<LetoThe2nd> Bug #985520
<ubot2> Launchpad bug 985520 in debian-installer "pandaboard ES does not boot after using armhf netinstall" [Undecided,New] https://launchpad.net/bugs/985520
<LetoThe2nd> anything else i should add?
<ogra_> LetoThe2nd, hmm, i cant see anything obvious
<LetoThe2nd> hehe
<fhilly_> Thanks ogra_
 * ogra_ will try to reproduce the netinst bug later today, i really cant find a single issue in the logs
<LetoThe2nd> ogra_: are any other logs of interest?
<ogra_> not really
<ogra_> your install went totally fine though
<LetoThe2nd> thats what i thought too ;)
<LetoThe2nd> anyways, thanks in advance and just ping me if you need additional info.
<ogra_> and the final install is using the exact same kernel the installer used during install, so its definitely not a kernel issue either
 * LetoThe2nd does not believe in such a high level issue. u-boot is not even startin.
<ogra_> well, i would say its the first partiton but even that looks ok
<LetoThe2nd> is there a difference between uboot in armel/armhf?
<ogra_> apart from being built with hf ? no
<LetoThe2nd> hmhm
<LetoThe2nd> i could offer an fdisk -l of the card, or dump of the partition table.
<ogra_> do that and attach it to the bug please
<ogra_> i wonder if parted makes the first partition not actually start at the beginning of the disk
<LetoThe2nd> ogra_: looks very much like it.
<LetoThe2nd> see last addition to bug.
<ogra_> hmm, 2048
<LetoThe2nd> nice number too, but bad for booting iomap ;)
<LetoThe2nd> omap, even.
<djszapi> ogra_: hey, ping
<djszapi> does upstart support the logging into a file ?
<ogra_> yep ?
<ogra_> yes, it does that by default in precise
<djszapi> ogra_: exec /usr/bin/foobar-commandline receive > /var/log/foobar.log 2>&1 -> I have put something like this into my upstart job.
<djszapi> but that file is entirely empty after the startup.
<djszapi> which should really be not the case.
<ogra_> did you set yourt console value in the upstart job right ?
<ogra_> iirc that manages the output handling
<djszapi> ogra_: I have mostly few lines, like: start on runlevel [23] stop on runlevel [!23] respawn exec /usr/bin/foobar-commandline receive > /var/log/foobar.log 2>&1
<ogra_> (dont ask me about details)
<djszapi> "receive" is an argument for the binary.
 * ogra_ guessed that much
<djszapi> stream redirection should work according to the upstart cookbook: http://upstart.ubuntu.com/cookbook/#exec
<ogra_> see 6.3.2 to 6.3.4 in that doc
<ogra_> +i gues you want "console output"
<djszapi> ok, upstart 1.3-0ubuntu12~linaro2 in here.
 * ogra_ has no idea about these two linaro changes
<djszapi> console log is probably better than console output in my case
<ogra_> but if you use a linaro image i think #linaro is the better place
<djszapi> sure
<ogra_> yeah, log sounds better
<ogra_> i guess you need to drop your output redirect though
<djszapi> of course.
<ogra_> since it looks like upstart wants to manage the file
<djszapi> yep, which is fine enough. ;)
<djszapi> though, there is no "/var/log/upstart" after the reboot.
<djszapi> I inserted the "console log" line after the "respawn" line and before the "exec" line.
<ogra_> djszapi, well, as i said, no idea what the two linaro changes are your version number indicates ... probably they switched loggin off :)
<djszapi> that would be a nasty one.
<ogra_> ask them :)
<ogra_> (or read the changelog)
<ndec> ogra_: hi. is compiz working now out of the archive on panda?
<ogra_> ndec, it *should*
<ndec> there is a subtle difference between it should and it does ;-)
<ogra_> i still havent gotten around to actually test it but plan to do so before end of the week
<ogra_> in any case all code is in, sgx gets automatically installed on first boot as well
<djszapi> ogra_: can I delete the linaro upstart, and install a stock ubuntu one ?
<ogra_> dunno, do you know what the changes are that linaro made ?
<djszapi> no clue
<djszapi> ogra_: is there a dpkg option for checking the changelog ?
<ogra_> ??
<ogra_> just look in /usr/share/doc/...
<ogra_> every package ships its changelog in its doc dir
<djszapi> ogra_: I do not see anything related: http://paste.kde.org/459902/
<djszapi> ogra_: this is my upstart job: http://paste.kde.org/459908/
<ogra_> well, i'm out of ideas, probably ask jodh (he is the upstart maintainer in ubuntu) in #ubuntu-devel
<djszapi> ogra_: you do not see any issues with the upstart job, right ?
<ogra_> nope
<ogra_> but i'm no upstart expert, mind you
<djszapi> jodh is also in #upstart, cool
<djszapi> ogra_: heh, figured out
<ogra_> what was it ?
<djszapi> console log was introduced in 1.4
<ogra_> oh
<nimesh_accenture> Hi guys... i have my Ubuntu image on the sdcard... how do i make a backup of it on the desktop?
<LetoThe2nd> nimesh_accenture: use dd
<nimesh_accenture> ya.. but that has a lt of options that need to be given... not sure ... which ones to give...
<LetoThe2nd> nimesh_accenture: usually you need if, of, and bs.
<LetoThe2nd> nimesh_accenture: googling "dd backup sd card" also gives a lot of ideas.
<nimesh_accenture> cool thx!
<djszapi> ogra_: pingie..
<LetoThe2nd> ogra_: it seems the partition table in the netinstall image is broken. see bug #985520
<ubot2> Launchpad bug 985520 in debian-installer "pandaboard ES does not boot after using armhf netinstall" [Undecided,New] https://launchpad.net/bugs/985520
<ogra_> djszapi, yes ?
<djszapi> ogra_: the modem on the serial port is most likely not initialized at the time my binary tries to write it during the upstart setup
<ogra_> LetoThe2nd, argh ... CHS issue it seems
<djszapi> ogra_: how can I postpone that, or which event shall I connect to ?
<ogra_> create a udev rule instead of an upstart job ?
<LetoThe2nd> ogra_: looks like that.
<ogra_> i wonder why though, since netinst is used in our automated testing infrastructure that shouldnt have shown up there as well
<LetoThe2nd> ogra_: don't ask *me* ;)
<ogra_> heh
<ogra_> well, theoretically CHS shouldnt have any influence on u-boot/MLO anymore
<ogra_> as a workaround you could try ext2 instead of vfat
<ogra_> iirc if you pick guided partitioning that default to an ext2 that gets mounted under /boot
<LetoThe2nd> i though guided partitioning is also broken?
<LetoThe2nd> and so far i'Ve never heard that the omap boot rom is ext2 capable.
<GrueMaster> LetoThe2nd: Are you doing a netboot install to the SD or to a USB drive?
<LetoThe2nd> GrueMaster: to the sd
<LetoThe2nd> GrueMaster: not really netboot install, its http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/boot.img-fat-serial
<GrueMaster> Yea, that won't work with guided partitioning, and I doubt you will get far with manual either (the way partman tends to screw up partitions).
<GrueMaster> Yes, that is netboot install.
<LetoThe2nd> GrueMaster: exactly. interesting fact - the precise armel one worked like a charm.
<GrueMaster> That particular image is for partition 1.
<GrueMaster> Use boot.img-serial.
<GrueMaster> And flash it to the entire SD device.
<LetoThe2nd> ah.
 * LetoThe2nd thought that the image i linked is just whats inside the -serial.tar.gz
<LetoThe2nd> improvement suggestion: give some rough information on the various images at https://wiki.ubuntu.com/ARM/OMAP :)
<rsalveti> ndec: where is the git tree for the 3.3 based kernel you're publishing to the ppa?
<ndec> rsalveti: as usual : http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=summary
<ndec> pick the right branch based on ABI.
<rsalveti> ndec: how is this related with the tilt-3.3 tree produced by the ti lt?
<rsalveti> probably based on it, but I don't see a clear tag, just the patches
<ndec> rsalveti: i think it's based on -21 tag from tilt.
<rsalveti> ndec: yup, seems so
<ndec> rsalveti: so you are trying to get the pkgs from 'trunk' ppa>?
<rsalveti> ndec: I'm just trying to understand which tree I'm going to track for the lebs :-)
<rsalveti> as we now got updates on both
<ndec> kernel?
<rsalveti> yup
<ndec> track Xavier's tree.
<ndec> this one is tested against X and video.
<ndec> fromt runkl
<ndec> trunk
<rsalveti> ndec: sure, then I expect xavier will keep updating his tree based on andy's one
<ndec> yep
<ndec> and the PPA as well...
<ndec> we are working atm at making GST updates for this new libdce (rpmsg) and new X/DRM
<ndec> rsalveti: btw, we have started 3.4 migration... and it's likely that -1482 kernel is the last 3.3 before we move to 3.4... fyi
<rsalveti> ndec: great, any eta to get the gst packages in place?
<ndec> rsalveti: when the development is done ;-)
<rsalveti> ndec: hm, ok
<rsalveti> ndec: ;-)
<ndec> i would hope by e/o this month...
<ndec> at least for decoders.
<rsalveti> yup, sounds good then
<ndec> rsalveti: did you see Xav's email? on armel image?
<rsalveti> ndec: yup, confirmed
<ndec> hehe
<rsalveti> ndec: already reported at #ubuntu-release
<ndec> it's always when we have to make a TI release ;-)
<rsalveti> ndec: :-)
<ogra_> janimo`, http://developer.nvidia.com/linux-tegra ... seems thesy released a new beta15
<ogra_> (and no, there is no armhf binary in there)
<janimo`> ogra_, yeah I think I saw that alpha a while ago, too bad there's no HF :(
<ogra_> well, i wonder if we should update or not
<ogra_> it surely has some fixes
<ogra_> but then, how much do we care for armel
<ogra_> i mean its nice they released it today so we still have a chance to pull it into precise if we want ...
 * ogra_ wouldnt have noticed if the nvidia guys wouldnt just discuss it in #ac100 :) 
<infinity> ogra_: Is there anyone you can ping about why there's still no armhf?
<infinity> ogra_: (for the nvidia blobs)
<infinity> ogra_: I'm not against armhf magically appearing in an SRU of said blob, FWIW.
<ogra_> well, swarren is resident in #ac100 ... he works on it but seems to have no influence on what gets built
<infinity> (Would be nice to have jockey support too, but I'm guessing no one ever got around to that)
<ogra_> well, jockey support is trivial ... we just add it to the omap4 panda code
<infinity> s/to/alongside/ but yes, I agree.  It's trivial.
<infinity> And would have been a no-brainer a week ago. ;)
<infinity> Now, it's hardly RC.
<infinity> But you might be able to convince the SRU team it's zero impact for !ac100, if it's well-contained.
<ogra_> well, do we care for an update to the armel driver ?
<ogra_> i agree we should SRU if an hf driver shows up
<infinity> I'm not sure that I care deeply.
<ogra_> but i'm not sure we should bother with the el one
<infinity> We're not producing armel images anymore, so this would purely be for people installing from oneiric and upgrading.
<ogra_> right
<ogra_> well, the driver ships a minimal ubuntu armel rootfs in the tarball
<infinity> *choke*
<infinity> That's special.
<ogra_> and has instructions how to install the desktop
<ogra_> (one full page to explain apt-get install ubuntu-desktop) :)
<infinity> Brilliant.
<infinity> So, the next time you see swarren (he's not online right now), can you ask him to ping me?
<ogra_> srwarren
<ogra_> sorry, missed the r
<infinity> Damnit, xfce-terminal, middle-clicking on an email address shouldn't open a mail client.
<infinity> Every third time I try to middle-click-paste into IRC, someone joins or parts a channel right under my mouse. ;?
<infinity> :/
<ogra_> just unset the mailto mimetype ;)
<infinity> No, middle-click shouldn't be doing anything BUT pasting.
<infinity> It's wrong for it to be doubling as left click.
<ogra_> <ogra_> srwarren, whats the blocker ?
<ogra_> <ogra_> essentially its just a recompile
<ogra_> * ppisati hat die Verbindung getrennt (Remote host closed the connection)
<ogra_> <srwarren> Well, we found a bug in gcc for one, which set our validation process back a long way
<ogra_> <srwarren> Of course, and it's fixed in a newer release
 * ogra_ wonders what ancient gcc they use internally at nvidia
<LetoThe2nd> oO( 2.95 )
<djszapi> ogra_: pingie...
<djszapi> am I using initramfs while booting ?
<ogra_> whats up ?
<djszapi> I have been asked, and I have seriously no clue
<djszapi> probably I do, I believe.
<ogra_> heh
<djszapi> ubuntu linaro thingie
<djszapi> oneiric
<ogra_> well, if you dont use quiet on your cmdline it shoudl be pretty obvious ...
<djszapi> sorry ?
<ogra_> else you need to check your boot log/dmesg, it will tell you
<djszapi> dmesg | grep initramfs
<djszapi> [    0.372070] Trying to unpack rootfs image as initramfs...
<ogra_> if the boot isnt quiet it talks about the init-top/init-bottom scripts etc
<ogra_> thats clearly stuff that only comes from an initrd
<djszapi> I had the impression it means I do use.
<ogra_> usually all ubuntu images use initramfs ... i would assume linaor does too
<djszapi> I am normally not checking the boot anyway, just using ssh
<djszapi> way after the boot.
<ogra_> well, if you used a std linaro image it should use the initrd
<djszapi> perhaps,
<ogra_> better ask in #linaro though
<ogra_> i dont use linaro images
<sveinse> I'm installing a chrooted armel system on a desktop intel machine (natty) using binfmt&qemu. This installer does a loopback mount, which works on my desktop machine (natty, amd64), while on the build server (natty, server, i386) it fails "loop: can't delete device /dev/loop0: No such device or address". Anything familiar to anyone?
<ogra_> sveinse, why so complex ?
<ogra_> use qemu-debootstrap
<ogra_> (there is no reason to use a loop device)
<sveinse> I am using debootstrap, initially. However, the (custom) system update comes on a image file, ISO to be specific, and needs to load the debs from it.
<sveinse> So this mechanism works perfectly on my machine, but not on the build server. There are two differences I can think of here: 1) I'm running dektop natty vs. server natty  2) I'm running stock qemu while server is runnning linary ppa qemu (to fix some qemu bugs)
<sveinse> But I guess you're shrugging already when I mention chroot and install armel system with qemu
<ogra_> well, does your server have loopdevice support ?
<sveinse> ogra_: Why so complex? Well, let me sidetrack and explain. Basic question: How do you update a system with a small sdcard? No internet, just USB. You put the debs on the USB stick. Secondly, you don't want to put 400 files on a USB stick (the customer will mess something up), so you need to encapsulate them into something, hence the ISO file and loopback. The beauty of loopback is that it...
<sveinse> ...can be mounted and installed from without any copying to disk which is painstakingly slow.
<ogra_> why do you take the iso format and not just .img ?
<ogra_> (with ext2 or so)
<ogra_> anyway, looks like your server doesnt know how to handle loopback devices
<ogra_> ahs3, did you already get a recent ubuntu to run on your cubox ?
<sveinse> I could. I think it was the convenience of mkisofs, i.e. not having to know the size of the img before copying all its contents. But we're about to merge to squashfs
<ogra_> (there is a guy in #ubuntu-devel trying that since yesterday)
<ahs3> ogra_: dunno.  haven't had any time to play with it yet
<ogra_> ah, k
<sveinse> Anyways, loopback is enabled on the server, as loopback are used elsewhere, but in the context of non-chroot and non-qemu/armel
<ahs3> you know, the day job and all that...
<ogra_> ahs3, yeah, these unimportant things
<ahs3> :)
 * ogra_ looks at his half finished tube amp and knows what you mean :) 
 * ahs3 pushes the partially disassembled auraslate tablet under the desk so no one can see it
 * sveinse likes ogra_'s project
<ogra_> it a constantly ongoing  thing :) i build one in a quater ...
<sveinse> you HW guy? (I am)
<ogra_> without that day job crap i would be able to build one per month ! and sell them probably
<ogra_> only partially HW guy ...
<ogra_> tubes are my compensation for all the high tech i have to handle daily ... needs some low tech in the spare time ;)
<sveinse> :)
#ubuntu-arm 2012-04-20
<scientes> anybody have a static armel coreutils? i only need chroot
<infinity> scientes: busybox-static should have chroot built in.
<scientes> infinity, i've got a guy in #debian-arm where debootstrap from lenny arm fails
<scientes> with invalid instruction
<twb> scientes: is he using qemu arm cpu emu?
<twb> There was a memory initialization bug in pre-2.0 qemu
<scientes> twb, no he is using the NSLU2
<scientes> with 2.6.32
<scientes> *2.6.26
<twb> pre 1.0 I meant, but OK
<scientes> he is doing a armel chroot
<scientes> does he need a newer kernel for EABI support?
<twb> NFI
<twb> Is it a recent ubuntu armel chroot?  You know recent ubuntu is v7 only right?
<scientes> no its squeeze
<scientes> ubuntu wouldn't work
<infinity> It's been a LONG time since I played with OABI, but aren't there kernel config differences between OABI and EABI-supporting kernels?
<scientes> infinity, every syscall is differn't
<scientes> but the new kernels support the old arch
<infinity> That would be a "yes". :P
<scientes> i just dont know which version
<infinity> Sure, but does he have a new kernel?
<infinity> I'd assume not.
<scientes> the EABI syscalls are 0x90000000something+
<scientes> 2.6.26
<scientes> guess he needs to upgrade that first
<scientes> i mean "new" relatively
<ogra_> hmm http://www.phoronix.com/scan.php?page=news_item&px=MTA4NjA
<lilstevie> ogra_: it doesn't do a great deal yet
<ogra_> sure sure
<lilstevie> but a great start
<ogra_> but it seems to do more than just xfbdev
<lilstevie> yeah
<marvin24> needs xf86-video-modeset driver
<marvin24> I'll hackup an upstream kernel after the next iteration
<marvin24> let's see how far it will come ;-)
<lilstevie> we have an almost working nv-tegra branched kernel running on the transformer prime :D
<twb> "if it compiles it's great if it boots ship it" ?
<lilstevie> lol
<twb> linus said that
<lilstevie> it boots
<lilstevie> well, unless I build it with the cross compiler in the ubuntu repo
<twb> A mere detail
 * twb waves hand dismissively
<lilstevie> :p
<LetoThe2nd> jedi hand move? ;)
<twb> more like politician
<LetoThe2nd> hrhr
<nimesh_accenture> what does this error mean? sh: cannot create /dev/null: Permission denied ? i get it on the chrooted ubuntu-core on android
<vstehle> nimesh_accenture: looks like you have an empty /dev directory. Try to 'mount -o bind /dev chroot/dev' before you chroot.
<nimesh_accenture> vstehle: :-) did that and it worked
<nimesh_accenture> Also, I wanted to check the stability of my chroot, so is are there a set of tests that I can run on ubuntu shell to check if all the basic things like audio/framebuffer/wifi/ethernet etc. are in order?
<vstehle> nimesh_accenture: for fb, you can always 'cat /dev/urandom > /dev/fb0' :)
<vstehle> for audio, aplay comes to mind
<vstehle> for wifi, try an iwconfig first
<vstehle> for ethernet, a ping is a good start
<ogra_> infinity, i guess you dont need to wait for the compiz stuff, the branch and the package have diverged (unuploaded changes in the branch), so i cant produce a sane patch that wouldnt cause havoc between package and branch (once again) ... unless i upload whats in the branch ... it seems that didrocks is on vacation and i dont want to blindly upload bits i dont know about...
<infinity> ogra_: Gah.
<ogra_> yeah
<infinity> ogra_: Tell me there's a hope we can fix it for release?
<infinity> (But I guess 0-ish day SRUs will be "okay"...)
<ogra_> i dont think so, we would have to update the patch after each commit
<infinity> ogra_: Mon/Tue would still be fine, if we can manage.
<ogra_> k
<ogra_> this will be a mess for five years though ... i dont see a clean solution (apart from the above which surely is a fulltime job)
<nimesh_accenture> vstehle: thx
<infinity> ogra_: Well, I would hope unity isn't getting major updates post-release.
<nimesh_accenture> vstehle:  but is there a test suit that does this for us? something similar to cts in android
<ogra_> infinity, hahaha
<infinity> ogra_: LET ME HAVE MY FANTASY.
<vstehle> nimesh_accenture: a test suite? There is a "Linux test project" and a Phoronix test suite, I think. But I did not run them.
 * ogra_ grins
<nimesh_accenture> vstehle:  ok...cool! i'll take a look thx again!
<rsalveti> ogra_: do you have the new package or patch done locally already? I can also help testing it if you want
<ogra_> rsalveti, alf_, http://people.canonical.com/~ogra/compiz/
<vstehle> ogra_: thanks! it works on omap5 :)
<ogra_> heh
<nimesh_accenture> guys i'm  getting this error on ubuntu-core 11.10 chrooted on Android ICS :  Temporary failure resolving 'ports.ubuntu.com' . is this a DNS issue? i changed /etc/resolve.conf with my local DNS ip add... the ubuntu-server version 11.10 works fine...
<ogra_> rsalveti, alf_, any news ?
<rsalveti> ogra_: updating/upgrading
<rsalveti> want to make sure it works with the latest stuff
<ogra_> right
<infinity> nimesh_accenture: Either you got resolv.conf wrong, or your DNS server is/was upset.  There's not a whole lot else that can go wrong there.
<infinity> nimesh_accenture: (Well, or your system isn't connected to the internets)
<nimesh_accenture> infinity: hmmm the same DNS works for my desktop ubuntu ... is there a possibility that some ports are blocked? because i'm behind a corporate network , which has some restrictions
<infinity> nimesh_accenture: I have no idea how your network or your android system are configured.
<infinity> nimesh_accenture: All I can tell you is that setting resolv.conf in the chroot is all you need to do.  If that doesn't work, it's the host system or the network.
<nimesh_accenture> hmmm ...ok...thx infinity...i'll try and talk to the network team to find out whats going on
<infinity> nimesh_accenture: It's more likely to be your android setup than the network team's fault.  But they may have some handy tips.
<nimesh_accenture> infinity: The README of pandaboard says "Ethernet networking is hardcoded to use 8.8.8.8 and 8.8.4.4 DNS."  , but should that affect the chrooted Ubuntu?
<infinity> No.
<ndec> nimesh_accenture: if you are behind firewall, you need to configure your proxy in the chroot as well. as your config outside of the chroot isn't visible
<nimesh_accenture> ndec:  but I didn't have to configure http_proxy  on my desktop ubuntu, however /cat /etc/resolv.config on my desktop shows me the DNS ip's
<ndec> nimesh_accenture: well, if you are behind proxy, you must have some configuration somewhere, no?
<nimesh_accenture> I dont know what the networking team has done , but we dont have to configure any proxy... our ip addresses are like 10.211.xx.xx
<nimesh_accenture> ndec: thx man...gtg ...have a happy weekend guys
<rsalveti> ogra_: working nicely!
<rsalveti> alf_: and it's actually usable!
<ndec> cool, from the archive?
<rsalveti> ndec: yup
<rsalveti> ndec: but with the latest package from ogra, that just starts gtw-window-decorator automatically
<rsalveti> that should hit the archive soon
<ndec> rsalveti: nice. i am running a minimal system atm, what's the simplest way to install unity3d? ubuntu-desktop?
<rsalveti> alf_: the only thing I noticed that's a bit slow, is when you're using dash in full screen
<rsalveti> ndec: if you have to install ubuntu-desktop I'd probably recommend you to install the pre-installed image from scratch
<rsalveti> it takes so much time to update/install the packages
<rsalveti> that it's just faster to flash a new one :-)
<ndec> rsalveti: from usb it's usually not to bad...
<alf_> rsalveti: ogra_: Great! Actually I missed the ping... Ricardo can you please ping me as the second name to test something
<ndec> i have lots of things on my /, i don't really want to flash something else ;-)
<rsalveti> ndec: so I believe installing ubuntu-desktop will probably do the work
<rsalveti> alf_: the dash with the default size sounds ok, but with full screen it feels quite slow
<alf_> rsalveti: I think the full-screen active blur is too much for the sgx, when I disable the dash blur it's much better
<rsalveti> alf_: makes sense
<ppisati> guys, rootstock is not supported anymore, right?
<ppisati> what should i use instead of it?
<ogra_> rsalveti, alf_ awesome, committed and pushed, the rest has to happen once didrocks is back from vacation
<ndec> ppisati: ubuntu-core
<ogra_> ppisati, depends, there is no 1:1 replacement
<kenws> Hi there, Does anyone know what eglibc options are used on ARM (in terms of option-groups.config)?
 * kenws is looking at https://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu2/+build/3199667
<kenws> hm, probably just the defaults (everything enabled)
<ppisati> ndec: ogra_ so, what do i use to roll an ubuntu filesystem in a tarball?
<ndec> ppisati: i don't understand the question...
<ogra_> you can use -core but need to do all configuration
<ndec> and i wrote that a while ago : http://omapedia.org/wiki/OMAP_Ubuntu_Core
<ogra_> yeah, i guess i will steal from it for the ubuntu wiki :)
 * ppisati goes to read
<ndec> ogra_: omappedia, says this "Content is available under Creative Commons Attribution-Share Alike 3.0 license.." so you should be fine ;-)
<ogra_> heh
<ndec> just say my name, and how nice i am..
<ogra_> and bring some bribing money ?
<ndec> that could do it
<ndec> rsalveti: apt-get install ubuntu-desktop took less than 15 mins ;-)
<rsalveti> ndec: nice :-)
<Adebar> Anyone knows a ubuntu compatible notebook (ARM) with bigger screnn than Toshiba AC100 or Genesi Efika MX Smartbook?
<steev> there isn't one
<steev> well, maybe the macbook air
<steev> oh wait, you said ARM
<steev> there still isn't one
<steev> that said, you could get either the AC100 or the Smartbook and replace the screen, there is a 10" 1280x720 screen that is compatible (disclaimer: i work for Genesi)
<Adebar> mhm... perhaps another one knows such a device. Sry if I asked three times in ten minutes, looked like it didn't work.
<alf_> vstehle: How does unity feel on OMAP4 performance-wise?
<alf_> vstehle: oops, OMAP5
<vstehle> alf_: it does not work so well...
<alf_> vstehle: Do you think (or guess!) this is a driver issue or a compiz/unity issue?
<ndec> alf_: i am trying to setup a panda with the same driver.
<vstehle> alf_: issue is probably on my side, between keyboard and chair :)
<ndec> in fact we are now using the new xf86-video-omap driver, which rsalveti is also trying to bring up for next LEB
<ndec> for now we have driver issues.
<alf_> vstehle: lol
<alf_> ndec: ok, thanks
<ndec> vstehle: on panda, i have the black screen issue... i guess our PPA does not have the latest fixes from robclark?
<vstehle> ndec: I don't know... I have not tested on OMAP4 since a week or two.
<prpplague> rsalveti: http://tincantools.com/product.php?productid=16158&cat=0&page=1&featured
<prpplague> rsalveti: kits will be ready on monday
<ogra_> alf_, rsalveti, compiz is now in precise-proposed, would be good to give the packages in the archives another test once they built to make sure everything is fine and i didnt make any mistakes
<alf_> ogra_: great, thanks!
<rsalveti> prpplague: awesome!
<rsalveti> ogra_: will do, thanks
<gdane> hello
<gdane> i recompile my kernel and i need ipkg-utils 1.6 r21
<gdane> can some one say me wherr i can find it?
<gdane> all the time bitbake try to compile it, it says that it cant go to cvs handheld.com
<gdane> hendheld isnt work now
<gdane> so i thought may be some one help me
<gdane> i asked google before, but it shows only misstakes and not solving of this problem
<jeinor> hi! I was redirect here from #ubuntu-devel because I had arm-related questions to getting Ubuntu Core up and running on a ARM-system.
<jeinor> I got an error message trying to boot a 3.3.1 kernel about "VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0)"
<jeinor> the kernel command line is from a older kernel (2.6), I'm not really sure what command line to use with the 3.3.1 kernel
<jeinor> grateful for any assistance
<rcn-ee> jeinor, it's probally either, your bootargs don't match your partition layout, or... you don't have the necessary drives to access the drive..
<jeinor> thanks for answering . I think the drivers are there, I got the kernel configuration from a forum thread where this user (which does not respond back) said he got it up and running with that configuration.
<jeinor> it's probably the bootargs, and me not knowing how to set them in u-boot
<jeinor> I tried editing the script /boot/boot.scr by hand (vim), but whenever I do it seems to break the boot process completely (even if I just add the --verbose flag)
<jeinor> rcn-ee, ok I figured out how to change kernel command line args. Apparently I can't just change the args directly in boot.scr, I had to regenerate it using mkimage :)
<jeinor> rcn-ee, did you just reenter?
<jeinor> ah, I missed your quit notice there
<jeinor> I'll repost my last message: rcn-ee, ok I figured out how to change kernel command line args. Apparently I can't just change the args directly in boot.scr, I had to regenerate it using mkimage :)
<rcn-ee> yeah, you can't edit that directly, take a look into your u-boot printenv, it might also support "uEnv.txt" files, which are raw text files.. so nice to edit..
<jeinor> ok, thanks. I think I'll go with the method I found for now, just running the mkimage-command
<jeinor> still no luck in finding that root partition though
<rcn-ee> then it might be either a missing driver for the interface, or even misssing support for that file system.. and assuming you've ran 'fdisk -l' on it so you know it's correct..
<jeinor> it's a dd copy to a new sd card from the stock one sent with the cubox, so I think it's correct. I'll check the filesystem though, as I replaced a 2.6 kernel with 3.3.1 perhaps the default support for ext2 is dropped
<jeinor> thanks for the tips
<rcn-ee> humm, if it's ext2, i've never seen anyone disable that by default..
<jeinor> you're right, checked with "make menuconfig" and it's enabled (you can see I'm pretty new with this)
<jeinor> this makes me believe the driver is there: "mmc0: SDHCI controller on sdhci-dove.0 [sdhci-dove.0] using DMA"
<jeinor> (I'm trying to boot from a sdcard)
#ubuntu-arm 2012-04-21
<steev> i was going to suggest he add rootwait to his bootargs
<steev> some mmc devices are rather slow
<jeinor> I get this while booting kernel 3.3.1: "EXT3-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)"
<jeinor> then "EXT4-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended"
<jeinor> and then "EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)"
<jeinor> and last "VFS: Mounted root (ext4 filesystem) on device 179:2."
<jeinor> the partition is a ext2 partition, but still it seems ext4 mounts it
<jeinor> the last line in the log is "Freeing init memory: 248K", but I still don't get any login console
<jeinor> should I?
<XorA> you sure the recomended fsck isnt running?
<jeinor> no. how do I know?
<XorA> no idea unless you have disk activity light
<XorA> also not sure which ubuntu versions give a console prompt and which just go to desktop with nothing on serial
<jeinor> I don't think I do. It's a small ARM system (Cubox). But the partition is only 4 GB, so I figured it would be done by now if so
<jeinor> I'm running Ubuntu Core 12.04 beta2, there's no desktop to go to
<XorA> you could try fscking the card on a PC
<XorA> it may have got stuck with an unrecoverable error or something
<XorA> but thats all I can think off
<jeinor> good idea. Would it be enough to just reformat the partition?
<XorA> I always try and recover before getting drastic
<XorA> just to try and understand what happened
<jeinor> ok, I'll try that
<jeinor> it found some errors, fixed them, recreated the lost+found and the error message "EXT4-fs (mmcblk0p2): warning: maximal mount count reached, running e2fsck is recommended" disappeared
<jeinor> so it did something :)
<jeinor> still it cannot mount the filesystem using ext2, even if it is an ext2 filesystem. it mounts it using ext4
<jeinor> and still no login console
<XorA> at some point in time you mounted it as ext4 and wrote a file
<jeinor> hmm
<jeinor> perhaps if ubuntu did it automatically when I inserted the SD card in another computer?
<XorA> possibly
<XorA> but as to why its not booting no idea
<ogra_> ubuntu doesnt do such stuff, does your kernel have ext2 support ?
<jeinor> yes, its compiled into the kernel
<ogra_> if not, it will indeed try different FS drivers
<ogra_> also does your fstab have a proper entry for it pointing to ext2
<jeinor> no, it does not. that file is just empty
<jeinor> (heh)
<ogra_> well, that means you leave it to the kernel to do guesswork :)
<ogra_> (ubuntu-core is seriously not thought as a rootfs if you dont know how to configure it and do all bits the installer would do ...)
<lilstevie> I am having a freezing problem :/ after "init: unreadahead main process (105) terminated with status 5" it hardlocks
<ogra_> are you sure it hardlocks or does it just not display anything ?
<jeinor> well, I am learning. I had Ubuntu Core running on qemu arm, and the only modification I did to get a login prompt was to setup a root password there.
<lilstevie> yeah it hardlocks
<ogra_> weird
<ogra_> ceck your boot.log ;)
<ogra_> *check
<lilstevie> I have an image on sdcard that should just go to console login rather than starting x
<lilstevie> and also logs are not written to
<ogra_> you dont have the SD locked to readonly, do you ?
<lilstevie> this is both emmc and microsd
<ogra_> hmm
<lilstevie> on transformer prime
<lilstevie> we think it is probably the kernel, just don't know why, and seriously lacking some debugging options
<ogra_> your kernel has all necessary bits ?
<lilstevie> yes
<lilstevie> http://paste.ubuntu.com/939433/ <-- my config
<lilstevie> just incase you do see something I may have missed
<ogra_> bug 936667 came to mind, but you should at least see error messages
<ubot2> Launchpad bug 936667 in upstart "Upstart early job logging causes boot failure for systems with no initramfs (error is "No available ptys")" [High,Fix released] https://launchpad.net/bugs/936667
<lilstevie> well I do have a different error when running noinitrd
<lilstevie> but it still ends up in the same lockup
<ogra_> hmm, you have legacy pyts on
<ogra_> not sure if that can get in your way, but the latest upstart is picky about kernel options at times
<lilstevie> oh that was me trying to work around failed to create pty with noinitrd
<lilstevie> I had this problem without legacy ptys
<ogra_> wow, why do you compile loopdevice support into the kernel ?
<ogra_> 8instead of making it modular)
<lilstevie> cause that is how it is for android
<lilstevie> I haven't finished with the kernel yet
<ogra_> wow, and also DM
<ogra_> your kernel must be huge
<lilstevie> 3.5MB
<lilstevie> this is just how things are in the default android config that I haven
<jeinor> ogra_: do you know any place I can find the minimum configuration I need to do in order to get ubuntu core up and running?
<lilstevie> haven't bothered changing yet
<ogra_> wowhmm your wlan driver is also hard compiled in and has a hardcoded firmware part ...
<lilstevie> yeah, that is bcmdhd
<ogra_> jeinor, http://omapedia.org/wiki/OMAP_Ubuntu_Core has some hints
<jeinor> thanks
<lilstevie> the firmware part is hardcoded cause I needed to rearrange some things :)
<ogra_> lilstevie, i would make a lot stuff in your kernel modular
<ogra_> as a first step
<lilstevie> bcmdhd does not work, at least on android without being compiled in
<lilstevie> this is a very early 3.1.10 port, a lot of the asus stuff is still horribly intertwined
<ogra_> well, if you are sure it is locked up hard ... hard to say what it is ... if you wouldnt be sure about that i would just have guessed for a worng console= arg on the cmdline
<lilstevie> the commandline is certainly correct
<ogra_> (the ureadahead message is usually the last bit you see before the userspace console kicks in)
<lilstevie> and this kernel will boot android with its config differences too
<lilstevie> and yeah I know
<ogra_> well, that it boots android has nothing to say :)
<lilstevie> thats why I was wondering if there was something extra for a more verbose output
<lilstevie> and haha yeah .39 boots android too, but has a horribly broken framebuffer in ubuntu
<ogra_> since you seem to properly get through the initrd i would boot with something like break=top or break=premount or so in your cmdline
<ogra_> that will drop you into the initrd shell for further debugging
<lilstevie> ok
<ogra_> (and indeed make sure to not have "quiet" set ;) )
<ogra_> jeinor, note that the above url refers to pandaboards, so dont pick up things like bootloader4 config etc from there since this is HW specific
<lilstevie> yeah I only have root= at the moment
<jeinor> ogra_: got it. I used it for configuring network and root user so far
<jeinor> I also recreated the filesystem using mkfs.ext3 and reuntared ubuntu core to it
<jeinor> let's see what happens... :)
<ogra_> lilstevie, right, try break=top ... that should get you the initrd prompt right after uncompressing
<jeinor> ogra_: that removed all error messages on the filesystem. it now properly detects the filesystem as ext3 and mounts it without any error messages.
<ogra_> good
<jeinor> ogra_: i still get no login console, but I'm starting to believe there's a problem with the graphics driver. I see no output whatsoever on the monitor connected via HDMI during the boot process
<ogra_> well, do you see anything on the serial console ?
<jeinor> I don't think I have setup a serial console. Learned yesterday how to connect through putty to be able to view the output to ttyS0
<jeinor> so I see all kernel messages in the putty console window
<jeinor> but I don't think I can do anything from there
<ogra_> well, see the hints on the webpage for setting up serial login then
<jeinor> right
<lilstevie> ogra_: testing with break=top now
<ogra_> good
<jeinor> ogra_: how do I connect to my new serial console? do I use putty?
<ogra_> do you use windows on your host PC ?
<jeinor> no
<jeinor> ubuntu
<ogra_> why do you use putty then and not a sane terminal program ?
<ogra_> putty is a windows terminal emulator (that happens to have been ported to linux)
<jeinor> the guide from the Cubox wiki contained instructions for using putty
<jeinor> I see
<jeinor> what is a sane terminal program?
<ogra_> try screen ...
<ogra_> i.e.:
<ogra_> screen /dev/ttyUSB0 115200
<ogra_> that should get you a serial console in the terminal you run it in
<ogra_> (see man screen for the commands to attach/detach from that session etc)
<jeinor> that gave me a flashing prompt. Would I need to switch tty using ctrl+alt+fX?
<ogra_> no
<jeinor> ok. that SHOULD have given me a login prompt then, right?
<ogra_> it talks directly to your serial port and will exactly output what the cubox sends to the serial port
<ogra_> (you should see boot messages (and possible errors) if you reset the cubox)
<jeinor> yep, that gives me the same output as putty did before (but nicer in a normal terminal window)
<jeinor> thanks for the tip
<lilstevie> interesting
<lilstevie> ogra_: it boots when exiting from the initramfs shell
<jeinor> but if I had succeeded in configuring the serial-console, I should have gotten a login prompt here, correct?
<ogra_> lilstevie, race then ...
<lilstevie> heh fun
<ogra_> jeinor, not if there were errors during boot
<lilstevie> ogra_: what do you suggest
<ogra_> jeinor, reset the cubox and see if you see any boot errors now
<ogra_> lilstevie, debugging :P
<lilstevie> heh
<ogra_> try break=premount next ... that drops you into the console a bit later
<ogra_> if that works too, try =bottom ... that gives you the console after it mounted the rootfs
<jeinor> ogra_: same output as before, ends with "Mounted root (ext3 filesystem) on device 179:2", "devtmpfs: mounted" and last "Freeing init memory: 248K"
<lilstevie> ok
<jeinor> I'll check earlier in the log
<ogra_> jeinor, whats your kernel commandline ?
<ogra_> i.e. what does the bootloader tell the kernel when it loads it
<jeinor> "console=tty0 console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 rootdelay=2 clcd.lcd0_enable=1 clcd.lcd1_enable=0 --no-log --verbose"
<ogra_> are you sure you need the  clcd bits in there ?
<jeinor> no, I'm not sure what they do. I copied them from the stock kernel command line
<jeinor> Tried to google that, didn't find anything so I figured I'd better leave them as is
<ogra_> well, i guess the device has two lcd ports on borad
<jeinor> LCD = HDMI/DVI/VGA?
<ogra_> no idea how marvell defined them :)
<jeinor> ok :) I'll try removing them
<ogra_> one could be attached to the hdmi port and one to an internal socket that gets used in other devices for touchscreens etc
<jeinor> makes sense, there is one HDMI port on the Cubox, no VGA/DVI
<ogra_> btw, are you using the armel or armhf tarball ?
<jeinor> currently the armel
<scientes> eek,
<ogra_> k
<scientes> not using to your full potential!
<ogra_> that should be on the safe side then
<jeinor> not using at any potential right now... :)
<scientes> jeinor, you know you can always use multiarch to install armel packages if you have problems right?
<ogra_> right, but it will make sure he wont be hit by any floating point issues for now
<ogra_> getting a first boot up is the current focus ;)
<scientes> ogra_, kernel could still be compiled with VFP support, but that kernel floating point but a few revs back only affected x86-32
<scientes> *bug
<ogra_> the kernel doesnt care
<scientes> ogra_, it actually has a VFP option
<jeinor> scientes: didn't know that. Will try the armhf as soon as I got an armel up and running
<scientes> (wouldn't make much of a speed diff as there is *very* little fp in the kernel)
<jeinor> how do I scroll in screen? the --verbose option gives lots of output
<scientes> jeinor, pipe it to less?
<scientes>  | less
<ogra_> man screen (in a second terminal you put next to it)
<ogra_> scientes, wont help much with dmesg from a serial port :)
<scientes> ogra_, well if you have that you can just turn on infinite back scrolling in your terminal emulator
<jeinor> uhm... feeling a bit stupid here... what does "C-a" mean? what key is that?
<ogra_> C means control
<ogra_> a means a :)
<scientes> ^
<jeinor> :) thanks. entered copy mode, and now I can scroll in the buffer
<jeinor> init is doing a whole lot of work here
<jeinor> but there are no error messages, just a lot of "Handling start event"
<jeinor> I must have done something wrong when configuring that serial console. everything looks fine
<ogra_> anything on the monitor btw ?
<ogra_> 8since you dropped the lcd args)
<jeinor> testing now
<jeinor> no, still nothing there. And still no login terminal.
<jeinor> hmm
<jeinor> perhaps that serial-console script on the web page parses my first console= line, thus missing the correct options for the ttyS0
<jeinor> I have two, console=tty0 console=ttyS0,etc
<ogra_> the first console line defines the console the kernel dumps dmesg to ...
<ogra_> the second one defines whats used for userspace
<ogra_> oh
<jeinor> the first one is console=tty0, so it should dump dmesg to the screen then
<ogra_> your second one say console=ttyS0 ?
<jeinor> console=ttyS0,115200n8
 * ogra_ wonders if the armada actually defines the serial console as S0
<ogra_> try dopping *all* console args for a test
<jeinor> hm
<jeinor> ok
<ogra_> and see what happens :)
<ogra_> though looking at the cubox wiki they all seem to use a single console arg defined as console=ttyS0,115200n8
<jeinor> yeah, that's where I got it from
<jeinor> but you're right, perhaps I should drop the first console at least (trying without all now)
<jeinor> ok, so removing all made screen stop receiving output after "Uncompressing Linux... done, booting the kernel."
<jeinor> I'll try just the first one, console=ttyS0,115200n8 now
<ogra_> right, but did you see anything on the monitor ?
<jeinor> no, I checked that too. tried to switch tty as well (ctrl+alt+fX)
<ogra_> (and make sure to wait for a while, it might take a bit to get to the login prompt, giv it time)
<jeinor> ... that I didn't do. will redo that attempt after trying the single console=
<ogra_> its an 800MHz system booting off slow media after all
<jeinor> true
<ogra_> "After a while (it takes a bit) a framebuffer console will appear, hiding the boot messages. Don't be scared, and wait for a few minutes. The login prompt will finally appear. "
<ogra_> from the wiki :)
<XorA> this is why us old school guys like out console messages, gives us hope :-D
<ogra_> yeah
<jeinor> :)
<jeinor> well, I think the framebuffer console won't appear here, this is not the stock kernel. The 2.6 kernel had graphic drivers and used a second command line arg, video= with resolution and stuff
<ogra_> what kernel is it then ?
<jeinor> 3.3.1
<ogra_> and are you 100% sure that kernel is supposed to work at all
<ogra_> (with ubuntu)
<jeinor> compiled by me, config from forum post where they said it booted fine
<ogra_> on ubuntu ?
<jeinor> they had Debian
<jeinor> perhaps it just wont work?
<ogra_> well, the debian kernel should tehoretically work
<jeinor> http://www.solid-run.com/phpbb/viewtopic.php?f=9&t=493
<jeinor> this is the link where this user (which doesn't respond back) says he got it working with stock 3.3.1 kernel
<jeinor> and Debian 6
<jeinor> so I figured Ubuntu Core would work with that kernel as well
<jeinor> first tried booting Ubuntu Core with kernel 2.6, but got looping error messages from dmesg complaining about missing functionality
<jeinor> the kernel I used is downloaded from www.kernel.org
<lilstevie> ogra_: all three work top, premount and bottom
<ogra_> lilstevie, well, then blame usersapce or some kernel option the userspace needs
<lilstevie> heh
<lilstevie> but I'm still in no better position to debug :/
<jeinor> but if the serial-console would have been working, I should have been given a login prompt in my screen session to /dev/ttyUSB0, correct?
<ogra_> "Also note that currently, the "make modules" fails, there is some sort of compile error for the framebuffer modules. I just ignored them at initial testing...."
<ogra_> so why would you expect anything on your monitor at all ?
<jeinor> ogra_: yeah, I've read that. I figured that was the framebuffer module (with support for higher resolution and such), and that it would fallback to just displaying the console using some basic graphics drivers
<jeinor> but perhaps you're right, perhaps it just doesn't work at all
<jeinor> but I still should get a login console on the serial-console
<ogra_> true
<ogra_> can you pastebin your full output from the screen session ?
<ogra_> (from one boot attempt indeed)
<jeinor> hmm, trying to get the whole screen buffer
<jeinor> hardcopy gives me the current window
<jeinor> I'm on it
<jeinor> where do screen logs go with the -L option?
<ogra_> C-a H       (log)         Begins/ends logging of the current window to the file "screenlog.n".
<jeinor> http://pastebin.com/NqfgpiCT
<jeinor> ogra_: I have to leave for a few hours, will be back here later. I am really grateful for your help, I've been stuck on this problem for some days now and it's frustrating when I don't know even where to start looking
<ogra_> yep
<ogra_> i might not be around though (i usually dont work on weekends :) )
<ogra_> i wonder what /etc/init,conf is supposed to be
<jeinor> the /etc/init.conf in the rootfs?
<jeinor> they don't mention that one in the OMAP guide
<ogra_> well, it usually doesnt exist on ubuntu systems
<ogra_> but seems ot be read on yours
<jeinor> hmm.. something specific to ubuntu core perhaps?
<jeinor> maybe upstart doesn't properly start my serial-console script because of some errors with /etc/init or /etc/init.conf
<ogra_> as i said, /etc/init.conf shouldnt exist
<ogra_> and it seems the boot stops at upstart-udev-bridge
<ogra_> probably soemthing you should take to our upstart maintainer on monday
<ogra_> (he is jodh in #ubuntu-devel)
<jeinor> actually, when I mount the root partion on another computer and look in /etc/ the file isn't there (init.conf)
<ogra_> yes, as its supposed to be, not sure why there is that message in your dmesg
<jeinor> true, maybe to notify me that if the file had been there, it should have been read
<jeinor> I do have the --verbose option on
<ogra_> yeah, likely
<ogra_> in any case it doesnt seem to even get to fire up a getty process
<ogra_> either a kernel misconfiguration or some issue with upstart
<jeinor> ok
<jeinor> then I have a pointer on where to continue next
<jeinor> thanks a lot for all your help!
<ogra_> np :)
<jeinor> I'll report back here on how it goes :)
<jeinor> really appreciate your help, worth a lot for me. take care!
<lilstevie> ok ogra_ I can trace it to something in bottom
<lilstevie> I get a panic some boots with break=bottom
<danboid> Are there no mirrors of Ubuntu ports?
<jeinor> ogra_, you here?
<jeinor> ogra_: I got it working!!! the reason I didn't get a console was that I had accidentally placed the serial-auto-detect-console.conf in /etc/, not in /etc/init
<jeinor> !!!
<jeinor> thanks again for all your help! now that I have a root console, I'm in my safe place again :)
<jeinor> ogra_: in case anyone else comes in asking questions about kernel 3.3.1 and ubuntu core :) http://www.solid-run.com/phpbb/viewtopic.php?f=4&t=544
<infinity> jeinor: Not that it matters for kernels that are ABI-agnostic, but if you're going to recommend people install an ARM cross-compiler, recommend they install gnueabihf, please.
<infinity> We really want to encourage people to switch to armhf completely.
<infinity> jeinor: Err, and same for core itself, you tell people to use armel, again, they'll be much happier with armhf.
<jeinor> Il
<jeinor> wops, I'll change that
<jeinor> infinity, what is ABI-agnostic?
<jeinor> to run a ubuntu core armhf, will I need to recompile kernel using the gnueabihf cross compiler?
<jeinor> more importantly, will it make any performance difference?
<infinity> jeinor: No, the kernel doesn't care what ABI your userspace is at all.
<infinity> jeinor: Using either compiler will get you an identical kernel.
<infinity> jeinor: I'd just prefer we encourage people to use hf in all cases.
<jeinor> I'll test that for my install and if everything works as before I'll change it in the post
<jeinor> thanks for pointing it out
<jeinor> hmm, what happens to all the armel-packages out there? in apt repositories for example? can I run armel compiled binaries on armhf systems?
<infinity> With multiarch, you might be able to.
<infinity> But generally, you should compile things for armhf.
<infinity> They're ABI-incompatible.
<infinity> The question is basically the same as "can I run i386 binaries on amd64", to which the answer is "sometimes".
<jeinor> I see. What about the packages in apt repositories? Are most armhf or armel nowadays?
<jeinor> openjdk, for example?
<mythos> i think, there are two ports. one for armel and one for armhf
<mythos> and as far as i know, the armhf port was completely rebuild (some weeks ago?). openjdk is also in the armhf-universe-repo of precise
<jeinor> ok, thanks
<jeinor> when you're saying "the armhf port was completely rebuilt", do you mean all packages in the official ubuntu repo were rebuilt for precise?
<mythos> for armhf in generell, i think
<jeinor> sounds promising, I'll see what packages are there when I begin to setup my system
<mythos> it's quite eays to geht the package-information: download http://ports.ubuntu.com/dists/precise/universe/binary-armhf/Packages.gz for main/restricted/universe/multiverse and grep for the "Package: "
<mythos> * row
<jeinor> nice, thanks for the tip
<mythos> np, you are welcome
<mythos> jesus, my grammar is bad today
<infinity> jeinor: There are two different prices ports.  armhf and armel.  armhf is the one we're supporting.
<scientes> jeinor, http://packages.ubuntu.com
<mythos> scientes, there is only i386, amd64 and powerpc selectable
<scientes> oh yeah ubuntu has an ugly split unlike debian
<scientes> there is another site, but i forget where it is
#ubuntu-arm 2012-04-22
<scientes> [890160.173487] VFS: Busy inodes after unmount of mtd_inodefs. Self-destruct in 5 seconds.  Have a nice day...
<scientes> a little bit of spaceballs eh?
<scientes> in my kernel you say?
<sveinse> I'm experiencing with precise debootstrap on precise. However it fails very often with "Couldn't download package..." and it happens for different packages for each invocation of debootstrap. Other with similar experience?
<sveinse> *experimenting
<sveinse> Where can I find the default compiler settings for armel and armhf?
<NekoXP> sveinse, gcc -dumpmachine
<sveinse> NekoXP: Oh? It returns arm-linux-gnueabi only.
<NekoXP> good :)
<NekoXP> sveinse, gcc -dumpspecs
<NekoXP> that's every default
<sveinse> NekoXP: How do I read it?
<sveinse> I find the specs hard to read. Then perhaps  touch foobar.c ; gcc -c -v foorbar.c  is easier to understand...
<sveinse> Let me ask it another way: We cross compile against natty with options "-march=armv7-a -mtune=cortex-a8 -ftree-vectorize -mfloat-abi=softfp -ffast-math -mfpu=neon  -fno-omit-frame-pointer"
<sveinse> 1) Should this line be changed when using precise?
<sveinse> 2) What should the options look like when cross compiling for armhf
<xranby_ac100> sveinse: when cros compiling for armhf you need to use -mfloat-abi=hard    and  make sure you link against a hard compiled userspace like libgcc
<LetoThe2nd> oO( "hard compiled userspace" sounds sweet )
<sveinse> xranby_ac100: Does the gcc-arm-linux-gnueabi packages include hf libgcc etc?
<xranby_ac100> sveinse: gcc-arm-linux-gnueabihf  for armhf
<sveinse> xranby_ac100: How could I miss that.. Thanks
<xranby_ac100> sveinse: if you use the ubuntu cross compile toolchains then you do not need to pass any extra tune options, they are set by default  like thumb and armv7 optimizations
<xranby_ac100> sveinse: to clarify if you run gcc -E -v
<xranby_ac100> then gcc will print all default compiled in options
<sveinse> One option ubuntu gcc does not specify is the -mtune= (iirc). Does it have much effect specifying it compared to not?
<xranby_ac100> well they usually pass --with-arch=armv7-a
<sveinse> I've always wondered if it really meant something to have the tune as well as arch.
<xranby_ac100> i cant say off hand without benchmarking if you gain anything by explicitly tune for cortex-a8
<sveinse> Anyways, do you happen to know if ld in 4.6 is compiled with sysroot support this time?
<sveinse> (If you don't, I'll figure it out)
<xranby_ac100> if your code are to be run on neon systems then that do make a little difference
<xranby_ac100> since ubuntu do not enable neon by default to stay compatible with tegra2 cortex-a9 cpus
<Cyberworm> hi
<Cyberworm> I have a problem booting Ubuntu 11.04 on the Pandaboard
<Cyberworm> it freezes at "Enabling oem-config"
<Cyberworm> 11.10 works
<Cyberworm> but I actually need 11.04
<Cyberworm> sooo
<Cyberworm> is this a known bug?
<xranby_ac100> Cyberworm: i think its a known bug. you can remove the /var/lib/oem-config/run file to let the board boot up
<xranby_ac100> using 11.04
<Cyberworm> isn't that neccessary for something?
<xranby_ac100> the oem-config are the setup wizard
<Cyberworm> ah
<Cyberworm> thank you
<xranby_ac100> youre welcome
<Cyberworm> huh
<Cyberworm> now it doesn't freeze
<Cyberworm> I guess it depends on how you format the sd card
<Cyberworm> on the first try I used to gparted to delete the partitions and then I used the command to transfer the image to the card
<Cyberworm> now I didn't format at all and just transfered the image
<xranby_ac100> Cyberworm: so.. everything are working now? great,
<Cyberworm> well let's see if the setup works
<xranby_ac100> what feature do  11.04 offer that is not found in 11.10 and later?
<xranby_ac100> i am curious why you need to use 11.04
<Cyberworm> xranby_ac100: there are problems with the player/server robot device server on 11.10
<xranby_ac100> Cyberworm: have you checked if this are fixed in 12.04 that gets released next week? (you can get install images today to test)
<Cyberworm> I don't know
<Cyberworm> but we need it for a project so it's better for us to use something where we know it will work
<xranby_ac100> thats fine, in which language are the robot programmed in?
<Cyberworm> dunno, we just need player/server for simulation
<xranby_ac100> Cyberworm: ok, good luck with the project.. if you get time left over after its finished.. please come back and i we can check out what the player/server depend on
<Cyberworm> I'll consider it, thanks
<sveinse> What is the state of armhf compared to armel (and precise)? I.e. can I consider migrating my embedded system from natty armel to precise armhf?
<jhobbs> A/wg 8
<jeinor> sveinse: as it was explained to me, Ubuntu will officially only support armhf from 12.04. All packages in apt repositories should already exist compiled for armhf.
<jeinor> sveinse: the difference is about the same as the difference between i386 and amd64 in terms of "will my program run or not"
<jeinor> sveinse: it might run using multiarch
<jeinor> sveinse: someone else can probably explain it better and more correct
<sveinse> jeinor: Perhaps my question was a bit, uhm, blunt. We're have been running natty armel on an embedded product for 1.5 years now and its working great. For the next version we're definitely going to upgrade to precise. The question was if we should consider hf (as this would give our apps a huge set of improvements)
<sveinse> Support is not the biggest issue
<jeinor> sveinse: I see. Well, in that case I think there are people better suited to answer your question than me.
<jeinor> :)
<sveinse> thanks, anyways
<mythos> i think, the question is already answered
<mythos> armhf is the supported port for precise. so if your hardware is compatible and your software compiles and is able to pass your testframework (*laughs a little*), go ahead and use precise/armhf
<sveinse> test framework, what is that? :P
<mythos> that's why i laughed =P
<Cyberworm> updating packages takes really long...
<sveinse> So if I should make up my own conclusion it would be: armel and armhf will be supported the same way. There is a larger set of FTBFS in armhf. -- yeah, I think we can do a testrun at least
<sveinse> dist-upgrading armel to armhf on a running system is NOT going to be easy, right
<mythos> easy? i think, thats impossible
<sveinse> Not completely I think
<mythos> nothing ist completely impossible
<sveinse> What makes it hard is because of glibc and libgcc?
<sveinse> E.g. you can't have both armel and armhf on the same system, right?
<mythos> because armel and armhf is not abi-compatible, so it can break _everywhere_
<mythos> not worth the time to try it
<mythos> with multi-arch, you can
<sveinse> abi incompatible across kernel - userspace as well?
<mythos> the kernel does not care, if it is compiled for armel or armhf
<mythos> and it does not care, what the userspace uses (to be clear)
<sveinse> Yes, so the armel libs and the armhf libs could co-exists
<sveinse> except they clash on file-basis, right
<mythos> with multi-arch, not with editing the sources.list form armel and armhf and do a dist-upgrade
<sveinse> What is multiarch specifically btw
<mythos> the new hot stuff
<sveinse> :D
<mythos> sorry, i'm not sophisticated enough with the basis of multiarch
<Cyberworm> it takes reaaaally long for updates
<Cyberworm> is that a normal thing?
<mythos> sorry, Cyberworm. what are you doing?
<Cyberworm> updating
<mythos> from what to what?
<Cyberworm> just the ubuntu 11.04 packages
<mythos> so a "apt-get update"
<Cyberworm> yes
<mythos> i would say, that it is not the normal behaviour (except your hardware (cpu, persistent memory), internet connection, or anything else is very slow)
<Cyberworm> it's on the pandaboard
#ubuntu-arm 2013-04-15
<Snark> infinity: about https://launchpad.net/ubuntu/+source/gmp/2%3A5.0.5%2Bdfsg-2ubuntu3
<Snark> who is the patch author (they're not documented as per DEP-3)
<Snark> ?
<Snark> where those patches forwarded to gmp upstream?
<Snark> and to mpir upstream, since they're a fork and they help there too?
<hrw> infinity: can you grab vboot-utils from NEW queue? one step closer for chromebook support ;D
<infinity> Snark: The patch author was me, if I uploaded it.  And no, I didn't forward it upstream at the time, because it was a known binutils bug that I figured would get fixed.
<Snark> infinity: did it get fixed? Will the patch break compilation with earlier binutils?
<Snark> do you have a link to the binutils bug?
<infinity> Snark: Not sure, no, and not at home right now to look.
<Snark> ok ; when can I ping you again to know?
<infinity> Tuesday, or try talking to SteveMcIntyre, I vaguely recall that he was looking into (or having someone look into) the binutils bug.
<infinity> Anyhow, the patch is harmless when used with old binutils, so if you want to submit it to upstream(s), go ahead.
<Snark> infinity: ok
<hrw> ok, chromebook users will have to wait for 13.10
<ogra_> hrw, why ?
<ogra_> vboot-utils just went in
<hrw> o. I got rejection email so though badly
<ogra_> i see it on -changes
<hrw> ok, so one thing less to worry
<ogra_> :)
<infinity> hrw: I synced it instead of taking your fake sync.
<infinity> hrw: Should have mentioned that.
<marvin24> janimo: I'm looking for a sponsor: https://launchpad.net/~marvin24/+archive/ppa
<hrw> infinity: I should check debian new first
<janimo> marvin24, ack, I do not have time ATM though and my ac100's wifi broke months ago
<janimo> but I hope I'll get some time this week and I may be able to test then
<ogra_> note that thursday is final freeze
<janimo> ogra_, yes I know we are close to release. Just that I have no time for distro stuff lately and my ac100 is gathering dust :)
<ogra_> same here
<marvin24> next kernel will be multiarch
<diwic> mine too! shall we setup a computing cluster of dust-collecting ac100s?
<marvin24> so I hope no need anymore for ac100 specific kernels
<marvin24> it's not the fault of the ac100 that it collects dust
<janimo> marvin24, indeed, in my case the availability of more powerful and convenient linux arm machines
<janimo> that plus ac100' hw failure
<marvin24> my wifi and 3g modem also died in one of my machines
<marvin24> seems to be a hw bug or so
<marvin24> will ubuntu powered  ARM servers also use the android kernel?
 * marvin24 hopes not
<janimo> marvin24, no
<janimo> mobile uses android kernels as those are the only ones that support the hw
 * ogra_ sees janimo's mail and wonders why the maguro image should work on an ac100 
<janimo> ogra_, he said he tested maguro
<marvin24> maguro?
<ogra_> oh, i see
<janimo> marvin24, on the phone mailing list unrelated
<ogra_> he went offtopic in his ownb thread :P
<janimo> well, the topic is black screen and errors in logcat
<janimo> which quite a few devices seem to share
<janimo> incuding one I have been looking at
<ogra_> ah
<ogra_> well, he started with his ac100 issue ... i didnt even know he does more than ac100 and HP touchpad
<janimo> no idea why though, maybe phablet and android 4.0 binaries not being compatible
<ogra_> well, CM 10.1 is 4.2.2
<ogra_> or 4.2 at least
<janimo> I think it's only the last mail he said he also tested gnex to rule out other issues
<janimo> 4.2.1 indeed
<ogra_> yep ... just looked through the thread again
<janimo> not sure what gothas there are with 4.0 binaries
<ogra_> different toolchain/bionic ?
<ogra_> though i know the maguro images are regulary tested in house ... so that should definitely work
<janimo> the vendor bits need to be added manually since they are not in the tree, that can be a common reason for buildable but nonworking images
<janimo> but let's see what he answers
<janimo> I also cannot get nexus4 to boot now but I could previously, need to track down why, (also forgot vendor blobs at one point)
<ogra_> well, does it work with the cdimage image ?
<janimo> testing now :)
<ogra_> :)
<ogra_> these images are definitely regulary tested
<janimo> it worked with a build I had done last week, now I did a fresh build on a different machine and this one does not work
<ogra_> so at least the friday build should be good
<janimo> right, I know they are supposed to wor
<ogra_> (i doubt anyone actively tests on weekends)
#ubuntu-arm 2013-04-16
<rnix> hi, i'm experimenting with ubuntu 13.04 on a nexus7 and was wondering what's used in order to check battery state. acpi is not installed. any hints?
<IamTrying> While using OLife my Eee Pad transformer was crashed.
<IamTrying> I have found the ROM from ASUS http://www.asus.com/Tablets_Mobile/Eee_Pad_Transformer_TF101/#support_Download_32
<IamTrying> But how can i transfer it to my Eee Pad using OLife?
<IamTrying> Where do i put those files? http://www.asus.com/Tablets_Mobile/Eee_Pad_Transformer_TF101/#support_Download_32
<IamTrying> i have downloaded the http://lilstevie.geek.nz/downloads/OLiFE-Prime-Edition.tar.gz_1.2a_TF101_767779ccfa200e5e00b2f1e33a3d73a9
<rnix> dbus on org.freedesktop.UPower does the trick...
<ogra_> right, we're using upower which attaches to the platform battery device
<rnix> another question, any idea to fix screen orientation to landscape? first time i tried 12.10 on n7, orientation was landscape, this changed with 13.04 to portrait
<ogra_> it should actualy autorotate
<darkfader> shake it ;)
<ogra_> sudo service acceld stop
<IamTrying> Why the Asus Eee pad after installing OLife always in Black screen?
<ogra_> use that to stop auto rotation
<ogra_> then use xrandr to rotate
<rnix> ogra_: thx
<IamTrying> ogra_, where?
<ogra_> IamTrying, ?
<ogra_> where what ?
<rnix> ok, xrandr works, now i need to transform xinput as well in order to correct touch input...
<IamTrying> ogra_, no its ok thanks, i thought you answered me
<ogra_> ah, sorry ... i didnt prefix the answer
<ogra_> hrw, the nexus has usb host ...
<ogra_> (just reading your blohg post)
<ogra_> (not sure if android offers it in userspace though, but the ubuntu desktop nexus7 image heavily relies on usb host (and we use the android kernel))
<hrw> ogra_: it has OTG
<ogra_> well, it runs in host mode if you attach an OTG cable
<ogra_> i'm using it with a HUB here
<ogra_> with a bunch of devices attached
<hrw> sure but it is still otg
<hrw> and I have had bad experiences with such
<ogra_> you want a big socket you mean ?=
<hrw> yep
<ogra_> ah
<hrw> with ehci signalling
<ogra_> i thought it was a complaint about function, not form :)
<hrw> both
<ogra_> it uses ehci
<ogra_> afaik
<hrw> updated post
<hrw> +And by USB Host port I mean normal EHCI host port. Not an OTG one present in Nexus 7.
<hrw> Archos has EHCI + OTG
<ogra_> ah
<ogra_> i never had an archos ... they never sent me one
 * ogra_ blames av500 :)
<hrw> I bought mine
<ogra_> crazy talk :)
<hrw> never again
<hrw> omap4430 suxx too much with 512MB ram
<ogra_> well, there were times when that was awesome :)
<ogra_> 4 years ago or so
<hrw> I had to skip those
<ogra_> note that ubuntu touch actually focuses on 512M now :)
<hrw> arm926 512MB -> arm1136 128MB -> 1136 256MB -> omap3 128MB -> omap3 256MB -> omap4430 1GB
<hrw> s/(arm)?1136/i.mx31
<ogra_> tell that to the manufacturers
<ogra_> the average non-highend phones still ship with 512M
<Neko> and 128MB of that is reserved for graphics :D
<hrw> ogra_: ICS was fine with 512MB
<ogra_> UTouch will be too :)
<hrw> ogra_: where are apps for utouch?
<ogra_> likely not shiny, but it will be ok
<ogra_> in the apps PPAs
<ogra_> michael hall blogs about them all the time
<ogra_> see planet :)
<hrw> so far did not saw anything breath taking
<ogra_> what woudl you expect ? there wasnt even a release of UTouch
<ogra_> and for not having a stable api yet i think over 40 apps is a good number already
<ogra_> (and for not having any sensors access)
<ogra_> hrw, *and* Ubuntu Touch is the *only* OS that has a Jono Head app !
<hrw> ;D
<hrw> ogra_: anyway I do not have device for ubuntu phone/tablet testing
<ogra_> really ?
<ogra_> we support over 50
<hrw> ogra_: neither my nexus 4 or 7 are free to be reflashed
<hrw> I know that they are supported but I use them
<ogra_> yeah, i dont run it on these either
<ogra_> my test device is my old galaxy S2
<XorA> heh the age old issue of needing actual working devices :-D
<ogra_> i think thats solved brilliantly for UTouch
<ogra_> thanks to the android core porting is super easy
<ogra_> https://wiki.ubuntu.com/Touch/Devices
<hrw> ogra_: I noticed that UbuntuTouchCore is other name for CyanogenMod ;D
<ogra_> hmm, i dont think so ...
<ogra_> core defines the plumbing layer on the ubuntu side afaik
<ogra_> (libhybris and Mir)
<hrw> Building the Android pieces
<hrw> You can find all the needed Android git repositories at http://phablet.ubuntu.com/gitweb. This is basically a mirror of CyanogenMod 10.1, but containing only the needed low level services used by Android (e.g. no Dalvik at all).
<hrw> porting guide
<ogra_> yeah
<ogra_> but i dont think thats what we calkl ubuntu touch core
<hrw> And: "To support a wide range of devices, we decided to use CyanogenMod as a base for the Android system. You could safely use AOSP, as we don't use a lot of the customizations and improvements done at the App/Java side, but it's easier with CyanogenMod due the scripts and build procedures available for it. "
<ogra_> would be silly to upset the CM devs by renaming their stuff :)
<hrw> ;)
<ogra_> will be intresting once we have the first preinstalled devices ...
<ogra_> i dont think it is decided yet if that will keep the android layer or not
<suihkulokki> It would certainly be better for the whole ecosystem if canonical put engineers into reverse engineering graphics drivers rather than working on wrapping propiertary android drivers
<ogra_> well, that would take a lot longer
<darkfader> which means they'd do cool stuff and go bankrupt ;)
<ogra_> :)
<suihkulokki> a cool but buggy solution
<suihkulokki> like ndiswrapper was quick to come but ended up cringing users with cornercase bugs
<ogra_> its a quick shot to get as many devices supported as possible so devs can work
<ogra_> with 13.10 you will see the first preinstalled devices ... or shortly after
<ogra_> and if canonical actually gains some market share there is the possibility to actually push for more opened drivers
<ogra_> (i'm pretty sure it wont be hard to surpass BB or Win8 sales for one for the free OSes like FFos or UTouch ... the question is how close either of them comes to anbdroid or iOS in sales to make some actual impact)
<darkfader> ogra_: preinstalled drivers, do you think there's a chance of gps and 3g drivers?
<darkfader> i know the touch / graphics are much harder on people who use their n7 as a tablet
<darkfader> but mine is wallmounted ;)
<ogra_> the preinstalled ubuntu touch device will definitely support all builtin sensors, yes
<wookey> yeah someone needs to employ luc to get on with the mali drivers
<wookey> s'funny how we used to suffer with hardware only coming with windows binary driver support. Now it's the same with android binary driver support, which is slightly better but still quite annoying.
<wookey> I'm sure this isn;t where we supposed to end up. something went wrong somewhere along the way
<prpplague> ogra_: https://plus.google.com/u/0/101339419642360856354/posts/MFc5mJKUAys
<ogra_> heh, just popped up in my stream
<ogra_> thanks :)
<ogra_> (got you in my circles)
<prpplague> ogra_: hehe
<prpplague> ogra_: ahh right
<ogra_> gma600 is PVR ?
<infinity> wookey: The Android binary driver situation isn't even remotely better.  It's just *lucky* that Android happens to be Linux, and we can fudge the situation to our advantage and toss a free userspace on top.
<infinity> wookey: But I don't see that as progress, or even "a little better".  We could have done the same thing with a free userspace on top of the NT kernel if we'd wanted to.
 * xnox ponders if Android used HURD kernel.....
#ubuntu-arm 2013-04-17
<jenenliu> hi guys, I wanna to learn arm, is there some place I can go from there, such as newbie tutorial
<jenenliu> thanks
<kulve> jenenliu: best way to learn is to figure out a goal, something real that you want to achieve. And then start doing it. It's not really efficient to just "learn arm".
<jenenliu> kulve: thanks
<rnix> hi
<rnix> this documentation https://wiki.ubuntu.com/Nexus7/UsingTheDevice states under Attaching a USB Device to the Nexus 7 -> There is no way to charge the device while it is connected to the OTG cable. why?
<kulve> with the OTG cable the device is the USB host, so it's giving power out through the USB cable. Where would it take power in for charging?
<hrw> rnix: grab cheap chinese powered hub, connect it to OTG and check what will happen
<[mbm]> https://bugs.launchpad.net/ubuntu-nexus7/+bug/1072320
<ubot2> Launchpad bug 1072320 in ubuntu-nexus7 "please consider adding OTG charging support to kernel" [High,In progress]
<rnix> so if i build something like this -> http://www.instructables.com/files/deriv/FDR/71ZI/GINP15VZ/FDR71ZIGINP15VZ.LARGE.jpg -> and connect to a usb hub it might work?
<[mbm]> but basically kulve is right; otg doesn't really provide a way to charge, the above is just a driver hack
<[mbm]> rnix: yes, a combination of that and a patched driver
<rnix> thx
<ogra_> and that driver hack makes the USB driver hardlock ... thats why we dropped it again (after testing it)
<[mbm]> I'd be a bit scared of accidentally having both the nexus and the external power active at the same time
<ogra_> heh
<rnix> ogra_: what do you mean with "makes the USB driver hardlock" ?
<ogra_> rnix, you can charge but not use any devices
<ogra_> which kind of defeats the purpose :)
<rnix> hmpf, true
<ogra_> and since that image most likely will die anyway in favour of ubuntu touch there is nobody actuvely looking into that bug
<[mbm]> not entirely surprising when hacking the usb controller into undefined modes
<ogra_> *actively
<[mbm]> they gave up on the full desktop experience?
<ogra_> no, but the desktop will be replaced by unity next and mir
<ogra_> which esssentially is ubuntu touch :)
<[mbm]> long as there's an x11 compatibility layer I suppose
<ogra_> there isnt atm
<rnix> ogra_: just to understand right -> what i want to do is connect a serial port (to write to, via /dev/ttyUSB[n]) while charging. and this is not supported and never will be?
<ogra_> there will be once the desktop gets replaced
<ogra_> rnix, right
<ogra_> i wouldnbt say "never" but it isnt any priority (not even low)
<[mbm]> rnix: officially, when your device is controlling a perhiperal (like your serial dongle) it's in usb host mode and is supplying +5v out of the usb port
<ogra_> ubuntu touch uses adb all over the place so even serial support is questionable
<[mbm]> rnix: to do charging you have to hack the usb driver not to switch on the 5v output and instead take 5v as a charge input
<rnix> ogra_: well, it already works if i connect my serial adapter to the otg cable
<rnix> but without charging
<ogra_> yes it works in this image ...
<ogra_> it wont/doesnt work in ubuntu touch
<ogra_> since the gadget is claimed by adb so you cant load the serial gadget driver in parallel
<rnix> ok, and ubuntu touch will replace the patced 13.04 image for n7 in future?
<[mbm]> (hacking the usb driver, as described above makes it prone to crashing)
<ogra_> rnix, most likely ... it isnt decided yet
<ogra_> we need *one* classic desktop image to test apps on until the desktop did get replaced
<ogra_> its not clear if that will just be the pandaboard image or probably the nexus7 one
<ogra_> but given that we dont want to maintain two n7 kernels and given that they need to differ between the two images its likely to go away if it turns out we cant use the same kernel on both images
<rnix> finally all i can do is either use a bluetooth or wireless bright to my bus or hack the hardware with an external power supply instead of battery. latter one makes the ose of a tablet obsolete...
<rnix> s/bright/bridge
<ogra_> you could use your own patched kernel (and fix the issue alongside)
<drasko> hi all. Login takes time as wifi interface is not up correctly. It is defined as dhcp, but I have an ipression that udhcpc is not started. How to verify this?
<drasko> hi all. Login takes time as wifi interface is not up correctly. It is defined as dhcp, but I have an ipression that udhcpc is not started. How to verify this?
<ogra_> !ask
<ubot2> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<ogra_> !patience
<ubot2> Don't feel ignored and repeat your question quickly; if nobody knows your answer, nobody will answer you. While you wait, try searching https://help.ubuntu.com/ or http://ubuntuforums.org/ or http://askubuntu.com/
<rnix> ..oO(  same in every tech channel ;)  )..
<darkfader> actually, look at the list of open bugs instead
<darkfader> same with every oss project ;)
<rnix> would it be possible to load via docking station while using micro usb to write?
 * ogra_ has never seen an n7 docking station ... 
<ogra_> i would assume not though ... it will likely claim the usb port for charging
<rnix> http://www.blogcdn.com/www.engadget.com/media/2013/01/nexus-7-dock.jpg
<rnix> well, that's what i fear as well - xor usage
<ogra_> it wont change the kernel or driver ... so it will likely do the same ...
#ubuntu-arm 2013-04-18
<xnox> ogra_: the panda issues were all fixed in X and we are expecting to release both desktop & server panda just fine next week, correct?
<ogra_> yeah
<xnox> ack.
<ogra_> unsupported ... but we'll release
<xnox> ogra_: as usual.... if somebody drop-ships golden bricks to your backyard, hell yeah it will be supported =)
<ogra_> we will not touch the kernel (not even rerbuild it) nor will we touch the xserver driver
<ogra_> even if there are bugs ... as long as they are not fatal
<ogra_> kernel and xorg driver are as is from quantal
<shadeslayer> hrw: hi, I'm trying to get the Nexus 10 with ubuntu as the main OS up, however my kernel+initrd combo seems kaput, ogra_ suggested I ask you for the chromebook kernel, since both the devices have the same board, I might be able to boot the chromebook kernel
<ogra_> note that the display stiff will most likely differ though
<shadeslayer> right
<ogra_> since the chromebook has a differnt display and no touchscreen
<shadeslayer> I can diff the .config maybe
<shadeslayer> ogra_: do you have the kernel config for the chromebook?
<ogra_> nope
<shadeslayer> mmmm
<ogra_> no /proc/config.gz here
<shadeslayer> heh
<ogra_> the package will surely have it
<shadeslayer> yeah, /proc/config.gz is disabled
<ogra_> but i think hrw already called it a day ...
<shadeslayer> :D
<hrw> shadeslayer: linux-chromebook package has /boot/config-* file
 * hrw off
<shadeslayer> thanks :)
#ubuntu-arm 2013-04-19
<gandhijee_> hey... does anyone here know what the movtls instruction for ARM does?
#ubuntu-arm 2013-04-20
<Meizirkki> hi
<Meizirkki> What prevents one from using android kernel directly with ubuntu?
<Meizirkki> on a tablet, for example
<ogra_> nothing .... but you need to change the configuration
<ogra_> and it shouldnt be to old for some options the userspcae needs
<ogra_> (udev or upstart require some settings that are only there from certain versions on)
<Meizirkki> so as long as the kernel source is available one could in theory boot ubuntu on any tablet?
<ogra_> well ... theoretically
<ogra_> android kernels usually have no support for consoles enabled ... if you are lucky the vendor included a driver but disabled it ... often there is no code at all for this ...
<Meizirkki> hmm
<ogra_> the issue with android kernels is that they usually are heavily hacked to get driver support in ... but in a way that possibly breaks building the kernel with other configs
<ogra_> so its really depending on how good the vendor implementation is or if its just a bad hack on top of a mainline kernel or so
<Meizirkki> okay
<ogra_> and then there are indeed no xorg drivers for most of the tablets out there since android doesnt use X
<Meizirkki> Yup I see.
<Meizirkki> Will wayland work?
<ogra_> dunno, mir will :)
<Meizirkki> (isn't it what ubuntu touch is looking forward to using)
 * Meizirkki googles mir
<ogra_> no, ubuntu touch will use Mir
<ogra_> https://wiki.ubuntu.com/Mir/Spec
<ogra_> its similar to wayland ... but different :)
 * Meizirkki gets a bunch of submarines and space ships googling mir
<ogra_> (there is an #ubuntu-mir channel)
<Meizirkki> Thanks ogra_ :)
<darkfader> Meizirkki: thanks for bringing ubuntu-on-android up, might help me solve my gps issue (if i dare try, that is)
<Meizirkki> :)
<aks_> hello all, i am working on beagleboard, i have installed ubuntu 11.04 image which was provided by vendor, now problem is i want to compile kerenl module for that but i m not able to get kerenl files in /lib/modules
<aks_> even i not able to find source of that kernel
<aks_> kernel version is 2.6.32
<aks__> hello all,
<aks__> i am working on beagleboard
<aks__> i have installed ubuntu 11.04 image
<aks__> on it which done not have kernel source
<aks__> kernel version is 2.6.32
<aks__> i want to compile kernel module
<aks__> but i dont find kernel source image in installed image
<aks__> so how can i do that
 * Snark wonders if emacs runs on ubuntu-touch
<pinportal_> hello, can I install Lubuntu in a CPU WM8650?
<pinportal_> WM8650 = 600Mhz ARM926EJ-S processor
<ogra_> nope, ubuntu (or lubuntu in that case) only supports ARMv7 and newer ... yours is a v5
<ogra_> (see channel topic)
<phillw> ogra_: thanks, I only know to send ARM questions here :) pinportal_ I have had a dig around, and it seems that debian sid should work, this is the link http://wm8650.net/index.php?newsid=444
<darkfader> i think i ripped one of those out of a nas box, they had a "netbsd.bin" in their fw package
<darkfader> but i never got up my spirit to hack at it
<pinportal_> so I can install on WM8650 tablet?
<k1l> pinportal_: no. no ubuntu
<pinportal_> it is bad :(
#ubuntu-arm 2013-04-21
<CQ> hello, I saw that ubuntu runs on the https://wiki.ubuntu.com/Nexus7/Installation ... will it run on the nexus10 as well=
<CQ> ?
<k1l> are you talking about ubuntu-touch or ubuntu desktop?
<CQ> k11 anything that makes a 10" tablet usable and isn't android ...
<k1l> did you look on xda if there is a ubuntu desktop port alreaady?
<k1l> since the nexus 10 got different hardware then the nexus7 its not that easy to put it on the n10
<CQ> ah, ok... I thought it was similar hardware and just a higher screen siye
<CQ> size
<kulve> "nexus" is a device supported by google. It doesn't say anything about the hardware.
<kulve> (unfortunately)
#ubuntu-arm 2014-04-15
<Aussie_matt> hi all, does anyone know if the later ubuntu versions support the allwinner a10 chip from the iso with out any mods?
<hrw> iirc no
<Aussie_matt> hrw: was that at me?
<ogra_> the iso :)
<Aussie_matt> ogra_: ?
<ogra_> doe your a10 device have a CDrom ?
<Aussie_matt> no, boots of sd card
<ogra_> why would you expect an iso then ?
<ogra_> (there are only either img files you can dd to the SD card or tarballs with rootfs)
<ogra_> but there are no images for a10 devices
<Aussie_matt> ah: so a ISO can't be put on an sd and function?
<ogra_> it can
<ogra_> you could indeed loop mount it
<Aussie_matt> but it wouldnt work?
<ogra_> there are no installer images for most arm machines ... you will have to assemble something yourself
<Aussie_matt> mmmmm sounds like a headache lol
<ogra_> well, its arm ...
<ogra_> you usually manage your bootloader and kernel yourself and use a rootfs from your preferred distro with it
<Aussie_matt> yeah im learning that the hard way lol
<ogra_> ubuntu supports a handfull of boards with the netinst installer but no a10 ones
<Aussie_matt> ah interesting
<lpalomares> hi all!.. looking at google to find out the status of this, cant find any new, only old pages will someone direct mi to a good link to read about status of ubuntu-arm ? I do have a nexus 7 to test
<lpalomares> thanks
#ubuntu-arm 2014-04-16
<angs> I have an armel processor and I will use qemu emulator on x64 ubuntu 13.10. do I need to add dpkg --add-architecture armhf for armel?
<angs> if I run dpkg --add-architecture armel, it outputs "W: Failed to fetch http://se.archive.ubuntu.com/ubuntu/dists/saucy-updates/Release  Unable to find expected entry 'main/binary-armel/Packages' in Release file (Wrong sources.list entry or malformed file)" when I run apt-get update
<ogra_> there is no support for aarmel in ubuntu anymore
<ogra_> *armel
<angs> is armhf better than armel? why ubuntu does not support it anymore
<ogra_> its not "better" they support different things ... and are optimized for different hardware
<angs> I see thank you
<angs> my purpose is to run qemu emulator to run debian 7.4(armel) on ubuntu 13.10(x86). can I do it on ubuntu?
<ogra_> armel supports older hardware but is not optimized for the latest ...
<ogra_> ubuntu armhf only runs on ARMv7 hardware and newer
<ogra_> sure
<ogra_> you just needs to install the right qemu
<angs> I installed qemu-user-static
<ogra_> and then follow whatever debian emulator howto you have
<ogra_> qemu-user.static is for chroots
<ogra_> not for a full VM
<ogra_> you want qemu-user-system or qemu-system
<angs> ah ok, thanks I will look into that one
<ogra_> and use the armel binary from that for your setup
<angs> ogra_ I have kernel and root files (armel) on a microSD card. can I run the linux on any GUI based VM  on my laptop (x64) that does the same thing what qemu-system does?
<ogra_> yes, qemu starts a complete virtual machine, but it is limited in what HW it supports ... whatever howto you use for brining up your debian VM should tell you though
<angs> thank you
<arg_> Hi , I am using Ubuntu 14.04 beta-2 arm root file system and facing an error . I see an empty desktop with just a mouse pointer .If I stop lightdm and manually run X , I see the X window. I am using the default modesetting driver and not sure if its driver issue. Can anyone please help me with this issue with lightdm/driver issue ?
<arg_> Hi , I am using Ubuntu 14.04 beta-2 arm root file system and facing an error . I see an empty desktop with just a mouse pointer .If I stop lightdm and manually run X , I see the X window. I  am using the default modesetting driver and not sure if its driver issue. Can anyone please help me with this issue with lightdm/driver issue ?
#ubuntu-arm 2014-04-17
<klaasvakie> Hi - I am running nm on two devices with identical USB wifi cards (ath9k_htc), one is x86 and the other is arm. Both are running headless nm 0.9.6 on Ubuntu 12.04. On the x86 wifi roaming works perfectly < 1.0s, and on the arm roaming does not work at all. Is there anything I need to check?
<klaasvakie> nm = NetworkManager
<arpd> Hi guys, what is that state of support for ARM chromebooks (particularly the samsung exynos ones, like the hp 11) with the recent 14.04 release?
<arpd> *the state of support
<arpd> The ubuntu wiki page on ARM is pretty out dated
<infinity> arpd: The state of support is there isn't any kernel support, as always, unless you have your own.
<arpd> infinity: Unless I have my own? i.e. unless I use the one distributed with chromeos?
<infinity> arpd: Right.  In other words, we don't support it at all, but our userspace will run fine on a chromebook if you provide a kernel and drivers and figure out how to install it.
<arpd> infinity: Would you have any advice for where I should start looking try and get the chromeos kernel and drivers, and ubuntu working together?
<infinity> arpd: No idea, sorry.  I don't have a Chromebook.  I'm sure there are HOWTOs and blog posts out there.
<arpd> infinity: Right, thanks for the help.
#ubuntu-arm 2014-04-18
<Aussie_matt> hi all: is 14.04 for arm available?
<teiler> my headphone jack does't say beep :(
<ansel> hhi
<ansel> hi
<ansel> need hlp
#ubuntu-arm 2014-04-19
<[7hunderbird]> hello, anyone know if the new 14.04 would install on the raspberri-pi at all?
<[7hunderbird]> or is it intented only for SoC (System on a Chip) machines?
<Tassadar> pi is armv6, and ubuntu doesn't support that architecture for some time now
<Tassadar> (and pi _is_ SoC)
<[7hunderbird]> rgr that
#ubuntu-arm 2015-04-13
<ars23> one question: what can be the cause of message: [   18.254389] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
<genii> ars23: Sounds like the driver tries to enable WOL but the hardware doesn't support it.
<ars23> yes, seems so... I also read that can be a power issue ( not enough amps) but it's strange that this problem appeared only 2 days ago and because of it i cannot configure internet on a rasperry that I use as a development board
#ubuntu-arm 2015-04-14
<nitroshift> hello people
<nitroshift> NCommand`, hello
<nitroshift> sorry, NCommander :)
<nitroshift> are you around?
<nitroshift> anyone here can answer a question regarding ubuntu on armada xp?
<nitroshift> hello people
<nitroshift> NCommander, hello, are you around?\
<ars23> hi nitroshif!
<nitroshift> hello ars23
<nitroshift> i've got a question regarding ubuntu on marvell arm
<ars23> ask, and if I know, I'll try to help... I also have some problem, but with debian and pppoeconf on a pi...
<nitroshift> more specifically on a patch
<ars23> so, let's try.
<nitroshift> marvell released a patch to enable network fast processing but that was for kernel 3.2
<nitroshift> how feasible is it to portr it for current kernel versions?
<nitroshift> meaning 3.18 - 4.0
<nitroshift> the tricky part is integrating the hooks in netfilter code
<ars23> yes, and also the dependencies...
<nitroshift> those too
<nitroshift> but the dependencies are easier to port
<nitroshift> i really wanted to talk to NCommander as he was the one that brought the patch into ubuntu code (though it was for kernel 3.2.0)
<ars23> yes, I think is better to wait for him... and talk with him...
<nitroshift> thought so... but it's late here, going to bed
<nitroshift> talk tomorrow
<nitroshift> see ya guys
<nitroshift> see ya ars23 and thanks :)
<ars23> you're welcome! bye!
 * NCommander is
<NCommander> But I missed nitroshift
<danielbrazilian> hello is odroid c1 officially supported by ubuntu?
#ubuntu-arm 2015-04-15
<nitroshift> hello people
<nitroshift> NCommander, ping
<nitroshift> NCommander, ping
<nitroshift> anyone can help me with a patch for armada xp?
<NCommander> Blast it, keep missing nitroshift
<k1l> and we will never know what the issue is
#ubuntu-arm 2015-04-17
<noob_rpi>  Hi, I am trying to cross compile a kernel for raspberry pi 2. The deb-pkg build generates an armel.deb instead of armhf.deb. How do I generate the armhf deb?
#ubuntu-arm 2015-04-19
<warsh> how do I change my username? I know about usermod -l [newName] [oldName] . But my the user is still running bash; and pkill isn't helping. Any suggestions?
<warsh> s/my/
#ubuntu-arm 2016-04-20
<glsmaxx> anyone here have problems with Ubuntu-Mate? I can only get my sound (Powered SPeakers.) to come out garbled and pretty much not understandable.  It worked for a long time, Just fine  -But then just all of a sudden changed for the worse. I had been watching YouTube Vids and anything else I tried to play...?..
#ubuntu-arm 2016-04-22
<J0hnD03ii> anyonee working on 16.04 for the pi 2/3?
<ogra_> there are snappy images ... and i think there will be mate ones .. (not sure if they are ready yet)
<J0hnD03ii> ogra_, what does the snappy image do?
<ogra_> run a snappy system (no apt)
<J0hnD03ii> no apt :(
<Gjax> trying to install new kernel at my raspberry pi.
<Gjax> However getting a dpkg configure error for the kernel
<Gjax> gzip: stdout: No space left on device
<k1l_> No space left on device
<Gjax> o rly? ... of course there is space. The issue is how do I replace the kernel
<Gjax> the automatic tool doesnt want to seem to do it automaticly
<ogra_> probably because there is no space left :)
<ogra_> if hwe had stayed around one could have asked about his partitioning :)=
<ogra_> *he
#ubuntu-arm 2016-04-23
<euanthe> Hello! I've extract an Ubuntu Server 14.04 "trusty" to my one-board PC arch-ARM, and I am trying to run "apt-get update" but it constantly shows "404 Not found" for "ports.ubuntu.com"
<euanthe> It tries to download a "Packages" file, this file exists on the repository as "Packages.bz2" and "Packages.tg"
<euanthe> What can I do to make it work? I can't install packages at all.
<drunkendwarf> Hi all. Im uding Ubuntu on an armhf system (chromebook) .. if some software I want to use is compiled to .deb for an amd64 system, im guessing there's not much I can do about it? (its closed source, so I can't compile myself)
#ubuntu-arm 2017-04-20
<Joe-GAMER> Hello I have a Amlogic 8726 MX tablet with Cortex A9 processor, and want to install Ubuntu on it, this tablet can't be bricked, also without bootloader, I can even flash this bootloader back.
#ubuntu-arm 2018-04-16
<fxnoob> how long is the port for ARM for a new LTS?
<Nakaori> Hello, there is someone who tried ubuntu on BananaPi-m3 and tell if it's work very good ?
#ubuntu-arm 2018-04-21
<popnfresh768> https://www.youtube.com/user/l0de/live IS POPPIN HOT RIGHT NOW STILL GOING!! CALL 315-505-4666. IRC.EFNET.ORG #lrh
<popnfresh768> Freejack wolfgang8741 k1l_ ColdKeyboard ogra_ rexxster mariogrip robher nighty- y0sh niska manjo alai ubot9 fxnoob dragan-s nashpa Tm_T steev Strykar chrisccoulson aeughusegtgt zumbi_ awafaa guerby cmagina lvrp16 rsalveti rbasak dannf akaWolf lool persia PaulePanter funnel ubuntulog HeMan AceLan nslu2-log Alesk13 Jack87 yofel mrutland tlbr ndec Wimpress popey doko NCommander moon127 chihchun_afk micahg amrith wgrant ChunkzZ fabo
