#ubuntu-arm 2009-08-18
<ogra> NCommander, uboot executes a bootscript which scans all supported boot devices for a boot script ??
<ogra> why would it not look for uImage instead
<NCommander> ogra, how do you set a kernel command line then?
<ogra> in the uboot environment
<NCommander> As it stands, you can't access the uboot envirionment from userland
<NCommander> There's no SPI-NOR driver in the dove kernel
<ogra> how do you know ?
<ogra> have you tried the distro kernel that only exists since two days yet ?
<NCommander> I haven't tried that one, I had tried the previous binaries from Marvell and our kernel team
<NCommander> Even if we could access u-boot directly, I still think being able to execute boot scripts is a better way to go as then we have more control of the boot process
<Meizirkki> anyone here familiar with android hacking?
<ogra> right, please work with the kernel team so they get tests from you and you get all options you need
<NCommander> Meizirkki, try #android-dev
<ogra> i assume you worked through uboot-tools by now and know how they work ?
<NCommander> ogra, I'm not getting why we want to touch uboot's enviornmental variables directly if we have a better way to control the boot process
<NCommander> ogra, right, uboot-envtools, and uboot-mkimage
<ogra> s/tools/envtools/
<Meizirkki> NCommander, thanks, i'm looking for anyone who might have some knownledge about the android-on-ubuntu
<ogra> i dont get why you want to move into grub1 hell
<Meizirkki> that's why i was asking here
<NCommander> ogra, grub1 hell?
<ogra> grub and its menu.lst was always very error prone, if you can avoid such a setup you should
<NCommander> How is it more error prone then just poking the u-boot variables from RAM?
<ogra> NCommander, your boot proposal doesnt tell anything about the image layout or your plans
<NCommander> And you still need to be able to load the command line from the boot device
<ogra> u-boot should try to load ext2 and fat formats, at /boot.scr and /boot/boot.scr
<ogra> can you make a decision for one here
<ogra> (prferably the latter)
<NCommander> No, it should support both
<NCommander> Having a separate /boot should be supported, as well as just one whole root partition
<ogra> you dont want to have /boot.scr
<NCommander> If /boot is a separate partition, when u-boot mounts it, its going to see it as /boot.scr
<ogra> there is nothing that indicates a separate /boot
<ogra> please properly write down how your image will look like first
<ogra> and how the installed system will look in the end
<ogra> make sure your setup supports what you lay out
<ogra> *then* add the noce to have stuff like separate /boot
<ogra> or /boot.scr
<ogra> the layout should be the first thing you describe
<ogra> so people know how it looks like
<ogra> you should also remove all the mentioning of imx51 in the spec ... its a bit confusing
<NCommander> ogra, amended.
<ogra> so *will* you have a separate /boot or will you *not* have a separate boot ?
<ogra> your spec doesnt say that
<ogra> "Normal vmlinux and initrds will continue to exist in /boot alongside the uImage/uRamdisk. "
<ogra> thats definately something you should quickly tell the kernel team
<ogra> since they just changed everything to *not* produce vmlinuz
<ogra> please work closer with them, they are depending on your input
<NCommander> ogra, both are supported
<ogra> no
<NCommander> no?
<NCommander> We don't want to support /boot as its own partition?
<ogra> i was commenting on vmlinuz
<NCommander> oh
<NCommander> argh, i talked to rtg on this yesterday, and no one said a thing
<ogra> what did you tell him to do ?
<NCommander> ogra, I had asked him on the status of packaging after being pointed at him by bjf
 * NCommander sighs
<ogra> they are modifying the deb package this moment to build uImage
<ogra> after the deb package sat in NEW since yesterday night
<NCommander> ogra, this is also why I wanted to use flash-kernel, so nothing would have to change elsewhere in the postinsts, and update-initramfs
<ogra> please coordinate with them on all the kernel stuff
<ogra> they will happily give you what you need if you actually tell them
<ogra> vmlinuz is surely not needed at all if the deb can spit out uImage at build time
<ogra> and you save hacking to convert vmlinuz
<NCommander> ogra, hrm, fiar enough, I was thinking about having the uImage made as the postinst rule
<ogra> why if the package can just use make uImage
<ogra> what would you use vmlinuz for at all ?
<ogra> NCommander, so what i would like to see in the spec is: the current livefs we build will use a partitioning scheme like: ... blah ...
<NCommander> ogra, I didn't know we could make uImage, I didn't realize Marvell added that target
<ogra> the installed system will default to a extX single partition setup (or will have /boot separated by default) etc etc
<ogra> i'm not talking about kernels yet
<ogra> i want to know what you are building and how the installed system looks like with the selected defaults
<ogra> and en explanation why you decided for the layout
<NCommander> ugh
<NCommander> This may be a stupid question
<NCommander> But is an ext4 filesystem compatible w/ ext2 once extents are enabled?
<ogra> i.e. "the installed system will use a two partition layout by default because we want to support the default used ext4 filesystem for the rootfs but uboot does not support that for /boot"
<NCommander> I remember reading that once you enable extents or do a full format, ext2 compatbiility flies out a window
<ogra> something like that
<NCommander> Ugh
<ogra> its your project
<NCommander> Let me update the spec to reflect that
<NCommander> ogra, yes, I know
<ogra> make a proper design, describe it and give reasoning for the decisions
<ogra> for both the livefs and the resulting installation
<NCommander> ogra, doing so now
<ogra> ok
<ogra> take your time
<ogra> i assume it will take a day writing that up properly unless you have it prepared already
<NCommander> ogra, I do have it prepared (I wrote up my ideas on the internal wiki, but I didn't quite get the right level of detail when I started writing :-))
<ogra> right, flesh it out, compare pro and con fo different designs and give an explanation why you decided for a particular design
<NCommander> ogra, *nods*
<NCommander> ogra, great, I see having to tweak partman in my future though :-/
<NCommander> the fun just never ends
<ogra> you could decide for a single partition ext3 setup
<ogra> that limits the changes
<ogra> u to you
<ogra> *up
<ogra> tlee2, hey am i just mailing with you ?
 * ogra just notices you are here, we could chat quicker than by mail
<tlee2> Orga, hi, yes, that's me.
<ogra> cool ! :)
<ogra> great to see you here
<tlee2> Thx
<ogra> amitk, ogra@dove:~$ uname -a
<ogra> Linux dove 2.6.31-rc5 #1 Tue Aug 18 17:39:23 CEST 2009 armv7l GNU/Linux
<ogra> amitk, meet tlee2, he is working on doves at marvell :)
<NCommander> hey tlee2
<ogra> tlee2, amit is one of our arm kernel guys
<tlee2> nice to meet you Amitk.
<ogra> amitk, so make uImage in the package tree gets me proper booting images
<ogra> ready to change the packaging :)
<amitk> tlee2: hi there
<NCommander> tlee2, you won't happen to do anything w.r.t. to uboot on the dove?
<amitk> ogra: awesome. So we'll changes the configs to create uImages instead of zImage
<ogra> yeah
<ogra> perfect
<tlee2> what's w.r.t?
<NCommander> tlee2, with respect to :-)
<tlee2> Well, I am new to this ...  Ok, I use the uboot.  Sometime, I build it too.
<tlee2> Do u need anything on uboot for Dove.
<tlee2> Wow, your uImage is newer than mine.....
<NCommander> tlee2, working USB support would be nice :-/
<tlee2> Need to upgrade mine now.
<ogra> tlee2, i just built it some mins ago :)
<NCommander> The last drop I got still didn't have it working (I'm not sure if SATA works as I lack the connector cable which I need to try and get today)
<ogra> from the latest merged tree from our kernel team
<ogra> they are working on getting a proper kernel package together atm, these are needed for the live images
<tlee2> I use sata and NFS from uboot.  They are faster, have not try usb from uboot yet.
<ogra> well, we traget live images, so everything has to be on the same media
<ogra> NFS is no option for that
<NCommander> tlee2, so SATA support works, that's a win
<ogra> cool would be if uboot could run what it finds on a USB key or SD card
<tlee2> SATA already work.
<NCommander> ogra, that's my plan
<ogra> then you get into a live image and run a normal install to SATA
<NCommander> ogra, the bootscript is going to iterate through all USB/SATA devices on start
<NCommander> ogra, like the beagle, with different devices
<ogra> right
<NCommander> ogra, that's why a boot script is loading from the partition and not mucked w/ uboot-envtools
<ogra> i was trying to explain to tlee2 what we are actually targetting
<NCommander> ah
 * NCommander goes back to writing
<ogra> yeah, if your writeup is done we can just point people there ;)
<NCommander> ogra, its getting there
<ogra> tlee2, NCommander is the michael i was CCing in the mail before ... he does the dove images
<NCommander> tlee2, is there a method to load a u-boot into RAM without flashing it? I got a set of steps, but it just caused the board to reset, and I don't have a JTAG flasher or equivelent to recover from a bad flash if that happens
<NCommander> tlee2, nice to meet you
<tlee2> Nice to meet you NCommander.
<tlee2> One few other board, there are way to load uboot to RAM from SATA.  I have not try that on Dove.
<tlee2> I don't have to change the uboot on my boards.  And I have ice.  :-) Sorry.
<NCommander> tlee2, well, I read the technical specifications we got, and I know the BootROM can load u-boot from NAND, SATA, NOR, and serial
 * ogra knows the beagleboard does that from SD ... so its easy to replace uboot there 
<NCommander> ogra, no SD support in Marvell's u-boot
<NCommander> (yet)
<ogra> yeah
<NCommander> tlee2, but I haven't managed to figure out how to flip the boot device
<NCommander> ogra, I'm not sure its targetting to exist or not)
<ogra> ??
<ogra> can you rephrase that ?
<NCommander> ogra, there's currently no SD/MMC support in uboot (the entire subsystem is missing). I'm not sure if we're excepting it or not to exist
<ogra> we need one, SD or USB ...
<ogra> i personally dont care which one :)
<NCommander> Right, and I know USB is supposed to be coming
<ogra> right
<tlee2> When are we going rebuilding the karmic with vfp compiler?     How long do u think it will take?
<ogra> as soon as the new build machines are in place
<ogra> the HW is there but afaik we're waiting for a chunk of new disks
<tlee2> The build machine is Dove, imx51 or Beagle?
<ogra> currently the older marvell boards (v5) new ones will be imx51
<ogra> our IS team lokes to use ubuntu on the build machines, imx51 is the system we have stable images for since last release ... we're hoping to upgrade everthing to dove next cycle
<ogra> s/lokes/likes/
<tlee2> which v5 board r u using?
<tlee2> 78k?
<ogra> i dont know the exact model actually
<ogra> but yeah, i think its 78xx something
<ogra> i'm luckily not working in the datacenter ;) i just use it
<tlee2> I see, just remotely....   Cool.
<jmc93739653> I know this is a little off topic, but does  anyone know if Freescale & Pegatron are still on target for a i.MX515 netbook release in the early fall?  It would be _perfect_ for Linux & ARM development, but I haven't heard anything since January.  128 MB on a Nokia N800 is a bit cramped (and gcc's -Os flag doesn't like to play nice for me).
<jmc93739653> I've only heard of, and possibly found a single JPG of a Babbage Board, so I'm presuming it's several thousand per dev-kit.  A consumer i.MX515-based rig on the other hand....quite compelling.
<ogra> there is a company selling an imx51 development board for $750, i sadly lost the link
<ogra> its largely the thing that will go into the pegatron netbooks
<jmc93739653> ogra: That alone is a lead to work off of.  If I find it, I'll pastebin or tinyurl it and paste it here.
<jmc93739653> ogra: I had some extra money in January when the i.MX51 line was announced, I would have bought one right then and there. 1000 MHz ARMv7A?  Yes, please.
<suihkulokki> ogra: presume you are talking about genesi
<ogra> yeah, right
<ogra> there are nettops coming from pegatron too but i dont know when they will go into mass production
<jmc93739653> suihkulokki: Genesi finally released the 515 boards?  They had their i.MX projects using Rev B Beagle Boards, last I heard.
<ogra> if you want something *Really powerfull* you wait for the marvell dove boards though ;)
<tlee2> ogra, the 78k build machine you are using can be use to build and test vfp code.   Is there any issue with that?
<ogra> outdated kernels
<tlee2> 78k kernel is check in to the kernel.org already.
<suihkulokki> jmc93739653: no idea if they are really released but they have it on their website
<jmc93739653> Are the Marvell Dove boards based on their Sheeva SoCs?
<ogra> jmc93739653, better :)
<jmc93739653> ogra: and Marvell's asking price ? (and the system RAM capacity?)
<ogra> no idea yet but ram i have seen was 512M
<jmc93739653> ogra: Nice. :) Is it true Ubuntu had a custom ARM-based motherboard built loaded to the gills with 2 GB of RAM, and clustered them into a build farm?
<ogra> heh, who told you that ?
<jmc93739653> ogra: honestly, I don't even remember.  I thought I read it on something like LinuxDevices.com, but at the time I was scanning 7000 tech stories a day from XML feeds.  The story was centered about a company which aided in the manufacture of embedded development boards, but was starting to center upon customized variants of their primary products.
<ogra> well, its not true
 * lool returns and waves
<ogra> lool, have you see the dove kernel in NEW ?
<ogra> the naming is borked again :/
<jmc93739653> ogra: damn!  Oh well, dreams are nice.  I'd be OK with QEMU, but it seems like no matter what x86 CPU I throw at it, ARM emulation is, let's say, sub-optimal.  I thought x86-64 would speed things up given better register parity between the ISAs, but I was wrong.  (A Diablo N800 running on QEMU-10.5 is not nearly as agile as I was hoping.)
<ogra> yeah, qemu arm emu is even worse on amd64
<ogra> thats why i only built the qemu-arm-static packge for i386
<ogra> it has massive issues with chroots on amd64
<ogra> (assuming you have seen https://wiki.ubuntu.com/ARM/BuildEABIChroot )
<jmc93739653> OK.  Thank you for the heads-up.  Has anyone been able to determine why amd64 causes so many issues?  Toolchain or code-base maturity/testing/deployment-base advantages of i386 over amd64?
<ogra> i stopped looking at qemu-system-arm ... userspace syscall translation is so much faster for the purposes i need qemu for
<jmc93739653> ogra: Yes, I have.  I was going to tackle the EABIChroot walk-through later this week in some spare time.  I have amd64 Karmic Alpha 4 installed, but if 32-bit from top to bottom pays dividends, I'll leave idealistic ISA daydreams at the door, and go back to i386.
<ogra> heh
<jmc93739653> ogra: karmic over jaunty for ARM-emulation purposes?
<ogra> yes
<ogra> qemu 0.11 is a real imrpovement
<jmc93739653> Cool.  The qemu versioning and the addition qemu-arm-static lead me towards karmic.  (I could have sworn I say a qemu-arm-static package for amd64.  Well, that's hay-fever season and extra-drowsy antihistamines for you....)
<jmc93739653> s/say/saw
<ogra> no, there is none
<ogra> i had one of the hacked up 0.10 in my PPA
<lool> ogra: Did you give a heads up to kernel team WRT kernel name?
<ogra> lool, yes, rtg knows my concerns about the header names
<ogra> fls is also being worked on i was told
<ogra> *fsl
<ogra> NCommander, http://people.canonical.com/~ogra/arm/dove/
<ogra> there is the uImage of my testbuild from todays branch
<ogra> (note the deb there is old and outdated)
<jmc93739653> ogra: I never checked the PPA, truth be told. ARM eabi-chroot and QEMU packaging, maintenance and modification are several of your core competencies, I'll take your word over my suppositions. :)
<ogra> heh, i never touched qemu before this release cycle :)
<ogra> but right, i'm focused on it since a few months
<ogra> mainly for image builders for hardware we dont support ... the arm community is still to small
<jmc93739653> ogra: Sweet.  All I've done with qemu source is alter the partition table parameters for the Nseries tablet emulation to enable Diablo compatibility.  (I had fun.  amd64's weaknesses hopefully explain why the ARM emulation ran so poorly.)
<ogra> i'm currently banging my head against the missing sched_getaffinity() syscall in qemu-arm-static
<ogra> it makes mono installations fail in the images
<jmc93739653> A 45nm, 3.0 GHz Core 2 Duo with a 65 watt thermal budget should not be beaten out by a 90nm, 2.0 Pentium-M for qemu emulation.
<jmc93739653> ogra: do you have any URLs for the issue reports handy?  I'll grep around launchpad all the same.  Am I right in assuming sched_getaffinity() is a QEMU syscall, rather than a libc6 or libpci-dev system-call?
<suihkulokki> ogra: feel free to send me a patch once you've implemented the syscall in qemu linux-user :)
<ogra> its a libc syscall that needs to be translated between the two arches
<ogra> suihkulokki, i have a patch that apprently idles around in the suse packages since ages
<ogra> they didnt bother to every send it upstream it seems
<ogra> sadly i havent mad it work yet ... it applies fine to 0.11 and the "unsupported syscall" messages goes away
<ogra> but the mono cil assembly installation still doesnt finish
<ogra> suihkulokki, http://paste.ubuntu.com/255278/
<ogra> in case you hve any idea for improvements
<suihkulokki> ogra: I guess you'll want to look at the definition of cpu_set_t
<ogra> good idea
<jmc93739653> Does any one know if using x86-32's PAE tanks userspace qemu performance?
<suihkulokki> ogra: also qemu-arm -strace ./foo and comparing it to strace qemu-arm ./foo gives usually good hints where the syscalls go wrong
<ogra> but not today anymore ... i'm on the kbd since 13h without break ... thanks for the suggestion though i'll dig into it tomorrow
<ogra> i really dont get why suse didnt contribute it upstream though ... i pulled that out of their 0.9 package
<suihkulokki> at least suse is sending most of their patches upstream
<ogra> well, that one not :) and it seems it has been a prob in maemo and scratchbox since ages
<ogra> though i doubt there are actually many people running mono on n8x0's :)
<jmc93739653> ogra: I'm hesitant to run Python apps on an N800 :)
<jmc93739653> Anyways, thanks everyone for your patience and time. My apologies for the rather daft questions.
<ogra> py is fine though from a design perspective it was intended to run cross arch
<ogra> mono only grew suport for non x86 later
<ogra> anyway, its getting late, i'm working way to long already and will call it a day now
<jmc93739653> ogra: Take care, again, thank you.
<ogra> :)
<Madsy> I followed the RootFromScratch article to setup Ubuntu for QEMU, but the emulated system crashes right away. I'd really appreciate some pointers on what the cause might be.
<Madsy> Here's my log from running the build-arm-rootfs script, with some of the overly verbose package info omitted: http://gist.github.com/169920
<lool> Madsy: Looks like the script assumes presence of /etc/init.d/loopback which is not there for you
<lool> Madsy: perhaps it works with karmic?
<lool> Madsy: Either file a bug or talk to ogra here
<Madsy> lool: I'll give the updated rootstock script a try first. Thanks for replying.
<Madsy> Gah, I feel stupid. I didn't remember that both QEMU and the kernel parameters take "friendly" values for sizes. I forgot an 'M'
<hammad> hi, i want to build a portable media player using the arm processor, is there somwhere you can point me to for guidance to start me on it.
<hammad> it is just n idea right now
<hammad> m planning on having a touchscreen and a camera and bluetooth for i/o
<hammad> with respect to the above query, if anyone can help me out, please contact me at: hammad.fauz <at> gm ail <dot> com
#ubuntu-arm 2009-08-19
<royerfa> HI all
<royerfa> I am trying to install ubuntu on my beagleboard
<royerfa> I am following the wikipage https://wiki.ubuntu.com/ARM/RootfsFromScratch
<royerfa> and I am not sucessful in creating a armel-rootfs-****.tgz
<royerfa> this command line sudo ./build-arm-rootfs --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 3G --seed ubuntu-desktop
<royerfa> is creating nothing for me :(
<royerfa> Thank in advance for any help :)
<lool> ogra: ^
<ogra> where is your log ?
<royerfa> this is what I have on the command line fabroy01@fabroy01-desktop:/media/sdb/test$ sudo ./build-arm-rootfs --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 3G --seed ubuntu-desktop
<royerfa> I: Creating temporary Image
<royerfa> fabroy01@fabroy01-desktop:/media/sdb/test$
<ogra> do you have qemu installed ?
<royerfa> yes
<ogra> well, there should be a log
<royerfa> and debootstrap_1.0.13~jaunty1_all.deb
<royerfa> there is nothing created
<ogra> are you on jaunty or karmic ?
<royerfa> I don't remember .. what is the command to tell ?
<ogra> lsb_release -a
<ogra> Codename should tell you
<royerfa> intrepid 8.10
<ogra> oh
<ogra> i dont think i every tested it on intrepid at all
<royerfa> OK could be the raison
<royerfa> I am testing it on a 9.04
<ogra> well, still strange that you dont get any output
<ogra> directly after "I: Creating temporary Image" it runs qemu-img to create an image, that should spill any output even if it doesnt work
<royerfa> I will upgarde and let you know
<ogra> oki
<royerfa> sudo apt-get upgrade right ?
<ogra> no, use update-manager
<ogra> do you run a desktop system atm ?
<royerfa> no I am using the box as a server
<ogra> http://www.ubuntu.com/getubuntu/upgrading
<ogra> "Network Upgrade for Ubuntu Servers (Recommended)"
<ogra> follow that reciepe
<royerfa> thx you very much
<Madsy> Slightly off-topic. Is it possible to tell gcc *not* to emit literal values in the .text segment?
<Madsy> ARM gcc does that (uses a pool) because the address modes can't hold all permutations of 32-bit immediates.
<lool> Madsy: the man page mentions -mtext-section-literals and -mno-text-section-literals; sounds like what you're looking for?
<Madsy> Wow, that's it. Thanks :-)
<Madsy> I did look at the manual, but must have missed it.
<Madsy> I made a metamorphic engine for fun some time ago. Compared to say, x86 it's a lot more easy since instruction encodings are of constant length.
<Madsy> I have a weird affection for evoolving code and AI.
<Madsy> If I can get rid of all data in the .text segment, I can simplify the code a lot. And rewrite it in pure C.
<royerfa> HI, I get rid of my problem on the 9.04 release
<ogra> cool !
<royerfa> I was wondering if the beagle board would boot without a keyboard and without a screen ?
<royerfa> as I want to use it only as a server
<ogra> it should
<royerfa> ok
<ogra> you will need openssh-server in the rootfs indeed and should set up /etc/network/interfaces on the SD card
<lool> Or use the serial console
<lool> :-P
<ogra> right, but that needs changes to the SD as well :)
<ogra> or use rootstock, that already has serial support ;)
<Madsy> ogra: Your qemu-versatile 2.6.28 image, is it straight from kernel.org or the kernel from Ubuntu Intrepid?
<ogra> ubuntu
<Madsy> Do you happen to know the calling convention for system calls? I.e is the immediate in SWIs used like in ARM Debian 2.4 kernels? Or are the arguments passed by r0-r4?
<Madsy> Debian updated the ARM ABI when they ported the 2.6 kernel.
<ogra> i havent used debian stuff since woody, sorry
<ogra> lool might know the differences
<lool> Madsy: its EABI syscalls conventions
<lool> Just like the Debian armel port
<Madsy> Thanks.
#ubuntu-arm 2009-08-20
<kinkie> Hi all.
<kinkie> Does anyone know if there is any cookbook on installing on a qemu-backed image? Thanks
<ogra> see /topic
<kinkie> ogra: found, thanks. I was hoping for something which didn't involve building the rootfs ;)
<salil> ogra, i have a question related to samba - large file copies are failing
<ogra> you mean using debian-installer with a netinst image ?
<salil> ogra, fiel accessing through windows clients, it says Network name no longer available
<ogra> salil, which arm board ?
<salil> ogra, sheevaplug
<ogra> might be a kernel issue, i bet you use a debian kernel with ubuntu rootfs ?
<salil> yup
<salil> but normal file copying succeeds fine
<salil> no issues - for larger files - this error pops up
<kinkie> ogra: sounds more like it ;). I'm interested in setting up virtual hosts for the squid build-farm.
<salil> and the size is being increased in the background - it might ftruncate()'ing i guess :(
<ogra> kinkie, https://wiki.ubuntu.com/ARM/QemuNetInstall might work
<kinkie> ok, will try that.
<kinkie> Thank you
<ogra> salil, sorry i never used samba on arm, are you sure its armel specific ?
<ogra> i know kblin does some samba stuff though, probably he knows something
<salil> ogra, might not be only arm-specific i think it can be a build issue?
<salil> ogra, i had faced similar problem while running samba on arm-board with a fedora distro
<salil> ogra, there the error vanished completely after recompiling the smbd with --enable-largefile or some such similar option
<ogra> well, as i said in the beginning, might be due to a version mistmatch between the kernel module and userspace for example
<ogra> not sure how deep smbd hooks into that
<ogra> probably wait for slangasek to show up in #ubuntu-devel, he knows a lot about samba in general (pacific timezone though)
<ogra> he might also know if that issue shows up on other arches, if its build related any why the build is done as its done
<salil> ogra, how/where can I find out if the samba is compiled with such an option?
<ogra> apt-get source ...
<salil> ogra, because for fedora exactly similar behavior was seen and it was removed after the compile flag addition
<ogra> look at debian/rules, it should have the config options used
<salil> ogra, o ok thanks
<royerfa> HI
<royerfa> I just want to share that with karmic on the Beagle board RevC2 and RevC3 I am having an issue with the usb adaptor http://www.amazon.co.uk/LUPO-Ethernet-Network-RJ45-Adapter/dp/B000S6DFZ8/ref=dp_cp_ob_ce_image_0
<royerfa> but this one http://www.amazon.co.uk/Belkin-Ethernet-Adapter-Patch-Cable/dp/B0002AFKN0 is working fine
<royerfa> :P
<amitk> ogra: do you know if fec ethernet requires firmware?
<ogra> no idea
<ogra> if so, we had it in jaunty
<amitk> i don't see the driver making any calls to load firmware, so probably not
<ogra> yeah and i dont remember it being added to linux-firmware in jaunty
<ogra> i thught you had the HW documentation, it should say that
<lool> royerfa: You're probably not using an Ubuntu kernel though so best to report the issue to your kernel distributor
<amitk> royerfa: does that usb adaptor work with _any_ linux distro? If so, you could file a bug with lsusb info for us to fix.
<royerfa> actually THis adaptor is just not working with my configuration, I tried with other Beagle Distrib without sucess such as Angstrom or a ARM filesytem
 * ogra sighs about the publisher slowness ... having to wait 2h after a package built is really no fun
<amitk> royerfa: have a linux PC on which it works?
<royerfa> Has someone use sucessfully this kind of adaptor?
<royerfa> This adaptor is for me connected to the USB hub and the HUB is connected to the USB host
<royerfa> with a REVC3
<amitk> what does 'lsusb' say?
<ogra> and did you try plugging it in a laptop or desktop machine
<ogra> from the case form it looks like various adapters i have seen working, all required the proper firmware to be available though
<royerfa> ubuntu@beagleboard:~$ lsusb
<royerfa> Bus 001 Device 003: ID 0fe6:8101
<royerfa> Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
<royerfa> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
<royerfa> would you mind if I copy/paste the dhclient output ?
<amitk> royerfa: dhclient is no use if the HW does not have an associated driver
<amitk> do you have an eth0 in the output of 'ifconfig'?
<royerfa> when i first start I have only lo
<royerfa> If I do a dhclient I will get a eth3
<royerfa> without ip adress
<amitk> from lsusb - Is this 0fe6:8101 your usb devices?
<amitk> try unplugging it and running lsusb to make sure
<royerfa> yes THis is the one 0fe6:8101
<royerfa> when I unplug the USB adaptor only ID 1d6b:0002 Linux Foundation 2.0 root hub is reamaining
<amitk> what is the output of lsmod?
<amitk> You need the dm9601 module loaded: http://cateee.net/lkddb/web-lkddb/USB_NET_DM9601.html
<royerfa> there is no module loaded as the Ubuntu filesytem doesn't have any
<royerfa> my /lib/modules/ is empty by default
<royerfa> And i guess this is probably the raison of the error but !
<royerfa> I tried with some 2.6.29 kernel all-build in
<amitk> royerfa: yes, it is compiled as a module in the ubuntu kernel
<amitk> but since you are not using the ubuntu kernel, you need to make sure that module is compiled-in or loaded somehow
<royerfa> I am using the ubuntu kernel  2.6.29-oer40.5
<royerfa> I just tried different setup
<amitk> that isn't an official ubuntu kernel
<amitk> since we don't create kernels for the beagle board
<royerfa> this is comming form the command sudo ./rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --seed xfce4,gdm --dist karmic   --serial ttyS2 --kernel-image http://rcn-ee.com/deb/kernel/beagle/karmic/v2.6.29-58cf2f1-oer40.5/linux-image-2.6.29-oer40.5_1.0karmic_armel.deb
<amitk> This driver probably wasn't even present in 2.6.29
<amitk> try .31
<royerfa> ok thx you
<royerfa> I will continue investigating!
<royerfa> where can I find some prebuild armel-rootfs-200908101131.tgz vmlinuz-2.6.29-oer40.5 Jaunty build for Beagle ?
<bjf> plars, http://kernel.ubuntu.com/~bradf/uImage-z0  (in case you are interested)
<plars> bjf: nice, I'll check it out thanks!
<ogra> lool might be intrested too
<plars> bjf: was it just a config issue?
<plars> yay, it's booting! :)
<ogra> bjf, i dont get the full 512M in the Y0 with the distro kernel btw, unless i specify mem=512M
<ogra> it works gret if i set it
<ogra> *great
<bjf> plars, yes, just a minor config issue
<plars> After this operation, 1894MB of additional disk space will be used... this might take a while on my 4G sd card :-S
<kozak> Hi all,
<kozak> I have some doubts on writing daemon programs, can some one point to resources on daemons?
<kozak> I am able to find and understand basic daemons, but would like to know if it can talk to other processes, take input from other processes,etc.
<rjune_> kozak: This isn't the forum to ask.
<rjune_> This channel is dedicated to ubuntu on ARM hardware.
<rjune_> I would point you to the C channel, the general linux channel. and If you can code already, I would suggest you look at existing services, such as lightweight webservers.
<kozak> Thank you for your response! I dont have a clue on where to ask in fact. I tried #ubuntu
<rjune_> or lightweight cron.
<kozak> oh thank you !
<rjune_> kozak: ##linux
<kozak> I will try it there
#ubuntu-arm 2009-08-21
<ogra> lool, how good are you with d-shlibs ?
<ogra> i'd like to add "s/ld-linux3-dev//" to the overrides to fix the graphviz and libshout FTBFS but i'm not sure its the right approach
<lool> I didn't touch that until now but can have a look
<ogra> 		/build/buildd/graphviz-2.20.2/debian/tmp/usr/lib/*.so
<ogra> devlibs error: There is no package matching [ld-linux3-dev] and noone provides it, please report bug to d-shlibs maintainer
<ogra> thats the error (same in libshout and i bet if i dig i find more that try to use the nonexisting ld-linux3-dev
<ogra> )
<ogra> so imho just wiping it from the shlibs should be ok, there is nothing like ld-linux3-dev or similar
<lool> Oh my this package is horid
<ogra> grapviz ?
<ogra> *graph
<lool> d-shlibs
<ogra> oh, heh
<ogra> well, its small at least ... only two binaries
<ogra> overrides are set in d-devlibdeps
<ogra> ah ubiquity uploaded
<lool> ogra: So I'm not sure we really want to hide the problem by changing d-shlibs; it might very well be the thing to do but I'd like to check why we end up wit a NEEDED entry on ld-linux
<lool> ogra: Could you do a manual build of either package and see whether all binaries have it and perhaps check why?
<lool> Could be new toolchain
<lool> ogra: At least in the current graphiv the *.so dont have it
<ogra> its a pretty old thing
<ogra> i just dug up the same on http://mojo.handhelds.org/frisky-devel
<lool> Sorry I mean in the jaunty graphviz; not sure whether we have a new one in karmic
<ogra> Our glibc ends up having /lib/ld-linux3.so found by d-devlibdeps and then it can't figure out how to do the depedencies. The quick fix is to add ld-linux3-dev to the overridelibs and replace it with nothing (i.e., s/ld-linux3-dev//). This problem first showed in in package libgd2
<ogra> thats the changelog entry mojo made back in feisty
<ogra> so i doubt its a new toolchain realted thing
<lool> ogra: Well that's exactly the same change as the one you want to do but it doesn't explain why we end up with a NEEDED on ld-linux
<ogra> bcause /lib/ld-linux3.so exists and d-devlibdeps adds it
<ogra> which is wrong in itself
<lool> ogra: Run objdump -p on random binaries or libs on an installed armel system
<lool> ogra: Under jaunty, I cant find any
<lool> with ld-linux as NEEDED
<lool> If I look at recent karmic rebuilds they have it
<ogra> yeah
<ogra> i see it on plenty files in /usr/lib
<lool> The question is whether this is a bug or not
<lool> I can tell for instance on libperl.so.5.10 it was added between jaunty and karmic
<ogra> so we should consult doko i guess
<lool> Yup that's what I'd d
<lool> do
<ogra> will do after my packagekit build is done and uploaded
<lool> NCommander: There's still a jaunty task on https://bugs.launchpad.net/ubuntu/karmic/+source/lightning-sunbird/+bug/385325
<ubot4> Launchpad bug 385325 in thunderbird "[armel] thunderbird-bin crashed with SIGSEGVI" [Medium,Confirmed]
<lool> NCommander: Please push a fixed TB to $ppa, either with backported fix or a new upstream
<NCommander> lool, sure, but its very low on my priorities list ATM, I likely won't get to it until next week
<lool> NCommander: I'm a bit worried that so many things are just falling off the radar instead of being fixed on the spot
<lool> It's not like it would be a very long job to prepare a backport would it?
<NCommander> lool, I was shot down on doing a backprot
<NCommander> lool, asac insisted that it would be fixed via a new upstream release via security
 * NCommander had a backport prepared
<lool> Hmm
<lool> I'll check with asac
#ubuntu-arm 2009-08-22
<ojn> Has someone already built and provided (official?) cross toolchains for arm in .deb format, or does everyone tend to prefer building their own?
<[g2]> ojn: I've build the rootfs from scratch (see banner), then it's just and armel rootfs and the .debs are native
<lool> ojn: AFAIK only emdebian provides some; I'd like this to change but didn't put much time in this project as of late
<lvh> Hi!
<lvh> I'm using rootstock to build an armel rootfs
<lvh> Is it normal that I don't see anything after this line for 10+ minutes with no evidence of activity?
<lvh> I: Switching to Virtual Machine for second stage processing
<lvh> Gah!
<lvh> Typical.
<lvh> I ask for help and ten seconds later everything starts working :-D
<lvh> Sorry to bother you ;-)
<lool> lvh: It's terribly slow
<lool> Due to use of qemu
<lvh> lool: The one that worked was ubuntu not debian lenny
<lvh> /bin/installer: line 28: locale-gen: command not found
<lvh> /bin/installer: line 29: locale-gen: command not found
<lvh> sed: can't read /etc/default/console-setup: No such file or directory
<lvh> sed: can't read /etc/default/console-setup: No such file or directory
<lvh> sed: can't read /etc/default/console-setup: No such file or directory
<lvh> sed: can't read /etc/default/console-setup: No such file or directory
<lvh> presumably that's a difference between Ubuntu and Debian :-)
<lool> lvh: That's interesting; would you mind filing this as an upstream rootstock bug asking for Debian support?
<lool> (Priority wishlist)
<lool> I think it's an acceptable feature req
<lvh> lool: well, there's an obvious problem
<lvh> I forgot the -s list
<lvh> (see #debian-arm on oftc)
<lvh> that is: I'm figuring out how to proudce a --seed line
<lvh> because dbian doesnt have base system metapackages
<lvh> so we cant do something like -s ubuntu-minimal
<lool> So actually ubuntu-minimal should'nt be the default that's all
<ojn> [g2]: Yeah, I've definitely got that option but it's also convenient to at least do kernel builds on a faster machine. I'll spin my own, it would just have been convenient with a .deb. :)
<ojn> lool: Thanks
<lvh> hah
<lvh> lool: building the rootfs was successful
<lvh> lool: Fixed it sort of
<lvh> lool: debian worked, but no sudo
<lvh> and that script doesnt set a root pw
<lvh> so
<lvh> I can log in.... and I dont have root access ^^
<lvh> <- idiot!
<acoc> hey guys, I'm trying to get ubuntu on my sheevaplug and after creating the rootfs with the build-arm-rootfs script, my system hangs at starting kernel log daemon
<acoc> the kernel I'm using is from http://sheeva.with-linux.com/sheeva/
<acoc> 2.6.30.5
<acoc> google says it might have something to do with ldap, but since I don't have it in /etc/nsswitch.conf I'm not sure if that pertains to me
<yacoob> Hello there. Just wanted to ask, are there security updates for armel version of ubuntu?
<acoc> ogra, I see you are the point of contact for the build-arm-rootfs script, not meaning to sound disrespectful, but is it still maintained?
<lvh> bunch of commits just over a month ago
<lvh> I'd say it is
<lvh> don't fix what aint broken and all that
<acoc> oops forgot people.canonical is launchpad
<acoc> should have thought to just search his name
<acoc> could you think of any reason why this rootfs wouldn't work for a newer kernel (2.6.30)?
<lvh> wfm
<lvh> Oh, wait, no
<lvh> No, I can't think of anything. Sorry, old kernel here.
<lvh> I use what works (linwizard)
<lvh> for some strange reason this debian rootfs results in incredibly slow performance
<lvh> compared to gizard/wing-linux
<lvh> I'm not sure why
#ubuntu-arm 2009-08-23
<vlad> hey folks, redboot question.. on a babbage board, my current boot_script_data just has 'fis load kernel\exec -c "console=...."\'
<vlad> with jaunty installed
<vlad> the latest BabbageImageFromScratch page states that it should also load an initrd as well.. do I need to do that bit?
<vlad> yeah, looks likeI did need it updated
<vlad> but running redboot-install was not the right way to do it, since it has a handy "rm -rf usr" in it (what the hell?)
<ogra> vlad, yes, it removes the $builddir/usr direcory
<vlad> ogra: but it never goes into $BUILDDIR
<ogra> did you follow the howto step by step ?
<vlad> no, I had an existing build from jaunty, using the old instructions, pre-initrd
<vlad> so given taht the script was part of redboot-tools, I ran it on my target, and it rm -rf'd usr :)
<vlad> as best I can see the script creates a temp directory and then never changes into it
<ogra> ouch, can you file a bug, redboot-install as is si for creating an SD card from a foreign system
<vlad> (I also don't see what would ever get unpacke dinto usr, but I didn't look that closely at that)
<ogra> s/si/is/
<vlad> will do.. I ended up mailing the authors, I should've just filed a launchpad bug
<vlad> will do that tomorrow
<ogra> well, i am one of the authors (i just dont read mail frequently on sundays :) )
<vlad> oh! well you have mail :)
<ogra> heh
<vlad> I can stick it in a bug tomorrow though, having /usr go away on my remote system was a nice way to get me to stop doing work and go do something else ;)
<ogra> i will add a check so you cant run it from a running system, the script is to prepare an SD for a rootfs, not to use it from your babbage directly
<vlad> yeah, I figured that out too late :)
<ogra> its what we use to create the liveimages we provide
<vlad> though it would be handy if it could set up a canonical rb setup even on a running babbage
<ogra> but instead of using a livefs i redid it a bit so you can use it for normal rootfs bulids
<ogra> right
<ogra> add that to the bug please
<ogra> did you run it on jaunty ?
<ogra> stat: cannot stat `/usr/lib/redboot/imx51-babbage-TO2_redboot.bin': No such file or directory makes me suspect so ...
<vlad> yep, on jaunty
<vlad> my rb setup didn't have an initrd segment, and my boot commands just had the kernel load
<vlad> this all started with me wanting to upgrade to a kernel that had NEON support
<ogra> do you have a babbage from the 2.x series ?
<ogra> i doubt NEON works on the early ones
<ogra> and i dont think we enable it yet in the karmic kernels
<ogra> (we only got a .31 kernel for babbage in karmic about a week ago)
<ogra> there are first daily builds of the installable live image already though
 * ogra points to http://cdimage.ubuntu.com/ports/daily-live/
<ogra> you might want to try it :)
<ogra> (note there are plenty of bugs still though, but it should do a proper install to USB disk or a second SD)
<melchi> Hey does ubuntu run on a beagleboard?
<melchi> Hey does ubuntu run on a beagleboard?
<melchi> am i doing something wrong here or is this room empty
<Q_Continuum> The room is filled with people who idle, not everyone is sitting at their keyboards waiting for people to talk.
<melchi> Q_Continuum: lol ok... anyways does ubuntu run on a beagleboard ??? have u tried it?
<Q_Continuum> I haven't a clue, I have a SheevaPlug
<yacoob> Q_Continuum, now that you've said that, I have a sheevaplug related question! :D
<yacoob> are there security updates to arm port of ubuntu?
<Q_Continuum> yacoob: Perfect, there's also a plug channel #openplug
<Q_Continuum> as far as I know, yes.
<yacoob> http://security.ubuntu.com/ubuntu/ doesn't seem to have anything more than i386 and amd64
<Q_Continuum> It's a normal architecture Ubuntu supports, so there should be all the normal updates.
<melchi> hey are all the packages in synaptic cross compiled for the arm processor?
<ubuntu-user-b2> hello
<ubuntu-user-b2> can anybody tell me if it is possible to install ubuntu on ipod touch 1st gen?
<Q_Continuum> melchi: AFAIK, yes
<melchi> AFAIK? i dont speak IRC :)
<Q_Continuum> ubuntu-user-b2: I doubt that, there are some Linux-based tools that will install on an ipod.
<Q_Continuum> As Far As I Know
<ubuntu-user-b2> :(
<melchi> wow thats great so i will be able to get python scapy and aircrack-ng running on the little monster
<melchi> ?
<ubuntu-user-b2> but with display manager?
<ubuntu-user-b2> it is arm based afterall
<Q_Continuum> the ipod is VERY feature-lacking
<Q_Continuum> it's a tiny tiny CPU
<Q_Continuum> with basically nothing for RAM
<ubuntu-user-b2> yeah but so is the spv c500 and linux runs on that :)
<Q_Continuum> ubuntu-user-b2: http://www.rockbox.org/ is the linux-based tool I know of.
<ubuntu-user-b2> uuu
<ubuntu-user-b2> thanks
<melchi> Q_Continuum: hey does ur devices run on battries too?
<ubuntu-user-b2> ?
<ubuntu-user-b2> what devices
<ubuntu-user-b2> ?
<Q_Continuum> melchi: No, the SheevaPlug is wall-plugged while running.
<ubuntu-user-b2> thanks
<ubuntu-user-b2> gtg
<melchi> Q_Continuum: hey will you please check ur synaptic on the sheevaplug and let me know if python and aircrack-ng are present in the list?
<rabeeh> melchi: python is support. basically sheevaplug runs ubuntu 9.04 with most of the packages built for arm processor
<rabeeh> you can check ports.ubuntu.com for the packages that are compiled for arm (has armel in it's name)
<vlad> ogra: this daily live image build for imx51 -- I can't install to a SD card using this, right?
<vlad> ogra: erm, though even in the latest kernels, CONFIG_NEON is not set -- any reason for that?
#ubuntu-arm 2010-08-23
<DanaG> Nice job: http://theironlion.net/blog/2010/06/06/ubuntu-arm-board-and-i-walk-bar/
<DanaG> RON LION
<DanaG> That's what I get at 150% fullzoom.
<hrw> morning
<ogra> lool, what are you fiddling with upstart ? it didnt FTBFS since two uploads
<lool> ogra: Fiddling?
 * ogra wonders if the -fpic is still needed
<lool> ogra: I don't understand your remark
<ogra> lool, oh, it was -fpie not pic, why did you make that change to libnih ?
<lool> ogra: I reverted an armel-specific workaround, read the changelog
<ogra> oh, oops
<ogra> sorry, misread
<lool>   * Re-add -fPIE to the testsuite on armel, removing all armel-specific tests;
<lool>     current gcc-4.4 don't seem affected by the ICE anymore (see LP #398403).
<ubot2> Launchpad bug 398403 in upstart (Ubuntu) (and 4 other projects) "[PR40735] gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error (affects: 2) (heat: 20)" [Undecided,Fix released] https://launchpad.net/bugs/398403
<ogra> yeah
<rsalveti> mythripk: how do you identified all the supported timing values for omap4 in the hdmi driver?
<rsalveti> I was thinking if it can be compatible with omap 3 too
<rsalveti> robclark: maybe you also know the answer :-) ^
<ogra> lool, wrt your filesystem corruption issue from the weekend, do you use the initrd from the image and also the boot.scr ?
<ogra> lool, i wonder how you even got fsck output on stdout, the scripts in initramfs redirect all that to the jasper.log
<ogra> lool, also you wont be able to use that image without dd'ing it to a bigger img file (or min. 4G SD card), did you do that ?
<ogra> (thre images we produce are really not suited for qemu usage without a lot of fiddling)
<robclark> rsalveti: not sure how the timings were identified..  I think that is a question for mythripk
<robclark> but I'm not sure how similar the beagle hdmi driver is..  but I assume there must be a table somewhere that the bootargs map to
<rsalveti> robclark: yeah, could be, will have a look at it
<hrw> robclark: omap3 did not checked edid
<rsalveti> because the hdmi driver basically fetch the edid and then finds the best resolution that has a matching timing
<robclark> hrw: but I assume it still uses timings somewhere under the hood... when you set code/mode bootargs, those must map to some supported timings
<rsalveti> don't know if the code/mode is actually supported at beagle
<hrw> there is a map of resolutions in omap3 driver
<ogra> we have a spec to implement using EDID under omap3
<ogra> fyi
<rsalveti> ogra: I know, that's why I'm asking all these questions :-)
<robclark> that map should contain the timings, I would guess..  since at some point that needs to be programmed in to the hw to generate correct signal
<hrw> ogra: but without going to highest possible I hope
<rsalveti> robclark: hm, true, will try to find it
<ogra> hrw, with going to highest possible the current monitor and driver support
<hrw> ogra: 1680x1050x16@24 omap3 can generate, my display probably will display but I prefer to not go more then 1280x800 on it
<ogra> hrw, you are free to change the generated cmdline
<ogra> its just to get a good default entry
<hrw> sure
<ogra> indeed preferably the omap3 driver would do the same the omap4 one just learns and wouldnt need cmdline args :)
<ogra> but since we dont put much effort into omap3 development the cmdline will do for now
<hrw> armel-cross-toolchain 1.16 sent to PPA for build
<lool> ogra: As noted in my email, I don't touch the image at all and run it without resizing
<ogra> lool, yeah, but did you use the cmdline from boot.scr and the initrd from the image ?
<lool> ogra: I understand it might not be expected to work out of the box under QEMU, but my experience seems to indicate an underlying bug which might be worth looking into
<lool> ogra: I'm not touching the image
<lool> ogra: So it uses everything in there
<ogra> (the corruption is surely on buildd side, i'm just wondering why you get that output at all)
<ogra> so you use u-boot to boot it ?
<lool> The u-boot in your image
<ogra> right
<ogra> thats weird
<ogra> and when do you see the error ? before or after the automatic reboot
<ogra> (there shouldnt be an fsck at all apart from teh jasper one before the boot and all jasper output is logged silently to a file)
<ogra> s/boot/reboot/
<lool> ogra: On first boot
<ogra> thats strange
<ogra> there is only one forced fsck during the resize process, then it should reboot right after jasper prints "reboot check"
<ogra> if you see the fsck after "reboot check" its likely not following the process
<ogra> i.e. reboot doesnt work
<ogra> its also very likely that it doesnt do the resizing and reformatting at all in your case, which will definitely cause issues
<ogra> (partitioning or filesystem size doesnt matter at all since we rewrite the whole partition table and reformat/resize the filesystems before the rootfs gets ever mounted)
<ogra> so the corruption doesnt matter for functionality if the resizing works
<ogra> ndec, try to re-upload to the PPA, it should build armel now
<ndec> ogra: well, in fact it's not showing armel, but it does show sparc and powerpc ;-)
<ndec> ogra: you should be able to see the PPA, i have uploaded
<ogra> well, it was just changed, it should build armel now
<ogra> i think you need to re-upload
<ndec> ogra: I uploaded after you told me about it... is there any delay?
<ogra> ndec, ok, i'm told it should be fixed *now*
<ndec> ogra: i just tried to upload a package with arch=armel only, and it seems that the upload worked. we will see in a few mins.
<ogra> yep
<ogra> seems armel needed special treatment for enabling
<ogra> enabling the ports just gave ia64, sparc and ppc
<ogra> ah, your ubuntu4 upload looks good
<ndec> ogra: ubuntu3 looks good too. it has arch=any, and armel is there.
<ogra> ah, i didnt look at 3 :)
<ogra> but right, seems ok now
<ogra> ndec, so i'd say enjoy your PPA :)
<ogra> (and give me a list with other trusted uploaders at some point)
<ndec> ogra: i can add them myself since you made me admin, no?
<ogra> i didnt make you admin, i think asac did though
<ogra> but yes, you should be able to
<ndec> ogra: i will try. for now we will try to put all the packages in the PPA for review, and let you know.
<ogra> great :)
<prpplague> mopdenacker: hey, do i need to send another confirmation for my ELF-EU presentation, or was that just for the people who were CC'd on that email?
<mopdenacker> prpplague: no, you don't have to. I already have your confirm. :-)
<prpplague> mopdenacker: dandy
<prpplague> mopdenacker: i've got to finish testing some new boards this morning, then this afternoon i'll be back on your display issue
<mopdenacker> prpplague: perfect. Thank you very much! I'm excited to meet you in Cambridge at last :-)
<mopdenacker> Good luck!
<prpplague> mopdenacker: me too
<prpplague> robclark: hey, so you think we need to trace through the resize notification to track down this issue?
<DanaG> hmm, that bit about the log redirecting to jasper.log... shouldn't it use "tee"?
<robclark> prpplague: yes.. I think so
<prpplague> robclark: can you recommend a function call to start looking at?
<ogra> DanaG, why =
<ogra> s/=/?/
<DanaG> So you can get them over stdout.
<DanaG> Or is it not possible to lose jasper.log anyway?
<DanaG> Say the thing fails in some way that makes you unable to retrieve the log... can that even happen?
<robclark> prpplague: hang on, I'll swing by
<ogra> DanaG, it cant get lost but in some stages it can get hard to access the log
<prpplague> robclark: thanks
<DanaG> Ah, pidgin died: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/622831
<ubot2> DanaG: Error: Bug #622831 is private.
<DanaG> ah
<DanaG> Would pidgin bug logs have passwords?
<DanaG> ah yeah, the core dump has my irc password.
<ogra> GrueMaster, so the oem-config fix works fine, as soon as dyfet has fixed telepathy-glib the images should build again and we should have a working install process again
<rsalveti> cool, finally :-)
<ogra> and oem-config has a cute panel now
<ogra> which suspiciously looks like upanel
<ogra> (the thing we dropped because DX didnt provide the code for it)
<ogra> anyway
 * ogra calls it a day
<GrueMaster> cool
<GrueMaster> ogra: I'm going to be spending the day trying to figure out how I am going to manage 3 new platforms into my office layout.  Should be ready for testing later today.
<prpplague> robclark: looks like i can replicate that problem with the dvi display
<mythripk> rsalveti: Timings supported by omap4 are based on functional spec and max /supported pixel clock values that can be generated by hdmi pll
<rsalveti> mythripk: hm, ok
<rsalveti> mythripk: I was thinking about omap 3, how can we check the supported timings?
<mythripk> rsalveti:not all omap4 timings are supported by omap3,it  has limited set of timings is what i believe ,I can check with pulukuru,srinivas in case you dont have his contacts and get back to you.
<rsalveti> mythripk: nice, that would for sure help :-)
<rsalveti> because then we can try to identify the best supported video mode for omap 3
<robclark> prpplague: oh good.. I can swing by in a bit
<mythripk> rsalveti:720P is the maximum supported timing in omap3 is what im aware of.. other timings i need to confirm
<rsalveti> mythripk: hm, I thought it would support higher timings
<rsalveti> mythripk: but please, confirm it if possible :-)
<mythripk> rsalveti : confirmed max omap3 supports is 720P
<ynezz> I think, that you can do 1080i/1080p@30 on beagle
<rsalveti> ynezz: the pixel clock seems to limit you
<rsalveti> mythripk: nice, thanks
<ynezz> rsalveti: yes, it depends on TV/monitor also, if it can do lower sync rates
<ynezz> but I've read, that somebody was able to run 1080p30 at beagle
<rsalveti> ynezz: cool
<ynezz> http://markmail.org/message/b7fii2z6qcf3di3x
<ynezz> heh, I'm blind or need more cofee, but where could I enter here new bug/feature request? :-) https://bugs.launchpad.net/~beagleboard-kernel
<GrueMaster> ynezz: If you wish to file it as a bug against the Ubuntu kernel for omap3, file it against linux-image-omap.  Use linux-image-omap4 for omap4 kernels.
<GrueMaster> Mark importance as wishlist.
<GrueMaster> Oops, excuse me, that should be linux-ti-omap & linux-ti-omap4.
<ynezz> ah, thanks :)
<ian_brasil_> is there a mobile meeting tomorrow?
<rsalveti> ian_brasil_: yep, every week
<rsalveti> ian_brasil_: 9 am for you, I guess
<ian_brasil_> rsalveti: thx
<DanaG> weird... plymouth doesn't work on the beagleboard.
<DanaG> ah, I see... it won't splash if serial console is present.
<lool> ogra: FYI libnih built fine
<DanaG> Weird... flash-kernel hangs the board at "erasing kernel NAND space..."
<DanaG> er, wait, it unfroze.
<rsavoye> to upgrade to maverick but leave the kernel, uboot, and firmware alone on a iMX51, is using update-manager a stupid idea ?
<DanaG> It's spewing: [ 6632.227600] uncorrectable error :
<DanaG> [ 6631.614959] Buffer I/O error on device mtdblock3, logical block 124
#ubuntu-arm 2010-08-24
<ogra> lool, merci :)
<lag> ogra: Why is my file system becoming fried when I install my own kernel on OMAP3 daily build?
<ogra> no idea, must be a kernel bug :P
<lag> fsck from util-linux-ng 2.17.2
<lag> /dev/mmcblk0p2: The filesystem size (according to the superblock) is 533515 blocks
<lag> The physical size of the device is 532153 blocks
<lag> Either the superblock or the partition table is likely to be corrupt!
<ogra> which filesystem exactly ?
<lag> Don't be silly
<ogra> ah, not the vfat
<lag> Nope
<ogra> is that after or before installation ?
<ogra> i.e. after or before the autoreboot
<lag> I dd, mount, put on my initrd-uimage-boot.scr, umount, boot
<lag> I'll get you the full log
<ogra> you shouldnt have an fsck at all at that stage
<ogra> i dont get why you (or lool) even get one
 * lag *shrugs*
<ogra> the fsck should only happen after the partition table was newly written and the automatic reboot happened
<lag> It's your toy, you tell me
<ogra> until the reboot there is no fsck at all
<lag> Clearly there is
<lag> I didn't know it was happening to lool too
<ogra> did it even reboot ?
<lag> AFAIK it happens on first boot
<ogra> right, i hear you, *did it reboot at some point*
<rcn-ee> first boot? you have 'fixrtc' set right in your bootargs?
<ogra> rcn-ee, isnt needed on first boot anymore
<ogra> only on subsequent ones
<lag> http://paste.ubuntu.com/482869/
<lag> That's my boot.scr
<ogra> if it gets to an fsck before rebooting, then something with the reboot is wrong
<ogra> which in tunr points to either a busybox or kernel bug
<rcn-ee> anyreason for no 'ro' in that? or isn't that needed anymore either?
<ogra> rcn-ee, it gets changed after first reboot
<ogra> jasper rewrites the kernel cmdline
<lag> So there's nothing wrong with my boot.scr?
<ogra> jasper does: kick in in initramfs *before* anything gets mounted, then repartitions according to teh SD size, reformats the vfat completely, grows the rootfs to full size, touches the last mouted stamp on the FS, mounts it, does some setup and then reboots into oem-config
<ogra> *before* oem-config runs, the system does its first fsck
<lag> http://paste.ubuntu.com/482871/
<rcn-ee> ah, cool..
<lag> ogra: Where does Jasper get it's kernel from?
<ogra> from the vfat
<lag> "reformats the vfat completely"
<ogra> right for that part it pulls it from /boot
<lag> So if I want to test another kernel, I have to put it in there too?
<ogra> the booting kernel is the uImage, the kernel after first reboot is a new uImage from /boot
<ogra> yeah
<lag> Great!
<ogra> but your initrd seems strange in that log
<lag> It's one I built
<ogra> aha
<lag> What's wrong with it?
<ogra> its missing jasper completely
<lag> Ahhhhhhhhhh
<ogra> you should see a lot of jasper messages after line 260
<asac> ogra: is omap4 in good state?
<lag> You certainly know how to make my job difficult don't you?
<ogra> the first part of jasper is a local-premount script and is still very niosy
<ogra> asac, no
<ogra> asac, nothing is in a good state atm
<asac> would anyone of you be able to test an image if we produced one at some point for us?
<asac> just headless -> on sd ... booting -> done ;)
<asac> not now ... in a few days
<ogra> telepathy-glib prevents image buiolding currently and oem-config is broken (upload pending)
<asac> we dont have omap4 atm :((
<lag> asac: Yes
<ogra> asac, sure, no prob, just ping me with an url once you have iot
<asac> good stuff ...
<asac> ogra: could you give me the mkimage paramaters ;)?
<asac> parameters ... damn my fingers never get it right
<lag> ogra: What am I going to do about this? Is it just a matter of installing Jasper? Or are there other hidden nasties that you've implemented?
<ogra> asac, they are the same as for omap3
<asac> ogra: and if possible a good boot cmdline ;)
<asac> ok good for the uimage
<ogra> lag, have a chroot with jasper in it and run update-initramfs there
<ogra> mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Ubuntu Kernel" -d "$uboot_input_kernel" "$uboot_kernel"
<ogra> mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0 -e 0x0 -n "Ubuntu Initrd" -d "$uboot_input_initrd" "$uboot_initrd"
<ogra> from the debian-cd script
<ogra> asac, ^^^
<ogra> asac, and see lag's paste above for a boot.scr
<ogra> oh, wait, thats omap3
<asac> ogra: ok found it
<asac> oh
<asac> ;)
<asac> looked really too similar ;)
<ogra> asac, http://paste.ubuntu.com/482874/
<ogra> thats better
<lag> ogra: How do you install Jasper?
<ogra> uboot_kernel_addr="0x80000000"
<ogra> uboot_ramdisk_addr="0x81600000"
<ogra> lag, apt-get install jasper in the chroot you use
<asac> board_opts="mem=463M"
<asac>  ?
<ogra> yeah, needed
<asac> thanks
<lag> Tried that
<lag> E: Unable to locate package jasper
<ogra> lag, its in main
<ogra> lag, only in maverick though
 * lag had an empty sources.list file
<lag> Err http://uk.archive.ubuntu.com maverick/main armel Packages
<lag>   404  Not Found [IP: 194.169.254.10 80]
<lag> Doh
<lool> ogra: I told you that size of the fs issue would bite you in real life!!
<ogra> lool, no, it wouldnt if jasper would be executed
<ogra> lool, you didnt by chance keep a log from your broken boot test, did you ?
<lag> ogra: Why isn't it finding the armel packages?
<lag> http://194.169.254.10/ubuntu/dists/maverick/main
<lag> ?
<ogra> lool, the point is that the initial rootfs is never used or touched, the whole thing gets adjusted before any fsclk, mount or other filesystem operations happen, while the corruption is ugly it *must* be gone after jasper has run
<ogra> so it shouldnt affect anyone unless jasper doesnt run
<ogra> lag, you want pool
<lag> ?
<lag> Instead of dists?
<lool> ogra: I suspect resize2fs is running fsck or some equivalent
<lool> ogra: I don't think it's the boot triggering fsck
<lool> ogra: I'm not sure it's clear, but the issue seeems to indicate a corrupted to start with!!
<lag> ogra:
<lag> deb http://uk.archive.ubuntu.com/ubuntu/ maverick main restricted universe multiverse
<lag> deb-src http://uk.archive.ubuntu.com/ubuntu/ maverick main restricted universe multiverse
<ogra> lool, jasper runs an fsck thats fully redirected to the logfile *right after* the new partitions were written
<ogra> lool, there is no way that you see *any* error message from that if jasper ran successfully ... and *after* jasper ran there shouldnt be any corruption anymore
<ogra> my point is that the corruption will not affect the actually installed filesystem
<ogra> i ageree that it needs to be fixed, but of the setup worked right you will never ever be able to even get any info about that corruption apart from jasper.log
<lag> ogra: Are those sources.list entries correct?
<ogra> if you *see* an fsck during boot, something went completely wrong (i.e. jasper wasnt executed, you didnt use a 4G SD card etc)
<ogra> lag, no, needs to be ports.ubuntu.com
<lag> k thanks
<ogra> the ports archive isnt mirrored
<persia> lag, s|uk.archive.ubuntu.com/ubuntu|ports.ubuntu.com/ubuntu-ports|
<ogra> oh, right
<ogra> i missed /ubuntu-ports
<persia> Rather, nobody has yet announced a public URL with a mirror.  There exist some number of mirrors that aren't announced (I know of at least 4, but none better for the UK than ports.ubuntu.com)
 * ogra knows one 
<ogra> but i guess there is a reason thats not announced anywhere
<lag> ogra: It's in your house?
<persia> I can't speak for anyone else, but I haven't announced mine because I don't serve it from a stable IP.
<ogra> lag, nah :)
<lag> ogra:
<lag> The following NEW packages will be installed:
<lag>   apt-xapian-index aptitude bc bogl-bterm consolekit cpp cpp-4.4 cryptsetup dbus defoma devio dmraid dosfstools ecryptfs-utils flash-kernel
<lag>   fontconfig fontconfig-config gcc-4.4-base gconf2-common gettext-base gir1.0-glib-2.0 hicolor-icon-theme hwdata iso-codes jasper keyutils
<lag>   language-selector-common laptop-detect libasound2 libatk1.0-0 libatk1.0-data libavahi-client3 libavahi-common-data libavahi-common3
<lag>   libboost-iostreams1.42.0 libbsd0 libcairo2 libcanberra-gtk-module libcanberra-gtk0 libcanberra0 libcheese-gtk18 libck-connector0
<lag>   libclass-accessor-perl libcroco3 libcups2 libcwidget3 libdatrie1 libdbus-glib-1-2 libdebconfclient0 libdebian-installer4 libdmraid1.0.0.rc16
<lag>   libecryptfs0 libeggdbus-1-0 libept1 libexpat1 libffi5 libfontconfig1 libfontenc1 libfreetype6 libgconf2-4 libgcrypt11 libgdbm3 libgdk-pixbuf2.0-0
<lag>   libgirepository1.0-1 libgmp3c2 libgnome-desktop-2-17 libgnutls26 libgpg-error0 libgssapi-krb5-2 libgstreamer-plugins-base0.10-0 libgstreamer0.10-0
<lag>   libgtk2.0-0 libgtk2.0-bin libgtk2.0-common libgudev-1.0-0 libice6 libicu42 libidl0 libio-string-perl libiw30 libjasper1 libjpeg62 libk5crypto3
<ogra> god !
<lag>   libkeyutils1 libkrb5-3 libkrb5support0 libldap-2.4-2 libltdl7 libmpfr4 libnspr4-0d libnss3-1d libogg0 liborbit2 libpam-ck-connector libpango1.0-0
<persia> !paste
<ogra> use a pastebin !
<lag>   libpango1.0-common libparse-debianchangelog-perl libparted0debian1 libpixman-1-0 libpolkit-gobject-1-0 libpython2.6 librsvg2-2 libsasl2-2
<ubot2> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<lag>   libsasl2-modules libsigc++-2.0-0c2a libsm6 libstartup-notification0 libsub-name-perl libtasn1-3 libtdb1 libthai-data libthai0 libtiff4
<lag>   libtimedate-perl libvorbis0a libvorbisfile3 libx11-6 libx11-data libxapian15 libxau6 libxcb-atom1 libxcb-aux0 libxcb-event1 libxcb-render0
<lag>   libxcb-shm0 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxdmcp6 libxext6 libxfixes3 libxfont1 libxft2 libxi6 libxinerama1 libxml2 libxrandr2
<lag>   libxrender1 lsof make oem-config oem-config-debconf os-prober parted perl perl-modules python-apt python-cairo python-dbus python-debian
<lag>   python-gobject pyt
<lag> Argggggggggggggggggggggggggggggggggggggggggggggggggggg
<lag> Paste bin is not as much fun!
<ogra> heh
<persia> Yeah, but not using one reliably makes me go fiddle with IRC commands :p
<ogra> anyway, jasper depends on oem-config indeed
<lag> persia: I noticed
<lool> ogra: Again, I'm not sure you see that the problem is *earlier*
<ogra> the other deps you see are all oem-config deps
<lool> ogra: I'm pretty sure the issue is that the fs in the image itself is truncated
<lool> whatever you do starting from there is bound to suffer from the corruption
<ogra> lool, well, but where did your fsck come from ?
<ogra> there is no technical possibility that you ever see any output of fsck if jasper ran
<lool> ogra: My understanding is that jsaper does a resize2fs
<ogra> lool, jasper runs completely silently *all* output of any subcommands is redirected to a logfile
<lool> Well I still got some output apparently
<ogra> if jasper ran there cant be any discrepancy between the partitioning and the fs anymore
<lool> Note that your pipe + read might not be enough to stop commands from writing to /dev/tty
<lag> What type of bot is ubot2?
<ogra> since the rootfs partition was resized (no matter of the corruption or not, sfdisk doesnt care)
<ogra> lool, well, then someone must have secretly uploaded a changed jasper :) we had various bugs and breakages that caused fsck errors that only show up in the log
<ogra> i wouldnt know why that suddenly would change and ignore a redirect of stderr and stdout
<lool> Well it's just a guess
<ogra> well, my guess is that jasper didnt run at all for you
<lool> either the fs is corrupted in the image, or it gets corrupted in the resize
<lool> ogra: http://people.canonical.com/~lool/fsck.png
<ogra> lool, there is no initramfs output at all
<lool> ogra: It's earlier
<lool> ogra: But I can't scroll back
<ogra> do you have a shot of that too ?
<lool> Let me try with serial console
<ogra> ah, darn
<lool> ogra: is there a way to turn serial console output during boot?
<ogra> only by changing boot.scr on the vfat
<ogra> as long as plymouth breaks once console= is set we cant make it a default else we wont have any splash anymore
<ogra> (second boot is completely with splash etc)
<lool> ogra: Can you give me the commands to run to type in u-boot?
<ogra> one sec
<lool> I don't have a boot.scr nearby
<ogra> fatload mmc 0:1 0x80000000 uImage
<ogra> fatload mmc 0:1 0x81600000 uInitrd
<lool> So I'm on the serial line
<lool> ** Unable to use mmc 0:1 for fatload **
<lool> mmc init
<ogra> sh, indeed
<ogra> s/sh/ah/
<lool> Ok, this is done
<lool> Now the tricky part
<ogra> setenv bootargs vram=12M omapfb.mode=dvi:1280x720MR-16@60 console=ttyS2,115200n root=/dev/mmcblk0p2 fixrtc
<ogra> bootm 0x80000000 0x81600000
<lool> thanks, booting
<lag> ogra: !paste
<lag> Lol
<lag> :D
<ogra> :P
<lool> I get kernel output on serial console at least
<lag> ogra: So now I have Jasper installed, when I run my usual script to build an initrd, Jasper will just appear in there yes?
<ogra> if jasper is inside the chroot you run upadte-initramfs in it will end up inside the initrd, yes
<lag> Jasper is installed in the chroot, yes
<ogra> well, then it should end up in your initrd
 * lag crosses fingers
<lool> ogra: http://paste.ubuntu.com/482895/
<ogra> lool, it doesnt reboot after line 30 ?
<lool> ogra: no
<ogra> aha
<ogra> thats one of the issues, can you try booting a second time ?
<lool> that will behave differently
<ogra> right
<lool> ogra: I'm quite busy for doing long testing; would you be interested in looking into it with qemu?
<lool> it's not hard to reproduce in qemu
<ogra> lool, also /var/log/jasper.log would be intresting
<ogra> well, using these images in qemu will require a lot of tinkering with images in advance
<lool> ogra: Why is that?
<ogra> because the FS needs to actually be resized
<ogra> if you just boot the img file there is no spare space
<lool> Yes, which exposes this bug which apparently other people are seeing
<ogra> so you would need to create a 4G image and dd the img file into it to have the proper way
<lool> As I noted in email, if I append some zeroes at the end of the image, I don't get this issue
<lool> like 10 MBs or so
<ogra> yes, the bug is on antimony side though
<lool> ogra: It's trivial to add space to the QEMU SD backing image...
<lool> dd if=/dev/zero bs=1024 count=10240 >> /tmp/maverick-preinstalled-netbook-armel+omap.img
<ogra> but it shouldnt appear if there is space to resize to, the resizing "fixes" the filesystem
<ogra> thats why we dont see it (apart from jasper.log) on real installs
<lag> Has the meeting been cancelled?
<ogra> lag, nope
<lool> ogra: Ok; I have other things to work on and I'm not blocked by that bug; I found it relevant to share what I believe is a bug in the Ubuntu images exposed by testing in QEMU, but it's time consuming for me to make my point and I have tons of other things to look into, sorry
<ogra> lool, yeah, understood, thanks for pointing it out
<lool> I can share the recipe to reproduce, but you don't seem interested in resolving what appears to me as a bug in the jasper scripts
<ogra> its not in jasper
<ogra> the FS is apparently corrupt without resizing
<ogra> which means its corrupt at creation time
<ogra> and thats surely something i'll look at
<ogra> what is worrying me more though is that the reboot doesnt work
<lag> ogra: When I build my own initrd, do I have to execute depmod at any stage? If so, what stage?
<lool> ogra: Well I'm not entirely sure it's corrupt at image creation time
<ogra> update-initramfs does that iirc
<lool> ogra: jasper resizes the partitions before calling resize2fs, to it might get that part wrong...
<ogra> lool, only your jasper.log could tell :)
<ogra> but after you sent me that mail i checked a jasper.log and i see corruption there
<lool> ogra: Well perhaps you can reproduce in QEMU and dig the info you need?  It's not hard, the .debs are pre-built, wont mess your other qemu, and you just need a maverick daily image to try out
<ogra> lool, i will
<lool> NCommander: I've just pasted the bug id on #linaro, but you don't seem to be in there
<lool> NCommander: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/623375
<ubot2> Launchpad bug 623375 in initramfs-tools (Ubuntu) "Skipping the bootloader installation when creating rootfs or installation media (affects: 1) (heat: 8)" [Undecided,New]
<ogra> lool, i pointed him to it in the arm meeting
<NCommander> lool: yeah, I saw that. Whoops on my part, though ideally, we shouldn't directly run update-initramfs in a chroot either
<lool> NCommander: I don't see an issue with running update-initramfs in a chroot, in fact it's the only way to generate an initrd
<lag> ogra: ?
<ogra> lag, ?
<lag> Look up
<ogra> <ogra> update-initramfs does that iirc
<NCommander> lool: I meant run it if a trigger calls it; we should run it if the user calls it directly. Obviously the generic bit of generic subarch detection is a bit too generic :-)
<ogra> look up too ;)
<lool> NCommander: I don't think we want to run flash-kernel though
<lool> Which is what the bug is about
<NCommander> lool: I think we can detect the chroot via a syscall (I remember there's a way to do it in C), and then we can adjust what we do based off that
<ogra> lool, before NCommander changed it it wouldnt have executed :)
<lag> <ogra> lag: update-initramfs does that iirc
<lag> :)
<ogra> lool, https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-maverick-arm-improved-subarch-detection
<NCommander> ogra: right, since flash-kernel --supported would have ailed
<NCommander> *failed
 * NCommander needs a new keyboard
<lool> NCommander: it's a bad idea to detect the chroot
<lool> NCommander: d-i and ubiquity will install into /target, where you do want flash-kernel to run
<NCommander> lool: we can have special logic in flash-kernel-installer to simply manually call flash-kernel and work around the problem.
<NCommander> but point taken
<NCommander> lool: what do you suggest for a solution?
<lag> ogra: http://paste.ubuntu.com/482907/
<ogra> lag, cool !
<lag> How is that cool?
<ogra> it works
<lag> ogra: FATAL: Could not load /lib/modules/2.6.35-18-omap/modules.dep: No such file or directory
<ogra> ignore that, you get to ubiquity-dm
<ogra> (which doesnt start because of a bug in oem-config)
<lag> I don't want to ignore that
<lag> I want to fix that :)
<lag> ogra: -^
<lool> NCommander: well it was discussed in the bug already
<NCommander> lool: I haven't had a chance to read it. LP from China is ... interesting
<lool> NCommander: Oh you're there already, how is it?
<lool> Chinese?
<ogra> lost of meo-burgers :)
<NCommander> lool: I've been here for a little over a week and a half :-)
<ogra> *meow
<NCommander> ogra: that's vietnam
<NCommander> ian_brasil: so, I admit, I haven't looked at the liquid stuff in-depth. Do you have a seed yet?
<ian_brasil> yes
<NCommander> (or a metapackage, but a seed is preferable)
<NCommander> oooh
<NCommander> handy
<GrueMaster> ogra: you really should watch food network sometime.  You'd know that in china, dog is the meat of choice.
<NCommander> ian_brasil: so if I build a chroot, and then do apt-get install kubuntu-liquid^, everything works?
<ian_brasil> no
<NCommander> ian_brasil: it doesn't?
 * NCommander admits he's not sure what your seed name is
<ian_brasil> no ..we dropped the liquid name
<ian_brasil> liquid was just a code name
<NCommander> ian_brasil: oops, I'm out of the loop >.<;
<ian_brasil> damn..fire alarm..back in a minute
<ian_brasil> excitement over
<ian_brasil> NCommander: the meta package is kubuntu-mobile
<ian_brasil> https://edge.launchpad.net/ubuntu/maverick/+package/kubuntu-mobile
<NCommander> ian_brasil: heh
<NCommander> ian_brasil: right, next step is to modify livecd-rootfs to add it as an image target
<NCommander> ian_brasil: its pretty straightforward on where the edits have to be made. Only thing is you want to pull by task, and not metapackage
<ian_brasil> ok
<ian_brasil> we have done that before i seem to remember
<ian_brasil> NCommander: i will ping you when that is done
<mopdenacker> ogra: Hi! I was wondering what OMAP3 boards you support in your OMAP prebuilt images. Just the Beagle board?
<ogra> cureently just the beagle, yes
<NCommander> ian_brasil: thanks. I can't merge or do the upload, but I can guide you with the edits and doing some initial testing
<mopdenacker> ogra: all right, thanks!
<ogra> mopdenacker, iegp2 might work if you have a special u-boot, gumstix too
<ogra> ootb only beagle though
<rsalveti> mopdenacker: ogra: xm should also work, but we have a mmc issue
<ogra> err, indeed, i counted that as beagle :)
<rsalveti> ogra: there are just too many different beagles at the marked hah
<rsalveti> b, c, XM
<ogra> C4 and XM are the ones we'll support by release day
<rsalveti> sure
<ogra> b will likely have issues to even boot
<rsalveti> hehe, probably
<ogra> at least our current images
<rsalveti> unless we get a minimal image, no way to support it
<rsalveti> even for simple boot
<ogra> right
<rsalveti> mine is running well with a simple rootstock fs
<GrueMaster> ogra: Any chance of building an alt-inst image?
<ogra> GrueMaster, nope
<GrueMaster> ok.
<rsalveti> ogra: I commented at the ureadahead bug, it doesn't make any difference for us
<rsalveti> I checked that
<ogra> GrueMaster, we are fully focused on preinstalled images and would have no way to support systems without NAND in a sane way atm
<rsalveti> but let's wait for the new rewrite
<rsalveti> and it doesn't make any sense to run until we get OOM, doesn't help at all
<ogra> rsalveti, yeah, i talked to Keybuk already this morning (thats why he commented on the bug)
<GrueMaster> ogra: ok.
<rsalveti> ogra: I saw that, and at the time I got to irc he wasn't there anymore
<ogra> GrueMaster, would be good to probably address that in N
<ogra> oh, he dropped again ... ? bah
<GrueMaster> ogra: What about a preinst-min image?
<rsalveti> ogra: so let's wait for the new version, then we can test
<ogra> GrueMaster, requires time i dont have
<GrueMaster> Minor mods needed.
<rsalveti> but I doubt it will make any difference
<ogra> no, massive mods needed
<GrueMaster> Ok, just a suggestion.
<ogra> thats the prob
<rsalveti> but will be happy to be wrong
<ogra> there apparently is a base image already that has been implemented for special purposes
<ogra> to change that requires a ton of changes
<ogra> (it doesnt build an image, just a base tarball for local testing purpose)
<ogra> GrueMaster, i'd love to have it, but the current quality of the images we actually have makes me thing that i wont find the time
<ogra> *think
 * ogra gest some coffee
<GrueMaster> Actually, if we had them, it might be easier to debug netbook image issues.
<GrueMaster> And daily image testing could continue at a limited pace.
 * GrueMaster remembers making this same arguement months ago.
<rsavoye> so I have a new imx51 "SmartTop" system sitting here I want to upgrade to maverick. Will it break ?
<ogra> GrueMaster, yes, and i said "i'd love to have them but i dont know if i have the time"
<ogra> rsavoye, no idea, we dropped imx51 support with lucid
<rsavoye> bummer. Can I upgrade and leave the kernel alone ?
<ogra> mater of luck i guess
<rsavoye> it's running karmic now
<GrueMaster> rsavoye: You'd need to bump the kernel.  Karmic was Armv6+vfp.
<GrueMaster> Might be as easy as copying the config and rebuilding.
<ogra> it might be possible to run v7 userspace with a v6 compiled kernel, not sure
<ogra> as long as your userspace is all v7
<ogra> i'D just keep a backup of the original system and try it :)
<rsavoye> so to do the user space hack, I'd just change sources.list?
<ogra> yes
<rsavoye> guess I'll let you know :-)
<ogra> but really, keep a backup !
<rsavoye> it's fresh hardware, so nothing to loose
<ogra> GrueMaster, our buildds were all running v5 compiled kernels until we got the babbage boards in the DC
<ogra> there were issues but i dont know if they were caused by v5 vs 6/7
<rsavoye> is ther an easy way to block upgrading the kernel when I upgrade everything else ?
<ogra> it shuldnt upgrade the kernel unless you already have an ubuntu kernel package
<ogra> which i doubt
<rsavoye> cool, I'll give it a try
<mopdenacker> rsavoye: I confirm. I use Lucid on my IGEPv2 board, and everything gets updated, except my custom kernel.
<GrueMaster> rsavoye: YOu can try to do a dist-upgrade, but cancel when it asks to continue.  Then do a manual install on individual packages.
<rsavoye> dist-upgrade or update-manager -d ?
<ogra> both should work
<ogra> or do-release-upgrade
<ogra> (the cli version of update-manager)
<rsavoye> ah, I'll try that
<mopdenacker> ogra: did you solve your issue with the latest preinstalled images? I'm asking because we need to make our own for our internal releases, and I need your howto on this...
<ogra> mopdenacker, half of it
<mopdenacker> ogra: thanks for the status update. Good luck with the second half!
<ogra> mopdenacker, second half is a package failing to build which keeps us from rolling images atm we're trying to get that fixed asap
<ogra> hey devilhorns
<devilhorns> hi ogra :)
<ogra> just sent a mail your way :)
<devilhorns> oh super :)
<devilhorns> guess yesterday was just bad timing :)
<ogra> yeah
<devilhorns> hehehe
<ogra> which TZ are you in ?
 * ogra is in europe
<devilhorns> EST
<devilhorns> in america
<devilhorns> east coast
<bench_adidas> hi, what kind of hardware can you use ubuntu on?
<bench_adidas> can you give me a system example?
<ogra> ah, east coast is fine, the time you replied looked more like asian morning to me :)
<devilhorns> ogra, k, just got the mail
<ogra> great
<ogra> davidm, meet devilhorns
<ogra> :)
<robclark> rsalveti: I sent you a uImage..
<hrw> bench_adidas: omap3, omap4, i.mx51
<devilhorns> ogra, well, was up late last night talking to raster :) and working on some code
<robclark> it will either not boot at all, work perfectly, or something in between ;-)
<devilhorns> hi davidm :)
<bench_adidas> can i get a system example please?
<ogra> bench_adidas, C4 beagle board will work with 10.10, marvell dove and freescale babbage too
<bench_adidas> is there one? an example or is this topic the new sh!t
<ogra> err 10.04
<bench_adidas> ?...
<bench_adidas> ah! cool!
<ogra> the dove isnt on sale and the babbage is really expensive
<devilhorns> ogra, typing up a response now wrt that email :)
<ogra> devilhorns, awesome :)
<bench_adidas> babbage is named after a character eh!
<ogra> likely, ask freescale marketing dept. :)
<bench_adidas> OMAP3 processor <<< only uses 2 watts?
<ogra> its ARM, sure :)
<bench_adidas> ogra, r u supposed to be a computr architech?
<ogra> me ?
<bench_adidas> oh-gra!
<ogra> i'm a software integrator ...
<bench_adidas> ive never herd of software inegrator
<ogra> stealing work from others and making OSes out of them :)
<devilhorns> lol
<davidm> hello devilhorns
<devilhorns> hi davidm :)
<davidm> I'll look forward to your response to ogra's email
<devilhorns> :) about to send it now
<devilhorns> ogra, in my day, we called that Systems Integration :)
<ogra> yeah, probably the better term :)
<devilhorns> :)
<bench_adidas> bye channel. thanks
<rsalveti> robclark: thanks, will try now
<rsalveti> was at lunch :-)
<robclark> cool
<rsalveti> GrueMaster: and your es2, how is it going?
<GrueMaster> Had to clean up a large area of my office yesterday to accommodate it along with my XM & Dove.  Just getting the final wiring in place now.
<GrueMaster> I did manage to get it booting to X and netbook-launcher-efl Friday.
<rsalveti> cool
<rsalveti> hopefully we're getting ours next week
<rsavoye> hope your XM board works better than mine...
<rsalveti> mine only works with mem=256M :-)
<rsalveti> but it's a P8
<rsavoye> oh well, looks like I just wedged my imx51 board :-( Time to start over
<rsalveti> rsavoye: if you got the kernel and the boot loader working, I'd suggest you to generate a rootfs with rootstock
<rsalveti> just a minimal, so you can get something to work with maverick
<rsavoye> it hangs after "init crypto disks"
<rsalveti> maverick?
<rsavoye> this was after upgrading to maverick user space on the karmic kernel
<ogra> rsavoye, on a serial console ?
<ogra> you might not have serial getty enabled
<ogra> (doesnt happen by default)
<rsavoye> hdmi monitor
<ogra> ah, k
<rsavoye> I guess I should pop the cover off the SmartTop an insatll the serial dongle
<ogra> well, it should work on a monitor for sure
<rsavoye> that's what I hoped
<ogra> also its weird that you have crypto disks installed
<rsavoye> I get a bunch of boot messages then it hangs
<rsavoye> I don't think I did, not sure where that came from
<ogra> i think thats only kept by the installer if you actually chose to encrypt your homedir
<rsavoye> al I did was an upgrade :-)
<ogra> well, its an upgrade
<rsavoye> no user dir beyond the default one
<ogra> *someone* picked to install it :)
<rsavoye> poltergists are hell...
<ogra> hehe
<rsalveti> robclark: well, the display works :-)
<rsalveti> robclark: can see 2 penguins and the boot log
<rsalveti> but got stuck after udev
<rsalveti> but I only got your uImage, so could be missing modules and stuff
<rsalveti> robclark: which tree is this one?
 * prpplague looks around for a blue box
<devilhorns> ol
<devilhorns> err lol
<devilhorns> dunno what happened to the first L there
<devilhorns> ogra, around ?
<devilhorns> ogra, ok, well when you get this, could you email me a list of packages that I will need to focus on ? Obviously the standard EFL libs and such, but not sure what other ones there may be. Thanks :)
<robclark> rsalveti: prpplague found something interesting..
<robclark> I'd been enabling only one 1fb.. but when 2nd fb is enabled then it doesn't work
<robclark> so I think we have something to go on now
<rsalveti> hm, ok
<prpplague> rsalveti: all of th e patches work, but when only 1 fb is enabled
<robclark> rsalveti: try with your existing kernel tree.. and change # of fb's to 1..  which I think you can even do w/ a bootarg
<prpplague> rsalveti: you can change the .config to turn those off
<rsalveti> prpplague: robclark: interesting, will try
<robclark> prpplague, rsalveti: I see what the issue is.. will have a fix in a bit
<robclark> basically fb1 gets updated with new size, instead of fb0
<robclark> but I'm not completely sure if it is the same issue that rsalveti sees..  with this issue, you'd still see scrambled picture, rather than no picture
<robclark> brb
<prpplague> robclark: well it depends on the display, some displays won't even display the scrambled picture to do incorrect data
<robclark> prpplague: hmm.. from display standpoint, the signal timings should be good.. so from monitor's point of view the picture is just fine.. the user is just looking at some abstract art ;-)
<robclark> (well, ok, you could run into some issues switching from lower to higher resolution, if you've exceeded the size of your framebuffer)
<prpplague> robclark: so you found the code issue?
<robclark> yeah.. basically the wrong framebuffer gets resized
<robclark> should be fixable
<prpplague> robclark: what does it do, just assume it is the last framebuffer available?
<robclark> seems to be
<rsalveti> makes sense
<robclark> yeah, basically each fb shares same dssdev instance.. so when second fb registers it overwrites the first fb's callback
<rsalveti> cool, nice catch
<Baybal> hi
<Baybal> do you have accelerated X on omap3 already?
<rsalveti> Baybal: you have the sgx package, but it's not yet integrated at X11 as we have for n900
<prpplague> rsalveti: did you get a chance to test the kernel with 1fb?
<prpplague> mopdenacker: greetings
<rsalveti> prpplague: not yet, needed to debug another issue
<rsalveti> will do in some minutes
<prpplague> rsalveti: np, just checking
<mopdenacker> prpplague: hi!
<GrueMaster> ogra_cmpc: Still up?
<ndec> rsalveti: what do you mean by 'we have the sgx package on omap3'? do you mean a ubuntu package or the TI tar ball?
<rsalveti> ndec: just tar ball, we're still waiting for the official deb :-)
<ndec> rsalveti: too bad ;-) that would have been better for me ;-)
<rsalveti> haha :-)
<rsalveti> prpplague: robclark: sorry for taking so long, but I can confirm that it works when I compile the kernel with just one framebuffer
<rsalveti> with robclark's patches on top of ubuntu kernel
<prpplague> rsalveti: dandy
<robclark>  oh goody :-)
 * robclark is working on better patch to support multi fb
#ubuntu-arm 2010-08-25
<DanaG> Weird... trying to use a pl2303 usb-serial ON the beagleboard... and it's giving me garbage.
<DanaG> pl2303_process_read_urb - tty_flag = 0
<DanaG> Hï¿½Hï¿½H
<DanaG> say, what's the practical difference between 2.6.35-17 (ubuntu) and 2.6.35-1002 (linaro)
<rsalveti> not much for now, I'd say
<rsalveti> but need to check the kernel tree
<DanaG> hmm, stupid pl2303 gives garbage on my beagleboard.
<DanaG> Say, if I'm using an aufs overlay, is there any advantage to having the underlying FS be ext4 instead of ext3?
<Baybal> yes
<Baybal> it would be faster
<persia> DanaG, Depends on what you're accessing.  If you're accessing stuff on the base FS, you'll get the normal advantages of ext3 vs. ext4.  If you're accessing stuff on the overlay, you won't see any difference between the two.  For most uses of union filesystems, actual usage is a mix of both.
<DanaG> ah, I don't even remember now what the advantages of the base were. =/
<persia> http://en.wikipedia.org/wiki/Ext4 has fairly extensive discussion
<DanaG> ah, checksum is a big one.
<persia> Note that it *only* provides benefits to files unmodified from the base: anything in the overlay will naturally be handled based on the backing-store mechanism used for the overlay (often RAM, but potentially other things)
<DanaG> I've also run into the blockage of hardlinks... http://patchwork.ozlabs.org/patch/52392/
<persia> What is this blocking?  I've played with all sorts of layed filesystems, and never ended up finding this painful.
<DanaG> It was blocking the "SingletonLock" Chromium links to wherever it links.
<persia> With packaged chromium?
<DanaG> Yeah.  Though, there was a new update today... maybe that would've helped.
<persia> My recommendation would be to try to catch fta: there may be a way to get it to work more easily.
<DanaG> Anyway, it only happened when the lock was on the underlying fs.
<DanaG> Say, is there any easy way to make ttyS2 start only if console=ttyS2 is present?
<persia> You could write a custom upstart job...
<DanaG> I need to use that port for other things in 'normal' (read-only) mode -- using the "user" button to boot read-write for servicing.
<DanaG> yeah, though I have no idea of the syntax -- start-on?
 * persia doesn't know modern upstart syntax, not having worked on upstart jobs since jaunty
<persia> My recommendation would be to review already installed jobs for clues, and ask in #upstart once you're sure you know the basics.
<DanaG> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/586386
<ubot2> Launchpad bug 586386 in linux (Ubuntu Maverick) (and 1 other project) "omap3 kernel should hand over all comdline args to the init environment (affects: 1) (heat: 40)" [Medium,Fix released]
<DanaG> Perfect, it's already been done.
<hrw> hi
<cooloney> lag: morning, man
<lag> cooloney: They Bryan
<cooloney> i just pinged sebjan who is still working on the 2.6.35 patches.
<lag> Hey~*
<lag> No problem
<cooloney> it will be available soon.
<cooloney> he helped a lot to fix coding style and duplicated patches. i think
<lag> I'd rather them late and in good order than quickly and in a state
<lag> I don't mind that at all
<lag> Keep up the good work sebjan
<cooloney> after sebjan boots the new kernel on panda, he will send it out.
<sebjan> thanks lag :)
<lag> :)
<ogra> ndec, a ti-team ML for the package maintainer field sounds fine to me
<ndec> ogra: ok. so should I use tiomap-dev team on LP and create a ML with same name?
<ogra> yeah, i think LP offers that
<ndec> ogra: ok. I will do that.
<ndec> ogra: Mailing list requested and queued for approval....
<ogra> perfect !
<ogra> ndec, was there ever a bug filed for your AAC issues ?
<ndec> ogra: no. in fact we are looking at using ffmpeg instead of faac by default. so i don't have any information to open a bug for now.
<ogra> ok
<ndec> ogra: but do you confirm that packages cannot be compiled with neon optimizations by default?
<ndec> ogra: do you really support v7 h/w that does not have neon?
<ogra> if you do neon on a common package you should roll an additional binary with -neon in the name, yes
<ogra> ndec, we support v6 HW that pretends to be v7 and has no NEON, yes :)
<ogra> ndec, ask NCommander :)
<ogra> he maintains the dove stuff
<ndec> ogra: so how do we automatically install these -neon packages in case the hw supports it?
<ogra> hmm, thats hard
<ogra> i think asac had a different idea of using runtime switches
<ogra> so the binary is the same but uses a different codepath if NEON is available
<persia> Can we reliably detect the ability to run neon on a given machine?  If so, hwcap might work.
<ogra> yes, i think asac's idea involved hwcap
<ogra> but he can probably elaborate
<persia> I'd hope it involved something similar to what we did for pango vfp for jaunty, rather than actually patching every source to have multiple codepaths.
<NCommander> ndec: there was going to be some work i was going to suggest in Natty to work towards solving this issue
<ogra> NCommander, the missing NEON on dove ?
<NCommander> ogra: no, having a mechanism in APT tohandle packages on a subarchitecture basis :-)
<ogra> that wont happen i think
<ogra> and it would have to be on dpkg level i think
<ogra> iirc we discussed it before
<persia> And it doesn't help the neon bit anyway: we don't want that: we want opportunistic use of NEON, if available.
<ogra> \o/
 * ogra dances 
<ogra> telepathy-glib builds !
<ogra> (when using -O0 :/ )
<persia> Um, how did you test that?  Everyone is reporting that it builds locally, and only fails on buildds.
<ogra> everyone ?
 * persia has yet to actually replicate the test failures.
<persia> everyone who told me about it.
<ogra> who was that ?
<ogra> it doesnt build with -O2 here or on the porter box
<ogra> one test fails with "invalid utf-8" the other segfaults
<persia> Hrm.  Right then.
 * persia suspects irregular hardware and incorrect environments
<pcacjr> morning
 * ogra files bug 623979 and uploads a telepathy-glib workaround
<ubot2> Launchpad bug 623979 in telepathy-glib (Ubuntu) "telepathy-glib fails to build on armel due to two unsuccessfull selftests (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/623979
<persia> \o/
<ogra> now that were 2 very productive hours to fix that :)
<ogra> finally we can start to prepare for beta
<devilhorns> mmm betas ... tasty :)
<devilhorns> ogra, any news/updates wrt doing the arm work ?
<ndec1> ogra: can we setup the PPA to send notification email to the team list for each upload and build success?
<persia> I think one only gets notification on build failures.
<persia> Or maybe I'm confused.
<ndec1> persia: hi! I did receive an email of build failure for something that was uploaded by someone else. so you might be right
<ndec1> persia: so there is no option to subscribe the team ML to get more notifications?
 * persia is asking
<persia> (for reference, #launchpad is a good place to ask questions about LP)
<persia> ndec1, At least one other user reports they couldn't find any way to get richer notifications.  If you want it, please file a bug against LP (and subscribe me, please).
<ndec1> persia: thx. will do.
<ndec1> persia: Bug #624038 entered. you and ogra are subscribed
<ubot2> Launchpad bug 624038 in launchpad "Team notifications of package upload and build success for PPA (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/624038
<ndec1> persia: cool.. didn't know about the ubot notification ;-)
<persia> ndec1, Thanks.  It may take a while to get implemented, but we now have a place to discuss it :)
<ogra> yeah
<ogra> thanks for that
<suihkulokki> lool: there is a rebased qemu branch in gitorious (omap3-rebase) with your and matts changes included
<lool> suihkulokki: Thanks
<rsalveti> ogra: ndec1: could any of you add me at tiomap-dev?
<rsalveti> I'm also interested on this, once we get the notifications
<lool> suihkulokki: I'm slowly moving this tree under a Linaro umbrella and we have asked one new Linaro starter to look at upstreaming these OMAP3 patches, amongst other things
<ndec1> rsalveti: done
<rsalveti> ndec1: cool, thanks :-)
<ogra> rsalveti, did you research the "Bad Magic Number" issues on omap4 more ?
<prpplague> ogra: it is an issue with the old u-boot
<ogra> seems that really bites us badly now i cant even fatls on the panda atm
<prpplague> ogra: updated u-boot from sakoman works with no issues
<prpplague> ogra: i created a small script to reload the boot partition
<rsalveti> ogra: nops, not yet
<ogra> prpplague, is there an updated 1.1.4 tree anywhere ?
<prpplague> ogra: http://paste.ubuntu.com/483487/   for reloading
<ogra> we're way paste feature freeze and i'm not really eager to change to a different u-boot version
<ogra> prpplague, thats not an option in release images
<prpplague> ogra: no, there isn't a fixed 1.1.4 since the fat driver was re-written
<ogra> sigh
<rsalveti> yep, our version is *very old*
<rsalveti> at least the common u-boot part
<prpplague> ogra: the issue only seems to occur when writing to the boot partition frequently
<rsalveti> that's why no one likes fixing that
<ogra> well, it was the one version that i was told to use
<rsalveti> ogra: probably because at the time sakoman's tree wasn't ready
<ogra> prpplague, it happens on first reboot for me, after install (which writes the new initrd once to the fat)
<ogra> rsalveti, right
<prpplague> ogra: ahh interesting
<ogra> beta freeze is tomorrow and we have a ton of other issues to fix
<ogra> gdm isnt starting either :(
<rsalveti> :-(
<ogra> GrueMaster, ^^^ do we have a bug for that ?
<GrueMaster> Looking.
<ogra> i can run startx and get to a desktop session
<ogra> well, i could before i tried to reboot
<ogra> and do we have a bug for the bad magic number ?
 * ogra digs
<GrueMaster> I'm missing something here.  What am I looking for?
<robclark> ogra: fwiw.. I think the issue updating the fat boot partition with new uImage is actually an issue with linux fat support...  if I write the uImage to an MMC card from macosx I can do it 100's of times and I haven't seen bad magic #
<ogra> GrueMaster, for a bug about gdm not starting on the panda
<robclark> so I think the best option is to dd an entire raw boot partition, rather than relying on fatfs
<GrueMaster> I don't think so, but I might have.
<ogra> robclark, why dont we have any issues on omap3 then ?
<robclark> I had same issue on omap3
<robclark> at least on 3430.. I never tried 36xx
<GrueMaster> No, thats what I was working on last week.  Haven't finished narrowing it down yet.
<ogra> GrueMaster, we need bugs for the freeze execptions
<GrueMaster> Understood.
<ogra> please file something generic for each issue you find first, we can do detailed research later
<prpplague> ogra: that is a good question, how are you mounting the boot partition? as vfat or just msdos?
<ogra> prpplague, vfat
<GrueMaster> Ok
<ogra> prpplague, well, we dont specify a fs actually we just mount it
<rsalveti> ogra: you said we don't have this issue for blaze
<rsalveti> that's more interesting
<prpplague> ogra: ahh, can you check to see what it is actually reporting after mounting?
<ogra>                 echo "Using u-boot partition: ${UBOOT_PART}" >&2
<ogra>                 TMPMOUNT=$(mktemp -d)
<ogra>                 mount $UBOOT_PART $TMPMOUNT
<ogra> thats the code that mounts it
<ogra> we rely on the kernel here to determine the fs
<ogra> i would, if i could boot :P
<ogra> /dev/mmcblk0p1 on /mnt type vfat (rw)
<ogra> thats what i get on x86
<GrueMaster> ogra: Bug #624059.  I marked it as critical - incomplete to indicate that it is high priority but cause unknown.
<ogra> thanks
<ubot2> Launchpad bug 624059 in ubuntu "gdm fails to start on armel images updated from Alpha 3. (affects: 1) (heat: 8)" [Critical,Incomplete] https://launchpad.net/bugs/624059
<ogra> prpplague, same on panda ... "/dev/mmcblk0p1 on /mnt type vfat (rw)"
<ogra> mkdosfs -n "SERVICEV001" -F 32 /dev/mmcblk0p1 is the way we use to create the filesystem btw
<rsalveti> yep, creating it as a simple fat 32 partition is enough to get the problem
<prpplague> ogra: can you email me a list of items that are of concern for the panda support?
<ogra> prpplague, you mean for u-boot ?
<prpplague> ogra: any issues that you have for 10.10 release
<ogra> the trashed filesystem is the only one atm
<ogra> the other ones are rather homemade
<prpplague> ahh ok
<ogra> i.e. busybox reboot doesnt work and things like that ... all stuff i need to fix in the packages
<GrueMaster> I have discovered on this issue that I can reproduce it by just moving/renaming existing files and copying new ones over.
<prpplague> robclark and i have seem to nailed down the issues with the hdmi/dvi stuff so we should be getting those merged soon
<ogra> GrueMaster, does the system dbus run if you try to start gdm ?
<prpplague> robclark has his stuff posted on gitorious
<GrueMaster> But if I copy them to a different area, reformat the partition, and recopy them back with the new files first followed by the old ones it works.
<ogra> yeah, right thats another issue but we're waiting for the latest kernel
<prpplague> GrueMaster: yea that is what my script does
<GrueMaster> It appears to be an issue with seeking past a certain pont in the filesystem.
<ogra> we cant reformat the whole thing on every initramfs update
 * ogra will not release with such hacks
<ogra> prpplague, how far is the new u-boot implementation feature wise ? shoudl it be on par with the 1.1.4 version ?
<ogra> (we need hush shell and scripting support for our images)
<prpplague> ogra: feature wise, it is 10000000 times ahead of 1.1.4
<ogra> if it works as good as 1.1.4 we should probably update
<ogra> but that would have to happen today
<prpplague> ogra: you'd need to get with sakoman to double check the complete status
<ogra> his wikipage didnt look like it would be comeplete
<ogra> http://omappedia.org/wiki/U-boot_Upstreaming_Project
<rsalveti> ogra: as I described at the bug report, it works fine :-)
<sakoman> ogra: for panda it should be fine
<rsalveti> ogra: even using the current u-boot default tree
<prpplague> ogra: i think that just means the upstream items
<ogra> rsalveti, would you have time to package it ?
<ogra> i think we need to switch for the es2.0 HW anyway
<rsalveti> ogra: sure, if you think we're good to update it now
<sakoman> for sdp/blaze it is missing final ethernet/spi driver cleanup and emmc environment support
<ogra> rsalveti, well, if it saves us from bad hacks like reformatting the fat every update
<sakoman> hush shell and scripting are there
<ogra> sakoman, do you have an ETA for landing teh blaze features ?
<rsalveti> ogra: should I update it now or wait for es2?
<prpplague> ogra: if you switch to the mainline u-boot to fixed the magic number issue, it will be a good reason to push for changing support on our end
<ogra> rsalveti, well, with the current state we cant roll beta images
<rsalveti> ogra: ok, will test the latest one and pack it
<rsalveti> *try
<sakoman> ogra: probably a month or two since I've had OMAP3 stuff moved up on the priority list by the LInaro folks
<ogra> prpplague, right, the thing is that we have time constraints and updating stuff gets harder every day, from tomorrow on each fix requires a ton of paperwork
<prpplague> ogra: ahh
<ogra> sakoman, bah, thats bad, out omap3 u-boot works fine apparently
<sakoman> ogra: not for Beagle xM or C4
 * ogra hast seen any such issues on beagles
<sakoman> that support is not upstream
<ogra> i only have a C4 to test (kernel issues on XM prevent me from testing there atm)
<sakoman> my task is to get all support upstream
<ogra> sakoman, i dont use upstream, i use your branches ;)
<sakoman> ogra: my omap4-exp branch has functional ethernet
<sakoman> it is just not cleaned up for upstream
<ogra> so we should use that one in the distro ?
<ogra> rsalveti, would you update our u-boot-omap4 package from that one ?
<sakoman> that is my working branch and I do frequent rebases as I clean things up and submit upstrea
<rsalveti> ogra: http://people.canonical.com/~rsalveti/maverick/kernel/linux-image-2.6.35-17-omap_2.6.35-17.23rsalveti1_armel.deb should work for your xM, if you want to test it
<rsalveti> ogra: sure
<ogra> rsalveti, i will, but i'm currently focusing on panda
<ogra> and have a long list of broken stuff still here
<rsalveti> i know, I'm pointing the link just in case you want to test it :-)
<ogra> yeah, i will
<sakoman> the omap4-exp branch should work with panda, blaze, beagle c4, beagle xm, and Overo (both 35xx and 37xx versions)
<ogra> sweet
<GrueMaster> cool.  One uboot to bind them.
<sakoman> the only caveat is that the omap4-exp branch is rebased fairly often as I prepare the patches, submit them upstream, and respong to feedback
<rsalveti> as we're not seeing any issue with u-boot-omap3, I'd prefer updating just u-boot-omap4 with your current branch
<rsalveti> ogra: what do you think?
<sakoman> I try to keep it working at all times though
<rsalveti> sure, np
<ogra> rsalveti, yeah, it will also be a lot easier to package
<rsalveti> ok then
<ogra> if you build multiple binaries you need multiple configure and build runs
<ogra> i plan to switch to linaro u-boot in N anyway
<rsalveti> that's not a problem as linaro's package is probably doing that already
<rsalveti> but I'd say it's better to just update omap 4 now
<ogra> yeah, linaro uboot is not uploaded yet i think
<rsalveti> if we see any blocking issue for omap 3, then we merge both packages in one that's upstream based (or linaro)
<ogra> i think slangasek said something like that in yesterdays call
<rsalveti> hm, ok
<sakoman> ogra: I know jcrigby is testing my branch for the linaro u-boot builds
<ogra> well, if the linaro u-boot would work on omap4 we could even switch now
<ogra> but i think thats plain upstream
<ogra> and i want all the additional sakoman love from the -exp branch ;)
<slangasek> hmm, what did I say?
<jcrigby> ogra: just uploaded new version to ppa
<ogra> slangasek, that u-boot isnt uploaded to the archive yet
<ogra> the linaro one
<slangasek> correct - I need to work with jcrigby today to get it uploaded in a feature-freeze-compliant manner
<ogra> slangasek, we have fat issues with the current omap4 version we use and i was wondering if it wouldnt make sense to switch to your version now instead of waiting for N
<slangasek> if it helps you, we're happy to support your use of it
<ogra> since i want to do that switch anyway at some point
<ogra> but you are building from plain upstream
<ogra> which doesnt have everything i'd like to have :)
<slangasek> ah
<ogra> (we need to support panda and blaze with the omap4 package)
<slangasek> well, we can discuss putting some sauce into the packaging
<slangasek> oh, that sounds less like sauce and more like a side dish :)
<ogra> and as sakoman said above eMMC support for blaze is missing atm
<ogra> and eMMC is the main disk on the blaze :)
<ogra> ndec1, whats your suggestion from a blaze POV ?
<rsalveti> ogra: jcrigby can confirm, but it seems current linaro's tree is using most of current sakoman's patches from omap4-exp
<ogra> rsalveti, well, lets do it that way, i trust you on picking the right way and leave it in your hands ;)
<rsalveti> ogra: haha, sure :-)
<rsalveti> but I'd say at the moment that linaro's tree is enough for us
<rsalveti> but still want to look for omap3 related patches
 * ogra needs to reasearch busybox, gdm and update the netbook-settings package 
<rsalveti> as we could be missing patches
<ogra> ok
<ogra> the busybox breakage smells very much like toolchain :(
<GrueMaster> ogra: I'm continuing my Alpha 3 update-to-fail investigation right now.  Should have something by EOD (since I can focus ,more on it & have faster network).
<jcrigby> ogra:I have all of sakomans latest patches
<jcrigby> on top of upstream
<rsalveti> jcrigby: cool, will try your package later
<ogra> GrueMaster, i still see no systm dbus on ym images, gdm will not start without that running
<rsalveti> and check omap 3 support
<rsalveti> if everything is well, than we can just use your package
<rsalveti> and drop omap3 and omap4 ones
<ogra> yeah
<ndec1> ogra: what do you mean by 'eMMC support is missing on blaze'?
<ogra> that was my plan for N
<ogra> ndec1, in u-boot
<ndec1> ogra: eMMC on blaze is working with TI version of uboot
<ogra> ndec1, which u-boot would you suggest to use, apparently 1.1.4 has massive issues
<ogra> since it seems unlikely that we can get the whole fat driver replaced now, we're discussing which other tree to use
<jcrigby> rsalveti, I have tested it on the hw I have which  is C4, xM and mx51 babbage
 * jcrigby has no omap4 hw
<ogra> jcrigby, yeah, we need omap4 panda :)
<ogra> but we have the HW
<rsalveti> jcrigby: nice, but our old omap 3 tree had some extra patches, I'd say
<rsalveti> initial zippy support and other stuff
<rsalveti> jcrigby: I'll test it on my panda
<ogra> rsalveti, i think i only made config changes and used sakoman'S omap3 tree as is
<jcrigby> rsalveti, I think sakomans next task is expansion board support for mainline
<rsalveti> jcrigby: cool, good to know
<rsalveti> ogra: yup, but these patches are not at his current branch
<ogra> ah
<ogra> ok, so downgrading busybox to the last version makes reboot -f work again
 * ogra re-adds -marm to debian/rules
<rsalveti> who could help testing it on blaze? ndec1, GrueMaster?
<ogra> i have a blaze but a) not set up and b) we need a special eMMC setup we dont have yet
<ogra> (in flash-kernel)
<rsalveti> hm, ok
<GrueMaster> ogra: and davidm have the blazes (I don't get cool toys, only guts).
<ndec1> rsalveti: we can. I just not available atm to discuss since I am on another meeting. i want to understand more about this. perhaps we can discuss on Fri during our call.
<ogra> ndec1, beta freeze is unfortunately tomorrow
<rsalveti> it's simply, just to test if the latest u-boot boots at blaze
<ogra> rsalveti, well, its more since the blaze should get a special setup later
<rsalveti> yeah, but for now, I mean
<ogra> it will boot from a raw partiton on the eMMC and the u-boot version we use needs to support that
<ogra> or at least be enhancable in a way that we can easily get a freeze exception
<davidm> I can send the blaze to GrueMaster if that helps, just got it back from NCommander
<ogra> well, to someone who will actually work with it would be good :)
<ogra> either GrueMaster or rsalveti i'D say
<NCommander> davidm: I think I forgot to send the power cord (i couldn't find it, but its a standard plug)
<GrueMaster> Probably faster/easier to send it to me, although rsalveti would be the better choice for long term development.
<davidm> GrueMaster, I can't send it to him the duties would be insane
<rsalveti> yep, expensive board
<rsalveti> send it to GrueMaster, I can work with him on that
<ogra> then send it to GrueMaster
<rsalveti> at least it'd be good so he could test it when needed
<rsalveti> GrueMaster: I can get it directly from you later, if needed
<ogra> ok, busybox uploaded, automatic rebooting should work again
<rsalveti> ogra: just reverting last commit is enough?
<rsalveti> re-adding -marm
<ogra> rsalveti, yeah, just building with -marm again
<prpplague> just a note, the power management is working on the ES2.0 8-layer panda boards
<prpplague> looks like the twl6030 silicon we had on the earlier es2.0 boards has an issue
<rsalveti> hm
<ogra> tricky
<ogra> i dont think we'll get the 8 layer yet
<rsalveti> ogra: i'd be good if people could test or ask to test arm specific changes on packages
<rsalveti> but don't know how hard was to find this bug
<ogra> it was just a look at the changelog and some experience :)
<ogra> the gdm issue seems to be rather tricky
<ogra> what would be good would be to have enough HW to give it to ara so she could set up automated testing
<ogra> i.e. not require the maintainer to test but just have automated tests that send regression alterts
<ogra> *alerts
<sakoman> jcrigby: correct -- adding the expansion board stuff is on the agenda next
<sakoman> should be in by end of this week
<GrueMaster> Hopefully I can work with her on this post release.  My systems are idle at night anyways.
<rsalveti> sakoman: nice
<ogra> GrueMaster, not your systems :) for N we should have huuuuge amounts of HW
<ogra> GrueMaster, but its surely worth a spec for N
<ogra> hey zul !
<ogra> you in -arm ?
<zul> hey ogra, yep just lurking
<ogra> phew ... i was fearing server breakage :)
<ogra> good to see you here :)
<GrueMaster> ogra: I've added a task to my list to write up a blueprint for test automation, however I'll need someone to proxy for me as I won't make UDS.
<ogra> huh ? you wont ?
<ogra> thats bad, but i can proxy for you
<zul> ogra: hehe
<ogra> GrueMaster, or worst case i'll delegate to NCommander he has nothing to do anyway ... just that little dove thing :)
<GrueMaster> I had already booked a cruise that week.  Booked it once we had the release date finalized at the last UDS.
<GrueMaster> heh
<ogra> ah, year i remember now, you told me at the sprint
<GrueMaster> When I told the wife I should go to UDS, she gave me a look that would have given an exorcist pause.
 * sakoman has no idea what this N thing is
 * NCommander embeds a golf club in ogra's head
<GrueMaster> Next Release.
<ogra> sakoman, next release after mmmmmaverick :)
<NCommander> sakoman: its a letter
<NCommander> :-)
<sakoman> :-)
 * sakoman imagines Sesame Street music in the background
<sakoman> "this release brought to you by the letter N"
<ogra> lol
<ogra> it actually *is* like sesame street :) you learn a lot about adjectives and animals following ubuntu releases
<ogra> maverick meerkat :) natty narwahl
 * ogra takes a break
<GrueMaster> I thought it was narcissistic narwhal.
<GrueMaster> Guess I should read the web a little more.
<mpoirier> has anyone been able to use the ftrace's "set_ftrace_filter" on OMAP3 ?
<prpplague> sebjan: ping
<slangasek> ogra: are you guys using the linux-fsl-imx51 kernel at all in maverick?  It was inherited from lucid when the archive opened, hasn't been updated since, and if it's not needed / worked on, it's better to cull it from the archive than to let it drift
<slangasek> (it's already missing two security revisions from lucid)
<lool> slangasek: it's removed already
<lool> in maverick
<slangasek> lool: no, it isn't
<ogra_cmpc> slangasek, we dont support imx51 at all
<ogra_cmpc> in maverick
<lool> slangasek: Oh I don't see the source in rmadison output
<slangasek> lool: I'm looking straight at the archive; not sure why rmadison doesn't show it for you
<slangasek> ogra_cmpc: so you're ok with me nuking it?
<lool> slangasek: Uh yes I do, I'm just assuming it's sort alphabetically </slap>
<lool> slangasek: I'm just tired, sorry
<ogra_cmpc> slangasek, totally
<GrueMaster> slangasek: I do get security updates for lucid to test.  And we do still support it on lucid.
<slangasek> GrueMaster: yes, we don't remove packages from released versions after the release
<GrueMaster> ok, just making sure.
<ogra_cmpc> GrueMaster, only maverick
<GrueMaster> Might also check with oem to see if they have any strange projects going on that require it.
<ogra_cmpc> oh, that might be, but for imx51 they will surely have their own kernel/bootloader
<ogra_cmpc> since ours definitely only supports babbage boards
<slangasek> and hasn't even been getting security updates
<ogra_cmpc> slangasek, lamont or IS might have some interest in having an imx51 kernel since our buildds are currently all babbage 3.0 boards
<slangasek> if OEM were using it, I expect they would've interfaced with the kernel team on this before now
<slangasek> ogra_cmpc: IS doesn't run non-LTS on the buildds
<slangasek> (if they can help it)
<ogra_cmpc> well, armel is spethial :)
<slangasek> it's nuked already, so anyone who needs it should've spoken up sooner
<slangasek> armel isn't *that* special, no
<ogra_cmpc> well
<ogra_cmpc> we had buildds where IS had no control about the kernel at all for the last few releases
<slangasek> which is quite a separate thing from wanting to run a kernel from a *newer* non-LTS release
<ogra_cmpc> if we run into HW related probs like we did with the former setup it might require an update
<ogra_cmpc> but for that we can indeed have a separate kernel if neede
<ogra_cmpc> d
<ogra_cmpc> (the pegatron buildds with the binary only kernel had issues building thumb2 for example)
<prpplague> ogra_cmpc: have you got a L24.9 repo you guys are using for testing your ubuntu builds from?
<ogra_cmpc> prpplague, for kernel ?
<prpplague> yea
<prpplague> rsalveti: said he was waiting on sebjan to do some testing with L24.9
<ogra_cmpc> prpplague, we get a specially merged tree from sebjan where he rebases the TI releases on top of the ubuntu tree
<ogra_cmpc> we're waiting for the 2.6.35 rebase, zes
<prpplague> ogra_cmpc: ahh ok
<ogra_cmpc> s/z/y/
<prpplague> ogra_cmpc: ok, i was kinda hope'n to test your builds
<ogra_cmpc> well, we should get the rebased tree this week
<ogra_cmpc> the only working image we currently have is a few weeks old if you are intrested
<ogra_cmpc> http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/alpha-3/
<GrueMaster> slangasek: I'm not sure why the kernel updates haven't been getting in there.  I know they have released some to proposed fairly recently (July I think).
<ogra_cmpc> just gunzip, dd to SD card and boot away
<GrueMaster> actually, I am currently running a kernel built on 8/19.
<ogra_cmpc> GrueMaster, because the mx51 kernel was in a separate tree
<ogra_cmpc> in maverick nobody maintains that tree
<slangasek> GrueMaster: because publishing to the current dev release isn't part of the security team's process for kernels; so if nobody's maintaining the kernel in maverick, it would be guaranteed to continue falling farther behind between now and release
<GrueMaster> ok.  Starting to understand.
<ogra_cmpc> smb updates the lucid tree
<ogra_cmpc> but cooloney doesnt update the dev tree anymore
<slangasek> if somebody wants imx51 in maverick, they can work on getting support upstreamed and into linux-linaro :-)
<ogra_cmpc> i thought linux-linaro has imx51 support already
<slangasek> yes, as much support as is present upstream
<ogra_cmpc> ah
<ogra_cmpc> which is likely sparse :)
<slangasek> quite
<ogra> sigh, now my panda stopped booting completely
<GrueMaster> Is there an easy way to backrev a package with apt?
<GrueMaster> Or does it always load the latest.
<ogra> you can define a version iirc, but if its only one package i'd just wget and dpkg -i it
<GrueMaster> ok
<rsalveti> sakoman: does 'reset' at u-boot work with you at beagle xM?
<rsalveti> at mine I just get stuck
<sakoman> rsalveti: I don't have a "final" xM yet (due tomorrow)
<sakoman> rsalveti: let me try on an early prototype I have
<sakoman> rsalveti: yes, just hangs
<rsalveti> sakoman: mine is a p8, not final too
<sakoman> rsalveti: let me try on an Overo 37XX
<rsalveti> hm, so, so it seems we got a bug
<rsalveti> ok
<sakoman> we can at least see then if it is a 37XX related issue, or is xM specific
<lool> sakoman: I'd love knowing if the XM comes with a MAC address in eeprom in the final version
<sakoman> lool: perhaps we'll find out soon :-)
<sakoman> rsalveti: same situation with the Overo 37XX
<sakoman> rsalveti: I'll investigate
<rsalveti> sakoman: ok, thanks :-)
<sakoman> rsalveti: looks like the reset command uses a generic arm library used by all arm processors
<rsalveti> hm
<sakoman> I'll have to ping some TI folks to see if they know why this code doesn't work on the 37XX
<sakoman> rsalveti: found a potential fix.  will test.
<rsalveti> cool
<sakoman> it is indeed -- in involves doing a "cool" reset
<sakoman> so your choice of words was amazingly accurate :-)
<rsalveti> haha :-)
<rsalveti> lool: so no mac address in eeprom for us
<rsalveti> the eeprom pins are  n.c.
<sakoman> bummer :-(
<rsalveti> maybe for panda, but not for xM
<rsalveti> prpplague: do you know if we get an smsc eeprom for panda?
<rsalveti> or is it just n.c. as xM?
<sakoman> rsalveti: the reset fix worked on my 37XX Overo, let me check for regressions on the 35XX versions
<rsalveti> nice
<prpplague> rsalveti: one sec
<sakoman> rsalveti: worked fine on 35XX also, I'll push to my omap4-exp branch shortly
<sakoman> I'll ping you when it is done
<rsalveti> sakoman: great!
<lool> rsalveti: sadness
<lool> rsalveti: So I definitely think it's worth talking to the usbnet maintainer
<sakoman> lool: the Overo's have eeproms on their network chips
<lool> Good!
<GrueMaster> HA.  I found a dependency issue in the pool that slipped by the awesomeness of debian packaging.  gnome-terminal now depends on libvte but libvte failed to upgrade at the same time.
<prpplague> rsalveti: the eeprom is no connect on the panda
<prpplague> rsalveti: you can do one of two things
<prpplague> rsalveti: either have linux driver get a random mac
<prpplague> rsalveti: or you can use rob's patch to assign one manually as a boot arg
<sakoman> rsalveti: I added the fix to the set of patches I am preparing for submission -- staged in the omap4-exp branch
<sakoman> rsalveti: in particular: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=ce927c809c6b3a619a2cd712c47563676d79f8f0
<rsalveti> prpplague: yep, also saw that patch
<rsalveti> just wanted to confirm
<prpplague> rsalveti: ahh ok
<rsalveti> I'm fine with the random one for the moment
<rsalveti> ouch, can't boot my kernel on a b5 (external abort on non-linefetch)
<rsalveti> hm... works at my c4
<rsalveti> sakoman: nice, thanks
<rsalveti> prpplague: but thanks for checking it
<prpplague> :)
<sakoman> rsalveti: thanks for testing and the bug report
<rsalveti> prpplague: ndec: don't know yet, but do we have access to any hardware documentation for panda? (public or canonical)
<sakoman> there's a lot of common code, so I need to test on 6 different OMAP3/OMAP4 boards
<ndec> rsalveti: jayabharath might know.
<rsalveti> sakoman: compiling new u-boot right now :-)
<jayabharath> rsalveti: what documentation would you like.. we can load it up on the wiki
<sakoman> rsalveti: I'm sure you'll let me know if it doesn't work ;-)
<rsalveti> jayabharath: things like the schematics
<rsalveti> this sometimes can help debugging kernel issues
<rsalveti> mostly gpio, pins and etc
<rsalveti> not anything specific at the moment, can ping you if I need anything else
<jayabharath> Sure.. will load them up on 'the' wiki
<rsalveti> sakoman: sure :-)
<rsalveti> jayabharath: cool, thanks :-)
<rsalveti> jayabharath: would you mind sharing the doc for es1 and es2?
<rsalveti> if not possible, just es2 related is enough
<jayabharath> Ok. will load up all the schematics for all revs :)
<rsalveti> jayabharath: awesome, thanks a lot
<prpplague> rsalveti: i have the lilluput/iMO display working on the panda
<rsalveti> prpplague: haha, cool!
<rsalveti> argh! another fried sd
<rsalveti> sakoman: do you know if reset worked for panda before?
 * robclark wants to see it
 * rsalveti can't remember
 * rsalveti can't see it :-(
<robclark> rsalveti: fwiw, the reset button works much better on es2
<sakoman> rsalveti: don't recall, will have to check
<rsalveti> well, doesn't seems to work at all at my es1 hah
<rsalveti> sakoman: at least with your latest patch it doesn't work
<rsalveti> but don't remember if it worked or not before
<rsalveti> took a while to test because one of my most used sd card got fried :-(
<rsalveti> lots of i/o errors
<sakoman> rsalveti: OMAP4 uses different reset code -- the arm reset library function calls an architecture dependent assembly language reset function
<rsalveti> oh, ok, makes sense
<sakoman> just tried sdp -- that hangs too
<sakoman> I may need to do a similar patch for OMAP4, will investigate
<rsalveti> sakoman: haha, ok
<rsalveti> but at least I can confirm that it's working fine for all beagles I have
<rsalveti> r5, c4 and xm
<rsalveti> with your latest patch
<sakoman> rsalveti: oops - I was mistaken OMAP3 and 4 share the reset code.  I tested with a pre-patch u-boot on SDP, so I need to rebuild and retest
<rsalveti> hm, ok
<sakoman> rsalveti: it hangs with my change, and it hangs with TI's internal u-boot
<sakoman> so I suspect that either the HW is bad, or the required reset code has changed for OMAP4 (or perhaps both)
<sakoman> I'll ping some TI folks about that
<rsalveti> could be both
<rsalveti> sakoman: do you have an es2?
<rsalveti> hm, needs other stuff
<sakoman> rsalveti: no, all my machines are ES1
<sakoman> prpplague: does the u-boot 'reset' command work with the latest OMAP4 silicon/boards?
 * rsalveti things he is the only one who actually uses this command
<rsalveti> *thinks
 * rsalveti needs more coffee
<sakoman> rsalveti: I used to use it a lot on OMAP3 after changing the u-boot environment in nand
<sakoman> rsalveti: I am roasting some coffee, cause I need some too :-)
<sakoman> rsalveti: I don't use it some much on newer 37xx/OMAP4 boards because they don't have nand!
<rsalveti> hahah, true
<sakoman> s/some/so/
<sakoman> see I do need coffee!
<rsalveti> haha :-)
<sakoman> in any event, I'll try to track down why reset command is broken on OMAP4
<prpplague> sakoman: not sure i'll have to test
<Baybal> mmm
<Baybal> are there any omap4 COMs?
<Iow> Im booting ubuntu-10.04.1-minimal-armel.tar.7z, it loads up to the language selection but it wont take input from my keyboard
<rsalveti> time for dinner, hungry
<Iow> Which line is the init for the usb keyboard?
#ubuntu-arm 2010-08-26
<Baybal> hmmm??!
<prpplague> ho ho hum
<prpplague> is it friday yet?
<Baybal> my cellphone went crazy and tried to launch irc client on himself
<cwillu> <Kaedenn> There's a deadlock which occurs when you use more than a certain number of pthreads in a single ARM program, running inside qemu-arm.
<cwillu> sound familiar? :)
<ebrahim> Hi
<lamp_> Hi
<lamp_> mouse and kayboard not working
<lamp_> writing  ubuntu-10.04-netbook-armel+omap.img on sd and cheng boot.scr
<lamp_> to folowing:
<lamp_> fatload mmc 0:1 0x80000000 /casper/uImage
<lamp_> fatload mmc 0:1 0x81600000 /casper/uInitrd
<lamp_> setenv bootargs quiet splash vram=12M omapfb.mode=dvi:
<lamp_> 1280x720MR-16@60  fixrtc file=/cdrom/preseed/ubuntu-netbook.seed  --
<lamp_> boot=casper only-ubiquity nocompcache mpurate=720 console=tty0
<lamp_> console=ttyS2,115200n8
<lamp_> bootm 0x80000000 0x81600000
<lamp_> booting beagleboard and see this error:
<lamp_>    hub 1-0:1.0: unable to enumerate USB device on port 2
<lamp_> My mouse and keyboard not working, how to resolve this problem ?
<lamp_> tanks
<lamp_>  On C4 beagleboard
<lamp_> ?
<lamp_> ?
<hrw> morning
<DanaG> say, anyone have experience with webcams on a beage?
<amitk> try #beagle
<amitk> lamp_: have you connected to the ehci host port or the otg port?
<amitk> lamp_: and are they connected directly or through a usb hub? (A hub is required)
<lamp_> ehci
<lamp_>  connected directly
<amitk> lamp_: directly won't work, you need to connect it through an externally powered hub
<lamp_> even otg port
<lamp_> flash usb working on directly connect
<lamp_> flash usb working on directly connect to ehci
<lamp_> sell  externally powered hub ?
<amitk> ?
<lamp_> Are you sure that buying a  externally powered hub The 'hub 1-0:1.0: unable to enumerate USB device on port 2' problem is solved?
<cooloney> amitk: can you use codesourcery 2010q1 cross compiler to build our maverick kernel package for omap3
<amitk> cooloney: I haven't tried it. I stick to old CS toolchains in general :)
<cooloney> amitk: sorry for bothering, i just tried that, it works.
<lool> amitk: Eh you should dogfood or cross-compiler packages!!
 * ogra thinks we need more builders ... 50 package in queue and all builders blocked :(
<amitk> lool: I'm running maverick on the laptop, so I do a bit of dog-fooding there. I wish we had lucid packages though
<lool> amitk: they don't install on lucid?
<amitk> lool: they didn't last I tried (a few weeks ago)
<lool> amitk: I'd be curious whether that's still the case
 * amitk re-adds hrw's repo to sources.list
<hrw> amitk: why not /etc/apt/sources.list.d/hrw-cross-compilers.list instead?
<hrw> easier to enable/disable
<amitk> hrw: that's what I'll do, much longer to type though ;)
<hrw> ;d
<amitk> hrw: is there a meta package?
<hrw> amitk: nope
<hrw> amitk: for kernel you only need gcc-4.4-arm-linux-gnueabi I think
<amitk> hrw: lool: http://pastebin.ubuntu.com/483859/ (needs libmpfr4)
<hrw> they are for *maverick*
<lool> hrw: Would it be possible to build them under lucid?
<amitk> hrw: that's what you told me the last time, but I repeated the experiment because lool asked me to :)
<lool> amitk: Given that the toolchain is relatively self contained, I was hoping these would be installable on lucid
 * amitk feels that lucid being LTS should be a target
<hrw> lool: some backports from maverick would be needed probably
<lool> amitk: You could most probably install libmpfr4 from maverick though   ;-)
<lool> hrw: Yeah
<lool> hrw: How far are you from a toolchain package for the archive?
 * ogra tries to pronounce libmpfr4
<ogra> ... and fails :P
<hrw> lool: need to solve stage3 problems
<hrw> ~curse ubuntu for not using sysroot
<lool> Don't do native for linux, it's heavy   :-(
<hrw> ?
<ogra> lool, arent all our linux packages native anyway ?
<lool> 90+ MB
<amitk> ogra: it is libmp-4-french people ;)
 * ogra thought the packaing tree merge happens on a git level
<ogra> amitk, lol
<hrw> amitk: you use amd64?
<amitk> hrw: yes
<hrw> good. deboostrap lucid in progress
<amitk> hrw: thanks! Let me know when to test
<hrw> ok
<hrw> amitk: one more thing - you will get maverick gcc not lucid
<amitk> hrw: that is fine
<hrw> anyway - first lucid one
<hrw> I am curious what will it bring and how will look
<ynezz> where can I find content of hrw-cross-compilers.list ? :)
<lool> ynezz: At the top of http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/
<lool> deb http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ ./
<lool> etc.
<lool> Currently maverick-only
<asac> XorA: hi
<asac> oops
<asac> -> linaro
<lag> rsalveti: ping
<hrw> amitk: lucid require too many backports to build maverick cross toolchain. better grab maverick one and add all needed maverick libs
<ynezz> hrw@canonical? what a change :)
<hrw> ynezz: its 4 months now
<ynezz> ah, didn't noticed
<ynezz> does it mean, that ubuntu is switching from native to cross? :)
<ogra> no
<persia> Very much not!
<ogra> it means that developers can do cross builds if needed
<ynezz> ok
<ogra> ubuntu will never switch from native to cross
<ogra> lool, bug 624568 FYI
<ubot2> Launchpad bug 624568 in busybox (Ubuntu) "building busybox without -marm on armel makes several binaries unusable (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/624568
<XorA> asac: hi
<asac> hey XorA ;)
<asac> XorA: so the maverick stack is now more or less ready to start working on things
<asac> XorA: you can intall mutter and then just install
<asac> libclutter-eglx-es20-1.0-0
<asac> to flip to egl
<asac> XorA: to implement the extension we talked to about just do a apt-get source libclutter-eglx-es20-1.0-0 ... and then look at the texture_pixmap function in the gles tree
<hrw> ynezz: cross builds are option for developers to not wait 3 days for kernel rebuild but have it done in short time
<hrw> etc
<asac> XorA: -> #linaro ;)
<ogra> NCommander, please bump https://edge.launchpad.net/ubuntu/+source/u-boot-linaro/2010.06-695-gbd23130-linaro-0ubuntu1/+build/1934915 to $very_high
 * persia encourages asking random buildd admins for such things in #ubuntu-devel: tends to avoid timezone limitations
<ogra> i *like* to nag NCommander directly :P
<persia> (as in "Could a buildd admin please ...")
<persia> Yeah, but doesn't help if he's not around.
<ogra> i usually fall back to that if he's not around
<persia> I'm 90% certain that's the case now, although I may be mistaken.
<lag> ogra: If I can get your XM to do this: http://paste.ubuntu.com/483904/
<lag> ogra: Can you start working on it?
<lag> (again)
<ogra> lag, i'll try soon, i'm currently a bit busy aith panda
<ogra> *with
<ogra> lag, thats with todays image ?
<lag> ogra: No
<lag> ogra: Today's image provides: http://paste.ubuntu.com/483908/
<ogra> grmpf
<ogra> doesnt resize, doesnt reboot
<lag> Correct
<ogra> i uploaded a fix for the reboot issue yesterday
<lag> So, back to my original question
 * ogra takes a look what happened to the busybox upload
<lag> ogra: No
<lag> ogra: It has nothing to do with it
<ogra> ?
<lag> I believe the daily image is still ro
<ogra> it should still reboot
<ogra> it cant be ro if you get through to oem-config
<ogra> since thats only enabled by touching a certain file on the FS
<ogra> line 327 in http://paste.ubuntu.com/483908/
<lag> Well tell me what the differences betweek the two pastes I gave you then?
<lag> between*
<ogra> weird i see the initrd script being executed twice in the latter one
<ogra> lag, the first one reboots fine
<lag> ogra: Correct
<ogra> which image is that ?
<lag> The second one is the daily build
<lag> The first one is the daily image with my kernel and initrd
<ogra> and the first one that works ?
<ogra> oho !
<ogra> same image ?
<ogra> but different kernel ?
<lag> Yeah
<lag> And initrd
<ogra> so i was right saying the broken reboot is a kernel issue ;)
<ogra> and you already fixed it !
<lag> Seemingly
<ogra> perfect
<lag> Where is Busybox?
<ogra> whatever you did, i want it in our kernel then :)
<ogra> its the shell that runs in initrd
<lag> So it must be using my Busybox?
<ogra> your chroot should have two packages, busybox-static and busybox-initramfs
 * lag looks
<ogra> can you check which version your used inside the chroot ?
<ogra> *you
<ogra> might be that my -marm fix is moot
<lag> How do I check?
<ogra> dpkg -l|grep busybox
<lag> ii  busybox-initramfs                1:1.15.3-1ubuntu1        Standalone shell setup for initramfs
<ogra> 1:1.15.3-1ubuntu3 has the -marm fix
<ogra> hmm
<ogra> 1:1.15.3-1ubuntu1 is the oldest one we had in maverick
<ogra> could you try upgrading ? that version used to work all the time
<ogra> 1:1.15.3-1ubuntu2 stopped working, 1:1.15.3-1ubuntu3 was supposed to fix that
<ogra> 1:1.15.3-1ubuntu4 is the current one (with another fix on top of mine)
<ogra> gah, todays daily still doesnt reboot :/
<ogra> at least on omap4
<lag> ogra: I know, I told you that!
<ogra> yes
<ogra> f*ck
 * ogra thinks he found the issue
<zumbi_> 111m355
<zumbi_> damn :)
<persia> have to change that now :)
<zumbi_> it is screenlock passwd
<zumbi_> but yeap, i need to change
<lag> ogra: And ...
<ogra_cmpc> lag, fix is uploaded
<lag> ogra: Which was?
<lag> ogra: And why did it work with my kernel/initrd?
<ogra_cmpc> if e2fsck finds a wrong last mount time (because of rtc skew or something) it tears down the whole resize script
<lag> Where is that? Jasper?
<ogra_cmpc> the last line in the resize script sets that reboot mark for the next script
<ogra_cmpc> yeah
<ogra_cmpc> no idea why your kernel initrd worked though
<ogra_cmpc> since it doesnt seem to be busybox at all
<ogra_cmpc> what fixes does your kernel include ?
<ogra_cmpc> anything related to ext2/3 ?
<lag> ogra: I'll show you
<lag> http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=commitdiff;h=fa324d1893d06e157a2f93040a20f1d490c3c834;hp=978e830c47ca5de5824ddf3ba9f7d3571da765a7
<lag> http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=commitdiff;h=27dafb99b153bab4bf7f061889775761cf7c2caa;hp=fa324d1893d06e157a2f93040a20f1d490c3c834
<lag> http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=commitdiff;h=12f88410bcaab12078b27e766a42b12a7d4bd2b5;hp=27dafb99b153bab4bf7f061889775761cf7c2ca
<lag> ogra: -^
<ogra> yep, looking
<ogra> ah, mmc fixes
<lag> Correct o mondo
<ogra> might be that thats related, i.e. if the mmc is bad e2fsck will exit 1
<ogra> same symptom, different cause
<ogra> lets wait until jasper is in the archive and i rolled a new image
<ogra> (which might take eternally)
<lag> ogra: Are you saying that there is no massive rush to place these patches into our kernel?
<ogra> we need more buildds
<ogra> lag, there is, but no way to test them quickly in the archive
<lag> ogra: That's find by me - they're not even in the linux-omap kernel yet
<persia> Nah, just faster buildds.
<ogra> lag, https://edge.launchpad.net/builders
<persia> more just means more parallel builds of superceded stuff
<ogra> lag, we're 60 package (or 10-12h) behind on armel
<ogra> (thats a guesstimate, could also only be 8-9h)
<ogra> lag, where do they come from initially ? rcn-ee ?
<lag> ogra: Yes, they are Robert's patches
<ogra> cool
<ogra> add them !
<lag> They have been ack'ed in linux-omap, but they're not in the tree yet
<ogra> pfft, lets be ahead :)
<lag> When will development continue on the XM?
<ogra> as soon as we can boot it
<ogra> which your patch should fix
<ogra> i want working images for beta
<ogra> lag, dont you need to mention a bug # in pull requests (seeing your mail to the kernel ML)
<lag> ogra: Although this does fix one of the bugs, it is not directly associated with one
<ogra> ah
 * ogra lears something new every day :)
 * ogra also learned that the new tires for his new car will cost him about 1000â¬ :(
<ogra> its only rubber ! damned
<persia> Get steel wheels: more sparks, less frequent replacement
<ogra> yeah, looks surely more shiny to do 270Km/h with these ... though i fear the traction wont be as good :)
<persia> Yeah, well.
<hrw> ogra: costs of using porsche?
<ogra> hrw, costs of buying porsche with horribly wide tires and knowing they need replacement
<lag> ogra: Have you tested the daily build on the Panda ES1.0 today?
<ogra> i didnt know there is only one set thats allowed though
<ogra> lag, yes, thats what i did above to find the jasper issue
<hrw> ogra: sucks a bit
<ogra> well
<lag> Hmm
<lag> That's not good
<ogra> hrw, i asked for it, i get it :)
<hrw> yep
 * hrw rebuilds gcc-4.4 again to check for regressions
<ogra> lag, whats not good ?
<lag> ogra: I recieved my, replacement Panda today
<lag> ogra: My old one's USB was borked
<lag> ogra: This one doesn't seem to want play nice with HDMI
<ogra> ah, well, your broken monitor again
<lag> ogra: Nope
<ogra> is that es1.0 ?
<ogra> or 2.0
<lag> ogra: Different one
<lag> ES1.0
<ogra> yes, but which version
<ogra> ah
<lag> I haven't plugged my ES2.0 in yet
<lag> There are more than one?
<ogra> mine is on the way, just had a call from fedex customs
<lag> How do you tell which version is which?
<ogra> one is painted black, one isnt
<hrw> wasn't black ones es2.0?
<ogra> right
<lag> You asked me which version of ES1.0 I had
<ogra> ??
<ogra> i didnt
<ogra> <ogra> is that es1.0 ?
<ogra> <ogra> or 2.0
<lool> Hmm my beagle doesn't see NAND anymore; I think this was a known bug and got fixed recently; can someone confirm that latest kernels have NAND?
 * ogra isnt sure that was uploaded to the archive yet
<ogra> i know the fix is committed
<ogra> lool, mpoirier was working on that
<mpoirier> lool: I committed the fix last week.
<lool> mpoirier: c08fa0be3ddeaca289b0646c8d087fc3820a7f3f right?
<mpoirier> lool: hold on, I'll double check.
<mpoirier> lool: yes that is correct.
<lool> mpoirier: thanks
<ogra> lool, jcrigby, btw, there is a few patches we carry that are not upstream yet, you might want to pull these in from the ubuntu tree
<ogra> (additionally to the NAND ones)
<lool> Well mpoirier's patch doesn't apply in Linaro 2.6.35; presumably we got it from linux-omap
 * ogra_cmpc thought it was our own developent
<lool> It's a workaround for the 2.6.35 situation, but upstream had already fixed it differently -- that's how I read it at least
<ogra_cmpc> mmmmk
<lool> mpoirier: f450d86790ebf72ac93c7ea5addd6fa278aae64c upstream I think
<lool> well in linux-omap; checking linus now
<lool> f450d86790ebf72ac93c7ea5addd6fa278aae64c in linus tree
<ndec> ogra: hi. back to my question on neon. should we append -neon on the package name or on the version?
<persia> package name, definitely
<ogra_cmpc> if we cant do runtime detection with hwcaps put it in the name
<mpoirier> lool: yes indeed, this is exactly what is written in my commit.
<ndec> persia: thanks!
<lag> ogra:
<lag> <lag> ES1.0
<lag> <ogra> yes, but which version
<lool> mpoirier: Eh indeed
<ogra_cmpc> lag, wrong context :P
<lool> mpoirier: Sorry, got confused by ogra
<lag> :)
<lag> ogra: Who is developing the x-loader for ES2.0
<ogra_cmpc> TI
<ogra_cmpc> lag, did you try with the linaro uboot ?
<lag> ogra: Yea
<ogra_cmpc> didnt work either i guess
<lag> ogra: It's okay, rsalveti Is going to sort me out with new binaries
<ogra_cmpc> well, we need new packages too
<rsalveti> ogra: sure, as we need a new kernel
<rsalveti> ogra: it'd be good to wait sakoman get it working with es2
<ogra_cmpc> i thought the current kernel can run on both
<ogra_cmpc> only the one we'll get with the next commit cant
<ogra_cmpc> (thats how i understood it)
<rsalveti> ogra_cmpc: lag: http://rsalveti.net/pub/ubuntu/kernel/maverick/es2/
<rsalveti> sweeeet, my es2 just arrived :D
<rsalveti> davidm: ^ :-)
<ogra_cmpc> lucky guy
<davidm> rsalveti, good, I knew it was on a truck heading to you
<ndec> rsalveti: which kernel source did you build your kernel from?
<rsalveti> ndec: lag: ogra: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-ti-omap4-es2
<rsalveti> I basically applied the patches from
<rsalveti> http://gitorious.org/pandaboard/kernel-omap4/commits/L24.8_panda_es2.0
<rsalveti> on top of our kernel
<rsalveti> also some extra display patches
<ndec> rsalveti: ok.. sebjan has sent a more official patch set to cooloney. not sure if you're aware of that. our patchset is here http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=shortlog;h=refs/heads/for-ubuntu-2.6.35. it should be same content as the initial patchset but with many cleaning in the patches
<cooloney> ndec: thx
<ndec> rsalveti: and this one is more likely to become the 'official' branch in  maverick/ti-omap
<cooloney> rsalveti: i am working on it
<lag> Where's my email?
<ndec> cooloney: thx for?
<rsalveti> ndec: sure, but this is the 2.6.35 tree, that we're waiting cooloney do review and etc, but thanks for pointing that
<rsalveti> ndec: will this tree work with es1 and es2?
<cooloney> lag: i just got it today.
<rsalveti> or just es2?
<rsalveti> cooloney: oh, so this is the "final" tree?
<lag> cooloney: sebjan said he'd sent it to both of us?
<lag> cooloney: Are you doing it then?
<ndec> ogra: lag: i see you are discussing linaro uboot. are you planning to use this one instead of the current one?
<ogra_cmpc> ndec, already switced, yes
<ndec> rsalveti: it depends on what 'final' means ;-)
<rsalveti> awesome, with all latest hdmi fixes
<ndec> rsalveti: yes. including support for multiple FBs
<rsalveti> ndec: I mean the point that cooloney can just review and get the tree :-)
<ndec> ogra_cmpc: oops... didn't know that. how does that work?
<ndec> rsalveti: cool... i thought that final means that there was no more issue with OMAP4...
<ogra_cmpc> ndec, lacking an es2 i cant tell yet but anything will be better than the 1.1.4 one
<rsalveti> ndec: it's working fine at the moment
<cooloney> lag: sebjan doesn't finished it
<rsalveti> based on sakoman's work
<ndec> ogra_cmpc: so the panda uboot support was merged in the mainline uboot? who did that?
<ogra_cmpc> ndec, 1.1.4 has a broken vfat driver
<ogra_cmpc> ndec, sakoman
<lag> cooloney: ndec just said you've been sent the email?
<cooloney> lag: no, i didn't sent email
<lool> pm215: Hey there
<ogra_cmpc> lag, ndec only pointed to the work branch of sebjan
<ogra_cmpc> without saying its done
<lool> pm215: ^P/^N or /win 2 to switch windows?
<pm215> lool: hello. I see I'm now in both channels with a hopelessly confusing UI :-)
<rsalveti> ndec: cooloney: should this kernel be compatible with both es1 and es2?
<rsalveti> the new one, based on 2.6.35
<persia> pm215, Alt+2 might work also
<cooloney> rsalveti: sebjan said it's not ready for both es1 and es2.
<cooloney> but he is working on it. i think
<rsalveti> cooloney: cool
<ogra_cmpc> i dont think es1 support is wanted
<ndec> rsalveti: only 2.0 for now. sebjan is trying to see if it can work on es1 as well..
<ogra_cmpc> at least thats what i understood in the call
<rsalveti> ogra_cmpc: sure, but just wanted to confirm :-)
<lag> ndec: What's the difference between "http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git" and "git://dev.omapzoom.org/pub/scm/integration/kernel-omap4.git"
<pm215> ^P/^N//win/alt+2> none of those do anything, I'm afraid. Never mind.
<cooloney> i've already prepared a omap4 branch based on sebjan's branch
<cooloney> lag and rsalveti http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
<rsalveti> cooloney: on current sebjan's tree?
<lool> pm215: ctrl-1/ctrl-2?  /win 2 might be keeping you in the same window, try /win 1
<rsalveti> cooloney: awesome!
<cooloney> rsalveti: sebjan is still working on it. so we need wait for a while
 * rsalveti preparing the build machine
<ndec> lag: kernel-omap4.git is TI BSP team tree, kernel-ubuntu.git is our tree (sebjan's tree) that we use as a staging area between TI BSP and Ubuntu tree
<cooloney> rsalveti: i cross compiled it on my local machine
<pm215> ctrl-1/ctrl-2> nope, no effect. /win 1 says "Unknown command: WIN"
<lool> pm215: If you want to see a quote of the day /qu erat demonstrandum
<cooloney> the L24.9 gonna some issue about ASOC codec driver
<rsalveti> hm, ok
<cooloney> so currently i disabled that ASOC codec drivers
<ndec> lag: our tree has some decent level of cleaning (400 patches removed, 3700 checkpatch errors removed)
<lool> This joke works better in French, with "/qui est lÃ "
<rsalveti> prpplague: didn't you do some work on that?
<ndec> lool: even in French I don't understand the joke...
<rsalveti> ogra_cmpc: another topic, how is today's image?
<ogra> rsalveti, still bad
<rsalveti> just download them
<rsalveti> ogra: what is broken?
<ogra> jasper, oem-config etc
<rsalveti> want to test the gles stuff with sgx and efl
<rsalveti> and latest clutter and etc
<lag> ndec: Excellent news
<lool> ndec: Well, IRC clients have an easter egg; you type /qui est lÃ , and it shows you a quote
<ndec> lag: well... thx sebjan...
<rsalveti> ogra: ouch hehe :-)
<lag> ndec: I already have
<lag> ndec: Yesterday :)
<lool> Apparently, this joke only worked back in the days I was at school
<ogra> rsalveti, the build queue was stuck for most of the day so the fixes arent built yet
<ogra> or in case of oem-config not even uploaded
<persia> Many easter eggs got polished out as more folks use the software, unfortunately.
<lool> That one is quite hard to polish out
<pm215_> (now I have a sane UI with the unfortunate effect of having to use two nicks...)
<rsalveti> ogra: hm, ok
<ogra> lool, hey !
<ogra> lool, where is the bzr commit for your flaash-kernel change =
<ogra> ?
<lool> Hmm I thought this was using the package imports
<rsalveti> lag: cool, so you're pushing the xM mmc fixes :-)
<lag> Attempting to
<rsalveti> lag: I'm using it already for days, and it's working nicely
<ogra> lool, it has a tree mentioned in debian/control :)
<lool> I'll fix that
<ogra> thanks
<ogra> its my working tree for debian merges too
<lag> rsalveti: Yes, I tested them this morning
<ogra> so it would be good to keep it consistent
<rsalveti> lag: nice
<lool> Grmpf, import-dsc doesn't work with native packages
<ogra> lool, just push your changes to the tree, what are you doing ?
<lool> I'm using the canonical way of importing a dsc into a branch!
<ogra> sigh, cant you just leave it as it is and commit your changes ?
<lool> ogra: Dude, I did already
<ogra> ah, then its fine :)
<lool> I don't understand why you care how I do it
<ogra> i dont, as long as it ends up in the right tree :)
<ogra> i thought you were fiddling with trees here ... sorry
<ogra> and thanks for the fix :)
 * ogra strikes it from his TODO
<ogra> lool, btw, does linaro care about kirkwood ? (there are some pending debian changes for flash-kernel i didnt actually plan to merge unless someone really needs them)
<cooloney> i got the 2.6.35 kernel boots on my panda now
<cooloney> http://pastebin.ubuntu.com/483996/
<ogra> cooloney, that becomes intresting if line 8 changes ;)
<rsalveti> cooloney: cool, at your es1?
<cooloney> too bad, i don't have the es2 HW
<cooloney> rsalveti: yeah, mine is ES1
<rsalveti> cooloney: nice, I will test on my es2
<cooloney> great, gonna sleep now
<rsalveti> cooloney: see ya!
<hrw> ogra: still using 512MB on panda? I thought that 1GB was running already
<ogra> hrw, not yet
<pm215_> help ?
<pm215_> whoops, can't drive my irc client still :-)
<ogra> lool, so why are the updates of my falsh-kernel branches all failing now ?
<ogra> what the heck did you do ?
<ogra> GRRRR !!!!
<robclark> ogra: if you are brave, you could try porting the 1gb patch from es2 branch..
<robclark> http://gitorious.org/~robclark/pandaboard/robclarks-x-loader/commits/omap4_panda_es2.0-1gb
<ogra> robclark, why porting ? shouldnt i be able to just build that one ?
<robclark> well..  depends on how aligned theory is with fact ;-)
<ogra> we dont plan to support es1 anyway
<robclark> in *theory* it should work
<ogra> i'll try as soon as my es2 arrives, if its good i'll just rebase the package on that one ;)
<rsalveti> robclark: nice, will try this one
<robclark> I've been using it for a couple weeks on es2..
<lool> ogra: I did what I noted in the changelog: moved to the package import branches...
<robclark> and in theory same x-loader should work on es1... but I haven't tested that myself, so who knows
<ogra> lool, well, and i have to rebade about ten development branches now
<ogra> *rebase
<lool> ogra: "rebase", why rebase?
<lool> it's the same branch
<lool> I replaced the package import branch with what was ~ubuntu-core-dev/flash-kernel/ubuntu
<ogra> i have to touch them still, you just wiped out teams work branch
<ogra> even though i asked you not to
<ogra> thats not nice ... but i'll point my branches to the new one
<lool> ogra: I don't understand what you're speaking about
<lool> You can merge them as you could before
<ogra> the master branch of my (and likely others) dev brances is gone from LP
<lool> ogra: It's not, it just moved
<ogra> ogra@osiris:~/Devel/branches/flash-kernel/ubuntu$ bzr pull
<ogra> Using saved parent location: bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/flash-kernel/ubuntu/
<ogra> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/flash-kernel/ubuntu/".
<lool> bzr pull --remember lp:ubuntu/flash-kernel
<ogra> lool, yes, i have to do that on all my branches now, at least note the new location in your changelog entry next time so people using it know where to pull from
<lool> ogra: it's the standard location...
<ogra> that was a totally unnecessary change that causes extra work
<lool> ogra: Wouldn't I do that, you would continue using the old location
<ogra> that was my plan yes
<lool> What's unnecessary is having two branches, and this will prevent people from not committing before upload
<ogra> ...
<persia> It doesn't prevent it.  It just does the right thing anyway.
<lool> ogra: There, I've pushed lp:~ubuntu-core-dev/flash-kernel/ubuntu again and marked it as abandoned
<persia> But it breaks if there are unuploaded commited changes in the branch.
<lool> ogra: please don't push to this "old" branch anymore, thanks
<persia> (which is a feature, not an impediment: stuff ought be uploaded)
<lool> ogra: Look, it sounds like you're pissed off; I'm trying to do the right thing by avoiding the mistake I made in the future; I thought it was obvious how to adjust your local branches for that, but it apparently wasn't as easy as I thought it was, so I've pushed something back will should help a bit, but wont force you into the right branch; do you understand why it's better to move to the new branch?
<ogra> lool, so will you run around and move all of cjwatsons branches too (i know he, like me prefers to use branches the old way) ?
<persia> So, this doesn't feel like constructive criticism (although I really like they way you've raised it early and publically)
<persia> Would you both agree that in future it's best to coordinate between common uploaders of a package before migrating a branch to the UDD home?
<ogra> and can you understand that people dont like to be "forced" intop a new way in the middle of the busiest time before a freeze where a branch might be used atm for fixes ?
<lool> Quite frankly, I didn't expect that there were any pending merges; I did look for pending merge requests and didn't see any
<lool> Would I have seen any, I wouldn't have moved before dealing with these
<ogra> lool, i would have moved the branch with the merge in N, its just not cool to do it if someone asks you not to
<prpplague> hey all you early developers for the Panda, i'm trying to finalize the features for the Bamboo accessory board for the panda
<ogra> but it happened now, so lets forget about it
<prpplague> if any has hardware requests for additions to the bamboo, now is the time
<lool> ogra: So the additional work it creates is this --remember lp:ubuntu/flash-kernel thing?
<lool> I dont want to defer dealing with problems when I can
<ogra> lool, that too, worse is that you simply ignored my request
<lool> ogra: where did you request what?
<ogra> prpplague, do you have a list of stuff thats in already ? so we can see what might be missing ?
<ogra> <ogra> lool, just push your changes to the tree, what are you doing ?
<ogra> <lool> I'm using the canonical way of importing a dsc into a branch!
<ogra> <ogra> sigh, cant you just leave it as it is and commit your changes ?
<prpplague> ogra: accessory board that provides: second sd/mmc, 2 user leds, 2 user buttons, reset button, power led, battery backed RTC, built in usb->rs232 for console power, 2 additional USB host ports, and an abs plastic case
<prpplague> ogra: creating a wiki page now
<ogra> <lool> ogra: Dude, I did already
<ogra> <ogra> ah, then its fine :)
<ogra> <lool> I don't understand why you care how I do it
<ogra> <ogra> i dont, as long as it ends up in the right tree :)
<ogra> <ogra> i thought you were fiddling with trees here ... sorry
<ogra> <ogra> and thanks for the fix :)
<ogra> prpplague, nothing strikes me on first sight
<rsalveti> prpplague: yep, sounds ok already :-)
<persia> prpplague, Any chance of eSATA?
<mopdenacker> I was going to ask...
<ogra> persia, heh or inflatable helicopters
<prpplague> persia: still working on that request
 * persia is *much* more interested in eSATA than inflatable helicopters.  One can glue the abs case to the baloon easily enough, but ...
<persia> prpplague, heh, OK :)
<ogra> heh
<prpplague> http://www.elinux.org/Panda_Bambo
 * persia is all sorts of excited: the ABS case is the best feature
<prpplague> i've updated the page with the color and dimensions of the case
 * GrueMaster assumes the case design includes externally accessable buttons?
<prpplague> feel free to leave comments there
<prpplague> GrueMaster: yea
<GrueMaster> Nice.
<prpplague> GrueMaster: front panel will have the power led, 2 buttons, 2 leds, the sd/mmc slot
<prpplague> GrueMaster: and the two addtional usb host ports
<persia> My main concern about the case is that it be stackable with other stuff: bare boards are hard to feel comfortable about sticking on a shelf with other stuff and attaching to a KVM.
<GrueMaster> Very nice.
<prpplague> GrueMaster: back will be the back of the panda, with a usb slave port for the console
<prpplague> persia: yea the case is stackable
<persia> Excellent.
 * GrueMaster might have to sneak the credit card away from the wife again soon.
<prpplague> estimated cost will be $55.00
<prpplague> (plus or minus $5)
<GrueMaster> Excellent.  That fits into my monthly turn & burn budget.
<GrueMaster> (i.e. not something I need to wait until I have the funds for).
<rsalveti> prpplague: nice, not that expensive
<hrw> prpplague: when will be available?
<hrw> y
<prpplague> hrw: should be available on the same day panda's become available
<persia> nice!
<rsalveti> lunch time!
<GrueMaster> Gah, seeing python issues with package updates.  Haven't updated libc6 yet, so there is hope this isn't a bug.
<ogra> rsalveti, it wont work completely, the .1 build i'm doing should only fix the reboot issue
<rsalveti> ogra: hm, ok
<ogra> rsalveti, oem-config/ubiquity was still not uploaded so it will fail
<GrueMaster> Still?  I thought the fix went in last week?
<ogra> yes, into the branch
<ogra> i didnt want to interfere with the ongoing work on the installer team so i waited for them to upload (the tree might have half breeded code in there)
<ogra> s/on/of/
<dcordes> hi
<dcordes> what is the difference between
<dcordes> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100826.1/maverick-preinstalled-netbook-armel+omap4.img.gz
<dcordes> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100826.1/maverick-preinstalled-netbook-armel+omap.img.gz
<rsalveti> default kernel, u-boot and x_loader basically
<dcordes> ok
<GrueMaster> dcordes: omap4 is for panda/blaze, omap is for Beagle
<dcordes> rsalveti: so there are no differences in the userspace binary compilation ?
<GrueMaster> (should be omap3 in my opinion - just to keep from confusing people with older platforms).
<GrueMaster> None.
<rsalveti> agree
<dcordes> ok guys thanks
<dcordes> yeah that would make sense to change omap into omap3
<dcordes> +1
<dcordes> after people loved ubuntu on the htc hd2 I am going to create a new 'release'
<rsalveti> cool
<prpplague> just to make sure everyone knows(i announced earlier today) i'm taking feedback and comments on the features for the bamboo board - http://www.elinux.org/Panda_Bambo
<dcordes> prpplague: love the case ;)
<prpplague> dcordes: hehe, i get 50/50 on that
<prpplague> <av500> the case is ugly
<dcordes> prpplague: despite from having that classical box, what is it ?
<prpplague> dcordes: accessory board for the panda
<dcordes> prpplague: is it bamboo or bambo ?
<dcordes> (page title says bambo)
<prpplague> yea someone just pointed that out
 * prpplague movies the page
<dcordes> you should add a small intro. bamboo is an expansion board for the [[panda]] device
<dcordes> something like that
<dcordes> downloading that maverick netbook rootfs with 20kB/s
 * dcordes sighs
<dcordes> university is charging too much for such slow dormitory net
<prpplague> dcordes: will do, i just assumed the folks who have a panda would understand
<ogra_cmpc> GrueMaster, the omap vs omap4 naming was chosen with the idea in mind that we might have a single omap image at some point once linaros unification work for kernel and u-boot is done
<ogra_cmpc> GrueMaster, you might have noticed that we use the same scheme for the kernel packages
<GrueMaster> My only point is that we are not supporting omap2 hw.
<ogra_cmpc> afaik thats on linaros plans too (i might misremember though)
<ogra_cmpc> at least kernel wise
<dcordes> aha
<dcordes> ogra_cmpc: how is the rootstock coming along ?
<rsalveti> dcordes: I'm using it right now, working fine :-)
<ogra_cmpc> dcordes, i gave it to rsalveti and since it made a quamntum jump in quality ;)
<dcordes> :P
<dcordes> it is because I joined the bugtracking system
<rsalveti> just need some ui fixes
<GrueMaster> ogra_cmpc: I'm down to the last 27 package updates to bring A3 current.  Still booting into X with gdm & netbook-launcher-efl so far.  Most critical path packages are updated now.
<ogra_cmpc> whats missing ?
 * ogra_cmpc doesnt get why we have that issue
<rsalveti> GrueMaster: cool, good to know
<ogra_cmpc> worrying though
 * ogra_cmpc would perfer a clear pointer to a package thats broken
<GrueMaster> Woohoo.  leann posted kernel with XM fix.
<ogra_cmpc> yeah
<ogra_cmpc> sadly i assumed she would just take the branch and upload it, but she cherrypicked ... so the NAND fix is still waiting until after beta
 * ogra_cmpc didnt think about that when discussing the freeze exception :(
<GrueMaster> I thought that was already in.
<ogra_cmpc> in the tree, yes
<rsalveti> ogra_cmpc: what nand fix?
<GrueMaster> for beagle
<rsalveti> hm, so isn't it released already?
<ogra_cmpc> rsalveti, the one that makes mtd work again
<ogra_cmpc> i didnt see it in any upload yet
<rsalveti> mine works, I even get i/o errors
<ogra_cmpc> and tohdays only has the cherry picked mmc fix
 * rsalveti looks at the kernel tree
<GrueMaster> I think it is already there.  I'm looking at today's image on beagle and seeing /dev/mtd*
<ogra_cmpc> oh, hmm, then i might be blind and have missed it in the changelog
<GrueMaster> That's highly possible.  :P
 * ogra_cmpc wonders if he has a misbehaving proxy .... i saw the 20100826.1 image on cdimage a few mins ago, now it seems to be gone again
<rsalveti> ogra_cmpc: bug 608266
<rsalveti> fix released already
<ubot2> Launchpad bug 608266 in linux (Ubuntu Maverick) (and 1 other project) "[regression] no more /dev/mtdblock devices on omap3 in maverick (affects: 1) (heat: 104)" [Medium,Fix released] https://launchpad.net/bugs/608266
<ogra_cmpc> ah, ik
<rsalveti> with 2.6.35-16.22
<rsalveti> :-)
<ogra_cmpc> consider me officially blind then
<rsalveti> I even told you that I was getting i/o errors
<ogra_cmpc> :)
<rsalveti> :-)
<ogra_cmpc> right, i thought that was with your own kernel
<GrueMaster> Helps not to look through a half full beer glass.  :p
<ogra_cmpc> i'm never sure what you use over there :P
<rsalveti> haha :-)
<rsalveti> true
<rsalveti> I try to use our kernel with possible fixes
<ogra_cmpc> GrueMaster, i had my last beer in prague :)
<rsalveti> so we can get it pushed later
<rsalveti> ouch
<dcordes> GrueMaster: I can offer a 1/3 full whine glass if somebody is interested
<GrueMaster> this saddens me.
<rsalveti> 2
 * dcordes always ready to help the community.
<ogra_cmpc> no, its healthy, keep my liver happy and makes me bear more in orlando ;)
<ogra_cmpc> dcordes, you whine into a glass ?
<ogra_cmpc> now *thats* saddening ;)
 * GrueMaster only whines about an empty glass.
 * dcordes everybody lol for the funniest typo 2010
<dcordes> that got me so down I need to refill
<ogra_cmpc> that year isnt over ... and my bad humor isnt either ;)
<ogra_cmpc> hmm, where is the .1 image gone .... looking above dcordes saw it too (according to the url)
<GrueMaster> I'm pulling it ok.
<ogra_cmpc> i get a 404 for the dir
<GrueMaster> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100826.1/maverick-preinstalled-netbook-armel+omap4.img.gz.zsync
<GrueMaster> odd
<ogra_cmpc> i started a zsync upstairs, not sure it still runs
<ogra> yeah, seems to be done
<dcordes> ogra_cmpc: .1 image ?
 * dcordes is downloading http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100826.1/maverick-preinstalled-netbook-armel+omap4.img.gz
<ogra> dcordes, right, but http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100826.1/ gets me a 404 suddenly
<ogra> and http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/ doesnt have a .1
<ogra> my download worked fine as well
<ogra> oh, there is is now
<ogra> irritating
 * ogra guesses our sync process from the builder to the webserver is somehow strange 
<dcordes> ogra: try to request the url 10 times
<dcordes> then it works
<ogra> well, it seems stable now
<dcordes> I always have weird problems with that server *_*
<ogra> err, no, it doesnt, its gone again
 * ogra checks the server itself
<dcordes> here it works but weirdo style as always
<dcordes> don't understand the underlying network mechanisms well enough to say what it is
<ogra> yeah, its definitely on the server
<dcordes> all I know is sometimes the sites there don't show up at a ll
<ogra> well, it would be ok if it was just delayed, that on/off stuff is weird
<dcordes> but when I keep hitting enter in the browser's url bar it works
<dcordes> :)
<dcordes> I think when I just let it time out it will also go 404 ...
<sakoman> rsalveti: I think I found a fix for the panda u-boot reset command issue
<rsalveti> sakoman: nice, what was the issue?
<sakoman> OMAP4 seems to want a different bit written to trigger the reset
<rsalveti> hm, makes sense
<sakoman> TI u-boot was using bit 1 (i.e. 0x02), but I think bit 0 (0x01) is right
<sakoman> it also uses a different address than OMAP3, but I already took care of that
<rsalveti> cool
<sakoman> so while 0x02 worked for all earlier OMAP3s, OMAP36XX/37XX need 0x04, and OMAP4 needs 0x01
<rsalveti> got it
<sakoman> so I need restructure the code/headers a bit
<sakoman> I'll revise the patch I posted previously to also take care of OMAP4
<sakoman> rsalveti: little things like this take way too much time, what with building & testig on multiple boards and reviewing multiple 3000 page TRMs!
<rsalveti> ouch :-)
<suihkulokki> how does the current preinstalled image decide if it is starting on beagleboard or beagleboard xm?
<rsalveti> suihkulokki: the omap image should work on both
<rsalveti> not with today's image, but that's going to be fixed for tomorrow
<suihkulokki> rsalveti: I know it support both :) my question is what does it _do_ to figure out which one it is running on
<rsalveti> suihkulokki: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=blobdiff;f=arch/arm/mach-omap2/board-omap3beagle.c;h=623c352f14695a3a01545db9a1307adc5d11e21d;hp=5501f310a9d0c34df4516d6efd0f5e5e25ca2960;hb=52e9cdbb825eae0f3f75550adacebdc36303700b;hpb=978e830c47ca5de5824ddf3ba9f7d3571da765a7
<rsalveti> an example
<rsalveti> then you can also check by the cpu type
<suihkulokki> ok, so there is a gpio to read. thanks.
<rsalveti> yup
<GrueMaster> Hmmm.  I'm thinking ureadahead is the cause of our current issues.  Testing that theory now.
<rsalveti> GrueMaster: hm, it shouldn't, unless we got a new release
<GrueMaster> Since Alpha 3, yes.
<rsalveti> you can disable it, mv /etc/init/ureadahead.conf /etc/init/ureadahead.disabled
<rsalveti> doesn't make a differente
<rsalveti> I mean, a major release
<rsalveti> *difference
<GrueMaster> I updated that, rebooted, then updated all of network manager packages, rebooted.  Not I am getting corrupt filesystem and hangs, but not getting past uInitrd.
<rsalveti> ouch
<ogra_cmpc> rsalveti, i think parts of ureadahead start in initrd
<rsalveti> hm, I'm not sure
 * ogra_cmpc neither ... thats why i said i think :)
<rsalveti> disabling it from init is enough to get it removed and avoid oom
 * ogra_cmpc goes to check
<rsalveti> so probably doesn't run inside uinitrd
<rsalveti> but :-)
<rsalveti> please check
<ogra_cmpc> rsalveti, right, only from init
<GrueMaster> It does.  I get "init: ureadahead main process (208) terminated with status 5" before it mounts rootfs.
<ogra_cmpc> thats fine
<ogra_cmpc> GrueMaster, that doesnt mean a thing about the initrd though, there could be a process that hands over data after the initrd for example
<ogra_cmpc> thats why i rather look at the code to make sure :)
<sakoman> rsalveti: I push a revised patch that fixes both 37XX and OMAP4 u-boot reset command issues:
<sakoman> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=56473fba8010c5def9ed778da4bcb4455d265b54
<rsalveti> GrueMaster: ogra_cmpc: exit 5 means that the trace failed, for some reason
<ogra_cmpc> rsalveti, according to Keybuk thaqts because its MMC
<ogra_cmpc> i asked him about it a few months ago, he said we shouldnt worry about it, it properly exits
<rsalveti> sakoman: cool :-)
<rsalveti> ogra_cmpc: hm...
<ogra_cmpc> rsalveti, i thinki we should talk to him soon so he can explain the possible benefits for us
<ogra_cmpc> i dont really see any
<rsalveti> if any
<ogra_cmpc> snap :)
<rsalveti> ogra_cmpc: sure, we first need to know when he is going to release the new major release
<rsalveti> ureahead 2 I guess
<ogra_cmpc> likely not during beta freeze
<rsalveti> but probably for maverick
<ogra_cmpc> thats what he said
<rsalveti> hm, ok
<rsalveti> but sure, lets talk to him later
<ogra_cmpc> the question is if it will work any better then :)
<persia> So, ureadahead is good because RAM is faster than flash is faster than {e,}MMC-mitgated flash.
<ogra_cmpc> persia, is it ? you still need to read from the SD
<rsalveti> persia: doesn't make a difference for beagle
<persia> So getting stuff into the page cache in advance always makes boot faster (and ureadahead doesn't read anything that isn't read anyway)
<rsalveti> sd is so slow that it really doesn't make a difference
<persia> ogra, The point is that you don't have to *wait* on reading from the SD.
<rsalveti> the seek is not the issue here
<ogra_cmpc> persia, only if things end up in the cache in time
<rsalveti> as a normal disk
<persia> rsalveti, that's because the beagle doesn't meet the minimum ram requirements (384MB)
<rsalveti> 384?!
<persia> Yep.
<ogra_cmpc> yeah
<rsalveti> funny number
<persia> Been 384 since Breezy or so.
<persia> 3x128.
<ogra_cmpc> 384M is the minimum the x86 livecd works in
<rsalveti> I know, but still funny
<rsalveti> persia: ogra_cmpc: I'd like to test at a valid xm (512mb) to see if changes anything
<ogra_cmpc> right
<rsalveti> and compare the bootchart
<ogra_cmpc> i really doubt it
<rsalveti> 2
<ogra_cmpc> the IO is to slow to gain any benefit form it is my impression
<GrueMaster> Well, any suggestions on where to go?
<ogra_cmpc> outside into the sun ?
<persia> It helps best when the IO is slow, because it means *not* spending time without full IO bandwidth in use.
<rsalveti> lol
<rsalveti> persia: doesn't help much
<ogra_cmpc> persia, how so if your bandwith is saturated all the time anyway
<persia> Mind you, it's Keybuk's code competing with Keybuk's code: ureadahead is only advantageous when upstart fails to use all available IO.
<rsalveti> helps a *lot* with normal disks, because the seek time
<rsalveti> not much from sd
<rsalveti> at least didn't show any difference on my bootchart when caching 64 mb
<rsalveti> even more
<rsalveti> but, still waiting for a xm test
<persia> ogra, If upstart can saturate the IO without ureadahead, then it makes no difference, but Keybuk isn't trying to saturate IO with upstart because he assumes ureadahead will do that (ureadahead is specifically designed to saturate the IO)
<prpplague> rsalveti: you guys have a preference where you want to have a pandaboard revision in sysfs?
<rsalveti> can test on panda later
<rsalveti> prpplague: hm... interesting question
<rsalveti> ogra: GrueMaster: ^
<GrueMaster> I have nrp.
<ogra_cmpc> no idea, really, i personally dont have one
<ogra_cmpc> as long as i know where to look in the end :)
<rsalveti> prpplague: my question is more with which device do you think of pluging this file into?
<persia> Where does this information live for other boards.  Let's strive towards some consistency throughout the industry.
<ogra_cmpc> yeah
<GrueMaster> I would suggest looking at existing systems for consistency.
<rsalveti> proc can be anywhere, but sysfs you need to use a valid device
<prpplague> persia: yea that was my question as well, but i can't seem to find any examples
<rsalveti> probably no examples
 * rsalveti never saw it
<ogra_cmpc> likely, else we woldnt parse /proc/cpuinfo for hardware detection
<ogra_cmpc> (on all armel systems)
<rsalveti> prpplague: is it related with gpios like beagle?
<prpplague> rsalveti: yea
<prpplague> rsalveti: same type of config
<persia> I think that there isn't a standard place (checked 3 arches just now for a variety of HW).  I think most folks just enumerate the devices, and don't actually discuss which board is providing those devices.
<ogra_cmpc> prpplague, currently all tools we use parse the Hardware line of /proc/cpuinfo
<GrueMaster> prpplague: I'm not seeing any specific standard compared to multiple systems I have here.
<persia> Then we autodetect what we can do based on the devices.
<persia> So that board mapping becomes fuzzy, based on the set of peripherals exposed.
<prpplague> thats what i thought , but i was told by "someone" (not sure who) that canonical wanted a sysfs entry
<ogra_cmpc> i wouldnt mind one to set a new standard
 * persia wonders what they were thinking
<rsalveti> prpplague: hm, for gpio there is the omap-gpio...
<ogra_cmpc> the /proc/cpuinfo parsing can be really tricky if you miss a tab or space or so
<rsalveti> maybe we can probe it if we can have access to the gpio values from userspace
 * rsalveti prefers not touching proc/cpuinfo
<persia> ogra, Why?  I'd rather map devices, so that if someone creates $random_board with the same SoC as a panda, and the same peripheral devices, it gets the same support, without lying about itself.
<prpplague> ogra_cmpc: might have to generate a new class device
<rsalveti> prpplague: could be
<rsalveti> or letting userspace to decide by probing the gpios
<persia>  /sys/class/ is where it'd belong, but I'd be unhappy to see Ubuntu use it.
<ogra_cmpc> persia, sure, but having a file thats easier to parse with a predefined entry might make thiings easier
<persia> ogra, For all the same reasons that I argue against all the embedded development practices that make things easier short-term for folks building one-off solutions, I reject that entirely.
<rsalveti> GrueMaster: what issue did you have after upgrading the packages?
<rsalveti> I updated my panda and now it doesn't boot anymore
<rsalveti> seems like an upstart issue
<GrueMaster> Yep, that's what I am seeing.
<GrueMaster> I updated upstart before ureadahead.
<GrueMaster> The fact that it doesn't appear to be going beyond mounting root is what puzzles me.
<rsalveti> GrueMaster: it mounts the rootfs here
<rsalveti> tries to start postfix and hangs
<rsalveti> disable postfix and now I can only see the hang :-)
<rsalveti> I'm creating another minimal rootfs with rootstock to see if I didn't mess with anything
<ogra_cmpc> try downgrading it
<rsalveti> I had an old rootfs there
<ogra_cmpc> (either chroot into the SD on an x86 or dpkg -x the older upstart into /mountpoint/of/SD
<ogra_cmpc> )
<rsalveti> yep
<rsalveti> and debug upstart
<rsalveti> oh.. how I love it
<ogra_cmpc> yesah
<ogra_cmpc> well, lets bug Keybok if its really upstart, he is usually helpful (if he gets online :P)
<rsalveti> yeah, but first we need to identify if our problem is upstart
<ogra_cmpc> well, if downgarding the package fixes it ...
<GrueMaster> I have a definite advantage here.  Babbage w/ two SD slots.
<rsalveti> yep
<rsalveti> lots and lots of issues on our current image :-(
<ogra_cmpc> yes :(
<rsalveti> it's going to take a while to be able to test efl with sgx and stuff asac asked us to do
 * ogra_cmpc goes back to his midnight dinner
<rsalveti> see ya
<GrueMaster> rsalveti: if you send me the cmdline for rootstock, I can build my own image for the XM here.  Much faster as I have my own mirror server.
<rsalveti> GrueMaster: I'm just finishing putting everything into my sd card, then will dd from it
<rsalveti> so others can test
<rsalveti> but if you want, this is how I'm generating it: ./rootstock --fqdn beaglexm-maverick --login ubuntu --password ubuntu --dist maverick --serial ttyS2 --components "main universe multiverse" --seed linux-image-omap
<rsalveti> use rootstock upstream
<prpplague> rsalveti / ogra_cmpc / GrueMaster :  http://paste.ubuntu.com/484226/
<prpplague> pandaboard revision reporting
<prpplague> it reports it as part of the boot up
<prpplague> and has the board revision available under /sys/kernel/pandaboard/board_revision
<prpplague> any issues with that?
<rsalveti> I'd prefer something more generic, like /sys/kernel/board/revision
<rsalveti> and then inside you'll have pandaboard: 0.1
<rsalveti> for example
<rsalveti> because then we can later use that for beagle
<GrueMaster> rsalveti: Thanks.
<prpplague> understood, making the change now
<GrueMaster> prpplague: I have to agree with rsalveti on that one.
<prpplague> np
#ubuntu-arm 2010-08-27
<prpplague> two line paste
<prpplague> PandaBoard Revision: 001
<prpplague> oops
<prpplague> PandaBoard Revision: 001
<prpplague> well darn
<prpplague> GrueMaster / rsalveti  http://paste.ubuntu.com/484228/
<GrueMaster> nice.
<prpplague> question though, do you want it more human readable, or more parse friendly
<GrueMaster> now to get other arch/platforms to follow suit.
<prpplague> i.e. should i just report revision without referencing pandaboard?
<GrueMaster> no, platform/revision is great info.
<prpplague> okie dokie
 * prpplague gets ready to send patch to L24.9 team
<GrueMaster> This way we can differentiate between systems (i.e. Blaze/Panda or Beagle/BeagleXM/Gumstix, etc).
<GrueMaster> I'm assuming this info is gathered through probing the system & using a lookup table of some sort?
<rsalveti> argh, my system is trashing... very slow
<rsalveti> opening the link
<rsalveti> prpplague: cool :-)
<prpplague> GrueMaster: 3-bit value on three gpios
<GrueMaster> ok
<rsalveti> prpplague: if we have a separator like : I guess it's ok for parsers
<rsalveti> name : version
<prpplague> rsalveti: thats what i was thinking
<rsalveti> or something like that
<prpplague> rsalveti: i was thinking
<prpplague> rsalveti: something like this
<prpplague> boardname - revision : revisionnumber
<prpplague> PandaBoard - revision : 001
<prpplague> is it that too much?
<prpplague> just leave it
<prpplague> PandaBoard : 001
<rsalveti> hm
<rsalveti> don't know, most of the time just the revision should be ok
 * GrueMaster finds nothing wrong with the pastebin version.
<rsalveti> like beagleboard: c4
<rsalveti> pandaboard: es1
<rsalveti> an example
<prpplague> yea
<prpplague> ok, do the KISS thing
<rsalveti> :-)
<rsalveti> always
<GrueMaster> rsalveti: Back to the image issues, I am really having doubts as to what could be breaking the system.  I created a manifest of the A3 image and compared it with 20100809 (first failing image).  Upstart & ureadahead are unchanged.
<rsalveti> hm...
<rsalveti> maybe a dependency between the upstart services
<rsalveti> waiting for something that doesn't get started
<rsalveti> debugging upstart would be the way to go
<GrueMaster> testing new theory.  We now have a new oem-config apparently.  Will flash 20100809 image and update oem-config on it.
<GrueMaster> Two issues that I have seen; latest images fail oem-config and updating from A3 fails to boot.  I doubt there is any relation to the two.
<GrueMaster> too many variables and not enough fast test systems.
<rsalveti> now I can see 20100826.1
<rsalveti> will also download it
 * GrueMaster has spent a frustrating 2.5 weeks on this issue.
<rsalveti> :-(
<rsalveti> sd card performance is frustrating
<GrueMaster> Yes.  Very.
<GrueMaster> Even on my desktop.
<rsalveti> GrueMaster: 152K/s of download is also frustrating
<GrueMaster> yes.  Which is why I have my own mirror.
<rsalveti> but this is for the image files
<rsalveti> I have a cache server around
<GrueMaster> 1Gb network throughout the house also helps
<rsalveti> for normal stuff
<rsalveti> for sure
<rsalveti> but an sd card with 3, 4m/s doesn't help
<rsalveti> haha
<GrueMaster> I mirror both.  And retain dailys until final.
<GrueMaster> Not that arm dailys take much room given the pool churn.
<rsalveti> yep, will start mirroring the image stuff
<rsalveti> the problem is that my stupid internet provider limits the amount of gb per month
<rsalveti> I can download only 80gb I guess
<rsalveti> with a 10m/s link
<rsalveti> so I avoid doing mirror and downloading only what's needed
<GrueMaster> ouch.  Some in the US are doing the same.  Fortunately, my ISP has been around since early '90s and has a fat pipe.
<rsalveti> that's nice
<rsalveti> with my previous provider I didn't have this issue, but doesn't reach my current city
<rsalveti> so I had to change to the stupid one
<GrueMaster> I'm currently limited by DSL speeds.  Which out here in the sticks is ~6.5M/768k
 * GrueMaster wishes he could get FIOS.
<rsalveti> mine is currently 10/1 m/s
<GrueMaster> nice
<persia> rsalveti, What blocks getting newest rootstock upstream into Ubuntu?
<rsalveti> persia: a new release? :-)
<rsalveti> persia: just 2 simple bug fix, still need to get some work at the ui to create a new release
<persia> You don't happen to know any upstream rootstock folk that might feel like rolling a release, do you?
<rsalveti> persia: it works fine with our version, but with upstream you'll always get the initrd and vmlinuz outside the rootfs
<persia> Ah, makes sense.  Best to get the FFe filed *before* beta-release, as otherwise getting it into maverick will be sticky.
<rsalveti> that's why I said GrueMaster to try it
<rsalveti> easier to run mkimage later
<rsalveti> persia: can you buy me some time? :P
<persia> Unfortunately, time and tuits are the two things of which I currently have shortages :(
<rsalveti> I'd love to do it, but have more important issues do solve atm
<rsalveti> yup :-(
<GrueMaster> rsalveti: Running now (got sidetracked by lack of lunch).
<rsalveti> GrueMaster: with latest minimal image it boots...
<rsalveti> let me start the upstart debugging session
<GrueMaster> Looks like rootstock finished ok.
<rsalveti> :-)
<GrueMaster> oops.  All three of my microSD cards are preoccupied atm.  hrm.
<GrueMaster> Gahhh.  Brb.  Need to start dinner (roast).
<persia> Anyone good at picking the right place to drop casts for qreal != double issues?  Seems like the outstanding bit for koffice.
<rsalveti> argh, nothing works today
<GrueMaster> Ok, roast is now...roasting.
<persia> Which part of nothing is most annoying at the moment?
<rsalveti> haha, like boards not booting? :-)
<GrueMaster> I get that all the time.
<persia> Oh yeah.  that one.  This is why we need large volumes of consumer-grade hardware (although I think I once heard a story about a chicken and an egg...)
<GrueMaster> I just file bugs and let the engineers fix it.  Oh, wait...
<rsalveti> ...
<GrueMaster> :P
<rsalveti> that's weird, I can't see 20100826.1 anymore
<rsalveti> wtf
<rsalveti> some times it works, some times it doesn't
<rsalveti> persia: any clue?
<persia> transparent proxies should be removed, and everyone should use IPv6 with endpoint verification.
<rsalveti> argh
<rsalveti> and the weird thing is that my current wget is still working!
<rsalveti> but I can't browse this link
<rsalveti> clean cache, different browsers
<rsalveti> just can't
<persia> Once you get a hit that works, it will be fine.  But stale/erroneous cache data needs to wait for timeout to pass.
 * persia forgets how to trick those offhand
<rsalveti> yep
<rsalveti> GrueMaster: weird, it hangs completely
<rsalveti> the kernel, serial, everything
<persia> rsalveti, Alternate thought: tell me which file you seek, and I can probably give you a deep URL (which may not be cached)
<rsalveti> persia: now I'm able to download it! haha
<rsalveti> persia: for the fs I'm still looking for it
 * persia fails at parsing
<rsalveti> nevermind :-)
 * rsalveti needs a lot more coffee
<persia> Or a good night's sleep...
<rsalveti> well, that'd help, for sure
<cooloney> rsalveti: you work so late and hard, man
<cooloney> rsalveti: do you have chance to test the 2.6.35 on your es2?
<rsalveti> cooloney: well... nothing better to do haha :-)
<rsalveti> cooloney: not yet, too much problems during the day
<rsalveti> cooloney: do you have a binary?
<rsalveti> I can easily test
<cooloney> rsalveti: i got an update patch from sebjan, will try to build again.
<cooloney> rsalveti: if i am ready, i will post the url for you, thx
<rsalveti> cooloney: cool, just ping me when you're done
<rsalveti> hm, installed network-manager and rebooted, now it hangs
<persia> Excellent!  Uninstall network-manager (from a cross-chroot mounted on something else), and see if that unhangs.
<rsalveti> that's what I'm doing now
<rsalveti> but got many other packages installed as a consequence, but let's se
<rsalveti> see
<persia> That's OK.  We can dig through dpkg.log, and find the responsible party.
<rsalveti> GrueMaster: persia: seems to be dbus, will test more
<persia> That's what ogra was finding
<rsalveti> yep, will try to identify why
<GrueMaster> Sorry, had to take a break.  Odd that dbus is giving you guys grief.  I had updated that a couple of days ago and it has worked fine.
<rsalveti> yep, it's dbus :-)
<rsalveti> initct dbus start -> hangs
<rsalveti> *initctl
<rsalveti> or some dependency from upstart
<persia> Excellent!  Can you get a strace?
<rsalveti> checking again
<rsalveti> will try
<GrueMaster> Is it dbus or network-manager?  Like I said, I updated dbus a couple of days ago while slowly churning through the 400+ package updates.  Didn't hang until network-manager update.
<rsalveti> network-manager
<GrueMaster> But oddly it doesn't appear to start anything after mounting root.
<rsalveti> removed the dbus dependency and it started fine
<rsalveti> not networkmanager got the hang
<persia> It's obviously dbus if "initct dbus start -> hangs"
<persia> Might only happen in combination with other stuff, but strace should tell us.
<rsalveti> nops, remove the dbus trigger from networkmanager
<rsalveti> then started by hand
<rsalveti> and it hang
<persia> stack trace (rather than syscall trace) would be better, but hard to get for a hang.
<rsalveti> so it's probably nm
 * persia suspects two bugs, rather than one
<rsalveti> let me start nm with strace or logs
<rsalveti> could be related with dbus also, on how it's using it
<rsalveti> but would say it's closer with nm
<rsalveti> let me check
<rsalveti> 1 sec
<persia> Please strace the initctl hang first: that's lower level.  it7s not worth masking it in nm if that makes it hard to find the dbus part.
<rsalveti> one thing at a time
<rsalveti> I want to first find the binary that's causing this
<rsalveti> then we can trace that
<persia> Honestly, strace the symptom.
<persia> if you set strace to follow, you'll track over *many* binaries.
<persia> then dpkg -S will tell you the package.
<persia> Saves time doing it twive.
<rsalveti> but for that I'd have to trace upstart
<rsalveti> and not initctl start dbus
<rsalveti> because when dbus is started, upstart tells nm to start
<rsalveti> and that hangs
<GrueMaster> hrm.  Having power & serial console on XM is not fun.
<persia> Right.  strace -f -p ...
<persia> Then run initctl, and wait for the hang.
<persia> then check the strace to find out what hung it.
<persia> then dpkg -S to find the offending binary.
<GrueMaster> rsalveti: Did you need to use a null modem with your XM?
<rsalveti> GrueMaster: nops
<rsalveti> usb-serial only
<rsalveti> same for panda
<GrueMaster> Ok.
<GrueMaster> Oops.  Forgot xloader & uboot.  That would explain things.
<rsalveti> GrueMaster: :-)
<GrueMaster> I only appear to be getting garbage on serial
<GrueMaster> Same xloader & uboot as on the daily for beagle, right?
<persia> speed?
<rsalveti> GrueMaster: yep
<GrueMaster> Serial works fine on the beagle.
<GrueMaster> Not on XM
 * GrueMaster was worried that the exterior renovations done with the dremel may have fouled serial usb adapter.
 * persia wishes koffice would build faster.
<GrueMaster> sigh.   Time to fix dinner.  Back later.
<persia> GrueMaster, You still have spare buildd cycles about?
<persia> Ah, not now :)
<rsalveti> persia: GrueMaster: interesting, the hang happens when NM tries to activate the usb0 interface
<rsalveti> if I give ifconfig usb0 up before initializing NM everything goes well
<rsalveti> but if I try to load it directly, it'll hang when trying to activate the usb0
<persia> What's the last syscall before it hangs?
<rsalveti> a sendmsg to a socket
<rsalveti> could be dbus
<persia> Which PID does the sendmsg?
<persia> And is the specific socket referenced earlier in the strace so you can determine if it's dbus?
<rsalveti> cooloney: can you share the binary of your 2.6.35 kernel that works with your es1?
<rsalveti> persia: sometimes just ifconfig usb0 up and ifconfig usb0 down gets the problem
<rsalveti> the problem is that NM gives up to probe information and then put it down again
<rsalveti> and put it up to configure
<rsalveti> and this sequence is giving the issue
<rsalveti> nm was updated, so this new sequence could be affecting ups
<persia> Right.
<persia> I'd suggest first concentrating on the ifconfig bit.  Once that's sorted, let's see if the other bugs are still present.
<rsalveti> sure, that's what I'm doing
<persia> It's clearly unsafe coding, but ifconfig should never cause a hang anyway, and that's the bit talking to the kernel, which is making the system hang (rather than just e.g. NM)
<rsalveti> sure
<rsalveti> that's why I want to test with latest kernel
<rsalveti> from ti
<persia> Is there a way to force a kerneloops during a hang?  I get lost when it gets to that level.
<rsalveti> depends on the kind of hang
<rsalveti> problem with code generally can show the trace and so on
<rsalveti> but if the problem happens while communicating with the device, than things can be harder
<persia> Not surprising.  I get confused as soon as I get below syscalls (and usually can only solve hangs where strace is looping, or waiting indefinitely for a response that will never come), rather than on the other side, but I imagine there's a few more barriers as one approaches control lines on hardware.
<cooloney> rsalveti: it is quite slow for me upload my package, damn it.
<rsalveti> it seems a kernel bug at the ethernet driver
<rsalveti> will take a better look at the down code
<rsalveti> it hangs when giving the ioctl to put the interface down
<cooloney> rsalveti: http://people.canonical.com/~roc/kernel/omap4-2.6.35/
<cooloney> rsalveti: finally uploaded. it is cross compiled
<rsalveti> cooloney: nice, does it work fine with your es1?
<cooloney> it boots up on my es1 and works fine with my maverick rootfs.
<rsalveti> cool
<cooloney> but not tested it on daily image
<rsalveti> let me try it
<cooloney> ok, thx
<rsalveti> np, I'm using a minimal one atm
<rsalveti> cooloney: do you have your usb working?
<rsalveti> doesn't work for me
<rsalveti> and the ethernet needs usb
<rsalveti> :-(
<cooloney> rsalveti: too bad, doesn't boot at all?
<rsalveti> it boots, but doesn't work with usb
<rsalveti> that that was the test I wanted to run
<rsalveti> but thanks anyway
<cooloney> oh, thx, for that. could you post your dmesg somewhere?
<cooloney> i will discuss this with sebjan
<rsalveti> cooloney: http://paste.ubuntu.com/484321/
<cooloney> OMAP4430 ES1.0, is it ES2.0?
<cooloney> I assume it is ES2.0, rsalveti
<rsalveti> cooloney: es1
<rsalveti> cooloney: I wanted to test on the board I know we have issues atm
<rsalveti> :-)
<GrueMaster> persia: yes, I have the dove ready for building.
<rsalveti> cooloney: I can test your deb on my es2 if you want
<rsalveti> just a sec
<rsalveti> cooloney: usb works with es2
<rsalveti> will reply your email
<rsalveti> let me test it with 1gb
<cooloney> rsalveti: great, man. thx for the testing in your mid night, i think
<cooloney> sebjan: told me he fixed some EHCI or USB configuration on ES2.0, so maybe ES1.0 got some issue.
<rsalveti> cooloney: hah, yeah
<rsalveti> cooloney: oh, cool
<rsalveti> they were also working on other things yesterday
<rsalveti> mostly display and sound issues
<rsalveti> let me put that on the email
<cooloney> cool, man, thx a lot
 * cooloney needs some food for his lunch
<rsalveti> cooloney: sent
<persia> GrueMaster, Excellent, although I found somewhere else to run that.  I'll let you know if I think I have another one solved.
<persia> (but it might be too late by then)
<GrueMaster> persia: If you are looking at ftbfs issues, can you check into ubiquity?  I looked at the lp page, and it indicates a version of ubiquity-frontend-gtk-2.3.8 was built 7 hours ago, but there are no armel packages
<persia> https://launchpad.net/ubuntu/+source/ubiquity/2.3.8/+build/1935852
<rsalveti> GrueMaster: ogra: lag: if you want usb with ES2 uses cooloney kernel, at http://people.canonical.com/~roc/kernel/omap4-2.6.35/linux-image-2.6.35-903-omap4_2.6.35-903.8_armel.deb
<rsalveti> with mine (2.6.34) it doesn't work
<rsalveti> ogra: lag: the hang while booting ("dbus" hang):  bug 625108
<ubot2> Launchpad bug 625108 in linux-ti-omap4 (Ubuntu) "System hangs when you run ifconfig usb0 up and ifconfig usb0 down (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/625108
<rsalveti> I'm still looking at it, but I can confirm that it doesn't happen with ES2 and cooloney's kernel
<rsalveti> and the driver didn't get any major changes between 2.6.34 and 2.6.35, so it could be related with the board
<rsalveti> ogra: regarding gdm, just now I got a "working" system that I can check this, and the only thing I saw is that doesn't get started
<rsalveti> Aug 27 04:13:46 acorn init: gdm goal changed from stop to start
<rsalveti> Aug 27 04:13:46 acorn init: gdm state changed from waiting to starting
<rsalveti> but that's all
<rsalveti> please continue the debugging and I can help looking into that tomorrow
<GrueMaster> rsalveti: Don't you sleep?
<rsalveti> GrueMaster: ogra: another interesting thing is that the hostname is now "localhost" but I can still get the builder's name at the messages
<rsalveti> GrueMaster: I try, but doesn't work that well with me :-)
<GrueMaster> That gets changed by oem-config.
<rsalveti> I know, but if we want to avoid having the builder's name logged, we should fix that
<GrueMaster> Too much Brazilian coffee.
<GrueMaster> I need some.  :P
<rsalveti> and messages I say the syslog messages of the first boot
<rsalveti> GrueMaster: haha, possible
<rsalveti> I can try to get you some at uds :-)
<rsalveti> or even before, it all depends on ti :-)
<GrueMaster> Sorry, can't make it.  Wife hexed me into a cruise.
<GrueMaster> TI maybe.
<rsalveti> ouch, true
<rsalveti> too bad
<GrueMaster> When I mentioned UDS and conflict in the same sentence, she started speaking in tongues and I swear her head spun a few times.
<rsalveti> lol
<GrueMaster> Currently testing the new oem-config fixes on babbage then off to bed.  Seams to work again.  I have hope that we might have a working image again soon.
<GrueMaster> "Starting PC Card Services..."  We really need to clean up the image next release.
<rsalveti> can't make oem-config to run here
<rsalveti> because of gdm it seems
<GrueMaster> Which version of oem-config?  2.3.8 is latest.
<rsalveti> hm, 2.3.7
<GrueMaster> Just finished.  Now to see if GDM starts.
<GrueMaster> Oop, removing packages.
<rsalveti> cool, good luck
<rsalveti> need to go now
<rsalveti> see ya in some hours
<GrueMaster> yea, understand.
<GrueMaster> get some sleep.
<GrueMaster> Yea, I now have a booting image again.  20100826.1 + oem-config updates are running on babbage.  Very encouraging.  Night all.
<mythripk> Morning All, If you any of you are interested in having a look at omap4 TRM it is now in http://focus.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12667
<lag> <rsalveti> 07:04:39> ogra: lag: the hang while booting ("dbus" hang):  bug 625108
<ubot2> Launchpad bug 625108 in linux-ti-omap4 (Ubuntu) "System hangs when you run ifconfig usb0 up and ifconfig usb0 down (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/625108
<lag> Doh
<lag> <rsalveti> ogra: lag: the hang while booting ("dbus" hang):  bug625108 <- I don't have working Panda
<lag> ES1.0
<ogra> :(
<lag> ogra: Is there anything wrong with this line?
<lag> sudo mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.script boot.scr
<ogra> looks ok to me
<lag> Weird
<lag> It's churning out boot.scr's with no header?
<ogra> lag, why sudo ?
<lag> Does it make a difference?
<ogra> no ideas
<lag> I'll try
<ogra> never used sudo with mkimage
<lag> Didn't make a difference
<lag> Still no header
<lag> Ah
<lag> No
<lag> It's just that cat doesn't print it
<lag> Emacs displays it fine
<ogra> and cat or less dont ?
<lag> cat doesn't
<lag> less does
<persia> what nonprintables do you have in it?
<persia> Maybe `TERM=dumb cat ...`?
<lag> '^E^YV<A7><a.Lwmm^@^@^A^U^@^@^@^@^@^@^@^@<80><C8>Î^E^B^F^@Ubuntu boot script^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^M^@^@^@^@
<lag> :)
<lag> It's okay
<lag> I can use less/emacs
<persia> Yeah, cat should show that with TERM=dumb
<lag> It's not a problem
<lag> So long as I know
<lag> ogra: When do you think the oem-* bug will be fixed?
<ogra> lag, i just kicked off a build
<ogra> it shoudl be fine in the next image
<ogra> though the usb0 bug will hit us hard
<lag> Which usb0 bug?
<ogra> do you read the channel backlog if you get up ?
<persia> That ifconfig up usb0; ifconfig down usb0; ifconfig up usb0 hangs the machine.
<ogra> its a useful practice ;)
<lag> ogra: No
<persia> bug 625108
<ubot2> Launchpad bug 625108 in linux-ti-omap4 (Ubuntu) "System hangs when you run ifconfig usb0 up and ifconfig usb0 down (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/625108
<lag> Well, I flick though
<lag> Usually it's dribble
<persia> (which you mentioned to us earlier, so you ought have seen it)
<lag> d
<lag> Does this happen with TI's new patches?
<persia> Hard to say.  The reporter went to bed.
<lag> I'll give it a go
<persia> Try it with TI's new patches and find out :)
<lag> This is Panda ES1.0
<lag> I was under the impression that all support for ES1.0 is to be halted?
<persia> Bug report is for ES1.0.  I'm not sure it's been tested with ES2.0
<persia> Perhaps, but let's make sure the bug is ES1.0 only before we ignore it :)
<ogra> hmm, theer is no bug about the dbus hang ?
<ogra> lag, tricky for beta we dont have es2 yet
<persia> The dbus hang is dbus running NM init once dbus<->NM comes up, which is NM hanging on configuring usb0, which is 625108
<ogra> lag, so i guess beta has to stay es1 ... also we dont have bootloader or kernel for es2
<persia> rsalveti spent hours hunting it down specifically.
<ogra> persia, hmm, i thought i saw initctrl mentioned above
<ogra> yes, i see that
<persia> Right.  initctl start dbus hangs the machine, by the process I just described.
<ogra> ok, then its fine with me ... just not sure what to do ...
<persia> kernel bug.  lag's on it.
<ogra> apart from disabling usb0 :)
<persia> Let's give lag a couple hours to hunt before we use the big hammer :)
<ogra> persia, lag doesnt have working usb, no ?
<ogra> (on the es1)
<persia> Ugh.
 * persia dreams of a day when mass commercial HW is available, and all these niggles go away
<ogra> natty FTW :)
<lag> lag, so i guess beta has to stay es1 ... also we dont have bootloader or kernel for es2 - <Yes we do>
<ogra> lag, show me the package on ports.ubuntu.com please
<ogra> *packages
<lag> <rsalveti> 07:06:13> and the driver didn't get any major changes between 2.6.34 and 2.6.35, so it could be related with the board
<lag> Don't you read your back-log? =;-)
<ogra> Well, I flick though
<ogra> :P
<lag> That's the wrong message
<lag> Doh
<lag> <rsalveti> 07:05:01> I'm still looking at it, but I can confirm that it doesn't happen with ES2 and cooloney's kernel
<lag> That's the one I meant to post
<ogra> doesnt really help
<ogra> we need to have booting images by thu. no matter what
<ogra> and since we only have software for es1 it needs to be es1 images
<lag> I can't help you there I'm afraid
<lag> The ES1.0 will boot, it just won't have USB working
<ogra> is the NIC driver a module so we can at least blacklistz it ?
 * ogra can apply a jasper hack that puts a blacklist file in place
<lag> You know the NIC drivers needs USB right?
<ogra> that wasnt my question :)
<ogra> is it modular so we have a worst case solution to get the images booting again ?
<lag> I don't believe it is
<ogra> damned
 * ogra goes to get more coffee while the images build
<lag> CONFIG_USB_NET_SMSC95XX=y
<persia> What happens if we make that =m ?
<persia> Should get us booting, and then we can track down other stuff whilst sorting the problem.
<lag> The world implodes
<persia> Ah.  That may impair a few things.
<lag> I don't know
<lag> But do you want to get that config change though SRU?
<persia> Could you find out?  The other option is trying to tell NM to ignore usb0.
<persia> Sure.  Without it, there's no booting images.
<persia> So no beta.
<lag> I can't give anything a go ...
<lag> I don't have a working ES1.0
<persia> But let's let ogra come back: he's more awake than me, to document the issue.
<persia> Ah.
<cooloney> lag: from the kernel dmesg on my es1, i found
<cooloney> [    1.573303] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<cooloney> [    1.580200] ehci_hcd: block sizes: qh 60 qtd 96 itd 160 sitd 96
<cooloney> [    1.580322] ehci-omap ehci-omap.0: failed to get ehci port0 regulator
<cooloney> [    1.580322] ehci-omap ehci-omap.0: starting TI EHCI USB Controller
<cooloney> [    1.580352] ehci-omap ehci-omap.0: failed to start ehci
<ogra_cmpc> lag, SRU ? you mean asking for a freeze exception
<cooloney> it looks like we missed some ehci port0 regulator configuration or driver?
<cooloney> lag: any idea about that? maybe it cause our USB failed.
<lag> cooloney: You'll have to fix it - I don't have an ES1.0 :(
<ogra_cmpc> died you send back both already ?
<ogra_cmpc> *did
<cooloney> lag: got it, man
<lag> ogra_cmpc: Nope, they are both here on my shelf
<lag> cooloney: Does your HDMI port work with the current image?
<ogra_cmpc> lag, well, the one with broken HDMI might have working USB ;)
<ogra_cmpc> and surely has working serial
<lag> ogra_cmpc: That's what I was thinking
 * ogra_cmpc curses TIs timing ... 
<ogra_cmpc> if we only would have been having everything (HW/SW) one week earlier ....
<ogra_cmpc> cooloney, will we get the new sebjan tree uploaded before beta ?
<cooloney> ogra_cmpc: when is the beta, i guess we are going to upload it soon
<ogra_cmpc> beta is on thu but we need the package earlier, i think serious images are due monday or so
<cooloney> ogra_cmpc: next thu? or yesterday.
<ogra_cmpc> yesterday was beta feeeze, next thu is beta release
<cooloney> oh, i c.
<cooloney> i am not sure about that.
<cooloney> still need to fix audio issue and this USB issue
<ogra_cmpc> we wont have probs to get an upload approved but it need to happen very soon
<ogra_cmpc> *needs
<ogra_cmpc> does the audio issue block anything apart from the obvious ?
<ogra_cmpc> else i'd say keep that for post beta
<lag> ogra_cmpc: FATAL: Could not load /lib/modules/2.6.35-903-omap4/modules.dep: No such file or directory
<ogra_cmpc> we can live with non working audio for beta
<ogra_cmpc> lag, you package should have called depmod during package install
<ogra_cmpc> looks like a bug in the klinux package
<ogra_cmpc> *linux
<lag> ogra_cmpc: I'm installing on my chroot
<ogra_cmpc> doesnt matter, the postinst of the package should call depmod
<lag> Do I just need to copy over the *.dep file from the shroot to the SD card to get it to work
<ogra_cmpc> that might workm, though i'd just call it on the SD
<persia> Better to call depmod afresh.  Less prone to oddities.
<cooloney> ogra_cmpc: i just got 2 patches from sebjan to fix audio issue,
<ogra_cmpc> cooloney, ah, cool
<cooloney> maybe we can fix it soon
<lag> It turns out that pivot-root isn't console specific - Doh!
<ogra_cmpc> pivot-root ???
<lag> I just pivot-root(ed) into an Arm /
<ogra_cmpc> ubuntu hasnt used pivot-root since 2004
<lag> I wanted to use it
<lag> To run depmod
<persia> Why not chroot?
<ogra_cmpc> yeah, i was about to ask :)
<lag> Because you can't specify the out dir
<lag> of depmod
<persia> The "out dir"?
<ogra_cmpc> ??
<lag> Oh, can you chroot into a given /
<lag> Rather than a saved one
<lag> Hold on
<ogra_cmpc> sudo chroot /target/chroot depmod -a
<ogra_cmpc> (needs qemu-arm-static installed for armel chroots)
<lag> I have that
<persia> And you need to copy the interpreter
<lag> But my usual chroot != /SDCard/rootfs
<persia> So?
<persia> chroot takes the target on the command line
<ogra_cmpc> mount /dev/mmcblk0p2 /target/chroot ;)
<lag> I didn't know you could chroot into random directories
<persia> that's the point :)
 * lag shrugs 
<lag> Every day's a school day
<persia> If you don't need that flexibility, schroot is probably more feature-rich.
<lag> sudo schroot /media/rootfs/
<lag> E: default: Chroot not found
<lag> Ahhhhhhhhhhhh, that's the difference between schroot and chroot
<lag> root@system1:/# uname -a
<lag> Linux system1 2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:12:52 UTC 2010 armv7l GNU/Linux
 * ogra_cmpc applauds
<lag> ogra_cmpc: Sarky baboon
<lag> It still doesn't work
<lag> WARNING: Couldn't open directory /lib/modules/2.6.32-24-generic: No such file or directory
<lag> Wrong kernel
<ogra_cmpc> man depmod :)
<lag> -v?
<ogra_cmpc> no
<lag> version
<ogra_cmpc> the manpage summary at the top is a bit confusing i admit
<ogra_cmpc> right just give the version
<ogra_cmpc> no -v
<lag> Oh, they're separate arguments
<lag> They should be separated
<ogra_cmpc> the text below makes it clearer
<ogra_cmpc> If a version is provided, then that kernel version's module directory is used rather  than  the  current
<ogra_cmpc>        kernel version (as returned by uname -r).
<lag> Who reads more than 5 lines of a manpage?
<lag> ;)
<ogra_cmpc> heh
<lag> Yeah, that's what I read to get 'version'
<lag> But I thought -v and version were related
<lag> I was correct
<ogra_cmpc> -v --verbose
<lag> I'm guessing -v would churn out depmod's version
<lag> Oh!
<lag> Doh!
<ogra_cmpc> -V --version
<ogra_cmpc>               Show version of program and exit. See below for caveats when run on older kernels.
<lag> I would have found it - I was on the right lines
<ogra_cmpc> funny that there is no "below" in the manpage anymore
<ogra_cmpc> (probably refers to depmod.conf or so)
<lag> sudo chroot /media/rootfs/ depmod 2.6.35-903-omap4
<ogra_cmpc> yeah
<lag> Does anyone know how to do a remote single lined bash command
<lag> Something like:
<lag> chroot /root bash "for i in \`ls /lib/modules/\`; do echo \$i; done"
<ogra> remote ? through ssh =
<ogra> ?
<lag> chroot /root bash -- for i in `ls /lib/modules/`; do echo $i; done
<lag> Actually through chroot
<lag> But I guess the principle is the same
<ogra> sh -c "mycommand"
<persia> Similar, but not quite.
<persia> `ssh foo bar` runs command "bar" on host "foo"
<ogra> or just leave the shell out og it completely
<ogra> *of
<persia> `chroot foo bar` runs command "bar" with "foo" as root.
<persia> So `chroot foo "for i in ..."` ought do what you seek.
<ogra> right
<persia> quotes may not be required, but may be safer.
<ogra> yes, the quotes were more for ssh :)
<lag> I've tried those
<lag> Not working
<persia> !doesntwork
<ubot2> Doesn't work is a strong statement. Does it sit on the couch all day? Does it want more money? Is it on IRC all the time? Please be specific! Examples of what doesn't work tend to help too.
<lag> You and your ridiculous !cmds
<lag> Do you have a list next to you?
<ogra> he has the bot sitting next to him :)
<lag> Quite
<lag> sudo chroot /media/rootfs/ "for i in `ls /lib/modules/`; do echo $i; done"
<lag> chroot: cannot run command `for i in 2.6.28-18-generic\n2.6.31-21-generic\n2.6.32-21-generic\n2.6.32-22-generic\n2.6.32-23-generic\n2.6.32-24-generic; do echo 2.6.32-24-generic; done': No such file or directory
<persia> Oh, right.
<persia> yeah, for chroot you *do* need to specify the interpreter.
<persia> So "/bin/bash for i ...
<lag> sudo chroot /media/rootfs/ bash -c "for i in `ls /lib/modules/`; do echo $i; done"
<lag> /bin/bash: -c: line 1: syntax error near unexpected token `2.6.31-21-generic'
<lag> /bin/bash: -c: line 1: `2.6.31-21-generic'
<lag> Tried that too
<persia> Otherwise it tries to find "for" in the path, and fails.
<lag> Correct
 * ogra crosses fingers and boots the latest image
<persia> But `chroot /media/rootfs ls /lib/modules` works?
<lag> Yes
<lag> It's a problem with the bash part
<lag> bash -c "for i in `ls /lib/modules/`; do echo $i; done"
<lag> That's broken in some way
<lag> for i in `ls /lib/modules/`; do echo $i; done
<lag> Works fine
<persia> How about echo `for i in $(ls /lib/modules/); do echo $i; done" > /media/rootfs/script; chroot /media/rootfs /bin/bash /script`
<lag> Got it
<lag> It wanted ' not "
<XorA> your backticks are executed too early?
<persia> Aha!
<persia> XorA, On the nose.
<lag> sudo chroot /media/rootfs/ bash -c 'for i in `ls /lib/modules`; do depmod $i; done'
<lag> That is the winning formula
<ogra> GRRR
<ogra> so resizing and rebooting works fine
<ogra> but it hangs after the fourth dot in plymouth was printed
<XorA> see there is a reason I hate all this gui obfuscation
<persia> How is plymouth obfuscation?
<XorA> it hides the kernel messages
 * persia isn't even convinced it's gui with the text profile
<persia> Doesn't passing noquiet show them again?
<XorA> no idea
<persia> Has since Breezy or so.  I think it's not plymouth, but the kernel command line that causes the sense of obfuscation.
<persia> But I haven't run with noquiet since jaunty or so, so I may be mistaken.
<lag> If you press left/right arrow, you can see the messages
<ogra> yeah, seems to be the same issue ricardo sees
<ogra> hangs right after ureadahead when trying to start apparmor
 * ogra tries to add /e/n/i to Ã¼prevent NM
 * ogra glares at the gdm screen
<ogra> hrm
<ogra> where is my oem-config
<ogra> k, i think i'll add a hack to jasper to set up /e/n/i, that seems to work fine
<ogra> uploaded
<ukleinek> moin, does anyone here use a display with an i.MX51 (e.g. Babbage)?  If yes, did you invest some efforts to improve the Freescale driver?
<persia> ukleinek, I used to do so, and no.
<persia> I remember it not having acceptable acceleration.
<persia> (but I was mostly interested in using the device to track down build failures, etc.)
<ogra> ukleinek, the display driver around 10.04 time was completely unusable (and non free) so we dont have it, out netbook images used fbdev only
<ogra> s/out/our/
<amitk> ukleinek: are you working on the fb driver for i.mx51? Robert mentioned something about pengutronix's involvement on linaro-dev...
<persia> We'd certainly be happy to ship a better driver, if someone wanted to help maintain it :)
<rsalveti> ogra: lag: all you need to do to have a working image is to give "ifconfig usb0 up" before initializing network-manager service :-)
<rsalveti> then you'll get everything working fine
<rsalveti> with network
<rsalveti> as I described at the bug already
<rsalveti> so if you bring that up before, starting the services, will probably get everything working
<ogra> rsalveti, i uploaded a hack already, waiting for approval
<rsalveti> ogra: what did you do?
<ogra> rsalveti, just adding usb0 to /etc/network/interfaces
<ukleinek> amitk: yes (Robert's my boss in case you don't know)
<ogra> that prevents NM from managing it
<rsalveti> ogra: hm, ok
<rsalveti> will work but no valid network
<ogra> its a hack but will get us through beta
<amitk> ukleinek: I figured that might be the case :)
<rsalveti> yep, but if you give ifconfig usb0 up it'll work *with* network
<rsalveti> so, better hack
<rsalveti> but anyway
<ogra> rsalveti, well, it seems to work, i got the time from ntp during oem-config
<lag> rsalveti: Eh?
 * rsalveti back to bed
<rsalveti> ogra: oh, so cool
<rsalveti> lag: what?
<ogra> go to bed we need you fresh in the morning :)
<rsalveti> if you bring the interface up NM will not bring up/bring down while starting
<ogra> right, /e/n/i has the same effect
<rsalveti> what could have happened is that the new NM is doing this procedure to get info from the interface
 * persia thought it *was* morning
<rsalveti> that's why it wasn't happening before
<rsalveti> I'd say
<rsalveti> ok, see ya in some hours :-)
 * rsalveti hopes to see a better image when starts working :-)
<ogra> well, its still shaky
<persia> rsalveti, Do I have the time wrong?  Is it 8am local for you?
<ogra> but gets quite far
<rsalveti> persia: yep
<rsalveti> cool
<persia> Ah, good.
<rsalveti> lag: don't you have a working es1 already?
<rsalveti> I thought davidm would sent you one
<lag> I have two borked ones
<rsalveti> lag: two borked?
<lag> Yea, but HDMI doesn't work on the new one
<rsalveti> so you're the problem
<lag> They have different issues
<rsalveti> lag: to reproduce this bug you don't need hdmi
<lag> Correct
<rsalveti> just ifconfig usb0 up/down
<lag> That's what I'm working on now
<lag> Yeah, I read it
<lag> Go to bed ;)
<rsalveti> I tried to activate the debugging messages from the module but than I got a huge trace
<rsalveti> probably wrong untested code at the debug messages
<rsalveti> :-)
<rsalveti> ok
<rsalveti> see ya
 * ogra dances around a working desktop 
<ogra> wohooo
<persia> \o/
<lag> On ES1.0?
<ogra> still way to many panels on my screen
<ogra> lag, yep, current image with some hacks
<lag> Get it built
<ogra> well, there is the paperwork ...
<ogra> its uploaded but someone needs to approve it
<ogra> and it will fail after reboot because of the issues with the old u-boot, we need the new one before beta
<ogra> bug #623242
<ubot2> Launchpad bug 623242 in pulseaudio (Ubuntu) "speex-float-1 provides poor performance on armel (affects: 1) (heat: 8)" [Low,Triaged] https://launchpad.net/bugs/623242
 * ogra_panda waves
<lag> ogra_panda == goon :)
<lag> hrw: Are you around?
<ogra> hey, i'm no bully !
<hrw> lag: yes
<lag> hrw: What is the module which controls usb0 on the XM? Is it smc91x?
<hrw> smsc95xx?
<lag> Do you know what it is on the Panda?
<lag> hrw: ?
<ndec> ogra: hi. is maverick moving to connman or staying with nm?
 * ogra twiddles thimbs waiting for the daily archive admin to get up
<ogra> ndec, *we* stay with NM
<ndec> ogra: thx.
<ogra> (our images do)
 * persia grumbles.  Why is fpc *still* not bootstrapped?
<zumbi_> persia: i though it was
<zumbi_> but maybe it is not, later upstream release had arm fixes
<persia> zumbi_, It was in Debian, and there was a ticket to have it done in Ubuntu for lucid, and it hasn't been.
<persia> zumbi_, feel like trying a bootstrap in Ubuntu, and see if it works?
<zumbi_> persia: oh! ok, i was just talking with debian hat
 * persia tracks down the relevant bug number
<persia> heh
<persia> bug #67544
<ubot2> Launchpad bug 67544 in fpc (Debian) (and 2 other projects) "Bootstrapping needed for fpc for armel (heat: 5)" [Unknown,Fix released] https://launchpad.net/bugs/67544
<zumbi_> persia: for testing ubuntu, is it maverick the right suite?
<lag> ogra: I think you'd best check the Kernel Mailing list
<persia> That's the one we're working on just now.
<zumbi_> i just setup 8 chroots for debian builds (4 suites for i386, amd64) adding a couple more won't hurt :)
<persia> Only 8?  I'd have expected you to have armel and armhf build chroots as well.
<zumbi_> persia: well this is x86 + cross builds; native arm stuff is in the stack, maybe in some weekend
<zumbi_> and arm + qemu .. this is really becoming insane
<persia> heh.
<persia> arm+qemu is too painful
<zumbi_> arm + qemu + croco
<persia> madness
<persia> I thought you had a few fairly fast settop boxes to play with though?  Why cross-build?
<zumbi_> at work we cross build some stuff
<zumbi_> usually cross building is very useful for kernels and custom applications
<persia> for kernels mostly because getting hardware with decent RAM is nigh impossible these days.
<persia> For custom stuff, I still prefer native, unless working on deep embedded targets, but that might just be my prejudice.
<zumbi_> for development, cross building helps you being faster
<persia> Depends on the HW you can get.
<persia> But yeah, fast big RAM hardware is hard to find for ARM.
<zumbi_> our hardware is PXA270
<persia> Ouch.  Now your propensity to cross-build makes sense :)
<zumbi_> Available chroots: lenny_i386 stable_i386 squeeze_i386 testing_i386 sid_i386 unstable_i386 experimental_i386 rc-buggy_i386 maverick_i386 lenny_amd64 stable_amd64 squeeze_amd64 testing_amd64 sid_amd64 unstable_amd64 experimental_amd64 rc-buggy_amd64 maverick_amd64
<persia> heh
<zumbi_> hrw: which are maverick cross compilers?
<zumbi_> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ || http://ppa.launchpad.net/hrw/arm-cross-compiler/ubuntu ?
<hrw> zumbi_: first
<hrw> zumbi_: my ppa is empty now
<zumbi_> thanks :)
<hrw> in few hours there will be binutils + eglibc + linux headers + libgcc there
<zumbi_> hrw: built with viro's changes?
<zumbi_> (well, for the libgcc part)
<hrw> no, I use ubuntu packages now
<hrw> zumbi_: when 4.4.4-10(ubuntu1) will land then I will get Al's changes
<hrw> zumbi_: Ubuntu versions have all I need now
<zumbi_> ok, great! - viro's changes are very cool
<ogra> lag, for what ?
<lag> The USB issue
<lag> Or information on said issue
 * ogra only sees 2 linaro pull requests 
<ogra> bah, sigh, why do people always need to add a ton of CCs
<lag> ogra: I told you the reason to that yesterday
<ogra> yeah, its still annoying
<lag> Not everyone has the masses of spare time that you do ...
<ogra> you cant properly reply to it, and it ends up in the wrong folders
<lag> Depends on your filters
<ogra> evo filters on ML headers
<lag> s/mv/cp ;)
<lag> ML?
<ogra> mailing list
<hrw> zumbi_: better check armel-cross-toolchain-base source package in my ppa
<lag> Anyway ... we digress
<zumbi_> hrw: i was asking for the maverick chroot setup, I would like to have in the maverick chroot official maverick cross compilers
<zumbi_> hrw: i guess i need to check ppa source for the packaging (to get into Debian)
<lag> zumbi_: Cross compilers?
<zumbi_> hrw: I looked you were basically calling dpkg -x
<zumbi_> lag: yeap
<lag> Why would you need to cross compile if you're in a chroot?
<zumbi_> i am on an amd64 chroot wanting to cross compile a kernel, for example
<ogra> usen an armel chroot then ;)
<lag> Exactly
<zumbi_> ogra: we talked on that arm+qemu+croco is nice, but only work for arm
<zumbi_> i would like to keep qemu stuff aside
<hrw> armel chroot? its insane waste of resources
<ogra> zumbi_, sudo apt-get install qemu-arm-static, sudo qemu-debootstrap armel ...
<zumbi_> hrw: they fake armel native compiler with cross compilers
<hrw> ogra: and wait 6h to build kernel?
<ogra> better than 18h on a beagle ;)
<lag> hrw: My armel builds take 20mins
<hrw> worse then 0.5h with cross compiler
<ogra> or 16h on a qemu vm
<lag> From scratch
<zumbi_> E: Unable to locate package qemu-arm-static,
<ogra> zumbi_, lucid or maverick ?
<suihkulokki> kernel is a special case, you dont need qemu or target arch userspace - just a crosscompiler
<hrw> or debian?
<zumbi_> hold on, i copied from your paste
<ogra> well, debian has static packages too but differently named
<hrw> suihkulokki: to build other packages I can use xdeb
<zumbi_> ogra: maverick
<hrw> zumbi_: add universe
<ogra> yeah
<ogra> though it might be that the transitional package was dropped ... qemu-arm-static points to a hilariously named qemu package
<suihkulokki> hrw: sounds interesting.. where can I get it?
<ogra> qemu-kvm-extras-static
<hrw> suihkulokki: maverick/universe?
<ogra> thats the actual package name
<hrw> suihkulokki: but you also need cross compiler
<zumbi_> suihkulokki: https://blueprints.launchpad.net/ubuntu/+spec/arm-m-xdeb-cross-compilation-environment
<hrw> suihkulokki: http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ has ones
<zumbi_> suihkulokki: xdeb is a rebranding of cjwatson work for chromeOS
 * hrw -> off
<zumbi_> bye hrw|gone, and thanks :)
<zumbi_> Failed to fetch http://aptcache:3142/uk.archive.ubuntu.com/ubuntu/pool/main/b/binfmt-support/binfmt-support_1.2.18_all.deb  Size mismatch
<zumbi_> E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
<hrw|gone> zumbi_: once done I will discuss with #emdebian team to merge it to Debian
<hrw|gone> al8
<zumbi_> hrw|gone: ok, thanks :)
<zumbi_> ogra: on maverick, "sudo apt-get install qemu-arm-static" fails :/
<ogra> well, try qemu-kvm-extras-static instead
<zumbi_> uhm... i wonder if it is taking the one from the cache with it is a debian one
<ogra> qemu-arm-static was a transitional package
<zumbi_> ogra: it was my aptcache fault
<ogra> ah
<lag> ogra: Any ideas?
<lag> sudo chroot /mnt1
<lag> chroot: cannot run command `/bin/bash': No such file or directory
<lag> ls -l /mnt1/bin/bash
<lag> -rwxr-xr-x 1 root root 658216 2010-08-27 14:23 /mnt1/bin/bash
<ogra> hmm, no, check your mount options
<zumbi_> ogra: btw, http://pastebin.com/k39xjk2Y
<ogra> zumbi_, heh, sorry typo
<lag> ogra: /dev/sdc2 on /mnt1 type ext3 (rw)
<ogra> --arch armel was indeed the right one
<zumbi_> i guess
<ogra> zumbi_, and all the other typical debootstrap options too
<ogra> the script is just a wrapper around debootstrap
<ogra> to copy the static interpreter into your chroot
<lag> ogra:
<lag> sudo chroot /mnt1 ls
<lag> chroot: cannot run command `ls': No such file or directory
<ogra> lag, no idea, sorry
<lag> :(
<ogra> must have something to do with mounting i guess
<ogra> since it works in your normal chroot
<lag> It _did_ work on the card
<ogra> oh, really ?
<lag> I've just tried the card it used to work on
<ogra> now thats weird
<lag> Same thing
<lag> Yeah
<lag> /dev/sdc2 on /media/549d738f-1c48-4c0a-a8d2-e12286a9fab1 type ext3 (rw,nosuid,nodev,uhelper=udisks)
<lag> Oh, this is the daily build
<lag> The last one was my homebrew
<ogra> nosuid,nodev ?
<lag> I didn't specify it
<ogra> thats automounted by nautilus i guess
<lag> Yeah
<ogra> dont do that, the mount options in udisks prevent chrooting
<lag> Okay, it still works with my homebrew
<lag> /dev/sdc2 on /media/rootfs type ext3 (rw,nosuid,nodev,uhelper=udisks)
<lag> That works
<lag> Same mount options
<lag> How does rootstock and the daily build differ?
<lag> SD card too big?
<ogra> rootstock builds a tarball daily is a partitioned image
<lag> Doesn't support HC devices?
 * rsalveti back
<lag> rsalveti: It's bed time!
<ogra> rsalveti, so for the images, the jasper fix sits in the release queue, i'm waiting for someone in #ubuntu-release to process it and we are waiting for the u-boot-linaro package thats stuck in NEW (and needs some script changes i have to do on the build server)
<ogra> then we should have relatively usable images
<rsalveti> ogra: awesome
<rsalveti> ogra: and how about the oem, gdm and efl session?
<rsalveti> is it all working now?
<ogra> no
 * rsalveti still reading the backlog
<ogra> oem-config had a crash after first reboot but worked for me on second
<rsalveti> hm
<ogra> i havent researched that yet
<rsalveti> ok
<ogra> gdm is just fine now after the usb0 hack
<rsalveti> let me download the latest image
<rsalveti> nice
<ogra> it doesnt have the usb0 hack yet
<rsalveti> ogra: is the 20100827 the latest?
<rsalveti> had that issue while browsing the webserver yesterday
<rsalveti> ogra: np, I can change that by hand
<ogra> rsalveti, right 0827
<lag> Does anyone get the SYNC_LOST_DIGIT errors?
<ogra> nope
<rsalveti> lag: with current kernel, yes
<rsalveti> lag: with my LG monitor
<rsalveti> this can be fixed with latest hdmi patches
<rsalveti> that's why I'm maintaining my own kernel until we get rebased for 2.6.35
<lag> When we get rebased, we won't be able to use ES1.0 any longer
<rsalveti> lag: I know, but we didn't get the display patches merged because we thought we would have the new version one or two weeks ago
<rsalveti> :-)
<rsalveti> lag: anyway, if you want to check that out http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-ti-omap4
<lag> ASSumption makes ASSes of people ;)
<rsalveti> :-)
<robclark> lag: fwiw at least on TI kernel tree, it is possible to build for either ES1.0 or ES2.x..  although it still has to be a compile time decision..
<rsalveti> robclark: does it work with usb at es1?
<rsalveti> robclark: can you say what config should I set? so I can test the ethernet issue
<robclark> rsalveti: on es1, you need to use musb instead of ehci..
<robclark> so almost need two different defconfig's
<rsalveti> hm, ok
<rsalveti> makes sense
<robclark> anyways, see CONFIG_OMAP4_ES1
<rsalveti> robclark: nice, will try, thanks
<robclark> np
<rsalveti> lag: any progress with the ethernet issue?
<lag> On ES1.0?
<rsalveti> yep, just wanted to know if you actually spent some time on that
<lag> I haven't managed to get a shell yet
<rsalveti> we have a workaround and will be switching to es2 (that works) soon, so not a high priority
<lag> Yes, do you know why it works?
<rsalveti> it's expected to work, the question is why it's not working on es1
<lag> USB on the ES1.0 only works due to a hack
<rsalveti> but didn't dig further
<lag> There is a hardware bug on ES1.0
<rsalveti> yep
<lag> Hence the stupid cable
<ogra> ndec, bug 623242
<ubot2> Launchpad bug 623242 in pulseaudio (Ubuntu) "speex-float-1 provides poor performance on armel (affects: 1) (heat: 8)" [Low,Triaged] https://launchpad.net/bugs/623242
<rsalveti> lots related with usb
<lag> Well ES2.0 doesn't need/have/contain that hack
<lag> ES1.0 uses the OTG port
<lag> ES2.0 uses true host
<rsalveti> yup, true
<lag> rsalveti: I'm checking out your kernel now
<rsalveti> lag: want the deb file?
<rsalveti> http://people.canonical.com/~rsalveti/maverick/kernel/linux-image-2.6.34-903-omap4_2.6.34-903.7rsalveti1_armel.deb
<lag> Ta
<rsalveti> with this kernel your lg monitor should work fine
<lag> I have two monitors
<lag> My Phillips one just worked
<lag> Until the last couple of builds
<lag> Now the SYNC_* happens every time on both monitors
<prpplague> ho ho hum
<prpplague> davidm: you on the conference call?
<ogra> prpplague, we all are
<ogra> wanna join ? :)
<prpplague> ogra: i'm on
<ogra> oh
<davidm> yes I am prpplague
 * prpplague keeps quiet
<lag> Party on PSTN!
<ogra> prpplague, dont be shy !
<lag> ogra: Snitch!
<lag> ;)
<ogra> *g*
<rsalveti> hm :-)
<lag> rsalveti: I get SYNC_ errors, even with your kernel
<rsalveti> lag: hm, this shouldn't happen
<lag> I told you lot, it's screwed
<lag> I know it _shouldn't_ happen
<lag> USB is borked on one, HDMI on the other!
<rsalveti> haha
<ogra> did they tell you to only touch the boards with gloves ?
<prpplague> lag: which boards? panda
<rsalveti> lol
<ogra> prpplague, es1
<prpplague> ahh
<lag> Yeah
<lag> We are caught in the middle of two boards at the moment
<lag> rsalveti: Can you send me a paste of an "lsmod" on your Panda?
<rsalveti> lag: es1 or es2?
<lag> 1
<rsalveti> lag: http://paste.ubuntu.com/484517/
<lag> ubuntu@panda:~$ ifconfig usb0 up
<lag> usb0: ERROR while getting interface flags: No such device
<prpplague> odd, neither of those should be loaded for the panda
<rsalveti> hm, do you have usb working?
<lag> Nope
<prpplague> lag: which kernel are you using?
<lag> rsalveti's
<rsalveti> I have it working here
<lag> *shrugs*
<prpplague> lag: you got the little black dongle plugged in?
<prpplague> davidm: can you give me the url for that wiki page?
<lag> http://paste.ubuntu.com/484518/
<lag> prpplague: Yep
<dcordes> hey guys
<dcordes> anybody using netbook interface on a touchscreen only device ? I am wodnering about on screen keyboard
<ogra> lag, !
<dcordes> I used the onboard keyboard in karmic
<lag> ogra: Yes?
<rsalveti> lag: http://paste.ubuntu.com/484521/
 * ogra just had the idea whats wrong with your chrooting :)
<rsalveti> the whole boot log
<ogra> lag, you need the interpreter in the SD
<rsalveti> usb 1-1.1: adding 1-1.1:1.0 (config #1, interface 0)
<rsalveti> smsc95xx 1-1.1:1.0: usb_probe_interface
<rsalveti> when your usb is recognized you'll easily notice at the boot log
<ogra> lag, cp your /usr/bin/qemu-arm-static binary into the same place on the SD, then you can chroot ... silly i didnt think of that in the beginning
<lag> usbcore: registered new interface driver smsc95xx
<lag> Does that already exist in my home brew then?
<ogra> check for it :)
<ogra> very likely
<dcordes> a keyboard like this would be nice http://www.youtube.com/watch?v=viSW_RGXzwA
<lag> ogra: That worked
<ogra> :)
<lag> ogra: Can we have it put into the daily build?
<ogra> sorry i should have thought of that earlier
<dcordes> prpplague: you should put a redirect to the new page http://www.elinux.org/Panda_Bambo
<lag> If not, I'll just add it to my scripts
<ogra> lag, no, that would require it to be in main
<ogra> right, thats the best
<dcordes> prpplague: and add internal link for PandaBoard
<prpplague> dcordes: mainly just there for early adopter feedback
<prpplague> http://www.elinux.org/Panda_Bamboo
<lag> rsalveti: Can you dd your entire image (with USB working) and make it available to me please?
<dcordes> prpplague: just saying
<prpplague> dcordes: yea
<prpplague> dcordes: i'll add more as i am allowed, hehe
<dcordes> forgot my elinux login
<rsalveti> lag: let me post my fat partition stuff and the rootfs tarball
<rsalveti> hold on
<lag> Just the rootfs would be good
<lag> In fact, screw it, I'll take both
<rsalveti> ok, will ping you when I'm done
<lag> This is from my other board (the one USB is properly borked
<lag> usb 1-1: device descriptor read/64, error -110
<lag> usb 1-1: device descriptor read/64, error -110
<lag> usb 1-1: device not accepting address 4, error -110
<lag> usb 1-1: device not accepting address 5, error -110
<lag> hub 1-0:1.0: unable to enumerate USB device on port 1
<sebjan> ogra: now that mainline u-boot is used, how is x-loader built? (still relying on old u-boot headers?)
<rsalveti> sebjan: same way as before
<rsalveti> yep, I think it's included at the deb package as a patch
<ogra> sebjan, its still the same binary, but we plan to upgrade to the 1GB version
<ogra> we'll have to see how that needs to be treated
<rsalveti> but even the latest one I'd say that needs the old headers
 * ogra would prefer to not have to carry a megabyte big patch for the headers
<sebjan> rsalveti, ogra: ok, we still have a small dependency on the old u-boot sources then
<rsalveti> yup, at least it didn't compile with latest source from u-boot
<ogra> well, in ubuntu i made a patch, the package doesnt use and u-boot tree directly
<rsalveti> didn't waste too much time on that, but it seems the they changed a lot the headers
<sebjan> ogra: yes, I remember looking at this package, with a big patch for u-boot headers :)
<GrueMaster> sigh.  Today's image hangs.  Likely the network manager issue.
<ogra> right
<ogra> GrueMaster, next will work
<GrueMaster> respinning or tomorrow?
<ogra> GrueMaster, you shoudl just add usb0 to /e/n/i in advance
<ogra> then you wont have the issue
<GrueMaster> ok
<ogra> GrueMaster, http://bazaar.launchpad.net/~ogra/jasper-initramfs/trunk/revision/67
<ogra> was just stuck in the release queue until 20min ago
<GrueMaster> perfect.
<ogra> now i'm waiting for the linaro u-boot to get out of NEW and into main and i can re-roll images
<ogra> oh, and indeed i need to change the build scripts to make use of linaro u-boot :)
<rsalveti> :-)
<rsalveti> cool, we're getting better
<GrueMaster> The jasper fix is just a bit of hackery to move the ball forward, I hope.
<rsalveti> GrueMaster: yup
<rsalveti> avoiding bring the usb0 down/up
<rsalveti> will be fixed once we move to es2
<rsalveti> but, not for beta
<GrueMaster> ah
<GrueMaster> I assumed we missed the boat on beta.  If we can get a prerelease kernel, xloader, and uboot, I can test them on the beta image once I have tested beta.  Help pick up lost time.
<GrueMaster> whee.  it's alive!
<rsalveti> GrueMaster: ok, ping me when you're ready to test es2
<GrueMaster> Anytime.  I'm running today's image with the nic fix now.
<GrueMaster> All I need is the kernel package, uboot & xloader.  I can manually munge them into the es1 image from there.
<rsalveti> GrueMaster: ok, will just check latest cooloney kernel and let you know about it
<rsalveti> lag: 5 minutes to go, tested here already
<lag> Remind me what this problem is again: http://paste.ubuntu.com/484545/
<lag> rsalveti: Thanks
<dcordes> lag: use an initrd that will run fsck on the rootfs on every boot
<lag> I make my own initrd
<lag> How do I tell it to do that?
<dcordes> I bootl ike this
<dcordes> http://htc-linux.org/wiki/index.php?title=Rootfs/Userfriendly
<lag> I thought Jasper took care of that
<rsalveti> ogra: ^
<ogra> lag, what image is that ?
<ogra> seems not the latest
<ogra> (sorry i'm in the release meeting)
<lag> It's the daily build with my initrd
<dcordes> lag: rootfs is in a file on vfat card and initrd will fsck on it on every boot. works bullet proof for me
<ogra> not todays
 * lag checks
<dcordes> lag: and it allows windows users to switch rootfs. hence the Userfriendly page title
<lag> Yes, todays
<lag> -rw-r--r-- 1 root    root    2175791104 2010-08-27 08:04 maverick-preinstalled-netbook-armel+omap4.img
<ogra> lag, its not todays jasper
<ogra> lag, in any case, file a bug and attach that jasper lof
<ogra> *log
<lag> You mean I have to update Jasper every day
<ogra> sorry, but i need to follow the meeting now
<ogra> lag, see my conversation with GrueMaster above
<dcordes> lag: feel free to reuse anything of it
<ogra> there were two jasper fixes uploaded the last 24h
<dcordes> I need to ask the initial author of the script for license
<rsalveti> lag: http://people.canonical.com/~rsalveti/maverick/lag/
<rsalveti> rootfs and first partition content
<lag> dcordes: Sorry, that's not going to help
<dcordes> lag: hehe yes it's very hacky and I'm sure you will not release images that way
<ogra> lag, i suspect there is something wrong at build time, i need to research that before beta but have different issues with higher prio first
<ogra> so a bug will help
<lag> ogra: Don't worry about it - I'll file the bug and use rsalveti's image in the mean time
<ogra> k
<dcordes> lag: personally I also used to put rootfilesystems on partitioned cards directly. but that method has many advantages
<lag> dcordes: But we're don't going to use that method for our released images :)
<dcordes> lag: yes as I anticipated I thought you wouldn't
<dcordes> as it can be useful in certain cases it can't harm
<dcordes> for me it is a tool to supply people who are new to Linux with ubuntu for their cell phones
<GrueMaster> hrm.  gdm is failing now.
<ogra> GrueMaster, after install ?
<ogra> worked here
<dcordes> GrueMaster: in the latest maverick netbook build ?
<GrueMaster> Yes
<rsalveti> GrueMaster: any error?
<GrueMaster> Today's current build + ogra's network fix.
<ogra_panda> weird
<dcordes> GrueMaster: ok. I am preparing a rootfs with yesterday's .1 build
<ogra_panda> id definitely works here
<GrueMaster> None.  Startx works fine.  Will deep dive to see what's amiss.
<ogra> my usualy question, is the system dbus running ?
<dcordes> GrueMaster: is that network fix a user space thing ?
<GrueMaster> yes
<rsalveti> ogra: GrueMaster: weird, seems oem-config failed
<rsalveti> got the gdm screen directly
<ogra> rsalveti, reboot
<rsalveti> oh, ok
<dcordes> GrueMaster: where can it be found ?
<ogra> i saw that too, we will need to research
<ogra> but only once out of three test installs
<dcordes> ogra: is there a mailing list or website to keep track of such things regarding latest maverick arm ?
<GrueMaster> dcordes: Need to fix network in the omap4 image before second stage (oem-config) will boot.  http://paste.ubuntu.com/484552/
<dcordes> GrueMaster: ah ok. that's not relevant to me
<dcordes> htc leo has usb net but I use it in host mode
<GrueMaster> That's my "fix it" script.  Run as root.
<rsalveti> ogra: nops, gdm still
<rsalveti> let me get a console
<ogra> look for a crash report in /var/crash
<lag> rsalveti:
<lag> ubuntu@panda-maverick:~$ dmesg | grep -i smsc
<lag> usbcore: registered new interface driver smsc95xx
<lag> ubuntu@panda-maverick:~$
<GrueMaster> Gah.  6 apport crash reports to wade through.
<GrueMaster> None are gdm
<ogra> what are they ?
<ogra> GrueMaster, oh, and are you on panda ?
<rsalveti> lag: ok, but did you get the usb0 interface?
<dcordes> ogra: something like launch
<lag> rsalveti: Nope
<lag> rsalveti: That's the same message I get with my own builds
<dcordes> ogra: sorry. something like a launchpad page. or are you only using IRC to discuss such things ?
<GrueMaster> Ubuntu one service, indicator-session, gnome-disk-utility, and policy kit.
<ogra> PK is a bit worrying
<rsalveti> lag: you're out of luck
<lag> rsalveti: It can't 'just so happen' that USB is broken on two of my boards!!
<GrueMaster> dcordes: We are having a lot of issues atm.  Trying to file bugs and wade through them.  Next week is beta release.  It will have a list of current issues.
<lag> ogra: What should I call this bug? In the title?
<GrueMaster> lag: fyi:  you aren't supposed to lick the boards before booting.  Thought you should know.  :P
<lag> "Jasper is borked"
<lag> GrueMaster: Doh!
<dcordes> GrueMaster: As I am going to do some work with yesterday's image I would like to contribute in that process
<ogra> lag, has nothing to do with jasper
<lag> GrueMaster: But they're to tasty!
<dcordes> GrueMaster: In that case I will just let you know here if I find something
<lag> ogra: What's the issue then?
<rsalveti> ogra: there's one crash: ubiquity
<ogra> filesystem corruption
<lag> What do I file it against then?
<ogra> rsalveti, open it (less)
<rsalveti> lag: my current daily image went fine
<lag> rsalveti: Good for you!
<rsalveti> ogra: is it expected to break?
<lag> ;)
<rsalveti> lag: I mean, without any fs corruption
<GrueMaster> dcordes: If you are going to be testing the images, get the latest (which I think ogra will respin soon).  If you find any bugs (highly possible), please subscribe ubuntu-armel-porters.  Thanks.
<dcordes> GrueMaster: cool.
<rsalveti> ogra: weird: XStartupError: X server exited with return code 1
<lag> I'll leave it then
<lag> It's probably my borked boards
<ogra> rsalveti, nothing more ?
<lag> I've had enough
<lag> See you on Monday!
<ogra> lag, against cdimage please
<rsalveti> lag: haha, have a nice weekend! :-)
<GrueMaster> lag: Go to the pub and have a cold one.  You've earned it.
<lag> ogra: You still want me to report it? rsalveti Said he's not had any trouble?
<lag> GrueMaster: I intend to
<ogra> hmm, k, i guess once he looks into jasper.log he will see some ;)
<lag> I think I'm just going to have to work on ES2.0
<lag> rsalveti: Do it
<lag> less /var/log/jasper.log
<rsalveti> lag: http://paste.ubuntu.com/484554/
<lag> I'll leave it then
<lag> I'm off
<lag> Have a good weekend
<ogra> wohoo, i wasnt grilled :)
<ogra> dmart, that didnt work, i saw you *all* the time !
<ogra> rsalveti, oh, awesome !!!
 * ogra likes that log :D
<rsalveti> :-)
<dmart> heh
<ogra> rsalveti, but thats es2 with your own kernel, right ?
<rsalveti> ogra: es1, with my kernel (only hdmi fixes), latest image
<rsalveti> with ubs0 fix at jasper
<ogra> rsalveti, great
<ogra> thats calming
<rsalveti> weird, now I'm the one who is getting usb errors :-(
<dcordes> what is the policy about joining a restricted team ?
<ogra> ask the owner
<dcordes> davidm: ping
<ogra> dcordes, what team is that ?
<dcordes> ogra: ubuntu-armel
<ogra> you need to be a core dev for that iirc
<dcordes> ok I will try to find a bug to report first ;)
<davidm> dcordes, yes?
<davidm> Ah, ogra answered good enough
<dcordes> davidm: ok
<dcordes> I like the well organized hierarchical development infrastructure
<GrueMaster> ogra: Seems like all 6 of the crash reports I have are Sig 5 crashes.
<rsalveti> ogra: ok, after 3 reboots I got oem-config working
<rsalveti> probably a racing condition
<rsalveti> x and oem-config
<ogra> rsalveti, yeah, pretty sure
<rsalveti> interesting, even with more ram ureadahead doesn't generate the pack file
<rsalveti> so, useless atm
<ogra> let me guess, it exists with status 5
<rsalveti> don't have the boot log
<rsalveti> ogra: my host name is localhost but if I go the the logs, inside /var/log, I can still see the builder's name
<rsalveti> sycamore
<rsalveti> at daemon.log, for example
<rsalveti> or messages
<ogra> hmm
 * ogra goes to #ubuntu-installer i guess oem-config needs to restart rsyslog
<dcordes> very nice. htc leo touchscreen works out of the box with yesetrday's image. I suppose it is using evdev
<rsalveti> updated the bug
<rsalveti> oh now, another irc channel!
<rsalveti> hahah
<ogra> heh
<dcordes> what is the default login ?
<ogra> dcordes, the one you gave during oem-config
<dcordes> ogra: it booted straight to the login screen
<ogra> then there si something wrong with jasper or the initrd
<ogra> *is
<rsalveti> well, installing :-)
<rsalveti> oem-config window is smaller
<rsalveti> can't read all the banner
<dcordes> ogra: Ok. I am not using the initrd. I extracted the second partition from the raw image and use it as bare rootfs.
<ogra> smaller than the slideshow even, yeah
<rsalveti> anyway, /me heads to lunch now
<ogra> dcordes, that wont work
 * dcordes reads up on oem-config
<ogra> you *need* the initrd
<ogra> its an essential part
<dcordes> ok I will extract it and see what it does
<GrueMaster> dcordes: YOu should just dd the entire image to an SD and let it boot.
<GrueMaster> After gunzip of course.
<dcordes> GrueMaster: That seems like the option for testint purpose. In the long run I will need to find a way to include it with the 'Userfriendly' rootfs method
<GrueMaster> ?
<GrueMaster> This is about as user-friendly as it gets.
<dcordes> GrueMaster: assuming user has Linux
<GrueMaster> Ok, before release we will add a link to something like https://launchpad.net/win32-image-writer for the windows crowd.
<dcordes> file uInitrd
 * ogra goes afk ... i'll come back later and chaneg the build scripts and trigger a build with the new u-boot
<GrueMaster> See you later.
<dcordes> GrueMaster: That looks interesting, thanks
<dcordes> GrueMaster: bye
<dcordes> I cannot find how to extract uImage
<GrueMaster> dcordes: I'm not going anywhere.
<GrueMaster> Why are you trying to extract uImage?
<dcordes> GrueMaster: sorry.. of course your replied to ogra.
<dcordes> GrueMaster: I want to find out what happens in oem-config . Can't see a wiki page on that
<dcordes> s/uImage/uInitrd/
<GrueMaster> It only prompts for timezone, keyboard, user info, and system name for the most part.  Beyond that it only removes packages needed for firstboot.
<GrueMaster> And it isn't in uImage.
<dcordes> Ok. Yeah I confused uInitd with uImage there
<GrueMaster> uImage contains jasper on first boot.  It is a script that resizes the root partition to fill the SD card and contains minor hacks to get around current bugs.
<GrueMaster> uImage is the kernel of course.
<GrueMaster> If you want to see what jasper does, it is here:  https://launchpad.net/ubuntu/+source/jasper-initramfs
<dcordes> Thanks. Reading the scripts
<dcordes> mkdir -p /root/var/lib/oem-config
<dcordes> touch /root/var/lib/oem-config/run
<GrueMaster> Simple semaphore to signal oem-config to run.
<dcordes> Can you also point me to the sources/scripts used in the initramfs (oem-configs and whatever else it does)
<rsalveti-panda> yee
<rsalveti-panda> cool, let's see how it goes on my es2 later on
<rsalveti-panda> wrong bars still
<GrueMaster> rsalveti: XM is running first-boot.  Wheee.
<GrueMaster> Errr.  Fail.  Doesn't appear to have run jasper.
<GrueMaster> oem-config is coming up, though.
<dcordes> GrueMaster: Can you think of a way to run oem-config without the initramfs ?
<GrueMaster> yes, just do what jasper does.
<GrueMaster> mkdir -p /var/lib/oem-config
<GrueMaster> touch /var/lib/oem-config/run
<dcordes> ok
<dcordes> GrueMaster: I will have to manually add a user first in order to run the commands
<dcordes> GrueMaster: It will be better to automate it
<dcordes> GrueMaster: is it a problem to have X running (the gdm login screen) when signaling oem-config to run ?
<GrueMaster> Why can't you just boot the entire image ant let it do it's thing?
<GrueMaster> It is already automated there.
<dcordes> Yes I see that. As I mentioned earlier I agree that is the sane thing to do. As I will be using the loopfile on vfat card method it is not suitable
<dcordes> I could simply write the configuration in the shipped rootfs but that will cut the advantage of oem-config
<dcordes> So it will be best to put a mechanism that will call oem-config once on first boot
<dcordes> (from the bare rootfs w/o initrd)
<GrueMaster> How are you getting the bare rootfs to the SD now?
<dcordes> GrueMaster: like so http://htc-linux.org/wiki/index.php?title=Rootfs/Userfriendly
<dcordes> The vfat formatted storage card contains rootfs.ext2 which is loop mounted and ran using an initrd.
<GrueMaster> I still am not following.  Our preinstalled images are pre-partitioned.  All the user needs to do is write it to an SD and boot, or is there a bootloader issue involved?
<dcordes> Yes, there is no u-boot
<GrueMaster> Our image has that.
<GrueMaster> And xloader.
<dcordes> GrueMaster: can you outline your boot chain ?
<GrueMaster> http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage has instructions from Linux.  Use the win32-imagewriter to write from Windows.
<GrueMaster> As to boot chain, I think it is documented in the blueprint https://blueprints.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap
<dcordes> Awesome
<dcordes> What I am wondering is how exactly the boot process operates from kernel execution to target rootfs init execution
<dcordes> So I can evaluate if I can implement it on my device
<GrueMaster> Essentially, on first boot, jasper copies the data from the vfat partition and reformats it to conform to CHS standards (needed for xloader), then rewrites the data back.  It then resizes root partition to fill the SD card based on the size of the card used (4G or greater required).
<GrueMaster> After resizing, it triggers oem-config to run and also does a little house cleaning to work around some other bugs.  Then it reboots and initrd mounts the root partition after a chkdisk scan.  Oem-config is launched by init and if the semephore exists, will prompt for timezone, keyboard, and user info.
<GrueMaster> Oem-config then configures those areas and removes first-boot only apps (jasper, oem-config, etc).  After it finishes, it restarts GDM and you are done.
<dcordes> Ok thank you very much
<dcordes> Are you making use of kernel modules in the entire preparation process ?
<GrueMaster> I don't think so.  Most are built in (audio, network, etc).
<GrueMaster> I can't think of any that would need to be loaded by uInitrd.
<dcordes> Ok that's what I was wondering
<dcordes> So basically it seems like I can do that
<GrueMaster> Some may get loaded after root is mounted./
<dcordes> ..on my device
<dcordes> But I will have to modify the initramfs
<dcordes> My bootloader can only load normal .cpio or .cpio.gz initrd
<GrueMaster> what bootloader are you using?
<dcordes> HaRET
<dcordes> http://htc-linux.org/wiki/index.php?title=HaRET
<dcordes> GrueMaster: where can I find the initramfs ingredients ?
<GrueMaster> Are you running a linux desktop atm?  You can extract the entire thing with some manual trickery.
<dcordes> GrueMaster: yes I am running Lucid on my x86 laptop
<dcordes> GrueMaster: I guess it has some uboot header I need to chop off ?
<dcordes> web searches wouldn't help me find how to
<GrueMaster> Yes.  dd bs=1 skp=64 if=uInitrd of=initrd.img
<GrueMaster> s/skp/skip
<GrueMaster> Then zcat initrd | cpio -ivd
<dcordes> http://htc-linux.org/wiki/index.php?title=Rootfs/Userfriendly&diff=prev&oldid=2213
<dcordes> Ok thanks
<GrueMaster> rsalveti: It looks like today's image is hanging on oem-config on my XM.  It has been sitting at getting the time from time server for a while now.
<dcordes> GrueMaster: gzip claims the resulting initrd.img is not in gzip format
<GrueMaster> right.  Use zcat.
<GrueMaster> The above is exactly what I used and it worked.
<GrueMaster> (although it should be zcat initrd.img |cpio -ivd ).  forgot the .img
<GrueMaster> gzip/gunzip fails for some reason, but zcat works.
<ukleinek> GrueMaster: that's not because gzip without further option doesn't write to stdout?
<dcordes> GrueMaster: Then something might be wrong on my end
<dcordes> GrueMaster: http://pastebin.ca/1927032
<GrueMaster> What image are you pulling uInitrd from?
<GrueMaster> hrm.  Seeing an issue with today's image now.
<dcordes> GrueMaster: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100826.1/maverick-preinstalled-netbook-armel+omap4.img.gz
<dcordes> I have very slow internet
<GrueMaster> You should be using the omap image, not omap4 (unless your system is omap4).
<dcordes> GrueMaster: Why ?
<GrueMaster> Different systems.  Different kernels.
<GrueMaster> Rest of the image is the same.
<dcordes> ok then it does not matter as I use my own kernel
<dcordes> GrueMaster: So what's foul with the uInitrd ?
<GrueMaster> If you are using your own kernel, and building your own image, then you should just use rootstock to build the image and not try to mess with the preinst image stuff.
<GrueMaster> I'm not sure what is up with the uInitrd.
<dcordes> GrueMaster: I made the decision to use the preinstalled image as a base for two reasons: rootstock is a time consuimg process which can come with several hurdles. with the preinst I hope to get your guys latest and greatest work with sane configuration
<dcordes> GrueMaster: Which build has a uInitrd that you are able to convert ?
<dcordes> GrueMaster: Is there no uInitrd 'source package' ?
<GrueMaster> I don't know.  One of the older images.  I'm doing testing on multiple platforms.
<dcordes> GrueMaster: I would like to look at the script that modifies the rootfs to perform the first boot oem-config
<GrueMaster> That would be jasper.
<dcordes> mkdir -p /root/var/lib/oem-config
<dcordes> touch /root/var/lib/oem-config/run
<dcordes> all it has is that
<dcordes> I perform that in my rootfs before boot and it will normally boot up to gdm login
<dcordes> [...] "Oem-config is launched by init and if the semephore exists, will prompt for timezone, keyboard, and user info."
<dcordes> that doesn't seem to happen for me
<dcordes> I greped jasper for oem-config and all it shows are those two lines plus the package dependency
<dcordes> So if I am missing something it is not in jasper
<dcordes> ogra: any hint ?
<dcordes> rootfs# ls root/var/lib/oem-config
<dcordes> run
<dcordes> It is present but does not show the desired effect
 * dcordes drops a few pins
<dcordes> office time over ?
<GrueMaster> No, just caught up in multiple tasks.
<dcordes> :>
<dcordes> GrueMaster: can you give me some extracted initramfs so I can go find the answer on my own ?
<GrueMaster> I'll see what I can do.
<dcordes> Thanks
<dcordes> My /etc/init.d/oem-config does not seem to check for semephore
<dcordes> I don't understand how this initramfs is such a mystery
<dcordes> how is it generated ? where are teh sources ?
<GrueMaster> I really am busy atm.  But I can tell you that we use livecd-rootfs to create the images.  Beyond that I only really test them and don't know all the sorcery required.
<ogra_cmpc> rsalveti, GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100827.1/ there is an omap4 image with linaro u-boot
<rsalveti> ogra_cmpc: great! was looking for it right now
<rsalveti> even better
<rsalveti> want to look at the possible oem-config racing condition
<dcordes> rsalveti, ogra_cmpc: I would like to have the bare rootfs start oem-config on first time boot
<rsalveti> dcordes: rootstock does that for you
<ogra_cmpc> right
<rsalveti> you can check the code
<dcordes> where is it ?
<ogra_cmpc> in ubuntu, apt-get install rootstock
<dcordes> 'touch /root/var/lib/oem-config/run' alone does not do the trick. it will still boot to gdm login
<ogra_cmpc> did you read the code of jasper carefully ?
<dcordes> I am not bootstrapping but still using the autobuild
<rsalveti> dcordes: http://bazaar.launchpad.net/~project-rootstock-developers/project-rootstock/trunk/annotate/head:/rootstock#L1136
<dcordes> ogra: grep -ri oem-config
<ogra_cmpc> thats not reading
<ogra_cmpc> read what the code does
<ogra_cmpc> or use rootstock
 * ogra_cmpc now really ends thye day
<GrueMaster> ogra_cmpc: Have a good weekend (and a beer if you can).\
<dcordes> rsalveti: it seems to me that is the part that will install oem-config . the preinstalled build I have here has that included already
<dcordes> rsalveti: I am just about the init
<rsalveti> dcordes: sorry, what are you trying to do?
<dcordes> rsalveti: apply the 'first time boot oem-config magic' to rootfs extract from preinstall image
<dcordes> rsalveti: (without initramfs)
<rsalveti> dcordes: but I don't think you need initramfs to run oem-config
<rsalveti> doing what rootstock does is enough
<rsalveti> it'll be an upstart init file
<GrueMaster> dcordes: Bear in mind that you need to start with either Alpha 3 image or 20100827 as anything in between had a broken oem-config.
<rsalveti> yup
<dcordes> ok thanks
<dcordes> rsalveti: the interesting lines are
<dcordes> apt-get install -y --no-install-recommends \$PACKAGE
<dcordes> touch /var/lib/oem-config/run
<dcordes> rm /usr/lib/ubiquity/plugins/ubi-tasks.py*
<dcordes> right ?
<dcordes> I basically did that before
<dcordes> so it must be broken oem-config problem
<rsalveti> dcordes: probably
<DanaG> fsck: Error 2 while executing fsck.btrfs for /dev/sde1
<DanaG> Can't use btrfs root.
<Baybal_> hmmm
<jcrigby> DanaG:I see in a pastebin that you posted a week ago the same problem I am seening.  Aug 20 00:50:08 <DanaG> hmm, ubuntu kernel fails on beagleboard: http://pastebin.com/WTjJgxgm
<jcrigby> #
<jcrigby> [    1.966705] WARNING: at /build/buildd/linux-linaro-2.6.35/arch/arm/mm/ioremap.c:207 __arm_ioremap_pfn_caller+0x20c/0x214()
<dcordes> jcrigby: are you using the latest build ? It seems like development is moving fast here
<jcrigby> actually latest build -1
<jcrigby> I maintain the linaro kernel that does not have the latest Ubuntu diffs
<jcrigby> the rcn patches from yesterday
<jcrigby> do those fix this problem?
<dcordes> jcrigby: what's rcn patches ?
<jcrigby> three omap3 patches that went into ubuntu kernel yesterday
<dcordes> jcrigby: can't comment there sorry. I only work with qualcomm devices now
<jcrigby> dcordes, no problem
<dcordes> jcrigby: why don't you use vanilla ?
<jcrigby> dcordes, the linaro kernel is an upstream linaro-next kernel merged with ubuntu
<jcrigby> we have had display problems since the last merge and I'm trying to find out which upstream is the source of the problem
<dcordes> aesome guys it works !
<rsalveti> dcordes: cool
<dcordes> rsalveti: thanks a lot for the help
<rsalveti> np
<dcordes> rsalveti: first hurdle in removing hackiness taken
<dcordes> rsalveti: now I need to sort out networking
<rsalveti> but nice anyway
<dcordes> rsalveti: does the netbook interface have restrictions regarding resolution ?
<dcordes> rsalveti: by default Xorg will give me portrait display i.e. 480x800
<rsalveti> hm
<rsalveti> never tried
<dcordes> oem-config finished, restart gdm and I only see the wallpaper
#ubuntu-arm 2010-08-28
<GrueMaster> sigh.  Oem-config no longer prompts for system name.  Everything defaults to ubuntu-laptop.
<rsalveti> GrueMaster: <user>-laptop
<rsalveti> GrueMaster: fill a bug for that, we should fix it
<GrueMaster> Still.  I now have four systems that think they are ubuntu-laptop.
<rsalveti> hahah
<GrueMaster> Thank the gods for dhcpd config on mac address.
<rsalveti> :-)
<dcordes> rsalveti:
<dcordes> I can't start anything on the display
<dcordes> I am on http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100827.1/maverick-preinstalled-netbook-armel+omap4.img.gz
<rsalveti> do you get at least a mouse pointer?
<dcordes> I don't think so. although oem-config worked fine
<dcordes> I see no errors in Xorg log about input
<rsalveti> hm
<rsalveti> try loading X and then some application by hand
<rsalveti> just X
<dcordes> ok
<dcordes> brb (I only have one keyboard)
<dcordes> should setup usb net kernel..
<dcordes> rsalveti: that worked. I started X and from another terminal ran DISPLAY=:0 netbook-launcher-efl
<rsalveti> hm, so at least not a display problem
<dcordes> and wow guys this interface is awesome
<rsalveti> something is not calling nb-launcher-efl
<dcordes> can't wait to shoot a video to show how good it looks on the HD2 !
<dcordes> are there gdm logs ?
<GrueMaster> I'm seeing the same thing on beagleboard now.
<dcordes> GrueMaster: should we open a bug
<dcordes> grep -ri launcher-efl /etc/X11/
<GrueMaster> yea, if we can figure out the cause.  Looking at .xsession-errors.
<dcordes> somebody ate the corret session script ? :)
<GrueMaster> Seems clutter is trying to run.
 * GrueMaster would rather be golfing.
<persia> This is with a jasper-initialised system?  The session correction was in jasper last I checked.
<GrueMaster> still is.  Not sure what got foobarred.
<GrueMaster> I ran the fix manually.  Will see what happens after reboot.
<GrueMaster> wonderful.  reboot and it now can't find the root partition.
<dcordes> Window manager error: Unable to initialize Clutter.
<GrueMaster> Yea, that's what I said.
<GrueMaster> Try running "sudo /usr/lib/gdm/gdm-set-default-session une-efl"
<dcordes> GrueMaster: Just confirming ;)
<rsalveti> lots of updates on clutter side
<rsalveti> probably the cause
<GrueMaster> On the image after pre-inst?  Jasper should be overriding that.
<GrueMaster> weird.  somehow the uuid for root changed.  That or jasper screwed up.
<rsalveti> GrueMaster: hm, it shoudn't
<rsalveti> otherwise you'll not be able to mount rootfs
<dcordes> !625591
<ubot2> Factoid '625591' not found
<GrueMaster> Yea, I know.  But I am staring at a system that has a different uuid for rootfs as what is in boot.scr
<dcordes> https://bugs.launchpad.net/ubuntu/+bug/625591
<ubot2> Launchpad bug 625591 in ubuntu "[ARM] ubuntu-netbook xsession broken (affects: 1) (heat: 6)" [Undecided,New]
<rsalveti> dcordes: cool, thanks for reporting it
 * GrueMaster manually fixes uuid to proper goodness.
<rsalveti> I'm out now but will also debug the image later on
<dcordes> rsalveti: heh it's time to repair my horrible karma on this channel
<dcordes> I will try to help out as good as I can
<rsalveti> that's always nice :-)
<persia> dcordes, Future note: syntax is like bug #3
<ubot2> Launchpad bug 3 in mono (Ubuntu) (and 2 other projects) "Custom information for each translation team (affects: 1) (heat: 2)" [Undecided,Invalid] https://launchpad.net/bugs/3
<rsalveti> dcordes: please subscribe "armel" group at arm related issues :-)
<rsalveti> then we can quickly check it
<GrueMaster> Actually, add armel to the tags and subscribe ubuntu-armel-porters.
<rsalveti> sure, forgot about htat
<dcordes> sorry, I have seen the tags but how to 'subscribe' ?
<persia> On the right "subscribe someone else"
<persia> The tag is more important, usually.
<persia> (and would be auto-generated if you ran `ubuntu-bug ubuntu-netbook` to file the bug (replace "ubuntu-netbook" with another package if you know better))
<dcordes> Ok thanks a lot.
<dcordes> persia: Ok next time I will use the ubuntu-bug program
 * persia finds it easier than remembering all the details about doing it manually in LP
<dcordes> GrueMaster: So you think it is related to uuid or clutter problem ?
<GrueMaster> Not sure what the uuid problem is.  Could be just a plbkac issue (I'm juggling 3 images on 4 systems atm).
<GrueMaster> Something that would help for testing & reporting issues.  https://wiki.ubuntu.com/MobileTeam/BugWorkflow
<dcordes> Thanks that's a useful wiki page
<GrueMaster> It's a little dated, but most of it is accurate.
<dcordes> How can I make the bug affect a package after reporting ?
<GrueMaster> sudo /usr/lib/gdm/gdm-set-default-session une-efl seems to have fixed my gdm default session.
<GrueMaster> The easiest way is to use ubuntu-bug <packagename>.  After, it is up to members of bug control to triage.
<dcordes> Also I can't subscribe to someone else 'ubuntu-armel-porters' LP says it expects a LP id or email address.
<dcordes> Yeah I will use that in future. But now that I created this bug manually already it would be nice to fix it.
<GrueMaster> Well, since I'm now on bug control, I can do that.  :P
<dcordes> :>
<Baybal> i can remember running linuxes on my long time dead hp4700
<Baybal> i wonder if DanaG1 uses ubuntu or android
<adcomp> 'llo ..
<GrueMaster> dcordes: Fixed data & confirmed bug 625591
<ubot2> Launchpad bug 625591 in jasper-initramfs (Ubuntu) "[ARM] ubuntu-netbook xsession broken (affects: 1) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/625591
<dcordes> Baybal: I bet the 1 is only an extension to the nickname in case the original nickname is in use and does not represent t-mobile g1
<Baybal> oh
<Baybal> by the way, g1 seem to be a great place to deploy desktop distro on...
<dcordes> Baybal: I am working on a phone distro for the G1 :)
<GrueMaster> Updated title to be a little more detailed.  bug 625591
<ubot2> Launchpad bug 625591 in jasper-initramfs (Ubuntu) "[ARM] ubuntu-netbook defaults to 3D session even after "fix" by jasper-initramfs (affects: 1) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/625591
<dcordes> Baybal: the htcdream (g1) display resolution is not large enough for a full desktop like gnome or so
<persia> Ubuntu isn't a "desktop distro", it's just a distro, with lots of flavours.  I wouldn't put any of the -desktop packages on a phone, but there are slighter-weight solutions around.
<Baybal> fbpanel + matchbox although worked quite well
<dcordes> GrueMaster: thanks a lot !
<Baybal> hp4700 had vga screen
<GrueMaster> Heh, no problem.  We all have to start somewhere.  And the more eyes we have on the arm stuff, the better it will be in the end.
<dcordes> Baybal: many recent smart phones have wvga
<Baybal> yea
<Baybal> one toshiba pda had it back in 2004 though
<dcordes> Baybal: Yeah, the mobile makret has been there. Also see Sharp Zaurus family (VGA touchscreens)
 * GrueMaster drools over the Droid X.  HDMI out.
<GrueMaster> Well, my eyes are starting to bug out, and it is a nice afternoon/evening.  Cutting out and heading to the links.
<dcordes> GrueMaster: Enjoy ! And thanks for the help
<Baybal> they have 5" xga in their recent model
<DanaG> Baybal: I don't have a smartphone right now.
<DanaG> Oh, and that Toshiba AC100 seems interesting... a bummer they phail by using a smartphone OS, without the smartphone apps store, on it.
<ogra> 2D session fix uploaded, we should have only one panel with the right applets now (still need to figure out how to get the shutdown applet there, but given that shutdown hangs anyway on bringing down usb0 ...)
<persia> Cool.
<ogra> was just a copy paste job :)
<ogra> (less than 10min including testing, i just couldnt do it without working session)
 * ogra vanishes again
<persia> Awww....
 * dcordes needs to find a way to have onboard popup when text input is expected and have it appear afterwards
<dcordes> s/appear/disappear/
<dcordes> is it expected no input help appears in oem-config ? I am missing the possibility to show keyboard
<GrueMaster> dcordes: I don't think the image is geared towards touch screens yet.   It is mainly derived from the x86 Netbook image.  While we are working on multitouch in a different group, I don't think it will make Maverick, and I know it won't be tested on arm very much.
<dcordes> GrueMaster: utouch I have seen it. very interesting
<dcordes> GrueMaster: I even have a touchscreen driver with multitouch support
<GrueMaster> Drivers exist, yes.  Hardware, not so much.
<dcordes> Well I got both
<dcordes> Maybe I can help testing
<GrueMaster> One thing you can do is file a bug against oem-config for adding touch screen support.  Make sure the bug report is as detailed as possible.  Add me to the subscribers list, and I can triage it and tweak as needed.
<dcordes> GrueMaster: Awesome, will do that.
<dcordes> I am also a bit worried about evtouch screen rotation. A bug exists for a while but it's not solved yet
<GrueMaster> Lack of hardware for developers to work with.  I have a Motorola Droid, which is the same base hw as the beagleboard, but I really don't want to sacrifice my cell phone for development yet.  These cost a lot of $$$.
<dcordes> That's what I'm doing htc hd2 is my day to day and development phone :)
<dcordes> Awesome now I have working backlight control in ubuntu :)
<dcordes> any Utouch contributors present ?
<devilhorns> hmm, when setting up an arm environment for qemu via: https://wiki.ubuntu.com/ARM/RootfsFromScratch , is it normal for the process to stall a very long time w/ libbonoboui2-common ?
<lool> devilhorns: probably not
<devilhorns> lool, yea, turns out my image was too small for everything
<devilhorns> got it sorted out now tho, thanks
<dcordes> devilhorns: stumbled across same problem few times with first rootstock attempts
<devilhorns> dcordes, hehe :)
<dcordes> devilhorns: be aware it is currently impossible to rootstock a full ubuntu image. it will fail installing mono
<devilhorns> dcordes, that's ok, just doing arm netbook stuff :) don't need a full desktop image :)
<dcordes> devilhorns: I am not sure but I think ubuntu-netbook will install mono as well
<devilhorns> ugg, I hope not :)
<dcordes> devilhorns: The savest thing is to roostock ubuntu-minimal and do anything else natively
<dcordes> devilhorns: That's what I did
<devilhorns> dcordes, ok, thanks for the tip :) Seems to be working so far tho...we'll see
<dcordes> https://launchpad.net/project-rootstock
<dcordes> https://wiki.ubuntu.com/ARM/RootStock/KnownIssues
<dcordes> devilhorns: good read
<devilhorns> dcordes, k, yea first one is of little use to me, but the Known Issues is good to know, thanks
<devilhorns> all this rootfs stuff is a little new for me ... not normally a *buntu user
<dcordes> Ok don't hesitate to ask if you got any questitions
<devilhorns> thx :)
<dcordes> questions even
<devilhorns> hehe
<persia> dcordes, You ought be able to get onboard to do the right thing: investigate under the accessibility menu.
<dcordes> persia: Is it expected to autohide ?
<persia> I believe so, as it can take up a chunk of the screen.
 * persia enables to check
<persia> it doesn&t autohide for me, but there is a mismatch between the onboard display layout and the keypresses sent to my irc client '*
<persia> Seems to use a US layout internally, for some reason.
 * persia files a bug
<dcordes> persia: You think I should file an improvement bug for the autohide ?
<dcordes> persia: As an option I thought about using a tiling window manager like matchbox. But that will cut good screen area permanently and I only have 800x480
<persia> I'd recommend getting in touch with upstream to make sure they are happy with using it also as a touchscreen base.
<persia> They're active folks, but concentrated on accessibility, which may have different driving requirements.
<persia> https://wiki.ubuntu.com/Accessibility/Projects/onBoard/ seems to document some of the ideas they've had to date.  I don't seem to find their mailing list offhand, but you might with a bit of digging.
<dcordes> persia: Ok I will contact them. One big improvement over previous versions is the new layout. And in case they really don't aim for touchscreen use, it is still the best option I found so far
<persia> Yeah, although the modeswitch buttons are a bit confusing
<persia> And I can't think of any good reasons why we shouldn't be collaborating between touchscreen and accessibility stuff: both groups have similar needs (can't use a real keyboard).
<persia> And high pixel densitys map well to poor motor control (e.g. using a wand in one's mouth)
#ubuntu-arm 2010-08-29
<dcordes> I'm all for it
<dcordes> persia: The wand in one's mouth metaphor is pretty nice if you want to describe my capcitive touchscreen :)
<persia> It's not a metaphor for lots of people, which is the target audience for the accessibility folk.
<persia> That's why I think there's scope for collaboration.
<dcordes> I have many other thoughts about how to improve the interface for my device
<dcordes> https://bugs.launchpad.net/ubuntu/+bug/626055
<ubot2> Launchpad bug 626055 in oem-config (Ubuntu) "oem-config: make on-screen keyboard available (affects: 1) (heat: 6)" [Undecided,New]
<dcordes> hehe first bug report I filed from my phone :)
<dcordes> I have to admit I connected a usb keyboard though
<persia> There's a way to do that for normal install images (using the accessibility prompt at the first screen).  Getting that sorted for preinstalled images is trickier.  ogra may know better, but I suspect that's really a jasper bug.
<dcordes> Ok it might not be a bug at all as I doubt it's expected on any device jasper is cut
<dcordes> i.e. maybe jasper enables it
<dcordes> I don't see much oem-config related in the jasper scripts though except for the semaphore write
<persia> The bug would be that there exists no way to enable accessibility features prior to oem-config launch on a jasper-based system.
<persia> One ought be able to turn on that stuff, if needed, so that it's available later.
<dcordes> Well if there is an option to enable that in oem-config the bug is still valid
<dcordes> Because it's disable currently
<persia> Hrm.  Interesting point.  Because those needing accessibility features might need to turn them on for preinstall devices that have keyboards (which can't be used).
<persia> yeah, I guess oem-config isn't a bad place.
<dcordes> persia: Actually GrueMaster suggested it ;)
 * dcordes looking at oem-config package
<dcordes> Well wherever the oem-config configuration is I guess the best solution will be to write one with accessibility feagures turned on in all netbook builds
<dcordes> s/feagures/features/
<dcordes> good night
<dcordes> persia: Thanks for the advise
 * persia doesn't think everyone needs them enabled, but everyone needs the ability to start them
<DanaG> Say, I sure hope the Linaro stuff will result in those TI DSP-accelerated codecs being packaged.
<DanaG> As it is right now, getting the DSP stuff to compile is cryptic and confusing.
<prpplague> DanaG: indeed
<armin76> i've hit bug 599862 on superh
<ubot2> Launchpad bug 599862 in pth (Ubuntu) (and 1 other project) "pth_init() aborts on armel with "longjmp causes uninitialized stack frame" (affects: 1) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/599862
<lool> armin76: I think it breaks apr too
#ubuntu-arm 2011-08-22
<GrueMaster> Daviey: I'll start looking at them this week.  Just returning from holiday/vacation.  Need a vacation just to relax from the vacation.
<Daviey> ogra_: Do you have a minute?
<Daviey> ogra_: I was hoping you could help me with qemu-system-arm? :)
<ogra_> Daviey, whats up ?
<Daviey> ogra_: I'm really sucking in trying to get either the server cloudimg's or the core images running in qemu-system-arm
<Daviey> They don't seem to output to tty.. and i couldn't get data over serial.
<Daviey> So i'm not convinced i'm doing it right.
<Daviey> I've been trying versatile(a|p)b
<ogra_> on what host ?
<Daviey> amd64
<ogra_> versatile is rather dead
<ogra_> no, which release i mean :)
<ogra_> (on the host)
<Daviey> Oh, oneiric
<ogra_> ah, better use vexpress
<Daviey> vexpress is the favoured machine?
<ogra_> right, omap should also work i think
<nicofs> I am having issues installing libscrollkeeper0 from karmic/lucid repos. all i get is 404... what can i do?
<Daviey> ogra_: Could i ask you to try, http://cloud-images.ubuntu.com/oneiric/20110821-armel/oneiric-server-cloudimg-armel.tar.gz (tarball contains a disk img and kernel))
<ogra_> phew, sure, let me install the qemu stuff, i havent used that since a year or so
<ogra_> hmm, though i have no oneiric x86 machine
<Daviey> ogra_: I can give you ssh access to a virtual machine if that helps?
<Daviey> but no graphical interface if you want that
<ogra_> nah, let me roll an oeniric chroot quickly
<Daviey> ogra_: expect beer.
<ogra_> Daviey, oh, btw, http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110822/ ac100 images ... (they dont work yet, but are close)
<Daviey> ogra_: Oh awesome!
<Daviey> ogra_: although, for bare metal arm - i care more about the images working through D-I. :/
<ogra_> indeed
<ogra_> we dont use them yet untl we have real arm server HW ...
<Daviey> .. unless someone writes a pxe enabled dd script :)
<ogra_> thats trivial
<ogra_> Daviey, so how is your image expected to work ? for the beagle emulation you need a full disk image with boot partitions
<ogra_> *partition
<ogra_> (containing x-loader and u-boot etc)
<Daviey> ogra_: We don't have much idea :)
<ogra_> well, you should produce something similar to what we build on the imagebuilders
<ogra_> a two partition image with the boot bits in the first (vfat) partition
<ogra_> and then go from here https://wiki.linaro.org/Resources/HowTo/Qemu-beagleboard
<Daviey> ogra_: I'm loathed to try and replicate what your team is doing.
<ogra_> well, probably vexpress can boot more similar to what versatile was
<ogra_> that would make it easier
<Daviey> ogra_: Does it have isa-serial per chance? :)
<ogra_> no idea
<ogra_> i never used it :)
<Daviey> yeah, libvirt seems to think everyone wants it :)
<ogra_> https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress
<ogra_> that looks more backwards compatible to versatile than qemu
<ogra_> and it seems to be able to emulate 1G
<ogra_> heh, ..."If you want you can add "-smp 4" to make it boot as a 4-core SMP model."
<Daviey> heh
<Daviey> ogra_: Who would be the best person for utlemming to work with to fix our build process?
<Daviey> utlemming is our cloud image master. :)
<ogra_> well, lets find a proper concept first :)
<ogra_> hummmm....
<Daviey> ogra_: Well use case is two fold:  1) Emulated ARM hardware using qemu-system-arm.. 2) Some manipulation to get it running on bare metal (probably pandaboard) via LXC.
<ogra_> we dont seem to build vexpress netinst images anymore
<ogra_> so there is no vmlinuz :(
<Daviey> argh
<ogra_> i wonder if linaro has something like that
<ogra_> Daviey, so using vexpress it cant determine the filesystem of the img it seems
<Daviey> argh
<ogra_> what fs is it ?
<Daviey> $ file oneiric-server-cloudimg-armel.img
<Daviey> oneiric-server-cloudimg-armel.img: Linux rev 1.0 ext4 filesystem data, UUID=87915972-5866-47e0-af76-306c3a1143b4, volume name "cloudimg-rootfs" (extents) (large files) (huge files)
<ogra_> oh
<ogra_> it doesnt try ext4 at all
<Daviey> ah, ok - what should it be?
<ogra_> it checks ext2/3 above the mount error
<ogra_> [    1.231251] No filesystem could mount root, tried:  ext3 ext2 cramfs vfat btrfs
<Daviey> Odd that it supports btrfs but not ext4 :/
<ogra_> Daviey, so here is what i did ...
<ogra_> pulling the latest vexpress hwpack from http://snapshots.linaro.org/oneiric/vexpress-oneiric/20110822/0/images/hwpack/
<ogra_> (there is sadly no "current" link and the hwpacks have version numbers in their filename)
<ogra_> unpack it, dpkg -x pkgs/linux-image-3.0.0-1001-linaro-vexpress_3.0.0-1001.1~ppa~natty_armel.deb .
<ogra_> qemu-system-arm -kernel boot/vmlinuz-3.0.0-1001-linaro-vexpress -M vexpress-a9 -cpu cortex-a9 -m 1024 -append 'root=/dev/mmcblk0 rw mem=1024M raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB devtmpfs.mount=0' -sd oneiric-server-cloudimg-armel.img -nographic
<ogra_> ...
<ogra_> heh
<ogra_> root@osiris:/root/tmp# grep EXT4 boot/config-3.0.0-1001-linaro-vexpress
<ogra_> # CONFIG_EXT4_FS is not set
<ogra_> intresting, not even a module
<Daviey> ogra_: that is great!  What do we need to do, to get the hwpack into Oneiric?
<ogra_> the vexpress package might be in the archive somewhere actually
<Daviey> Ah ok, does vexpress max out at 512MB of RAM like versatile?
<ogra_> there you go http://ports.ubuntu.com/pool/main/l/linux-linaro-vexpress/
<ogra_> it should apparently support 1G
<Daviey> groovy.
<ogra_> Daviey, if you download the kernel-image udeb (you can also extract that with dpkg -x), that only contains vmlinuz and System.map
<Daviey> ah, worth knowing
<Daviey> ogra_: So, is there a reason it shouldn't support ext4?  Ie, should i raise a bug - or is there a logical reason?
<ogra_> are your instrances supposed to survive reboots ? or is it some throw away thing ?
<ogra_> i dotn see a reason to not support ext4
<ogra_> if its throw-away i would actually go without journal, that speeds up I/O (and if you dont need reboot-recovery the journal is rather moot anyway)
<Daviey> ogra_: should be persistent across reboots
<ogra_> ah, k, then better keep a journal ;)
<Daviey> although perf is probably more importiant than reliability at this stage IMO :)
<ogra_> well, talk to linaor if you need config chaneges in the kernel
<ogra_> *linaro
<Daviey> linaro being on a different release cycle to us kind of concerns me to rely upon their kernel TBH.
<ogra_> the packages in the ubuntu archive fall under the ubuntu release schedule
<ogra_> (not more QA than other universe packages indeed)
<ogra_> but indeed you can use omap instead, but with less ram and more complex image creation
<ogra_> (since the vm behaves exactly like a beagle you also need a matching image)
<Daviey> Yeah, i want to be able to allocate as much memory as possible.
<Daviey> Ieally up to 16GB :)
<ogra_> lol
<Daviey> Ideally*
<ogra_> so you should go into qemu hacking and invent a VM that can do that
<ogra_> i think the vexpress is the biggest we have up to now
<ogra_> also dont expect great performance of qemu in general
<nicofs> I'm trying to do "sudo -s" in console, but all i get is "sudo: must be setuid root" - what can I do?
<nicofs> The system I use (Ubuntu inside maemo on N900) arrived with that glitch. I did nothing to provoke that, I can't reinstall to fix it.
<rajendra> help
<Daviey> utlemming: Hello!
<utlemming> howdy Daviey
<Daviey> utlemming: meet ogra_ and NCommander.. they are your new best friends, which we will have to buy lots of beer for at UDS>
<utlemming> hello ogra_ and NCommander
<Daviey> utlemming: So ogra_ managed to get your images working by doing, http://pb.daviey.com/nINF/
<Daviey> ext4 isn't supported by the kernel at this stage, which is why you've changed it to ext3.
<utlemming> I just pulled ext4 out of the recipe
<utlemming> and I was working on the in-image kernel
<utlemming> looking at your pastebin, do we not have a working Ubuntu-provided kernel?
<Daviey> You should be able to use, http://ports.ubuntu.com/pool/main/l/linux-linaro-vexpress/
<Daviey> utlemming: I got a proof of concept with openstack starting the instance, but i lucked out with the options.. If you are able to ack that process works.. we should be able to land that soon.
<utlemming> yeah, the change shouldn't be too difficult. I should have confirmation shortly.
<utlemming> do we not have a 3.0.0.x kernel for arm images in the ports pool?
<Daviey> utlemming: apparently, https://launchpad.net/ubuntu/+source/linux/3.0.0-9.12/+build/2733971
<utlemming> ah...okay, so I was using the right kernel :)
<Daviey> pass. someone from the arm team is best placed to answer that.
<GrueMaster> utlemming: We do for omap/omap4, not sure why there isn't one for vexpress.
<utlemming> I was building the cloud images with the omap kernel simply because it was the only one current for the 3.0.0.x kernel tree.
<GrueMaster> Might be a question for ppisati.
<utlemming> ppisati: can you chime in on the building of vexpress arm kernels?
<NCommander> Daviey: why am I buying utlemming beer?
<Daviey> NCommander: Awesome!  You can buy me one aswell.
<Daviey> NCommander: I think you didn't parse it correctly, beer is being provided for you, not by you.
<NCommander> Daviey: er,I just asked why you are buying me beer
<NCommander> oh, awesome
<NCommander> yay
 * NCommander got wired crashed and might be semi-sleep deprieved
<charlie-tca> Can I get one too?
<Daviey> charlie-tca: no.
<charlie-tca> oh, well. Worth asking, anyway :)
<Daviey> charlie-tca: heh, sure you can - utlemming is buying.
 * GrueMaster sighs.  Everyone always ignores the QA guy when beer is involved.
<charlie-tca> +1 GrueMaster
<rajendra> Hi, ogra_
<rajendra> this is regarding USB OTG
<rajendra> last tuesday u had mentioned that u will update the status on USB OTG
<nicofs> How can I generate a new .Xauthority file?
<utlemming> has anyone had success with the vexpress kernel and networking?
<utlemming> I'm seeing "qemu: hardware error: lan9118: Unimplemented MAC register write: 9 = 0x8100"
<Daviey> utlemming: lool experienced that a while ago
<utlemming> Daviey: thanks
<Daviey> utlemming: we need to cherry pick, http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02900.html
<Daviey> Or with a better comment, http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=commitdiff;h=a0313c00fc
 * utlemming looks to test patch
<Daviey> utlemming: If that resolves it, lets get a debdiff / branch together to upload.
<utlemming> Daviey: sure thing
<utlemming> Daviey: patch confirmed
<Daviey> utlemming: rocking, show me the money^D debdiff
<utlemming> Daviey: http://uec-images.ubuntu.com/oneiric/20110822-armel.2 (new images)
<Daviey> utlemming: ROCKING.. can you throw me the qemu-system-arm command line you tested it with?
<utlemming> Daviey: give me a minute...the image isn't pinging so I think my network setup needs some work
<Daviey> bah, who needs network access.
<lool> utlemming: vexpress networking only half works sadly; I get some packet drops when doing a netinst  :-/
<lool> utlemming: but I didn't get your failure
<lool> https://bugs.launchpad.net/qemu-linaro/+bug/799757
<ubot2> Ubuntu bug 799757 in qemu-linaro "Network unstable with vexpress model" [Undecided,New]
<utlemming> lool: well then, whats your qemu invocation?
<utlemming> I'm using: qemu-system-arm -kernel boot/vmlinuz-3.0.0-1001-linaro-vexpress -M vexpress-a9 -cpu cortex-a9 -m 1024 -append 'root=/dev/mmcblk0 rw mem=1024M raid=noautodetect console=ttyAMA0 ip=10.1.6.2::10.1.6.1:255.255.255.0 rootwait vmalloc=256MB devtmpfs.mount=0' -sd oneiric-server-cloudimg-armel.img -net nic,vlan=0 -net tap,vlan=0 --nographic
<lool> utlemming: I'm not passing any -net, not sure what raid=noautodetect does and the one thing which is bad here is your -sd which should be -drive file=sd.img,if=sd,cache=writeback
<lool> you don't actually need -cpu
<lool> I believe you want console=ttyAMA0,115200
<lool> I don't know why you pass vmalloc=256MB devtmpfs.mount=0 either
<utlemming> both those were feed to me by http://pb.daviey.com/nINF/
<utlemming> lool: well, that worked better
<utlemming> Daviey: use qemu-system-arm -kernel boot/vmlinuz-3.0.0-1001-linaro-vexpress -M vexpress-a9 -cpu cortex-a9 -m 1024 -append 'root=/dev/mmcblk0 rw mem=1024M console=ttyAMA0,115200 rootwait ' -drive file=oneiric-server-cloudimg-armel.img,if=sd,cache=writeback --nographic
<Daviey> utlemming: is this on oneiric?
<utlemming> I'm using natty. Firing up oneiric now
<lool> utlemming: --nographic should be -nographic
<utlemming> yup, it should. But qemu didn't spawn an SDL window
<Daviey> utlemming: Argh!  That explains why it's not fixed for you :)
<Daviey> .. and why i started ranting :(
<utlemming> My pleasure to increase your stress level a bit
<Daviey> utlemming: I live for stress, yeah baby!
<utlemming> Asside from being _dog_ slow, I can confirm the image boots
<lool> utlemming: drop -nographic if you want the SDL window
<utlemming> lool: is SDL faster?
<lool> no
<lool> but it gives more features
<lool> you can switch between qemu console, serial console and fb
<lool> I usually disable graphics and use -serial stdio to get the output of ttyAMA0 on my terminal
<utlemming> lool: do you have any suggestion for making it run any faster?
<lool> utlemming: only use one CPU, not SMP (1 x cortex-a9 is fine); disable safe writes (-drive above); put the -sd in tmpfs; run on a fast intel box  :-)
<lool> utlemming: it will be slow though
<lool> utlemming: some useful things can be run under qemu-arm-static instead; you will be using your intel kernel and hosts' files
<lool> depends what you're doing, and some things also fail utterly in that mode
<utlemming> the images are being installed under qemu-system-arm -- it takes about an hour to generate the images, but works well for debootstrap
<michaelh1> Anyone about?  I'm seeing a 20 % drop in performance after updating my PandaBoard kernel to 3.0.  Looking for some kernel hackers...
<GrueMaster> michaelh1: Describe your test method.
<michaelh1> GrueMaster: CoreMark, which is a CPU bound benchmark.  First noticed on my own NEON benchmark which shows the same results.
<michaelh1> GrueMaster: NFS root.  Build CoreMark.  Boot into a random 2.6.35.  Run CoreMark.  Boot into linux-linaro 3.0.  Run same binary.  Compare.
<michaelh1> GrueMaster: The bogomips in /proc/cpuinfo is also at ~80 %
<michaelh1> LP: #831683
<GrueMaster> michaelh1: I'd have to check, but I believe there was an issue with the cpu speed above 900mhz in the kernel (may have been beagleXM).
<GrueMaster> lp 831683
<ubot2> Launchpad bug 831683 in linux-linaro "Performance regression between 2.6.35 and 3.0" [Undecided,New] https://launchpad.net/bugs/831683
<GrueMaster> thanks, ubot2.
<michaelh1> Ah, that's the incantation!
<michaelh1> GrueMaster: the board is stable with a .35 kernel (it's used in a build farm and works quite hard)
<GrueMaster> It is highly possible that this may be related to bug 709245
<ubot2> Launchpad bug 709245 in linux-ti-omap4 "ARM SMP scheduler performance bug" [High,Confirmed] https://launchpad.net/bugs/709245
<GrueMaster> Try running with nosmp on the kernel cmdline and see if that helps performance.  Or, try ping -f to the machine while it is busy.
<michaelh1> GrueMaster: will do
<michaelh1> GrueMaster: note that the machine is idle and this is a single threaded benchmark
<GrueMaster> Well, the benchmarks we ran earlier were mainly hdparm and discovered a 10x boost with nosmp.
<michaelh1> GrueMaster: nope, nosmp has no effect.  Noted on the bug.
<GrueMaster> Ok.  Worth a shot though.
<michaelh1> GrueMaster: is there a debug flag I can set to show the clocks/frequencies that have been set?
<GrueMaster> It should be in the dmesg output or /var/log/syslog.
<michaelh1> GrueMaster: no, nothing.  We'll see what people think of the bug...
#ubuntu-arm 2011-08-23
<julumme> hi,
<julumme> I wonder if I could get some advice here, regaring Ubuntu on Beagleboard
<julumme> I'm currently running "Robert Nelsons" ubuntu image, and everything seems to work more or less
<julumme> my target is to operate serial infrared trasnceiver on the BB, and for that I chose ubuntu as I saw that lirc was there already in apt
<julumme> however, dpkg-reconfigure complains that it can't compile as I don't have kernel sources installed
<julumme> I don't really know how to compile natively on BB/ubuntu, or how could I cross compile kernel modules on a x86
<julumme> so I guess I would like to know what someone who understands how these things should be done, suggest to do
<julumme> I tried an official headless image 11.04, but I was unable to get network working on that one (I could not see eth0 nor usb0 at all)
<julumme> it would have enabled me to easily download kernel sources through apt, I guess
<julumme> anyone ?
<erbo> julumme: I think the build-essential package should give you the tools you need to compile things on your BB
<julumme> oh, I see
<erbo> But I don't know where you can get a package with the kernel source for Robert Nelson's kernel
<julumme> there is a link in the Nelson's wiki, where I could get the kernel sources for compiling myself - silly question: so if I git those to my BB, would I then be able to compile lirc against those sourecs ?
<julumme> I guess what I really need, is just the headers and binaries to link against ?
<julumme> sorry for such simple questions, it's all a bit new to me stil
<erbo> I can't see any reason why that wouldn't work..
<erbo> yeah, check http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
<julumme> looks interesting, I'll read through, that - thanks
<erbo> I don't know how good the page is, I just googled some. But it looks like it might give you some hints
<julumme> it's all good info, I'm still pretty new to development on linux
<julumme> the info was good indeed
<julumme> erbo, do you happen to know what linux-libc-dev - Linux Kernel Headers for development is ?
<julumme> I'm thinking downloading the whole source code for kernel will take ages ( and also I'm on a budget with space on the BB, as my memory card is currently only 2GB)
<erbo> apt-cache show linux-libc-dev says: "They are NOT meant to be used to build third-party modules for your kernel. Use linux-headers-* packages for that."
<julumme> :p
<erbo> :)
<julumme> ah, linux-headers-omap might be good
<erbo> But I don't know if there's a package with the headers for your custom kernel, those are probably for the ubuntu kernel
<julumme> mmm, I think there is no package
<julumme> my understanding was that Nelson compiled the default kernel for arm, with some settings for BB
<julumme> if that was the case, wouldn't it work if I had same headers ?
<julumme> oh, looks like he used 3.0.0-x2 (?) kernel
<julumme> apt only seems to have 2.6.xx stuff
<erbo> yeah he's using a much never version
<erbo> if you have the source he has used, you can just pass -C /path/to/those/sources when compiling your module
<julumme> hmm, ok, looks like I'll have to get a usb drive or something to pull the sources
<erbo> I'm not sure exactly what you need though
<julumme> he has a git link to the sources
<julumme> I'm hoping to compile lirc against his sources
<julumme> so I could configure to use serial port
<erbo> if your using a usb-stick you can grab the whole git and then you should be ok I think
<erbo> s/your/you're/ :)
<julumme> ok.. let me try that
<julumme_> hi guys, I'm trying to compile lirc for BB/ubuntu, but I'm running into a strange problem. make fails to before any compiling is done sayng "scripts/genksyms/genksyms: 1: Syntax error: "(" unexpected"
<julumme_> there is a pastebin of the whole thing here http://pastebin.com/x2w1VXcP
<satish_> what is the Hardware-accelerated player for ARM Board ?
<GrueMaster> satish_: ???
<GrueMaster> You mean gstreamer?
<rajendra_> Hi ogra_
<rajendra_> Need info regarding USBOTG
<utlemming> Anyone farmiliar with using omap kernels and qemu?
<austeregrim-wr> has ogra_ released an image for the toshiba device?
#ubuntu-arm 2011-08-24
<jo-erlend> what kind of performance can I expect from OMAP4? Is it capable of running a monitor in fullhd and play movies without problems?
<GrueMaster> jo-erlend: I have seen a single panda play 1080p movies on two screens.  Yes it can.
<jo-erlend> wow. Nice. :)
<jo-erlend> GrueMaster, I'm very interested in a pandaboard. How much difficulty will I have installing Ubuntu on it+
<jo-erlend> ?
<GrueMaster> Not hardly any..  Just follow the info on the wiki (see room topic).
<jo-erlend> and since you seem to have some experience with it... If you should compare it to a PC... What kind of PC would be comparable?
<GrueMaster> Probably an atom based system in overall performance.  The only real downside is there isn't a SATA port, so you don't get as good of HD IO performance.
<GrueMaster> The panda is essentially a cell phone development platform, but it can be good for other uses like set top boxes, wifi access point, and even some server tasks.
<jo-erlend> it is a long time since PCs surpassed my needs, so I'm considering replacing my desktop with an ARM board. I was thinking about waiting for the OMAP5, but when I look at the specs for pandaboard, it seems like a potential candidate.
<jo-erlend> the specs doesn't tell me as much though. You can't compare CPU speeds between an x86 and an ARM, right?
<GrueMaster> Not really.  Pandas run at something like 1.2Ghz, and on some tasks (like video playback) they are more than sufficient.  Other tasks, like heavy duty builds (think rebuild of openoffice) it lacks a lot.
<jo-erlend> sure. But I don't do that. I surf a little bit and I write some python code. That
<jo-erlend> s mostly it.
<jo-erlend> well, except for playing movies and such.
<GrueMaster> And overall cpu speed can be a real misnomer (more of a marketing tool than anything).  I spent 8 years at Intel doing processor validation, and back in the day, the mobile processors based on the PIII would outperform the desktop P4 based processors at half the clock rate.
<jo-erlend> the OMAP3 was a little bit too slow and didn't support 1080p, but it seemed very close to acceptable.
<GrueMaster> For the tasks you are looking at, it should be able to handle that fine.
<jo-erlend> GrueMaster, exactly.
<jo-erlend> great :)
<jo-erlend> and the dollar is cheap as well. That's a good bonus. Guess I'll get myself a couple to play with.
<GrueMaster> Heh.  I have 6.
<jo-erlend> yes, but you're a pro :)
<GrueMaster> These are personally bought.  Only one was provided.  But I can write them off at tax time.
<jo-erlend> one thing I thought I could use it for, is to attach it to a VESA wall-mount and connect it to a TV. The HDMI would transmit audio to the TV, right?
<GrueMaster> Yes.  Actually, hdmi audio works better sometimes than analog.
<jo-erlend> great. So then I'd install Synergy on it and I could control it with a laptop. That ought to be cool :)
<jo-erlend> wonder if OMAP5 will come with USB3 support.
<michaelh1> jo-erlend: I'd be surprised.  You need a ton of bandwidth...
<jo-erlend> michaelh1, that's probably why I want it :)
<michaelh1> jo-erlend: yeah, something that isn't USB like SATA would be nice...
<jo-erlend> yes, but is it likely that it'll provide both USB and SATA?
<jo-erlend> other than that, these things seems kinda perfect for a home mikroserver.
<michaelh1> jo-erlend: SATA seems unlikely on a phone targeted OMAP5.  The Samsung Orion has a port though, but I don't know if it works.
<jo-erlend> I'm amazed by how cheap they are.
<jo-erlend> I grew up with 8088 and 8086. Everything is amazing nowadays,, come to think of it :>
<twb> Is ubuntu arm equivalent to debian's armhf?  From the wiki page in /topic it looks like it, except maybe the thumb2 stuff.
<twb> Hm, that page has "How does this differ from Debian's armel port?" but not the same for Debian armhf
<julumme> is there a known fix for the headless natty image on beagleboard to get the network interface up ?
<julumme> already in the system configuration phase, it complains that there were no network interfaces detected
<julumme> (I suppose technically the image "headless omap" image for natty
<janimo> anyone running oneiric with latest kernel on the panda? 3.0.0-1203-omap4
<janimo> I get no ethernet with it
<janimo> twb, ubuntu arm is armel not armhf. It uses the soft-float ABI. There is work going on to have armhf ubuntu port by next cycle
<twb> OK, thanks.
<twb> Probably not as big a deal for me, I'm looking at the ASUS TF101, which is A9 not A8
<janimo> A9 vs A8 have mostly performance differences, but otherwise the same core architecture. Orthogonal to armel vs armhf
<twb> the wiki.d.o armhf post said they saw 40% speed improvements on A8, but expect smaller benefits for A9
<twb> "It's likely that the performance benefits are much larger on Cortex-A8 CPUs than on Cortex-A9 CPUs which have a faster VFP design and more conventional pipeline."
<twb> http://wiki.debian.org/ArmHardFloatPort
<erbo> I want to create a rootfs using rootstock, but with some custom packages that I want to host on a local repo. I figured I could use the --extra-mirror file:///path/to/repo, but it seems to me as if it only accepts ubuntu-mirrors. It complains about not finding the repo/dists/natty/main/binary-armel/Packages file. I just created a minimal repo using dpkg-scanpackages hoping that would work.
<erbo> Any pointer to what I need to do to get custom packages into a rootstock build?
<twb> Any multistrap fanboys in the audience?
<lag> ogra_: You still alive?
<lilstevie> twb: biggest issue in A8 vs A9 is that nVidia decided to kill us all by not including the NEON instruction set
<lilstevie> A8's could all run with NEON if we wanted
<twb> Yeah, I saw that
<lilstevie> that is going to be probably the biggest drawback with all hardfloat, catering for the one backwards company
<twb> You don't need to convince me that nv are douchebags
<twb> If there was a strong alternative to the TF101 I'd probably be looking at that instead, just to avoid nv
<janimo> lilstevie, I was not under the impression that neon is part of hardfp ABI. It is an optional extension to VFP
<janimo> one should still have armhf with optional neon
<twb> Marvell Dove also lacks NEON
<lilstevie> janimo: it isn't no, just it is a hinderencce to not have it
<janimo> right. tegra3 is supposed to have neon
<twb> I saw arm's Cortex-A15 page, and that also said NEON, so I guess all A15s have NEON
<lilstevie> janimo: I just mean like the likes of nv and marvell not including NEON are holding hf back
<twb> At least it's better than armel
<lilstevie> heh true
<twb> So does the TF101 just use normal nouveau/nvfb/nvidia GPU drivers?
<lilstevie> it uses the Linux4Tegra GPU drivers if you are using the right kernel
<lilstevie> otherwise fbdev
<twb> lilstevie: is your git repo based on the one at git://nv-tegra.nvidia.com/linux-2.6.git ?
<Neko> armhf doesn't rely on NEON at all
<Neko> what's holding what back?
<lilstevie> twb: no, it is based off the asus source drop + patched up using the android kernel.org repo
<twb> Hm, OK
<lilstevie> twb: however the one that allows acceleration is based off the chromeos kernel tree
<twb> Grmph, yet another tree
<twb> I hope all this work gets merged into the mainline at some point
<ogra_> lag, i am now :)
<lag> ogra_: Hey
<ogra_> yo
<lag> ogra_: On my snowball, when I start xterm using the serial console ...
<lag> ogra_: It starts but I can see lots of 1111111111111111111111111111's appear
<lag> ogra_: Any ideas?
<lag> ogra_: No keyboard is connected
<ogra_> are the serial settings correct ?
<ogra_> or wait, you export DISPLAY and run it from serial ?
<lag> The 11111111111111's aren't appearing on the serial console
<lag> Yeah
<ogra_> hmm
<ogra_> check ~/.xsession-errors
<ogra_> and /var/log/Xorg.0.log
<ogra_> if there are input layer issues you should see it there
<lag> ogra_: http://paste.ubuntu.com/673646/
<ogra_> line 3 is intresting
<ogra_> that doesnt look like an xterm though
<ogra_> your power manager looks pretty unhappy ... but that shouldnt print 1111
<ogra_> to be honest i dont see anything that could cause this but i also dont see any indication of an xterm session
<diwic> ogra_, have you started to run omap etc tests on oneiric yet?
<ogra_> diwic, what kind of tests ?
<ogra_> GrueMaster tests the images regulary
<diwic> ogra_, checking if things work? E g the new pulseaudio version
<ogra_> no, i dont think we have tested that much yet
<ogra_> everyone is so focused on server stuff atm, i'll make sure we test it asap
<diwic> ogra_, as the UCM patches are currently not included
<diwic> and I haven't heard you scream about it ;-)
<ogra_> i think the 3.0 kernel for omap4 also lacks alsa bits atm
<ogra_> i have to check that forst ...
<ogra_> *first
<ogra_> (i'm currently a bit focused on ac100 work and getting the last beta workitems done)
<diwic> ogra_, no sound news on ac100, I assume?
<ogra_> diwic, no, suspend made some progress but sond not yet
<ogra_> *sound
<diwic> okay
<diwic> yeah, hadn't had a moment to do anything here either
<ogra_> janimo, hey, i added mx5 to cdimage and fired off a first livefs testbuild
<janimo> ogra_, cool
<ogra_> for server (so archive skew doesnt bite us)
<janimo> thanks
<ogra_> lets see if something comes out at the rear end :)
<ogra_> janimo, do we have a landing page for mx5 install instructions etc ?
<janimo> this makes the live image, but did you add the boot/post-boot scripts too?
<janimo> ogra_, only the linaro one
<janimo> I'll add one to our wiki once we have the images
<ogra_> http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110824.1/ ... have a look, i re-arranged the arch specific bits for preinstalled images a bit, mx5 will currently just say "For i.MX5x boards"
<ogra_> but i think it would be good if it also pointed to a wikipage with instructions
<janimo> ogra_,  will push here as well bzr+ssh://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/ ?
<ogra_> or just pastebin the change and i'll add it
<janimo> ogra_, skeleton page: https://wiki.ubuntu.com/ARM/MX5
<janimo> I wonder if they could work on MX51 too, the kernel supports it.
<janimo> Although if Uboot, as I suspect is different, it is too much to add mx51 back
<ogra_> well, i left everything generic for now in the texts
<ogra_> k, i'll add that page to the arch stuff
<ogra_> that page can then have instructions how to modify the image for mx51
<ogra_> (if thats possible by i.e. just replacing u-boot.bin
<ogra_> )
<ppisati> janimo: it seems the .ddeb kernel pkg should do it (at least it works for i386 and amd64), testing it now...
<ppisati> janimo: talking about the systemtap support
<janimo> ppisati, thanks. There may be binaries already, but then I just did not find them :)
<janimo> the linaro systemtap wikipage points to some older binaries
<ogra_> Building dependency tree...
<ogra_> E: Unable to locate package linux-mx5
<ogra_> E: Unable to locate package linux-meta-linaro-lt-mx5
<ogra_> P: Begin unmounting filesystems...
<ogra_> janimo, ^^^
<ogra_> seems to need some livecd-rootfs changes
<janimo> ogra_, I wrote that part before the packages landed, but I thought I had gotten the names right .hmm
<ogra_> janimo, i guess thats the automatic bit trying to do the generic kernel installation
<ogra_> it somehow assembles the package name from flavour etc
<janimo> ah linux-image-linaro-lt-mx5
<janimo> oh, so the naming convention of the package is not in line with others? :(
<ogra_> it has linaro in the package name
<ogra_> it should still work if you seed it as you do atm though
<janimo> ogra_,I  will commit a change
<ogra_> yep, tell me if it hits ports.u.c, then i can trigger a new build
<ogra_> s7if/when/
<janimo> although I wonder where the linux-mx5 was gotten from, that is not put in the file
<janimo> is that the automatically generated name?
<ogra_> likely, yes
<ogra_> infinity knows that code deeper :)
<ogra_> i never know where he pulls the code snippets from he shows me :P
<janimo> I had the source package name added initially, before it was built and  I thought binary name would match
<ogra_> yeah, with the binary it shoudl work, if not, we need to dig deeper and add it to the pattern that aut-creates the package names
<ogra_> though i fear that will get hairy, while adding -linaro- might be trivial, adding the -lt- could get tricky
<ogra_> you could indeed most easily work around it by just making the meta create a binary linux-mx5 metapackage :)
<janimo> ogra_, it is probably linux-$SUBARCH
<janimo> we have linux-omap omap4 and ac100
<janimo> but not linux-ac100
<ogra_> we do
<ogra_> linux-ac100 exists
<janimo> sorry, but not linux-mx5
<ogra_> yeah
<janimo> contradicted myself above
<janimo> the linux-SUBARCH packages just seem to depend on the generic image binary
<janimo> not sure why the indirection
<janimo> jcrigby, ^. Would it be too much hassle or counter to linaro naming conventions to provide a linux-mx5 package that depends on the current generic mx5 image ?
<janimo> that is the way ubuntu kernel packages are from what I see
<ogra_> Package: linux-mx5
<ogra_> Architecture: armel
<ogra_> Section: metapackages
<ogra_> Priority: optional
<ogra_> Depends: ${misc:Depends}, linux-image-linaro-lt-mx5 (= ${binary:Version})
<ogra_> Description: ....
<ogra_> just add that bit to debian/control in the linux-meta-linaro-lt-mx5 package
<ogra_> (and massage the new binary through the NEW queue)
<janimo> I just had my first relatively pleasant UDD experience (hope it also gets built :). First time I did not spend more on looking up debcommit & co docs for more than 5 minutes
<janimo> I do packaging so seldom that I keep forgetting how UDD works :(
<ogra_> i stay away from if if i can ...
 * ogra_ still prefers dealing with source packages
<janimo> hack code + changelog ||  debcommit || hack changelog || debcommit -r || bzr push || bzr bd -S || dput
<janimo> UDD in a tweet :)
<hrw> how sync requests should go now?
<hrw> gtk-gnutella 0.97-2 needs to be synced to fix bug 823709
<ubot2> Launchpad bug 823709 in gtk-gnutella "gtk-gnutella version 0.97-1 failed to build on armel" [Unknown,Fix released] https://launchpad.net/bugs/823709
<ogra_> use the requestsync script as usual ?
<hrw> ok
<hrw> bug 832692 then
<ubot2> Launchpad bug 832692 in gtk-gnutella "FFe: Sync gtk-gnutella 0.97-2 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/832692
<ogra_> janimo, new livefs mx5 build running
<janimo> ogra_, works without the linux-mx5 metapackage?
<ogra_> no idea, running
<ogra_> didnt fail yet
<ogra_> though that usually takes a while
<ogra_> janimo, ...
<ogra_> Reading package lists...
<ogra_> Building dependency tree...
<ogra_> E: Unable to locate package linux-mx5
<ogra_> P: Begin unmounting filesystems...
<janimo> ogra_, right, the missing meta package , as expected
<ogra_> well, i had hopes we could get around it
<janimo>  did you work around it elsewhere?
<ogra_> nope
<ogra_> i was hoppig it is clever enough to recognize that we have a kernel in place already
<ogra_> but it apparently isnt, so we should change the metapackage
<janimo> right
<janimo> jcrigby, ogra https://bugs.launchpad.net/ubuntu/+source/linux-meta-linaro-lt-mx5/+bug/832744
<ubot2> Ubuntu bug 832744 in linux-meta-linaro-lt-mx5 "please provide linux-mx5 meta-package binary" [Undecided,New]
<jcrigby> janimo, ogra_ : looking at your conversation above...
<ogra_> you should be able to just copy/paste what i dumped into the channel above
<jcrigby> ogra_, and that replaces this:Depends: ${misc:Depends}, linux-image-${kernel-abi-version}-linaro-lt-mx5, linux-firmware
<ogra_> just add it additionally to the existing bits
<ogra_> (not replacing anything, i assume teh existing binaries have a usecase)
<jcrigby> ogra_, ahh ok, this is a section that disappeared in my first meta for linaro the the linaro build was changed to deal with it.  Sorry, I didn't really have a clue what I was doing back then.  Still fuzzy on some things even now:)
<ogra_> no, what you did is perfectly fine for your typical packages
<ogra_> its just if we want to use your kernel with the ubuntu buildsystem that a package named linux-$flavour needs to exist
<jcrigby> got it
<ogra_> if you would have done the same with omap i would have shouted ;)
<jcrigby> ok, thats easy, I'll do it right now
<ogra_> since there we have linux-omap already and that would clash
<ogra_> mx5 is special here
<jcrigby> ahh
<ogra_> janimo, if that change has landed you can actually drop everything but the bootloader stuff from your live-build/auto/config line
<ogra_> GrueMaster, why did you set preseed testing for preinstalled to BLOCKED ? i thought we talked about that before your vac. presseding works fine but you have to do it on cmdline
<ogra_> (that shouldnt block testing)
<janimo> ogra_, in debian-cd what is the separation of boot and post-boot scripts for?
<janimo> the different subarchs do not use those consistently
<ogra_> you likely wont need boot
<ogra_> post-boot is fine, ignore the other
 * janimo learns about apt-cache policy
<janimo> ogra_, ok
<infinity> ogra_, jcrigby : Don't make a linux-mx5 metapackage, it will break some other code assumptions.
<infinity> janimo too.
<ogra_> infinity, huh ?
<infinity> I have to run to a doctor's appointment, but I'll help you deal with this in a sec.
<infinity> ogra_: Just trust me.
<ogra_> why ? it doesnt break for ac100 either
<infinity> ogra_: It doesn't break for ac100 because ac100 is actually your kernel flavour.
<infinity> mx5 isn't.
<ogra_> weird ... but we'll wait for enlightenment :)
<jcrigby> ok, I'll wait for you smart folks to figure this out before pushing anything
<infinity> Anyhow.  Back ina couple of hours.  Tonsil specialist appointment. :/
<ogra_> mx5 isnt ? what does uname have ?
<ogra_> oh my, good luck
<infinity> linaro-lt-mx5
<ogra_> urgh
<infinity> *runs*
<ogra_> janimo, so seems we need to change the pattern matching in livecd-rootf
<ogra_> s
<ogra_> (or live-build effectively)
<infinity> Before I run..
<infinity> In the SUBARCH case statement, something like FLAVOURS=linaro-lt-mx5 in the mx5 case statement should do the trick.
 * ogra_ must admit he doesnt really get why uname has any influence though, given we dont actually run the kernel
<infinity> Since FLAVOURS normally is jst set to SUBARCH.
<ogra_> ah, cool, thats easy
<infinity> ogra_: There's pattern matching elsewhere that makes it matter.
<ogra_> ah
<infinity> ogra_: Since uname also lands in the filenames.
<infinity> Kay, gone now. :)
<ogra_> of the build host ?
<ogra_> weird
<infinity> ogra_: No, uname of the kernel is in the filenames of the kernel and initrd, and we pattern match on those like craz.
<infinity> crazy*
<ogra_> ah, k
 * ogra_ gets it now
<ogra_> aha
<ogra_> KERNEL_FLAVOURS="${SUBARCH:-$KERNEL_FLAVOURS}"
<ogra_> ok, the var is actually LB_LINUX_FLAVOURS
<ogra_> janimo, ^^^
<ogra_> LB_LINUX_FLAVOURS="linaro-lt-mx5" should work
<infinity> ogra, janimoe: set kernel_flavours, not the lb_ variable.
<infinity> forgive the awful typong, lag on my phone in the waoting room sucks. :P
<infinity> janimo ^
<janimo> infinity, I need to find those things
<infinity> janimo: the same case statement where you add you botloader packages for mx5, just set KERNEL_FLAVOURS to linaro-lt-mx5
<infinity> janimo: and you don't need to explicitely install the kernek too, that variable will handle it.
<janimo> infinity, I see only core uses that variable ATM
<infinity> janimo: I can hep less awkwardly later today when I'm not typing on a touch screen with 3s latency.
<infinity> janimo: it's set 10 lines up to SUBARCH, which you don't want, hence overriding it in the mx5 case.
 * janimo wishes for a detailed dump of infinity's and other cdimage connoisseurs'  brains into a wiki or something that can feed into other people's heads
<janimo> infinity, thanks. Let's hope this change will move things forward.
<janimo> does the linux-mx5 metapackage still has a purpose then?
<infinity> Theree shouldn't be one.
<janimo> this looks again like last cycle's headless-image taks, which I was assigned to and took me about 10 times as much as it would have for someone who know cdimage. Oh well
 * janimo tries out his still fresh UDD skills again on livecd-rootfs
<infinity> Kay, actually out of the waitong room now.  Doctor time, back later.
<GrueMaster> ogra_: on the preseed thing, you also told me that you needed to do something in jasper to get it to work.  So I marked it as BLOCKED until that happens.
<GrueMaster> In fact, you still have a work item to that affect.
<hrw> bug 809760
<ubot2> Launchpad bug 809760 in unison2.27.57 "unison2.27.57 version 2.27.57-4 failed to build on armel" [Undecided,New] https://launchpad.net/bugs/809760
<hrw> can someone push 'retry build' on this page: https://launchpad.net/ubuntu/+source/unison2.27.57/2.27.57-4/+build/2620947
<hrw> ?
<ogra_> GrueMaster, that WI is for one specific preseed option to switch serial on/off ... preseeding in general works fine if syou do it on the cmdline
<ogra_> what doesnt work yet (but will hopefully tomorrow) is using a preseed file in the vfat ... that shouldnt block testing preseeding in general though
<GrueMaster> I would prefer to test all options at once.  I don't want to test it now and mark it DONE only to have it reverted yet again because I didn't test yet another as of yet un-implemented feature.
<ogra_> k
<ogra_> grr, my machine is wonky
<austeregrim> ogra_ keep up the good work =)
<rajendra> Hi, can anyone pls let me know if USB OTG as Host is working on panda board, on Ubuntu, kernel 2.6.38
#ubuntu-arm 2011-08-25
<PDunny> Howdy
<PDunny> Anyone active here?
<Lopi> anyone know why this would be happening? http://yfrog.com/h6bbx1j
<GrueMaster> Lopi: See bug 746133
<ubot2> Launchpad bug 746133 in linux-ti-omap4 "Video loses sync on omap4" [High,Incomplete] https://launchpad.net/bugs/746133
 * Jack87 wonders if folk here are considering the touchpad 
<AceLan> of course, but hard to buy one
<janimo> infinity, do you know when the .calc files in cdimage are needed? I see most but not all of the armel ones all set BOOT_SIZE_1=2 but I'd like to avoid it for mx5 if it is not strictly necessary
<ogra_> Building dependency tree...
<ogra_> E: Unable to locate package linux-linaro-lt-mx5
<ogra_> P: Begin unmounting filesystems...
<janimo> not sure what thre reserved space there is
<ogra_> janimo, hmm, that didnt go so well
<janimo> ogra_, hmm, an -image- is missing
<ogra_> yep
<ogra_> well
<janimo> the whole mucking around with cdimage is reminiscent of 'how many X are necessary to insert a lightbulb' jokes
<janimo> we'll prevail eventually
<ogra_> you should just copy the omap script and start from there
<janimo> ogra_, this is livecd right? I meant cdimage as the full build from livecd to publish
<janimo> ogra_, yes I use the omap script
<ogra_> ah, good
<ogra_> right, the above is the live-build output
<janimo> but here I deleted the explicit kernel name in the hope of it being picked up implicitly as per infinity's suggestion
<ogra_> welll, it still expects a toplevel metapackage ...
<ogra_> linux-image- is the linux-image metapackage only
<janimo> ogra_, I think so too. So one still needs adding by jcrigby
<ogra_> yes, but not called linux-mx5 but linux-linaro-lt-mx5
<janimo> right
<janimo> I thought the implicit rule (KERNEL_FLAVOUR) was about picking up the image not the meta
<janimo> I was wrong
<ogra_> oh, you didnt use the other var ?
<ogra_> LB_LINUX_FLAVOURS="linaro-lt-mx5"
<janimo> but then again we could have just left KERNEL_FLAVOUR untouched and created the linux-mx5 with the same result
<janimo> ogra_, no, I used KERNEL_FLAVOURS only. Did I misread what infinity told me? Sigh
 * janimo goes reread the logs
<ogra_> no, because other scriptds seem to use the snippet
<ogra_> and mx5 isnt the full uname string
<janimo> right
<janimo> ok
<ogra_> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ btw
<ogra_> in case you want to check any live build logs yourself
<janimo> ogra_, can you make the change in the script on antimony and see if that fixes (LB_LINUX_FLAVOURS instead of KERNEL_FLAVOURS) instead of me doind another shoot and miss upload?
<ogra_> no, live-build runs on the live builders ... not on antimony
<ogra_> i dotn have any access to fiddle on them, only http access to logs
<ogra_> so we need an upload
<janimo> sigh
<ogra_> antimony is only dbeian-cd cdimage
<ogra_> *debian
<janimo> so should I just change that varname?
<janimo> did infinity not know that off the top of his head, with a medical examination pending and all?
<ogra_> well, i'm not sure that will do much else than KERNEL_FLAVOURS did
<ogra_> i think we're better off waiting for a meta upload and keep the rest as is
<janimo> ogra_, agreed
<janimo> so no upload for now
<ogra_> unless infinity has any brilliant idea inbetween ... though i doubt he types in his sleep
<ogra_> (assuming thats what he does atm)
<janimo> ogra_, so livecd.sh is no longer used right?
<ogra_> right
<ogra_> only BuildLiveCD and the stuff in the live-build subdir
<janimo> I think we should put the 3 unused files there in the attic
<janimo> anyone can find them in bzr history
<ogra_> might be there to makes sure we have a reference for possible regressions
<janimo> cjwatson what do you think? ^
<ogra_> but i agree we should drop them before final release
<janimo> well it nevertheless confuses those looking at the code
<janimo> seems to do much more than it actually does
<ogra_> livecd-rootfs was always brilliant in confusing people ... especially its massive amount of documentation :P
<janimo> ogra_,unrelated: what about switching to ext4 before oneiric?
<janimo> what could go wrong?
<ogra_> live-build could not support it
<janimo> hmm, does it not support it on non-armel?
<ogra_> nothing beyond that, though i fear the u-boot stuff a bit
<janimo> well linaro has switched to ext4 by default
<janimo> and I test hwpacks like that
<ogra_> well, we can just try, but i suspect there are a good bunch of additional changes, it wont just be a switch we change
<ogra_> and the u-boot changes will bind our resources soon
<janimo> any other ext3 assumptions in the code?
<janimo> even the ext3 tools we call should work on ext4
<ogra_> cdimage has some and debian-cd too
<ogra_> jasper indeed as well
<ogra_> for debian-cd changing CONF.sh might suffice
<ogra_> cdimage needs changes in bin/buildlive and bin/download-preinstalled-filesystems
<janimo> we touch those these days anyway for imx53
<janimo> the linaro issue I ran into with ext4 is covered in our kernels
<ogra_> well, let me do a test run
<janimo> CONFIG_LBDAF is set
 * ogra_ changes buildlive ... that should suffice for seeing if live-build can cope on the buildd
<ogra_> ok, ac100 ubuntu-server build running with ext4 as default
<ogra_> lets see what comes out
<ogra_> argh !
 * ogra_ slaps forehead 
<ogra_> silly me... i shouldnt test with a tar.gz image :P
<ogra_> luckily we have two buildds
 * ogra_ fires off an omap server build on the other machine
<janimo> I wish there was an easy way to install a local cdimage setup to test these before uploading things
<ogra_> well, even then you couldnt easily make sure that everything is always 100% in sync
<ogra_> it consists of to many parts to be really reliable
<ogra_> imho
<janimo> working on these components is by far the most unpleasant for me, beats autoconf mucking in broken packages :)
<ogra_> you should join the cdimage team ... doing the changes on antimony makes working easier
<janimo> ogra_, remember I woved not to join this team when I had to fight headless last cycle :)
<ogra_> and there are several levels of bzr trees, so its easy to roll back
<janimo> isn't it the same craziness just via ssh?
<janimo> or can you do exaclty what the build setup does in cron?
<ogra_> yes
<ogra_> i actually use the cron commands doing testbuilds
<ogra_> with additional env vars set to limit the build to one arch
<ogra_> janimo, did you recently test any of our desktop images ?
<ogra_> on ac100 the greeter is so slow its close to unusable
<ogra_> janimo, hmm, so ext4 will need more changes in live-build it seems
<ogra_> i dont get an image file (everything else including logs , initrd and kernel files looks fine)
<ogra_> bah, so there is no ext4 support at all
<julumme> I'm running custom kernel by Robert Nelson, which I compiled for beagle/ubuntu.. now when compiling lirc serial module for it, I run into a compiling issue: scripts/genksyms/genksyms: 1: Syntax error: "(" unexpected
<janimo> ogra_, I tried testing panda a week ago, but did not come up :(
<julumme> I checked in the linux source "../scripts/genksyms" with 'file genksyms'
<julumme> genksyms: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
<julumme> scripts are not normally compiled in part of the kernel compilation ?
<janimo> ogra_, I need to test desktop images for bootcharting them, but they keep being broken when I test :(
<ogra_> the code doesnt know it
<ogra_> yeah, currently the archive skew breaks them once again
<ogra_> anyway, no ext4 for us without extra effort, live-build doesnt support it at all
<janimo> ogra_, oh well, at least you tested it. Shall we file a bug on it?
<ogra_> i think there ios a bug and an upstream patch ... one sec
<ogra_> bug 803547
<ubot2> Launchpad bug 803547 in live-build "live-build lacks EXT4 support for binary image types" [Undecided,Invalid] https://launchpad.net/bugs/803547
<ogra_> geez, the mkfs stuff in live-build is super inconsistent
<ogra_> sometimes it uses mkfs.${LB_CHROOT_FILESYSTEM}, sometimes mkfs.${MKFS} and often eough it is just hardcoded
<ogra_> ok, i reverted the default to ext3 again (but left the other ext4 code in cdimage, so we dont need to touch that again)
<jcrigby> janimo, ogra_: I see from comments above that you need something changed in the mx5 meta pkg?  Similar but different than what was discussed yesterday?
<janimo> jcrigby, yes, similar issue, but different metapackage name
<rsalveti> ogra_: janimo: also, we can already replace x-loader with u-boot-linaro spl for omap 4
<janimo> ogra_, has the exact error msg IIRC
<rsalveti> well tested and no regression with 11.08
<janimo> rsalveti, I am all for it
<janimo> but it is one of those cdimage jobs which only some folk can handle effectively
<janimo> rsalveti, good to hear it works well
<rsalveti> janimo: when can we push the new package?
<rsalveti> or, who can we talk to to make it work? ogra_ ?
<janimo> rsalveti, hmm, the new package switches to SPL with no backwards compat?
<rsalveti> would be nice to push it before beta-1
<jcrigby> janimo, that is the one downside
<rsalveti> janimo: nops, x-loader doesn't work anymore with it
<rsalveti> that's why we need to be in sync
<janimo> rsalveti, definitely before beta 1. We expect breakage these days. ogra would know better when to synchronize
<janimo> rsalveti, ubuntu-arm meeting ATM
<janimo> maybe something to bring up there ?
<rsalveti> sure
<rsalveti> jcrigby: #ubuntu-meeting
<janimo> jcrigby, rsalveti there should be an images topic soon, and then it can be brought up
<rsalveti> janimo: great
<nicofs> Hi there! Is there someone who can help me with rootstock? when trying to create a ubuntu rootfs, i get this: http://paste.ubuntu.com/674573/
<dmart> nicofs: try as root: lsof | grep /tmp/tmp.EvKThwZJAG/tmpmount/proc
<dmart> This may show what process is still using that directory
<nicofs> dmart, what process is using the image is not so much my concern as the dpkg error...
<dmart> Sometimes this is just caused by a race between some program terminating and unmounting that filesystem -- if you try again, you may find that it works
<nicofs> dmart, been trying for 2 days now...
<nicofs> dmart, --seed xubuntu-desktop works, so does ubuntu-minimal.
<dmart> nicofs: oh, I see.
<nicofs> ubuntu-desktop fails at that stage. in natty, maverick and lucid
<dmart> rootstock may spit out some logs you can look at ... I'm not sure offhand where to look, though
<dmart> Have you got a more complete log?
<rsalveti> jcrigby: ok, then it seems we only need a bug for that
<rsalveti> as we need a FFe
<nicofs> dmart, it does normally - but not in that case... they should be in the same folder as the finished rootfs...
<jcrigby> an explicit bug for the FFe or an existing bug to justify the FFe
<dmart> nicofs: maybe the logs are being deleted on error, but I would hope not.  Error conditions are when you _want_ the logs
<nicofs> dmart, what i pasted is what my console gave me... i can redirect the output of rootstock to a file and paste that...
<rsalveti> jcrigby: bug for FFe
<jcrigby> ok
<dmart> nicofs: I suggest capturing the whole log ... there may be earlier errors
<rsalveti> jcrigby: FFe: replace x-loader with new u-boot-linaro SPL
<rsalveti> something like that
<rsalveti> for omap 4
<jcrigby> rsalveti, ok got it
<rsalveti> jcrigby: https://wiki.ubuntu.com/FreezeExceptionProcess
<nicofs> dmart, yes, i just need to run it again for that... can't scroll back so far in my console...
<janimo> rsalveti, the uboot+SPL blueprint's last WI suggest UBOOT still boots with xloader.
<rsalveti> janimo: it was tested, but the test result is not posted there
<nicofs> dmart, i could try --no-root - maybe that helps...
<janimo> but is still works then with xloader? I thought xloader does not boot uboot, from what I understood
<janimo> the new uboot that is
<rsalveti> janimo: nops, just updated the bp
<rsalveti> it doesn't work with x-loader anymore
<janimo> ok
<rsalveti> because to remove duplicated code, some part of u-boot was moved to spl
<janimo> rsalveti, thanks for the clarification. I filed the FFE for uboot and linked the bp, so it helps if it is clear
<rsalveti> so once you build with spl, it doesn't work with x-loader anymore
<janimo> ok
<rsalveti> janimo: great
<dmart> nicofs: don't know -- I suggest you just repeat whatever you did last time, but capture the full log.  The first line of your paste looks like the end of an error report, rather than the whole report
<dmart> nicofs: The "script" command is useful for logging terminal sessions
<nicofs> dmart, i just started and appended " &> logfile"
<jcrigby> rsalveti, I don't understand this line:Please note that we expect requesters to have an updated package already prepared and tested! You will need this anyway to provide proper build logs.
<rsalveti> jcrigby: just to know that you already built the package locally and tested
<rsalveti> and that we already did with 11.08 release
<jcrigby> rsalveti, ok so the version in the ppa fills that part
<rsalveti> yes
<dmart> nicofs: that also should work
<nicofs> dmart, just takes quite a while... i guess about 15mins
<nicofs> dmart... ok different error... my bad... have to start again
<nicofs> just ran out of memory...
<janimo> rsalveti, linaro-media-create also needs to be uploaded, as it now assumed uboot.bin right?
<janimo> I tried 3 times today until it downed on me that what we were discussing today may be relevant to my error, not finding uboot.bin
<janimo> I mean lmc needs uboot.img on panda now. Testing 11.08 daily hwpack
<rsalveti> janimo: yeah, it's uploaded only at the PPA I believe
<janimo> rsalveti, so I'll add a new FFE and we need to add that too. Is it also stable enough?
<janimo> has the same cycle as the rest of linaro?
<rsalveti> janimo: yes
<janimo> ok
<rsalveti> would be nice to have a FFe for it too
<janimo> rsalveti, who is in charge of lmc. Can they upload or should I sponsor - asking them first if it is ok
<rsalveti> guess james_w can upload it
<janimo> rsalveti, actually not sure if it needs a FFe if it's a universe package and not part of default Ubuntu images
<janimo> NCommander, does it? ^
<janimo> it is not technically a release team supervised feature
<rsalveti> janimo: I thought all package updates that are not only bugfixing needs a FFe
<rsalveti> so even universe-only changes
<janimo> rsalveti, I may be wrong indeed. This technically fixes a bug - cannot make panda linaro images without
<janimo> also adds features I guess
<rsalveti> but is also a newer version
<rsalveti> bbl, lunch
<janimo> NCommander, https://bugs.launchpad.net/linaro-image-tools/+bug/834003 another FFE request
<ubot2> Ubuntu bug 834003 in linaro-image-tools "FFE: upload 11.08 to Oneiric" [Undecided,New]
<janimo> closely related to the uboot one
<MrCurious>   Anyone know if the USB speed issue has been solved yet?
<infinity> Nope.
<MrCurious> such is life
<PDunny> Hey guys!
<PDunny> Can anyone help me make a chroot to boot onto my touchpad?
<GrueMaster> MrCurious: Keep an eye on bug 709245.  Work is being done.
<ubot2> Launchpad bug 709245 in linux-ti-omap4 "ARM SMP scheduler performance bug" [High,Confirmed] https://launchpad.net/bugs/709245
<MrCurious> thanks gruemaster
<GrueMaster> PDunny: What kind of touchpad?
<MrCurious> you weren't kidding.. longest bug page i have seen yet
<GrueMaster> You might be able to use the ubuntu-core image.
<MrCurious> wow! almost an order of magnitude potential gains! that is going to be a game changer
<PDunny> GrueMaster - HP Touchpad
<GrueMaster> PDunny: Ok, so at least armv7.  You should be able to use the ubuntu-core image as a base.
<PDunny> Gruemaster - Would the kubuntu-mobile project be suffice? It has most of the features I am looking for in it just not sure how to make the chroot
<GrueMaster> I don't know.  I don't work with that image.  It might though.
<GrueMaster> You could probably just loop mount the image and chroot into it that way.
<PDunny> ok .... hum .... not in my ubuntu partition right now:/
<PDunny> Have yall had much luck with cellphones/tablets yet?
<PDunny> The touchpad community is essentially begging for something more than just webos so if you need testers for OMAP4 devices .....
<GrueMaster> I thought the HP system was snapdragon.
<prpplague> that is what i thought as well
<PDunny> It is snapdragon but from the research I have done it looks like it is OMAP4
 * PDunny newb not sure
<GrueMaster> Both are dual core iirc.  They may look the same for the most part.  Need to check /proc/cpuinfo.
<PDunny> I had seen somewhere that it was on a compatable list as an omap4 processor so entirely possible I was wrong, of course I bookmarked it on my ubuntu partition
<acesofsky> hi
<acesofsky> do you know the offcial forum for ubuntu arm support
<GrueMaster> Try #ubuntu-arm.  Oh, wait...
<GrueMaster> :P
<GrueMaster> What can we help you with?
<austeregrim> So kind of generic question.. would an ubuntu image just replace my android system partition?
<austeregrim> or are we looking at modifying partitions for space?
<GrueMaster> What is the platform?  We currently are only supporting TI dev platforms (beagle, beagleXM, panda), although there has been work in the community for other platforms.
<austeregrim> I've got a Toshiba Thrive... it's been on my mind
<austeregrim> and unfortunately not close enough to the other Toshiba Android device for me to say it'd be a simple push...
<GrueMaster> Unfortunately, it is not a platform that is currently being worked with, but someone in the community may have something based on ubuntu.  I know there is a community behind the Toshiba AC100, which uses the same basic core hw.
<GrueMaster> I don't know if there is an active community yet for that system.
<austeregrim> the AC100 doesn't seem close enough to the Thrive for me to think the Hw is compatible.
<GrueMaster> They are both nVidia Tegra2 dual core Arm Cortex A9.  That in of itsself is a major step in the right direction.
<austeregrim> I'm just trying to wrap my mind around how it would be booted, first of all... there is about 600mb of space in the System Partition to use
<austeregrim> actually there may be more.
<austeregrim> 688M according to df
<GrueMaster> What about other partitions?
<infinity> We tend to repartition our ac100s a bit.
<austeregrim> data - 2g, cache - 1007M
<GrueMaster> I believe the ac100 image uses a larger partition, like the user partition.
<infinity> Though you can dual-boot android and Ubuntu if you feel the strange desire.  It's just irksome.
<GrueMaster> Ah.
<austeregrim> storage - 9G
<infinity> (When we dual-boot, we just take over that storage partition)
<infinity> When not, we reparition and turn system+data+cache+storage into one nice large one.
<austeregrim> hmm
<austeregrim> can't partition the thrive, we only have fastboot
<infinity> We only have fastboot on the ac100 too.
<infinity> Not sure how that relates. :P
<austeregrim> thats when it gets scary for me I guess. lol
<infinity> I'm willing to bet that the Thrive is pretty much just "an ac100 without a keyboard".
<infinity> I'd put pretty good money on it, even.
<infinity> But without touching one, it's hard to know for sure. :/
<austeregrim> I've looked at the hardware, too many other differences.
<infinity> Care to come visit? :)
<austeregrim> visit where?
<infinity> Calgary, AB.
<austeregrim> Too far
<austeregrim> although I could probably give simple access to a shell, as close to touching one I can give.
<austeregrim> unless you're willing to come to California ;-)
<infinity> Well, I'll be in Santa Rosa in early September. :P
<austeregrim> 7 hour drive to there
<austeregrim> what are you doing up there?
<infinity> Linux Plumbers.
<austeregrim> I just wonder why it isn't as simple as pushing a new system partition to get a different linux distro booted on these arm devices.. or could it be? and it's just not ready yet?
<austeregrim> I mean I understand the requirements that the kernel needs to know what it's on, etc.
<GrueMaster> Part of the problem is the vendor.  Some (most) vendors don't want you mucking with their default OS (Windows 7, Android, OSX, etc).
<GrueMaster> So they don't make it easy for you to do so.
<austeregrim> Tablets though have seemed to be fairly easy to root, and like the thrive, fastboot isn't locked.
<GrueMaster> Try to get factory warranty service on a system that originally sold with Windows 7 that you have installed Ubuntu on.
<Lopi> what fs type is http://cdimage.ubuntu.com/releases/11.04/release/ubuntu-11.04-preinstalled-headless-armel+omap.img.gz
<GrueMaster> That may be true, but have they posted specs on how to get the HW to work in the kernel?
<austeregrim> no... lol... of course not
<GrueMaster> Lopi: The file is an image of an SD card with a fat32 partition and an ext3 partition.
<Lopi> GrueMaster: how can I mount it?
<GrueMaster> If you want to mount the fs with -o loop, there is a bit of a process to do it.  First, use gunzip to uncompress it.
<Lopi> yeah I did that
<GrueMaster> Then type "file ubuntu-11.04-preinstalled-headless-armel+omap.img" to find out the partition locations.
<Lopi> okay
<GrueMaster> To mount a partition, type "sudo mount ubuntu-11.04-preinstalled-headless-armel+omap.img /mnt -o loop,offset=$((512*<partition start point>)).
<GrueMaster> Give me a sec and I can give you an exact example.
<Lopi> will this cause any issues if I'm using emulated filesystems?
<GrueMaster> Huh?
<GrueMaster> I'm assuming you are doing this on a Linux desktop system.
<GrueMaster> (i.e. Ubuntu Desktop).
<Lopi> yeah I am
<Lopi> what I'm asking is
<Lopi> can I get rid of these partitions and create a new image with this image
<Lopi> on my device, the ramdisk mounts the nand then mounts a loopback image to create an emulated fs
<GrueMaster> Yes, but it is not easy.
<Lopi> then pivot roots, etc.
<GrueMaster> So, back to the mount process, on my system "sudo mount ubuntu-11.04-preinstalled-headless-armel+omap.img mnt -o loop,offset=$((512*144585))" will mount the second partition.
<Lopi> I see
<GrueMaster> But I think what you would want to do is beyond the scope of the preinstalled images.
<Lopi> can I generate my own natty rootfs with rootstock?
<GrueMaster> Part of the boot process of these images is to resize the ext3 partition to fill the SD card being used, from 4G to 32G.
<Lopi> ah
<GrueMaster> It also runs oem-config to customize the image to the user.
<Lopi> yeah that would be a problem :/
<Lopi> lilstevie was telling me about this
<GrueMaster> You might have a better time taking our new Ubuntu-Core image and expanding on it.  It is smaller than the headless image by quite a bit, but is usefull to start with as a chroot environment.
<Lopi> hm okay
<infinity> Someone needs to remind me to purge rootstock with fire for the next cycle.
<Lopi> where can I get ubuntu-core
<GrueMaster> You also can't boot directly to it as there is no kernel, but you can boot a kernel and have it mount a filesystem with ubuntu-core as /
<infinity> I'll need a spec to make sure that whatever functionality it has lives sanely elsewhere.
<GrueMaster> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/
<infinity> (And don't download "current", it's not actually current... But the dated directories are)
<Lopi> btw, this is for Ubuntu on the iPad
<infinity> (This will be fixed tomorrow :P)
<Lopi> you can see the linux kernel "booting" on it here: http://yfrog.com/hsu4bigj
<GrueMaster> Lopi: Then ubuntu-core is probably your best starting point.
<Lopi> GrueMaster: thanks for the help
<GrueMaster> Nice
<Lopi> it's going to be awhile before I have interaction with the image, but I figured I might as well get it booting now ;p
#ubuntu-arm 2011-08-26
<temp> Hello, does somebody know how to boot with tv output with a beagleboard and 11.04 image?
<twb> So <coworker> was burgled last night, and suddenly I'm raising the priority of doing whole-disk encryption on my new netbook.
<twb> lilstevie: am I likely to encounter any problems doing whole-disk LUKS encryption of Debian/Ubuntu on the eMMC of a TF101?
<twb> (I nearly bought one yesterday, but I decided to wait a month until the 3G model comes out, so I don't actually have one to test yet.)
<lilstevie> 3G one won't be able to do this stuff to just FYI
<lilstevie> and whole disk encryption would have some issues
<twb> eI'm assuming the 3G one will be identical except for having a 3G device jumpered to a USB or PCIE header
<twb> Hmm, no mention of hardware AES acceleration for the Tegra 250 T20
<lilstevie> 3G one will feature the new Secure Boot key
<lilstevie> and yes, the AP20 most certainly has an AES accelerator
<twb> Fuck (re secure boot); yay (re AP20)
<twb> I said T20 not AP20 based on https://secure.wikimedia.org/wikipedia/en/wiki/Tegra_2
<lilstevie> eh, they are very similar
<twb> Nod
<lilstevie> in any case, SBK is handled by the AES accelerator
<twb> SBK = Secure Boot Key?
<lilstevie> yeah
<twb> And because TF101G has SBK, I wouldn't be able to reflash it with Debian?
<lilstevie> well all tf101's have an SBK set
<lilstevie> just last time the SBK leaked
<lilstevie> and ASUS cracked it and all newer devices starting with B7O series devices (random assortment of them) have the new SBK
<lilstevie> given that the tf101g's have been manafactured since the changeover happened
<twb> Ah, OK
<twb> So should I wait and get a TF101G, and hope that someone leaks the SBK key quickly, or should I just get a TF101 and a 3G dongle?
<lilstevie> well the SBK /may/ have already leaked ;)
 * twb reads http://androidroot.mobi/technical/tf-secure-boot-key/
 * Martyn has just about gotten the hp touchsmart to run arbitrary code
<Martyn> they aren't using trustzone, thank goodness
<lilstevie> Martyn: :)
<Martyn> still a long, long, long way from getting u-boot or any arbitrary bootloader on there
<Martyn> but I can crash WebOS, and that's a start
 * twb wishes there was enough consumer demand to make handsets fungible, like peecees
<Martyn> supposedly there are some units that shipped with Android, according to Gizmodo
<Martyn> no details available though (and they are running froyo)
<lilstevie> Martyn: yeah I heard about that
<Martyn> My big issue, right now, is chasing down the IO slowdown issue with cortex A9 SMP
<Martyn> right now, I'm worried the problem lies in the SCU
<Martyn> so I'm trying to get a kernel where the SCU is disabled but still SMP
<Martyn> and getting ftrace and oprofile working on STmicro
<Martyn> IT's really bugging me that disk IO, usb IO, emmc IO are all affected by the bug
<Martyn> and this is a pretty serious bug ..
<julumme> hi guys, I'm trying to compile lirc on beagleboard, but the make will complain about genksyms:  scripts/genksyms/genksyms: 1: Syntax error: "(" unexpected
<julumme> file genksyms says: genksyms: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped
<julumme> should it be for armel ?
<julumme> I have successfully compiled the kernel from those sources (cross compiled, though)
<julumme> after compiling, I copied those sources also over to ubuntu that is running on beagle
<Guest68784> can anyone help me in arm9 in a custom board on a custom platform
<Guest68784> ??
<ogra_> beyond thatr fact that we dont support such old arches with ubuntu, you could just tra to ask, probably someone can help
<ogra_> *try
<temp> Hello, How can I boot with the tv out as main output with a beagleboard?
<jo-erlend> Oneiric comes with a server edition for ARM, right? I thought perhaps I could use my IGEPv2 (OMAP3) as a mikroserver. Will I still have to install the Linaro kernel and what kind of other obstacles should I be prepared for?
<jo-erlend> It's been a couple of years since I played with that card, I think. It's a waste. I'd like to use it for _something_ :)
<temp> Hello, how can I boot a beagleboard with tv out as my main display?
#ubuntu-arm 2011-08-27
<Lopi> can someone point me to documentation detailing how to generate an arm initrd?
<jraynes> Hi all. trying to load ubuntu on my Beagleboard xM and I'm having a little trouble.  I downloaded ubuntu-11.04-preinstalled-netbook-armel+omap4.img.gz, unzipped it with 7-zip and copied the raw image over to my SD card with win32diskimager. When I put the SD Card in my Beagleboard and turn it on I don't get any video or serial at all. Any ideas as to what I'm doing wrong here?
<infinity> jraynes: The Beagleboard is omap3, not omap4 (so, use the "omap" image)
<jraynes> Downloading now.. thanks.
#ubuntu-arm 2011-08-28
<dcordes> rsalveti: I just found your lp bug with the fix for thumb2 crash on webm content
<dcordes> rsalveti: been looking for a solution to this for a while
<dcordes> rsalveti: I am wondering if we can make it available in the natty updates
<dcordes> rsalveti: I know many ppl who run natty on ARM tablets etc. and it would be nice to get webm on all these images floating around on the net
<bkerensa> GrueMaster: Hi
<bkerensa> :D
<jo-erlend> I'm downloading 10.04 Netbook live image since it says it's for OMAP3 devices and I have an IGEPv2 OMAP3. But how do I use it? Can I just dd it onto the memory card and boot?
<jo-erlend> and if so... Is there an image for oneiric as well?
<GrueMaster> jo-erlend: You would be better off with the 11.04 image as the omap3 kernel there covers more hw.  The 10.04 was a tech preview only for Beagle.
<jo-erlend> oh, ok... I think I remember that, now that you mention it.
<jo-erlend> I'd really prefer oneiric, if there is an image for it?
<GrueMaster> And yes, dd is how you write to an SD.  Instructions are at http://wiki.ubuntu.com/ARM
<jo-erlend> I can't find an image for 11.04 either. That's why I started to download 10.04.
<GrueMaster> The last released image for Oneiric was Alpha 3, but Beta 1 release testing begins tomorrow with release on Thursday.
<jo-erlend> there's no daily image?
<GrueMaster> It is now under http://cdimage.ubuntu.com/daily-preinstalled.  It more closely matches the x86 desktop, so we dropped the netbook name.
<jo-erlend> ah.
<jo-erlend> I suppose upgrading from a3 to b1 will take quite some time on an OMAP3?
<GrueMaster> Possibly.  But if you grab the daily-preinstalled/current, it won't be as bad.
<jo-erlend> where can I find that?
<jo-erlend> ah.. :)
<jo-erlend> I found it. :)
<jo-erlend> will I still have to compile a kernel, etc, or should it just work?
<GrueMaster> I have to run.  It's my day off, so massive yard work is commencing.  Need to get a load of gravel before they close.
<GrueMaster> I don't know how much support for iegp2 you can expect.
<jo-erlend> oh... Have fun and thanks for helping :)
<jo-erlend> GrueMaster, I'll let you know then :)
<GrueMaster> Good luck.
<jo-erlend> thanks. :)
<jo-erlend> now I remember. The IGEPv2 doesn't boot from boot.scr. I think it uses some kind of ini-file.
<infinity> jo-erlend: Assuming our uBoot and xLoader work on igepv2, you might just be able to cp boot.scr boot.ini and be done.
<infinity> jo-erlend: If not, you might been the uBoot and xLoader from here, and have to re-create the boot image: http://labs.igep.es/index.php/How_to_get_the_Ubuntu_distribution
<jo-erlend> infinity, it's only for 10.10 though.
<infinity> Those old bootloaders would still work with our newer kernels.  But, there's a fair chance our current bootloaders might Just Work anyway, if you rename boot.scr.
<infinity> I can't say for sure, since I've never had a chance to play with an IGEPv2 board.
<jo-erlend> infinity, I had a brief look at the boot.scr file from the Ubuntu image. It seems to be configured for a resolution my monitor doesn't support. How do I change it?
<infinity> jo-erlend: Is it using omapfb.mode=dvi:?? notation?
<jo-erlend> infinity, I think so. I don't really know what that means.
<jo-erlend> that's what it looks like in the boot.scr file.
<infinity> If so, something like omapfb.mode=dvi:1024x768MR-16@60 might work on your older monitor.
<jo-erlend> yes, but how do I make that into a valid boot.ini file?
<infinity> Just copy boot.scr to boot.ini, and edit the command line.
<jo-erlend> what command line? I have no screen.
<infinity> boot.ini is the same format as boot.scr, just a different filename to be difficult. :P
<infinity> Err.  I mean, edit the kernel command line in boot.ini.
<infinity> Surely, you're doing this on another computer.
<infinity> One with a monitor. :)
<jo-erlend> yes. But is it just a text file?
<infinity> Yes.
<infinity> Well, ish.  Some implementations have a whacky hex header.
<infinity> But if you edit in something like vim, it will happily just leave that alone.
<jo-erlend> it can't be opened in gedit.
<jo-erlend> oh, ok.
 * infinity wanders off to have a Sunday.
<infinity> Good luck. :)
<jo-erlend> :)
<jo-erlend> doesn't seem to want to boot.
<jo-erlend> perhaps I'll just have to use 10.10 and then upgrade and upgrade and upgrade :)
<jo-erlend> I don't understand why they don't just make an image and make it available.
<jo-erlend> the last time I wanted to boot that thing, I spent a week getting it to start.
<jo-erlend> is it normal for these kinds of ARM boards to require so much labor in order to boot?
<jo-erlend> heh.. I mean.. Installing Ubuntu on my laptop takes about 15 minutes. Installing it on ARM takes about 15 days. :)
#ubuntu-arm 2012-08-20
<infinity> janimo: Ooo, shiny, a 3.5.0 armadaxp kernel?
<infinity> janimo: Any reason that went to the PPA instead of the archive?
<infinity> janimo: And a followup question to the above, did you want that copied to the archive?
<hrw> ogra_: aptitude merge was done long time ago. during weekend it was review/sponsored/uploaded
<Rasperin> Hey guys, I'm trying to get video playback with my pandaboard ES, I heard this was a better platform then the old pandaboards but every OS I install on it has serious performance issues.
<Rasperin> Is there a way to squeak better performance out of this? I've tried Linaro Ubuntu and Android, I'm switching to a usb 2.0 boot harddrive
<Rasperin> but it looks like the software not the hardware is rendering 3d, I know people got smooth playback with the old pandaboard and linaro, is there a way to get the graphics drivers from TI or anything like that?
<xranby> rsalveti: first great screenshots of 3d working nice on the pandaboard..
<xranby> encouragins to see
<xranby> well i tested to boot up my own pandaboard and installed the latest drivers offered by "jokey" .. something installed but it did not get connected all the way to silicon http://paste.ubuntu.com/1156993/
<xranby> running quantal
<ogra_> forget quantal until the new drivers are uploaded
<xranby> ogra_: ok well cant help it.. i have to try it before its stable.. will try the 3.5 kernel and use the precise drivers     in hope to see http://lockerz.com/s/236484513
<xranby> :)
<RoyK> xranby: where?
<xranby> RoyK:  (17:17:33) robclark: this omap ppa for precise plus this kernel works fine w/ unity3d: http://people.freedesktop.org/~robclark/try9
<lilstevie> if only nvidia would provide us with a nice working driver :(
<ogra_> xranby, i'd rather use rsalveti's packageds than the precise ones ;)
<ogra_> i guess there is a PPA somewhere
<RoyK> xranby: thanks - gotta try that when I get back home :)
<xranby> ogra_: i hope so. i was hoping rsalveti would say.. hey use my secret ppa at location X)
<ogra_> xranby, well, patience will help too, it has to be uploaded this week (feature freeze coming)
<xranby> RoyK: good luck
<RoyK> thanks
<RoyK> xranby: should this work with precise, or should I upgrade to quantal?
<xranby> RoyK: honesly i do not know
<xranby> i have not tested it yet
<ogra_> the shots are from the quantal development drivers ... they arent uploaded yet
<ogra_> but will ... during the week
<xranby> RoyK: to get the nice result shown in rsalveti screen shots ogra_'s advice is the best.. be patient and wait for the upload
<xranby> to get something working today with a high chance of breaking things use the link i posted
<RoyK> :)
<xranby> ogra_: the "unaccelerated" experience on the omap4 is amazinly snappy in quantal.. running the lubuntu desktop and it flies
<xranby> great progress
<ogra_> yeah, same on the ac100 :)
<ogra_> the accelerated expirience with unity running isnt so great i heard though
<xranby> if i only can get away from my opengl es addiction ;)
<ogra_> i.e. massively limits your video playback framerate to have compositing on
<xranby> ogra_: how is it imagined to get solved?
<xranby> can unity get re-engineered to fix this limitation?
<xranby> for example is someone working on temporally disable composition if openmax is running
<xranby> ?
<ogra_> no idea, i was even surprised by the llvmpipe as default switch ...
<ogra_> i guess you have to ask the unity guys
<xranby> lovely, have you send them a pandaboard?
<xranby> to test their work on?
<ogra_> i think they have one ... but that wont help ... upstream llvmpipe isnt ready on arm afaik
<ogra_> i fear panda will have to use swrast (and fail with that)
<xranby> i will install the package and check, by running some 3d fluff to see if it is working on the panda
<xranby> its only a libGL replacement after all
<ogra_> the grand plan is to ship pvr by default though
<xranby> this is plan B
<xranby> if all else fail
<xranby> of course getting the accelerated bits in would be great
<ogra_> well, plan B wuold be more intresting on all the other arm images we have
<azert> hello there
<ogra_> plan A has to happen in any case for the panda
<azert> anyone own beagleboard ?
<xranby> the nice thing about llvm-pipe is ofcourse that it supports all desktop GL applications
<ogra_> but only runs on SSE currently
<xranby> i imagine that the accelerated bits only supports opengl es
<xranby> ogra_: you are correct as allways. its only using the traditional old and slow mesa sw rasterizer
<ogra_> well, i was just guessing :)
<xranby> nice guessed then!
<janimo> infinity, I wanted to make 100% sure it builds in the archives not only on my machine. And then I'd want it copied sure, but no meta yet so others can test too
<janimo> infinity, this is a code-drop from Marvell, my attempt at forward porting the 3.2 patches did resulted in a kernel that hangs while calling init
<janimo> did result
<rsalveti> xranby: hopefully we should have the packages at a ppa today
<rsalveti> there's a fix  at the kernel package that needs to land as well, bug 1038846
<ubot2`> Launchpad bug 1038846 in linux-ti-omap4 "linux-headers pkg for omap4 doesn't include omap_drv/drm headers" [High,In progress] https://launchpad.net/bugs/1038846
<rsalveti> ppisati: ^
<ppisati> rsalveti: i fwded to the ukml, but it's in master next
<ppisati> rsalveti: i'll cut a new relase with what we have now + that fix
<rsalveti> great, already got applied at master-next
<rsalveti> ppisati: awesome, thanks!
<rsalveti> just because without it we can't install the pvr-omap4 package
<xranby> rsalveti: ok, thumbs up, thank you for processing all the bits and packages through the grinder
<xranby> rsalveti: have the drivers been tested on both old and new pandaboards?
<xranby> i got a rev A here (assuming its the old panda)
<xranby> A1
<rsalveti> xranby: yup
<ppisati> rsalveti: does pvr-omap4 need anything else to work properly with 3.5?
<rsalveti> ppisati: not at this point, it worked just fine with 3.5
<rsalveti> unfortunately I got 2 freezes while testing, similar to what I was having with 3.4
<rsalveti> not sgx specific
<rsalveti> didn't get any logs at the serial, just stopped completely, without blinking leds
<rsalveti> that's with a panda es
<sveinse> plymouth is rather married into the bootup process, right? I tried to remove it but mountall depends on it. Does it do anything except provide splash? What should I do if I don't want any of that at all?
<xnox> sveinse: it prints *all* of the login text as well....
<xnox> s/login/boot/
<sveinse> xnox: ok.. I added console= to my serial port and I think I got all of the boot output (fsck and such). It's plymouth that does that?
<xnox> sveinse: i am not sure. but my experience was that, that is the case
<sveinse> Point is: I have plymouth installed, but no themes. Now initramfs does not contain plymouth binaries, just some init-top and init-bottom scripts which complain upon boot.
<sveinse> I'm tempted to not use plymouth at all since I have all the output I want, yet for some reason mountall depends on plymouth, so some connection/requirement must there be
<sveinse> ah, it's a requirement to mountall because mountall pass progress to the plymouth daemon
<ogra_> sveinse, imagine libplymouth as a poor mans dbus :)
<sveinse> yep.
<ogra_> it lives between the UI and the backend, so mountall is heavily tied into it for any kind of user communication
<xnox> ogra_: i'd rather imagine btrfs giving me a pony
<ogra_> haha
<lilstevie> lol
<sveinse> It seems its not in ubuntu's use cases to not have any plymouth themes installed, since its complains without one
<sveinse> Having no plymouth theme installed, will result in having no plymouth[d] installed in initramfs, yet they are referred to by the init-top and init-bottom plymouth scripts :P
<ogra_> the init-top and init-bottom scripts are parts of the plymouth package, they are gone if the package is gone
<ogra_> and plymouth should force a rebuild of the initrd from its postinst
<sveinse> no, you can't rid yourself of plymouth. Its a dep of mountall. So you have it either way. However if you don't have any themes installed, no ply bin end up in the initramfs, but their init-* script does
<sveinse> in all cases, plymouth does not bother me. point is. Is there a theme I should use if I want text/serial output only. No hazzle dazzle.
<sveinse> (I'm optimizing a product for faster bootups...)
<lilstevie> I wish I could get it to display the splash :p
<lilstevie> I have to press the down or up arrow for it to appear :/
<sveinse> Well, we did write a simple plymouth theme showing a simple splash (no progress & stuff). and it works. However, plymouth assumes that the text console and the splash device are the same, so for embedded products where you want everything on the serial port, while keeping the screen with a splash, it not easy with plymouth AFAIK.
<sveinse> Are there any tools for recording the timestamps during boot. I want to see what the system is spending time on while booting.
<lilstevie> sveinse, dmesg shows time since boot
<lilstevie> or well time since kernel start
<ogra_> and there is indeed bootchart ...
<stgraber> sveinse: you may want to look at bootchart
<sveinse> lilstevie: Well, dmesg only shows kernel events. Theres a 20 second delay between the last kernel message during boot and our application start
<stgraber> oh well, ogra_ was faster ;)
<ogra_> heh
<sveinse> bootchart, thanks both of you. I'll look at it
<sveinse> I'm asking to make sure: Is there any way to get plymouth to log to a serial console, while displaying a splash on the fb?
<ogra_> no
<ogra_> plymouth will not allow a splash as soon as console= is set
<ogra_> (silly upstream decision)
 * xnox wants dual screen support for plymouth: splash on the left, console messages on the right.
 * ogra_ wants two splashes ... 
<ogra_> i got a triple screen setup ;)
<infinity> janimo: Is this Marvell code drop audited and all the non-free stuff removed?  I spent a lot of time license checking and removing junk from the old source.
<janimo> infinity, they say so, and that the code can be published
<ogra_> heh
<janimo> I pushed it onto zinc anyway
<jocarter> I want a splash screen on one screen, logs in the middle, and a youtube video of cats on the 3rd one
<infinity> janimo: Their last code drop could be published, that didn't make it Free (and it wasn't).
<janimo>  what's worst that can happen?
<infinity> janimo: The worst that happens is that we lie to people and give them things they can't modify or redistribute legally. :P
<janimo> well, if someone notices we can fix whatever is wrong :)
<ogra_> Aug 20 17:12:35 ubuntu acpid: 1 rule loaded
<ogra_> Aug 20 17:12:35 ubuntu acpid: waiting for events: event logging is off
 * ogra_ glares at his beagleboard
<janimo> it's not like we reveal secrets or offer non-free but irreplacable code
<janimo> small mistakes at worst imo :)
 * sveinse wants splash on screen with console on serial port
<lilstevie> ogra_, wait... console= means no splash? so then on tegra we are screwed
<ogra_> lilstevie, my saying :)
<lilstevie> with that stupid bug where it dies unless we set it
<ogra_> since months
<lilstevie> :/
<ogra_> not much we can do though
<janimo> lilstevie, nvidia is supposed to be working on that bug already
<lilstevie> janimo, yeah yeah, we'll see :p
<sveinse> lilstevie: Yes it's like that. You get console though since getty runs. But you lose console output between kernel handing off to initramfs and until getty is run if you enable splash
<infinity> janimo: Hrm?  No, no secrets, but there's plenty of "all rights reversed" code in their code drops with no license.  Even if they hand-wave and tell us we can distribute it (which their engineering department really can't tell us anyway), third parties definitely can't.
<infinity> janimo: This isn't the sort of thing we should do the "well, we'll just ship it and wait for them to whine" thing with.  We put serious effort into cleansing that tree for 3.2, for good reason.
<janimo> afaik the talks were among sales/whatever departments too or at least not just engineers
<janimo> infinity, I had no idea 3.2 was assumed clean by them but cleansing was needed
<GrueMaster> With Marvel, never assume anything.
<lilstevie> wait
<lilstevie> holy
<lilstevie> apparently that bug is fixed for tegra3 already :p
<sveinse> Tegra 2 does not have NEON, right. So no armhf? What about newer tegras?
<ogra_> ??
<ogra_> why would there be no armhf ?
<sveinse> no float ops implemented in HW... I might well be misinformed. I though NEON and FPU was part of the same deal
<ogra_> no
<lilstevie> it is a pain to not have NEON but NEON and FPU are not mutually exclusive
<sveinse> right. And FPU is generally implemented across the >=ARMv7 devices today?
<lilstevie> is a requirement of armv7 AFAIK
<sveinse> aha (while reading http://wiki.debian.org/ArmHardFloatPort/). ARM implements a VFP which is the FPU. And it poses an extra set of registers -- which is the same reason the EABI is different
<sveinse> But from what I understand, the kernel is agnostic to armel/armhf, right? The VFP is never used for passing arguments to/from kernel?
<infinity> sveinse: Right.
<sveinse> excellent. That might help a lot... You see. If mgmt decides they want armhf in the next release, I need to figure out how to dist-upgrade armel -> armhf...
<ogra_> LOL !
<ogra_> now you made my day
<sveinse> (It's always interesting to be the center point for laughing. Especially when you don't know why....)
<lilstevie> dist-upgrade does not sound fun at all
<lilstevie> like potentially broken.... everywhere
<ogra_> well, currently the distro doesnt support that path withoutu tinkering a lot on the low level
<sveinse> I think I'll have to construct some chroot jail with armel and let it stage the upgrade the main system
<infinity> It's not something we support, period.  It's something you can make work in a very controlled environment, but you're not going to upgrading customer machines blind.
<sveinse> No, I dont expect you to either
<lilstevie> speaking of crossing armel/armhf, still haven't found a reason worth setting up multiarch
<lilstevie> :p
<infinity> Let me put it differently.  It's not something YOU will be able to support any more than we can.  Unless your machines are all a specific image with no extra packages.  And if they are, you can just re-image them armhf. :P
<lilstevie> ok hud is starting to annoy me :/
<jcrigby> ogra_, I need some assistance, it would be nice to get linaro-boot-utils pushed to quantal before ff
<ogra_> lilstevie, shout at it ... that surely helps *g*
<jocarter> ooh, it has voice recognition already?
<ogra_> jcrigby, where is it ?
<jcrigby> it is only in a ppa now,
<ogra_> jocarter, only shout recognition yet :)
<jcrigby> https://code.launchpad.net/~jcrigby/+recipe/linaro-boot-utils-daily
<sveinse> is it possible to multiarch armel/armhf? I though the nature of the incompatabilities between the EABIs made them unable to multiarch
<lilstevie> ogra_, I have had several cases where I am working away nicely in my terminal, accidentally trigger hud, and all of a sudden my sudo password has ended up in xchat :(
<jocarter> ogra_: heh
<infinity> sveinse: We can multiarch them, yes.
<infinity> sveinse: We put a lot of effort into that.
<ogra_> lilstevie, do you use focus-follows-mouse ?
<infinity> sveinse: (And ABI incompatibility is the use-case for multiarch... i386 and amd64 are incompatible ABIs too...)
<sveinse> infinity: right
<lilstevie> ogra_, that shouldn't make a difference right? I run my terminal windows at full screen
<ogra_> lilstevie, it makes a massive difference, unity isnt ready for FFM
<infinity> lilstevie: Just re-bind the HUD hotkey to something you never press (mine is "pause"), and your life will be much better.
<sveinse> infinity: Am I understanding that armel->armhf is not possible at all? (If not, I can save me the attempt)
<infinity> sveinse: Multiarch cross-grading isn't something that's "possible" on more than a macihne-by-machine with insane amounts of effort and breakage basis.
<infinity> sveinse: So, for someone who's wanting to attempt it to more than "their personal laptop that they're happy breaking", I'd call it impossible, yes.
<lilstevie> ogra_, in any case I haven't changed the setting from default, I was considering it though, but if it will make it worse :p
<ogra_> jcrigby, so are the source packages on https://code.launchpad.net/~linaro-maintainers/+archive/kernel/+packages in a state you want to have them released in ?
<lilstevie> infinity, sounds like a good idea, while I like the idea of hud, I still haven't really used it
<ogra_> jcrigby, signing and uploading them only takes me a few :)
<infinity> lilstevie: If I still did a lot of graphic arts things, I could see it maybe being useful.  Or if I did office productivity type things.  But if you don't use complex applications with thousands of menu entries, the novelty wears off pretty quickly.  And the bugs become the only part that you notice. :P
<lilstevie> infinity, I live in the command line
<lilstevie> so yeah
<lilstevie> not really much use
 * ogra_ really doesnt get that acpid thing in his beagle boot 
<ogra_> i mean, i dont mind that we have it installed, by why the heck does it start ?!
<jcrigby> ogra_, I believe so except for the funky version string
<ogra_> jcrigby, yeah, looks a bit like a math exercise :)
<lilstevie> anyway, I'm turning in for the night
<lilstevie> later
<ogra_> so pick a nicer version, put the source package somewhere and i'll upload
<jcrigby> ogra_, ok thanks
<sveinse> infinity: Thanks.  You'll have to excuse me for challenging armel->armhf upgrade feasability. I'm trying to measure the degree of "impossibleness". Not trivial is not the same as impossible. (A couple of years ago we were told cross building of armel deb package was impossible, but that turned out to be just non-trivial, but implementable.)
<infinity> sveinse: Oh, yeah, no.  This is way beyond "not trivial" for anything other than a single system.  And the single system is something that would need excessive babysitting.
<ogra_> you could write a babysitter ;)
<sveinse> Well, in our case, if you babysit one, then you've handled all. All installed systems are *exactly* the same in respect of package composition
<infinity> ogra_: You really couldn't.
<infinity> ogra_: That's why it's not feasible.
<infinity> sveinse: If they're identical, re-image.  Seriously.  You'll hate yourself less.
<infinity> sveinse: Heck, that's a truism for dist-upgrading when not cross-grading too. :P
<sveinse> infinity: This is an embedded device with no alternative boot. The only bootsource available is the sd-card (which we don't want customers to fiddle with). That's why I trying to hot-upgrade a running system
<sveinse> For the fun of it: Here's how I hoped it would work: 1) deboostrap armel into a dir  2) chroot into jail. Bind mount system drive. Run debootstrap armhf over armel installation (which "resets" the list of installed packages). 3) reboot  4) finish install and install the set of packages needed on the system
<sveinse> I have to leave. _ogra, infinity. Have a nice evening (or whatever TZ you're in)
<ogra_> samei guess :)
<GrueMaster> One way to handle the switch from armel to armhf is through a two-step reboot.  I'd have to diagram it out, then script it, but it is possible.  For an embedded system, it is a bit tricky, but that is what test environments are for.
<GrueMaster> And it also depends on how the embedded system is layed out to begin with.
<GrueMaster> Actually, I wonder if it could be done with netboot d-i & preseed?
 * GrueMaster wishes he had free time to experiment with this idea.
<jcrigby> ogra_, http://people.canonical.com/~jcrigby/linaro-boot-utils/
<ogra_> bah, sigh
<ogra_> since when does dpkg-buildpackage fail hard on a missing ubuntu maintainer address
<ogra_> how silly
<infinity> ogra_: Since forever.
<infinity> ogra_: But it depends on if you have DEB_EMAIL set.
<infinity> ogra_: Which is a weird heuristic.
<ogra_> infinity, no, im sure it never killed the build
<infinity> ogra_: It's done this for ages.
<ogra_> it was a warning
<infinity> (And I actually quite appreciate it)
 * ogra_ doesnt 
<infinity> ogra_: No, really, it's hard failed like this for quite a long time.  Unless you've been building all your source packages on an ancient release for the last few years.
<ogra_> i like to maintain the packages i'm upstream for in ubuntu ...
<ogra_> now, i'm in the lucky position to have an ubuntu.com address ... others arent
<infinity> I maintain my Debian packages in Ubuntu too.  That's not a problem, unless you try to upload something with an ubuntu revision but no ubuntu maintainer.
<ogra_> well, it breaks for sponsored linaro uploads
<infinity> It doesn't "break" at all, it's working as intended.
<infinity> Just run update-maintainer(1) and be done with it.
<ogra_> jcrigby, adding a watch file would be nice, the standards version is one behind and apparently you need to run update-maintainer as infinity suggests above
<jcrigby> ogra_, just catching up, my xchat lost connection just after I sent link
<ogra_> yeap, saw that
<jcrigby> ogra_, I fixed the standards version and maintainer.  I did not add a watch file because after searching I'm still unsure how to do that part.  I pushed the result to http://people.canonical.com/~jcrigby/linaro-boot-utils/
#ubuntu-arm 2012-08-21
<cooloney> marvin24: hey, Marc, I'm looking at bug https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/746137
<ubot2`> Ubuntu bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released]
<cooloney> ogra_ told me you found some trick about changing GFP_KERNEL to GFP_ATOMIC will solve this issue
<marvin24> cooloney: the replacement is only possible in certain cases
<marvin24> in ours, the wifi driver needs some memory to receive messages
<cooloney> marvin24: ok, thanks,
<marvin24> because it is attached to the usb bus (which is slow), you can replace it
<cooloney> yeah, ogra_ said it is usb wifi driver, on pandaes it is usb ethernet driver
<marvin24> looking at the bug, it seems it is the usb host controller itself
<marvin24> you may try to replace it and see if it fails under stress test
<Chipaca> hi guys
<Chipaca> trying to run solr (from solr-jetty), am getting issues on ARM
<Chipaca> stupid things like it not picking up the config
<ogra_> filed a bug ?
<Chipaca> ogra_: trying to figure out what's going on, first :)
<Chipaca> it might, after all, be PICNIC
<kalem> ppisati: easycap driver is not in 3.4.0 ti-omap4 kernel. Is it ok ?
<kalem> ppisati: staging media easycap
<ppisati> kalem: actually i din't even know what this easycap was about
<ppisati> kalem: fill a bug
<kalem> ppisati: usb video capture
<ogra_> likely also good to have in omap3
<kalem> ad omap4
 * ppisati kicks another compilation...
<ogra_> ... like beckham
<ogra_> :P
<LetoThe2nd> oO( compile like victoria )
<kalem> ppisati: ok, submitted
<smplman> which Ubuntu release has audio / openGL support out of the box for the beagleboard XM?
<ogra_> smplman, none of them
<jcrigby> ogra_, is linaro-boot-utils ok for upload now?
<ogra_> jcrigby, should be in NEW since several hours already :)
<jcrigby> ogra_, ok thanks sorry for pestering my internet was out for 6 hours last night so I thought maybe I missed something
<ogra_> ah, no, dont worry :) you should have gotten a mail for the upload actually
<jcrigby> I though so, but I did not see it. Hmm....
<xnox> ogra_: does quantal server daily prebuild images boot on pandaboards?
<xnox> ogra_: are there 12.04.1 prebuild images?
 * xnox 's panda winking with one green led and that's it
<infinity> xnox: No 12.04.1 images, no.  What's wrong with using 12.04 and upgrading?
<infinity> xnox: (Or a netboot)
<xnox> infinity: the fact that I am unlucky booting it at all.
<xnox> infinity: netboot doesn't work for me either =(
<infinity> xnox: Then a different image won't help. :P
<xnox> thanks =)
<infinity> xnox: It's either a bad SD card, or it's making a bad connection, or you're writing the image incorrectly, or the board is just plain dead.
<infinity> xnox: I assume you have a serial cable for the thing, and you're seeing nothing on serial?
<xnox> infinity: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-core-armhf_default/
<xnox> nice and red
<xnox> nothing past:
<xnox> Starting kernel ...
<xnox> Uncompressing Linux... done, booting the kernel.
<infinity> Oh, that doesn't sound like there's a problem at all.
<infinity> Try a precise netboot.
<infinity> You could just be suffering console confusion or something.
<xnox> probably tty isn't starting where i am watching it.
#ubuntu-arm 2012-08-22
 * xnox should not have started reinstalling
<nigelr> ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
<nigelr> sorry
<nigelr> screen doing some weird stuff there.
<ppisati> ogra_: todays omap4 live are still 3.4 based, how do i check if they promoted to 3.5?
<ogra_> ppisati, look at the .manifest fiel for the image
<ogra_> *file
<ppisati> ogra_: you call it "seed" right? the thing that list all the packages that should be included in an image?
<ogra_> or for desktop it might be .list
<ogra_> the seed is the input for tasks and metapackages, yeah, it defines what goes where
<ogra_> but the .list and .manifest files show you what actually ended up in the image ;)
<ppisati> well
<ppisati> http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-armhf+omap4.manifest
<ppisati> shows me 3.4 since the live is 3.4 based
<ogra_> linux-image-3.4.0-204-omap4	3.4.0-204.9
<ogra_> The following packages have unmet dependencies:
<ogra_>  empathy : Depends: empathy-common (= 3.5.5-0ubuntu1) but 3.5.90-0ubuntu2 is to be installed
<ogra_> well, no image builds since two days
<ogra_> yesterdays failed on pythin-glib i think
<ppisati> for emapthy?
<ppisati> :(
<ogra_> todays on emptahy
<ogra_> try the server image ;)
<ppisati> where do you check these status?
 * ppisati is missing some ml... 
<ogra_> nah, they are hidden on people.ubuntu.com
<ogra_> i'm in the cdimage team, we get the logs mailed daily
<ogra_> one sec
<ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/
<ogra_> and http://people.canonical.com/~ubuntu-archive/livefs-build-logs
<ppisati> cool
<ogra_> todays is at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/quantal/ubuntu-omap4/20120822/livecd-20120822-armhf.out
<ppisati> the last one is the one i was looking for
<ppisati> ogra_: when does it run next?
<ogra_> ppisati, hmm, good question, the crontab on the build machine looks a bit weird
<ppisati> The following packages have unmet dependencies:
<ppisati>  gwibber : Depends: gwibber-service (= 3.5.2-0ubuntu1) but 3.5.3-0ubuntu1 is to be installed
<ppisati>  gwibber-service : Conflicts: libgwibber2 but 3.5.2-0ubuntu1 is to be installed
<ppisati>                    Breaks: libgwibber2 but 3.5.2-0ubuntu1 is to be installed
<ogra_> fun
<ppisati> ogra_: ^
<ogra_> say thanks to people that upload packagesets to the main archive instead of proposed
<ogra_> it should resolve itself after a while
<ppisati> yes, but i can't test my kernel in the archive
<ogra_> our kernel uses gwibber ?
<ppisati> no
<ogra_> (does it twitter dmesg lines ?)
<ppisati> but builders don't complete a build if $foobar is brokern
<ogra_> so just grab a workin server image then
<ppisati> i want the desktop image
<ogra_> and apt-get install the kernel
<ogra_> forget desktop
<ogra_> unusable atm
<ogra_> even if it would build
<ppisati> ah right
<ppisati> bah
 * ppisati dies in a corner
 * ogra_ does that since a week
<ogra_> welcome to the club
<ogra_> gwibber (3.5.3-0ubuntu2) quantal; urgency=low
<ogra_>   * debian/control:
<ogra_>     - add some missing internal package dependencies
<ogra_> ppisati, ^^^
<ogra_> uploaded 8 min ago
<rsalveti> ogra_: I'm now working on the remaining changes for pvr, should have the packages ready later today
<ogra_> \o/
<GrueMaster> What?  Arm daily images are broken?  Say it isn't so.
<ogra_> GrueMaster, nah, it isnt ... server always works :P
<GrueMaster> Pfft.  Of course it works, there's practically nothing there.
<ppisati> besides, where're the server images now?
<ppisati> https://wiki.ubuntu.com/ARM/Server/Install
<ogra_> where they always were
<ppisati> refers to P
<ogra_> cdimage.ubuntu.com/ubuntu/server/daily/
<ppisati> ah
<ogra_> err
<ogra_> ubuntu-server
<ppisati> Not Found
<ogra_> (sorry trying to get used to a new kbd here)
<ppisati> 404
<ogra_> http://cdimage.ubuntu.com/ubuntu-server/daily/
<ppisati> no ok
<ogra_> my daily omap3 autotest just finished ...
<ogra_> i would expect omap4 to be fine as well ... unless someone uploaded a kernel that doesnt work on servers :P
<ogra_> ppisati, dont forget to mount the first partition after dd'ing and copy preEnv.txt-serial over preEnv.txt
<ogra_> unless you want a framebuffer based install
<ppisati> if (am_i_on_a_server()) panic("thou shalt not server\n");
<ogra_> haha
<ogra_> dont let Daviey see that :)
<ppisati> ack
<GrueMaster> I wonder if u-boot could be made to detect if there is a monitor attached?  Something like "if EDID {console=fb} else {console=serial}" (simple logic).
<ogra_> not in hush shell script
<GrueMaster> Not that I do much with my pandas these days (except intercept calls from ET).
<ogra_> it already can drive the framebuffer
<ogra_> (see the beagle images that get this over-guly orange screen before loading the kernel)
<ogra_> the prob is that your u-boot.bin gets so big
<GrueMaster> I know it can drive the framebuffer, but it would be nice if it detected something on the other end.
<GrueMaster> So?  It is on SD.
<ogra_> to be loaded into ram
<ogra_> MLO needs to assign more space in that case etc etc
<GrueMaster> Doesn't it get booted out once the kernel boots?
<ogra_> yep
<infinity> Yeah, it's a question of how much RAM you have to play with before the kernel does anything to it.
<infinity> And mapping it sanely.
<GrueMaster> I'm not saying for u-boot to actually drive the FB, just detect if it is there.  Let the hush shell do simple scripting (which I know it already can do most of what I recommended).
<infinity> FSVO "sane".
<infinity> Which basically is just rough arithmetic and some luck.
<infinity> And I'm pretty sure you'd need the FB driver built-in to even hope to detect a display on the other end.
<infinity> But maybe not.
<ogra_> GrueMaster, its not the hush shell, you need to include the whole framebuffer stack to even provuide that device somewhere
<infinity> Seems like a bit of effort for just one subarch, though.
<infinity> (I agree that it would be nice to autodetect the console, mind you, I've brought it up before too)
 * ogra_ grumbles about that new kbd
<GrueMaster> Do you need the FB stack to do plug detection?
<ogra_> GrueMaster, yes
<ogra_> at least parts of it, you can probably cut it down if you dont want to display stuff
<GrueMaster> Hmm.  I would think a snippet of code in u-boot would be enough.
<ogra_> but thats really a lot effort for not much benefit
 * ogra_ thinks since we dropped boot.scr it got easy enough to edit 
<ogra_> i'll probably drop the preEnv.txt-serial too and just put the info on the wiki
<ogra_> (its not like its actually hard to add "console=ttyO2" to the end of a file that only contains one line
<ogra_> )
<xnox> ogra_: you'd be surprised =)
<ogra_> heh
<xnox> ogra_: help.ubuntu.com & wiki.ubuntu.com & askubuntu.com are full of duplicate one-liners....
<ogra_> hahaha, complain to the doc team :)
 * ogra_ didnt even know there are people asking arm questions on askubuntu
<ogra_> (and i wonder who answers them ?)
 * GrueMaster really wishes Unity would support rdp.
 * ogra_ really wishes unity would work on arm :P
<GrueMaster> Yea, that too.
<rsalveti> I don't think console autodetection should happen based on the monitor presence
<rsalveti> that's something that can be done, but then you'd need to boot the board with the monitor already plugged
<rsalveti> and even at my own use cases, that doesn't happen so frequently
<infinity> rsalveti: Based on monitor and keyboard presense is a clever way to do it for installers.  Not for installed systems.
<prpplague> anyone making it out to LPC/LCNA ?
<infinity> rsalveti: That's the trick generally pulled on other platforms.  Autodetect for the installer, trust the bootloader's set default after that.
<rsalveti> I'll be at plumbers
<infinity> prpplague: I'm plumbing.
<prpplague> infinity: ahh dandy
 * ogra_ would like to, but forgot to ask for compan coverage
<prpplague> infinity: come on by the TI booth if/when you have time
<ogra_> *company
<infinity> prpplague: Do you have presents?
<prpplague> infinity: just one at linuxcon
<ogra_> mouse mats with pandas on them :)
<rsalveti> infinity: I understand the use case, but I'm still not convinced that mouse+monitor should be a reference for automatically selecting the console here
<infinity> (Is LC co-located with LPC, I haven't really looked at the former)
<rsalveti> it'll depend a lot based on each soc again
<rsalveti> which can be a huge pain
<rsalveti> can't be something that the kernel/initrd would be able to detect?
<infinity> rsalveti: Eh.  It's as correct as any other guess for installer first-boot.
<rsalveti> once we're at the kernel side, it's a lot easier
<prpplague> infinity: http://lcna2012.sched.org/event/df97704300418c3eee409c7254c5160d#.UDURbWY6css
<rsalveti> prpplague: will you be at plumbers as well?
<rsalveti> oh, cool
<prpplague> rsalveti: yea
<prpplague> rsalveti: no presentation though
<ogra_> present yourself :)
<prpplague> hehe
<infinity> prpplague: Oh, you misunderstood, I asked if you had *presents*, not a presentation. ;)
<prpplague> infinity: ahh
<infinity> prpplague: As in, gifts, toys, incentive to come say hi. ;)
<rsalveti> :-)
<prpplague> infinity: nothing special at linuxcon/lpc
<GrueMaster> I'd go out for post-event beers, but it is in San Diego, not Portland.
<prpplague> infinity: i have some plans for some stuff at ELCE
<infinity> prpplague: Oh well.  Maybe I'll find the time to come be friendly anyway. :P
<ppisati> who is going to ELC in Barcelona?
<prpplague> infinity: i can't afford to give a bunch of stuff away at every conference, cuts in to my beer money
 * ppisati is going
<infinity> rsalveti: Bring a box of Linaro pens, we can take turns throwing them at prpplague.
<ogra_> ppisati, its such a bad timin :/
<ogra_> *timing
<ppisati> ogra_: why? right after uds
<ogra_> exactly :)
<rsalveti> infinity: yeah, I think I have a bunch around
<infinity> Right after UDS is perfect conference timing, no one works that week anyway.
<ppisati> come on, you can drive down from Germany :)
 * ogra_ will go by car to UDS ... 
<ogra_> ppisati, no, from denmark
<prpplague> yea LF has done a terrible job of scheduling conferences this year
<GrueMaster> Bloody hell.  Remote desktop IS available, just not enabled.  Grrr.  http://liberiangeek.net/2012/04/list-of-remote-access-support-software-for-ubuntu-12-04-precise-pangolin/ (see bottom).
<ppisati> unfortunately i'll miss plumbers this year
<ppisati> but at least i'll go to elc
 * ogra_ curses bluetooth 
<ogra_> damned
 * GrueMaster now wishes his laptop would support more than 2 monitors.  So many remote machines to work with, so little desktop space.  sigh.
<prpplague> ugh, i so hate the lack of output on ubuntu desktop installs
<ogra_> prpplague, well, we improved that, now we dont even start any GUI in quantal anymore
<prpplague> ogra_: 11.10 works with pandaboard-es and dvi right?
<ppisati> ogra_: so i din't get, are you coming or not to elc? and if yes, when? friday? sat?
<ogra_> ppisati, no, i wont
<infinity> prpplague: I don't think we supported the ES until 12.04?  I could be wrong.
<ogra_> unless someone thinnks they need to send me
<ogra_> we supported the ES with lucid iirc
 * prpplague hates when management asks for ubuntu installations for demos
<GrueMaster> infinity: It was supported (barely) in 11.10
<GrueMaster> Lucid never supported omap.
<ogra_> oh, it did, not omap4 though
<GrueMaster> omap3 support was a tech preview iirc.  And very late in the game.
<infinity> GrueMaster: Yeah, I know for a fact that natty doesn't even pretend to boot on an ES, never tried oneiric.
<ogra_> no, right, it was maveric
<ogra_> that was the release we spent at TI during release week
<ogra_> to bring up the ES iirc
<GrueMaster> As far as DVI goes, I'm not sure if it was supported properly (or is now).  afaik, the images assume output on hdmi port only, and there was no dual monitor output.
<GrueMaster> ogra_: That was the original panda omap4 4450.  I thought the ES was the 4460.
<scientes> GrueMaster, hdmi is backwards compatible with DVI-D
<GrueMaster> (or do I have those numbers wrong).
<GrueMaster> scientes: I know, but there are two "hdmi" ports on panda, 1 is true HDMI, the other is DVI-D in an hdmi form factor.
 * prpplague wishes he had time to fix these issues
<scientes> hdmi also has usb and ethernet for the crazies
<GrueMaster> Only in newer HDMI specs.
<scientes> and for the crazies
<ogra_> GrueMaster, ES was the second gen panda
<ogra_> iirc
<infinity> ogra_: The ES definitely won't work on maverick or natty.
<ogra_> hmm
<infinity> ogra_: And the ES is the 4460, the other Pandas are 4430.
<ogra_> what am i getting wrong here
<GrueMaster> ogra_: Ok, then that wasn't supported until Oneiric
<ogra_> oh, i mixed up E and ES
<ogra_> and EA
<GrueMaster> Yea, the EA was the preproduction 4430.
<ogra_> EA was maverick til natty ... E natty and later
<GrueMaster> The ES is the 4460.
<ogra_> right
<ogra_> sorry, my fault
<GrueMaster> How is it that I'm the only one that always remembers this?  :P
<ogra_> dunno, beer imprints in your braincells we others miss ?
<GrueMaster> Heh.  That must be it.
<rsalveti> :-)
<rsalveti> E1, EA1, 6 layers, 8 layers ES2, lots of names for the older panda :-)
<rsalveti> but yeah, 4460 is supported at precise already, and probably just with hdmi
<rsalveti> dvi is only stable enough to be used since the 3.4 based kernel
<rsalveti> still without support for dual monitors, something maybe prpplague would know more
<rsalveti> but agreen said it'd be quite hard to sync both outputs to make them usable at the same time
<prpplague> rsalveti: it isn't that hard to sync up, but does require some work
<prpplague> rsalveti: the main problem is most of the things i need to test are via the DPI , not HDMI
<prpplague> rsalveti: which makes using the builds almost useless
<rsalveti> yeah, ok
<prpplague> just very frustrating that my angstrom builds work great, but management only wants to see ubuntu
<rsalveti> prpplague: and what is your issue with ubuntu at this point?
<rsalveti> what is causing you headaches?
<prpplague> rsalveti: no DPI support, basically the same issue i always have with it
<rsalveti> I think that's supported with the latest kernel I'd guess
<rsalveti> you could also use the ubuntu-linaro pre-built rootfs we have based on precise
<rsalveti> which delivers the ti lt kernel
<rsalveti> it's just that we had issues with it for a few kernel releases
<rsalveti> if latest 3.5 kernel doesn't support it, it's probably config bug or similar
<balloons> ogra_, does opengl|es mean unity for us on pandaboards? http://smspillaz.wordpress.com/2012/08/22/delivering-compiz-and-unity-on-the-next-wave-of-embedded-form-factors/
<balloons> or do we still need the powervr driver?
<prpplague> rsalveti: got a link to the linaro-ubuntu you are refering to?
<rsalveti> balloons: we still need the pvr driver, but that's also landing today/tomorrow
<ogra_> balloons, well, unity on x86 supports GL ... would it run without a GL capable xserver ? :)
<rsalveti> which will allow us running unity 3d on panda
<rsalveti> just like we had with precise, but now without a huge package patch :-)
<rsalveti> prpplague: http://snapshots.linaro.org/precise/pre-built/lt-panda-x11-base/260/lt-panda-x11-base-precise_ubuntu-desktop_20120821-260.html
<rsalveti> prpplague: download, dd it and let me know if it worked or not for you
<balloons> ogra_, rsalveti thank you.. I assumed we still needed the driver. but that's awesome it's showing up soon as well
<balloons> so friday's builds, fingers crossed should have all the goodness in them?
<ogra_> yeah, by end of the week we should have all bits we need in the archive
<balloons> wah-hoo!
<jimerickson> yay!
<ogra_> but they will need additional integration work (teh driver isnt seeded yet etc)
<ogra_> so i'd rather say monday
<prpplague> rsalveti: thanks will do
<prpplague> rsalveti: looks like i am going to have to build a custom kernel to do what i need
<prpplague> rsalveti: oh well
<prpplague> rsalveti: do you know where the kernel source is for that linaro build?
<prpplague> rsalveti: nm, looks like the linaro build is going to work, still testing
<prpplague> rsalveti: doh detecting the wrong resolution, hehe
<samek> is there any repository with gcc 4.4.4 available for ubuntu 10.04?
<rsalveti> prpplague: but did it work at some leve at least?
<prpplague> rsalveti: yea the linaro-ubuntu boots, but with the wrong resolution detected
<samek> i'm having trouble configuring serial console login on my arm board
<samek> https://help.ubuntu.com/community/SerialConsoleHowto
<samek> this doesn't work
<samek> is there any updates to this document
<samek> oh it works.. was using wrong tty device
<samek> thanks for not answering ;)
<GrueMaster> You're welcome.  :P
#ubuntu-arm 2012-08-23
<rsalveti> ogra_: you changed Bootloader-sets-root: to yes even if the meaning is currently wrong! :-)
<rsalveti> that's a different behavior from debian
<rsalveti> but will at least now work after the installer finishes?
<ogra_> rsalveti, i havent tested it on actual images yet, but beyond that it should work
<ogra_> (as documented in the changelog)
 * ogra_ hugs rsalveti 
<ogra_> yay
<rsalveti> ogra_: there's only one new package that needs to land now, the libdri2
<rsalveti> which is what I'm testing at this moment
<rsalveti> then we'll be ready to go with pvr-omap4
<rsalveti> kernel and xorg related packages all in already
<ogra_> yay
 * ogra_ wonders if omap should be in the xserver-xorg-video-all deps on arm
<rsalveti> I belive so, at least we need to make sure we're installing it by default
<ndec> rsalveti: libdri2-omap in the archives for 12.10?
<rsalveti> ndec: that's what I'm doing now
<ndec> nice1
<rsalveti> it's needed by the sgx driver
<ndec> nice!
<ndec> are you taking the Xserver patches for dri2video as well? sounds more risky ;-)
<rsalveti> ndec: not at this point yet
<rsalveti> want to first make sure it works without any new fancy features :-)
<ndec> how about the clutter/totem 3.4? is there any ARM SoC which has support for that?
<rsalveti> ndec: don't think so
<ndec> rsalveti: also i wanted to ask you about LEB. so ubuntu is no longer doing pre-installed. how does it impat linaro LEB?
<ndec> in fact i don't recall exactly how LEB are generated.
<rsalveti> ndec: doesn't change much, we're still doing pre-installed images
<rsalveti> as well with hwpack + rootfs
<rsalveti> even for quantal
<ndec> rsalveti: ok. is there a wiki that explains your image generation?
<ndec> we need to change our image generation for TI releases... since we were using pre-installed images ;-)
<rsalveti> ndec: sure, 1 sec
<hrw> ogra_: can you grab powertop 2.1 from http://people.linaro.org/~hrw/debian/ and sponsor upload? :D
<rsalveti> ndec: http://git.linaro.org/gitweb?p=ubuntu/ubuntu-build-service.git;a=summary
<rsalveti> http://git.linaro.org/gitweb?p=ubuntu/ubuntu-build-service.git;a=tree
<rsalveti> if you see, this is how we're maintaining our build jobs
<rsalveti> the only thing done by jenkins is a cd to the right folder and ./configure && make
<ndec> rsalveti: and it works outside of LP, e.g. I should be able to run this script?
<rsalveti> that runs live-build and generate the tarball in the end
<rsalveti> ndec: yup
<ndec> hmm... why did I not look into that before...
<hrw> bye
<rsalveti> ndec: the logs from the job handling the quantal images: https://ci.linaro.org/jenkins/view/Ubuntu%20Build%20Service/job/quantal-armhf-ubuntu-desktop/65/consoleFull
<rsalveti> if you want to create a pure ubuntu image (without the linaro sauce), it's quite easy as well
<rsalveti> just need some minor changes, like by not installing linaro-ubuntu-desktop and installing the task ubuntu-desktop
<ndec> thanks a bunch!
<ogra_> hrw, hmm, the .dsc expects a tar.gz tarball
<ogra_> i cant extract it with dpkg-source
<ogra_> rsalveti, any chance that we see a pcr for omap3 update (not FF critical indeed) ?
<ogra_> *pvr
<rsalveti> ogra_: that depends on TI providing us the armhf binaries =\
<ogra_> i thought there were published ones
<rsalveti> not for armhf, at least not by the official channel
<ogra_> hmm, i thought i read something about hf binary drivers
<ogra_> but i cant findit in my history...
<ndec> ogra_: rsalveti: i don't think i have seen a DDK/armhf for OMAP3.
<ogra_> k
<ndec> i think, though, that some TI people are working on adding armhf support in OE, so it is a sign that such binary might show up...
<ogra_> well, probably someone talked about an inofficial binary or some such
<ogra_> i know i catched it up somewhere
 * ogra_ adds unity-2d  back to the ac100 images 
<rsalveti> ogra_: there's a new mesa at the archive today
<rsalveti> might be nice to check if unity3d would work
<rsalveti> or at least how it'd explode
<ogra_> rsalveti, well, slangasek apparently tested yesterday, with rather disatrous results
<rsalveti> hehe :-)
<ogra_> it doesnt explode, but itsnt usable either
<ogra_> hmm, i see a compiz upload but nothing in the changelog indicates its the one that has GLES
<infinity> ogra_: How does adding unity-2d to ac100 work when it's been removed from the archive?  Or did I miss someone adopting it and re-uploading it?
<ogra_> it hasnt been removed
<ogra_> it was removed from the seeds
<ogra_> and i dont think anyone plans to remove it from the archive actually
<infinity> ogra_: Uhm.  It was removed from the archive last week.
<infinity> ogra_: Because no one stepped up to fix the dconf->gsettings mess, or something.
<ogra_> why does apt-cache madison on a current panda still show source and binary then ?
<infinity> Because it lies?  Or has precise in its sources?  Or something?
<infinity> The source was removed.
<ogra_> SH*T
<infinity> Some binaries may still linger due to them having rdeps.
<ogra_> well, rickspencer3's suggestion was actualyl to have it back on the arm images worst case
<infinity> Yes, well.  The desktop team screwed you there.
<ogra_> and the results for llvmpipe are far from usable
<ogra_> damned
<infinity> Probably worth an internal discussion about porting the bits that need porting and reintroducing it.
<rickspencer3> as I understand it, llvmpipe is completely out of the question for ARM
<rickspencer3> we need to wait for the PVR driver to run unity
<ogra_> rickspencer3, after slangasek's test results definitely
<rsalveti> problem is that we'll be able to solve the unity issue just for panda
<rickspencer3> I don't think anyone ever envisioned that it would work, really
<rsalveti> which we have the river
<rsalveti> people can dream hehe :-)
<ogra_> rickspencer3, haha
<rickspencer3> is there another DE that we can use at least to test until the PVR is available?
<rickspencer3> just to bridge us until Unity is runnable?
<rickspencer3> Gnome 2?
<ogra_> rsalveti, right, and for ac100 i was just planningg to pull unity-2d in ... i wasnt aware they actually removed it
<rsalveti> rickspencer3: the pvr driver will be available later today
<ogra_> omap4 will be fine soon
<rickspencer3> oh, so Unity 3d should work(ish) later today?
<rickspencer3> sorry
<ogra_> ish, right
<rickspencer3> you guys were talking about other boards
 * rickspencer3 backs away quietly
<ogra_> what wont be fine are all other arm desktop images
 * rickspencer3 backs back in
<rickspencer3> I wonder if Lubuntu might be a better flavor for other boards?
<ogra_> my second choice after re-introducing unity-2d is lubuntu-desktop
<rickspencer3> it runs my eeePC 701, which is pretty impressive
<ogra_> but that requires more work for me
<infinity> ogra_: Given that ac100 is a community image, why not just switch it to Xubuntu? :)
<rickspencer3> ogra_, you can't just apt-get install lubuntu-desktop?
<ogra_> infinity, why using that much overhead ?
<infinity> ogra_: Or lubuntu, sure.
<ogra_> :)
<rsalveti> lubuntu works as well
<ogra_> yeah, and will have a tiny footrprint
<rickspencer3> the lubuntu community targets exactly this scenario
 * ppisati +1 for reintroducing unity2d
<infinity> ogra_: I really see no reason to ship the full whiz-bang Unity experience for anything except our darling "tech demo" platform (OMAP4).
<rickspencer3> it's the only reason that we bought new PowerPC builders, so that lubuntu could make a PowerPC version
<ogra_> ppisati, its gone from the archive ... i dont see how we woudl get it back without lots fo extra work
<infinity> ppisati: And as much as I want unity-2d back, someone needs to commit to the work, it's not self-maintaining.
<ogra_> infinity, i agree, but someone has to maintain the differences
<ppisati> ogra_: didn't you just said it was just eliminated from seed?
<ppisati> *say
<ogra_> ppisati, i was just proven wron above
<ppisati> ah
<ogra_> *wrong
<infinity> ogra_: What difference?  s/ubnutu-desktop/lubuntu-desktop/ in the ac100 target in livecd-rootfs, profit?
<ppisati> infinity: i agree, but have you ever tried the "3d experience" on a pandaboard?
<ogra_> infinity, well, i have to get used to it for testing etc etc
<ppisati> infinity: if we need to switch for $foobarUbuntu, i prefer U2d
<rsalveti> it's working way better with latest compiz
<infinity> ppisati: With the PVR driver, it's not bad.
<rsalveti> you'd be surprised
<ogra_> and will start to fix arm issues on lubuntu
<ogra_> since people tend to copmpain to *me*
<ogra_> *complain
<infinity> Fixing ARM issues in the whole archive isn't a bad thing. :P
<infinity> But really, it should all Just Work.
<infinity> If it doesn't, we suck at this.
<infinity> A lot.
<ogra_> i think its a lot more than changing the target btw
<infinity> Either way.  I don't want us shipping desktop images for a ton of platforms regardless.  ac100 gets a free pass because it's a pain to install it any other way.
<ogra_> i'm not even sure there is any oem-confi support in the lubuntu ubiquity
<infinity> Uhm, it's the same ubiquity...
 * ppisati goes testing another kernel...
<ogra_> they have overlay packages for everythin in lubuntu, no ?
<infinity> Not for the installer itself.
 * ogra_ needs to get used to this new kbd 
<ogra_> ok
<ogra_> well, then lets just do it :)
<infinity> I suspect just swapping xubuntu or lubuntu in will Just Work, as I said, but either way, it's probably less effort than committing to support unity-2d, unless you want to be the new u2d upstream in your spare time.
<infinity> And if you do, awesome, lots of us love and miss u2d. :P
<ogra_> haha
<ogra_> i'm not that crazy, no
<ogra_> i really would like to see some community people picking it up though
<ogra_> infinity, erm, you didnt mean livecd-rootfs but the nusakan crontab (and default-arches), right ?
 * rickspencer3 looks forward to dist-upgrading panda board tomorrow 
<infinity> ogra_: Oh, fair point, it's not hardcoded anywhere.
<ogra_> good, you had me confused :)
<infinity> ogra_: But yeah, just add armhf+ac100 to lubuntu's default-arches, and give it a try, I guess.  Or do a test-spin by hand.
<infinity> ogra_: It seems like the sane(ish) way forward.
<ogra_> yep
<ogra_> what do we do with mx5 ?
<rickspencer3> rsalveti, will HD video work tomorrow too?
 * rickspencer3 hopes 
<ogra_> LOL
<rsalveti> hahahaha
<ogra_> rickspencer3, we have no codecs
<rickspencer3> so, "not yet", right?
<ogra_> and its unlikely they will ever enter the archive
<rickspencer3> ogra_, well, I thought I could install them from somewhere else
<rsalveti> you can, but for precise
<ogra_> with luck TI will provide gstreamer packages and codecs from the PPA after release
<infinity> ogra_: We already dropped mx5 desktop images, didn't we?
<infinity> ogra_: If we didn't, I'll do that.
<rsalveti> unfortunately for quantal a lot of stuff changed
<ogra_> infinity, not sure, i thought that was only temporary
<rsalveti> they are maintaining like hundreds of patches at the gst packages
<ogra_> wrt livebuilder shortage around a milestone
<infinity> ogra_: Nope, the only desktop images we should be producing are omap4 (the blessed tech demo image), and ac100 (cause it sucks installing any other way).
<ogra_> i think we do build omap still atm
<infinity> ogra_: But mx5 reminds me that we still need to do d-i images from universe kernels.
<ogra_> and i woudl like to keep the opportunity open for an omap3 HF driver
<ogra_> so i would like to go on buildin them
<ogra_> no need for testing or milestone releases though
<infinity> I see no issues with asking non-omap4 users to use netboot and install desktops by hand.  It's not like ubiquity on a Beagle is a pleasant experience anyway.
<ogra_> infinity, i guess FF day is a little late for that
<ogra_> according to colin there is some heavy lifting involved to make d-i use universe
 * ogra_ would really like to see some images to actually test flash-kernel-installer
<hrw> ogra_: fetch again
<ogra_> will do
<rsalveti> ogra_: new compiz doesn't include yet the gles branch
<rsalveti> it's one rev before the one we wanted
<infinity> D'oh.
<ogra_> sigh
<ogra_> oh that endless game
<rsalveti> hm, someone really need to spend some time optimizing the updating of the software catalog
<rsalveti> that always takes a huge time
<ogra_> improve IO
<ogra_> its unzipping huge files
<rsalveti> yeah, imagined that
<ogra_> bah, sigh
<ogra_> if i hadnt messed up livecd-rootfs i could now do an ac100 tesbuild
<ogra_> life always strikes back
<ogra_> hrw, done
<hrw> ogra_: cool, thanks
<rsalveti> ogra_: bug 1040611
<ubot2`> Launchpad bug 1040611 in ubuntu "[needs-packaging] libdri2" [High,Confirmed] https://launchpad.net/bugs/1040611
<rsalveti> ogra_: last piece before the pvr-omap4 driver
<ogra_> rsalveti, uh, whats the license
<rsalveti> http://paste.ubuntu.com/1163077/
<rsalveti> expat
<infinity> rsalveti: Is this a generic dri extension thing that's being pushed to fdo/xorg upstream and (eventually) used all over, or some ARM(or TI)-specific madness?
<ogra_> oh, i misunderstood "as it's binary only, and built against the shared library "
<ogra_> :P
<ogra_> i thought that libdri2 had binary bits
<ogra_> liked against the free one
<rsalveti> infinity: no, idea is to be the reference and generic dri extension
<rsalveti> to avoid duplicates all around
<infinity> rsalveti: If it's not actually generic and intended to be used cross-platform, "libdri" is pretty awful namespace pollution.
<infinity> robclark: ^
<rsalveti> he's the father
<infinity> robclark: Bring your sideburns over here and tell me about libdri.
 * ogra_ runs an ac199 lubuntu-desktop testbuild
<ogra_> *ac100
<infinity> If the ac199 comes with an en_US non-android keyboard, I'll take two.
<robclark> infinity, rsalveti, libdri2 is basically some code extracted out of mesa so that other things can use it
<ogra_> infinity, you and your keyboard fixation :P
<infinity> robclark: Sure, I grasp *what* it is, but is it being pushed upstream as a generic solution that others intend to use for this same purpose, etc?
<infinity> robclark: Cause if it ends up being just an ARM thing, just a TI thing, the namespace pollution of "libdri" is a bit icky.
<infinity> robclark: And, if it's partly cargo-culted from mesa, why not build it from mesa, so it can be more readily kept in sync?
<robclark> infinity, well, I did send a while back a patch for mesa to use it..
<infinity> robclark: (And so others can learn of its existence and use it)
<robclark> anyways, the point was that mesa, vdpau, vaapi, etc where all just copy/pasting the same code
<infinity> robclark: Dude, are you going German on me?
<robclark> :-P
<infinity> "well, I did send a while back a patch for mesa to use it"... I thought Oli typed that, until I read the nick. :P
<infinity> Just sayin'.
<robclark> I need to kick mesa folks again...
<ogra_> LOL
<ogra_> texas is full of germans
<rsalveti> lol
<robclark> heheh
<infinity> robclark: Anyhow, if you've had any positive response from upstream about it at all, and if it seems likely it'll end up being "a thing" upstream, then I'm less grumpy about including it as-is as a stop-gap in Ubuntu right now.
<ogra_> might have some bad influence on the language :)
<robclark> well.. my reasoning is that currently dri2 is a bit of an exception to the way most x11 extensions work.. ie most you have a proto tree plus a client side lib tree
<robclark> dri2 is the only one (that I know of) that doesn't have a client side lib tree.. hence libdri2
<robclark> anyways, why is it a namespace issue?
<infinity> robclark: *nod*... Like I said, I'm down with the concept, and your reasoning.  Just more curious if you've been able to sell upstream.
<infinity> robclark: But if you're pushing upstream to DTRT here, that's cool.
<infinity> robclark: It's a namespace issue only because I could totally see someone else introducing a libdri that's an entirely different thing, so it would be nice if yours was on the radar and won. :P
<robclark> I do need to kick them again..  if I can make it to xdc then I'll bring it up in person there..
<robclark> I think main issue is that most everyone on xorg/mesa/gfx side of things has too much to do and too little time to care about those sort of little cleanups :-P
<ogra_> bah, lubuntu build failed
<infinity> robclark: You'd think that would make them all the happier about someone else doing it.
<ogra_> The following packages have unmet dependencies:
<ogra_>  indicator-application-gtk2 : Depends: indicator-application (= 0.5.0-0ubuntu1) but it is not going to be installed
<ogra_> GRMPF
<ogra_> i guess lubuntu wasnt a good choice if they have to port the world to gtk3 first
<infinity> I assume that's just buildd skew.
<ogra_> i would assume that indicator-application stopped providing its gtk2 bits
<rsalveti> infinity: so what do we say, trust robclark and push it to the archive? :-)
<infinity> Oh, indeed.  Very recently.
<infinity> rsalveti: Yeah.  If robclark fails us, we can wax his face.
<infinity> ogra_: Yell at Seb?
<ogra_> infinity, he will just point me to the unity team
<infinity> ogra_: Dropping GTK2 in indicators all over is a nightmare for Xubuntu and Lubuntu, and right before FF, no less. :/
<ogra_> and they then point me to sabdfl ... and i wont yell at him i fear :P
<infinity> You should.
<infinity> In cases like this, he's just another contributor.
<ogra_> no, yelling is the wrong approach for sure
<infinity> Until he formally sabdfls something, which is a different matter.
<xnox> there was an email about moving those bits to universe? or was it a complete drop?
<xnox> (e.g. separate source package)
<ogra_> well, seb just referred to that mail
<ogra_> in -desktop
<ogra_> so it seems xubuntu wants to take over maintenance of gtk2 parts in universe
<scientes> ogra_, so xubuntu is not gtk3?
<ogra_> but seemingly need to push these in from scratch
<scientes> *xfce
<ogra_> no idea
<ogra_> they use a lot of gtk2 stuff, that i know
<ogra_> lubuntu intrestingly as well
<ogra_> i guess for NM
<rsalveti> infinity: ogra_: and finally, the pvr driver: http://people.linaro.org/~rsalveti/pvr/, but it needs libdri2
<ogra_> yay
<rsalveti> http://git.linaro.org/gitweb?p=ubuntu/pvr-omap4.git;a=summary
<infinity> scientes: XFCE is GTK2 for now.  There was a push for GTK3 porting, and it got derailed upstream.
<infinity> Turns out it's a lot more work than people realised when they first got gung-ho about it. :P
<infinity> Like, effectively a rewrite of half the world.
<scientes> looks like lxde is being ported too
<scientes> and i *was* subscribed to the linux gtk3 migration
<scientes> but that patch and email flow was just too great
<rsalveti> ogra_: hey, any news about the driver?
<rsalveti> infinity: for you as well, in case you're willing to sponsor it :-)
#ubuntu-arm 2012-08-24
<ogra_> http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/20120824/
<ogra_> there we go
<ogra_> ac100 lubuntu
<ogra_> wow, and only 400M
<lilstevie> nice
<lilstevie> I've recently renewed some work on the tf101
<lilstevie> (took long enough) :p
<ogra_> heh
<lilstevie> but u-boot won't play ball with my usb keyboard :/
<ogra_> get a bluetooth one
<ogra_> will surely be better :P
<lilstevie> u-boot
<lilstevie> :p
<ogra_> yeah, that was the joke :P
<lilstevie> instead I have started writing a driver for the dock keyboard
<ogra_> ++
<ogra_> ood move
<ogra_> *good even
<lilstevie> we have no serial
<lilstevie> so playing with involves putting a boot.scr with the commands I want to execute on a usb stick
<lilstevie> speaking of u-boot though, documentation on device tree stuff is really lacking
<ogra_> yep
 * ogra_ agrees
<lilstevie> is there any documentation anywhere that could give me a hand, so far I have had nothing but fail in trying to get a kernel running using a device tree
<ogra_> i dont know of an, oogle ...
<ogra_> *google
<lilstevie> yeah tried that
<lilstevie> :(
<lilstevie> fragments, none of which seem to help tegra
<ogra_> well, what i know is that you need a devicetree file and u-boot needs to load it somehow
<lilstevie> heh
<lilstevie> well I managed that part
<ogra_> and indeed your u-boot version needs to know how to handle it
<lilstevie> and ran the fdt commands
<lilstevie> yeah, I'm using the l4t-r15 u-boot
<marvin24> lilstevie: what's the problem?
<marvin24> on ac100 the device tree get appended to the u-boot binary
<marvin24> which is transfered to the kernel later in the boot process
<marvin24> the problem is that kernel has a slightly different device tree than u-boot
<ogra_> ouch
<ogra_> it shouldnt, should it ?
<marvin24> no it shouldn't
<ogra_> (at least by my knowledge of DT one DT file should work with bootloader as welll as kernel)
<marvin24> but mainline u-boot isn't updated yet
<marvin24> but I guess you can just copy the kernel dt to u-boot
<marvin24> as long as the syntax is equal
<marvin24> ogra_: is the new quantal image installable?
<ogra_> marvin24, havent tested it since teh switch to lubuntu, download is just done
<marvin24> I wonder if it also has the limitation to be only installable to the internal mmc
<ogra_> http://cdimage.ubuntu.com/lubuntu/daily-preinstalled/20120824/
<marvin24> I will try out later
<ogra_> i havent changed anything in the installer
<ogra_> everything should work/fail as it did before :)
<marvin24> :-(
 * ogra_ doesnt get what was broken, for me all install variants worked last time i tested
<ogra_> ah, sweet i'm in lubuntus oem-config :)
<ogra_> X took quite long to come up ... i already thought it had crashed
<marvin24> maybe it restarted several times
<ogra_> might be, i'll check the logs once i can
<ogra_> hmm, weird that they use the same slideshow
<ogra_> doesnt really match the color theme
<xnox> oh their slideshow was crashing or something
<ogra_> ah
 * xnox ponders if I should continue ubiquity development on lubuntu
<ogra_> yay, oem-config survived ... i'm in package removal
<xnox> ogra_: based on the foundations-team report, is there a bug tracking compiz llvmpipe landing in ubuntu?
<ogra_> not yet, no
<xnox> and will there be a release meeting today?
<ogra_> and i'm pretty sure we wont enable it at all for arm builds
<ogra_> ask kate :)
<ogra_> i have it on my gcal but that doesnt mean much :)
<ogra_> xnox, we're still waiting for input from doko in the mail discussion about llvmpipe (thouh i suspect he wont maically pull code out of a hat that makes arm work)
<ogra_> yay, "removing cryptsetp" :)
<ogra_> *setup
<ogra_> lightdm !
 * ogra_ logs in
<ogra_> heh
<ogra_> the games subment uses the same icon for all games
<ogra_> *submenu
<ogra_> marvin24, so at least the default install works just fine here
 * ogra_ is surprised to see the initial desktop use 267MB 
<ogra_> thats way more than unity-2d used
<ogra_> (about 100M)
<marvin24> nice it worked so far
<marvin24> I will try install on sd card then
<ogra_> hmm, chromium is not working
<xnox> crashes?
<xnox> it did for me, i switched to chrome
<ogra_> yep
<ogra_> on your panda ?
 * xnox 'for me' usually means 'on my amd64'
<ogra_> ah
 * xnox has no screen for panda remember =)
<ogra_> well, there is always ssh -X
<ogra_> ;)
<ogra_> sigh, apport
<xnox> aport - is the command you give your dog to 'fetch' in Russian
<ogra_> haha
 * ogra_ tries suspend
<ogra_> bah
<xnox> let me just tell you =) quantal daily amd64 is awesome in the VM: no dash, no indicators, no panel on the top. Simply a pretty background + icon install ubuntu
<xnox> simply precise =) awesome
<ogra_> haha
<ogra_> you should try it on the panda ... there its awesome and breaking :)
<xnox> i am pretty sure that it's the fallback metacity without any acceleration
<xnox> btw what did happen to the gnome fallback (ubuntu classic)
 * ogra_ thinks now that he has to look at xcreensaver again regulary it is time to reintroduce the xft patch for the unlock window as infinity suggested
<ogra_> this thing is just to ugly
<xnox> ogra_: see what unity does to you! calling other projects "too ugly"
<lilstevie> marvin24, screen black (backlight on) and nothing
<marvin24> lilstevie: serial console available?
<lilstevie> no
<marvin24> if the kernel is compiled for device tree support and no dt is supplied it will just stop
<lilstevie> not enough resources have gone into locating the serial
<marvin24> hacking u-boot without a serial console is ...
<lilstevie> by supplying dt you mean fatload ; fdt address {blah}; fdt resize; bootm
<marvin24> lilstevie: mmh, we use u-boot-dtb.bin
<lilstevie> without a serial console is... fun? :p
<marvin24> which does not require loading it from somewhere else
<lilstevie> hm
<marvin24> do you have patches for tf101 on mainline?
<marvin24> 3.1 kernel won't boot with device tree anyway
<lilstevie> oh
<lilstevie> even though it has generic DT support?
<marvin24> yes
<lilstevie> that could be the issue
<marvin24> a *lot* of dt work went into mainline in the last version
<lilstevie> ah
<marvin24> that's what the nvidia folks mostly did over the last months
<marvin24> mainline just removed board file support ;-)
<lilstevie> :)
<marvin24> so, better spend your time towrite a nice device tree file for tf*01
<marvin24> and add u-boot support
<lilstevie> well the seaboard device tree pretty much works with a resolution change
<marvin24> so you got mainline kernel working already?
<lilstevie> no u-boot
<marvin24> ah
<marvin24> I think linux kernel support should be a big problem then
<lilstevie> haven't really tried much past trying to get the device tree to load on a working 3.1
<lilstevie> marvin24, is the ac100 stuff somewhere?
<rsalveti> ogra_: hey, any news about the pvr driver?
<rsalveti> :-)
<ogra_> rsalveti, hmm, didnt infinity upload it yesterday ?
<rsalveti> ogra_: nops
<ogra_> yeah, doesnt seem to be in any queue
<ogra_> i'm in a call now, will take care afterwards
<rsalveti> ogra_: great, thanks
<ogra_> rsalveti, uploaded (will be stuck in NEW now)
<rsalveti> ogra_: did you also upload libdri2?
<rsalveti> ogra_: bug 1040611
<ubot2`> Launchpad bug 1040611 in ubuntu "[needs-packaging] libdri2" [High,Confirmed] https://launchpad.net/bugs/1040611
<ogra_> only libdri2 yet
<rsalveti> oh, ok
<rsalveti> good, we can poke infinity when he's back on-line
<ogra_> under the assumption that NEW processing might take a bit
<rsalveti> we just need to get someone from the desktop to update compiz again
<rsalveti> now using the right revision
<ogra_> seeing seb128's release report on the ubuntu-release ML they are aware it seems
<ogra_> "* compiz GLES landing to compiz-trunk, needs to be tested and released"
<ogra_> seems they wait for an upstream release for it
<rsalveti> got it
<Laney> ogra_: Care to take a look at http://ubuntuone.com/0E3feYdrhGY1ywL9vNBjbS and tell me what I did wrong please? That's a netboot install on my panda using the latest fb image. :-)
<ogra_> Laney, they system needs the SD card to boot (and write the bootloader to it during install)
<ogra_> so dont unplug it ;)
<ogra_> sorry, i'm behind with the install instructions, the wiki should say that
<Laney> unplug? I unplugged nothing
<Laney> I just did what this says http://testcases.qa.ubuntu.com/Install/ARM/NetBoot
<ogra_> how did you boot the netboot image ?
<ogra_> and the Sd is still in the slot ?
<Laney> yes
<ogra_> hmm
<Laney> unless it fell out ...
<ogra_> probably bug 806751
<ubot2`> Launchpad bug 806751 in debian-installer "Boot partition on SD is too small on omap/omap4" [Medium,Fix released] https://launchpad.net/bugs/806751
<Laney> Fix Released?
<ogra_> though that shouldnt say "is not a block device"
<Laney> I'm installing with / on an attached USB drive if that matters
<ogra_> thats fine
<ogra_> and you used guided partitioning ?
<Laney> manual â select free space â auto partition
<ogra_> hmm
<Laney> I think it made a separate /boot partition
<ogra_> yes, it does that by default
<Laney> ho hum
 * Laney gets a live image instead
<ogra_> noo !
<ogra_> get a server image at best :)
<ogra_> desktop is totally borked due to the removal of unity-2d
<Laney> argh, really?
<ogra_> yep
<ogra_> llvmpipe on arm doesnt work...
<Laney> sigh
<ogra_> and there is no 2D desktop anymore ...
<ogra_> nor are there 3D drivers yet
<ogra_> the alpha milestone might work ... but you should refrain from upgradin
<Laney> i'll just get that and hold unity-2d then
<ogra_> that should work
<ogra_> sorry, that netboot didnt work out for you, i'll have a look over the weekend what that is
<ogra_> weird error ... really
<Laney> I chose the desktop task so it would have been a bit doomed anyway :P
<ogra_> heh, yeah
<Laney> there was a weird "Ubuntu Desktop (USB)" task too â wonder what that's about
<ogra_> tasksel should be able to tell
<ogra_> it should have at least a long description (that d-i doesnt show i think)
<xnox> ogra_: shall we ship gnome-session-fallback on arm then?
<xnox> to unbreak desktop images
<ogra_> xnox, nope, we're waiting for NEW prosessing of libdrm2 and will then have the new GLES driver in the archive shortly after
<ogra_> no need to invest time into hacks
<furan> is there some way to dump the sym versions using a kernel image?
<furan> I tried looking at /proc/kallsyms but that doesn't give me the versions
<rolf__> I am running a padaboard. is a dist-upgrade from ubuntu 11.10 server to 12.04 server a standard procedure or is there anythins special to take care of?
<rolf__> How much time will such a dist-upgrade take?
<infinity> rolf__: Given that 12.04 was the introduction of armhf as our supported arch, I'd recommend a reinstall.
<infinity> rolf__: But dist-upgrading your armel install should work fine.
<infinity> (It'll just not be armhf)
<rolf__> thank you
#ubuntu-arm 2012-08-25
<ogra_> infinity, ARGH !
<ogra_> why did you drop omap server ?
<ogra_> that breaks my virtual bamboo feeder (and automatic image testing in VMs)
<ogra_> infinity, can we please keep these images running as unsupported
<ohad_> Hello
<ohad_> Can someone assist me installing ububtu under the BBxM? the USB doesnt work...
<xnox> it's quiet over the weekend. And I am sorry I don't know much about BBxM
<xnox> try googling for answers / instructions =|
<xnox> ogra_: sorry that i am not much help...
<xnox> Please help =) no wifi & package from proposed does not install
<xnox> bug 1041607
<ubot2`> Launchpad bug 1041607 in linux-meta-ti-omap4 "cannot install linux-ti-omap4 3.5.0-209-omap4" [Undecided,New] https://launchpad.net/bugs/1041607
<xnox> is it just me or: 1GHz i386 is actually much faster 1GHz armhf ?
<scientes> xnox, the arm might not have neon (simd)
<scientes> alot of x86 power is in the simd instructions (sse2, sse3, etc)
#ubuntu-arm 2012-08-26
<infinity> ogra_: You can turn back on omap server if you want, especially if you're testing it.
<infinity> ogra_: I was trying to eliminate things we never/rarely get testing on, mostly.
#ubuntu-arm 2013-08-19
<snkt> hello
<snkt> I m working core ubuntu... I have to installed icewm window manager.... but it fails to have proper taskbar...
<snkt> can anyone help which are the packages required...
<infinity> snkt: Did you install icewm or icewm-lite?  The former is meant to have a taskbar.
<snkt> icewm
<snkt> I m using a core ubuntu image...
<infinity> (You may also want icewm-themes and menu)
<snkt> without gdm
<snkt> in core ubuntu... first I have installed "xorg" then I need a window manager...
<infinity> I'm afraid I've never used icewm, so you could Google the answers as well as I can.
<snkt> I am trying ubuntu for Low Memory System...
<snkt> without heavy packages such as gnome, kde etc...
<snkt> ok infinity ..
<infinity> Are you *positive* you installed icewm, and not icewm-lite?
<snkt> Ya I have installed icewm
<snkt> can someone help me.... in which script I should make changes in order to invoke "startx" directly...
<snkt> without any login
<chrs_> hey. anyone have mali opengl es working on chromebook arm?
<janimo> rbasak, I successfully created armhf chroots a while ago, maybel earlier this year
<janimo> rbasak, via mk-sbuild iirc
<janimo> so debootstrap must have worked too
<rbasak> janimo: what about the lxc-create template though?
<janimo> rbasak, I had never tried it via lxc just saw stgrabgers year old blogpost saying how it's done
<janimo> https://www.stgraber.org/2012/02/03/ever-wanted-an-armel-or-armhf-container-on-an-x86-machine-its-now-possible-with-lxc-in-ubuntu-precise/
<rbasak> janimo: ah OK. Sounds like it is a regression then.
<janimo> rbasak, at least the big report I filed first has the workaround, stgraber said the template has the hardcoded iproute name
<janimo> which need chaning
<janimo> he may have missed the deps of the dhcp one
<janimo> rbasak, as for why it does not start correctly even after debootstrap succeeds I have no idea, hence filing the bug :)
<mijk> anyone here running Ubuntu on their Chromebook?
#ubuntu-arm 2013-08-20
<gbit86> anyone here ever setup a wyse thin client with lpd usb printer redirection to a xrdp server?
<gbit86> I do this all the time with windows, but I want to move away from it
#ubuntu-arm 2013-08-21
<mijk> anyone run ubuntu on a chromebook?
<mijk> I can't get opengles to work, i know it's been done but there's 0 documentation on how to successfully get it to run
<hildebrandus> Does anyone have some experience on using ubuntu on pandaboard ES
<dowson> How can I go about replicating the Ubuntu for ARM build infrastructure (Launchpad?) locally on my machine, so that I can use a Yocto generated toolchain with specific optimizations, to build a standard Ubuntu 12.04 distro locally, from scratch?
<ogra_> dowson, like this ? https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally
<dowson> What does soyuz do?
<ogra_> https://dev.launchpad.net/Soyuz/TechnicalDetails
<ogra_> ?
<dowson> Great. So, if I setup a new virtual machine with Ubuntu 12.04, follow the instructions given here: https://dev.launchpad.net/Running and then install Soyuz, I would have the basic infrastructure setup?
<ogra_> you should yeah
<dowson> great, thank you!
<elisa87> hey I have problem cross-compiling a C code . can you see this? http://stackoverflow.com/questions/18363288/error-in-cross-compiling-a-c-code-unknown-type-name-syscall-slong-t
#ubuntu-arm 2013-08-22
<dowson_> Hi, while trying to setup launchpad, I get the following error:
<dowson_> $ bzr --no-plugins cat http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/utilities/rocketfuel-setup > rocketfuel-setup
<dowson_> bzr: ERROR: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/.bzr/repository/packs/abccead16fd611e1473706f5f6170373.pack is redirected to http://91.74.184.33:80/videoplayer/abccead16fd611e1473706f5f6170373.pack?ich_u_r_i=e569ed64709aa12b4388ab15efbec59f&ich_s_t_a_r_t=0&ich_e_n_d=0&ich_k_e_y=1345088922750663092468&ich_t_y_p_e=1&ich_d_i_s_k_i_d=7&ich_u_n_i_t=1
<dowson_> Yesterday, I was able to download the rocketfuel-setup script once, but then after a couple of failed attempts at running the installation, I noticed that I wasn't able to download it any more
<dowson_> I've checked my /etc/hosts, and ensured that it doesn't redirect requests locally, and I'm using a clean VMware Ubuntu 12.04 installation.
<infinity> dowson: Sounds like a captive portal or other icky ISP madness.
<snkt> hello
<snkt> can anyone help me... ethtool doesnot work...
<snkt> I am getting " No data available"
<snkt> can anyone help me....
<snkt> I am using ubuntu11.10 core image for ARM
<rbasak> snkt: sounds like ethtool may not be supported by your kernel/NIC driver. Try mii-tool. If that also doesn't work, you probably need to figure out what you need to do with your kernel (which isn't part of Ubuntu Core itself, I don't think)
<snkt> rbasak, Can you please help me... which are the supports required in kernel.... I have already configured kernel .... but still unsuccessful
<rbasak> Sorry, I don't think there's any general answer to your question.
<suihkulokki> can someone update device-tree-compiler to latest in saucy and provide stable update to raring as well?
<rbasak> suihkulokki: I just asked on ubuntu-devel. You should follow bug 1194183. I'm not sure about an SRU to raring, since I'm not sure that it'll meet SRU policy. But it could definitely be backported if someone does the work. First step though: sync to Saucy.
<ubot2`> Launchpad bug 1194183 in device-tree-compiler (Ubuntu) "v1.4.0 released upstream" [Wishlist,Triaged] https://launchpad.net/bugs/1194183
<rbasak> suihkulokki: and if someone could check that the update won't break qemu, that would help :)
<rbasak> suihkulokki: looks like xnox has synced it, so 1.4 is in saucy now.
<suihkulokki> rbasak: ok, thanks
#ubuntu-arm 2013-08-23
<snkt> hiii
<snkt> ethtool is not working.... Can anyone help me... any support required in kernel configuration???
<snkt> hiii
<dowson> Hi, I've installed Launchpad and Soyuz, locally on my machine. I'd like to build Ubuntu-12.10 for ARM locally on my machine. What should I be doing next? .. build launchpad-buildd locally, build QEMU for ARM? Where can I get the package specifications for the Ubuntu 12.04 for ARM distro, so that I can attempt a build locally on my machine?
<snkt> Is Java Plugins for firefox is available for Ubuntu 11.10 arm ???
#ubuntu-arm 2013-08-24
<teeks99> I've got an Allwinner A10 chip (in a HDMI dongle), which is a Cortex A8 (ARMv7). The image I see on releases.ubuntu.com says it's an armhf+omap4....does that mean the omap part is optional and it will work with any armhf?
<infinity> teeks99: Our userspace will work with any ARMv7, but you'll need to bring your own kernel, we don't ship an A10 kernel.
<teeks99> i see
<teeks99> so kernels are specific to manufacturers?
<infinity> teeks99: Sadly, at this point, yes.  And often specific to device, not just SoC.
<infinity> teeks99: Work is ongoing to make that not true, but some OEMs play better on the generic multiplatform kernel front than others.
<teeks99> i see
<teeks99> so TI's omap4 is the only one that is officially supported?
<teeks99> with 13.04
<infinity> And via the generic kernel, a few others (Calxeda highbank, Freescale i.MX6, TI OMAP3, ARM vexpress...)
<infinity> But not the A10, sorry.
<teeks99> so what's currently the cheapest one I could get to try out?
<infinity> A Beagleboard-xM (OMAP3) or Pandaboard (OMAP4) might still be your best bets, if you don't feel comfortably rolling your own kernel.
<infinity> The iMX6 SabreLite will outperform both, but installing to one isn't foolproof.  I should probably fix that when I find some Spare Time(tm).
<teeks99> cool, thanks for the tips
<das_plague> no recommendation for beaglebone black?
<infinity> prpplague: I'd happily recommend it if I knew we shipped a kernel/installer that worked out of the box with it, since the above user wasn't comfy with fiddling with his own kernels.
<prpplague> infinity: which brings me to the point.... why can't get a out of the box installation for black?
<infinity> prpplague: In fact, if someone can tell us what we need to do to make the generic multiplatform kernel happy on the Black, I'd be happy to get it going and add installer support for it.  Though, it might help if I had a device. :/
 * prpplague bangs head on desk
<prpplague> infinity: i've been emailing and calling for two weeks to canonical trying to get this done
<infinity> prpplague: SRSLY?  To whom?
<infinity> (Clearly not me)
<armin76> lol
<armin76> bureaucracy
#ubuntu-arm 2013-08-25
<lilstevie> <teeks99> so kernels are specific to manufacturers? <-- they can be specific all the way down to a device level depending on SoC and whether they use device trees
<mijk> anyone here run Chrubuntu?
<hrw> mijk: what is a difference between chrubuntu and *buntu? both use same base system
<mijk> hrw, are you Marcin?
<hrw> yes
<mijk> oh cool
<hrw> my chromebook runs fedora now anyway
<mijk> I'm just trying to get OpenGLES to work to some degree on my Chromebook
<mijk> maybe I'm using the wrong term by saying chrubuntu
<hrw> mijk: I do not have anything else to say that I wrote on my blog
<mijk> okay
<hrw> so do not waste time asking me about opengles for chromebook
<mijk> wow, okay
<mijk> like I don't know what your problem is, not everyone's as 1337 as you, sorry
<hrw> have a nice day
<mijk> fuck yourself too I guess
<hrw> mijk: opengles for chromebook has license problems
<hrw> as we are not quite allowed to redistribute it
<mijk> that was easy
<hrw> so packages cannot be created to be included in distro
<hrw> and I do not want to keep such stuff in external repos
<hrw> it has nothing about being leet or not
<mijk> there, that's all you had to say rather than make me feel like a piece of shit for asking something that I am not aware of and not technical enough to figure out
<hrw> I know that my style of writing posts is far from perfect
<hrw> http://marcin.juszkiewicz.com.pl/2013/04/15/hardware-acceleration-on-chromebook/ has info about drive
<hrw> r
<hrw> since then another version appeared but this time I did not even bothered looking at it
<mijk> I can't find libmali 35 so I'm screwed either way
<hrw> mijk: https://github.com/hrw/chromebook-mali-driver may have it
<hrw> or maybe it has 0.0.45 - I do not remember
<hrw> nope, 45 only
<hrw> old recovery images you need ;(
<hrw> or refreshed kernels
<hrw> but that's not me - I finished my ubuntu work.
<hrw> have a nice day/night
<hrw> 01:13 here so time to sleep
#ubuntu-arm 2014-08-19
 * genii sips and ponders in-vehicle infotainment systems
#ubuntu-arm 2014-08-21
<Mio-chan> Ello
<Mio-chan> I'm thinking of purchasing the new Acer Chromebook 13 w/the Nvidia Tegra K1. Shouldn't be too much of a hassle to get Ubuntu on it (or any other distro)....right? Just wondering..
#ubuntu-arm 2015-08-19
<lvmc_> Hello.
<lvmc_> I'm looking for any documentation explaining how to port Ubuntu ARM for new platforms like MK808b Plus or Measy U4C.
<lvmc_> Based on rk3188 or amlogic processors.
#ubuntu-arm 2015-08-23
<Cloudie7> good day
<Cloudie7> is someone here skilled in the use of a RPI 2?
#ubuntu-arm 2017-08-23
<zaoqi> How can I get the minimal root filesystem?
<ogra_> zaoqi, look at cdimage.ubuntu.com for ubuntu-base
<zaoqi> How can I install xephyr?
<k1l> install the xserver-xephyr package?
#ubuntu-arm 2017-08-24
<zaoqi>  apt update:https://paste.gnome.org/pp7cdxf20 (gnupg is installed) ... Could not execute 'apt-key' to verify signature (is gnupg installed?) ...
#ubuntu-arm 2017-08-25
<leftyfb> So I'm running Ubuntu on my pi. I'm trying to run a resize script similar to what raspbian does on boot but from the kernel directly. I'm adding init=/path/to/script to the kopt. After update-grub it gets added to all the kernel lines in menu.lst but the script doesn't seem to be running at all.
