#ubuntu-arm 2009-02-09
<ogra> lool, in fact it migth not even matter which endianess the kernel is, seems its a simple switch in apex
 * ogra wonders if he can flip that without re-rolling the whole image
<lool> ogra: We should use the same endianess as Debian otherwise multiple places will have to diverge
<lool> e.g. flash-kernel, d-i
<ogra> ah, indeed
<Stskeeps> how's the kernel project going btw?
<ogra> slow, we might not see omap kernels for jaunty
<Stskeeps> alright
<ogra> there is still hope though... 10 days to go until FF
<Stskeeps> jaunty is freezing in 10 days? k
<ogra> https://wiki.ubuntu.com/JauntyReleaseSchedule
<Stskeeps> ah
<Stskeeps> ta
<playya> 10 days = at least 200h for working. no family. no sleep. and sitting on a big basket :)
 * ogra wonders why playya describes his day to day work
 * ogra lifts the cover of the basket and sees that it snows outside
<playya> i sit on a very comfortable chair. but the rest: yes :D
<playya> but atm i have a few exams. so sometimes i have to learn  ;)
<NCommander> ?
<ogra_> !
#ubuntu-arm 2009-02-10
<Ramon_Valdez> someone knows if GNAT will be available with Ubuntu ARM ?
<ogra> lool, so just not byteswapping the kernel doesnt solve the nslug bootprob
<lool> ogra: Does it help booting the Debian kernel?
<ogra> you mean i should dump the debian kernel into d-i during build ?
<lool> (just curious)
<lool> ogra: No, serve it over HTTP and boot
<lool> ogra: Cause it was simply hanging in my tests
<ogra> oh, i would have to reflash to redboot again
<lool> ogra: I guess it's the apex partition then
<ogra> which is a bit tricky without a bootable system atm
<lool> Reflash to redboot?  just load it from redboot over HTTP and exec it
<lool> You don't have redboot in your current image?!
<ogra> its using apex
<ogra> di-nslu2.bin has apex ....
<lool> APEX is loaded by RedBoot
<lool> di-nslu2.bin wont touch your redboot...
<lool> I hope you didn't erase the full flash, but the default in upslug is not to
<ogra> oh, right, it scrolled off screen :P silly me
<ogra> well, i'm ore intrested in why our kernel just dies ...
<ogra> its not even uncompressing
<ogra> and i would it to do so now that i have a di-nslu2.bin without changed byteorder
<ogra> *would expect it to
<lool> ogra: From the nslu2 README:
<lool> In practice, this means that there is only 1 MB of space for
<lool> the kernel because the initrd starts 1 MB after the kernel.
<ogra> meh
<lool> Might be why our initrds don't work with plain redboot
<ogra> -rw-r--r-- 1 ogra ogra 1,9M 2009-02-10 12:34 vmlinuz-2.6.28-7-ixp4xx
<lool> That's ok
<lool> It's just when you use plain redboot
<ogra>  - A partition for the kernel: the kernel is split in two and each parts
<ogra>    have a header
<lool> However our redboot tests are useless
<ogra> right
<ogra> i want a working binary blob
 * ogra wonders off reading http://www.nslu2-linux.org/wiki/Info/BootFlash
<lool> ogra: Would be nice to have the nslu2 firmware for the ethernet device in restricted and build with it
<ogra> lool, definately
<ogra> i dont get where they put the second half of the kernel
<lool> ogra: There's a single partition for the kernel, but it's written in two parts
<ogra> how does a >1M kernel fit in there ?
<ogra> debians is 1.3M, also bigger than 1M
<lool> [part 0 <RedBoot>][part 1 config][part 2 <APEX> <kernel part 1/2> <magic> <kernel part 2/2>][part 3 <initrd>]
<lool> The problem is that RedBoot looks at part 2 + 1M to find a special magic
<lool> We don't care about what it loads except that it loads apex fine
<lool> But it needs to find its magic
<ogra> oh, so the whole device is 8M in any case, we just need to set the magic mark at the right point
 * ogra slowly gets it
<ogra> what a silly design
<lool> It's due to the restrictions of linksys' redboot
<ogra> ah, right http://tech.groups.yahoo.com/group/nslu2-linux/message/33 doesnt talk about mtdblock3 at all
<lool> Wow the make foo in build/config/armel/ixp4xx/netboot.cfg is awful
<ogra> heh
<ogra> yeah
<lool> ogra: So how did you try to revert the endianess of the kernel?
<lool> I see nothing wrong with Colin's changes
<ogra> i just commented the devio line and didnt use .swapped at the bottom
<ogra> which should make it use the kernel 1:1
<ogra> but the behavior is identical, swapped or not
<ogra> its just hangs after "copy -s fis://kernel 0x00008000" in both cases
<ogra> hmm, though shouldnt that be  0x00010000 ?
<ogra> ah, no, its right
<lool> This skips APEX
<ogra> no
<ogra> that is apex output
 * ogra re-flashes the debian di binary to compare
<lool> I'm saying this offset is to skip APEX, but actually it's not
<ogra> # copy -s $kernelsrc $bootaddr
<ogra> # copy -s fis://kernel 0x00008000
<ogra> 1441760 bytes transferred
<ogra> ok, thats the debian output
<lool> So this is in the APEX package which is built specifically for the NSLU2, how inelegant
<ogra> complain to martin michlmayer :)
<ogra> i think he rlled most of these packages initially
<ogra> *rolled
<lool> No, Marc Singer did
<ogra> he wrote apex
<lool> Well I'm complaining about apex
<ogra> ah
<ogra> i thought about how it was used
<ogra> i mean apex is only a bootloader in the end, like uboot, no ?
<lool> Yes, my problem is that its script is hardcoded in the apex package
<ogra> hmm, looking at the debian d-i code:
<ogra> util/pad $(TEMP)/initrd.gz.nslu2 6291440 # size of partition - 16 for header
<ogra> i wonder if colin didnt pick to high values
<ogra> hmm, no the sum is identical
<ogra> so what about raising the kernel partition size by 1 block
<lool> ogra: Do you have debian installed?
<lool> Could you run apex-env in it?
<ogra> i.e. to 2228192
<lool> I'd like to confirm that the script is like "copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr"
<ogra> no, i dont, and it takes 8h to do so
<ogra> yes, it is
<lool> actually:
<lool> copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot
<ogra> i can see that by using the di binary blob
<ogra> its executed exactly in that order
<ogra> Use the command 'help help' to get started.
<ogra> # copy -s $kernelsrc $bootaddr
<ogra> # copy -s fis://kernel 0x00008000
<ogra> 1441760 bytes transferred
<ogra> # copy -s $ramdisksrc $ramdiskaddr
<ogra> # copy -s fis://ramdisk 0x01000000
<ogra> 6291440 bytes transferred
<ogra> # wait 10 Type ^C key to cancel autoboot.
<ogra> Type ^C key to cancel autoboot.
<ogra> # boot
<ogra> there is a semicolon missing though, it doesnt wait at all
<StevenK> ogra: I wonder if this is an overrun ...
<ogra> thats why i said we should probably give the kernel one more block
<lool> CONFIG_RAMDISK_LMA=0x01000000
<lool> ogra: really?  I think it does wait one second
<lool> I had the apex prompt more than once
<ogra> it doesnt here
<lool> CONFIG_AUTOBOOT_DELAY=10
 * ogra tries again ... i might just be to slow
<lool> prompts the user and waits a specified number of 10ths of a second.
<lool> So it's 10th of a secnd
<ogra> ah, yeah, constantly hitting ctrl-c while the ramdisk loads helps
<ogra> i was expecting 10 secs :P
<ogra> silly
<lool> I know
<ogra> so while i'm at the apex prompt, anything you want from printenv ?
<ogra> startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot
<lool> ogra: Yeah, all values
<ogra> apex> printenv
<ogra> fis-drv *= nor:0x7e0000+4k
<ogra> cmdline *= console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug
<ogra> cmdline-alt *= console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug
<ogra> startup *= copy -s $kernelsrc $bootaddr; copy -s $ramdisksrc $ramdiskaddr; wait 10 Type ^C key to cancel autoboot.; boot
<lool> for bootaddr ramdiskaddr
<ogra> ramdisksrc-alt *= fis://ramdisk
<ogra> ramdisksrc *= fis://ramdisk
<ogra> kernelsrc-alt *= fis://kernel
<ogra> kernelsrc *= fis://kernel
<ogra> ramdiskaddr *= 0x01000000
<ogra> bootaddr *= 0x00008000
<ogra> apex>
<ogra> there you go
<lool> nor:0x7e0000+4k hmm
<lool> ogra: is this from debian or ubuntu?
<ogra> debian
<ogra> i cant get to the apex prompt on ubuntu
<lool> really?  that's suspicious
<ogra> no, thats logical
<lool> why so?
<ogra> the prompt comes after loading
<lool> loading of apex
<ogra> it gets stuck loading the kernel
<lool> Oh right
<ogra> i can get into the redboot prompt
<ogra> but not apex
<lool> the wait should be at the beginning
<ogra> yeah
<ogra> silly design
<ogra> though you dont gain anything being in apex anywa
<ogra> y
<ogra> the whole config is readonly ...
<ogra> you can only modify it from the running system via apex-env
<lool> Yes
<lool> ogra: setenv doesn't work?
<ogra> so i dont know why it has a prompt at all
<ogra> nope
<ogra> i tried to change the cmdline parameter before ... doesnt apply
<ogra> apex> setenv cmdline 'console=ttyS0,115200 noirqdebug'
<ogra> Environment region is unwritable
<ogra> so having a prompt is just fake
<lool> You can type commands
<ogra> right, the ones that are executed anyway
<ogra> the only most intresting thing, changing the cmdline doesnt work
<lool> ogra: You can pass cmdline to boot
<lool> "boot [-g ADDRESS] [COMMAND_LINE]\n"
<ogra> oh, i didnt know that
<lool> ogra: Perhaps you should read apex
<ogra> that makes it a bit more useful then
<ogra> yeah
<lool> So the fis://kernel works even with a split kernel
<lool> Because APEX has an extension to RedBoot partitions
<lool> To skip some areas
<lool> Check README_fis in apex' source
<lool> I don't understand why it's not copy fis://kernel@16 $bootaddr
<lool> ogra: It might be best to not rely on byteswapping the kernel but rebuild it though
<lool> amitk: Hey
<ogra> i'm just doing a build in the background with one more block shifted to the kernel
<lool> amitk: CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y is set in debian/config/armel/config.ixp4xx, but not in Debian
<lool> amitk: This needs fixing in all cases (even if that's correct)
<lool> amitk: Basically the hardware supports both, but we're an armel port and the debian tools assume a LE kernel which gets byteswapped at various places (flash-kernel, d-i)
<ogra> swapped or unswapped, it doesnt load
<lool> amitk: So it's easier to have the same type of kernel in Ubuntu
<ogra> so i expect we are exceeding the size
<ogra> hrm, the other loic suddenly hunts me in #edubuntu ... i wonder what he wants
<lool> ogra: I think I'll drop the ball here on NSLU2; if you are stuck, you could try mailing Marc Singer, he helpfully replied to me when I asked about the shim's COPYING file being missing
<amitk> lool: ack. We will stick to one type for the kernel.
<lool> ogra: If you show that you researched it that far, he might be willing to help !Debian
<lool> amitk: thanks; do you need a bug?
<amitk> lool: I guess that CONFIG option automatically gets set on selecting ixp4xx, let me check
<amitk> lool: if ARCH_IXP4XX
<amitk> config ARCH_SUPPORTS_BIG_ENDIAN bool default y
<amitk> in Kconfig
<lool> amitk: Ack; the device can do both so the upstream bit doesn't make any sense to me, but please force it to LE
<lool> amitk: Did you get your NSLU2 to work BTW?
<amitk> lool: -EOUTOFSOLDER, will head to store a bit later
 * ogra hopes amitk has a pump to get the solder out of the holes
<ogra> its really painful without
<lool> amitk, ogra: I'd love if you two could sort this out quickly; I think I understand most of it, but can't usefully research without a device
<ogra> well, let me builod a kernel if you think thats the solution
<ogra> and inject it into the di binary
<ogra> i still suspect its a size issue though
<amitk> lool: I can give you a kernel if you need
<amitk> ogra: size issue for initramfs?
<lool> amitk: I wouldn't have much use of it without a device :)
<ogra> amitk, no issue with the apex partition shufflung we do to make our kernel fit
<ogra> amitk, gimme kernel :)
<lool> amitk: The way the NSLU2 firmware is built is quite complex
<lool> amitk: Do not rely on RedBoot to do regular stuff, it hardcodes plenty of stuff and wont work correctly (can't pass cmdline, expects initrd at specific address etc.)
<ogra> amitk, the prob is that our kernel is nearly 2M big, debians is only 1.3
<lool> amitk: Debian/Ubuntu use APEX as a second state loader with some special partition mappings for redboot to be happy
<ogra> so the apex partitioning for the di binary blob needs adjustment
<lool> ogra: You could try building an image with Debian's kernel to see if that boots
<lool> ogra: It might be that one of our binaries is broken
<amitk> lool: so it was confirmed that redboot cmdline doesn't work
<amitk> ?
<ogra> lool, well, if amit has a kernel for me i'll try that first
<lool> amitk: Yes
<lool> ogra: You can try both :)
<ogra> lool, well, the kernel loads if you load it from redboot via http
<ogra> i'll try everything that can get me towards a solution indeed :)
<lool> ogra: Exactly my point, we know the Ubuntu kernel works and the Debian kernel as well; but the Debian one is smaller and not swapped
<ogra> since thats our only arch we target for jaunty ;)
<lool> ogra: You could see if that helps, if amitk's kernel doesn't work and Debian's does, then you know that the partitioning changes are wrong
<lool> If both work, then we're done :)
<ogra> well, amits kernel wont be smaller
<lool> ogra: Err yes, that's my point
<lool> ogra: Which is why I'm hinting at the Debian one? :)
<lool> Both are useful tests
<amitk> ogra: It could be with allnoconfig I guess
<ogra> oh, so you mean keep the shuffled partitions and just use debians kernel
<lool> ogra: No, you revert the partition shuffling and confirm that our d-i + apex + debian kernel and initrd work
<lool> ogra: or you keep the partition shuffling and confirm that our d-i + apex + debian kernel and initrd work
<ogra> right, but then i need to change two aspects to try out ours
<lool> ogra: or you keep the partition shuffling and confirm that our d-i + apex + amitk's kernel and initrd work
<ogra> which doesnt tell me much mor than i already know
<lool> doubt amitk will hand you an initrd though
 * amitk agrees, he hates initrds
<ogra> right, i need to do the tests both with a shuffled partitioning scheme to keep the same env
<lool> Anyway, use your logic
<ogra> i dont care about initrd atm
 * lool moves his brain to something else
<ogra> lool, so it is definately partitioning scheme it stops with the exact same symptoms using debians kernel
<ogra> i'll try to confirm by using their scheme with their kernel
<lool> ogra: it could be our APEX or whatever; you might want to try the debian kernel with the debian partitioning scheme
<lool> in our d-i with our apex etc.
<ogra> yes, thats what i'm currently fiddling with
<ogra> lool, yep. debian kernel and debian partitioning scheme works
<lool> ogra: Ok
<ogra> even with our initrd.gz
<lool> ogra: Might be slugimage not liking this change then
<ogra> yeah
<ogra> sigh ... i have to dig out my perl foo i fear
<lool> Ah got it
<lool> my($kernel_offset)  = 0x00060000;
<lool> my($kernel_size)    = 0x00100000;
<lool> my($ramdisk_offset) = 0x00160000;
<ogra> oh
<lool> That's likely the issue
<lool> IMO
<ogra> shouldnt the first one be 80000
<ogra> (additionally to the size mistmach)
<lool> Hmm be careful, these are redboot partitions, not apex partitions
 * ogra goes to try with 2M
<ogra> yeah, i wont change the kernel offset
<ogra> only size and ramdisk offset
<lool> You have a debug flag for slugimage
<ogra> hrm, just changing to 0x00200000 and 0x00260000 respectively doesnt work
<ogra> it doesnt have a ramdisk_size parameter
<lool> The kernel_size is just where to split the kernel
<ogra> oh, so just bumping ramdisk_offset should suffice
<lool> Not sure, you could try
<lool> Bump it by 5 blocks
<ogra> i will luckily the script is freindly nough to tell me if it breaks :)
<lool> 0x00200000
<ogra> oh i used 22
<lool> Perhaps I miss computed
<ogra> Ran out of flash space in <Ramdisk> - 0xA0000 bytes too large.
<ogra> nope
<lool> That's what we added
<lool> ogra: Do you have a debug run?
<ogra> http://paste.ubuntu.com/116488/
<lool> Hmm it doesn't list the skip partitions
<ogra> oh, wait i made a mistake i think ... i padded initrd twoce
<ogra> yay
<ogra> didnt choke
 * ogra waits for upslug
<ogra> ogh
<ogra> that trashed apex
<ogra> nope, no way
<ogra> what if we just cut down our kernel ?
<ogra> lool, i think slugimage is the wrong attempt
<ogra> it just makes sure the redboot markers are in the right place
<lool> ogra: I'd like to see the final partition table
<lool> it's missing from your paste
<lool>         print "after buildPartitionTable():\n";
<lool> ogra: Ideally, compare the output from debian layout wiht debian kernel with ubuntu layout with debian kernel
<ogra> because it failed :)
<ogra> it didnt get to that point, you asked for a debug output when i did a failed attempt ... one sec
<lool> I know, but the most interesting output is when the image builds..
<ogra> http://paste.ubuntu.com/116497/
<ogra> thats with unmodified slugimage but our sizes
<lool> Loader          0x00060000	0x00020000	[0x00000/0x00010]
<lool> Kernel          0x00080000	0x00200000	[0x00000/0x00010, 0xE0000/0x00010]
<lool> The right part are skips
<lool> ogra: Would be nice to have a "normal" run with debian's configs
<ogra> lool, http://paste.ubuntu.com/116499/
<ogra> comparing the two it seems to DTRT
<ogra> it properly recognizes the different blocksizes and adjusts itself
<ogra> i start to suspect its an apex limitation
<ogra> hrm, d-i fails at the hw detection step without the firmware
<ogra> which makes it pretty useless
<lool> Ok, now I know why it doesn't use fis://kernel@16 but just fis://kernel
<lool> Erf don't set ibase before obase in bc
<lool> The 0xE0000 skip is exactly on the initrd, that seems alright hmm
<lool> ogra: kernel size is too small
<lool> Kernel          0x000800000x00160000[0x00000/0x00010, 0xE0000/0x00010]
<lool> 0x00160000 is too small
<lool> our kernel is 1977064
<ogra> right
<ogra> but kernel size needs to cooperate with ramdisk offset, no ?
<ogra> or do you think just bumping it helps ?
<ogra> hmm, slugimage doesnt complain
<lool> ogra: The kernel is presumably truncated; it seems to be a bug in the perl script
<lool> ogra: Oh was looking at the Debian output
<lool> So that's correct for Debian crap
<ogra> lets see, i just bumped kernel size blindly to 0x00200000
<ogra> and padded the two files with our values
 * ogra is upsluggin ...
 * ogra has to go shopping soon, will be out for 1-1.5h
<lool> IIUC, you shouldn't have to touch slugimage; it's meant to be generic
<ogra> yeah
<ogra> and it didnt work anyway
<lool> ogra: So APEX hangs where exactly?
<ogra> same symptoms as always
<lool> After the load?
<ogra> # copy -s $kernelsrc $bootaddr
<ogra> # copy -s fis://kernel 0x00008000
<ogra>  /
<ogra> the fan animation below does oen or two rotations and then stops
<ogra> *one
<lool> I'll shoot an email to the apex maintainer
<lool> ogra: Hmm I don't understand how you achieve the ubuntu call to apex
<lool> ogra: Why does slugimage detect a changed kernel size when you're passing vmlinuz-2.6.26-1-ixp4xx.swapped in both cases
<lool> Oh nevermind, I get it
<lool> It's padded by d-i
<ogra> grr
<ogra> yes, as i suspected kernel_size has no influence at all
<ogra> no matter what value i set for it it works
<ogra> but as soon as i change the padding it breaks
<ogra> i will find out how big the kernel partition can grow by adjusting it block by block after shoppin
<ogra> g
<ogra> we'll see where it chokes then
<ogra> lool, hmm, are you aware that the apex version we use is ancient ?
<ogra> heh, the version we use doesnt even exist upstream
<lool> ogra: ohhh
<ogra> 2007.01.29 (apex-1.4.13)
<lool> ogra: Try adding one block more
<ogra> 2007.02.15 (apex-1.4.16)
<ogra> there are no .14 or .15 ones
<lool>       apex | 1.4.15.2ubuntu1 |        jaunty | source
<lool> ogra: Could you try adding one more block to the kernel and one less to the initrd?
<ogra> and we use 1.4.15.2 according to the bootmessage
<ogra> oh, you found out already :)
<lool> 1.4.15 works on Debian
<lool> and on Ubuntu with debain kernel
<ogra> one more to our scheme or debians ?
<lool> ogra: To our scheme
<ogra> ok
<lool> I think we're hitting a corner case with our value
<ogra> flashing
<ogra> now that would be cool
<ogra> what got you the idea ?
<lool> Well it seemed the ramdisk would write exactly on top of the kernel's skip
<ogra> ah
 * ogra twiddles thumbs
<ogra> resetting
<ogra> nope :(
<ogra> same symptoms
<ogra> as i said, i'll start changing it block by block until it hits the fan if i'm back
<ogra> so we see the exact limit
<ogra> lool, hmm
<ogra> lool, i dont get why colin cuts off 21bytes from the initrd instead of thw 16 debian does
<ogra> *the
<ogra> til/pad $(TEMP)/initrd.gz.nslu2 6291440 # size of partition - 16 for header .... thats debian ...
<ogra> util/pad $(TEMP)/initrd.gz.nslu2 5636080 # size of partition - 21 for header .... thats ours
<ogra> lool, sooo ... making the kernel partition one block smaller works fine
<ogra> though it panics ...
 * ogra tries if he can fit the ubuntu kernel into that 
<ogra> hmm, no
 * ogra dances !!
<ogra> err
<ogra> hrm
<ogra> argh
<ogra> ok, its officially not my day ...
<lool> ogra: He didn't cut 21 bytes but 16 and I made him fix that comment in bzr already
<lool> ogra: (earlier this morning)
<ogra> yeah
<ogra> lool, so i think what we want is CONFIG_RAMDISK_SIZE=0x004CCCC0 in the apex config
<lool> Hmm
<ogra> that gives us 5033152 bytes for the initramfs and leaves more than 1.9M for the kernel
<ogra> if my HEX foo isnt to wrong
<ogra> i'm convinced its debian bug 451882 that gets in our way
<ogra> bah, no bugbot
<ogra> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451882
<lool> ogra: Isn't it 0x0055FFF0?
<ogra> it is
<lool> It's currently 0x005FFFF0, I think we should have 0x0055FFF0?
<ogra> we have 8M ... 6291440 bytes of that get reserved for initrd
<ogra> we do
<ogra> thats the prob
<ogra> if you have 8M, cut off 6M for initrd and additionally a bit for apex and the redboot tags you end up with a bit less than 1.9M for the kernel
<lool> Why do you say CONFIG_RAMDISK_SIZE=0x004CCCC0?
<ogra> that should be 5033152 bytes
<ogra> which means we have 1258288 bytes more for the kernel partition
<lool> ogra: That's not a block multiple
<ogra> 6291440 isnt one either
<lool> ogra: We changed the size of the initrd by 5 blocks of 131072
<lool> ogra: So we need to change it by 655360 bytes, 5FFFF0-A0000 = 55FFF0
<lool> Where did you find 6291440?
<ogra> read the bug
<lool> ogra: It's certainly not our bug as we hang in the kernel copy
 * lool curses at bc
<lool> 55FFF0 is 5636080 but 005FFFF0 is 6291440; piece of crap
<ogra> i'm able to boot with a kernel area of 15 blocks with the debian kernel
<ogra> it stops working if i go up to 16 blocks which is the first time i get over 1.9M for the kernel partition
<lool> But we don't want CONFIG_RAMDISK_SIZE=0x004CCCC0 but 0x0055FFF0
<ogra> thats what we currently have
<ogra> and which results in 6291440 bytes
<ogra> as the reserved flash space for the ramdisk
<ogra> which in turn limits the free space we have for the kernel to less than 2M
<ogra> since the overall space we have is 8M
<ogra> and we lose space for apex and the redboot tags in the image
<lool> ogra: I don't understand
<lool> ogra: What we have right now is 005FFFF0
<lool> I say we want 0055FFF0
<ogra> oh ... sorry, my eyes saw to many HEX today
<ogra> :P
<lool> hmpf
<ogra> i didnt see the second 5
<ogra> ok, i'll do a testbuild of apex with the change lets see if i get it booting then
<ogra> sorry for being so dense ... i really cant see any hex anymore
#ubuntu-arm 2009-02-11
<lool> ogra: So this smells the overflow if 15 -> 16 blocks don't work
<lool> It's not, it's APEX being clobbered by the kernel!  :-)
<lool> ogra: Quick, try Marc's suggestion!
<ogra> lool, if my eyes are open enough :)
 * ogra yawns and goes to look for coffee
<lool> ogra: Dude why did you mail debian-arm@?
<lool> I told you I would mail him and I Cc:ed you
<ogra> whats wrong with asking in multiple places ...
<lool> It creates duplicate work?
<ogra> and brings more ideas in in case the solution isnt clear
<lool> I absolutely hate IRC users coming to multiple channels I'm in and copy-pasting the same question
<lool> Sorry but it's resource abuse
<lool> I value the high quality of the responses I get so far, I don't think Marc will give us much attention if we keep asking at multiple places
<lool> It's exactly like researching before asking
<ogra> well, to me it wasnt clear it was apex
<ogra> apart from that the next guy having this prob will find it in the ML archive
<lool> That's an issue I created, but your fix is worse than the disease
<lool> It's like these cross-posts spanning multiple lists, but it's worse in that these are separate threads
<ogra> well, sorry for that if you feel like that, but i still think it was okayish to have it on a public ML my questio was different and contained other information than yours, but i'll keep away from such things in the future now that i know you dont like it
<lool> I basically don't want to take any chance to piss off valuable people we rely on (how would we move forward if we lose help from these folks?)
<lool> And here Marc had to reply to both and said he did
<lool> Probably he doesn't mind much, I'd hate if we'd do that again
<lool> s/doesn't/didn't
<ogra> right, i'll be more cautious about that in the future ...
<lool> Thanks, I appreciate your effort
<ogra> lool, hmm changing CONFIG_KERNEL_LMA=0x00008000 to 0x01000000 means that it will have the identical address CONFIG_RAMDISK_LMA has ...
<ogra> i suspect we need to do some more math with that ... but will test first
 * ogra goes to rebuild apex
<ogra> lool, well, it doesnt boot ...
<ogra> ... but it get kernel and ramdisk loaded
<ogra> lool, http://paste.ubuntu.com/116755/
 * ogra starts shuffling the ramdisk address around
<ogra> hmm, so moving the ramdisk to 0x011FFFE0 les it panic but the kernel unpacks ....
<ogra> *lets
<ogra> bah and our kernel stops after uncompressing
<ogra> (using it unswapped, else it doesnt work at all)
<ogra> hrm
<ogra> lool, any idea ? the kernel is 0x00200000 big, so i add that to CONFIG_RAMDISK_LMA (making it 0x01200000) that makes the kernel load but apparently it doesnt find the initramfs and panics now
<ogra> intrestingly it seems to find the start of the ramdisk ... "[42949378.630000] RAMDISK: Compressed image found at block 0"
<lool> ogra: Sorry didn't follow; do you have an idea of the memory map since the board powers up down to apex calling into the kernel?
<lool> I would start by writing that down
<ogra> well, when i move the kernel from 8000 to 1000000 i need to move the ramdisk up by the size of the kernel
<ogra> since the ramdisk used to live at 1000000
<ogra> so the kernel occupies 1000000 to 1200000 (as its 200000 big)
<ogra> so naturally the ramdisk load address needs to be 1200000
<ogra> HA ! lool !! got it :) indeed we also need to adjust the max size of the ramdisk, it boots with CONFIG_RAMDISK_SIZE=0x00400000
<ogra> i'll try to bump that up bock by block now to find the possible max limit, then we should be done ... only a fixed eb kernel is missig
<lool> Right, kernel is being loaded at 0x00008000, ramdisk at 0x01000000
<ogra> right, now kernel is 0x01000000, ramdisk is at 0x01200000 and ramdisk size is 0x00400000 ... with these values it boots just fine
<lool> ogra: That's only 2M for kernel
<lool> ogra: Where is the kernel unpacked?
 * lool lunch &
<ogra> erm, its unpacked in ram, these values are flash
<ogra> its only about the flash partitions apex uses
<ogra> err, strike that
<ogra> apex assigns 8M in ram it seems and then copies itself and the flash partitions to that area
<ogra> why would you want more than 2M for the kernel ?
<ogra> all former debian kernels are below 1.5M and i expect us to still drop some bload from the 1.9M we have now
<ogra> *bloat
<lool> ogra: ??
<lool> ogra: isn't 0x00008000 the address where to copy to?
<lool> ogra: The flash read address is fis://kernel, the RAM write address 0x00008000
<ogra> yeah, ignore me
<lool> ogra: "why would you want more than 2M for the kernel" well we just hit the case where the preceeding assumptions were not enough
<ogra> i thought we had the 8M limit in ram as well, but that doesnt seem to be the case at all
<lool> Why not make sure we cover all cases and solve the problem once and for all?
<lool> slugimage works no matter what sizes you pass to it for instance
<ogra> yes, i just booted with a ramdisk at 0x01400000
<lool> So if the contents are discarded, I'd recommend loading apex, kernel, and initrd at 0, 8M, and 16M
<lool> that way we shouldn't ever have to worry about them
<ogra> i'm just trying with 6M for the kernel
<lool> The flash is 8M right?
<ogra> i'll do 8 next
<ogra> yes
<ogra> so the bigger the kernel gets the more we limit ourselves on the ramdisk wrt flash ...
<ogra> lool, ok, seems the max limit for the ramdisk size is actually 5636080 bytes (our flash ramdisk partition size ...) if i go above it it corrupts the initrd ...
<ogra> and it seems it doesnt matter where i load it to so 0 and 8M wont be an issue, but 16M wont be possible due to the 8M flash constraint
<lool> ogra: I want us to plan the apex script to accept any theoritical initrd or kernel sizes
<lool> And apex' builtin defaults
<ogra> not for jaunty though
<lool> Why not?
<ogra> that really requires deep apex tinkering and a proper spec imho
<ogra> feature freeze is in 8 days
<lool> So you prefer learning it all, implementing a workaround, then having to learn it all again to fix it properly or simply not bother to fix it properly?
<ogra> no, i prefer to have sane defaults for now and to add additional features if we have time for that
<ogra> i havent touched the touchscreen issues at all yet, we dont even have a working kernel for the slug etc etc ...
<lool> Why would a ramdisk size larger than 5636080 corrupt the initrd?
<lool> I hate leaving things half fixed when we can fix them properly
<lool> This is seriously not fun for me to invest so much time on an issue and then look back and think "I didn't really fix it"
<ogra> i guess thats a question for marc ... using any bigger size than the one we padded it to simply results in a panicking kernel
<lool> I think I shouldn't have looked at this issue at all, it's too frustrating, we don't have the same goals
<ogra> right, so do you want me to drop all my specs for supporting an arch nobody uses ?
<lool> I guess it depends how much time you think you need to fix it properly versus implementing a workaround
<ogra> the only committment i have atm is to get a working d-i image for that thing
<ogra> which i have now module a decision on the proper default values for apex
<ogra> and a working kernel ... which isnt in my hands
<ogra> lool, moving the apex VMA adress to 3MiB seems to work as well as shuffling kernel and rmadisk adresses, given that we differ in only one value from debian here (and will likely be able to convince tham to accept that as default) i'll g with that ... the ramdisk size propblem persists though and i think its likely due to the fact that apex tries to assign a memory area but the ramdisk image itself doesnt fill that up with zeroes as soon as the apex va
<ogra> lue is bigger than the actual partition ... values between the actual initrd.gz size up to the padded partition size do work well, i'll ask on debian-arm to get a confirmation from marc about the theory
#ubuntu-arm 2009-02-12
<pwnguin> is there a list of ftbfs for arm?
<pwnguin> the wiki has one last updated in like november
<prpplague> davidm: ping
<prpplague> Mirell: greetings
<Mirell> 'allo
<ogra> jldugger, http://qa.ubuntuwire.com/ftbfs/
<amitk> ogra: just finished reading the massive scrollback from yesterdays apex debugging. Impressive work!
<amitk> ogra: So it seems it isn't a kernel problem?
 * amitk starts to read up on apex a bit
<ogra> amitk, well, upstream answered my last mail on debian arm ... where i said "hello, my kernel panics if i choose more than 5M for the ramdisk size" ... with "yes, you can use up to 8M for the ramdisk"
<ogra> its not all solved yet, but i have a workaround for now
<ogra> whih i intend to upload so we get working daily builds as soon as there is a kernel ... but its something we surely need to revisit
<ogra> *which
<amitk> ogra: re: as soon as there is a kernel?
<ogra> the kernel corruption thing itself is solved ...
<ogra> amitk, our endiness is wrong
<ogra> *endianess
<amitk> ogra: ah right, i'll get that fixed
<amitk> anything else you need in the ixp4xx image for this upload besides endianness?
<ogra> and if i use the kernel not swappped with devio it stops after unpacking (not sure thats related to endianess mistmatches with apex, kernel and initramfs but i suspected so
<ogra> only the NIC firmware ... doing a netinstall without NIC is quite tricky ;)
<amitk> and that will be required for d-i too
<ogra> right, but d-i builds udebs from linux-firmware
<ogra> just a matter of adding the right udeb to the netinstall image
<ogra> i might have kernel changes afterwards though, i couldnt test our kernel at all yet
<ogra> (i.e. i dont know how it bevhaves in an installed system ...)
<ogra> lool got it to boot directly from redboot during the sprint (which is why i suspect the non booting to just be an endianess issue in d-i) but we werent able to change the cmdline in redboot as everything at that stage is readonly
<ogra> amitk, did you get your serianl port to work ?
<ogra> *serial
<amitk> ogra: removing the solder blobs is being a problem, i've got to go and get a desoldering braid
<ogra> yeah, though davidm managed to just blow it out of the holes, i had to use a pump
<amitk> blowing it sounds dangerous, though he has a ton more experience than I do
<alesan> hi
<alesan> I have this board with an ARM, 128MB of memory, USB, ethernet, serial, VGA, audio, PS/2; I wrote all the drivers. Can I run Ubuntu on it?
<ogra> sure
<ogra> see the last link in the topic
<alesan> well
<alesan> I think my board is not a ready target
<alesan> it will require the proper drivers for example
<alesan> even an headless image would require my ethernet drivers
<alesan> or - maybe I'm mistaken and this rootfs does not contain the kernel
<ogra> right, its only the userspace
<ogra> if yu have a kernel, use that, if you can push your drivers upstream to kernel.org we can fully support your board in jaunty+1
<alesan> yeah :) that would be nice
<alesan> just as an information, when is likely to be the "freeze" for j+1 ?
<ogra> hard to predict, the j+1 schedule will only be finalized at the next developer summit ... which is in may
<ogra> jaunty releases in april ... feature freeze for jaunty is next week
<ogra> feature freeze is usually the point where stuff like that needs to be in ... given that j+1 will happen in october it might be around august
<alesan> yeah but it is hard by that time my drivers will be in an official kernel release
<alesan> it's a lot of stuff in many subsystems
<ogra> well, if you can get them into .29 or .30 we'll get them for free from upstream
<ogra> then supporting your HW is a non issue, just a matter of enabling the .config
<alesan> yeah
<alesan> listen as a side question
<alesan> openoffice is actually running on ARM?
<ogra> on some HW, yes
<ogra> i doubt you will get it running properly on 128M though
<alesan> do you have an idea of the requirements?
<ogra> it will *run* but not be fun
<alesan> or an hardware that is known to run it? just as comparison with what I have here on this board
<ogra> if you want to support ubuntu-desktop including firefox and openoffice your HW should have above 256M and above 500MHz
<alesan> yeah :) it's a pity, I remember when I was able to run office97 on a 16MB PC :( nowadays 128MB are too little
<ogra> i doubt there is any HW public yet
<alesan> ah ok
<ogra> http://www.notebooks.com/2009/01/07/new-generation-of-netbooks-199-and-299-eight-hour-battery-sexy-design/
<ogra> something like that will likely run ubuntu-desktop incl. openoffic fine
<alesan> by the way, what about Koffice, it used to be lighter than OOo
 * ogra hasnt tried any QT based stuff on arm yet
<ogra> i know xubuntu and gcoffice work fine though
<ogra> even on the beagleboard i have if i add some swap and a USB disk
<ogra> (so that IO times are not to huge)
<alesan> gcoffice = ?? I only found a german cheese office with that name :)
<ogra> abiword and gnumeric
<ogra> the actual so called "gnome office"
<alesan> the moment you create this rootfs... what format is that? it is likely the way to mount it is with a USB key right?
<ogra> alesan, its a tgz that you csn untar on any kind of partition (given it has the right size)
<ogra> *can
<ogra> if you use the --notarball option it will create a qemu image instead
<ogra> so you can play with it in qemu-system-arm
#ubuntu-arm 2009-02-13
<Meizirkki> KDE 4.2 on Nokia n810: http://picasaweb.google.com/meizirkki/MerOnN810#5300841488593994434
<Meizirkki> it runs "ok", but is there any tricks to make it faster?
<persia> Meizirkki, The usual recommendation is to add more memory, but that's not easy for that device.  Is it thrashing, or is there some specific part that is slow?
<Meizirkki> well, it runs somehow without swap, and 256mb swap makes it usable... it's just slow to use.
<persia> Hard to say if it's too many instructions, or not enough working space.
<persia> You might try asking in #kubuntu to see if anyone has any general KDE speed-up tricks.
<Meizirkki> ok, thanks :)
<Meizirkki> i'm surprised that it kde itself only takes about 110 mb memory.. but it's just hungry for cpu-power
<persia> There's been a lot of work with KDE to try to keep the footprint down: it's not just for handhelds that it makes it feel faster :)
<Meizirkki> yes, i remember how ugly kde 4.0 ran on my old pc
<Meizirkki> kde 4.2 is a lot faster
<Meizirkki> :P
<Meizirkki> is jaunty using Qt 4.5??
<persia> 4.4.3
<Meizirkki> k
<Meizirkki> ppl @ #kubuntu said Qt 4.5 would make things a lot faster
<persia> Well, they should get the kubuntu-ninjas to upload it if they think so :)
<Meizirkki> yeah, they also said it's a bit crashy ;)
<persia> Ah, that explains why :)
#ubuntu-arm 2009-02-15
<ian_brasil> just ran build-arm-rootfs and it worked but gave a couple of error messages
<ian_brasil> arm_script build-arm-rootfs build.sh Setting kernel variables (/etc/sysctl.d/10-network-security.conf)... [80G error: "net.ipv4.tcp_syncookies" is an unknown key
<ian_brasil> [74G[[31mfail[39;49m]
<ian_brasil> arm_script build-arm-rootfs build.sh Setting kernel variables (/etc/sysctl.d/10-process-security.conf)... [80G error: "vm.mmap_min_addr" is an unknown key
<suihkulokki> no hwcap-optimized libs in ubunut-arm yet?
<Stskeeps> debian moving anywhere in that area yet?
<suihkulokki> Stskeeps: now that lenny is out, it a good time to look at it. I was looking if I were lucky and ubuntu had already done it, but no such luck today ;)
<Stskeeps> i'm eagerly awaiting any work :P
<ogra> well, lets take that here :)
<ogra> running KDE or GNOME on less than 256M is really adventurous :) and there isnt much arm HW yet with more ram out there
<ScottK> Tscheesy_: ^^^
<ogra> though the 256M beagleboard is due soon
<ScottK> Dunno what he has excatly...
<ogra> (on the 128M version even xubuntu is painful)
<ScottK> Tscheesy_: What are you running?
<ScottK> Also we haven't made any armel specific changes to our desktop, so there may be stuff we're flat out missing.
<Tscheesy_> re
<Tscheesy_> actually i'm trying to build kubuntu-desktop on Jaunty
<ogra> probably
<ogra> NCommander cared most of the time for KDE on armel
<ogra> i dont know much about it nor did i test it yet
<ogra> Tscheesy_, why ? isnt the version in the archive not working that you try to build it yourself ?
<ogra> the only think i see on http://qa.ubuntuwire.com/ftbfs/ is kpackagekit
<Tscheesy_> ogra: i need the Root-Fs because i can't get it on my Openmoko otherwise
<ogra> see the topic ;)
<ogra> last link
<Tscheesy_> yes - there i got following fatal
<Tscheesy_> FATAL: Could not load /lib/modules/2.6.28-6-versatile/modules.dep: No such file or directory
<ogra> thats fine
<ogra> all stuff you need for the versatile kernel is builtin
<ogra> so modules arent needed
<Tscheesy_> hmm.. computer ist szcuk for a while
<ogra> (you can indeed install linux-versatile in the rootfs if you feel like, but that wont run on any real HW anyway, its a qemu kernel)
<Tscheesy_> stuck
<ogra> the script calls qemu to exec the stuff inside the chroot, so its very slow
<Tscheesy_> k.. sounds good
<Tscheesy_> btw is there a jaunty uImage for gta-02 ?
<ogra> if it really fails it will tell you
<ogra> and if it does, please keep the log and tell me ;)
<ogra> nope
<Tscheesy_> ok
<ogra> the only HW we support in jaunty are versatile (qemu and if you still find such an old board the actual versatile HW) and the nslu2
<ogra> for all others you need to build your own kernel atm
<ogra> jaunty+1 will be better in that regard
<Tscheesy_> k.. even debian proposes a way to build in the Device-Supplier uImage
<Tscheesy_> do you have a link HowTo build a Boot Image for uBoot?
<Tscheesy_> do i need my HW-Settup in a VM for this?
<ogra> you should have a qemu build env
<Tscheesy_> ogra: i have for /fs-from-scratch - so i get a uImage.bin out of the Build? ;) would be nice :D
<ogra> right, just log in to it and you can build anything you like ;)
<ogra> install openssh-server on the host, then you can scp files back and forth (look at the default route inside qemu to find the ip for teh host from qemu)
<Tscheesy_> ok.. sounds for reading.. first i will try the community uBoot with some root-fs changes..
<ScottK> Tscheesy_: If it turns out there are packages you need that aren't in the default install for arm, let me know and I can get it changed.
<ogra> ScottK, kpackagekit seems to need some attention
<ogra> but i'm sure NCommander will take a look
<Tscheesy_> ScottK: thounds cool but i'm not that far :|
<ScottK> ogra: It does, but currently packagekit ftbsf on arm.
<NCommander> a look on what?
<ScottK> NCommander: The packagekit ftbfs we talked about yesterday.
 * NCommander is currently hooking up his babbage board, but still feeling like death
<NCommander> Oh yes
<NCommander> Its still on my todo list
<ogra> ScottK, heh, i didnt scroll down balow K :P
<ogra> *below
<ScottK> NCommander: Also there's a different one on ia64 you may as well fix at the same time ....
<Stskeeps> babbage board? :P
<Tscheesy_> ogra: btw - HW Memory-Support.. i hope for /dev/ttyACM0
<Tscheesy_> on the host i hope it enlarges the device environment
<Tscheesy_> workaround for Android by the community
<ogra> it doesnt, host and client are distinct
 * ogra has to go afk again ... 
#ubuntu-arm 2010-02-15
<koalo> hi
<koalo> i tried to build a rootfs for qemu but everytime i get a Kernel panic - not syncing: Attempted to kill init!
<persia> How are you trying to build the rootfs?
<koalo> like in https://wiki.ubuntu.com/ARM/RootfsFromScratch
<koalo> sudo rootstock --fqdn ubuntu --login ubuntu --password ubuntu
<koalo> and then mkdir /tmp/arm
<koalo> sudo mount -o loop /tmp/arm.img /tmp/arm
<koalo> cd /tmp/arm
<koalo> sudo tar xzvf ../qemu-arm-rootfs.tgz
<koalo> cd ..
<koalo> sudo umount /tmp/arm
<koalo> rm /tmp/arm
<koalo> qemu with
<koalo> sudo qemu-system-arm -M versatilepb -kernel /tmp/vmlinuz-2.6.28-versatile -cpu arm926 -hda /tmp/arm.img -m 256M -append "root=/dev/sda mem=256M"
<persia> That certainly looks right.
 * persia tries
<koalo> oh and qemu-img create arm.img 1G
<koalo> sudo mkfs.ext2 -F arm.img
<persia> I seem to be bumping into a bug that prevents rootstock from running at all today.  Sorry.
<persia> Someone else may have to help.
<koalo> thanks anyway!
<koalo> the rootfs from http://people.canonical.com/~ogra/arm/qemu/qemu-arm-rootfs.tgz works....
<koalo> i give up for today
<koalo> bye
<DanaG> interesting... bootchart doesn't do anything on arm.
<DanaG> Nor does ureadahead.
<DanaG> Probably doesn't need to do anything, though.
<Martyn> wait, ureadahead should work!
<Martyn> it should be prepopulating the cache
<Martyn> Did we forget to add the patch into the arm branch of the kernel?
<DanaG> Then again, my ureadahead doesn't work on my host amd64 system, either... terminates with status 4.
<DanaG> =Ã¾
<DanaG> So maybe I'm just unlucky.
<DanaG> hmm, /var/lib/ureadahead/ has just debugfs; no "pack".
<DanaG> Also, my thing isn't using an initramfs, and update-initramfs does nothing.
<DanaG> http://pastebin.com/fc125c14
<DanaG> that is:   bash -x `which update-initramfs` -u -k all
<Martyn> Yeah, I'm only just starting to work with initramfs/initrd for arm server
<Martyn> it will be a while before I walk the entire chain
<DanaG> Plus, initramfs needs u-boot to know what to do with it, also.
<DanaG> As it is, the kernel has to come from elsewhere -- I went here: http://rcn-ee.net/deb/kernel/beagle/
<DanaG> Are there any plans to have standard in-repo kernels for various boards?
<Martyn> no
<Martyn> at least, from what I saw, only the supported processors on their test platforms for now
<Martyn> Marvell Dove
<Martyn> etc
<Martyn> etc
<ogra> does anyone have additional ideas what should be on the rootstock gui for its first iteration ? http://people.canonical.com/~ogra/rootstock-gui.png
<ogra> asac, ^^^ ?
<asac> ogra: make the image size typable ;)
<ogra> pfft
<asac> ogra: whats the "run tasksel" button
<ogra> well, beyond that, any options you would like to see ?
<asac> if you click there it instantly runs tasksel?
<ogra> it fires up the tasksel gui
<asac> so right when clicking?
<ogra> http://people.canonical.com/~ogra/rootstock-tasksel.png
<ogra> its a separate window
<asac> k
<ogra> asac, http://people.canonical.com/~ogra/rootstock-gui.png more happy with that ?
<asac> ogra: can one type
<ogra> (the file menu has a save profile/load profile as well)
<ogra> indeed
<ogra> well, you will, thats all mockup atm
<asac> ogra: seed url doesnt work?
<ogra> no, thats not in the script yet either
<asac> kk
<ogra> something for L+1
<asac> image size -> implies we create a real image now?
<ogra> no, should i call it rootfs size rather ?
<asac> rootfs max size
<asac> ?
<asac> why do we need that? cant we do an estimate?
<ogra> its one point i would even like to automate, but that smells like a huge amount of code to compute it in advance
<asac> guess not ;)
<asac> right
<ogra> also L+1 :)
<asac> but cant we say: 4GB by default?
<ogra> no, people that do ubuntu-minimal will only neeed 500MB
<asac> but that space isnt wasted
<ogra> i dont want to waste more diskspace than needed
<asac> its just temporary right=
<asac> ?
<ogra> its used during build
<asac> right
<ogra> so your host definately needs that amount
<asac> we can take as much as the file system has ;)
<ogra> no, that would strictly bind to the filesystem
<asac> run a check before build if /tmp partition has more than 4GB ... if so acquire it, other pop up a dialog and ask user to select a smaller guess ;)
<ogra> i want to preserve the funstionallity that you can use the script without a FS
<asac> without a fS?
<asac> FS?
<ogra> without a target partition
<asac> how can a rootfs work without a filesystem?
<ogra> the script should still go on to produce tarballs
<asac> i dont think i understand you. keep the option ;)
<ogra> as well as the gui ...
<asac> i know
<ogra> only if you fill in the bottom option to write to target partition we actually have a size
<asac> i am saying. if your local /tmp partition has more than 4GB size, use that as image size
<asac> otherwise ask :)
<asac> but i see that its not accurate
<asac> maybe "grow-on-demand"?
<asac> guess thats harder
<ogra> yes, thats quite hard the stages are to disconnected
<ogra> i would go with a hard 4G for the gui ...
<ogra> given that when you run the gui you really should make sure to have enough build space
<asac> anyway. i think we should set the image size to a reasonable default and move it from the top
<asac> i think i just care so much because i would expect the top most option to be quite important
<ogra> the prob is what happens if a user is insane enough to pick kubuntu-debsktop, ubuntu-dekstop, xubuntu-desktop at the same time
<asac> right
<asac> lets move it down
<asac> and use a reasonable default (e.g. 4 or 2 GB)
<ogra> 4 then
<ogra> thats definately safe for most operations
<asac> also name it (build space) or something
<ogra> with a minimal size coded in the spinbutton
<ogra> i.e. 0.5 G
<asac> i dont care about minimal size ;)
<ogra> well, the actual build space is a bit more than the image size
<asac> doesnt matter ;) ... name it: rootfs build area
<ogra> (kernel Packages file etc... but that should be in the megabytes
<ogra> ok
<asac> what is in datei ?
<asac> in the menu?
<ogra> load profile/save profile and quit
<asac> ok
<ogra> to load/save the set of options you picked
<ogra> asac, reload :)
<asac> ogra: good ... maybe in (TEMP) in brackets
<asac> ;)
<asac> but its ok
<ogra> yeah, thats easy to add when i code that stuff ... its currently all glade to get a grasp of the layout i want
<ogra> for mockups there is nothing better than glade :)
<asac> oh wasnt there the idea to also allow adding .deb files?
<ogra> yes, thats for later though
<asac> k
<asac> only one additional mirror?
<asac> or a list of?
<ogra> one for now
<ogra> the mirror stuff can definately need some extra love later (i'll turn that into post FF bugs) currently it needs to be a properly set up ubuntu archive
<ogra> i'd like to make it handle PPAs as well but that needs some extra gpg fiddling in the code thats not there yet
<asac> i think its ok ;)
<asac> just wondered if a syntax like in pbuilder is allowed
<asac> that allows you to specify more than one mirror in one line iirc
<ogra> well, that can surely be added... just a check for comma in the argument and split accordingly
<ogra> heh, i just wanted to point jamie to commanet #3 on http://ograblog.wordpress.com/2010/02/15/the-shiniest-and-fastest-arms-ever-in-ubuntu/
<ogra> i guess he knows why he just disconnected :P
<dmart> Hi guys, can you remember who was looking at the Thumb-2 issues in gmp?  Was it dyfet?
 * ogra thinks so
<ogra> but you might not catch him today (national holiday in the US)
<lool> dmart: According to https://bugs.launchpad.net/bugs/513732 he was assigned shortly
<ubot4> Launchpad bug 513732 in gmp (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged]
<dmart> thanks
 * jmc93739653 finds himself in the role of a sterotypical American, as he didn't know it _was_ a holiday in the US today.
<Martyn> bank holiday though
<Martyn> most businesses are open
#ubuntu-arm 2010-02-16
<DanaG> Feb 15 23:02:44 beagleboard NetworkManager: <WARN>  device_creator(): /sys/devices/platform/musb_hdrc/gadget/net/usb0: couldn't determine device driver; ignoring...
<DanaG> argh, so I can't use NM on the onboard usbnet.
<DanaG> anyway, I've set the beagleboard up to be dhcp server now, instead of client.
<DanaG> That's consistent with what WinMobile does, at least.
<lool> apw: Hey
<lool> apw: So I discussed linux-versatile on ubuntu-mobile@
<lool> apw: See <20100211101825.GA5444@bee.dooz.org>; had a reply from ogra
<lool> apw: I think it's helpful to provide udebs and a meta
<lool> apw: Do you want a bug report?
<lool> or two rather
<apw> bug report yes please
<lool> apw: lp #522516 and lp #522515
<ubot4> Launchpad bug 522516 in linux-meta (Ubuntu) "linux-versatile meta (affects: 1)" [Undecided,New] https://launchpad.net/bugs/522516
<ubot4> Launchpad bug 522515 in linux (Ubuntu) "linux-versatile udebs (affects: 1)" [Undecided,New] https://launchpad.net/bugs/522515
<lool> apw: Also, just an unrelated heads up on lp #522308 which I filed and probably went under the radar when moving to 2.6.32
<ubot4> Launchpad bug 522308 in linux (Ubuntu) "linux-source-2.6.32 is empty (affects: 1)" [High,New] https://launchpad.net/bugs/522308
<apw> no i suspect i broke that when i did the abstraction simplification
<Sleep_Walker> hello ubuntu people
<Sleep_Walker> I'd like to ask about Sharp PC-Z1 Netwalker a bit
<Sleep_Walker> does anyone here knows about this device?
<lool> Sleep_Walker: Some people here do, yes
<Sleep_Walker> 1] is it based on some babbage board?
<lool> Babbage is the name of the reference design boards from freescale used for development purposes
<lool> It's based on the same SoC, but it's a different board
<Sleep_Walker> I see
<lool> for instance it has no NIC, one USB port, no MIC jack so it's different from the babbage boards
<Sleep_Walker> 2] is someone working on merging drivers to upstream Russel's kernel?
<ogra> someone upstream imx51 drivers where appropriate
<ogra> *upstreams
<lool> Sleep_Walker: ATM, I am not sure that any imx51 SoC based board boots with an upstream kernel, so that would need to happen first; the kernel trees are hard to merge for various reasons
 * ogra doesnt know how big the portion beyond general basic mx51 stuff is though
<lool> IIRC, there were some people working on getting at least the basic boot stuff working for imx51 upstream, but that's a long way to go until we get to things like wifi or video drivers...
<amitk> Sleep_Walker: it will boot with a 2.6.34, I've pushed the base mx51 code upstream
<Sleep_Walker> and where are these people gathered? (mailing list, irc, forum...)
<amitk> but there's a LOT to be done, in case you're looking to help
<Sleep_Walker> amitk: yeah, I had something like that in my mind...
<Sleep_Walker> (if there will be time)
<Sleep_Walker> I noticed your patches so I was curious
<Sleep_Walker> unfortunately I don't know much about Netwalker's HW
<Sleep_Walker> only that I was able to read from sources and from running system
<amitk> Sleep_Walker: Just hang out on #ubuntu-kernel if you need some help and on linux-arm-kernel otherwise
<persia> amitk: You pushed the Netwalker code upstream?
<amitk> persia: Babbage base code (serial port, timers, clocks)
<persia> Ah.  Do you know if anyone is pushing the Netwalker patches?
<persia> lool: There's actually two USB ports : one full-size, one mini.
<Sleep_Walker> is it OTG capable?
<Sleep_Walker> and can that be charged from USB?
<amitk> persia: Netwalker is the pegatron stuff?
<persia> amitk: Not at all (why does everyone think this?)
<ogra> heh
<amitk> persia: too many codenames...
<persia> Sleep_Walker: The mini port looks like an OTG port, but I haven't tried to use it, actually.
<amitk> with no context
<persia> Yeah, well.  Netwalker is it's own beast.  There's kernel patches for the kernel that shipped, but I haven't heard about anyone porting them to newer kernels or pushing them upstream.
<Sleep_Walker> persia: I tried to connect it with PC with no success
<lool> persia: Well true, I meant one full size one compared to 4 on babbage boards
<amitk> persia: is there a public git tree for the sources? Who did the kernel? What company made it?
<lool> Both have mini-USB ports
<persia> Sleep_Walker: I don't believe the USB Gadget driver is included in the shipping kernel: you might need to fiddle the kernel configuration.
<Sleep_Walker> and that is the problem - I wasn't able to find any comunity about this device
<persia> amitk: Not git, but there's a public apt-get source repo.
<persia> (I heard the Netwalker kernel devs don't use git)
<lool> amitk: netwalker is a sharp device
<persia> Sleep_Walker: The community is almost entirely local.  The device has seen very little adoption overseas.
<Sleep_Walker> persia: I saw some SW support but I wasn't sure about HW support
<persia> Sleep_Walker: Aside from accellerated audio/video codecs, everything seems to be open-source.
<amitk> persia: and their kernel is based on freescale's SDP?
<lool> http://www.ubergizmo.com/15/archives/2009/08/sharp_netwalker_unveiled.html
<persia> amitk: I don't know precisely.  When it comes to kernels, I'm just a user :)
<persia> That's not quite right.  It's 10 hours JEITA, which means 5-7 depending on load.
<amitk> persia: if you can point me to the source, I could have a quick look when I have some time.
<persia> Sharp just released a new "Dictionary edition" in the past couple weeks.  The specs seem about the same (just different software load), but all the samples at the shop were password-locked, and I didn't want to try to hack them.
<persia> amitk: Sure.  Let me dig up what I have.
 * persia fusses with apt sources
<persia> amitk: If you find it's not terribly hard to get up-to-date kernels, I'll give you one :)
<persia> amitk: http://netbook-remix.archive.canonical.com/updates/pool/public/l/linux-fsl-imx51/linux-fsl-imx51_2.6.28-15.50fsl1araneo19.dsc
<persia> That's from January.  I'm unsure if there's a newer one on the new "Dictionary Edition" devices.
<persia> But that's definitely enough for basic HW enablement.
<Sleep_Walker> psi died - sorry - did I miss something?
<persia> Sleep_Walker: I posted the URL to kernel sources for the Netwalker.  Dunno if those are useful to you.
<persia> Nothing else meaningful.
<Sleep_Walker> persia: does it differ from the ones I get with apt-get source
<Sleep_Walker> or from the one provided by sharp?
<persia> Don't think you.  You're getting linux-fls-imx51 2.6.28-15.50fsl1araneo19 ?
<persia> s/you/so/
<persia> But I haven't checked the uname on the newest edition, so I don't know if there's a new kernel available from Sharp.
<Sleep_Walker> ....araneo18
<Sleep_Walker> I don't think so
<Sleep_Walker> and I thought I bought finaly device for work and not to hack :b
<amitk> persia: I don't see any 28-15.50 at http://netbook-remix.archive.canonical.com/updates/pool/public/l/linux/
<persia> amitk: `dget http://netbook-remix.archive.canonical.com/updates/pool/public/l/linux-fsl-imx51/linux-fsl-imx51_2.6.28-15.50fsl1araneo19.dsc` should get you want you want.
<persia> It's in the linux-fsl-imx51 subdirectory.
<Sleep_Walker> ok, I'll try to create wiki page about Netwalker (sorry, but not ubuntu one) to gather informations and possible community around Netwalker
<Sleep_Walker> thanks for all your help
<Sleep_Walker> bbl from work
<persia> Sleep_Walker: Please share the URL when you get it together.
<ogra> Sleep_Walker, if you create one, can you point us to it so we can at least link it from the ubuntu wiki ?
<Sleep_Walker> of course
<Sleep_Walker> I don't want to split efforts around t
<amitk> persia: so it's called erdos...
<Sleep_Walker> I'lll put it on hackndev.com - distro neutral area :)
<persia> amitk: erdos?
<amitk> persia: the board is called erdos in the kernel tree
<persia> Ah.
<amitk> and from a 5s look, the patches that I pushed upstream ought to be able to boot on it (given that IO mappings are identical to babbage)
<persia> So I should be able to boot a babbage kernel?  I can test with lucid if you like.
<Sleep_Walker> erdos is name of Netwalker's board in kernel?
<lool> persia: I don't think so, the bootloader board id needs to match
<persia> lool: That's a bootloader thing or a kernel thing?
<amitk> persia: naah, it'll require a tweak or two, but the kernel should probably be 99.99% identical
<lool> Plus the board support file will try to load drivers at various I/O addresses where you might miss devices or have other ones, for instance the netwalker has builtin wifi and not babbage etc.
<ogra> persia, upstream, not lucid
 * persia is *not* overwriting the nice dual-boot support redboot
<amitk> lool: we're talking about the upstream (minimal) babbage kernel
<Sleep_Walker> you can do it on kernel side
<persia> lool: wifi is through separate modules.
<lool> persia: The kernel needs to grow a new netwalker board file with the proper board id and this file needs to be tweaked to list the proper devices
<lool> amitk: I'm not sure which babbage kernel persia meant
<amitk> lool: the board id is mapped to babbage
<lool> exactly
 * persia was kinda hoping for the lucid babbage kernel, but will trust statements that this doesn't work (didn't work with karmic kernel)
<lool> amitk: Oh you mean netwalker uses babbage's?
<amitk> MACHINE_START(MX51_BABBAGE, "SHARP PC-Z1") .phys_io      = AIPS1_BASE_ADDR, .io_pg_offst  = ((AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc,
<ogra> which should be fine for bringup
<lool> Hmpf
<ogra> just not for all devices
<amitk> lool: right
<lool> amitk: isn't this ugly?
<ogra> lool, did you expect beauty ?
<lool> persia: it seems that a minimal upstream kernel would work with the babbage id then; nervermind
<amitk> lool: tell me about it, they were too lazy to even get their own board id
<Sleep_Walker> :b
<lool> persia: I wouldn't try booting a full blown kernel though, that might blow things up
<persia> lool: As in physical damage?
<lool> I can't exclude that
<amitk> persia: I think there is no danger with physical damage with the minimal kernel going upstream in 2.6.34. Since it keeps most IO pins to their defaults
<amitk> and we're no where close to a full-blown kernel yet
<lool> amitk: I think persia intended to use the lucid babbage binary kernel against a netwalker
<persia> Ah.  I think I'll wait then, since I use this daily as a handheld, and it also houses my lucid pbuilder environment :)
<lool> Which I fear has a small chance of being dangerous
<amitk> true
<lool> apw: Thanks for the quick fix
<apw> we get into trouble if the source is missing ...
<NCommander> lool: ping. for ARM softbootloader, I need to have kexec-tools available for kexec, but the package unfortunately then changes the installed system to use kexec for rebooting as well which is unfortunate. I want to split the package out so I can have kexec installed and on its own without having the restart script stuff, any ideas on how to best do that?
<lool> apw: Ah?  I saw only three rbdeps in universe
<lool> NCommander: the restart stuff is disabled in Ubuntu by default
<apw> people complain when that package is empty as they percieve it contains the source, and if its empty we arn't publishing it, even though its in the the 'source' package
<lool> apw: Ah so a lot of people get it wrong, eh
<apw> yep
<persia> apw: Now you just need to find a way to make `apt-get source linux` work :)
<apw> persia, define work
<persia> apw: heh.  DWIM : download the source for the source package named "linux".
<persia> Current trick is to use `apt-get --only-source source linux`
<NCommander> lool: hrm, that must be a recentish change. Ignore previous ping then :-)
<lool> NCommander: It's not
<lool> It might be that you used the Debian package during the sprint
<NCommander> lool: It still did the kexec-load in karmic.
<NCommander> Which was the last time I looked at this
<lool> This was disabled in June
 * NCommander shrugs
<NCommander> lool: sorry for the noise
<dmart> dyfet: ping
<dyfet> *yawn*
<dyfet> morning
<dmart> Hi... wasn't sure if you'd be up
<dmart> I had a question on gmp
<dyfet> oh I remember that...
<dmart> Did you try to build the asm code for Thumb-2 in the end?
<dyfet> I had some trouble with coming up with a patch for configure.  They reject using try_compile, and try to do everything by the gnu target architecture tags alone
<dmart> Actually, I had an idea for that... you can maybe get the predefined macros out of GCC and munge that.  I wrote some notes on the Thumb-2 howto wiki page.
<dyfet> Oh, okay, cool!  I did not notice that
<dmart> It was late yesterday :)
<dyfet> But that is kind of what I need to do for that one :)
<dmart> However, if you do try to build this code for Thumb-2, we do need to check that the function symbols in the asm are properly tagged as function symbols, otherwise they would get called as ARM accidentally.
<dmart> I think that the PROLOGUE() m4 macro used in the asm does this, but I didn't fully track down where it's defined.
<dyfet> Ah....
<asac> great. we have 1 builder again ;)
<asac> https://edge.launchpad.net/builders
<dmart> Did you have >1 or 0 builders before?
<asac> perfect timing in a3 week ;)
<persia> dmart: 0
<dmart> (I'm guessing >1)
<asac> dmart: this morning we had 0 ;) ... usually we have 7
<dmart> Oh, OK
<dmart> What's the problem?
<dyfet> For me, lack of coffee :)
<asac> dmart: not sure. our is knows about it and are investigating. most likely the aweful pegatrons died again
<dmart> Hum
 * asac hopes for new build machines ;)
<dmart> dyfet: To check whether a symbol is a proper Thumb code symbol, you need to use readelf -s <object>
<dmart>      6: 00000001     0 FUNC    GLOBAL DEFAULT    1 f
<dmart> Crucially, the symbol type if FUNC, and the value is an odd number (bottom bit set)
<dmart> objdump helpfully masks of the bottom bit so as not to confuse you, so it's no good for this check :P
<dyfet> This should be described on the wiki page too...
<dmart> Yeah, I'll post it.  (I was just figuring out how to check...
<saeed> asac
<asac> saeed: hi
<saeed> hey
<saeed> I want to install lucid img on dove
<asac> right
<asac> whats the prob?
<saeed> http://cdimage.ubuntu.com/ports/releases/lucid/alpha-2/ has only imx images
<asac> saeed: just pick latest daily
<saeed> link?
<asac> and yes. we didnt publish alpha2, because at that time we had severe issues with dove ;)
<asac> saeed: http://cdimage.ubuntu.com/ports/daily-live/current/
<asac> http://cdimage.ubuntu.com/ports/daily-live/current/lucid-desktop-armel+dove.img
<saeed> ok
<persia> saeed: If /current/ doesn't work for you, there's often an archive of the past couple days which ought work if current doesn't.
<asac> yeah. just navigate one up in the tree
<asac> and you will find it
<persia> (end the URL at .../daily-live/ to see the (short) archive list.
<asac> but current should work afaict
<persia> Usually does.
<saeed> can you update me which issues still unresolved with dove
<asac> saeed: i planned to do some thorough testing on dove this week ... afaik all bad issues are fixed with the X0
<saeed> great
<asac> NCommander: any unresolved dove issues for saeed ?
<NCommander> asac: saeed, X0 isn't here yet (I wasn't home yesterday to get the delivery)
<NCommander> saeed: I did see the patch to fix kexec()'s decompression speed, thanks for the fast turnaround on that.
<persia> saeed: I can't find a good list of *all* the issues with dove, but https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove probably includes a good chunk of them.
<saeed> you're welcome
<asac> NCommander: can you throw mrpt on one of your many babbage boards and check if that builds?
<asac> NCommander: seems that package killed all our biulders
<NCommander> asac: ugh. I'm still not setup on any of the boards, and may need to do a purchase order to get them all up
 * NCommander is kinda still coming off unpacking from the long weekend
<asac> k
<saeed> NCommander: when I tried kexec, the bootargs were not passed to the kexeced image
<saeed> I've had to append all the command line in order to make it work properly
<NCommander> saeed: I thought that's the way kexec is supposed to work but I'm not 100% sure
 * persia is 100% sure : one may well want to have completely different bootargs from the bootloader and to the target kernel
<NCommander> dmart: is there a handy list of arm opcodes? I think I need to tear some code apart by hand without a disassembler
 * NCommander feels like crying
<asac> NCommander: for ooo=?
<NCommander> asac: uh huh :-/
<suihkulokki> NCommander: not handy but IIRC the only place to find opcode->instruction mapping is arm archictecture reference manual (aka ARM ARM)
 * NCommander is trying to determine where this code is blowing up
<suihkulokki> alternatively, if you can run the binary under qemu linux-user, qemu-arm -d in_asm ./binary can give good insight
<dmart> NCommander: really best to use a disassembler ;) (You could create an assembler file with the data words in it and disassemble that.)
<dmart> If you really want to decode instructions by hand, you need to refer to the ARM ARM
<NCommander> dmart, suihkulokki its just a buch of hexcodes in a C file. No specific binary to take apart ;.;
<dmart> Ah, is this in the kexec implementation?
<NCommander> dmart: OpenOffice
 * NCommander is trying to track down where it explodes
<dmart> oh!  Which file?  I think I have that unpacked somewhere...
<asac> its in the uno bridge
<asac> we currently need to ship a jaunty .so fo rthat
<asac> because otherwise it fails
<asac> we have a binutils bug open for that
<asac> iirc
<NCommander> asac: its not clear that binutils is the issue
<NCommander> the debugger breaks and cries though when you try and solve this, so I'm just scattering debug printfs
<dmart> Can you point me to the affected file in OOo?
<NCommander> dmart: we don't know specifically where its going bust
<asac> NCommander: can you please give dmart the bug id ;)
<NCommander> dmart: https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009
<ubot4> Launchpad bug 417009 in openoffice.org (Ubuntu Karmic) (and 3 other projects) "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic (affects: 1)" [Low,Won't fix]
<asac> bug 436617
<ubot4> Launchpad bug 436617 in binutils (Ubuntu Karmic) (and 2 other projects) "ARM unwind table linker processing broke OO's uno2cpp (affects: 1)" [High,Won't fix] https://launchpad.net/bugs/436617
<asac> i think thats the bug
<asac> dmart: NCommander: ^^
<dmart> thanks
<asac> hmm ... the sata disk i have is really really slow here for imx51
 * asac break before meeting
<dmart> NCommander: Is this any help? http://pastebin.ubuntu.com/377573/
<NCommander> dmart: I'll play with it in a moment
<dmart> It should allow you to decode invidual opcodes
 * NCommander is making some headway
<dmart> ok
<asac> dmart: the links to the quick references in the asm intro you posted dont exist
<asac> like http://www.arm.com/pdfs/QRC0001H_rvct_v2.1_thumb.pdf
<asac> dmart: hmm for libv4l compiler wth thumb2 complains about  cbnz    r5, .L2  ... with "jidctflt.s:74: Error: branch out of range"
<asac> i found a quick refernce and that refers to CBNZ as T2 :/
<asac> with -marm it doesnt fail
<asac> cat jidctflt.s | pastebinit
<asac> http://pastebin.com/f350081ab
<asac> thats the full asm generated
<asac> cc -Wp,-MMD,"jidctflt.d",-MQ,"jidctflt.o",-MP -c -I../include -I../../../include -fvisibility=hidden -fPIC -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o jidctflt.o jidctflt.c
<asac> /tmp/cctyjob8.s: Assembler messages:
<asac> /tmp/cctyjob8.s:74: Error: branch out of range
<asac> thats the error
<dmart> asac: Thumb-2 has different range limits for some instructions.  If cbnz can't branch far enough, you may be able to move the branch destination closer, or recode using cmp <Rn>, #0 // bne (I think)
<dmart> Hmmm, actually CB(N)Z is Thumb only
<NCommander> saeed: ping?
<NCommander> saeed: I just got my X0, it won't boot; kernel hangs at Uncompressing; the X0 I used in Portland worked just fine with our existing images
<asac> dmart: hmm. i think that .s is generated by gcc
<asac> i only get that with -save-temps
<asac> (already found that range thing in the quick reference)
<asac> dmart: yeah. i think for -marm its probably not generated by gcc at all
<asac> will produce a .s with -marm and compare
<dmart> Oh, right.  That's a compiler bug then.  Can you raise a launchpad bug on gcc and stash the preprocessed source there?
<dmart> The compiler should not generate out-of-range branches in its own code...
<asac> dmart: yep
<asac> will give you a bugid when filed (once off the call)
<dmart> I posted info on the porting wiki page showing where to find the up-do-date instruction set quick references btw (in case you didn't already find them)
<dmart> thanks
<asac> dmart: oh on top of the asm intro?
<asac> good
 * asac checks
<dmart> yes
<asac> found
<NCommander> plars: GrueMaster, I'm reminded of what happens when the bootloader machine id and the kernel machine id fail to match :-/
<asac> dmart: bug 522717
<ubot4> Launchpad bug 522717 in gcc-4.4 (Ubuntu) "libv4l code compiles to invalid asm: jidctflt.s:74: Error: branch out of range (affects: 1)" [Undecided,New] https://launchpad.net/bugs/522717
<dmart> asac: Can you attach the preprocessed source?  This makes it easier for the compiler guys to reproduce the problem.
<asac> right ;)
<asac> done dmart
<dmart> asac: cool, thanks
<saeed> Ncommander
<NCommander> saeed: ah, your around!
<saeed> what it's the board rev?
<plars> saeed: mine is 1.4, same problem
<saeed> NCommander, please try the patches I just sent you be email
<plars> GrueMaster: did you see the posting that just came across ubuntu-qa? how does that relate to the libtest stuff you've been doing? any help at all?
<NCommander> saeed: will try as soon as I can
<saeed> ok
<GrueMaster> just a sec.
<GrueMaster> plars: which channel?
<plars> GrueMaster: ubuntu-qa mailing list
<GrueMaster> Forward to me.  I don't appear to be on that list.
<plars> sure
<GrueMaster> It might be useful.  It does more api level testing, whereas the test suite I am working with does more low level testing (like at the fpu level).
<GrueMaster> It is also very new.
<GrueMaster> Wiki is dated this month.
<GrueMaster> plars: A good read on the different test suites would be http://ispras.linux-foundation.org/index.php/LSB_Tests.
<GrueMaster> It lists the different types of tests and compares them.
<plars> GrueMaster: cool, will take a look.  I was mostly just wondering if that one would also be useful
<plars> or if it added anything really
<GrueMaster> My understanding is that the tests mentioned in the email are essentially smoke tests.  They will quickly tell you if there is a problem with a library function.  What they don't give you is an underlying understanding of the problem (i.e. is it a toolchain issue, hardware issue, etc).
<asac> anyone can install netbook-launcher and see if it fails to start?
<asac> the 3d one
<asac> idea is to understand if we need another probing on top ... or can just rely o nthat failing to determine if we want to go for 2d
<ogra> asac, why dont we have the compiz wrapper in netbook-launcher ? that works pretty relaibly
<asac> ogra: thats too slow
<asac> for une
<asac> takes 2 seconds or something on boot time
<ogra> oh, i wasnt aware it takes 2sec
<JamieBennett> GrueMaster: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100223
<GrueMaster> Cool.  Send me that link on 20100222 and I'll be good.
<JamieBennett> :)
<ojn> Wow, i.MX51 cell phones announced? Not having POP in that form factor must hurt.
<ojn> (yeah, off topic, I know :)
#ubuntu-arm 2010-02-17
<DanaG> Feb 16 22:22:28 beagleboard pulseaudio[890]: memblock.c: Pool full
<DanaG> argh
<DanaG> Feb 16 22:24:08 beagleboard pulseaudio[890]: last message repeated 10 times
<DanaG> Feb 16 22:24:08 beagleboard pulseaudio[890]: ratelimit.c: 469 events suppressed
<DanaG> argh
<DanaG> Interesting... perhaps switching to speex-fixed-3 instead of speex-float-1 may have fixed it.
<DanaG> Is higher number better quality, or lower?
<DanaG> I'd assume the former.
<DanaG> Feb 16 22:40:40 beagleboard pulseaudio[1745]: protocol-native.c: Underrun on 'omap3beagle Analog Stereo for dana@EliteBook', 0 bytes in queue.
<DanaG> Feb 16 22:40:49 beagleboard pulseaudio[1745]: alsa-sink.c: Wakeup from ALSA!
<DanaG> ratelimit.c: 470 events suppressed             memblock.c: Pool full                 last message repeated 10 times
<DanaG> ARGH
<DanaG> p   xserver-xorg-video-omap3     - X.Org X server -- Omapfb display driver (NEON optimized)
<DanaG> p   xserver-xorg-video-omapfb    - X.Org X server -- Omapfb display driver
<DanaG> which of those two is recommended?
<DanaG> ah, optimized.
<DanaG> right.
<NCommander> armin76: ping, any luck with OOo on Gentoo?
<saeed> NCommander
<NCommander> hey saeed
<NCommander> saeed: how goes it this morning?
<saeed> good
<saeed> any luck with the new board?
<NCommander> saeed: not yet, I just finsihed cooking a kernel with the patches ytou set (although I couldn't get one of the powermanagement ones to apply)
<NCommander> *you sent
<NCommander> saeed: 0001-Dove-PM-Change-deepIdle-default-to-disable-and-add.patch didn't apply
<DanaG> oh yeah, speaking of PM... my beagleboard won't suspend.  Says something about "class failed to suspend on cpu 0" -- or something like that.
<saeed> you can leave meanwhile, but make sure to disble the deepIdle by adding pm_disable to the command line.
<saeed> later I'll sync with eric the dove git tree
<saeed> brb
<NCommander> saeed: I think ericm_'s out on vacation this week (hence why I"m building a kernel myself; I'm not much of a kernel guy ;-))
<NCommander> saeed: I did manage to get it to apply by applying the diffs by hand (not sure why git kept saying patch failed versus hunk failed)
<NCommander> saeed: successfully booted my X0 with a patched kernel into our live image environment
<saeed> great
<saeed> NCommander: didn't the gui hanged?
<i_am_ed> What's the feasibility of compiling 9.10 for the ARMv5TE processor on a sheevaplug?
<NCommander> i_am_ed: Very time consuming, needs loads of resources, and loads of people with experience on how to run buildds, and retune the archive
<NCommander> saeed: no hangs.
<saeed> did you loaded it over USB>
<i_am_ed> NCommander: Thank you. I'll have to push on with debian for now then.
<ericm_> NCommander, saeed, I've uploaded the kernel for testing on X0 at http://people.canonical.com/~ycmiao/dove-x0test/
<ericm_> NCommander, saeed, sorry was only available intermittently
<NCommander> ericm_: I already confirmed the X0 kernel patches work :-)
<NCommander> ericm_: can't test on Y boards though
<ericm_> NCommander, great - thanks
<ericm_> NCommander, I'll test it
<ericm_> NCommander, I'm still sending the mail in case it's still useful
<saeed> Ncommander: how can I load your live image?
<NCommander> saeed: on the X0?
<saeed> yes
<ericm_> NCommander, confirmed it works on Y1
<NCommander> saeed: grab our live image, write it to a USB stick
<ericm_> saeed, hi
<saeed> is it with the updated kernel?
<saeed> hey eric
<saeed> happy new chines year
<ericm_> saeed, thanks
<NCommander> saeed: you have to swap the kernel out, I have the files you need
<saeed> can I boot uImage and initrd from tftp and boot from the usb?
<NCommander> saeed: the boot.scr from USB also sets the command line. Its technically possible, but probably easier just to replace the files on the written image :-)
<saeed> ok, can you send lint to the image
<NCommander> saeed: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/lucid-netbook-armel+dove.img
<saeed> Ncommander: thanks, I'll try it
<NCommander> saeed: http://people.canonical.com/~mcasadevall/dove/x0_casper/
<NCommander> saeed: once you grab the image and write it to a USB stick, replace the uImage and uInitrd in /casper with the two from the second link
<NCommander> Power it on, and you should end up at the UNE desktop
<NCommander> The installer is somewhat fubar'ed ATM, so installation will fail if you try it.
<saeed> great, does firefox work fine for you?
<NCommander> saeed: works as well as it usually does (very slow to scroll due to no graphics acceleration)
<ericm_> saeed, 3.6 works OK, but not that significant faster as compared to x86
<saeed> is it version 3.5 of ff?
 * ericm_ fades out to bed ....
<NCommander> saeed: we're shipping 3.6 in lucid
<armin76> NCommander: still building
<armin76> saeed: i want a board too *g*
<armin76> NCommander: gimme your Y0!
<NCommander> armin76: don't have it any more
<armin76> boo
<armin76> NCommander: where's it?
<NCommander> armin76: far far away :-)
<armin76> oh nice, you sent it to me *g*
<armin76> openoffice is compiling for 11 hours now
<plars> NCommander: anyone tested the new kernel from ericm_  yet?
 * plars goes of to build a new squashfs with it
<NCommander> plars: it works
<plars> NCommander: ah, great :)
<plars> NCommander: any idea if it breaks previous revs?
<plars> NCommander: also, do we need to do something similar for karmic?
<NCommander> plars: not according to ericm_
<NCommander>                     
<NCommander> plars: do we care for X0 running karmic?
<NCommander> we'd have to spin a custom image
<dmart> asac: Hi there, was a time agreed for another porting sprint?
<armin76> NCommander: i'll get the X0 boards, so you don't need to care *g*
<armin76> oh, nvm, thought you were talking about Z0 :D
<saeed> NCommander: live image works for me
<saeed> but after installing it on sata disk. things are not so good
<NCommander> saeed: yeah the installer doesn't really like it if the uImage to boot and the image in the squashfs don't match
<NCommander> saeed: once the kernel in the archive is properly updated, and the images are respun, the installer will work correctly.
<ynezz> is it possible to find somewhere some info on how to rebuild kernel for ARM (beagleboard)
<ynezz> I'm using OE, I know how to do that there, but for ubuntu I can't find any useful links
<JamieBennett> ynezz: http://elinux.org/BeagleBoardUbuntu
<ynezz> I have it running already
<ynezz> there you can find how you can make custom image using rootstock
<ogra> ynezz, it has links ot the kernel archive
<ogra> and that has the patchsets and configs afaik
<ynezz> ok, but to rebuilt it I'll need some cross toolchain
<ogra> or build it on the beagle itself and leave it running over night
<ynezz> :)
<ogra> or use qemu-arm-static and build in a chroot if you run ubuntu
<ynezz> hm
<ynezz> the debs on ports.ubuntu.com are build the same way, in qemu?
<ogra> no, natively on real hardware
<ynezz> ok, that's what I would like to do, I'm using ubuntu
<ynezz> I just can't find any basic info, like what toolchain to use etc.
<ynezz> ah ok, found it that info in that bzr 2.6-dev branch in system.sh.sample
<persia> ynezz: Try `apt-get build-dep linux-source` from a running system: it should download all the right toolchain packages, etc.
<persia> You may also have to install build-essential
<persia> (if you don't have something running yet, the beagleboard wiki has pointers to a starter kernel)
<ynezz> yes this would work, but I would like to get it working on my host system
<persia> Oh, I don't think we have a good suite of cross-building tools.
<persia> I could be wrong, but I haven't heard of one that is known good.
<persia> Generally we do native builds.
<ynezz> ah
<ynezz> now I understand :)
#ubuntu-arm 2010-02-18
<saeed> plars: ping
<ogra> saeed, ~3am where he lives ...
<saeed> ogra: hi
<ogra> hey
<saeed> have you installed lucid over dove x0?
<ogra> i'm not one of the lucky guys to have an X0
<saeed> I see
<ogra> and i think NCommander is travelling, plars and GrueMaster ate in later timezones
<ogra> *are
<saeed> asac: ping
<asac> saeed: hi
<saeed> asac: have you installed lucid on dove?
<wv> Hello
<wv> does somebody has some experienc an i.mx51 bbg board combined with gstreamer?
<lool> A lot of people here played with babbage boards, but with varying versions; less so with the gstreamer codecs
<wv> its the latest evk board
<wv> installed with the demo image from freescale itself
<wv> Problem is that I want to stream some rtp (mpeg ts, with divx) to this board
<wv> and use the gpu to decode
<wv> but it kindof hangs
<wv> I mean
<wv> things seem ok
<wv> it's detected
<wv> it does some things but then just "hangs"
<wv> i see no video
<wv> command to receive I use is: gst-launch-0.10 -v gstrtpbin name=rtpbin udpsrc caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP2T" port=1234 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtpmp2tdepay ! decodebin2 ! xvimagesink
<wv> do I choose a wrong output device or something?
<wv> do I miss an option?
<wv> on a normal pc on my network, it just works like that
<wv> and localy also
<lool> wv: Sorry, no idea about the hangs
<lool> You don't have any buffer though
<lool> You might want to add some ! queue elements in your pipeline
<wv> what are queue elements?
<lool> You could also try in software without the gpu decoder
<wv> I mean, I'm not a gstreamer specialist
<lool> wv: literally buffers
<wv> this pipeline is also constructed with some help from the gstreamer channel :)
<lool> wv: gst-inspect-0.10 queue will give you some doc
<wv> lool: ok
<wv> lool: I already tryed with vlc and it works ok, despite the lack of hardware acceleration
<lool> wv: but I'm not sure it's the problem; it's just usual to have at least one queue to have sufficient data for the decoders to work
<lool> wv: Try with gstreamer without hardware acceleration
<lool> wv: Or try the pipeline on your PC
<lool> wv: FSL's gst codecs require patching to gstreamer
<lool> and it might be that they either hang with some input, or that the gst stack misbehaves
<lool> I would validate my pipeline in pure software decoding mode, and then try with FSL's stack and optimized elements
<wv> lool: how can i test it without the fsl gst codecs?
<wv> it just loads them as I run this command
<wv> or do I uninstall them?
<lool> wv: Try on your Ubuntu host?
<lool> wv: You could just "mv" the elements away to try it on the board; you'll need replacement elements such as the ffmpeg divx decoder
<wv> I tryed it on my host and it worked (streamed to 127.0.0.1)
<wv> lool: also tried to another networked pc and worked also
<lool> wv: Ok; so try without the gpu codecs; look for the gstreamer plugins which provide these and move them away, see if the software decoders work
<lool> If it works with software decoders, you can basically point at the fsl plugins
<lool> If it hangs with software decoders, you should look into the fsl gstreamer patches, perhaps rebuilding an unmodified gstreamer
<wv> owkey
<wv> well, I'll first have a look to add some "queue"
 * ogra lols about lool's creative long patch names
 * lool uses git format-patch's default
<ogra> long sentences with dashes ?
<lool> Yes
<lool> git format-patch takes the first line of the commit, just as shortlog does
<lool> And changes spaces to dashes
<ogra> ah
<lool> ogra: Since you mention it, at your earliest convenience please test this new qemu-kvm upload; I wonder whether the GCC atomics changes break anything and would like some additional testing before submitting upstream
<lool> I usually submit to upstream first, but this change is quite intrusive
<ogra> is that working around the glib issues or do i still need to export the gslice stuff ?
<ogra> or are you just referring to -static here ?
<lool> This is unrelated, it's for the armel build
<lool> But it changes locking on all architectures
<ogra> ok
<ogra> given that i'm madly testing rootstock atm i'll have it with the next upload and will notice any issues i guess
 * ogra curses compiz broken focus behavior in lucid 
<Sleep-Walker> hi all
<Sleep-Walker> amitk, am I right that for changing board ID (understand assinging Netwalker's specific ID) I would need to modify RedBoot in NOR?
<amitk> Sleep-Walker: redboot would need to pass the correct board id to the kernel, yes
<ogra> whats the current id you see in /proc/cpuinfo ?
<amitk> Sleep-Walker: what is it you're trying to do?
<ogra> (the field is "Revision:" iirc)
<Sleep-Walker> I'm preparing that wiki page and read Netwalker's code
<Sleep-Walker> amitk, I'd like to have support for Netwalker in upstream
<Sleep-Walker> I'm trying to make some plan of pushing all neesary stuff
<asac> saeed: the smoke testing? let me ask whats the progress on that
<Sleep-Walker> (I know that large part of code need to be rewritten or modified a lot)
<asac> saeed: i was fighting with getting stuff done for feature freeze (which was today) ... so i didnt get to it personally yet
<asac> but GrueMaster and plars wanted to check it ... and NCommander afaik
<amitk> Sleep-Walker: as I said the other day, try booting the stuff that is upstream with a modified bootloader. You'll find it probably boots
<Sleep-Walker> yeah
<Sleep-Walker> but there is more work left than support for i.MX51
<Sleep-Walker> wifi, optical point, touch buttons,...
<amitk> Sleep-Walker: one small step at a time is my motto. Personally, I want to concentrate on the drivers _on_ the SoC first. Not the external peripherals.
<amitk> and there is lots of things there too
<Sleep-Walker> I'd rather try kexec instead of bricking my new toy for now
<Sleep-Walker> I'm currently not writing code itself, just creating plan, status page etc
<saeed> asac: I've seen few issues with lucid installation, Iet me know when we can work on it
<asac> saeed: what issues did you see?
<asac> saeed: which image did you try?
<asac> http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/20100215/ ?
<asac> (i dont remember if i gave you the desktop image)
<asac> ogra: do you know whats up with the image builders?
<asac> they are down?
<asac> no logs for me
<asac> ah wait
<asac> looking at wrong logs i think
<ogra> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-netbook-imx51/
<ogra> has logs
<ogra> buildd breakage fallout
<ogra> today we should get images again
<asac> ogra: i dont even say a fatal error in the current log
<asac> see
<asac> it produces squashfs
<asac> and then its gone
<ogra> huh ?
<ogra> The following packages have unmet dependencies:
<ogra>   update-notifier: Depends: update-notifier-common (= 0.94) but 0.95 is to be installed
<ogra> from http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-netbook-imx51/20100218/
<ogra> not sure what you look at :)
<asac> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-dove/current/livecd-20100126-armel.out
<asac> ok
<asac> now i see
<asac> looking at netbook might help
<ogra> yeah :)
<KosiNuss> hi, what does "Unhandled fault: external abort on non-linefetch (0x1018) at 0x4033e000" mean?
<plars> saeed: I tried the patched kernel yesterday and was able to boot
<plars> I did hit some problems when I built it into an image, it was complaining about my squashfs, so something went wrong when rebuilding it I suspect.
<plars> saeed: I'd like to try with the image once it's built in, but I'm traveling today, GrueMaster should be up in about 2 hours and would be able to test it though
<GrueMaster> saeed: I'm up now.  What would you like to know?
<saeed> GrueMaster: hi
<saeed> I've tried to install lucid from live image on dove
<saeed> dove x0
<GrueMaster> The most recent image I have is 20100215, and it doesn't boot on X0.
<GrueMaster> It gets as far as uncompressing the kernel, then nothing.
<saeed> ok, you should take this img http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/lucid-netbook-armel+dove.img
<GrueMaster> Oddly enough, I get the same problem with a known working Karmic image.
<saeed> then take the image and initrd from http://people.canonical.com/~mcasadevall/dove/x0_casper/
<saeed> the kernel image from that link should work on x0
<saeed> GrueMaster: new dove x0 boards (rev 1.4) needs patches that still not merged to the lucid dove kernel
<GrueMaster> I planned on trying that later today.
<saeed> the live images boots fine
<saeed> but I started to see issues when installed it on sata hdd
<saeed> the installation process doesn't complete gacefully
<saeed> I mean there was no message the it completed, and some error message regarding ubiquity showed up
<GrueMaster> Any ideas as to why Karmic fails?  Same kernel issue?
<saeed> yes
<saeed> eric uploaded kernel package that suppots dove x0 board at  http://people.canonical.com/~ycmiao/dove-x0test/
<GrueMaster> Ok, I'll look into them.  Thanks.
<lool> Wee upstream u-boot gets support of imx51 with fec
<lool> for babbage actually (evk)
<NCommander> lool: \o/!
<ogra> funny, wolfgang told me he doesnt want to merge the git tree when i pointed him to it yesterday
<lool> They just selected a new imx custodian on the u-boot list and the port was proposed immediatly thereafter
<lool> http://lists.denx.de/pipermail/u-boot/2010-February/067329.html
<lool> http://lists.denx.de/pipermail/u-boot/2010-February/067475.html
<lool> (Stefano Babic proposed himself as the custodian)
<ogra> oh, funny
<ogra> its not the freescale tree
<lool> It's from freescale though
<ogra> but not the git tree
<ogra> somehow that defeats the purpose
<lool> and that's the fec fix http://lists.denx.de/pipermail/u-boot/2010-February/067329.html
<ogra> err
<ogra> 08 ?
<ogra> freescale has everyting on 09
<ogra> all 08 patches were dropped and rewritten
<lool> Funny, the new custodian gets pointed at our source package http://lists.denx.de/pipermail/u-boot/2010-February/067656.html
<ogra> oh my
<ogra> and that source is really messy
<ogra> a mix of 08 and 09 patches
<armin76> NCommander: ooo built, however it fails as http://www.openoffice.org/issues/show_bug.cgi?id=105359
<ubot4> OpenOffice.org bug 105359 in udk "bridges:arm failure to start OOo - terminate called after throwing an instance of 'com::sun::star::ucb::InteractiveAugmentedIOException'" [Defect,Started: ]
<NCommander> armin76: there's already a bug for this, I just wanted to make sure it wasn't an Ubuntu specific bug; I need to do some testing  but its possible this is a binutils issue
<armin76> y
<armin76> you have your answer now :)
<NCommander> armin76: thanks.
<armin76> yw
<armin76> openoffice-3.1.1: Wed Feb 17 02:12:23 2010: 1 day, 11 hours, 42 minutes, 56 seconds
<lool> apw: Thanks for udebs, linux-source, and meta, you rock   :-)
<ogra> even meta ?
<ogra> wow
#ubuntu-arm 2010-02-19
<DanaG> beagleboard is spiffy.
<Shambat> anyone here have any experience with the Sheevaplug?
<pranith> hello, i want to install ubuntu on the ipad. which version should i choose?
<pranith> UNR?
<Stskeeps> is ipad at all hackable?
<pranith> Stskeeps, i have special priveleges ;)
<Stskeeps> well get a linux kernel working first, :P
<pranith> im sure the kernel works
<pranith> its a general ARM core in the A4 chip
<Stskeeps> well, not so much about that
<pranith> cortex-A9 to be specific
<Stskeeps> but you need to have linux kernel booting and chipsets/SoC supported etc
<pranith> so which version of ubuntu do i choose? UNR? Ubuntu MID?
<Stskeeps> and iphone linux attempts haven't gone that well, afaik
<pranith> Stskeeps, ya, it's a imaginary scenario... i dont really have the ipad
<pranith> :)
<pranith> i was asking for ipad like ARM touch devies
<pranith> devices*
<Shambat> I want to build a custom Ubuntu based on 9.04 that has support for a lot of wifi chipsets ... This is for a Sheevaplug ... what is the best resource for accomplishing this?
<Shambat> basically, I need to learn how to gather the parts and compile the OS, and install it....
<ogra> pranith, as long as you have a kernbel and bootloader, try rootstock to assdemble a userspace
<ogra> *assemble
 * ogra needs to take a typing course it seems
<ogra> i would start with a simple ubuntu-minimal build to see if the kernel works with the userspace, if that works, install whatever desktop env you like (use the ubuntu-desktop or ubuntu-netbook metapackages for that, MID is rather dead nowadays)
<pranith> ogra, thanks!
<noisi>  hi! i search for sql-server and client for arm720t. can you give me some advice, please?
<lool> Would be great if someone could test valgrind on armel   :-)
<lool> I'm aware of one upsteam issue which might affect some code pathes, basic testing against e.g. "ls" would be great
<lool> noisi: Are you looking for binaries?
<noisi> yes, everything :-)
<lool> noisi: Your CPU is very old, I'm not sure it's supported by ARM anymore
<lool> noisi: Also, it's of the ARMv4 family, and Ubuntu never supported this
<lool> We supported ARMv5t in jaunty (9.04) but that is getting old
<lool> noisi: Debian does support ARMv4T though, so Debian binaries should work
<lool> noisi: Are you using EABI or OABI?
<noisi> i donÂ´t know eabi/oabi
<lool> noisi: That's important, you should find out
<lool> noisi: check your kernel config, look for ABI in CONFIG_ names
<lool> we have CONFIG_AEABI=y CONFIG_OABI_COMPAT=y in Ubuntu for instance
<noisi> i got a box with arm720t form http://www.owasys.com/
<noisi> with no sources
<lool> noisi: I understand, but arm720t wont work with Ubuntu and depending on which ABI you're using, you should use one or the other Debina port
<lool> Both will work on your hardware, it depends of your kernel
<lool> noisi: So you don't have a kernel?
<noisi> ok
<noisi> there is running a system
<lool> noisi: With Linux?
<noisi> Linux (none) 2.4.18-rmk3 #1264 Tue Nov 28 11:40:43 2006 armv4l unknown
<noisi> if i type uname -a
<lool> noisi: This is antique
<lool> noisi: But you should have gotten the sources with your kernel (per the GPL)
<lool> noisi: I am not sure how well Debian will work on 2.4.x kernels at this point though
<noisi> okk
<ogra> lool, do you have any elegant pygtk reciepe to make Popen non-blocking without having to fiddle with fnctl and additional filehandles ?
<ogra> i.e. a magic switch i dont know about for subprocess
<StevenK> I'm sorry, you can't use 'pygtk' and 'elegant' in the same sentence.
<ogra> pfft
<ogra> i just cant imagine that subprocess doesnt have anything builtin
<lool> ogra: I don't understand the problem
<lool> ogra: The default for Popen is to not block
<lool> I mean subprocess.Popen
<lool> ogra: By default, subprocess.Popen does os.spawn with P_NOWAIT
<lool> It's only if you interact() that it will block on it (obviously)
<lool> err communicate()
<lool> Sorry, I'm confused by expect terminology
<ogra> hmm
<ogra> well, if i have output where the subprocess is busy for a while without spilling a new line my UI gets unresponsive
<lool> ogra: How are you reading from your subprocess?
<lool> ogra: code?
<ogra> http://paste.ubuntu.com/379703/
<ogra> stdout.readline()
<ogra> i tried communicate but its buffering eternally
<lool> ogra: I think you need to use select.select() and os.read()
<ogra> and fnctl then i guess
<lool> ogra: oh you're doing while output.poll() is None:
<lool> So you should use poll()
<lool> check for POLLIN
<ogra> ah, thats what i was looking for i think
<ogra> all solutions i found yet route through additional filehandles which i'd like to avoid
<lool> The pipes should be fine
<asac> non-blocking IO for the python world!
<ogra> asac, well, even python can do fork() and pipe() :) its just that i dont use that
<JamieBennett> we'll get asac loving python sooner or later ;)
<ogra> yeah
<asac> just remember gwibber spawning threads for blocking IO ;)
<ogra> i luckily have never seen gwibber from the inside :)
 * asac reboots after upgrade
<ogra> dont !
<ogra> you'll lose your sound
<lool> Sadly there's no proper threading in python   :-(
<lool> only real child processes
<ogra> yeah
<asac> seems my upgrade removed a bunch of stuff i didnt spot ;) ... like nm-applet etc.
 * asac goes fixing his system
<asac> hmm. is it possible that the sata port of bbg is really really slow?
<ogra> yes, because it is no SATA port
<JamieBennett> It hangs off of USB doesn't it?
<ogra> right
<ogra> with usb speeds
<ogra> 16MB/s
<ogra> can peak up to 20 ... but thats rare :)
<asac> ogra: my sata drive is definitly slower than what i had with USB
<asac> its really crawling
<asac> maybe i should go for SD card again ;)
<ogra> heh
<ogra> ogra@babbage2:~$ sudo hdparm -t /dev/mmcblk0p2|grep MB
<ogra>  Timing buffered disk reads:   32 MB in  3.17 seconds =  10.09 MB/sec
<hrw> morning
<hrw> Stskeeps: hi here
<Stskeeps> moo
<hrw> I see that next ubuntu release will target armv7 cpus only. which devices/cpus are supported?
<hrw> as https://wiki.ubuntu.com/ARM/DeviceSupport is rather not up-to-date
<ogra> hrw, imx51 (freescale) and dove (marvell armada)
<ogra> up to now ...
<hrw> ogra: no omap3?
<ogra> no kernel
<hrw> ok
<ogra> so we dont build images
<ogra> but userspace indeed works on all v7 CPUs
<hrw> how many people work on ubuntu/arm?
<ogra> well, hard to say ... we ven have a good bunch of beagle people helping on it :)
<ogra> or do you mean inside canonical ?
<hrw> inside
<hrw> I have a bunch of arm boards on desk and just checked how many of them can run ubuntu.
<ogra> in the distro/mobile team we're 8 if i didnt miscount, plus a bunch in the kernel team
<hrw> but most of them are armv5te or armv6. just beagleboard and n900 are armv7a ones
<ogra> v5 was supported in jaunty
<ogra> in karmic we switched to v6+vfp
<ogra> lucid now is v7+thumb2
<hrw> I noticed
<ogra> btw, as you can see on http://webapps.ubuntu.com/employment/ it will soon be more than 8 :)
<ogra> like ... a lot more :)
<hrw> ogra: I do not have to go there to know ;) I just looked into my inbox
<hrw> ;D
<ogra> lol
<asac> hmm
 * asac blind
<asac> doesnt see where ocaml uses arm.S
<asac> i guess its not used at all
<asac> anyone can check if i miss something?
<asac> hmm. is ASPP a default variable for make?
<asac> dont see it defined either
<asac> oh
<asac> ;)
 * asac should go one up
 * ogra hands asac some glasses
<asac> still cant find that arm.o is really used
<asac> dont see anything in the build log either
 * asac thinks about marking it as invalid
<asac> dmart: ^^
<asac> ocaml ... cant find in build system that arm.S is actually used
<hrw> btw - armel is not 1st class arch in ubuntu? it is not present in packages.ubuntu.com interface
<asac> hrw: thats just a technical detail
<asac> it still lives in ports.ubuntu.com for a few reasons
<asac> but its supported ;)
<hrw> ok
<hrw> where I can read more about devices which are supported?
<asac> we currently support marvel dove and freescale imx51 devboards
<hrw> thx. both looks like hard-to-get devboards
<NCommander> hrw: Ubuntu lucid will work on any board with VFP+Thumb2+ARMv7 support, you just need to use rootstock to spin your own image.
<hrw> ok
<asac> update-notifier: Depends: update-notifier-common (= 0.95) but 0.96 is to be installed
<asac> whtas going on :(
<ogra> asac, still ?
<asac> it definitly built
<asac> so its something else
 * asac tries what apt-get install says
<ogra> was it published etc
<asac> that doesnt have a problem
<ogra> weird
<asac> i didnt ran it, but it didnt complain and asked to go ahead
<asac> ogra: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-netbook-imx51/20100219/livecd-20100219-armel.out
<asac> maybe thats not a new run=
<asac> ?
<asac> ogra: can you kick off a llivefs build manually?
<ogra> yes
<asac> ogra: can you do? :-P
<ogra> running
<ogra> takes 3h though ...
<ogra> asac, didnt fail yet, thats a good sign
<ogra> unless the livebuilder locked up :)
<Martyn> hey, for those pegatron nettops .. is there a 9.10 or 10.4 image I can throw on it?
<ogra> nope
<ogra> we dont have a kernel
<Guest48348> Martyn: I found Karmic can work, though it requires a bit of a bodge to run it on the existing jaunty kernel
 * dmart_ curses nick lockouts
<dmart_> ogra, asac: Did anyone have a chance to connect a board running the current imx51 kernel via a hub?
<asac> dmart_: ogra tried that
<ogra> dmart_, i dont have a hub around and nobody around me seels them :(
<asac> he wasnt able to reproduce issues
<dmart_> IRC _really_ does not like that I have to keep pulling out my uplink cable to download things onto the board...
<ogra> *sells
<asac> really
<ogra> asac, i only tested on switches
<asac> ogra: you sent a mail
<asac> ogra: why did you test switches ;)
<asac> dmart_: ok scratch that. seems we dont have a hub then
<lool> Can one still find hubs?
<ogra> asac, because i dont have hubs and nobody said there was a prob with hubs until after i sent the mail
<ojn> Martyn: I never got any useful information out of ARM, so I just went with the Genesi-side docs instead. They use a different wifi chip but the rest works: http://blog.efikamx.info/2009/12/releases-for-22nd-december-2009-u-boot.html
<asac> ogra: your mail really sounded like you tested hubs ... i wouldnt have expected a mail aabout switches at all
<asac> because noone complained about those
<ogra> asac, huh ?
<asac> nevermind
<asac> lool: maybe on ebay
<ogra> or as a do-it-yourself soldering kit for kids to learn about network HW :)
<dmart_> Maybe fsl could help with this?
<ogra> well, i didnt see any issues with iftop on switches when testing karmic and lucid ... there was a difference of 5Mbit/sec between the two though
<ogra> dmart_, are you seeing that on lucid too ?
<dmart_> It's only on lucid --- it may have come in at the time of the fsl .31 kernel merge, since it didn't happen very early in the cycle.
<ogra> early in the cycle we used the karmic kernel
<ogra> lucid is 100% freescale now
<dmart_> But boards running the current kernel are ~ unusable for development unless I uplink directly --- download drops from normal speed to 10-100kB/s
<dmart_> This has been seen with Babbage 2.0 and 3.0, and with multiple hubs.
<ogra> bad :/
<dmart_> Unfortunately our IT temporarily ran out of switches too...  but I'll try and order one.
<ogra> i'll try to get a hub somewhere over the weekend
<ogra> cant be that hard to find one
<dmart_> hopefully not...
<ogra> (i only checked the closest HW shops around)
<dmart_> On another topic, is anyone else having trouble with the current armel images?
<dmart_> For me, ubuntu-netbook 20100215 (current) -> ubiquity crashes shortly before completion
<dmart_> ubuntu-desktop 20100218 -> the same, + nautilus crashes and repeatedly respawns
<ogra> there were a lot of fixes to ubiquity within the last three days
<ogra> though i heard partitioning is broken atm
<dmart_> I didn't try to run ubiquity on 20100219, but nautilis still crashes.
<ogra> ignore ubuntu-desktop please
<ogra> the livefs isnt updated anymore
<ogra> StevenK, ^^^ can we stop producing images as well here ?
<dmart_> I did a debootstrap instead and I get a working-ish system (except rsyslogd eats all the CPU), and nautilus does not crash, weirdly.
<ogra> (gah, i still didnt check how late it is for steve ... )
<dmart_> Ah, if the livefs is no longer updated that would explain why nautilis isn't fixed.
<ogra> right
<dmart_> I was only using -desktop because the netbook image was borked...
<ogra> ignore desktop, i'll care for it not showing up on cdimage anymore next week
<dmart_> Sounds sensible
<dmart_> Is there a metapackage for -netbook in case I need to bootstrap it?
<ogra> yep
<ogra> ubuntu-netbook :)
<dmart_>  Hmmm, looked for that but couldn't find that before
<ogra> though better try the task
<ogra> apt-get install ubuntu-netbook^
<ogra> (mind the caret)
<dmart_> Found it now, maybe my package list was out of date.
<ogra> i just did a rootstock testinstall today like that
<ogra> right, should be there
<dmart_> Found it... maybe my lists were out of date
<ogra> yeah
<dmart_> Is the intention that ubuntu-desktop should still work?  It's a bit nicer for development purposes, but building images is not really needed.
<ogra> should still be installable, yes
<ogra> we just dont test it or roll images
<dmart_> Sure.  It looks like mono unbroke, so I can install it now, anyway.
<ogra> but unless there are massive regressions (which i wouldnt expect) it should just work
<dmart_> Nothing untested ever "just works" ;)  But that's fine in this case
<ogra> heh
<dmart_> asac: How's the Thumb2 porting stuff going?
<asac> dmart_: currently working on it my self.
<asac> ocaml invalidated (asm isnt used at all)
<dmart_> Should we have another sprint?  I don't think a time was suggested yet.
<persia> I also haven't seen a time suggested.
<asac> dmart_: next week about the same time i would suggest
<asac> problem is that australia wants to participate
<persia> 11:00 UTC on Thursday?
<asac> thats good
<asac> then US has to skip i guess
<asac> but they had their chance last time
<persia> Or come late.
<dmart_> I can possibly do an evening, so long as it doesn't happen too often ;)
<asac> dmart_: 1100 UTC it is
<asac> i will send an invite
<dmart_> OK, fine for me.
<dmart_> That's a week away though, did we want to do it earlier?
<asac> and try to get the team to work on that next week with more pressure ;)
<persia> dmart_: The issue is that midnight UTC is a good time to start working in Asia, so "evening" can get quite late :)
<asac> dmart_: you are always here ... thats ok; we just need to work outside of the sprint on it too
<asac> which I feel we didnt do enough the last week (partly excused by part of the team on the road this week)
<dmart_> Is there a list of packages which nobody has picked up yet?  I've been a bit distracted this week, but hopefully I can look at a couple
<persia> People should be updating the wiki when they do something.  If you find a pacakge not updated, it's fair game.
<dmart_> OK
<dmart> How is dove these days?
<ogra> curring
<ogra> (sorry couldnt resist :P )
<ogra> X0 should be fine again
<dmart> sounds good
<ogra> and i heard even Y1 was good according to GrueMaster
<dmart> Was that from kernel updates, or something else?
<ogra> kernel updates, mainly the most recent fix afaik
 * asac apt-get source mono
 * asac find | xargs grep mov.*pc
<ogra>  2.6.32-201.10
<ogra> only went in yesterday
<persia> For lucid also, or just karmic?
<asac> dmart: we have really odd issues in the mono testcases... one that strikes me is that Integer.MAX_VALUE++ seems to not overflow ... does that ring any bell?
<dmart> Not really.  Is this a regression since Thumb2?
<asac> unlikely
<asac> in karmic 40 testcases failed
<asac> now its just 37 ;)
<dmart> ah
<asac> nevermind. have to check the code what is actually happening for increment to get an idea
<dmart> Maybe the code which detects the overflow is not correct.  I don't know the mono internals myself...
<asac> ulong a =  UInt64.MaxValue; ulong t = a++;
<asac> thats what is not overflowing
<lool> asac: find | xargs grep => rgrep or grep -r
<asac> dmart: yeah probably. its odd that it works on other archs though ;)
<asac> lool: i know ;)
<lool> Oh ok
<asac> its jus tthat that flows out of my fingers automatically ;)
<asac> also you can more easily restrict what to search with find imo
 * lool has grep -rl in his fingers instead
<asac> but could be i am just too old ;)
 * persia things xargs is obsolete anyway, since find grew exec +
<lool> asac: I do **/*.c when I need to limit to certain file types
<asac> will try to change my habit ;)
<lool> asac: Oh just suggested it in case you wouldn't use it
<lool> I discovered grep -r after some years of linux and it changed my life
<lool> Would have been suprizing if you hadn't known about it
<persia> grep -rn is key to understading source files.
<asac> to be honest i discovered it not that long ago ... couple of years maybe ;)
<asac> dmart: #define ARM_DEF_BX(reg,sub,cond) (0x12fff << 8 | (reg) | ((sub) << 4) | ((cond) << ARMCOND_SHIFT))
<asac> that is supposed to emit bx ;)
<asac> is that number correct?
<dmart> It looks probably correct for ARM, but the Thumb encodings are different.
<asac> right.
<dmart> Do you know what gets passed for sub
<dmart> >
<rbelem> Hey guys! Are you using any crosscompiling toolchain?
<ogra> rbelem, nope
<asac> dmart: http://paste.ubuntu.com/379877/
<ogra> rbelem, use qemu-arm-static and do native builds in chroot :)
<asac> so ARMREG_IP
<asac> let me check what that is
<rbelem> ogra, i'm using that, but i want make builds faster
<dmart> Probably the register numper for ip (it's r12)
<rbelem> using icecc
<rbelem> icecc rocks!
<rbelem> :-)
<dmart> asac: The fact that mono is doing code gen might be an issue --- it's presumably generating ARM code, so we need to watch out for calls into and out of that code.
<asac> dmart: so sub == 1
<asac> dmart: not worth fixing the code to emit thumb2 code?
<dmart> Yes, but that might be a larger job.  Is this a JIT, or it just generating a few native call veneers or similar?
<asac> its a jit ... we have all the defines in the mono/arch/arm/arm-codegen*.h
<rbelem> ogra, i'm using maemo(RIP) with qemu-arm-static and icecc to speedup the builds
<asac> there is mono/arch/arm/arm-codegen.h and also mono/arch/arm/arm-codegen-vfp.h
<asac> and otheres
<ogra> rbelem, ah
<asac> dmart: wanna take a look at those files to see how much changes it would be to come up with thumb?
<asac> feels like if i knew this stuff it would be just going through that full file ;)
<asac> dmart: so whats the idea to watch for calls-in and out?
<rbelem> ogra, and the scratchbox toolchain
<ogra> right, thats fine for maemo stuff :)
 * dmart apt-get source mono ...
<rbelem> ogra, but now i'm planning help you with arm porting :-)
<asac> hmm they already have stuff like: "THUMBOP_TST"
<asac> e.g. ThumbOpcode
<asac> in mono/arch/arm/arm-codegen.h
<ogra> rbelem, well, then qemu and icecc to do native builds are likely the best you can do beyond using real HW
<ogra> (or distcc)
<rbelem> ogra, that's why i want a crosscompiler. The build nodes will use it.
<ogra> just make the nodes run it in qemu-arm-static ?
<rbelem> ogra, but it is very painful
<ogra> well, cross building is more painful imho
<ogra> as long as you have dependenciesw at least
<ogra> its surely suitable for something like a kernel testbuild
<rbelem> ogra, i use my colleagues computers, so i can not install it on each computer
<ogra> but i wouldnt want to build any desktop package in a cross way
<ogra> and beyond that you might hit toolchain issues that arent present in native builds or vice versa
<ogra> or compiler issues
<rbelem> ogra, which issues are possible?
<asac> reconnect
<ogra> well, you use a different compiler
<asac> dmart: didnt get anything from last 5 minuts
<ogra> different version, other features etc
<dmart> asac: Are you still talking about mono?  If so, not yet --- NFS (slow)
<rbelem> ogra, isn't it the same compiler but compiled to be cross?
<ogra> rbelem, where do you get that compiler ?
<ogra> we dont offer a cross build of our gcc 4.4.3
<asac> dmart: just notified you so you can repost if you said something
<dmart> OK.  still waiting I'm afraid
<dmart> rbelem: You could try using the Ubuntu gcc source and messing with the configure args.  But that's only feasible if you've already build cross-compilers (there are many pitfalls and I've not done it myself recently)
<rbelem> ogra, it is just an assumption
<ogra> well, its a techincal impossibility atm :)
<rbelem> dmart, it would be nice
<ogra> right
<persia> rbelem: Even if the same compiler, but compiled differently, one can encounter ABI skew, which makes things segfault for unexpected reasons.  It's essential to compile everything in the same way.
<ogra> if someone would build a cross compiler from the same source you would be on the safe side
<ogra> *safer
<persia> Since we compile everything native, anything that needs to link to it should also be compiled natively.
<rbelem> let me check a cross compiler package contents
<NCommander> rbelem: what are you trying to build specifically?
<rbelem> NCommander, nothing specific. But i'm planning to build kde stuff
<dmart> Well, there should be no ABI skew in principle between cross and native compilers build from the same compiler source.  But native/cross compatibility is not well tested--- most people use just one of the other, and there have been discrepancies in the past.
<NCommander> rbelem: you *really* don't want to cross-compile KDE unless you love torture :-)
<rbelem> eheheh
<dmart> To accelerate local package hacking, a cross compiler + scratchbox could be useful.  But this is no good for the Ubuntu archive.
<NCommander> CMake supports cross compiling, but its really really different from auto**** and kinda wonky
<ogra> the dependency cahin will be fun :)
<ogra> *chain
<NCommander> dmart: indeed. We've made some progress improvmenting qemu-linux-user
<ogra> NCommander, none WRT speed though
<asac> dmart: i think it might speed things up if you are joining #monodev on irc.gimp.net
<ogra> and i doubt you can speed it up
<rbelem> dmart, i can do almost the same thing with qemu-arm-static
<asac> dmart: the guy that knows all this is currently there it seems ;)
<rbelem> dmart, to remove the "almost" i need the cross toolchain
<NCommander> ogra: with some cross-compiler hooks, you can offload compiling to native; I played around with it on m68k
<rbelem> :-)
<NCommander> Its fairly stable as a buildd actually.
<persia> rbelem: dmart There's also lots of packages that have assumptions in the build systems that make them unsuitable for cross-compilation which would need to be sorted.
<ogra> NCommander, you mean that scary hack suse is using in OBS ?
<NCommander> (in that case, there was no QEMU, but I had hacked up distcc to do the offloading)
<ogra> ah
<rbelem> persia, it is transparent if you use icecc
<rbelem> persia, the cross will be in other machine
<NCommander> ogra: I remember pitching the idea at UDS jaunty, but we decided that native compiling was just easier
<ogra> rbelem, he talks about hardcoded stuff in packages etc
<ogra> NCommander, the OBS idea ?
<ogra> thats a horrid hack
<NCommander> ogra: using cross-compilers via distcc to speed up compilation
<rbelem> ogra, which kind of stuff?
<asac> dmart: so we need to adjust all ARM_DEF defines vargaz said
<ogra> rbelem, injecting x86 libc into the amrel chroots
<asac> dmart: with #ifdef thumb
<asac> if we go the full jit way
<rbelem> ogra, i didn't get. do you have an example?
<rbelem> :-)
<ogra> NCommander, i would support using distcc across a bunch of machines using qemu-arm-static ;)
<asac> dmart: is it usually just the OPTAG that needs to be adjusted?
<asac> like ARM_MUL_TAG
<asac> or the full ARM_DEF_MUL_COND ?
<dmart> You cannot generate Thumb code from an ARM JIT implementation without significant work, because a lot of assumptions break down.
<asac> they use BX at least they told me
<asac> but yeah
<rbelem> ogra, "Now based on GCC 4.4.1!"  - http://www.codesourcery.com/sgpp/lite/arm
<ogra> rbelem, they inject the x86 libc into an arm chroot and use the x86 gcc in there, what comes out is arm code like its been cross compiled but the env it is built in is arm, that speeds up and solves the dependency issues
<ogra> rbelem, right, we use 4.4.3
<rbelem> :-(
<dmart> asac: I haven't looked in detail yet
<asac> dmart: sure so i guess too much work ;) ...
<asac> 19:09 < vargaz> thumb2 support is only required on cpu-s without the arm classic instruction set, which are rare.
<asac> dmart: ^^
<ogra> heh
<asac> or is he just saying that -marm is ok?
<ogra> so we should revert the archive ...
<dmart> asac: If they have the interworking correct, then that statement is true.  There is no special reason to convert a JIT from Thumb to ARM unless it is the only way to resolve interworking issues.
<asac> ok
<asac> he claims there are thumb-2 only CPUs out there ;)
<asac> 19:13 <@kangaroo> someone makes thumb-2 only cpus?
<asac> ah ok
<asac> 19:13 < vargaz> yes.
<asac> 19:13 < vargaz> there is the cortex-m series or something, which are micro-controllers.
<asac> i guess we are not ready for that ;
<asac> )
<dmart> The ARMv7-M profile does not have the ARM instruction set.  Cortex-M* profiles implement this.  These are intended for microcontrollers and don't have an MMU etc., so this is uClinux territory.
<asac> yeah ... was just kidding
<rbelem> ogra, yeah! :-( When will them will launch 4.4.3?
<ogra> no idea
<asac> dmart: anything you would like me to ask now that the right folks for mono seem to be available?
<ogra> asac, seems the livebuild doesnt get forward and lamont it in the air :/
<asac> ogra: sigh
<asac> ogra: single point of failure is just bad
<ogra> yeah
<asac> is there someone in the pipeline?
<ogra> single lifevfs builder too :(
<asac> ;)
<ogra> i pinged in #is
<dmart> asac: Sounds like ARM/Thumb interworking in the mono JIT should be discussed with vargaz?  If he can explain why it works, we're probably fine.  If he doesn't understand the question, we have some work to do ;)  (but it sounds like he has thought about it...)
<rbelem> ogra, do you think it is possible for lucid+1?
<asac> dmart: see pmsg
<ogra> rbelem, i dont think we'll ever support it because you cant be sure the cross built stuff is really identical to a native build ... and i suspect codesourcery might always be behind in versions
<persia> rbelem: native build doesn't take *that* much longer.  IF you want it really fast, run distcc on a bunch of ARM hardware.
<ogra> asac, seems its still running, just not spitting out logs atm
<rbelem> persia, i just have two arm devices :-(
<persia> Yeah, well.  That is still a problem for most of us :)
<rbelem> persia, ogra suggested to run icecc inside a chroot with qemu-arm-static as an alternative
<ogra> asac, ah, there just popped up some logs for dove ;)
<ogra> seems to run fine ...
<armin76> persia: you can always run cross distcc
<persia> rbelem: Sure.  ARM boxes can be real or emulated :)
<ogra> i dont get why dove was built before imx51 though ... i gave the command in a different order :/
<persia> armin76: I don't trust the reliability of mixing that with native, give that it's not well tested and there have been issues in the past with alignment, etc.
<persia> armin76: If it's all cross or all native, no issues.  Since the rest of the archive is native...
<armin76> always worked for me :)
 * ogra goes afk and will check the builds later tonight again
<ogra> armin76, you mix cross and native stuff ?
<armin76> ogra: for building my stuff yes
<ogra> with a toolcahin and compiler on the edge and highly optimized default flags ?
<asac> 19:24 <@kangaroo> yes
<asac> 19:24 <@kangaroo> we use interworking all the time
<asac> 19:24 <@kangaroo> if its not, its a bug and we'll fix it
<asac> 19:24 <@kangaroo> we have to support it to pinvoke thumb libs from C#
<asac> dmart: ^^
<dmart> Probably it works then... I'll try and chat with him on Monday and check.
<armin76> ogra: no, i use what we call stable, which is gcc-4.3.4,glibc-2.10,binutils-2.19 atm
<dmart> asac: Mind you I can't figure out where the arm-codegen stuff is actually used from.
<asac> dmart: in in mono/mini/arm*
<asac> i think
<asac> at least thast how i found the codegen parts ;)
<asac> (those filse have the mov matches ... which turned out to be just comments before they use those macros)
<ogra> anyway ... -> afk
<dmart> Oh yes, I see (the first function I searched for wan't used...)
<asac> ls mono/mini/mini-arm*
<asac> mono/mini/mini-arm.c  mono/mini/mini-arm.h
 * rbelem goes check for toolchains
<lool> persia: sudo works for me in latest qemu-arm-static
<Martyn> ojn : Still about?
<Martyn> ojn : I'm downloading your installer and karmic image .. hopefully this will all work sans serial, since I don't have a serial cable for this pegatron
<ojn> Martyn: not mine, but genesi's. Yeah, I got a hold of one of the debug boards they have that brings out serial and jtag. I'd been dead in the water with out.
<Martyn> Without the serial and jtag, do I have a hope in heck of getting this installer SD and image to work?
<NCommander> Martyn: on a pegatron imx51 board?
<Martyn> yep
<NCommander> Probably not. Pegatron uses Lange which is a variant of babbage
<Martyn> the little white one that looks like a genesi
<NCommander> Kernel is incompatible
<ojn> Martyn: You can borrow my debug board if you want
<Martyn> Hmm .. where can I find the original system image for the white Lange based unit?
<ojn> Martyn: dmart kept promising one but I never saw one.
<Martyn> because what happened is that someone in the company decided to try upgrading from 9.04 to 9.10 using the system updater
<Martyn> and let me tell you, it's in a sorry state :)  Kernel panic :)
<persia> lool: works for me too.  Nice work!
<armin76> Martyn: yes it will
<Martyn> armin76 : Wait, so the genesi installer _will_ work on this white pegatron?
<armin76> Martyn: you can always change the kernel :)
<armin76> Martyn: ask neko on #efika, but i guess so
<ojn> Martyn: That's what I used on mine
<ojn> Martyn: on a separate SD card
<armin76> i believe it still has the nice bug that once you reboot it, ssh won't come up again
<Martyn> ojn : So - sequence of events is -- installer-sd.img onto an SD card .. change DIP to 0001 .. power up system
<Martyn> without a serial cable, will there be any external indication that the process is complete?
<ojn> Martyn: correct. Yes, framebuffer should come up
<armin76> it tries to get a ip from dhcp
<armin76> Martyn: the efika boots from sd before internal 'ssd' without touching the DIP
<Martyn> then copy the karmic-minimal tar to a SD card?
<armin76> Martyn: there's a dd image
<Martyn> armin76: so installer-sd.img is sufficient on it's own then...
<armin76> i believe so
<Martyn> allright .. I'll be right back then.    Lets give this a spin
<Martyn> I flipped the DIP to 0001, light went blue for a few moments, then power light went green.  No framebuffer came up
<Martyn> how long should I leave it be?   What is the expected time before the framebuffer should come up if this was at all successful?
<Martyn> armin76: I used the image from http://www.powerdeveloper.org/platforms/efikamx/linux
<asac> heh http://infocenter.arm.com ... doesnt work on chromium for me
<armin76> Martyn: there is some problems with the display, i don't believe that image has them fixed
<armin76> its from last year, so definitely it doesn't
<armin76> Martyn: check if it looks for dhcp requests, then you could access it through ssh
<Martyn> armin76: Is there an /original/ system image available?  The 9.04 image Pegatron used?
<Martyn> Frankly, I'd be happy just getting this unit back to factory-working condition
<armin76> i don't have it
<armin76> nor its hosted there afaik
<Martyn> Grrr.. how the heck can I fix this thing then.
<armin76> put gentoo on it *g*
<Martyn> It's all fine for them to give them away, but an original system image would be nice.
<Martyn> armin76: not the point :)  I'd like to get it just working again.
<Martyn> okay, I'll look for a DHCP request .. so far none show up
<Martyn> once the SD card installer has finished, is there any exernal indication?
<armin76> Martyn: maybe you could try replacing the kernel in that image with the one you already had
<Martyn> that's the problem .. without serial, there's no way for me to get to the uboot
<Martyn> so I need some sort of flash-recovery image
<Martyn> Hmm .. no evidence of DHCP activity
<Martyn> I'll flp the DIP switches back to the original state and reboot
<Martyn> see if anything changes
<armin76> oh, thought the original image was on another sd card
<Martyn> no.  They just toasted the box by attempting an ubuntu upgrade from 9.04 to 9.10
<armin76> ok, then definitely you're screwed if you aren't able to boot the kernel
<armin76> blame ubuntu for breaking stuff :P
* armin76 changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Debian ARMel TODO: http://wiki.debian.org/ArmEabiTodo | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | build probs with your packages in lucid ? see https://wiki.ubuntu.com/ARM/Thumb2
<armin76> (i just removed the thing about pinging me wrt anyone going to mwc)
<Martyn> So what is this thing called exactly?  Babbage 2?
<armin76> lange 5.1 i believe
<armin76> thats what uboot says
<Martyn> I'm obviously going to have to either talk to Pegatron or Freescale about getting a recovery system image
<persia> I believe it's sufficiently different from the babbages that the babbage kernel doesn't work (but base this entirely on hearsay)
<armin76> Martyn: canonical has lange boards as buildd's, maybe they could help you
<armin76> Martyn: just a question, can't you access uboot from video output?
<armin76> (haven't plugged my efika, no hdmi monitor)
 * lool is a bit pissed off that bzr needs more than 200 MB of RAM to checkout d-i
<Martyn> armin76: Nope, can't access uboot from video
<Martyn> armin76: uboot doesn't seem to have framebuffer
<armin76> ok. thanks :)
<Laibsch> Hello
<Laibsch> I come from an Openembedded background, but as a user of Ubuntu I'm increasingly interested in Debian/Arm and Ubuntu/Arm
<Laibsch> I'll have a few dumb questions if you don't mind
<Laibsch> Why are karmic and lucid only available for armv6 and armv7 respectively?
<Laibsch> I have a Sharp Zaurus spitz, that is armv5te and I would like to see if I can't get some kind of Ubuntu running on it
<lool> Laibsch: We build natively and we don't have enough hardware or manpower to build and qa multiple flavours
 * lool &
<Laibsch> lool: Hi
<Laibsch> Nice to see you again
<lool> Hey
<Laibsch> What do you mean "/me &"
<Laibsch> I take that as "me too"
<Laibsch> You have a spitz as well?
<lool> I mean I'm putting myself in the background
<persia> '&' as in backgrounding
<lool> As in going to sleep
<Laibsch> I see
<Laibsch> good night
<lool> you too
<Laibsch> Just five more minutes?
<Laibsch> lool: I understand your question that if more people with more hardware where trying things out there is nothing in the way of relaxing armv7 to armv5te, for example?
<Laibsch> Correct?
 * Laibsch REALLY hopes that assumption is correct
<Martyn> Laibsch: No, the armv7 + thumb was pretty much a -requirement- for lucid
<Laibsch> :-(
<Martyn> armv5 support is dropped
<Laibsch> d'oh
<Laibsch> Can you explain why?
<lool> Laibsch: We want v7 + thumb2 in any case due to performance benefits on the platforms we mainly target
<Martyn> thumb2ee support
<persia> It's a parallel set of reasons to the reasons that real i386 isn't supported by the i386 flavour anymore.
<Martyn> so even armv6 is dropped
<persia> Basically, newer code runs faster on newer chips.  As there aren't a lot of people who run Ubuntu ARM right now, the baseline has been set high.
<Laibsch> I have a Freerunner that I don't use for anything else
<persia> This *should* reduce complaints about insufficient optimisation in the future.
<Laibsch> So I guss that will have to become the test target, then
<persia> I thought the freerunner didn't even support ARMv4 fully.
<Laibsch> Oh no!
<Laibsch> Well, I think I'll give it a try nonetheless
<Laibsch> and don't expect anything really working
<Laibsch> Well, if all else fails, at least Debian seems to run on the Freerunner
<Martyn> Since new cheap platforms are now mostly v7 (beagleboard, etc) this shouldn't be a huge problem
<Martyn> we'll see more platforms based on the omap3xxx omap4xxx armada smooth-stone, etc...
<persia> There's even stuff in nice consumer plastic boxes (like the Efika MX and Netwalker)
<Martyn> true
<Martyn> *curses that his Pegatron i.mx51 board isn't as easy to reflash as the Efika MX*
<Martyn> I mean, I --thought-- the hardware would be identical
<Laibsch> The way ubuntu-arm works is to compile natively or pull packages from the repo, right?
<Laibsch> Openembedded used cross-compilation
<persia> Martyn: There's something special about those boards.  The Netwalker is similarly trivial to reflash.
<persia> Laibsch: Indeed.  Full native compilation.  This will become less painful when the rumoured >1GHz >1GB devices become easily available.
<Martyn> persia : *nod*  Driving me up the wall though ...
<Martyn> persia: I'm --working-- on it as hard as I can.  -lol-
<Martyn> It's not that easy to tape out a chip, yanno?
<persia> Martyn: given the time, you're probably stuck until Sunday night, but I think you need to get support from Pegatron directly for those.
<persia> Or at least I haven't heard of a sufficient release that normal folk can get them.
<persia> Martyn: Understood.  I'm looking forward to new toys, although I'm hoping you can fit it in a smaller box.  Something the size of a Mac Mini would be a perfect addition to my desktop :)
<Martyn> persia : We can fit into a 5cm x 5cm board :)
<Laibsch> http://unstable.buildd.net/buildd/armel_Failed.html nice, Debian is even building opie!
<persia> With all the power you showed at UDS?
<Laibsch> hm, seems to be something else from what I was expecting
<Martyn> persia : more performance, less power
<Martyn> persia: We're probably now going to be able to clock up to 1.6, maybe 1.8GHz
<persia> Oh, excellent.  And I presume that someone is going to package that into a set-top or monitor-back or similar form-factor?
 * persia has a weakness for plastic cases
<Laibsch> Are you guys intensively using icecc or distcc or is all compilation really done on arm devices?
<Martyn> compilation is done natively
<Martyn> persia : It's an SoC for anyone to package, but I believe the majority of them are going to be stuffed into high-density clusters in a blade, 1U, 6U or whole rack chassis
<Martyn> perisa : 30 to a board or some such
<persia> Martyn: Yeah, I suspect you're right.  Same issues I have getting a Sparc: my use case is the extreme minority.
<Martyn> persia : What I /can/ guarantee is that we're going to produce a ton of development boards
<Martyn> with at least TWO chips each
<Martyn> so you can practice making little clusters
<persia> And I can probably stuff one in an old NAS or something.  I'm just a bit lazy :)
<Martyn> heh
<Martyn> likely they will come in a little plastic box
<persia> Oh, now I suspect I'll have to get one :)
<kblin> Martyn: yay, new toys :)
<Martyn> and if I have anyting to do with it .. the system images will be <easy> to find, the wiki will be <open> to edit, and god-damnit the thing will run ubuntu
<persia> Martyn: If I can add to the wishlist: could you add a dual-booting bootloader, so that one can easily swap userspace/kernels with a low chance of bricking the unit?
<persia> (or n-booting :) )
<persia> While I have issues getting new kernels for the Netwalker (I should go study kernel hacking), I know that I've used this a couple times to reinstall with great confidence.
<plars> persia: he left already
<persia> Yeah.  That happened during my first response.
<persia> But I figured I'd complete my thinking for the logs.
<plars> :)
<persia> Maybe someone else is also making cool devices that run Ubuntu and will also implement it :)
<persia> It's really cool.  If I hold down both mouse buttons, I boot off SD, and if I don't, I boot off SSD.
<persia> makes it trivial to install different flavours, etc.
<persia> Unfortunately, most of the cool flavours with which I want to play don't exist for Jaunty :(
<plars> but at least you know you have an easy way to test it if you (or anyone else) feels like hacking it together :)
<persia> Absolutely.
<persia> And I'm sure someone will produce a newer kernel someday.
<persia> But for some reason, nobody outside Japan seems to be buying these.  I've only enountered one user from elsewhere.
<GrueMaster1> Maybe if/when device tree ever hits the streets
<persia> So there's almost no English-language sites about it.
<persia> GrueMaster1: When that happens, I get a kernel in just a few hours :)
#ubuntu-arm 2010-02-20
<Tscheesy> yess - nor-Booting please ;) or even better an open capable Bootmanager in nand/nor preinstalled - beeing afraid to damage the device can hold one from action
<ogra> lool, meh, plymouth chokes in qemu-arm-static
<ogra> root@osiris:/# plymouth-set-default-theme
<ogra> qemu: Unsupported syscall: 250
<ogra> plymouth: ply-event-loop.c:466: ply_event_loop_new: Assertion `loop->epoll_fd >= 0' failed.
<ogra> qemu: uncaught target signal 6 (Aborted) - core dumped
<lool> ogra_: Looks like this needs a port of epoll()
<ogra_> ah
<lool> epoll_create() is 250
<ogra_> removing the plymouth hook lets me at least roll an initramfs in the chroot :)
 * ogra_ currently has to fight with completely screwed X on his main machine
<ogra> hmm, wasnt X but gtk
<armin76> lool: i hit the ram issue with bzr on the emacs repo...stupid bzr, it made my sheevaplug run oom
<armin76> bzr co --lightweight worked, though
<asac> armin76: version?
<asac> try latest ... maybe its better - otherwise file a bug ;)
<asac> ogra_cmpc: on cmpc?
<asac> fun
<ogra_cmpc> yeah
<ogra_cmpc> easier to work from living room on gtk formatting in rootstock :)
<asac> hehe
 * ogra_cmpc doesnt get it
<ogra_cmpc> newstring = _('<b>Error:</b>\n\n %s'), string
<ogra_cmpc> newstring apparently ends up as a tuple here
<ogra_cmpc> i dont understand why
<ogra_cmpc> argh
<ogra_cmpc> silly me
 * ogra_cmpc replaces the comma with %
<armin76> asac: dunno, debian carl
<lool> asac: In my case it was latest lucid from < 2 days ago
<lool> ogra_cmpc: Would you file a bug on the missing plymouth syscall?
#ubuntu-arm 2010-02-21
<saeed> canonicals, installing lucid on sata hdd on dove fails, http://paste.ubuntu.com/380922/ contains the /var/log/installer/debug file
<armin76> you need to use gentoo
 * armin76 runs
<persia> saeed: You'll probably do better to file a bug against debian-installer and attach the log (and maybe more: I know I've seen syslogs requested from failed installs as well).
<saeed> ok, I'll also run ubiquity with --debug
<saeed> l
<lool> saeed: Could you file a bug against flash-kernel and you /var/log/installer logs?
<lool> Ah persia asked you already
<lool> saeed: This seems to be due to flash-kernel not handling your particular setup
<lool> saeed: Did you format in any particular way?
<saeed> lool, I used default options, and in the partitions section, I chose the second option (use full disk)
<saeed> lool: should I modify the bug to be set for flash-kernel instead of debian-installer?
 * persia was giving completely generic advice without insight into the hardware or the issue, so should not take precedence.
<lool> saeed: It's ok, it might actually be in some partition manager code instead of flash-kernel
<lool> saeed: In general, if you're discovering installation bugs using the installer from the live CD, file them against ubiquity and subscribe ubuntu-armel; if using the text mode installer, file them against debian-installer and subscribe ubuntu-armel; we will eventually figure out which component is affected and triage them
<lool> saeed: if you know which specific component it is, you may file it directly there of course!
<ogra_cmpc> or just use: ubuntu-bug ubiquity from a terminal
<ogra_cmpc> that will set all tags and attach all relevant logfiles
<ogra_cmpc> (needs network connection on the board though)
<zumbi_> do you support substvars (@foo@) on debian/control file in Ubuntu?
<persia> I generally use ${foo:Depends} or ${foo:Recommends} for some value of foo, but yes.
<persia> I believe it must be ${variable}
<persia> man deb-substvars for more info
<persia> Note that some people use a debian/control.in which uses autotools to generate debian/control, but that's usually more than is required.
<zumbi_> persia: using substvars on control files violates debian-policy and it is not sane, it is better to use control.in files approach
<zumbi_> persia: i was wondering this because I saw openjdk (doko package) using substvars on control file, but only in ubuntu, maybe you had done the modifications to the tools for this behaviour to be sane
<zumbi_> lool: ^
<persia> zumbi_: Um, using things like ${shlibs:Depends} and ${misc:Depends} violates policy?
<persia> I'm very suspicious about that.
<zumbi_> persia: no, that is allowed
<persia> zumbi_: Then I think I don't understand you.
<zumbi_> persia: line 38: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk6/annotate/head:/control
<persia> Why is this bad?
<persia> I agree it's kinda excessive.
<zumbi_> persia: and line 36 36 	230 	
<zumbi_> persia: uhm... i might be wrong as it uses ${foo:bar} not @foo@ (as more common on control.in)
<persia> I don't think using @foo@ in debian/control is acceptable: I think that has to be in control.in
<zumbi_> persia: it would be dangerous because you can't ensure that the substitution will be done correctly (at the time it should be done), but I guess it is right as packagers know very much what they do
<persia> But I don't see an issue with ${foo} in debian/control, as long as it doesn't affect anything in the source stanza or any of the names of the produced binary packages.
<zumbi_> persia: right, bad call... thanks
<persia> Well, it always happens at dpkg-gencontrol time.
<persia> So as long as debian/substvars is correct by the end of the install, it ought be safe.  Mind you, policy demands that debian/substvars be removed in clean, if it can exist, so it's always generated afresh in debian/rules at build-time.
<persia> But it still requires care, and can be done in vary awkward ways.
<persia> (and it's possible to violate policy with it, if one isn't careful, by fiddling with the source stanza or the binary package names)
<zumbi_> yes, i agree :-)
<lool> zumbi_: Sorry, which part do you want me to comment on?
<lool> zumbi_: I don't see where substvars are a problem in openjdk-6's debian/control
<zumbi_> lool: no, no problem, i was wrong.. badcall
<persia> zumbi_: Don't worry about it: It's better to raise anything you see like that, rather than let it slide, because it might be a huge potential bug.
<zumbi_> persia: hehe, i was only trying to understand if ubuntu had done some patching to made this posible, it was just curiosity.
<hrw> morning
#ubuntu-arm 2011-02-14
<smplman>  i have ubuntu 10.10 running on my beagleboard xm. im trying to configure my lilliput um70 7" usb touchscreen. I have the screen working with the display link drivers, but i cant get the touchscreen to work.
<smplman> i have looked through the input devices, but i cant find any for the usb touchscreen. I did find an event for the power button on the monitor.
<xerebz> i'm trying to get out audio to come out of the beagle
<xerebz> i tested powered speakers on the same file on a fresh mplayer install on my laptop and it was fine
<xerebz> i used the speakers on the bb
<xerebz> running the same file and mplayer but there's no sound
<xerebz> what are some of the things i can check to see what's wrong?
<xerebz> btw mplayer acts the exact same it looks like it's playing i just can't hear anything
<hrw> morning
<persia> hrw, You had a flash-kernel fix for the efikas: have you tested that with linux-linaro-imx51?  Does it work?  Has it been applied to natty?
<hrw> persia: merging flash-kernel is still on ogra's todolist
<hrw> persia: and I did not tested it with other kernels then own ones (or genesi one)
<persia> Where is your branch/bug?
<hrw> bug 671027
<ubot2> Launchpad bug 671027 in flash-kernel "Add Efika MX Smartbook/Smarttop support" [Undecided,New] https://launchpad.net/bugs/671027
<persia> Thanks.
<persia> What is expected to create /boot/boot.script?
<persia> Also, this looks like it wouldn't work for a bare install (where /boot/uImage and /boot/uInitrd don't exist yet)
<lool> hrw: i see you're adding efikamx support in your patch as well; did you test that successfully?
<hrw> lool: no, but genesi version had same code for both
<hrw> lool: it is cleaned version of their code
<lool> Ok
<hrw> persia: I had /boot/boot.script on my system, similar one I have on panda/ubuntu. where from it came? no idea
<hrw> persia: and this code is not perfect but works for me. there were no comments on improving code anyway
<persia> We'll need something to create it, if we expect it to be there.  Obviously, if it's already there, fine, but consider the case where someone wants to completely reinstall.
<persia> Also, why comment out check_subarch?
 * persia is currently trying to provide comments on code
<hrw> persia: let me boot efika to check at original code
<persia> Thanks.  If you're busy with something else, feel free to tell me to ask about this another time :)
<hrw> persia: add comments to the bug - this will maybe take genesi guys to react too
<hrw> *** /dev/sda2 will be checked for errors at next reboot ***
<hrw> I need to track down script which says that and kill it
<hrw> persia: looks like 'check_subarch' checks does machine runs proper flavour of debian/ubuntu kernel. if this is right then it has no use on efika so far as it runs only unofficial kernels (at least with ubuntu)
<hrw> whole flash-kernel script is full of copy/paste code ;(
<hrw> efikamx_flash_kernel() is more or less based on code for dove
<persia> hrw, The efika can boot with linux-linaro-imx51, so we should expect that.  That's perfectly official.
<persia> lool, hrw: would you mind attaching /proc/cpu for each of the MX and Sb to bug #718615?  Needs samples to match against the kernel selector.  Thanks!
<ubot2> Launchpad bug 718615 in base-installer "Please add support for linux-linaro-imx51 on efika MX and efika SB" [Undecided,Incomplete] https://launchpad.net/bugs/718615
<lool> persia: I'm not a fan of subarch detection; we're trying to build a common kernel with support for more than one SoC, so uname -r wont mean much anymore
<hrw> persia: I have efikasb only
<hrw> added
<lool> persia: cpuinfo > will add when I get the chance to boot it
<hrw> persia: efikamx can be taken from flash-kernel patch ;d
<persia> hrw, I need the *complete* cpuinfo, for the base-installer test suite.
<hrw> lool: subarch is used in many places other then just scripts like flash-kernel
<persia> lool, Thanks.  no huge rush.
<hrw> persia: mkey
<persia> I suspect that the MX looks almost identical to the SB, but want to be careful so that I don't break MX folks.
<persia> (especially because right now, MX works and SB doesn't, with the in-archive kernel)
<hrw> define 'works' probably
 * hrw -> breakfast
<persia> The information I have is that linaro-linux-imx51 boots successfully on the MX.  I'm following upstream, and will prepare a queue of other things to get merged just after the update to 2.6.38-rc5, which *should* support SB as well.
<lool> hrw: Where is it used?
<lool> hrw: There is another subarch concept in d-i, which I believe is computed differently (from cpuinfo, not uname -r)
<hrw> ok
<hrw> persia: looks like you got all info for bug 718615 now ;)
<ubot2> Launchpad bug 718615 in base-installer "Please add support for linux-linaro-imx51 on efika MX and efika SB" [Wishlist,Incomplete] https://launchpad.net/bugs/718615
<persia> Cool.  Thanks.
<persia> lool, hrw got steev to submit the cpuinfo: no need for you to hunt it up later.
<hrw> steev has to2 and to3 efikamx so extra info were given too
<lool> persia: thanks
<ogra> you would need to extend archdetect to make use of the actual revision info, currently all detection is based on the Hardware: line
<davidm> g'day persia you are around quite late today
<persia> davidm, DMB meeting today.
<persia> ogra, I'm going to pretend to not care, unless you see some reason why it's important to distinguish the T02 from T03 devices.
<ogra> i dont think it is
<ogra> just noted that the different cpuinfos wont gain you much there
<hrw> the only difference is neon in to3 and noneon in to2 - but thats handled by kernel to not give neon cpuflag for to2
<persia> Anyway, I'll toss them into the test cases.  Doesn't matter.
<xerebz> does anyone have a quick link to how to fix the no audio issue for beagleboard xms?
<rcn-ee> xerebz, http://bazaar.launchpad.net/~beagleboard-kernel/+junk/2.6-stable/view/head:/patches/beagle/0001-xM-audio-fix-from-Ashok.patch seems to work for me..
<persia> Has that been proposed for the Ubuntu kernel?
<JYRO> hi everybody....
<JYRO> where I download the arm toolchain??
<JYRO> I have the 3.3.2 version... but I need the 4.1 version
<hrw> JYRO: which ubuntu ver you are using?
<JYRO> one moment please while I see that
<JYRO> jaunty, and 2.6.28.19 kernel
<hrw> sorry, there are cross toolchains for lucid and newer only
<JYRO> really?  :(
<JYRO> ok.. in my laptop I have a 10.10 ubuntu version.....
<JYRO> How I can install the arm toolchain?
<JYRO> I have my laptop at my side
<hrw> on 10.10: apt-get install gcc-arm-linux-gnueabi
<ogra>  see the channel topic
<ogra> there is a link
<hrw> substiture gcc with g++ gobjc gfortran if want other langs
<JYRO> this install get the utilbins too?
<hrw> which utilbins?
<JYRO> I need to compile a kernel for a ARM target.... just I need the toolchain?
<hrw> you may need uboot-mkimage package too
<prpplague> JYRO: if all you need is just a toolchain, you can try getting the codesourcery packages
<prpplague> JYRO: http://omapedia.org/wiki/Android:_Configuring_the_Host_PC#ARM_Cross_Compiler
<hrw> prpplague: since 10.10 ubuntu contains cross toolchain
<prpplague> hrw: ahh
<hrw> prpplague: took me some time to make them ;D
<JYRO> I'm using a M-501 development kit....  in this moment I learn how to compile a kernel for a target.... then I would try probe a example module ....
<JYRO> hrw... I try use the apt-get command and the system said that it can't found the gcc-arm-linux-gnueabi packet
<JYRO> hrw... I'm sorry... but my ubuntu version is karmic ....
<JYRO> is it the reason why I can't install the arm toolchain?
<hrw> like I said - you need at least 10.04 (lucid)
<JYRO> I'm sorry for that....
<hrw> no need to
<JYRO> hrw another question...  I find this page
<JYRO> http://www.gnuarm.com/
<JYRO> can I install this toolchain??
<hrw> better go to http://emdebian.org or to code sourcery labs
<hrw> I would avoid anything under gcc 4.3.3
<hrw> which is old too
<JYRO> who is the last gcc version??
<hrw> 4.5.2
 * hrw ends a day
<JYRO> hrw... a last question...
<hrw> go
<JYRO> can I install debian packets in ubuntu?? I'm sorry for this question, but I newbie :$
<hrw> I would not suggest it for a newbie.
<JYRO> can I crash my system if I can't install it correctly??
<JYRO> :$
<JYRO> someone knows how I can get the public key from http://emdebian.org??
<LetoThe2nd> JYRO: i guess you're here... and therefore, i suggest to start reading - at the top.
<LetoThe2nd> http://www.emdebian.org/crosstools.html
<LetoThe2nd> JYRO: there's a topic "secure apt"...
<JYRO> LetoThe2nd... thanks for that... I read this link now
<LetoThe2nd> JYRO: i've seen that the documentation for your specific development board is outdated and rather crappy... but in general, reading is a _very_ good idea if you want to get into arm/embedded/kernel stuff :-)
<LetoThe2nd> JYRO: BTW - your target is not able to run ubuntu, if that's what you're heading for.
<JYRO> LetoThe2nd...  I tell you that I need....
<JYRO> I have a M-501 target, is a development kit for a ARM91 SoC....
<LetoThe2nd> JYRO: i know. you told us, and i looked it up.
<JYRO> ok... :$
<JYRO> in this machine... I have the 3.3.2 version for arm-linux toolchain.... that's very old....
<LetoThe2nd> JYRO: and to get you nomenclature right: it's not an "arm91" development kit, it an "arm9" platform, and in that one in the at91 family incarnation myde by atmel.
<LetoThe2nd> JYRO: i know, you told us.
<JYRO> ok LetoThe2nd...  thanks
<LetoThe2nd> JYRO: but because you are asking in the #ubuntu-arm channel, there is the possibility that you might be aiming to run ubuntu on that target. and that is not possible.
<JYRO> I know it, I don't need to run ubuntu in this target... just I need to run the 2.6 kernel linux
<JYRO> am I in the wrong place?
<GrueMaster> How is the natty-server-armel+dove.img even building?  I thought the dove kernel was removed from natty?
<GrueMaster> JYRO: Unfortunately, yes.  This channel is specifically for developers discussing current ubuntu builds on current arm hardware.
<LetoThe2nd> JYRO: a bit, yes :-) it's not much of a problem, but mainly this channel is about running ubuntu on arms, not about making arms work using ubuntu as the development platform.
<GrueMaster> Try #debian-arm on OFTC network.
<LetoThe2nd> JYRO: you maybe want to checkout elinux.org and see if they have an IRC channel. or if you have decided which toolchain to use, head for their channel.
<LetoThe2nd> JYRO: specifically: http://elinux.org/Toolchains
<JYRO> LetoThe2nd: thank you very much....
<JYRO> GrueMaster: thank you too!
<JYRO> it's too late for me .... I'm going for my house now...... thanks for all!!
<prpplague> hey is there any updated info on ubuntu build for the ac100?
<ogra> prpplague, there is a guy in the #ac100 channel hacking on getting the overlay filesystem from linux4tegra to work on it, beyond that not much, without nvidias help it will always be hackish and unstable
<prpplague> ogra: ahh
<ogra> look for "phh" in the channel if you want more details
<ogra> i dont touch the L4T crap
<prpplague> ogra: i was just curious
<ogra> k
<ogra> :)
<prpplague> ogra: there were some conversation threads on some of the hardware channels about doing open source laptop/netbook design
<ogra> heh, i doubt nvidia will ever get to that
<ogra> they are nvidia after all
<prpplague> ogra: sorry, the conversation turned to asking if ubuntu was available for any arm based netbook
<ogra> ah, ok
<ogra> yes, indeed, the image is publically available
<prpplague> ahh dandy
 * prpplague would love to do a omap4 netbook if only he could get the chips
<ogra> either in my plain version that doesnt use any nvidia bits and thus has no features or in phh's version that has all features but is neither upgradeable nor stable
<ogra> i heard it slowly gets better wrt chips
<prpplague> ogra: indeed
 * armin76 throws l4t at ogra 
<armin76> prpplague: you can also use gentoo :D there's some ppl on #ac100 using gentoo as well :D
<GrueMaster> But who (in their right mind) would use gentoo?  :P
<armin76> </spam>
<armin76> GrueMaster: i'm pretty sure your dreams are powered by gentoo :P
<prpplague> armin76: hehe indeed
<armin76> who doesn't like nice gentoo penguins? :(
<GrueMaster> Due to international laws, I can not state publicly what powers my dreams.
<xerebz> hello i've been given a bug patch that consists of a uimage files and a modules.tar.gz how can i apply this patch?
<XorA> boinmg
#ubuntu-arm 2011-02-15
<xerebz> is there some timeout to the console? i'm leaving an apt-get installing and after a couple minutes of being idle, the monitor turns off and it seems like the install is halted until you move the mouse..
<xerebz> the ubuntu demo image has a timeout of the screen and it seems like the system too.. is there a way to disable this?
<xerebz> like an idle timer until the screen goes blank
<sveinse> (How) can I download an ubuntu source package for natty armel from my maverick amd64 host?
<amitk> the source package should be the same regardless of arch
<amitk> so if you have the right deb-src lines 'apt-get source <package>' should work
<cooloney> sebjan: hi sebjan, are you around?
<sebjan> cooloney: hi, yes!
<cooloney> sebjan: i just updated the status of bug 633227
<ubot2> Launchpad bug 633227 in linux-ti-omap4 "instabilities with highmem activated" [High,Confirmed] https://launchpad.net/bugs/633227
<sebjan> cooloney: yes, I saw that. I cant' remember if I tested with an old panda prototype or with a official one
<sebjan> cooloney: but I know that I tested also on Blaze with an E2.1 chip and I reproduced the issue there
<sebjan> I can make a test with a recent panda, but I don't expect any surprise here
<hrw> cooloney: I have mem=1G problems on EA1 and on A1
<hrw> es2.0 and es2.1
<cooloney> yeah, but Ming Lei can't reproduce that.
<cooloney> and with mainline kernel and Angstrom file system, system is unstable when building kernel
<cooloney> i'll ask him to provide some information about his board
<hrw> cooloney: let he fill tmpfs with 512MB of data first
<hrw> it helped for me to get it fail faster
<cooloney> hrw: hmmm. ok, i will let him know
<persia> sveinse, Note that if you need a *natty* package from a maverick system, you'll need to put a natty deb-src line in sources.list (or apt-get source in a natty chroot)
<sveinse> persia, so I discovered. thanks
<XorA|gone> grrrrrrrrrrrrrrrrrrrrrrrrrrrr
<ogra> grrrrr ?
<XorA|gone> just grrrrr
<janimo> rsalveti, so rootstock needsa chaging?
<rsalveti> janimo: yup, just to get the omap3 kernel
<rsalveti> easy change
<rsalveti> was planning to work on this soon
<rsalveti> together with other rootstock changes
<ogra> its a trivial change
<rsalveti> yup, but need testing
<ogra> grrr .... still no trace of unity-2d at http://ports.ubuntu.com/ubuntu-ports/pool/main/u/
<janimo> ah ok, I did not know rootstock did something hardcoded with kernel name
<ogra> it pulls from the netinstall dir
<rsalveti> janimo: yup, getting the versatile one
<ogra> since we have a plain vmlinuz there
<rsalveti> only when using the full emulation mode
<ogra> yep
<topfs2> rsalveti, not sure if you saw it but I have xbmc + gstreamer with h264, the other codecs are being a little pain (mostly because I'm not sure what the demuxer should output as caps, talking with gstreamer crew about this)
<topfs2> this is with our player and all our post-processing stuff
<rsalveti> topfs2: cool, that helps with most of the cases already
<rsalveti> good to know
<rsalveti> once you have it working with gst it shouldn't be that hard to support other formats
<rsalveti> but I don't know the code
<topfs2> its a successful poc, have quite a lot in school atm so not sure when I will be finishing it. I have no doubt that we can add more formats as time progress
<topfs2> have a vaccation comming up but will try to clean it up after that and push to a branch so the code is available for the world :)
<rsalveti> topfs2: awesome
<topfs2> off to school again now though :)
<topfs2> ttyl
<rsalveti> later
<ogra>  netbook-meta (2.040) natty; urgency=low
<ogra>  .
<ogra>    * Refreshed dependencies
<ogra>    * Added transmission-gtk to netbook-recommends
<ogra>    * Added unity-2d to netbook
<ogra> \o/
<ogra> curious if the images will build with that :)
<rsalveti> cool
<ctyler> davidm: prpplague in #pandaboard said we're building similar things. PandaStack being built to supplement our build farm: http://twitgoo.com/1z7sxh
<davidm> Indeed you are
<davidm> ctyler, http://dmtechtalk.wordpress.com/
<davidm> I'm planning on 20 pandas in a single 3U box
<davidm> all remote controlable and with a secure booting method
<ctyler> we're adding 15 Pandas to the Fedora-ARM build farm in stack form
<davidm> Also see: https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster
<davidm> I'm going to provide part numbers and directions so anyone can build 3U 20 device stacks
<davidm> ctyler, we are designing a daughter card that will allow a secure boot method, as panda has no secure booting
<davidm> anyone can overwrite the SD card, the daughter card stops that
<davidm> I'm just waiting on my pandas to free up
<ctyler> cool :-)  wish these things were shipping faster!
<davidm> ctyler, you and me both :- you and me both......
<ctyler> we just got our last 3 of 15 ordered in November, so they're starting to move, but man.
<davidm> Yep
<davidm> ctyler, Do you need remote control of the units and does secure booting matter to you?
<ctyler> no, they're builders in a koji system, which uses a mock (chroot) build environment
<ogra_> ctyler, any what prevents me from uploading a package with scripts that break out of that chroot and gain me access ?
<ctyler> ogra_: we'll know you you are :-)
<ogra_> ah
<persia> ogra_, Difference between distro builders and PPA builders.
<ogra_> so only signed up people can upload
<ctyler> the chroot isn't so much for containment as a clena buildroot
<ctyler> clean*
<ogra_> persia, yeah
<persia> Mind you, if the cluster servers were in general availability, the koji admin might be happier, but it's a balance of effort vs. trust.
#ubuntu-arm 2011-02-16
 * XorA|gone is back somewhere near Shinjuku again :-D
<dasilva333> hey guys ive tried much research still no luck, any one willing to help? im getting this error when i try to do df -h 'Stale NFS file handle'
<dasilva333> root@TonidoPlug:/etc/init.d# umount /dev/sdc1
<dasilva333> umount: /dev/sdc1: not mounted
<dasilva333> root@TonidoPlug:/etc/init.d# mount /dev/sdc1 /media/SeagateNTFS/
<dasilva333> mount: according to mtab, /dev/sdc1 is already mounted on /media/SeagateNTFS
<dasilva333> root@TonidoPlug:/etc/init.d# ls /etc/mtab
<dasilva333> ls: cannot access /etc/mtab: Stale NFS file handle
<ogra> new images building
 * ogra wonders about lool's change to qemu-kvm ... i thought all arm is done in qemu-linaro now
<lool> ogra: qemu-kvm still provides some shared binaries like qemu-img and needs to be built on ARM platforms
<ogra> ah, i thought all was migrated to linaro source
<lool> it also provides x86 machine emulation, for all arches, and that was failing to build on arm arches without some workaround in cflags -- I made sure the workaround is applied to all ARM arches, not just arm/armel
<ogra> yeah, then its clear
<Wizard> yu!
<Wizard> yo!
<ogra> there we go http://cdimage.ubuntu.com/ubuntu-netbook/daily-preinstalled/20110216/
 * ogra rsyncs 
<ogra> s/r/z/
<rsalveti> ogra: great, so this one is with unity-2d?
<ogra> yes
<ogra> manifest looks ok and the default session should be proper too
<ogra> but indeed all untested
<rsalveti> nice anyway
<rsalveti> where is GrueMaster :-)
<ogra> sleeping all day, as all these portlanders :P
<GrueMaster> I'm up.  What do you slackers want?  (btw:  it is 7:40am here)
<prpplague> if you are using pandaboard, please complete the survey at http://www.surveymonkey.com/s/Y2DN2CN
<prpplague> a chronos watch and some multimeters will be raffled off to those who complete the survey
<ogra> GrueMaster, pfft, its 5:41pm *here* !
<ogra> GrueMaster, unity-2d images are there, keep them and pet them, they might be unique (i will update to the latest unity-2d versions this week and the world might break)
<prpplague> ogra: hey you, fill in the survey
<prpplague> ogra: or else! we know where you live
<GrueMaster> Already running on omap4.  I need to revert one system back to Maverick for comparison, but I believe it is more useful currently on maverick.
<ogra> prpplague, uuh, then i'll better hurry !
<GrueMaster> prpplague: Done.
<prpplague> GrueMaster: thanks
<ogra> GrueMaster, yeah, maverick ppa has the newer versions
<GrueMaster> (or do I need to do it for each board?)  :P
<ogra> i'll Ã¼pull them over this week
<ogra> first step was to get the images ready
<ogra> though we're missing the icon theme apparently
<ogra> it works fine but has all the wrong default icons
<GrueMaster> What icons?  I have no icon list to launch from.
<GrueMaster> I have to revert to classic desktop to launch a terminal.
<rsalveti> prpplague: done
<prpplague> rsalveti: thanks
<ogra> GrueMaster, bug 719861 is about the icons apparently
<ubot2> Launchpad bug 719861 in gdk-pixbuf "After installation icon theme default to gnome-icon-theme and cannot be changed" [High,Triaged] https://launchpad.net/bugs/719861
<prpplague> if you are using pandaboard, please complete the survey at http://www.surveymonkey.com/s/Y2DN2CN  , the survey will only be up for a short time, giving away a chronos dev kit to one winner
#ubuntu-arm 2011-02-17
<dasilva333> hey guys
<XorA|gone> morning
<prpplague> hey bud
<prpplague> XorA|gone: you get a chance to fill in the pandaboard survey?
<XorA|gone> prpplague: already done
<prpplague> XorA|gone: dandy
<XorA|gone> probably the only hope I have of getting one :-D
<prpplague> a chronos watch?
<prpplague> XorA|gone: you still haven't gotten a pandaboard?
<XorA|gone> prpplague: nope
 * XorA|gone is now starting to hate hardware designers
<XorA|gone> prpplague: thats not you BTW :D
<prpplague> hehe
<hrw> flash-kernel needs changes for panda ;(
<hrw> 1. 2.6.38-rc has "OMAP4 Panda board" not "OMAP4430 Panda Board"
<hrw> 2. linaro kernel is 'omap' not 'omap4' flaovour
<janimo> hrw, you mean /proc/cpuinfo changed for panda?
<hrw> yes
<hrw> who knows, maybe one day there will be 4440 based panda
<janimo> on a panda, how can I pass boot arguments to the kernel from u-boot without adding a new boot.scr ? I'd like to pass nosmp
<hrw> easiest it to edit boot.scr
<lool> hrw: I'm afraid there are multiple versions of the kernel which can boot panda in natty and the latest flash-kernel changes don't allow this
<hrw> I know
<ogra> well, -omap is tricky, tres is trivial
<ogra> s/tres/the rest/
 * ogra doesnt get where the letters went, i definitely typed them
<hrw> I prefer to not touch flash-kernel. my changes ends in ogra's merge queue which is huge enough
<ogra> hrw, i will surely fix the cpuinfo bit but would appreciate a patch to handle the case where the package is named -omap
<ogra> i fear that will break NCommander's changes for generic kernel installation
<persia> Why does flash-kernel limit which kernels can boot?  Shouldn't it take the latest usefully installed kernel, and perform the appropriate action?
<ogra> hmm, wait, you are right, flash-kernel doesnt care for package names at all
 * ogra re-checks
<hrw> it cares for flavour names
<ogra> it shouldnt
<persia> If it cares for flavour names, it needs to be fixed.
<hrw> then kill sub_arch check
<persia> Hrm, but it ought care about subarch.
<ogra> persia, it does that since NCommander added his subarch stuff
<ogra> uname -r | sed -e 's/.*-//'
<ogra> it doesnt care for package names but for flavour in uname
<persia> Right.
<ogra> which also breaks blaze
<persia> Debian flash-kernel uses kfile to determine subarchi.
<persia> With subarch=$(echo "$kfile" | sed -e 's/.*-//')
<persia> The confusing bit is that the Debian version seems to be willing to accept kfile=/boot/vmlinuz and I'm unsure how that works with check_subarch
<hrw> flash-kernel require rewrite I think
<persia> Ah, I see.  if subarch="", check_subarch always returns true.
<ogra> that doesnt matter
<ogra> what matters is that check_subarch is completely ignored on dove omap and omap4 arches
<persia> Ah, because there are no "machine" entries.  I see.
<ogra> yep
<ogra> the prob is that instead of guessing for a proper kernel the code just makes it ignore the check
<ogra> and installs whatever kernel is available
<ogra> to be proper implemented it would need more of a database and some clever algorhythms to do guesswork
<persia> Right.  I see the issue now.  flash-kernel is just entirely different for omap|omap4 than everything else, which is a bit confusing.
<ogra> a proper implementation would be possible with devicetree db's
<ogra> you could match kernel features against the actual hw
<persia> How would that work?
<ogra> the kernel ships the devicetree data anyway
<ogra> so you iterate over the devices and match them against the actual HW of the board on your first run or from d-i
<ogra> if you find the kernel supports a) the arch and b) enough devices for booting, you write a flag
<ogra> that flag is looked up on flash-kernel run
<persia> How does one define b) ?
<ogra> rootfs device, serial support and basic init ... you need a db for that indeed
<persia> Why do we care about serial?  How can we identify "basic init" for arbitrary boards?
<ogra> you could spill a warning if not everything is supported
<ogra> you cant you will always need a matching db about whats needed for init
<ogra> but that way you can at least support a wider range of HW without breaking it for totally unsupported stuff
<persia> Makes porting new devices kinda annoying.  I thought with devicetree, we were expecting the kernel to be able to do discovery-boot on arbitrary devices.
<ogra> only for devices it has a machine file for
<persia> I thought you would be able to specify a machine file on the kernel command line.
<ogra> you still have the toplevel subarch
<ogra> i.e. take the touchbook ...
<ogra> essentially its a beagle
<ogra> and you can use a beagle kernel on it
<ogra> but wont have much devices
<ogra> since the devices are special and never have been pushed upstream
<ogra> you will still be able to boot into serial with any std beagle kernel though
<persia> So, let's say there is a device with necessary upstream support.  Should that just work?
<persia> And with the current model, what ought be done differently for the touchbook?  It seems to me that it wouldn't be any different to use the machine specifier or running_subarch.
<persia> (as the subarch isn't changing)
<ogra> it would be able to tell you that you only have minimal kernel support and optionally ask you about proceeding or not
<persia> So, increase the verbosity of the "Generic Subarch" warning, and ask the user to confirm the operation?
<ogra> leave the user the option to not mess up his system
<persia> I can't reconcile wanting to be able to boot (perhaps with confirmation) on devices the code doesn't know about and wanting to have a comprehensive DB controlling the booting.
<persia> How would that work?
<ogra> heh, well, if you run flash-kernel you already have a working system
<ogra> if you would run it on a kernel that drops features you surely would want a warning
<persia> Yes, but if you run flash-kernel-installer, you may not have a working system yet.
<ogra> if you run flash-kernel-installer on such a system, d-i has a bug
<persia> Huh?  Why?
<ogra> it shouldnt install on unsupported HW
<ogra> actually the check should happen way way earlier
<persia> So, I'm a user.  I copy some data I downloaded off the internet onto my card.  I stick it in my device.  I turn it on.
<ogra> and d-i (or whgatever else) politely tells you that you in max will run that device with a serial console
<persia> At this point, there are three options.  If I'm booting an alternate image, base-installer checks to make sure I'm installing an acceptable kernel.
<ogra> or tell you its not supported at all
<ogra> or it just works
<persia> If I'm booting a live image, there is no check.
<persia> if I'm booting a pre-installed image, there is no check.
<ogra> right, we should add that to jasper
<persia> jasper should probably leverage base-installer to do that.
<ogra> yes
<persia> But there's still the live image case.
<ogra> its on my WI list
<persia> Heh, OK.
<ogra> thats why i asked you about your tool in main ;)
<persia> How is that related?
<ogra> device-detect gets me more detailed info
<persia> Than what?
<ogra> archdetect (which is what base-installer uses)
<persia> Please *don't* use devicetype-detect for that.
<persia> You'd just be duplicating the test suite, etc.
<ogra> but i need to match against more detailed data than archdetect can deliver
<persia> No you don't.
<ogra> jasper *is* duplicating stuff
<persia> If you need more specificity, you need to get that into archdetect
<ogra> thats its whole purpose
<ogra> no, i dont
<persia> I thought we had a UDS session about that.
<ogra> archdetect does exactly what its supposed to do
<persia> And decided that jasper should *not* duplicate stuff.
<ogra> but doesnt get me enough data back
<ogra> jasper *has* to duplicate casper functions
<ogra> thats its whole purpose
<persia> What data do you need?
<ogra> if you would check live images you would have to implement it in casper
<ogra> arch *and* device
<persia> Why?
<ogra> because our kernels can support more than one device
<persia> So, back to my story.
<persia> I boot into the live image.  Everything is working.  I press install.
<ogra> and it would be clever to i.e. be able to shut off gdm if you detect you run on a beagle C4
<persia> It installs, the install runs flash-kernel installer.  It installs the kernel that I booted.
<persia> Why do I care if I'm using a device that you've never heard about?
<ogra> yeah, thats no issue
<persia> It is if you care about device.
<persia> Because if you care about device, you're going to tell me it doesn't work, and maybe try not to install.
<ogra> exactly
<persia> So it is an issue, which is a bug.  Let's look at another way to do it that doesn't have that problem.
<persia> As I see it, we have two ways we can fail.
<persia> We fail if we write a kernel to a device which can't use it, and render it unbootable.
<persia> We fail if we refuse to work on a device on which the kernel works.
<persia> Do you see any others?
<ogra> half way working devices
<ogra> and devices for which this image isnt suited
<ogra> (beagle C4 with a full desktop for example)
<persia> I refuse to have an opinion on whether someone wants to run a given image on a given device.  That decision belongs to the user.  All we can do is suggest things.
<ogra> we can adjust defaults
<persia> I don't think that's being nice.
<ogra> if i turn off gdm on a C4 thats helping the user and gdm is still there to be started if he wants to
<persia> Let's imagine someone has a beagle C4 that they hacked to have 1G ram and are running overclocked in liquid nitrogen bath: who are we to say they can't run normal desktop?
<ogra> they can
<ogra> and given they were clever enough to hack it that way i would trust them to find out how to re-renable gdm
<persia> Anyway, we're getting sidetracked.  Let's ignore all the defaults for now.
<persia> So, about devices that only kinda work: is the failure if we boot our kernel, or if we don't boot our kernel?
<persia> I'll claim the failure is to not boot the kernel, as otherwise we can never collect useful bug reports.
<ogra> yes, i agree
<ogra> but the user needs to know about it
<persia> I've no issue with that.
<ogra> if you boot a kernel that has no display support at all the user needs to know that
<persia> How can you tell the user this?  There's no display...
<ogra> mors code on an LED :P
<ogra> *morse
<persia> You're mad!
<ogra> no, indeed you are right, if we are in first boot that doesnt help
<persia> Going back something useful.
<ogra> if i install a development kernel it does though
<persia> So, we've booted the first time with a downloaded install image.
<ogra> right, that either boots or doesnt
<persia> As a result, we have confidence that the kernel we booted is sufficient to allow the user interaction, which implies able to boot off install media, input/output of some sort, etc.
<ogra> yes
<persia> And I claim we can trust the user to have selected the appropriate input/output (serial console, KVM, etc.) for their needs.
<ogra> if the user sees it booting he should, yeah
<persia> Next, we do the install steps (jasper/ubiquity/d-i).
<persia> At this point, we end up calling flash-kernel-installer
<persia> This should succeed.  I've no issues with warning the user in the event that it's a device we don't know, but since we booted on that kernel, we ought to be able to install that kernel on the device.
<ogra> then flash-kernel-installer should have no checks at all
<persia> Now, here's where it gets tricky.
<persia> There's N different kernels in the archive, and K different ways to mangle the kernel to make it bootable.
<ogra> the point is that you need to identify the way the device boots
<ogra> in which case you again need the data about the device, not the arch
<persia> So, we care about K, but not about N?
<ogra> you just said yourself, if we are booted from that kernel to a point where it works, we dont need to care about N
<ogra> flash-kernel will only dump the kernel in a different place
<ogra> the place is the point
<ogra> and that depends on the device data
<persia> OK, so for that we want the machine info from CPUinfo
<ogra> right
<ogra> but probably even more
<ogra> i.e. beagle C4 vs XM
<persia> And the abstraction of omap_flash_kernel and dove_flash_kernel only breaks things.
<ogra> cpuinfo doesnt identify the difference
<persia> devicetype-detect doesn't.
<ogra> hmm, we should enhance it that way
<persia> (actually, devicetype-detect only outputs strings like "netbook", "laptop", "desktop", "phone", etc. (even less detail))
<persia> No.  The point of devicetype-detect is to add some flexibility to laptop-detect.
<ogra> device-name detect would be more intresting, yes
<persia> devicename-detect has all sorts of arch-specific hackery, but for armel, just uses machine from cpuinfo.
<persia> devicename-detect is mostly interesting because it has the equivalent collection for every architecture.
<persia> So, again, that's no more information.
<ogra> it should have revision data
<persia> cpuinfo has that.  Devicename-detect doesn't care.
<ogra> or at least a switch to show it
<persia> Parsing cpuinfo is significantly more robust.
<ogra> but exhausts what flash-kernel can do atm
<persia> How do you mean?
<ogra> machine=$(grep "^Hardware" /proc/cpuinfo | sed 's/Hardware\s*:\s*//')
<persia> Right.
<ogra> thats all that is matched against
<ogra> and not all boards ahve a revision in cpuinfo
<ogra> so you cant just blindly match against it
<persia> You're saying that cpuinfo:Hardware doesn't have an identity relation to method-to-make-kernel-bootable?
<ogra> not on all boards
<ogra> thats the prob
<ogra> "OMAP3 Beagle Board"
<ogra> is returned for *all* beagles since revision A
<ogra> so you can have a 128M, 256M or 512M version with or without flash etc etc
<persia> Is this a kernel bug, or is there additional information available that lets us identify the specific requirements for boot?
<ogra> no, thats a design decision from the manufacturer
<hrw> persia: it is not a kernel bug
<hrw> A3/B7/C3 are beagleboard. they just have different revision
<ogra> XM too
<hrw> ogra: never played with xM
<persia> So, is there additional information available that lets us identify the specific requirements for boot?
<ogra> and you will see the same prob on panda
<ogra> though here its even worse since the kernel string changed between revisions
<ogra> would be intresting to know what the linaro kernel says on blaze or tablet
<ogra> or on the RIM tablet :)
<ogra> or the new LG phone ...
<persia> So, is there additional information available that lets us identify the specific requirements for boot?
<ogra> not on beagle, i think there is a sysfs file somewhere and u-boot should know it too by poking some HW info
<ogra> but u-boot is gone at that point
<persia> Do we know which sysfs file?
<ogra> no, i dont atm
<persia> Because we ought to be checking that to define machine in flash-kernel/flash-kernel-installer, rather than cpuinfo:hardware
<ogra> and dont have either board around to check
<persia> hrw, Any ideas?
<ogra>  cpuinfo:hardware is ok for top level identification
<hrw> cpuinfo:hardware + cpuinfo:revision are nearly always present on arm
<persia> No, it's useless, if there isn't an identity relation between that and technique-for-making-device-bootable
<persia> hrw, does that pair have an identity relation to technique-for-making-device-bootable?
<hrw> persia: sorry, I didn't followed whole discussion
<hrw> persia: even hw+rev will not tell you do you need uImage or zImage.
<persia> Ah, so yeah, that's not complete.
<hrw> beagleboard can have u-boot or Qi or barebox or anyother bootloader
<persia> Basically, we need some way to know what method to use to make a device bootable.
<persia> Or rather, to be able to select from a set of recipes to convert a packaged kernel into whatever format/placement/etc. is required so that it is a bootable kernel.
<hrw> if you stick to 'this machine is ubuntu stock config' then hw+rev should work for most I think
<persia> What do you mean by "ubuntu stock config"?
<hrw> granted that device runs known bootloader
<hrw> otherwise you will end in hell of providing uImage + zImage + wtfImage + .... + yabImage
<lilstevie> rim tablet may not be so easy to get your own kernel executing on
<persia> I'm willing to pick a preferred bootloader on a per-device basis.
<persia> lilstevie, Why?
<lilstevie> the playbook devel images are starting to show RSA 4096bit signatures
<persia> Oh, annoying bootloader.  I'm happy to ignore those devices.
<lilstevie> heh
<lilstevie> the galaxy tab is starting to do my head in too
<persia> Most of the time someone figures out a way to work around them at some point, and only after that is anyone likely to run Ubuntu on them.
<lilstevie> something really doesnt want to let X work on it
<lilstevie> if it is anything like iDevices someone will need to write a replacement bootloader for it
<persia> ogra, Do you know of a case where Hardware+Revision matches two different devices with different requirements for flash-kernel?
<lilstevie> is there a way of getting greater detail on what is screwing with Xorg than -verbose 20
<persia> lilstevie, You might ask the folk in #ubuntu-x
<lilstevie> persia: ok thanks I asked over there
<persia> ikepanhc, Hey.  Do you happen to know if there is a unique device entry in the sysfs tree, or if our best information is Hardware+Revision from cpuinfo?
<hrw> did someone stacked beagles with pandas?
<apachelogger> do we have a tiwlan driver somewhere?
<ikepanhc> persia: you need the list of device within SoC?
<persia> ikepanhc, Rather, when booting a retail device, I'm trying to have a unique identifier for what to do with a kernel post-install so it will boot.
<persia> Sorry for the confusion around the word "device"
<persia> apachelogger, There's one in a PPA: https://launchpad.net/~tiomap-dev/+archive/release : probably needs some review if it is to be in-archive.
<ikepanhc> persia: so, I guess you need a way to identify the SoC because you want to use the same image on different platform?
<apachelogger> hm
<apachelogger> persia: one gets to wonder if it works with omap3 :D
<persia> ikepanhc, It's more than just SoC: for example, the Touchbook and the Beagle are both the same SoC, but different hardware.
<persia> apachelogger, Heh.  No idea.
<apachelogger> persia: ok :)
<ikepanhc> persia: ok, then for SoC, cpuinfo maybe not perfect but as I know, its the only one
<ikepanhc> persia: but for other device outside the SoC, I believe we need to probe them one by one
<ogra> persia, the PPA one will go away, it has been reimplemented in .38
<persia> ikepanhc, Thanks for the confirmation.  Right now, we're using cpuinfo:Hardware, but we'll look at cpuinfo:Hardware+revision.  If that's not enough, we might request more from the kernels :)
<ogra> persia, touchbook is such a case as you ask for above, it is identical to beagle in all aspects
<ikepanhc> persia: some hardware designer will try to use gpio pins or ROM for identifying hardwares
<ikepanhc> persia: but there is no standard rule for this
<persia> apachelogger, Try the .38 omap3 kernel from the linux source package, and see if the wlan just works.
<persia> ikepanhc, Ah, OK.  That makes it extra tricky.  Thanks.
<ikepanhc> :)
<apachelogger> well, I don't have much to try yet :D
<apachelogger> though
<apachelogger> I'll get an archos 101 it would seem
<hrw> apachelogger: nice device
<hrw> persia: i2c:50 on beagleboard will give you ID of extension board for example
<apachelogger> a notion ink adam would still be nicer ^^
<persia> ogra, So, I'm wondering if it's hubris to assume we can guess how to make a kernel bootable.  I wonder if we wouldn't do well to catalog a set of post-install recipes, and then have the user select one (defaulting based on cpuinfo:Hardware)?
<ogra> hmm, i would prefer to automate it more
<persia> I'm thinking that we have some conffile that specifies the recipe to use, and just reuse it reliably post-install.
<persia> So users would only encounter this on first install, when they are asked to confirm booting method: and it's just the confirmation for some devices, other devices would have to select an alternate method *OR* choose "none", and do it manually.
<ogra> hmm, yeah
<persia> So, for the Touchbook/Beagle example, we default to Beagle, but someone with a Touchbook could select Touchbook.
<persia> Mind you, if they happen to be installing a kernel that doesn't have the support for the Touchbook, they will be unhappy, but that's a separate issue.
<persia> And once there is richer devicetree support, we could consider doing an analysis between current hardware and supported hardware, and informing the user if we believe they are installing a poor kernel for their device.
<persia> But that's not for Natty.
<ogra> yep
<persia> NCommander, So, the above massively impacts your generic-subarch stuff.
<persia> Basically, we're not convinced that there is a useful relationship between detected-subarchitecture and recipe-to-make-just-installed-kernel-boot.
<persia> NCommander, Do you think we can leverage the generic-subarch spec to do as described above, or do you think we need to do something differently?
<sveinse> persia, doesn't ARM linux have a machine ID mechanism which had to be setup in the bootloader?
<sveinse> see http://www.arm.linux.org.uk/developer/machines/
<hrw> sveinse: but you can make kernel which boots on more then one machineID
<persia> sveinse, I don't believe we can see that from userspace, I'mo not convinced there's an identity relationship between that machine ID and the method by which the kernel is made bootable, and I know of devices (e.g. Sharp Netwalker) that do not have a registered unique machineID (which has caused issues with upstreaming support for that device)
<persia> Mind you, I'd be glad to be wrong :)
<persia> NCommander, Since you'll apparently encounter this in backscroll: the description of what I'd like to do starts at :47
<sveinse> persia, It's probably true, though. We had a long discussion internally whether to register a public machine ID or not, since it would reveal info about a upcoming product
<persia> hrw, I think we would have cases where the same kernel would boot on multiple devices, using different recipes to make it bootable.
<persia> sveinse, I can't emphasize enough that you really want to have one registered in order to ensure support for the device can eventually go upstream.  Use a funny codename, or something that otherwise is unidentifyable with any specifics.
<sveinse> I do embrace the Machine ID idea in all cases, because as you've said, without it you can't know reliably which HW you're on
<persia> Things like "rhino" or "snowball" or "guppy" or "spitz" don't tend to be very informative.
<persia> Even with it, it's not easy to know, but yeah :)
<sveinse> USB has it, PCI has it, even mobles phone all have systems for tracking the HW its running on
<sveinse> iirc PC has it as well via. the DMI
<persia> So you suggest that we ought to try to expose the machineID to userspace, and then claim there is an identity between machineID and recipe-for-kernel-postinstall-mangling?  File bugs for devices without machineIDs?
<sveinse> I would love that yes, but I fear many boards/bootloaders don't set this ID properly
<sveinse> The machine type codename ("rhino", "snowball" etc.) is irrelevant. It's the number which should uniquely identify the HW.
<sveinse> And it would be nice if the machine id also could add a field for revision. Now I need to put in some custom mechanism for identifying the board revision to load the correct driver options, etc.
<persia> devicetree is better for that.
<persia> And in the absence of devicetree, a detection algorithm.
<sveinse> I still need to determine which HW revision I'm on.
<sveinse> I can probe, but that is implementation dependant. If I could get the revision along with the machine ID, it would be sufficient to inform the SW which HW its running on
<persia> I assert that you care which revision of each peripheral you have, rather than which revision of the board/retail device you have.
<persia> Which is why I claim machineID isn't the right place for that.
<sveinse> sorry, what do you mean? Machine ID identifies the HW, right? The HW revision number also follows the HW, so it's linked to the Machine ID
<sveinse> pluggable peripherals are IMHO another ballgame and needs its separate scheme for identification (like USB VID/PID)
<persia> I believe that non-pluggable peripherals ought be treated the same, for the most part.
<persia> Helps reduce duplication of code or special-casing when the same components are used on multiple boards, etc.
<sveinse> ah, I see.
<sveinse> That would require that the SoC implementors agreed upon some scheme for device ID on peripherals...
<persia> Yes.
<lilstevie> good luck with convincing them of that
<persia> Well, rather that the board implementor happened to select components, all of which had some scheme for device ID implemented.
<sveinse> I second that, but doubt it will be easy to convince the mfgs
<persia> heh :)
<sveinse> When you port linux to a new SoC, you need to make the platform driver's list
<sveinse> what if you would have to put some pre-defined ID in here, a scheme like USB VID/PID?
<lilstevie> maybe once windows arm devices start being sold
<persia> sveinse, Perhaps, but I'm thinking more about off-SoC peripherals.  I'd much rather only have to identify SoC+revision than board+revision and then go hunt up a lookup table.
<persia> lilstevie, Why would that be different?  The more so considering all the existing ARM devices that run various flavours of Windows?
<sveinse> persia, what kind of off-SoC peripherals are we talking about? this doesn't apply for USB at least
<lilstevie> well once windows8 arm gets released that will push for uniform identification methods
<persia> sveinse, Being a software person, I probably have an incomplete picture: I've been presuming that the reason we care about per-machine stuff rather than just per-SoC stuff (with machineID) is that there exists some set of hardware that is on the board and not part of the SoC that is important for booting and initial bringup.  I've no idea about the specifics.
<sveinse> persia, SoC+revision only identifies, well, the SoC. board+revision gives you the ability to know e.g. which gpio is connected to what.
<sveinse> possibility, not ability per se
<persia> Right, and it's that bit which I'd hope to have some way to identify without tracking board revisions.
<sveinse> I understand what you want, and I do agree, but I don't think the picture is that easy unfortunately
<persia> What complicates it?
<sveinse> Many SoC is capable of booting without support from other devices except memory
<sveinse> Take ethernet as one example: The phy may be external or internal to the phy, same applies to the MAC. You don't know that from a generic SW point of view while booting
<sveinse> I ment external or internal to the SoC
<persia> And these different implementation choices require different hinting to the drivers, in a way that the drivers cannot handle through discoverability?
<persia> s/discoverability/discovery/
<sveinse> persia, essentially yes
<persia> I see.  I don't much like it, but I think the right answer is to handle that with devicetree rather than trying to engineer something else currently, for all that means waiting a bit more.
<sveinse> iirc, the kernel uses the machine id to select which platform init to run. And the platform init (like arch/arm/mach-omap2/board-omap3beagle.c) sets up all the drivers and devices specific to the HW
<persia> That makes sense.
<sveinse> BTW: looking in the board-omap3beagle.c I find a function named omap3_beagle_init_rev() which actually probes some gpio pins for HW revision. -- Because the designers of the beagle board decided to place the HW revision scheme that way
<sveinse> When I come to think about it, it wouldn't help to have the HW revision number along the machineID from the bootloader, beacuse its "just" software. Then the bootloader would have to do some HW probing anyways, and then you're back were we started
<sveinse> oh how time flies...
 * sveinse *leaving*
<lool> persia: efikamx smarttop support on its way to linaro-image-tools https://code.launchpad.net/~lool/linaro-image-tools/efikamx/+merge/50151
<persia> lool, Cool.
<persia> lool, I notice overo listed there as well.  Is that working cleanly with the linaro builds?
<lool> persia: It is, albeit there is a kernel issue which has a patch
<lool> I think it's hdmi output or so
<persia> Your merge doesn't seem to have EfikamxConfig: that was already merged?
<lool> LP #660811
<ubot2> Launchpad bug 660811 in linux "Display is not working on Gumstix Overo" [Undecided,Fix released] https://launchpad.net/bugs/660811
<lool> persia: +class EfikamxConfig(Mx5Config):
<lool> 28	+    uboot_name = 'efikamx'
<lool> +class EfikamxConfig(Mx5Config):
<lool> gah
<lool> persia: I see it
<persia> Am I reading 660811 correctly as fixed-in-maverick-open-in-natty?
<persia> Right.  That's just me not understanding linaro-image-tools.  Sorry.
<lool> persia: 660811 > yes
<lool> albeit I think the bug tasks are bogus
<persia> What's wrong with the bug tasks?
<lool> it says linux
<persia> I thought that omap3 kernels were produced by the linux source package for both maverick and natty.
<ogra> right
<ogra> just not for lucid
<lool> Yeah, but I think Andy is commenting for the Linaro kernel
<persia> Ah, so maybe it needs some linux-linaro tasks as well?
<persia> But we ought get that patch into linux anyway: regressions are bad.
<lool> I've checked all trees and added missing tasks
<lool> the linux task is still needed
<ogra> hrw, just uploaded a little present for you ;)
<hrw> ogra: flash-kernel finally?
<ogra> :)
<lool> Bah I've just noticed that Ubuntu's flash-kernel doesn't remove tmpfiles it creates and has some insecure constructs like usage of tempfile + suffix
<persia> And needs a merge with upstream :)
<ogra> upstream only adds unused arches
<ogra> else i would have done it
<persia> There's some code-safety and syntax improvements as well.
<lool> ogra: what did you do of the check_subarch part in the end?
<ogra> lool, have you seen initramfs-tools upstreams comment on the bug i files about create vs update ? he claims that the kernel should ship the scripts that call update-initramfs and flash-kernel
<ogra> lool, nothing yet
<ogra> i need the right data first
 * ogra hasnt run .38 yet
<ogra> lool, and i have no real idea what to do about -omap vs -omap4 atm
<persia> Could we just allow *both* "omap" and "omap4" for omap4 hardware?
<ogra> its about the uname check
<persia> Or does this go back to the earlier discussion, and I should ignore it this time?
<ogra> not sure
<ogra> its quick fix vs proper implementation i think
<ogra> the latter is as you stated not natty
<persia> What?
<persia> I said that doing devicetree mapping of capabilities was not-natty.
<lool> there are three subarch concepts in Ubuntu's flash-kernel (and two in Debian's)
<ogra> lool, yes, the third one is NCommander's subarch detection
<persia> I don't see any reason not to do selectable-recipe for natty, as the generic-subarch spec is still pending, and I no longer believe that solves the actual problem it was intended to solve.
<ogra> which as i stated above in the discussion just a way of ignoring subarch detection and spilling a message on certain arches
<lool> one is uname -r (running_subarch), Ubuntu-only, one is the sufix of the vmlinuz which we're about to install, and the third one is the subarch name which we use for the platform
<ogra> then there are four, not three
<persia> What?  Where is the fourth?
<lool> my personal preference would be to never use uname, and to change flash-kernel to create a flash-kernel.conf on install or upgrades which documents the kernel which one prefers to run
<sveinse> Where are the logs for this channel located?
<ogra> persia, two debian ones, plus ubuntus vmlinuz plus ignoring arch check completely on dove, omap and omap4
<persia> I'd also like to add selectable-flash-recipe to that conffile, and get away from the tight integration of machine and flash-recipe.
<lool> sveinse: usually irclogs.ubuntu.com is the place for ubuntu chans
<persia> ogra, No.  $running_subarch is the one that is used to ignore things.  It's not a fourth one.
<ogra> lool, agreed
<lool> persia: Yeah; I'm not sure how much should be configurable, but I think there should be a recipe or "method" concept for installign the kernel, e.g. NAND vs MMC
<lool> persia: I've actually started work on cleaning up flash-kernel upstream; I'm not at the method part yet, but I made good progress on the rest
<persia> In the earlier discussion, we use the Touchbook vs. the Beagle as an example, where someone might want to have different install recipes for the same reported hardware.
<persia> Obviously, we should default to the sensible recipe for the detected hardware, but in cases where it's uncertain, or cases where there are choices, or cases where the hardware is unknown at release time (but the user knows a supplied recipe works), the user can still do something useful.
<lool> Yeah
<lool> flash-kernel basically needs extension and configuration points; it's just hard to get these right and not end up with a very painful to maintain system
<lool> or risking to break systems
 * ogra is eager to see functions and hw database separated as a first step
<lool> that's what I'm working on ATM
<lool> it's really a lot of work though
<ogra> cool !
<ogra> yeah
<janimo> lool, still in bash ?
<lool> well, in POSIX shell
<ogra> hopefully
<lool> janimo: I don't really mind  :-)
<lool> there are some painful points I admit
 * ogra prefers shell 
<lool> but I always liked shell, I'm a bit of a masochist
<janimo> well it i s great for the seemless integration with the OS and running commands, but it is not a sane programming language
<janimo> part of the reason why flash-kernel is spaghetti
<lool> I tend to disagree
<lool> Debian's flash-kernel is actually readable, just has a lot of code duplication
<lool> and I would hope my reworked code is even more readable
<ogra> ubuntu isnt so much
<ogra> thats the issue ... we added on top of debians and not always in the most appropriate way
<lool> janimo: Another quite sad choice is to intend everything with a tab; it makes it really hard to read when code gets nested a bit  :-/
<NCommander> lool: just adjust your tabstop to 2 or something; its why I prefer tabs to spaces
<persia> NCommander, So, about generic subarch and the lack of apparent relationship between SoC and flashing-recipe.  What's your opinion?
<NCommander> persia: I'm not quite sure I follow
<persia> So, based on the set of devices seen, there seems to be no useful relationship between the SoC and the recipe required to ensure that the available kernel is used for the next boot.
<ogra> NCommander, did you read backlog of the last hours ?
<persia> And you're working on this generic-subarch spec, which seems to focus on providing a good installation experience regardless of whether the device is one that happens to be certified in some way.
<ogra> (if not, i would suggest to do so)
<NCommander> ogra: I didn, but still confused
<NCommander> persia: I disagree, the install scripts should be smart enough to detect what's present and properly install based on that
<persia> What sort of detection do you imagine?
<persia> Specifically, I don't see how we can determine the bootloader configuration in a safe or repeatable manner, especially for devices where we aren't installing the bootloader.
<NCommander> persia: on devices we support, we assume the bootloader is uboot, and its installed to the SD card or NAND
<NCommander> its straightforward to check if the bootloader is there, and if so, write boot files
<persia> So, why does ogra claim this breaks some devices?
<ogra> it breaks the blaze
<NCommander> ogra: ?, for blaze we simply write to SD card, same as panda
<ogra> doesnt work with emmc
<ogra> the device names are different
<ogra> you have assigned the bug, read it
<NCommander> ogra: we don't support using the eMMC, nor have we ever. The block device is written out by flash-kernel-installer into a confiugration file
 * ogra sighs
<NCommander> ogra: am I wrong about supportng the eMMC for booting?
<ogra> it should not break at least,. please read the bug
<NCommander> ogra: care to provide a link?
<ogra> it think it was discussed teher since maverick
 * GrueMaster looks
<NCommander> ogra: and my work mostly beeon of dove until this cycle, and then on panda; I don't even have a blaze; I have to borrow GrueMaster's
<GrueMaster> I think it is Bug #626749
<ubot2> Launchpad bug 626749 in flash-kernel "flash-kernel tries to use MTD devices on OMAP4 when no flash-kernel.conf exists" [Medium,Confirmed] https://launchpad.net/bugs/626749
<persia> So, specifics aside, can we not imagine a device that should just work that doesn't have an identical recipe to make a kernel boot?
 * NCommander can't
<persia> What about Touchbook & Beagle, discussed earlier.
<persia> Apparently they have the same cpuinfo
<GrueMaster> persia: The hard part about this is platform availability.
<persia> GrueMaster, Why?
<GrueMaster> If you don't have one, makes it hard to support.
<NCommander> persia: already handled by existing code. If the bootloader is on an SD card already, flash-kernel writes to the SD card, else it tries to write to NAND
<NCommander> the bug GrueMaster references is simply the code tries to write to NAND unconditionally if theres no configuration info
<NCommander> which is a bug
<GrueMaster> NCommander: That assumes /etc/flash-kernel.conf.
<NCommander> GrueMaster: which exists if somene installed with one of our images
<persia> GrueMaster, Why?  The point of a flexible architecture is that it allows one to support anything that doesn't work (and accept fixes to tune that).  An inflexible model only supports that which was tested and verified.
<GrueMaster> persia: I was referring to the current code, which is not flexible.
<persia> Well, it's worse than that: parts of it are inflexible, and other parts simply assume a recipe works because it's "dove" or "omap" or "omap4"
<ogra> persia, beagle C vs XM
<persia> ogra, What's the difference in recipe for those?
<ogra> stop using the touchbook example ;)
<ogra> NAND vs SD boot
<GrueMaster> persia: Beagle C has nand, XM doesn't.
<ogra> identical cpuinfo
<GrueMaster> Physically.
<hrw> ogra: same rev too?
<persia> Better example.
<NCommander> ogra: GrueMaster: so you detect for NAND and use it if its available if something isn't set in flash-kernel.conf
<hrw> NCommander: how you check for nand?
<hrw> NCommander: /proc/mtd?
<GrueMaster> Even our current images are broken wrt beagle C.  If the Beagle has had Lucid installed (or anything else that used nand), our current images will fail as they are set to boot from sd only.
<NCommander> hrw: yeah and the device in /dev/*
<hrw> NCommander: "modprobe mtdram" and your test will fail
<persia> Indeed.
<persia> Alternately, modprobe nandsim
<GrueMaster> Will that work in the case of Tegra?
<persia> Tegra will hit the hardcoded path
<GrueMaster> Or other systems where the user may not want to kill nand?
<NCommander> persia: so you think then generic subarch should die and shelf it as a spec?
<persia> Well, I'm not sure about that.
<persia> The more I think about available devices, the more I think that the set of recipes doesn't map well to the set of subarchitectures.
<NCommander> persia: you've just made a very convincing case that its not going to have a wide swatch of support
<NCommander> persia: right
<persia> And so while I'm hugely in favour of the goal of making it just work on arbitrary devices, I wonder if splitting by subarch is the right way to do that.
<ogra> NCommander, it shouldnt die but needs more detailed testing for devices
<persia> So I guess I wonder if you'd be interested in doing some sort of recipe-mapping model rather than a subarch-mapping model in your work for natty.
<NCommander> pI dropped out of Mileage Plus years ago after flying 300,00 revenue miles as a 1k or at the mid tier level over 5 years ago.Moved all my business to AA/ One World where I am far happier with fairness on redemption.
<NCommander> I would like to go back to UA so I am monitoring the situation but stll feel UA is too stingy with seats to justify switching back.But if the Starnet blocking scenario is over they may have lifted the largest issue off the platform
<NCommander> I will be monitoring the situation .Thanks for the heads up all
<NCommander> argh
<NCommander> I really need to hack Xorg.conf and remove this stupid pasting behavior
<ogra> ??
<NCommander> persia: a lot of boards can't be easily told apart, Beagle and BeagleXM both identify themselves as Beageboard in /proc/cpuinfo
<ogra> heh, yeah, you should
<persia> NCommander, Right, and I've come to believe that this is even more widely true in retail devices based on various platforms.
<ogra> NCommander, right, so we need to find a better solution on top of the cpuinfo
<ogra> cpuinfo is good but not enough
<persia> So, because we can't tell them apart, we should provide a menu of recipes, and default best we can.
<persia> And leave the rest for documentation.
<NCommander> persia: ugh, that's fugly, and adds a lot of complexity to user installs
<persia> For most users, it should be pressing enter once for confirmation.
<NCommander> persia: for most users, they won't know the difference
<persia> For a few users, it may be more complicated, but the alternative is to force them to hack things together manually.
<GrueMaster> Maybe using a separate conf file would be better.  That way, it can be more easily updated without package rebuilding.
<NCommander> If we can't do it automatically, then I rather not do it
<ogra> i would prefer better automation before we resort to interaction
<ogra> but its a good last resort
<persia> And we already have too many complaints about stuff that we know is broken because someone didn't perform a regular install.
<GrueMaster> By conf file, I mean a file with a list of supported platforms that can be easily updated.
<persia> I'm happy with something like debconf-priority-low: adjustable, but not shown by default.
<hrw> looks like you will end with database keeping lot of scripts which will check which exactly hardware it is run on
<hrw> like "if cpuinfo=beagleboard and amount-of-ram=256M then Cx elseif amount-of-ram=512M and lsusb |grep ID-OF-SMSC then beaglexm else ax/bx"
<persia> Why?
<persia> I imagine having install-to-NAND, install-to-SD, etc.  Just a few recipes.  Then, some routine that picks a reasonable recipe.
<GrueMaster> The biggest problem is system identification.  cpuinfo just isn't always enough.
<ogra> it is enough as a base but not for details
<sveinse> let me get this right: The problem is how to write the kernel image into NAND or MMC (FAT partition) or similar, right?
<persia> Kinda.
<GrueMaster> More of how to detect which to use.
<persia> There's a script (flash-kernel) that gets called when a new kernel is installed.  This script needs to do something to convert the unpacked kernel .deb into something that is being booted on the device.
<sveinse> interesting and challenging. I've made a manual post-kernel-install script to move it to the FAT partition (use mmc boot) which surely isn't an elegant solution
 * sveinse wish the HW bootloader in the SoC could read sector 0 from NAND or MMC and behave like a PC bootloader. Maybe.
<persia> sveinse, Take a look at the flash-kernel package.  Both flash-kernel and debian/flash-kernel-installer-postinst are interesting.
 * sveinse is reinventing the wheel...
<persia> Can't have that :)
<ogra> more wheels !!!
<rcn-ee_at_work> hrw, amount-of-ram might not be the best, there's "white label" c4 boards with 512Mb. ;)
<hrw> ~/cr
<hrw> rcn-ee_at_work: nice
<sveinse> I'm a little curious about bug 705689. Does anyone knows if this will result in a patch & update for armel-cross 4.5 ?
<ubot2> Launchpad bug 705689 in gcc-4.5 "QT applications crash with segfault error on armel when QT is built with gcc 4.5 on natty" [High,Confirmed] https://launchpad.net/bugs/705689
<lool> sveinse: It's relatively close to what happens, problem is that every SoC needs a different first piece of code to run, to setup the DDR for instance
<rcn-ee_at_work> hrw, you can get it from dmesg, since the gpio detect is printed out..
<rcn-ee_at_work> hrw, dmesg | grep "Beagle Rev:"
<hrw> rcn-ee_at_work: how you check dmesg on machine which works for 2 months and have /var/log/dmesg removed?
<sveinse> lool, the FAT load from MMC is a HW bootloader implementation in OMAP, iirc
<rcn-ee_at_work> hrw, not easy..  userspace progam to read all 3 gpio pins?
<rcn-ee_at_work> hrw, if you know your on a beagle... looks at "cat /proc/cpuinfo" the xM is "CPU variant	: 0x3" the Bx/Cx should be "CPU variant	: 0x1"
<lool> sveinse: That's correct, but DDR isn't setup at this point; it's setup by this piece loaded from MMC ("MLO"); the ROM could technically set it up if it was padded in some special ways, but that's a different config block from SoC to SoC
<lool> sveinse: So concretely, you have different constraints on the data / location from different SoCs
<lool> You could arrange for writing the first sectors on a lot of SoCs though
<GrueMaster> lool: WOuld it make sense for MLO to setup an area in memory that could be read by userspace similar to dmidecode?
<rcn-ee_at_work> hrw, yeap it is.. http://pastebin.com/5WP3TSiK (comparsion of c4/xM)
<persia> Something like dmidecode would be nice.  I wish all architectures had it.
<ogra> thats easy
<ogra> just add a BIOS to all arches :)
<sveinse> well, the dmi info is actually in concept the same as the machine id we talked about earlier
<lool> GrueMaster: what kind of data do you intend to provide?
<lool> I think UEFI has provisions to pass various data
<ogra> lool, device lists ?
<hrw> rcn-ee_at_work: thx
<lool> Well, concerning tables of devices, we're leaning towards device tree
<TheUni_> rsalveti: around?
<ogra> lool, i think devicetree will solve that anyway
<GrueMaster> Basic hardware info, similar to what dmidecode provides.  Like what busses are available, what the system is, etc.
<GrueMaster> If/when it appears.
<hrw> ogra: I have x86 which does not use efi and can be booted even without bios
<persia> lool, Will I be able to get stuff like Manufacturer, Product Name, etc. from devicetree?
<GrueMaster> I have been hearing about devicetree since 2009.
<ogra> hrw, pfft, prototypes
<ogra> hrw, btw, my booking is finally confirmed i'll arrive on sunday evening
<hrw> ogra: no, on-the-shelf hardware
<hrw> ogra: with coreboot
<lool> persia: I'm not sure about these specific things; it's mainly to describe the hardware layout, but I'm pretty sure it would be easy to have the information
<ogra> hrw, how do you remove the BIOS from that ?
<sveinse> In all cases, having dmiinfo or devicetree, will imply that the MLO or bootloader must setup the information uniquely for each HW and revision.
<GrueMaster> hrw: The difference there is all x86 cpu's fetch from the same location for booting.  Not so with arm.
<lool> sveinse: Correct, or the firmware
<hrw> ogra: coreboot ;D
<lool> GrueMaster: ah but you define booting as after the BIOS
<persia> lool, OK.  That's the information I wanted from dmidecode, but I don't really care where I get it.
<hrw> ogra: coreboot can load filo or grub as payload without any bios legacy stuff
<ogra> hrw, i know coreboot, i worked with it in the past
<GrueMaster> lool: No I don't.  I define booting as after the cpu is initialized ant goes external to fetch code.
<ogra> hrw, still there is a BIOS coming up on the boards i used it
<ogra> unless you remove the eprom probably
<sveinse> yes, so in that respect, this bootloader or firmware which prepares the machine for kernel boot, is a BIOS per definition. It could provide the information needed for flash-kernel
<persia> Or flash coreboot into the eeprom
<persia> sveinse, The complicated thing is that the ARM community doesn't tend to favour two-stage bootloaders, but wants an all-in-one solution, including both full init *AND* kernel load.
<persia> Some devices support OpenFirmware, and some second-stage bootloaders were ported in the past, but nothing recent has separated stages.
<sveinse> persia, I have yet too see a SoC device booting directly into linux kernel. All I've encountered so far have two stage boots
<sveinse> As lool said, the DDR needs to be setup and the kernel command line, and so on by the bootloader
<hrw> sveinse: iirc on omap3 you can add header to kernel image which will setup ddr etc (which xloader does normally) and boot
<hrw> sveinse: kernel cmdline needs to be hardcoded in kernel
<ogra> only on 3530, not ?
<sveinse> it is? hmm. I need to check my sources...
<persia> sveinse, I heard of some demos about it, but you mean "two-stage" to be bootloader/kernel.  When I talk about "two-stage" bootloaders, I'm talking about the sort of thing we see for x86, powerpc, sparc, etc. where one uses one codebase to init, launches to another codebase for kernel selection, and then loads the kernel.
<sveinse> ah, then I agree
<hrw> bios -> grub -> kernel or chiprom -> xloader -> uboot -> kernel...
<persia> So, EFI/grub or OF/yaboot, etc.  (although I think we'll switch to OF/grub for natty powerpc, but I may be mistaken)
<GrueMaster> persia: On x86 images, we currently have 3 stages:  bios, bootloader (lilo, grub, etc), kernel.
<GrueMaster> It is possible for x86 to have one:  Linux-bios.
<hrw> anyway it is time for me
<sveinse> In fact when doing OMAP MMC boot its 3 stages as well:  MLO -> Uboot -> Kernel
<hrw> sveinse: mlo is read by inchip code
<GrueMaster> On SOC's, most fetch from an internal rom on the SOC, then fetch from there.
<sveinse> hrw, do you know anything about the 4.5 gcc bug in respect of Qt?
<persia> sveinse, Indeed.  OMAP is the closest we have to sanity, but it's still not quite there: lots of messiness in MLO, and Uboot could be doing a lot more than it does in that context.
<hrw> sveinse: no
 * hrw -> out
<hrw> have a nice rest of day people
<GrueMaster> Actually omap/omap4 is 4 stage by that logic:  SoC ROM, MLO, u-boot, kernel.
<persia> The SoC ROM is stage-0, by my nomenclature.
<persia> x86 BIOS would be stage-1
<GrueMaster> Ok, in binary you are correct.
<persia> silo would be stage-2
<GrueMaster> :p
<sveinse> We are (for boottime reasons) considering to skip the MLO -> uboot part of the boot. I.e. let the MLO image load the kernel itself with a small init function for setting up the magic things like DDR & co
<GrueMaster> X86 always fetches from CS:IP F000:FFF0
<GrueMaster> Or the end of 1M.
<sveinse> uboot is not efficient if you are waiting for it :D
<sveinse> GrueMaster: If ARM always fetched from the same addr, would that help us in any way?
<GrueMaster> Might.
<GrueMaster> I don't know much about arm architecture, but I believe it may already.  Just most SoC vendors put rom code there on die.
<GrueMaster> Which can't be changed.
<sveinse> Because the BIOS or whatever you name it, will always contain the board specific initialization which is the same that we do in our bootloaders
<GrueMaster> With x86, it is the flash-rom chip on most systems.
<sveinse> So the question is more to agree upon some dmi-like struct that needs to be setup prior to kerel boot
<GrueMaster> http://en.wikipedia.org/wiki/Booting has some interesting details on this.
<GrueMaster> sveinse: right.  That would need to be done by MLO/u-boot.
<sveinse> yes,
<GrueMaster> Or the kernel if it is used directly (which may happen in the future).
<sveinse> In concept, arm has one (1) dmi-like information: MachineID. Period
<GrueMaster> As I said, I am new to the architecture, but on x86, the bios loads and probes the platform for "extra" devices that aren't hardcoded into the bios already.
<GrueMaster> Things like pci devices, drives, memory boards, etc.
<sveinse> Out of interest: How is that done? (I dont mean PCI and USB devices, because they have well defined ID's attached to them)
<GrueMaster> Each vendor uses core bios code from one of the bios vendors (ami, phoenix, etc) and adds board specific information to it.
<GrueMaster> So in the case of arm, MLO would be board specific.  u-boot & kernel not so much as they should get the info they need from MLO.
<sveinse> and how is this any different from arm's machineid ?
<GrueMaster> I'd have to look, but the machine ID is very limited in what it contains.
<GrueMaster> Does it change between Beagle C4 and other devices using the same CPU?
<sveinse> Yes, that I agree. You'd need some database to provide the extra information, like how to update the kernel
<persia> sveinse, In the x86 world, one encodes the map of devices and layout in code, following one of three known formats (mostly concurrrently two with modern devices).
<sveinse> And it does not support extra information, like revision number. I would love to see that feature added. And call it dmi info
<persia> Personally, I prefer the OF model, where one has board-specific code that loads, which loads a datafile from a known location, and uses that to determine what to do (and can pass the data to the kernel).  The ARM devicetree stuff mirrors that, except it doesn't mandate OF (unfortunately)
<sveinse> OF? Do you have any references to that?
<persia> OpenFirmware
<persia> You can look at the openhackware package for an example implementation: that one targets qemu's powerpc.
<GrueMaster> I just checked /proc/cpuinfo on my Motorola Droid and it is almost identical to Beagle C4.  The only difference is the Hardware and Revision lines.
<persia> That's expected: Hardware and Revision are the lines that are checked for all device-specific stuff.
<GrueMaster> Oh, and bogomips.  (for some reason my droid is running at 249 - odd).
<sveinse> I think we're talking about the same. A datafile at some specific location could provide a dmi-info like structure with a devicetree or similar. I would shurely like to have such a featureset added
<persia> I don't know the complete set, but there was once a port of OF for Marvell's MMP (PXA688-based) as prior work on ARM.
<persia> Note that as much as I like the model, I can't recommend OF for use on ARM: I simply have never used OF on ARM, nor have I heard stories about anyone working on a port to new hardware.
<persia> GrueMaster, bogomips are intentionally bogus: ignore those.
<GrueMaster> persia: Checking Hardware and Revision isn't enough.  In the example of Beagle C4 & BeagleXM, they are the same.
<GrueMaster> ok
<rcn-ee_at_work> GrueMaster, the droid has pm scaling working, hence the low bogomips..
<sveinse> the revision in /proc/cpuinfo only gives the SoC revision not the board's, iirc
<rcn-ee_at_work> sveinse, it's a single case, on the "beagle" you can use /proc/cpuinfo to determine weither it's a Bx/Cx series or xM...
<persia> GrueMaster, Right, which is why I 1) want to separate flash-kernel recipe from machine type (cpuinfo:Hardware), and 2) was asking about Manufacturer and Product strings from devicetree
<rcn-ee_at_work> GrueMaster, you need to check the "varient' and "revision" to differentiate the beagle's... http://pastebin.com/5WP3TSiK
<GrueMaster> Yes, I know.
<GrueMaster> rcn-ee_at_work: That is for the cpu only, right?  The Hardare lines are board specific?
<rcn-ee_at_work> yeap, cpu only... the hardware line comes from the board-omap3beagle.c file..
<sveinse> gpio pin probed, right?
<rcn-ee_at_work> no, the cat /proc/cpuinfo is pure processor..  the gpio pin probed is just dumped to dmesg on bootup..
<prpplague> anyone know if andy green is on irc?
<GrueMaster> rcn-ee_at_work: So there is no way for software to detect hardware differences then?
<rcn-ee_at_work> GrueMaster, well we can detect an xM board vs a bx/cx board.. but to seperate a C1/2/3 vs a C4 we need to read the gpio pins..
<rcn-ee_at_work> (like what is already done in the board-omap3beagle.c ..)
<rcn-ee_at_work> i don't know if it would be excepted, but could we modify the "hardware" line in /proc/cpuinfo based on gpio pin setup we have?
<lool> prpplague: He is agreen on IRC an hangs on #linaro from time to time, but not all the time
<lool> prpplague: He is on ATM
<prpplague> lool: thanks found him
<GrueMaster> rcn-ee_at_work: My ideal goal would be to have an arch specific kernel (armv7) that could detect what it was on and move forward without having to be specificly compiled for beagle?Panda/Blaze/Dove/imx51/etc.
<GrueMaster> Having MLO with the proper info could allow that.
<persia> GrueMaster, linaro is working on such a beast.
<GrueMaster> Cool.
<rcn-ee_at_work> GrueMaster, actually right now you can boot the same kernel on all the mailine omap3/4 boards...  so either mlo/u-boot would have to hint on omap vs imx51..
<GrueMaster> The next step would be to have some way for userspace to get more info on the platform, similar to dmidecode.
<persia> devicetree
<persia> And I think linux-linaro-omap already has the necessary bits to boot on all omap3/4 devices.
<GrueMaster> ok, then all that needs to happen is for it to fall in my lap for rigorous testing.  :P
<persia> Well, you can grab linux-linaro-omap today, and see if that works.
<persia> The devicetree stuff seems to still be future.
<persia> (but getting *very* close)
<rcn-ee_at_work> since both the imx51 and omap are pretty well supported in mainline, if you can get both to atleast build in one uImage.. it might work..
<GrueMaster> If I get bored, I might see if I can fire up my babbage with a more recent kernel/image.  if...
<GrueMaster> :P
<rcn-ee_at_work> for kicks.. what's the best supported imx51 target in mainline right now?
<GrueMaster> I think it is the Efika Netbook.  Apparently linaro got a bunch.  I missed out.  :(
 * GrueMaster never gets cool hardware, only semi-functional development systems
<persia> They are available retail.
 * persia has purchased any number of retail ARM devices now
<persia> Not even that expensive, as laptops go, although you should probably only get one if you plan to actually use it for something other than idle speculation.
<persia> rcn-ee, mainline, best supported is still the Babbage for imx51.
<sveinse> What is the relationship between the ubuntu native (and armel-cross) compiler and the one provided by linaro?
<ogra> they are the same
<ogra> linaro maintains the arm toolchain in ubuntu
<sveinse> ah, ok. thanks
<sveinse> I see both 4.4 and 4.5 is available from armel-cross. Which to use. I.e. why would I consider using 4.4 over the 4.5?
<lool> sveinse: Ubuntu gcc-4.x includes the Linaro patchset + Ubuntu patches; cross compilers are built from the exact same sources, but less frequently
<sveinse> We're having some issues with compiling Qt (QWS not X11), and it seems surprisingly similar to bug 705689. So my question is what do I lose by downgrading the (cross)compiler to 4.4
<ubot2> Launchpad bug 705689 in gcc-4.5 "QT applications crash with segfault error on armel when QT is built with gcc 4.5 on natty" [High,Confirmed] https://launchpad.net/bugs/705689
<lool> sveinse: sometimes we have multiple versions because the new one is not stable enough, or because we still need the old one for some time
<lool> sveinse: well we're not developping 4.4 any further in Linaro
<lool> sveinse: and it will eventually go away
<martyn> Is there a wiki page describing how the OMAP4 server image is meant to be installed?
<sveinse> ah, that's an answer, thanks
<martyn> Hey there lool
<persia> GrueMaster, I discovered why the kernel recommends "grub" when the kernel fails to install: it's a string in debian.master/rules.d/armel.mk : turns out it doesn't mean anything.  Dunno if it's worth fixing.
<lool> hey martyn
<persia> martyn, So, there's two answers to that.  1) there's work on a minimal jasper-based image, which you don't really "install", as such.  2) someone could work on debian-installer and add more omap4 support for some into-real-target install.
<persia> Err, rather, *if* there existed a wiki page about it, it would have two answers ...
 * persia believes such a page doesn't currently exist
<martyn> i.e. "don't bother, not even ready for alpha"
<martyn> "use rootstock"
<persia> Um, no.
<persia> The main issue is that nobody is working on it.  If you want to do it, it's not that hard to get working.
<martyn> I know, but right this second, I'm teaching someone how to get a system image up .. more about expediency
<persia> The big obstacle is that most folk with OMAP4 have pandas, and pandas don't have flash: they just boot off the SD card.  As a result, there's no useful answer to how one should "flash" a kernel and boot configuration.
<persia> If you just want a system image, just write an SD card, boot it, and maybe trim the installed packages.  That's the expedient way.
<persia> Post-boot, migrate /var and /srv to some real storage device, and reboot.
<martyn> Heh.. I'm trying for Versatile Express
<martyn> so the image has nothing bootable for me
<GrueMaster> interesting.
<persia> martyn, If you want to use non-archive kernels, rootstock is your best option.  When are you uploading a kernel to the archive?
<martyn> not just a versatile express either .. but one that's been chopped up and reformed into a Calxeda system
<martyn> persia: Not for a while yet .. probably not till .39
<persia> So, natty+1?
<martyn> better answer would be 'once we have silicon in house'
<persia> heh.
<martyn> because before then, it's all based on simulation, fpga, hard engineering, and good intentions
<persia> I've heard some murmurs about folk doing armel servers, so there's a chance that it's just a matter of uploading the kernel and making a few patches.  If nobody does one, you may have to tweak a few more things.
<persia> apachelogger, thumb2 support is presumed for every Ubuntu armel device
<apachelogger> persia: ok
<apachelogger> NCommander: I get segfaults for every kde app all within Qt, ScottK suggests that you said it is a gcc bug?
<apachelogger> on the n900 that is
<NCommander> apachelogger: no, thats NEON built into Qt by accident. Will be fixed when 4.7.2 is uploaded
<apachelogger> NCommander: the n900 cpu supports neon though?
<NCommander> apachelogger: oh ... hrm ... it does, doesn't it
<apachelogger> it did with maverick ^^
 * apachelogger installs libqt4-dbg
<GrueMaster> apachelogger: it may be related to the recent precompiled header bug we found.
<ScottK> That's the one I was referring to I think.
<robclark> hey ogra (or anyone).. what secret magic is done to make the boot partition on an sd card not automatically mount under /media?  And is it possible to reverse this?
<persia> robclark, I believe it's just a hidden partition.
<persia> Why do you want it mounted?
<robclark> how does one make a partition hidden/unhidden?
<ogra> robclark, /sbin/mkdosfs -n "SERVICEV001" -F 32 ${ROOTDEV}1
<persia> fdisk :)
<ogra> just rename ti
<ogra> *it
<robclark> ok, so just based on the partition name
<ogra> yep
<robclark> it is more convenient to copy over new kernels when I'm mucking with stuff it it mounts itself ;-)
<ogra> note that you will have it permanently on your desktop once renamed
<robclark> no prob
<robclark> that is what I want
<ogra> k
<robclark> thx :-)
<persia> ogra, It's not a hidden partition?  Why not?
<ogra> persia, the naming hides it
<ogra> udev ignores it completely that way
<ogra> we dont want to hide it from mount but prevent automounting
<persia> It seems to me that you're using a hack that accidentally works rather than using the partition table as it was designed.
<apachelogger> GrueMaster: what bug is that?
<GrueMaster> persia: Actually, this is a predefined use case in udev.  It is mainly to hide pre-installed partitions.
<persia> GrueMaster, Doesn't make me like it any more, but yeah, it's because of a common naming scheme for certain OEM restore partitions.
<GrueMaster> apachelogger: Bug 705689
<ubot2> Launchpad bug 705689 in gcc-4.5 "QT applications crash with segfault error on armel when QT is built with gcc 4.5 on natty" [High,Confirmed] https://launchpad.net/bugs/705689
<apachelogger> GrueMaster: 4:4.7.1-0ubuntu9 ought to be built agianst 4.4 though
<apachelogger> oh
<apachelogger> nevermind me, apparently I have ubuntu7 :O
<GrueMaster> heh
<GrueMaster> You had me doing a double-take.  Had to check my panda.
<ogra> lool, does: check_subarch "imx51" look ok for the efika stuff ?
<lool> ogra: Dunno
<lool> ogra: I don't know Ubuntu's flash-kernel
<apachelogger> GrueMaster: ubuntu9 does not seem to fix the issue though :S
<persia> apachelogger, Everything linked against qt4-x11 is still segfaulting apparently randomly?
<apachelogger> I wouldn't say random... it *always* segfaults
<apachelogger> gdb says it is in kdeui though ... getting rid of that and trying again now
<ogra> lool, well, you complained at the bug
<apachelogger> righto
<apachelogger> persia: something is fishy with current qt combined with kdelibs
<persia> From what I could tell from the bug before, it seemed that the segfault happened just about anywhere it could, because of being caused by an inline macro definition.  What I'm wondering is if everything linked against qt4-x11 that built during the time it was built with gcc-4.5 needs to be rebuilt.
<apachelogger> persia: a rebuild could indeed fix this, as some kdelibs stuff is sort of used as plugin for Qt (e.g. fileopen dialogs)
<apachelogger> without kdelibs unity-2d starts without segfault
<lool> ogra: well I complained because I saw a commented out line, and suggested either fixing it to be consistent (no idea which value it should have though), or removing it entirely
<lool> +                #check_subarch $running_subarch
<persia> Was unity-2d rebuilt against ubuntu9?
<apachelogger> yep
<lool> ogra: does that make sense now?
<apachelogger> persia: ubuntu9 was uploaded feb 7, unity-2d feb 15
<lool> ogra: I just looked at the diff, I don't know how running_subarch should be handled
<persia> Well, that's annoying.  On the bright side, most of the base of KDE FTBFS anyway currently, so it needs to be rebuilt.
<apachelogger> hmm
#ubuntu-arm 2011-02-18
<apachelogger> last kdelibs upload also was feb 15
<persia> So, we'd expect kdelibs to work
<apachelogger> yes, reinstalling kdelibs5 - unity still works
<persia> But kdebase is broken (uses old binaries)
<apachelogger> looks like it
<persia> http://launchpadlibrarian.net/62899430/buildlog_ubuntu-natty-armel.kdeartwork_4:4.6.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<apachelogger> that is an intersting fail
<persia> NCommander, Did you say that the bottom of the KDE stack is kdebindings?
 * apachelogger loves how bindings always breaks arm building
<ogra> lool, well, i think running_subarch is the wrong approach for consistency, all other arches use a fixed value apart from the ubuntu subarch detection stuff, i was more after finding out if imx51 is the right arch to use here (i'm not sure which flavour name is used on the efikas)
<apachelogger> uhhhh
<apachelogger> Program received signal SIGSEGV, Segmentation fault.
<apachelogger> 0x414fbee0 in ?? () from /usr/lib/libphonon.so.4
<persia> ogra, imx51 is the kernel flavour (linux-linaro-imx51)
<ogra> ok
<apachelogger> phonon needs a rebuild against ubuntu9
<lool> persia, ogra: I checked the build log, and the vmlinuz file is called
<lool> boot/vmlinuz-2.6.37-1003-linaro-mx51
<lool> so maybe it should be linaro-mx51?
<ogra> aha !
<NCommander> persia: yeah
<ogra> thanks !!
<lool> just a guess
<lool> it might be sed-ed down to mx51
<persia> lool, Oh, maybe.  Is "linaro" part of $FLAVOUR?
<ogra> i'll test that tomorrow before i upload
<ogra> persia, doesnt matter :)
<ogra> it depends what the sed command drops out
<ogra> and i'll use that
<lool> uname -r says 2.6.37-1003-linaro-mx51
<persia> ogra, Yes it does: we ought be semantically correct.  if we're not, then we have a kernel bug.  If we are, then we may have a sed bug.
<lool> persia: What's $FLAVOUR?
<persia> Otherwise it all becomes guesswork.
<ogra> in the context atm it doesnt matter, i wont change the function
<lool> CONFIG_VERSION_SIGNATURE="Ubuntu 2.6.37-1003.6-linaro-mx51 2.6.37"
<ogra> i will just add the right value to the one line change i do so it matches the kernel naming
<persia> lool, It's the type of kernel built.  I believe it's defined by the existence of./debian.${ENV}/config/vars.${FLAVOUR}
<persia> ogra, OK.  Don't blame me if I change the kernel and you have to do it again.
<lool> So I checked flash-kernel and check_subarch compares with subarch which is set as subarch=$(echo "$kfile" | sed -e 's/.*-//')
<ogra> persia, why would you change linaro kernels ?
<lool> so the correct subarch would be mx51
<ogra> k
<ogra> i would have checked that anyway
<persia> ogra, Because when *any* package in Ubuntu is semantically wrong, I get annoyed at it.
<apachelogger> ^^
<ogra> i'm to tired to upload tonight
<lool> persia: Oh ok; I thought you meant some runtime thing
<persia> lool, No.  If you don't know offhand, I'll check the linux-linaro source.  I suspect that "linaro" is not part of the flavour, but just want to make sure.
<persia> apachelogger, Indeed: phonon built nicely against ubuntu8, sadly.
<persia> NCommander, Do you know which was the first revision of qt4-x11 to have issues?
<lool> looking at 2.6.37-1003.6, I see the config is named config.flavour.linaro-mx51
<lool> persia: ^
 * persia thinks it might be best to ask for a mass-rebuild from an LP-generated lsit
<apachelogger> persia: if that is the issue at all ;)
<apachelogger> phonon ubuntu4 uploaded, should be finished in some 20 minutes
<persia> lool, Indeed.  I'm not sure that's how it ought be done: I think it would make more sense to have linux-linaro as SRCPACKAGE, with flavours "mx51", etc.  So we'd end up with linux-linaro-image-foo-mx51 rather than linux-image-foo-linaro-mx51
<persia> apachelogger, Let's see.  NCommander said it was at :09
<lool> persia: Ah I can speak in favor of linux-image-*: apparently this pattern is used in places like d-i, and it's a bad idea to diverge from it
<NCommander> persia: it was an issue with GCC, not qt
<lool> persia: it was a design choice to have the packages be named linux-image-linaro-foo rather than linux-linaro-image-foo
<persia> NCommander, I understand the root, but would the miscompiled qt4-x11 cause the segfaulting apachelogger is seeing in phonon?
<lool> it's quite a dance to get this right across all binary packages and meta packages
<persia> lool, I understand.  I don't like it.  I hope you understand why I don't like it.  I'll leave it alone for now.
<persia> (and thanks for reminding me: I have to do a -meta)
<persia> Oh, and to be clear, I don't care about linux-image-linaro-foo-mx51, it's the linux-image-foo-linaro-mx51 I don't like (but the former is hard to arrange with the kernel packaging scripts as they exist)
<lool> ah with foo you meant ABI and version
<lool> yeah linux-image-linaro-foo-mx51 is hard
<persia> Yeah.
<lool> more of a limitation
<persia> I'm not sure it's a limitation, just would need definition and insertion of $VENDOR
<lool> I mean, it's just not provisioned in the current implementation
<persia> I'd like to fix it at some point, so that $FLAVOUR as defined in the kernel packaging and $FLAVOUR as detected by the many sed scripts again have the same value.  Doesn't have to be soon.
<GrueMaster> persia: I think the fix in qt4-x11 is only temporary to disable precompiled headers.  The real fix is in gcc, and I am not sure if that has been released to update the toolchain.  If that is the case, we may need to rebuild kde with precompiled headers off as well.  Not sure.
<persia> Probably just an entry in debian.linaro/control.d/vars.* and corresponding bit in flavour-control.stub, really.
<GrueMaster> apachelogger: ^^^
<persia> GrueMaster, apachelogger just tried a test recompile with phonon to see if that's sufficient.  We'll know more RSN
<GrueMaster> Sorry, I was at the UPS store earlier.
<GrueMaster> I don't think a simple recompile will fix it, but I could be wrong.
<GrueMaster> NCommander: want to weigh in?
<persia> More testing is welcome :)
<persia> GrueMaster, What's the name of the maverick dove kernel meta package?
<ogra> linux-mvl-dove
<GrueMaster> Yep.  Was just verifying.
 * ogra had to fight with the headers on the weekend ...
<persia> ogra, That's real kernel, not the meta.
<ogra> else i would have had to look it up too :)
<apachelogger> still segfaulting \o/
<ogra> persia, nope. thats the meta
<persia> Not according to the source I'm looking at.
<ogra> linux-image-mvl-dove is the kernel
<persia> Ah, maybe I should ask: what's the name of the source package that provides that?
<ogra> well, the kernels meta
<apachelogger> GrueMaster, persia: rebuild apparently does not help :S
<persia> NCommander, Any suggestions for workarounds that could help apachelogger?
<ogra> persia, linux-meta-mvl-dove
<persia> Thanks!  That's the one permutation I didn't try before giving up.
<ogra> and the binaries of meta and kernel are actually just linux-dove and linux-image-dove
<ogra> dunno where the mvl vanished to
 * apachelogger installs dbg symbols
<persia> ogra, The kernel packaging hackery fails to define VENDOR consistently (see above), with results like that.
<ogra> yep
<ogra> well, its gone from the archive since last week
<ogra> so nothing to worry about anymore
<ogra> (for now)
<persia> Fixing it probably means me generating some PoC kernel hackery, and taking it to UDS, and getting it applied to all vendor kernels.
<persia> Still have TI and Linaro kernels in the archive though.
<ogra> well, linaro wants to have the branding in the package name as i understand
<apachelogger> yay
<apachelogger> http://paste.ubuntu.com/568547/
<apachelogger> looks familiar
<ogra> and TI can hopefully be built from upstream next round
<persia> Yes, but there's always going to be reasons why vendor kernels are interesting, and it makes sense to do them right, rather than half-way and hackishly
<ogra> agreed
<apachelogger> persia: supposedly gcc 4.5 should be fixed, otherwise we'd need a pile of force-gcc-4.4 changes
<ogra> i just meant its not for natty
<ogra> anyway, nearly 2am ...
<persia> Oh, indeed.  See earlier comment about UDS.
<persia> Good night :)
 * ogra vanishes
<persia> apachelogger, The Linaro GCC team was looking at it.  I don't know current status.
<XorA|gone> morning
<persia> Good morning.
<NCommander> apachelogger: persia I'm honestly not sure why sip is choking
<persia> NCommander, I'm not fussed about sip: I'm concerned about phonon segfaulting, when it wasn't before.  Does *everything* have to be rebuilt, or is there a workaround of some sort?
<persia> And if everything is rebuilt, will it need to be rebuilt again once gcc is fixed?
<NCommander> persia: I wasn't aware of phonon segfaulting
<NCommander> persia: that beign said, since we were dealing with a miscomplication, everything might need a bump-build :-/
<persia> That's not enough.
<persia> So, phonon was built against qt4-x11 ...ubuntu8, which was broken.  It segfaulted.  apachelogger rebuilt it against ...ubuntu9, which is the latest.  Same segfault.
<persia> konsole is even segfaulting.
<apachelogger> NCommander: http://paste.ubuntu.com/568547/
<NCommander> apachelogger: what hardware are you one?
<apachelogger> NCommander: n900
<GrueMaster> apachelogger: Try building with gcc-4.4 & adding -no-pch to the extra_configure_opts.  This is what was needed to get a working qt.
 * apachelogger i going to bed in a bit
<GrueMaster> Just building with gcc 4.4 isn't enough as 4.4 has a bug with precompiled headers.
<apachelogger> GrueMaster: I do not think that was built against 4.4 at all
<apachelogger> just a rebuild against new Qt
<persia> NCommander, Are we going to need to rebuild a significant chunk of the archive like that?
<apachelogger> which does not help as the function in question seems to be inline
<GrueMaster> I'm referring to gcc 4.4 not qt 4.4
<apachelogger> GrueMaster: that is what I meant too ;)
<NCommander> persia: I honestly don't know at this point
<persia> See, if qt4-x11 is broken, I'm sorely tempted to upload a replacement that causes everything to fail to built against it, to reduce the number of times we have to reupload stuff later.
<NCommander> persia: but its not broken, unity-2d now works fine against it
<NCommander> as do other Qt apps, the problem seems tobe kdelibs
<persia> Ah, so Qt works, but KDE is broken?
<ScottK> It can't be too broken as I can build against it.
<ScottK> persia: ^^^
<persia> ScottK, Sure, but if you're building with an inline macro that generates a segfault at runtime, you may not find the results very useful.
<ScottK> True, but I'm bulding kdebindings.  I think kdelibs has to actually do stuff for that to work.  Not sure though.
<persia> I don't know.  From what I can tell from IRC traffic and bugs, it seems that there are two issues: firstly that gcc-4.5 has a reference count issue meaning that inlines in nested functions can break stack accounting, and gcc-4.4 has an issue with precompiled headers not being compiled in a way that safely allows reuse.
<persia> This only affects some code, with certain sorts of inline macros.  Where that would be hit isn't clear.
<ScottK> We'll re-upload all of KDE before release, so it should be ~fine as long as it's sorted soon.
<persia> I don't think it would be advantageous to apply workarounds to everything that seems dodgy, but a simple rebuild (as tested with phonon) doesn't seem to help.
<persia> There's a candidate patch under review by the Linaro gcc team for gcc-4.5, which looks like it might do the right thing.
<persia> (at least in terms of generated RTL)
<persia> I'm mostly concerned about the timing: with feature freeze and Alpha 3 coming up relatively soon.
<ndec> ogra: hi! any news regarding the alsa upgrade in the archive?
<ndec> persia: ^^^ you might be interested too
<ogra> ndec, i havent heard from TheMuso yet buut pinged him
 * XorA|gone dances
 * ogra shades his eyes
<apachelogger> GrueMaster, NCommander, persia: building phonon with gcc 4.4 and -no-pch seems to fix the segfault there ... so I guess we need a fixed gcc 4.5 or the better part of Qt based libs will have to get that workaround :/
<apachelogger> actually I have semi-random segfaults now, so clearly nothing in phonon ^^
<ogra> apachelogger, talk to the toolchain guys in #linaro
<ogra> they will be intrested in debugging data to track down and fix the compiler issue
<ogra> they solved our last issue within two days
<ogra> (though it took two weeks to get them the right data and actually prove its gcc)
<apachelogger> oh
<apachelogger> https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/705689/comments/30
<ubot2> Ubuntu bug 705689 in gcc-4.5 "Qt applications crash with segfault error on armel when Qt is built with gcc 4.5 on natty" [High,Confirmed]
<apachelogger> seems they have a patch already
<ogra> yes
<ogra> i dont think gcc was uploaded since
<ogra> ask linaro if they ahve a testbuild in a ppa or so
<kenws> Hi there, Does anyone know where to find the ddebs for natty?
<kenws> The following apt.sources line doesn't seem to work:
<kenws> deb http://ddebs.ubuntu.com natty main restricted universe multiverse
<ogra> kenws, well, it should looking at http://ddebs.ubuntu.com/pool/main/ there are armel versions
<kenws> ogra: thanks, do you know how the corresponding apt.sources line would look like?
<kenws> brb
<ogra> the above should technically work
<ogra> kenws, did you run apt-get update after adding the line ?
<ogra> https://wiki.ubuntu.com/DebuggingProgramCrash ha smore details
<ogra> you might need to add the key etc
<Neko> http://blog.efikamx.info/2011/02/one-kernel-to-rule-them-all.html Efika MX Smartbook devs might want to build a shiny new kernel from here :)
<kenws> ogra: hm, this exactly what I'm using in my sources list
<ogra> kenws, and you did apt-get update
<ogra> kenws, and also impotred the gpg key
<kenws> ogra: yes
<kenws> also yes
<kenws> http://pastie.org/1579164
<kenws> http://pastie.org/1579161
<ogra> https://wiki.ubuntu.com/DebuggingProgramCrash
<kenws> ogra: yeah, and it matches what I have or am I blind? : )
<ogra> how do you try to get a ddeb ?
<ogra> you need a special invocation of apt for that
<ogra> its documented on the page too
<ogra> (point 6)
<kenws> ogra: but the apt-get update fails to fetch the Packages.gz that is before the user installs any ddebs
<ogra> weird
<ogra> http://ddebs.ubuntu.com/dists/natty/main/binary-armel/
<ogra> Packages.gz is there
<kenws> yep, but what about natty-updates, natty-security and natty-proposed?
<ogra> no security updates in the dev release ;)
<ogra> nore -updates or -proposed test archives
<kenws> point 2 of that wiki page seems to indicate that they shoul be there
<ogra> for a release they are
<ogra> but natty isnt released yet
<kenws> ok, i see
<kenws> ogra: thanks for your patience : )
<ogra> np :)
<NCommander> apachelogger: *groan* :-(
<ogra> Bug 721121
<ubot2> Launchpad bug 721121 in humanity-icon-theme "Icon in Launcher should be home folder icon" [Medium,Triaged] https://launchpad.net/bugs/721121
<ogra> heh
<GrueMaster> You should see the comments.
<apachelogger> NCommander: only that bug is keeping us from having an almost rocking kubuntu mobile :(
<apachelogger> kernel is close to inclusion too
<apachelogger> ScottK, mpoirier: http://people.ubuntu.com/~apachelogger/tmp/sshot1.png
<Neko> https://bugs.launchpad.net/update-manager/%20bug/610820
<Neko> is anyone ever going to fix this?
<prpplague> Neko: that the full url?
<Neko> https://bugs.launchpad.net/update-manager/+bug/610820
<ubot2> Ubuntu bug 610820 in update-manager "Download size discrepancies" [Undecided,Confirmed]
<Neko> on ARM it says 704MB, 740MB, 74.0MB or some variation, it's so weird that it always has a 7 and a 4..
<Homefix> anyone here i can annoy?
<Homefix> Hello? anyone
<Homefix> ogra:
<Homefix> rbelem:
<rcn-ee_at_work> Homefix, maybe you should state your question, and if it interest's someone they might answer.. ..;)
<Homefix> sorry babysitting had a mess......
<Homefix> I am missing var/run/dbus in my chroot using arm lucid build
<Homefix> im soory..........
<Homefix> im missing.....
<Homefix> pid system_bus_socket normal?
<Homefix> i must be loosing my mind i am running a ubuntu arm img lucid on my htc evo my article:http://forum.xda-developers.com/showthread.php?t=932754
<Homefix> i am able to windows share thru hamachi I thought upstart does not function in that kind ov enviroment?
<Homefix> Nautilus does not share, it did with karmic,
<Homefix> sksudo nautilus brings up : (nautilus 1010) : WARNING**: Failed to connect to socket /var/run/dbus/system_bus_socket: no such file?
<Homefix> Help
<rcn-ee_at_work> Homefix, i'd bug the guy who wrote the article.. the people on this list are usually running boards where we have access to everything.. bootloader -> kernel -> rootfs..
<Homefix> i wrote it
<rcn-ee_at_work> ah fun.. so which kernel do you have on there?  lucid really needs 2.6.32+ ?
<Homefix> of corse the kernel is mising bits and peices
<Homefix> maybe it might be another issue u could help me with
<Homefix> other than the kernel
<rcn-ee_at_work> not likely, my chroot's work just fine, using debian squeeze as a base, chroots for (karmic/lucid/maverick/natty)
<Homefix> im just looking for a kind help im not as intellegent as most of u people. thats all maybe ill get lucky and find a solution, what have i got to loose besides time. and maybe gain a friend:)
<rcn-ee_at_work> google shows with that error, try restarting dbus in your chroot..
<Homefix> i would be satisfied with karmic ( no uppstart to mess things up in the chroot) but the programs stop opening after some time.
<rcn-ee_at_work> Homefix, https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/441100 workaround seems promising
<ubot2> Ubuntu bug 441100 in dbus "within chroot, can fail to reload daemon configuration if not running (detects dbus daemon outside of chroot)" [Medium,Triaged]
<Homefix> I am unable to connect to upstart
<Homefix> I now but i dont quite understand somthing.................
<Homefix> I beg you would this workaround apply to this please look:http://forum.xda-developers.com/showthread.php?p=10584098#post10584098
<Homefix> i dont have a dbus outside the chroot right?
<Homefix> so im stuck with karmic?
<Homefix> Im using an android kernel
<Homefix> arm7
<rcn-ee_at_work> it would seem so..  if you can get the kernel source, i've heard htc has that.. enable CONFIG_DEVTMPFS with atleast 2.6.32 should get you closer..
<Homefix> yaaaaaaaaaa
<Homefix> thanks for somewere to go ILOVEYOU
<Homefix> like i said u amaze me with your knowledge
<Homefix> and thank u
<Homefix> rcn: one more thing please explain what is the "atleast 2.6.32" it cant mean ver.
<rcn-ee_at_work> in lucid, that config was manadority and it was enable with 2.6.32
<rcn-ee_at_work> i'm not sure if it matters for the os underneath the chroot.....
<Homefix> rcn: how woul i enable in the kernel "CONFIG_DEVTMPFS 2.6.32" on a line, then compile ?
<Homefix> add that is
<rcn-ee_at_work> it's a .config option.. have you built kernel's before?
<Homefix> well i enabeled loop_devices im the kernel i am using i have a lot to learn
<Homefix> I will post over at xda to get help with this
<pmathews> <rcn-ee_at_work> manadority?
<xerebz> i'm trying to compile opencv 2.2 on a beagleboard xm but i get this: http://pastebin.com/X3H4SsDc
<rcn-ee> pmathews, try booting lucid with out it.. i belive it's udev dependicy..
<pmathews> <rcn-ee> define  manadority
<rcn-ee> oh it's been awhile.. but during lucid's development cycle, you couldn't successfully mount lucid on a 2.6.32 kernel with out..
<pmathews> man  manadority
<pmathews> No manual entry for manadority
<rcn-ee> this was on the beagle at the time..
#ubuntu-arm 2011-02-19
<rcn-ee> "required"
<pmathews> no luck with " find / -name manadority -maxdepth 6" either
<pmathews> or "which manadority"
<rcn-ee> bug: 510130 https://lists.ubuntu.com/archives/kernel-team/2010-January/008518.html
<rcn-ee> sillybot seems slow... https://bugs.launchpad.net/ubuntu/lucid/+source/mountall/+bug/510130
<ubot2> Ubuntu bug 510130 in linux-ec2 "ec2 instance fails to boot if registered without ramdisk" [High,Fix released]
<pmathews> got it - you meant mandatory
<sim_> hi. which qemu gives best results for beagleboard ubuntu-arm?
<ogra> the one in natty
<sim_> ok, looking...
<sim_> would that be qemu-system-arm?
<sim_> ogra, is it in qemu-kvm-extras.
<ogra> that should be a transitional package, but yes, it should get you the right bits
<sim_> any change i will get it to work by rebuild of source package from natty under maverick?
<ogra> if you rebuild the right one, you want the qemu-linaro source package, it uses omap by default for all VMs in natty
<sim_> ah, qemu-kvm_0.14.0~rc1+noroms-0ubuntu3.dsc no good?
<ogra> no, look for qemu-linaro
<sim_> found it
<sim_> shall i configure and compile from trunk/2011.02 instead?
<ogra> i think thats the same as what is in natty atm
<sim_> https://launchpad.net/ubuntu/natty/+source/qemu-linaro says newer version avail
<sim_> do you know quick tip to install builddeps, i can take package names from dsc, but there might be a better way.
<ogra> "for packaging"
<ogra> just sudo apt-get build-dep qemu-kvm should suffice
<sim_> ok
<ogra> i doubt they changed much between natty and maverick
<sim_> indeed
<sim_> LOL: E: Unable to find a source package for should
<sim_> is bootloader for beagle included in qemu-linaro?
<sim_> is ../ubuntu-10.04-netbook-armel+omap.img an SD card  image?
<ogra> sim_, yes, its supposed to be dd'ed to an sd and contains two partitions, the rootfs partition gets expanded to the full size of the SD on first boot
<sim_> im puzzling on the qemu-system-arm cmdline.
<sim_> does it load the kernel from the SD, or do i need to spec it on the cmdline?
<ogra> i think you need to spec it on cmdline
<ogra> but tbh i havent tried the linaro packages yet, there might be a way to just use u-boot from the image
<sim_> u-boot resides in flash i guess, so i should build a flash image first and present to qemu on cmdline?
<sim_> -mtdblock i think?
<ogra> u-boot resides on the first partition of the SD card image
<ogra> none of the boards we currently build for have flash
<ogra> (while you can use a beagle C4 with the images its not really recomended and the XM which we test on has no flash)
<sim_> ogra, its a casper image
<ogra> ??
<sim_> i unpacked ubuntu-10.04-netbook-armel+omap.img and it looks like a bootcd
<ogra> yes
<sim_> ah, its a live image.
<ogra> no
<ogra> its a preinstalled image that expands itself to the full size of the card on first boot
<sim_> ok
<ogra> nothing "live" in there
<sim_> do you know the qemu cmdline i should use to boot it?
<ogra> no, sorry, check the linaro documentation
<ogra> they likely have info on their wiki
<sim_> ok thanks.
<sim_> ogra, is there nand emulation in qemu?
<ogra> no idea, might be for some ancient machines
<sim_> beagleboard has NAND
<brendand_> hi
<brendand_> i have a beagleboard C4 which i'd like to use for some tinkering around
<brendand_> it appears to be configured so that it 'autoboots' after some timeout if i don't press a key
<brendand_> using minicom i can't seem to send a keypress such that it cancels the autoboot
<brendand_> so it's kind of useless fo me at the moment
<brendand_> is there anything unusual i need to do to send keypresses over serial?
<brendand_> input is coming over just fine it seems
<rcn-ee> brendand_, is this a fresh install that you did, or did someone else set it up for you?
<brendand_> well, i'd say i got it from someone else, but that would be lying
<brendand_> i actually used to do some stuff on it with Windows
<brendand_> and hyperterminal worked fine for sending keystrokes
<rcn-ee> okay, well the 'autoboot's' is not normal.. so either some configured it do that.. or... ;)
<brendand_> i did
<brendand_> :P
<brendand_> yes - i got myself in this situation...
<brendand_> embarrasing
<rcn-ee> so undo it?
<rcn-ee> if you don't remember what you did, just reinstall it a base os and start again..
<brendand_> that would be one way. wouldn't i still need to be able to send keystrokes to do anything with u-boot?
<rcn-ee> ah.. u-boot's autoboot..
<rcn-ee> so you don't want it to autoboot, but stay in u-boot?
<brendand_> yeees
<brendand_> well. i think i do
<brendand_> certainly i'd like to be able to interact with u-boot in some way
<rcn-ee> well... in u-boot, type printenv... you'll see the whole enviroment scripts including the autoboot stuff..
<rcn-ee> but your on your own..i just use u-boot as a bootloader, nothing else..
<brendand_> http://pastebin.com/GHZayL8m
<brendand_> at line 13 i'm just hammering keys and it counts down from 3
<brendand_> ah
<rcn-ee> thru the serial terminal?
<brendand_> yeah
<rcn-ee> has it worked before?
<brendand_> in windows
<rcn-ee> ah.. dump minicom... use gtkterm..
<brendand_> will do
<brendand_> have also tried putty and screen, with no success. let's see how this works
<Neko> ogra, there? anyone else who knows how linux-fsl-imx51 worked and why there is a seperate debian.fsl-imx51 directory?
<ogra> Neko, no idea and imx51 is removed from the archive since quite some time, fo rthe subdir talk to the kernel team during workhours, if you want to use imx51 today, use the linaro kernel
<ogra> (though the linaro flavour is called differently)
<Neko> ogra, it's for our kernel...
<Neko> because we use make-kpkg we have no .dsc and therefore don't get any virtual packages for linux-image-efikamx for now
<Neko> I don't care about fsl-imx51 but I do care that it is the only reference for this arch in ubuntu that has a debian directory that "works" for us.. seems the scripts were updated for 2.6.35+ and they don't build .31 kernels anymore. we're not spending the time to port to .35 just to fix a package error :D
<Neko> (there are other reasons pressuring that but not packaging :)
#ubuntu-arm 2011-02-20
<xerebz> i just installed maverick from the preinstalled image and i'm getting anything on the dvi out
<xerebz> i'm not*
<lilstevie> noes natty have better touch drivers that maverick
<lilstevie> does*
<persia> Ought do, but depends on hardware.
<lilstevie> ok
<lilstevie> well Xorg doesnt want to recognise touch events in maverick
<persia> There may be some noise due to specific issues, but for the most part you should see only the difference between 2.6.35 and 2.6.38
<persia> With which hardware?
<lilstevie> but the mtdev tools and utouch register the touch events
<lilstevie> Galaxy Tab
<lilstevie> AT42QT602240 touch panel
<persia> Ah, if you're seeing events with mtdev and utouch, you have kernel support.  I wouldn't expect any differences between maverick and natty in terms of driver support.
<lilstevie> hm
<lilstevie> I do not know what driver to use for it though
<lilstevie> evdev/evtouch dont seem to register events
<lilstevie> evdev segfaults
<persia> It's probably worth tracing the events through the stack: while I'm convinced you're getting something useful from the kernel to userspace, there's some chance that you have a strange set of events that doesn't cause changes in X or Y.
<persia> Excellent!  segfaults make debugging easy.
<lilstevie> utouch gives X/Y events
<persia> Dig up a stack trace, and determine what is out of bounds, has an unexpected value, etc.  That ought show what isn't handling.
<persia> If utouch gives X/Y events, what isn't working?
<lilstevie> well evdev segfaults
<lilstevie> the other drivers just dont register touches
<lilstevie> how would I go about getting that stacktrace
<persia> Either enable apport, and fiddle with apport-retrace, or attach gdb pre-segfault, and ask gdb for "bt full"
<persia> You'll want the appropriate debugging symbols installed for whatever is segfaulting (and sometimes that ends up crossing layers)
<lilstevie> persia: how would i attach gdb to it
<lilstevie> cause attaching to x and its pid doesnt give me anything
<persia> https://wiki.ubuntu.com/X/Debugging is probably a good place to start.  I don't know that much about precisely how the layers interact: most of my input work has been at the /dev/input level
<lilstevie> ah ok
<lilstevie> persia: http://pastie.org/1584978
<persia> Next: go dig in the source.  Find out what miDCRestoreUnderCursor does.  Find out what is does with those arguments.
<lilstevie> kernel or the x driver
<persia> apt-file is your friend: you're looking for midispcur.c
<lilstevie> ah ok
<persia> If that doesn't work, I'd try X first, but could be the kernel.
<persia> Anyway, the problem might not actually be at the place the segfault happens: sometimes the bug is a few levels up.  I'll recommend going up and down the stack a couple times, to make sure you understand what is going on.  At some point, I suspect you'll suddenly realise the nature of the bug.  Most patches tend to be obvious (check a return value, add bounds checking, catch an exception, initialise a variable before using it, etc.)
<lilstevie> persia: turns out that miDCRestoreUnderCursor is missing
<persia> Heh.  Either make sure it's not implied by the structural definition, OR implement it, and everything ought be fine.
<lilstevie> hm
<lilstevie> I am wondering what calls it though
<persia> miSpriteRemoveCursor()
<persia> Each frame in the stack represents a call: dig back until you find something that exists.
<persia> Be aware that X tends to have a pluggable model, so that functions tend to be defined as structures, with some implementaitons providing more than others.
<persia> There's supposed to be matching declarations, so that nothing not implemented is declared, but it's easy to drop the ball between headers and implementation, especially if one is attempting to implement some other driver and copied the headers.
<lilstevie> hm
<lilstevie> thing is this is just using xorg from apt
<persia> Sure, but that doesn't imply anything particular about the folk who wrote it.
<lilstevie> heh
<persia> People make mistakes.  Software has bugs.  If we can find them, it's best if we can track down the reason, and try to fix.  Most folk who maintain software tend to be very glad when someone catches something they dropped.
<persia> And lots of times, especially for X, it seems that folk implement only enough to meet their test cases, rather than attempting any sort of top-down approach for full function coverage: there's heaps left for other folk to implement if they need it.
<lilstevie> hm
<lilstevie> I don't know enough about how x works :/
#ubuntu-arm 2012-02-13
<GeorgeJ> Hello folks!
<GeorgeJ> IS there any ARM channel on freenode?
<GeorgeJ> Specific to ARM, not neccesarely ubuntu-arm.
<cooloney> GrueMaster and NCommander, i uploaded armadaxp kernel to PPA, building is ok.
<NCommander> infinity: ogra_: anyone want to review the kernel before I upload?
<infinity> NCommander: It'll land in NEW anyway, I can review it there. ;)
<infinity> NCommander: Unless you suspect it's a mess and will need a few iterations.
<NCommander> infinity: its pretty hidious, but I think I got everything correct.
<infinity> Is there any reason that, despite using the omap4 packaging, it's only building for armhf?
<GrueMaster> infinity: Define "mess".  It does need work, but the sooner we get it into main, the sooner we can spin images and hammer it with more tests (and file bugs against it).
<infinity> I mean, I know we'll only build IMAGES for armhf, but there's no reason not to provide the kernel for armel too.
<GrueMaster> Mainly for testing.  We have a very limited quantity of systems.  Beyond that, I don't see a reason for no armel rev.
<infinity> NCommander: Anyhow, what I see for ~ppa4 looks fine on the surface, but I haven't done copyright audits and the like, which I'll do when it lands in NEW.  So, make sure debian/copyright is sane.
<infinity> GrueMaster: Yeah, it just didn't make sense to me to intentionally fork that from the omap4 packaging.  Had it been cargo-culted wholesale, it would have armel too. ;)
<infinity> But, not picky.
<NCommander> infinity: well, I need to cut some crud, I don't thinkwe need linux-armadaxp-libc-dev
<infinity> Most people should only ever want armhf on this thing anyway.
<infinity> NCommander: I don't see that in the published packages...
<NCommander> oh, it got stubbedout
 * NCommander is going through one last time
<infinity> NCommander: Anyhow.  Yeah.  Just double-check that licensing stuff is right, blah blah, any last-minute crap you care about, upload, and I'll put on a different hat and give it a proper review.
<infinity> NCommander: And we did, ultimately, get agreement from all concerned parties to jam this in main, right?
<NCommander> infinity: I used the existing copyright with a notice that its Linux for ArmadaXP, and that Marvell added that support
<NCommander> infinity: yes, we did, but we need a proper MIR for it
<infinity> We... Do?
<NCommander> (per skaet)
<infinity> It's a kernel.
<infinity> I'll talk to her about that.
<NCommander> infinity: publish it to universe for now. We can promote it later, but I need something sitting in archive
<infinity> I'll talk in parallel with my review.
<infinity> Of the tlak goes nowhere fun, I'll accept to universe.
<NCommander> infinity: thanks
<infinity> But I'd prefer to accept to main.
<infinity> So, we'll see how that goes.
 * NCommander would like someone else review this before kicking to the archive, but uploading 100 MiB to REVU on this linux will SUCK
<NCommander> s/linux/link/g
<infinity> And no orig either.  So, every iteration is a new land of suck.
<NCommander> infinity: I built one
<infinity> But, honestly, all of our !primary kernel packaging is a mess.
<NCommander> or more specifically
<infinity> apw and I have been talking about ways to make that less so.
<NCommander> I grabbed the .orig that was used in oneiric
<infinity> But for now, "Whatever, if it builds packages that work."
<NCommander> but it should make future uploads be about 4 MiB (the Marvell crap lives in diff.gz :-()
<NCommander> infinity: uploading now. Holding about 200 KiB (I found T-Mobile gave me better upstream than my home ISP or starbucks)
<infinity> That's a bit sad.  But good advertising for tmo. :P
<NCommander> 3 Mbit up/7 down according to speed test
<NCommander> Home connection is 256kpbs up/25 down
<NCommander> and t-mobile offers $30 prepaid SIMs with 5 GiB. When I hit the bandwidth cap, I run to the store, buy a new SIM, and run with it
 * NCommander went through about 10 GiB of 3G data in a week when we were in Austin due to the pathetic hotel wireless
<NCommander>   Uploading linux-armadaxp_3.0.0.orig.tar.gz: 19570k/94410k[Errno 104] Connection reset by peer
<NCommander> ARGH$#!@#!#^$
<infinity> NCommander: rsync --partial to chinstrap, and dput from there.
<infinity> NCommander: Then you can at least resume.
<NCommander> good idea
<GrueMaster> NCommander: I already have the ppa4 kernel in my chinstrap directory, if you want to save time.
<NCommander> GrueMaster: cooloney packaged it wrong and there is no orig.tar.gz so it needs a reupload
<GrueMaster> bah.  Figures.
<infinity> NCommander: Well, also...
<infinity> NCommander: If that's a bit-for-bit copy of the orig from oneiric, just grab it from the librarian to chinstrap and rename it.
<infinity> NCommander: Then upload diff and dsc, and dput.
<infinity> diff and dsc and changes even, but you know what I mean.
<NCommander> infinity: indeed
<GrueMaster> infinity: I didn't push the source up.  Just the binary .deb
<GrueMaster> Let me know if there is anything I can do to help.
 * infinity grabs a snack while this all goes on.
<NCommander> uploaded
 * NCommander waits for a NEW email
 * NCommander still waits for a NEW email
<NCommander> infinity: [ubuntu/precise] linux-armadaxp 3.0.0-1500.1 (New)
<NCommander> do your thing
<infinity> NCommander: Thinging.
<GrueMaster> ewww,
<TheMuso> ogra_: That thread for the AC100 config patch didn't go anywhere, so if that alsa-lib config snippet works with the aC100 for the kernel you have in precise for that hardware, then I'll put it in for precise, and we can sort it out properly in the future, when are get into the device-tree ira.
#ubuntu-arm 2012-02-14
<ogra_> TheMuso, oh, then please go for it :)
<GuiltyCrown> hello
<GrueMaster> GuiltyCrown: hello?
<TheMuso`> ogra_: Ok thanks, will do.
#ubuntu-arm 2012-02-15
<ogra_> janimo`, what about the ac100 kernel ? (FF is tomorrow, would be good to have the new version by then i think)
<janimo`> ogra_, I heard no other developments upstream - and di not check either
<ogra_> right, but the archive kernel is still at .8
<janimo`> we will have anew version anyway by release, it is not a feature, but incremental fixes
<guiltyCrow> sudo update-rc.d -f apache2 remove
<guiltyCrow> sorry wrong console
<guiltyCrow> :P
<janimo`> right, I'll update when marvin24 has it in the stable branch, last I checked (last week) it was on -exp
 * ogra_ is just seeing many people dpkg -i'ing your kernel from startx.ro
<janimo`> so we have to have the .deb in sync with upstream's stable branch
<ogra_> ok
<janimo`> and we had more suspend issues from what I saw on the list
 * ogra_ didnt bother to try suspend here, beyond that sound works so much better with the new one
<janimo`> ogra_, well they should, so they test it, too bad they do not report back to the mailing list
<janimo`> but if they report on #ac100 to marvin that is fine too
<ogra_> and the touchpad is supposed to be multitouch (not that i knew how to test that)
<janimo`> suspend does not work for me at all now
<janimo`> although it may be the nvidia thing again
<ogra_> well, i'm using the binary driver, so i dont even hesitate to test
<ogra_> i wouldnt expect it to work in this setup anyway
 * ogra_ blames nvidia here 
<janimo`> once marvin24 is happy with the stabel tree I'll make a new release
<ogra_> ok
<marvin24> janimo`: I merged -exp to stable some days ago
<janimo`> marvin24, ah great, I'll roll a package then these days :
<janimo`> :)
<marvin24> great - thanks!
<janimo`> marvin24, oh I see you have a 3.2 branch, sweet
<janimo`> I wish it were ready in a few months for the release
<marvin24> janimo`: yes, I'll think we have to wait for the 12.10 at least
<janimo`> marvin24, is it not building/booting :)
<marvin24> btw, is it possible to package experimental kernels?
<marvin24> janimo`: oh, what, which one?
<janimo`> marvin24, well we can have debs packaged
<janimo`> I would not put htem in the archives though
<janimo`> marvin24, 3.2, is that not even close to being ready?
<marvin24> that's no problem, people just need an url with the package
<janimo`> marvin24, well as I did with test kernels on startx.ro
<marvin24> janimo`: I can make it ready, but there is not much support from upstream
<marvin24> it is more like a quick and dirrty port
<janimo`> marvin24, if you have a concrete plan writing to the ml for help would be ok
<janimo`> indeed, since you have done this before
<marvin24> and I cannot maintain tegra specific stuff
<marvin24> I only added ac100 support
<marvin24> but 3.2 misses some tegra parts which I cannot include myself
<marvin24> on the other hand, 3.2 is booting and working so far
<janimo`> I know. But if you have an idea of what is exaclty missing and what kind of work is needed, putting it in a mail may get more poeple involved
<janimo`> I am interested in helpgin as well
<marvin24> mmh, I guess mostly better powermanagement support
<janimo`> in Ubuntu we'd all prefer a 3.2 to be in line with the rest of the kernels, for less post release pain
<janimo`> so we may put some effort in now if it helps in the long run and out free time permitting :)
<marvin24> yeah, but real life isn't perfect :-)
<janimo`> so if it boots/works without lockups and has no regressions in sound/video/wlan/pm etc, why not make a shot?
<marvin24> I prefer to keep 3.2 as it is
<janimo`> marvin24, ah and upstream only works on 3.3+ ?
<marvin24> I (and maybe others too) don't have enough info to get it working in a sane way
<marvin24> janimo`: upstream still misses usb device tree support (and video of course)
<marvin24> we have to wait until nv releases a kms kernel driver
<janimo`> 'of course' : I have no idea, I am not familiar with the upstream kernel status :)
<marvin24> I heard someone is working on it
<janimo`> ah so it does not work at all? Why is kms needed for the gfx accelerated proprietary bits?
<marvin24> no, the current implementation is so ugly, it cannot be upstreamed
<marvin24> and a kms driver would propably require new userspace binaries
<marvin24> so don't expect it to land soon
<marvin24> on the other hand, nv already began to upstream some gound working (gart, iommu)
<marvin24> if people like to work on tegra 3.2, feel free to send patches ;-)
<newbie> joined
<Guest89622> excuse me
<Guest89622> i need the ubuntu arm on qemu which have GUI....how i do ?
<Guest89622> i can install X-server ?
<Guest89622> excuse me...help me
<erbo> Guest89622: Have you looked at https://wiki.ubuntu.com/ARM ?
<Guest89622> it don't have what i want
<Guest89622> thanks
<infinity> jcrigby: Have you played with u-boot and gcc-4.6 at all?  It's now one of the only two packages keeping gcc-4.5 in main.
<ppisati> GrueMaster: so you basically added `smsc95xx.macaddr=$foobar` to your bootargs, right?
<GrueMaster> ppisati: That was how it used to work, yes.  I still want to keep the die id code, but IS needs this as they have some pandas with duplicate die id's.
<ppisati> GrueMaster: it seems this feature was borked since Natty onward
<GrueMaster> Hmm.  I haven't tested it since Maverick (die id code went in in natty).
<GrueMaster> How hard will it be to fix and SRU?  I'm sure IS will need it for the buildd pool, and I don't know what kernels they use.
<ppisati> GrueMaster: don't know, i'm investigating
<GrueMaster> Ok, thanks.
<GrueMaster> ppisati: I have been having an issue lately with the Dove SRU kernels.  The linux-headers-2.6.32-422 package is empty for some reason, and without it, I can't build kernel modules for security testing.  But I'm not sure how much I care either, as no one seems to be using it (except me for SRU testing).
<GrueMaster> Who on the kernel team should I ping about this?
<ppisati> empty???
<ppisati> anyway, i guess that's m
<ppisati> e
<GrueMaster> Well, copyright & changelog is there, but no headers.
<ppisati> doh!
<GrueMaster> Like I said, I'm torn between wanting completeness, and not caring about a system no one uses and will vanish in a couple of months.
<infinity> GrueMaster: I'm tempted to just not care about dove kernels.
<ppisati> perhaps ot's just a variable, i'll fix in the next SRU
<GrueMaster> Same here (especially if I don't have to do SRU testing anymore).  :P
<GrueMaster> ppisati: Don't go to too much trouble.  I've run all the other SRU tests.  No new holes.  I'll go ahead and pass this with a note.
<janimo`> infinity, which is the other package keeping gcc 4.5 in main?
<infinity> janimo`: grub2, u-boot-linaro, and now mysql again. :/
<janimo`> infinity, ah so not arm-only stuff
<janimo`> or is it grub2 on arm?
<infinity> janimo`: No, no.  grub2 and mysql everywhere, not just arm.
<AfouToPatisa> hello everyone, I would require some help with my preinstalled image for beagleboard please, who should I ask?
<pbuckley> just ask
<pbuckley> and someone will get to helping you
<pbuckley> its very async here
<AfouToPatisa> ah cheers
<AfouToPatisa> well I just installed ubuntu arm OMAP and my screen is flickering up and down
<AfouToPatisa> I cannot even read anything its running all the time
<AfouToPatisa> I installed it by SD card normally it should be fine...
<AfouToPatisa> oh I forgot to say the only error I got was this: 2190475264 bytes (2.2 GB) copied, 536.94 s, 4.1 MB/s dd: closing input file `standard input': Bad file descriptor
<infinity> So your image didn't write correctly to the SD card, for one.
<infinity> Though I can't see how that would cause screen flicker. :P
<AfouToPatisa> haha true :P
<infinity> I don't have a beagle, though, so I'm not entirely sure on the flicker front.
<AfouToPatisa> i guess i will rewrite it then...
<infinity> Which Ubuntu version are you using?
<AfouToPatisa> 11.10
<AfouToPatisa> btw , does the sync thing go alone?
<infinity> Kay.  You could try a 12.04 daily for giggles, but 11.10 should work.
<AfouToPatisa> thanks man, gonna give 12.04 a spin as well
<AfouToPatisa> see what comes out
<AfouToPatisa> im just installing because 10.04 was probably too old to support my touchscreen I guess :/
<AfouToPatisa> thanks brb
#ubuntu-arm 2012-02-16
<micahg> looks like upstream Chromium almost fixed the build on arm :)
<suihkulokki> micahg: I and markos attached patches that fix chromium on armel/armhf to the debian bug
<micahg> suihkulokki: now I find out, I just uploaded a new version :)
<micahg> ok, I"ll grab them for the next updat
<micahg> suihkulokki: I realized that I was only checking for armel in debian/rules, I fixed that for the next upload
<ogra_> hey kalikiana, good to see you around :)
<kalikiana> heyhey
<kalikiana> I checked out #arm before, seems the cool kids are all here :-P
<ogra_> well, here is where the community is ... way more important than the other channel ;)
<ogra_> hey micahg, whats that patch you talked about last night ? i think kalikiana would like to know about it
<micahg> ogra_: patch, what patch?
<ogra_> chromium
<kalikiana> micahg: oh, you're there, was just typing a mail
<micahg> I think it might work now without any patches
<micahg> I'm waiting on the first armel build from yesterday
<kalikiana> micahg: so who builds it? where's the package source?
 * ogra_ only saw that riku said he attached the patches to a bug ... but didnt mention the bug number
<ogra_> kalikiana, in the ubuntu archive i guess
<ogra_> (precise sources)
<kalikiana> I couldn't find working steps to get a cross-compile setup with all packages
<micahg> kalikiana: chromium-browser? the same way anything else in the archive is built
<kalikiana> micahg: well, but a human must have tested it :-)
<micahg> kalikiana: I think Debian must have upstream their patches
<kalikiana> meh, so yet another possible team to poke...
<ogra_> why ?
<ogra_> they will just end up in precise
<micahg> I also found a bug in the packaging, which I'll fix for the next upload to get armhf
<ogra_> just pull the precise source package for your project
<micahg> we don't merge from Debian for Chromium
<ogra_> micahg, that would be helpful, given we will make the switch today :)
<kalikiana> micahg: so do you have a working build setup?
<kalikiana> I'm running into broken deps
<ogra_> (armel will become unsupported from today on)
<micahg> kalikiana: no, these are archive builds, I upload 2 recent stable releases to precise
<kalikiana> hmm
<kalikiana> I really need to build it locally
<micahg> ogra_: I figured another chromium upload will come in a week or 2, if you need it sooner and armel works, I can upload with the armhf fix
<ogra_> yes please, we will stop caring for armel from today on
<ogra_> we wont stop building it, but nobody will look at issues
<micahg> ok, I'll keep an eye on it
<kalikiana> micahg: can you recommend a person who cross-compiles usually?
<micahg> kalikiana: only one I know is suihkulokki :)
<infinity> ogra_: "nobody" is a bit much, I always watch build issues on all ports.
<infinity> ogra_: I just prioritize. :P
<ogra_> infinity, hey, you are not supposed to be up at that time !
 * micahg does that too :)
<infinity> ogra_: I'm not, it's all in your head.
 * micahg is also not supposed to be up now
<kalikiana> micahg: k, I'll wait for him then
 * ogra_ was just trying to secretly spread FUD while infinity wasnt watching ...
<ogra_> damned !
<kalikiana> (or her)
<infinity> I'll be sure to call Riku a her the next time I see him. ;)
<micahg> kalikiana: did you try the instructions on the linaro wiki?
<ogra_> lol
<kalikiana> micahg: yes. but gconf2 and bzip2 at least are broken
<micahg> file bugs?
 * infinity wonders why everyone gets so excited about cross-compiling.
<infinity> Especially to the point of wasting days/weeks trying to make it all work right.
<kalikiana> infinity: because it is several times faster
<infinity> When you could just build natively (sure, more slowly), but be done with it.
<infinity> kalikiana: Not when you factor in all the annoyance. :P
<kalikiana> well, the setup is actually simple. the problem is really that arm is relatively recent
<ogra_> yeah, its such a waste
<infinity> "recent"?
<ogra_> heh
<suihkulokki> we even wronte instructions to cross-compile chromium: https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/ChromiumCrossCompile
<kalikiana> infinity: as in packaging :-)
<kalikiana> yes
<kalikiana> and those don't do it
<ogra_> we have it since jaunty ...
<kalikiana> hey suihkulokki
<ogra_> and debian has it since ... hmm, forever
<kalikiana> suihkulokki: gconf2 and bzip2 are broken
<suihkulokki> bug# ?
<kalikiana> suihkulokki: the packages don't install
<ogra_> infinity, do you know if anyone talked to kate about armhf ? we should make her announce it in the FF announcement i think
<kalikiana> suihkulokki: is it expected to work as described there, as in used by somebody on a regular basis?
<infinity> ogra_: I brought it up when I spoke to her on the phone on Monday, but we didn't discuss a formal announcement.
<suihkulokki> kalikiana: yes if you don't deviate from the steps
<ogra_> ok, i'll ping here if she is up to make sure she doesnt forget
<infinity> ogra_: Also, I think we need to be careful how we word such an announcement.
<infinity> ogra_: People seem gung-ho to say things like "we only support armhf now!" which is patently untrue.
<infinity> ogra_: It's just that we've selected armhf as the LTS arch.
<ogra_> k
<ogra_> lets make sure that goes into the announcement then
<kalikiana> suihkulokki: I don't. so is there somebody who I could poke about those packages? I'd think bugs might not exactly receive attantion very quickly
<ogra_> though i suspect we will stop building armel images for some flavours
<ogra_> at least until your LP changes are ready
<infinity> ogra_: (From a Canonical standpoint, yes, we only support armhf now, but Canonical != Ubuntu, and we need to be clear about that, or just steer clear of such statements, I prefer the latter)
<suihkulokki> kalikiana: pastebin your errors please (as well as what is in your sources.list)
<infinity> ogra_: I intend to drop armel images for !omap tomorrow.
<infinity> ogra_: But installer/image support != archive support.  Again, distinction is key. :)
<ogra_> if we can it would be nice to keep el and hf for ac100
<ogra_> simply for the binary driver
<infinity> ogra_: Yeah, that's fair.  It's also a good platform for us to keep testing armel on as a community port.
<infinity> ogra_: Alright, I'll keep omap and ac100, and drop mx5 and omap4.
<ogra_> ++
<infinity> (The reason I'm keeping omap is simply because it's the only kernel that builds from mainline, so it's "free" from a maintenance perspective)
<ogra_> yeaqh
<infinity> Plus, we might free up some beagles from the DC soon, and pass them around to people, thus making omap useful. ;)
<infinity> ogra_: Oh, we did get some indication at Connect that nvidia is actually planning armhf builds of their binary driver.
<infinity> ogra_: I was told they've already done builds in-house, they're just working on the tarball drop.
<ogra_> yeah, but they dont exist yet and we have no promises they will be there by release
<infinity> So, we'll see.
<ogra_> i'm carefule about them if it comes to timelines (unlike ndec whom i belive blindly if he says it will come)
<infinity> Heh.
<infinity> Well, this was engineers, not legal.
<kalikiana> suihkulokki: http://pastebin.ubuntu.com/844219/
<infinity> Which is a double-edged sword, I guess.
<infinity> The engineers are doing the real work, and they know what they've done.
<infinity> Then again, they don't get to do the final release to the website.
<ogra_> yep
<ogra_> fi engeneering had a say, we would have everything in since a year or two, i know
 * micahg still would like an mx51 kernel for precise, but fears that's not happening
<infinity> micahg: For babbage, or efika?
<ogra_> micahg, complain to linaro, we donmt maintain that arch :)
<micahg> efika
<infinity> micahg: For efika, talk to markos.
<infinity> micahg: He promised me a kernel.
<ogra_> for what ? netbook or nettop ?
<infinity> micahg: I even promised him unofficial image enablement if he got me a working kernel. :P
<infinity> ogra_: Yes.
<ogra_> there was an or in the question
<infinity> ogra_: (He seemed to think he could build one that would work on both)
<micahg> ogra_: I have both, would prefer the smartbook
<ogra_> unless they very recently started having a unified kernel
 * ogra_ too, i have one here as well
<micahg> although, I guess I'd prefer an armhf kernel for mx51 :)
 * infinity has a smarttop.
<infinity> micahg: Kernels are FP agnostic.
<micahg> oh, ok, cool
<ogra_> packages arent indeed :)
<infinity> micahg: But seriously, nag markos.  If he can get me something that's sane, I'll get it into universe.
<micahg> infinity: I'm happy to be the second reviewer on that ;)
<infinity> micahg: I wouldn't mind a vaguely current kernel on my efika either. :P
<suihkulokki> kalikiana: argh. looks like I have uploaded a precise targetted gconf to the ppa's oneiric side
<infinity> (Though it is the slowest ARM device in my house)
<ogra_> you dont have beacgle A/B versions ?
<suihkulokki> kalikiana: tho the bzip2 should install just fine
 * ogra_ has a beagle A1, thats definitely the slowest
<micahg> suihkulokki: is there something we should fix in precise for cross compiling?
<infinity> ogra_: I have no beagles.
<ogra_> ah
<infinity> ogra_: My N900 used to be the slowest ARM device on my desk, but I sold it to Sledge.
<ogra_> yeah, and thats already twice as fast as an A1
<infinity> ogra_: So, now I have the efikaMX, an i.MX53, a Panda, an ac100, and an LGP999 (Tegra2 phone).
<kalikiana> suihkulokki: ah. yes, sorry, bzip seems okay at this point. I tried a different ppa before, but made sure to clean up before I pasted
<ogra_> and has enormous amounts of ram compared...
<infinity> It's a bit sad that the phone is actually the fastest of the bunch.
<kalikiana> suihkulokki: any chance you could re-upload it correctly? anything I can bribe you with? :-P
<ogra_> stop using it as a phone then and send it to lamont as a buildd :)
<infinity> I used it as a buildd during the armhf bootstrap. :P
<ogra_> heh
<ogra_> we should make tobin build a cluster of them in a rack case :)
<suihkulokki> kalikiana: testing.. will ping back in a hour or so
<suihkulokki> micahg: gconf2 is probably the most annoying thing missing multiarch conversion in precise.
<infinity> micahg: So, I harassed markos, and he said they're (A) working on 3.2 for efika/mx51, and (B) it will be a unified smarttop/smartbook kernel.
<infinity> micahg: And he's going to try to get me half-functional bits ASAP so I can work with them in my copious free time.
<micahg> suihkulokki: we might be able to do something about that, it's still got a lot of reverse dependencies though
<micahg> infinity: that's awesome, let me know if I can help with my copious amounts of free time
<suihkulokki> can't we just make chromium not use gconf? =)
<micahg> not for another year :)
 * micahg wonders if they have an option to s/gconf/gsettings/
<kalikiana> suihkulokki: wrt bzip2, I get this http://pastebin.ubuntu.com/844238/
<kalikiana> removing gconf from chromium shouldn't be that hard, but more time probably than fixing gconf2 packages :-P
 * micahg has plenty of other archive cleanup work to do
<ogra_> well, it eventually needs to move to gsettings anyway
<infinity> kalikiana / suihkulokki: That looks like the bzip2 in the linaro PPA was built with a broken gzip.  We've fixed that bug in precise... Though, if this is an oneiric PPA, it's a crap shoot if it'll break or not. :/
<kalikiana> yes, it's oneriric I need to build for
<infinity> kalikiana: You can work around it by just doing "dpkg --force-overwrite -i /var/cache/apt/archives/libbz2-1.0_1.0.5-6ubuntu2linaro1_armel.deb"
<suihkulokki> I'll throw backport of gzip to the ppa
<kalikiana> infinity: same error
<infinity> kalikiana: Oh, right.  "rm /usr/share/doc/libbz2-1.0/changelog.Debian.gz && dpkg -i /var/cache/apt/archives/libbz2-1.0_1.0.5-6ubuntu2linaro1_armel.deb"
<infinity> kalikiana: That'll make it happy. :P
<kalikiana> evil :-D let's try
<kalikiana> you won't believe, same error
<infinity> Err, that's not possible.
<infinity> Or, shouldn't be.
 * ogra_ wonders how that cross build setup is set up ... might be caused by that
<infinity> ogra_: No, it's just straight up multiarch and gzip sadness, I'm sure.
<ogra_> weird
<infinity> But deleting the target before installing the other arch's package should work...
<infinity> kalikiana: It's not complaining about another file now, perhaps?
<ogra_> kalikiana, seriously, how many days did you spend on getting that working now ?
<kalikiana> presumably "different" here includes that it exists
<kalikiana> ogra_: I had a different setup before that, native arm, wither other problems. although I could get it to sort of work, it wasn't exactly working well
<kalikiana> it took in the hour range to test anything
<ogra_> well, the build only takes 12h
<ogra_> at least the lsat successfull one in the archive did
<ogra_> given that you alkready spent several days to get your cross setup working ...
<kalikiana> it was not 12h, more like 2h, but still, that's no basis for working on code
<ogra_> 2h ? for a plain make you mean, surely not for the package build (natively)
 * infinity decides to refrain from "when I was your age" stories.
<ogra_> haha
<kalikiana> ogra_: when I say native I mean chroot. which I guess is faster, but still a pain
<infinity> Besides, if you're "working on code", you don't rebuild from scratch every time, you have a built tree, and you let the magic of make only re-compile and re-link the bits you changed.
<ogra_> right
<ogra_> and that should just take minutes
<ogra_> unless you make clean every build
<kalikiana> infinity: unfortunately it includes changing the build system
<infinity> Fun.
<kalikiana> yes. plenty.
<infinity> Speaking of build systems.
<infinity> I'm grumpy that I need to teach fpc about armhf after all. :/
<ogra_> give it to NCommander :P
<ogra_> he did it several times before
<infinity> Because, despite not being VFP-aware, it DOES hardcode the linker path when linking with C code.
<ogra_> and doesnt have libO anymore on his plate .... he needs a new challenge
<infinity> suihkulokki: Say, about LibreOffice...
<suihkulokki> infinity: looks like janimo is ahead of me..
<infinity> Oh, I didn't realise Jani was working on it too.
<infinity> Hrm.
<infinity> Duplication of effort, for the loss.
<suihkulokki> ogra_: I could always tell people to use ebuilds when they want to cross-compile ;)
<micahg> infinity: any idea how to bootstrap gnat-4.6?
<infinity> micahg: Cross-compile from another arch, native compile and check for correctness.
<infinity> micahg: markos was working on it, and seemed to be stuck on the latter step.
<micahg> infinity: right, but how to do for the archive, same?
<ogra_> suihkulokki, lol
<infinity> micahg: Cross, native, plunk native in my stage-2 repo of doom, build on buildds.
<micahg> infinity: ah, cool, ok, that's what I thought which is why I can't do it :)
<infinity> micahg: If you can get the first two steps done, I won't mind. :P
<janimo`> \o/ libreoffice passes the bridge tests on armhf, on to the rest of the build
<infinity> micahg: If you give me a self-hosting gnat, I'll happily turn it into something archivey.
<infinity> janimo`: !
<janimo`> infinity, !
 * janimo` does not let himself be intimidated by excalmation marks
<ogra_> janimo`, !!!!
<ogra_> !
<infinity> Hahaha.
 * janimo` collapses
<xranby> janimo`: !o!
<infinity> janimo`: That's awesome news.  And I suspect awesome news for suihkulokki, who now doesn't have to care. :P
<janimo`> infinity, yep. I just need top make sure it works on OABI - the code still has that support although I am not sure who still cares
<janimo`> xranby, is that the 'happy drummer' sign?
<infinity> janimo`: Pardon my French, but fuck OABI.
<infinity> janimo`: If anyone's building Open/LibreOffice for OABI, they should be shot.
<janimo`> infinity, my thoughts exactly only I express them more delicately
<janimo`> I was not sure how much Debian cares about baxckporting TBH, I am not sure either how much of Debian users are on legacy hw/installs
<infinity> janimo`: More to the point, while an upstreamable fix might need to keep OABI working (though, god knows why), a Debian/Ubuntu patch clearly doesn't.
<janimo`> I plan on pushing upstream today
<janimo`> and deal with bug reports if OABI people come along
<infinity> janimo`: Debian doesn't support OABI.
<suihkulokki> OABI is forgotten in debian. however we should check it doesn't break EABI softfloat
<janimo`> I'll put ifdef around FP regs usage and that should be all I guess
<infinity> suihkulokki: EABI soft, or softfp?
<janimo`> suihkulokki, test passes on armel as well
<janimo`> but only hardfloat tested
<infinity> (God, that's confusing)
<infinity> janimo`: Our armel is softfp, which is still VFP-aware.
<janimo`> I have no soft (no FPREGS usage at all) setup
<infinity> janimo`: Debian's armel isn't.
<infinity> And somewhere along the way, my head explodes.
<janimo`> aha, that indeed needs to be checked for, I'll make use of the SOFTFP define then and hope it is not too much work
<janimo`> infinity, suihkulokki can I test a Debian/softfloat setup in an ubuntu hosted chroot ? just create a sid-armel one?
<suihkulokki> janimo`: yes
<janimo`> schroot I mean if it matters
<janimo`> oh great then
<infinity> janimo`: Yeah, kernels are completely VFP agnostic, so debian-armel chroots work fine.
<infinity> (And armhf, and, and)
<janimo`> excellent
<suihkulokki> janimo`: didn't you ifdef the hardfb abi with__ARM_PCS_VFP already? that should not be set on either debian or ubuntu armel
<janimo`> suihkulokki, yes that one I used
<janimo`> but I noticed there's another SOFTFP variable too
<janimo`> so it may all just work indeed
<infinity> Which may or may not relate to softfp.
<ogra_> hardfb ? hard floating bubble ?
<infinity> Because the soft/softfloat/softfp naming between toolchain and userspace applications is never consistent. :P
<infinity> (Heck, it gets even worse when Oracle refers to softfp as "hard-float")
<xranby> heh yes.
<ogra_> haha
<infinity> And they're not wrong.  It is hard float.  Just not what WE call hard float.
<xranby> its kind of funny oracle compared their tuned armel builds against icedte built using debian squeeze
<ogra_> could have been worse
<ogra_> they could have built against woddy
<infinity> We didn't have armel in woody, did we?
<ogra_> nah
<infinity> woody would have been OABI, I believe.
<ogra_> only arm i think, if at all
<infinity> But it's been a while.
<xranby> i think we are doing good, at least our work runs on the armhf ABI
<infinity> I dunno.  I gnored all you ARM weirdos back then.  I was working on promising new future technologies like m68k and parisc.
<ogra_> mips ?
<infinity> I wasn't a mips porter, no. :)
<infinity> 68k, parisc, powerpc, and alpha.  I sure can pick 'em.
<infinity> 1 out of 4 isn't bad, right? :P
<ogra_> mmm, alpha ... i loved them
 * janimo` completely forgot how he created the precise-armhf schroot, now needs to figure out same for debian.sigh
<janimo`> I do not recall running debootstrap explicitly
<janimo`> and my bash history agrees
<janimo`> it may have been mk-sbuild
<infinity> janimo`: debootstrap --variant=buildd --arch=armel sid sid-armel http://ftp.debian.org/debian
<infinity> janimo`: Ish?
<janimo`> yes, it was not that I guess, probably mk-sbuild did it all behinf the curtains for me
<janimo`> do debootstrap and schroot have a common location for chroots in which case I may just do that above
<janimo`> mk-sbuild --eatmydata --arch=armel precise was it
 * janimo` remembers seeing the one and only alpha machine sometime in 94 at an expo. It was higher Mhz that the 486's (150 I think) and it had a video promo of Jean Luc Picard extolling its virtues
<janimo`> probably they though it was meant for enterprise servers
<infinity> janimo`: debootstrap has no canonical location for anything, it just creates the chroot where you tell it to.
<janimo`> infinity, ok I just started a mk-sbuild so it is stored along with the rest of schroots
<suihkulokki> perhaps I can do the debian/armel build and testing
<janimo`> suihkulokki, sure thanks. I am setting up a sid chroot now but my panda would be happier if left to build only a precise armhf and not something else in parallel :)
<suihkulokki> janimo`: ok, on it
<janimo`> suihkulokki, softfloat in debian mean no actual VFP instructions in asm right? Not that they are trapped and emulated by the kernel
<janimo`> suihkulokki, you can stop the build after a couple of hours (not sure when) once the deps for bridges/ and testtools/ are built.
<janimo`> then make bridges.deliver testtools alternating with changes to code is easy iteratin
<suihkulokki> janimo`: do you have a line to grep in the buildlog when bridges have compiled?
<janimo`> suihkulokki, hmm, not sure I know where the bridges' module number is
<janimo`> what I did was ctrl-c and see if make brdiges works or says it has files missing
<janimo`> but  gcc3_linux_arm is a dir within bridges that needs to be entered so maybe good for grepping
<janimo`> last build of libo on armel in the buildd: 5 days 19 hours. Ouch
<infinity> janimo`: On a babbage, I assume?
<janimo`> assuming a panda is used instead of babbage it still likely be 1-2 days
<janimo`> infinity, yes some old board
<janimo`> I think with pandas it was over a day too last cycle
<janimo`> or whenever we had pandas built libo
<infinity> Yeah, a dayish sounds about right.
<janimo`> by accident
<janimo`> so I am not holding my breath today for it to complete
<jeremiah> .c
<slangasek> infinity: actually, the test suite failure I was fixing in upstart was unrelated... the one on arm*/ppc is still there, and I'm not sure what to make of it
<infinity> slangasek: Oh, it just happens to be in the same test.  But, you're right, different error.
<slangasek> infinity: yes, the "same", 4kloc test ;)
<infinity> slangasek: Ugh.
<kalikiana> suihkulokki: did you upload updates for libbz2 or gconf2 yet?
<suihkulokki> kalikiana: yes but bzip2 is still building
<pbuckley> this morning's dump of updates seems to have another alsa bug
<pbuckley> ALSA lib conf.c:1220:(parse_def) show is not a compound
<pbuckley> ALSA lib conf.c:1686:(snd_config_load1) _toplevel_:24:26:Unexpected char
<pbuckley> ALSA lib conf.c:3406:(config_file_open) /usr/share/alsa/pulse-alsa.conf may be old or corrupted: consider to remove or fix it
<pbuckley>                 show {
<pbuckley>                         @func refer
<pbuckley>                         name defaults.namehint.basic
<pbuckley>                 }
<slangasek> infinity: ah, I understand jhunt has figured out the race in the test that was causing things to fail, so we should have a fixed package tomorrow-ish
<infinity> slangasek: \o/
<orion___> ALLCON:  I am attempting to setup ubuntu server 11.10 on a Pandaboard es with no luck.  I attempted multiple times with the same pre-installed distro with different outcomes. They range to when the system unpacks and reboots, I either booting and then nothing, booting and then root access.  With root access I try to adduser and get one of two options:  The user is added but not in the sudoers list, or the user is not added and I
<orion___> I gave up for a while and tried installing 12.04 and had no issues at all.  It went straight to the installation screen, gave me all my options, and then worked great.  I just went back to 11.10 since it is supported
<orion___> Is there anyone who may know what is wrong and could help
<GrueMaster> orion___: 11.10 doesn't have full support for the 4460 in u-boot or kernel.
<GrueMaster> It can cause overheating.
<orion___> is there a better option to go with
<GrueMaster> I am testing 12.04 daily.  It is very stable, but since it is in development, constantly updating stuff.
<GrueMaster> You should be fairly safe running Alpha 2, then upgrading during milestones (beta 1, 2, etc).
<orion___> yeah, this is going onto a robot that needs to be mostly stable.  I will only need usb, ethernet, wireless (maybe bluetooth), and the ability to work with the gpio if needed
<GrueMaster> Ah.  Yea, stick with the 12.04 and just turn off auto-updating.
<orion___> How are the service packages with 12.04.  For instance, I tried to download openjdk as a quick test with 12.04 and couldnt find it
<GrueMaster> It is there.  I use it daily to run a Jenkins slave.  I use open-jdk-jre-headless, but I also just tried default-jdk.
<orion___> got it
<orion___> just must have missed it then
<GrueMaster> default-jdk will give you a lot more packages, but only really usefull cor compiling java.
<GrueMaster> /cor/for
<orion___> and would you say that 12.04 server is the fastest build for pandaboard es right now?
<GrueMaster> Yes.  Especially the armhf release.  BTW, we will no longer be making armel images after today.
<pbuckley> orion___: i will voice for 12.04 armhf builds be wicked fast
<orion___> got it.  I would rather hf anyways
<pbuckley> err confirm
<pbuckley> my english this morning is a little off
<orion___> thanks to both of you.  I will go back to 12.04 then
<pbuckley> (though slap a hard drive on the thing.. running off the sd card is pure pain)
<orion___> yeah, that is another area I am noticing
<pbuckley> Linux panda 3.2.0-1406-omap4 #8-Ubuntu SMP PREEMPT Tue Feb 14 16:12:38 UTC 2012 armv7l armv7l armv7l GNU/Linux
<orion___> thinking of getting an ssd
<pbuckley> here is what i did
<pbuckley> LABEL=home /home ext4 defaults,noatime,errors=remount-ro 0 0
<pbuckley> LABEL=usr /usr ext4 defaults,noatime,errors=remount-ro 0 0
<pbuckley> LABEL=var /var ext2 defaults,noatime,errors=remount-ro 0 0
<pbuckley> tmpfs /tmp tmpfs defaults,noexec,nosuid 0 0
<pbuckley> tmpfs /var/log tmpfs defaults,noexec,nosuid 0 0
<pbuckley> tmpfs /var/run tmpfs defaults,noexec,nosuid 0 0
<pbuckley> tmpfs /var/lock tmpfs defaults,noexec,nosuid 0 0
<pbuckley> though ill probably migrate /var/log to the hard drive
<pbuckley> i had it in a ramdisk before i added the hd
<orion___> got it
<pbuckley> GrueMaster: btw it looks like that sound patch made it in the recent kernel build \o/
<orion___> thanks to both of you
<GrueMaster> for your robot usage, SD should be fine.  It really only sucks when you have a lot of io load.
<pbuckley> (by a lot he means more then 2 MB/s
<GrueMaster> pbuckley: Yes, I was told today.  Also fixed the ucm configs last week.
<pbuckley> )
<orion___> the robot will be communicating with the google cloud and with other robots
<pbuckley> indeed.. there is a new alsa bug i mentioned earlier
<pbuckley> but it doesnt break functionality
<GrueMaster> sounds cool.
<pbuckley> just throws a warning
<pbuckley> orion___: sweet.. graduate project?
<orion___> also, may be using opencv, so there is a bit of IO
<GrueMaster> pbuckley: I'll look into it.
<orion___> pbuckley: yes
<pbuckley> reminds me of
<pbuckley> http://www.google.com/url?sa=t&rct=j&q=ryan%20walker%20robot&source=web&cd=1&ved=0CCYQFjAA&url=http%3A%2F%2Fweb.cs.swarthmore.edu%2F~meeden%2Fcs81%2Fs09%2Ffinals%2FRyan.pdf&ei=Eks9T4H4AuTUiALj-dzDAQ&usg=AFQjCNG3THVik7wByH61j67PnDqGDWn2Ww&cad=rja
<orion___> pbuckley: pioneer robots?
<orion___> pbuckley: same ideas.  Going to be multiple ground and air vehicles cooperating togehter
<orion___> *together
<pbuckley> if you want me to hook you up with that author of that paper hes usually interested in talking about robots ;)
<orion___> that's be great, however this wont be my common irc name.  Using webirc now, working on setting up a more permanent version right now
<orion___> strange
<orion__> pbuckley: think i got it setup
<orion__> pbuckley: yeah, looking at the paper, it seems pretty good with the adaptive controls
<GrueMaster> orion__: When you start diving into this on the panda, I recomment you keep a complete copy of your workspace on your desktop that you can just dump into the SD after flashing a new image.  It is much faster to flash a fresh image than it is to update on SD.
<orion__> GrueMaster: do you mean a complete copy of code, etc.  I haven't moved anything to the distro yet.  I am currently getting the board setup first to move code from a chumby hacker board
<GrueMaster> Yes.  What I do with my test projects is store them in a self-contained tarball,  When I run them, I assume a clean image and install the necessary packages, change the environment settings, etc accordingly.
<GrueMaster> Too often someone on here complains that they lose a lot of work when they decide to upgrade and they are on SD.
<GrueMaster> I prefer to think of the SD as a good demo image/embedded project storage that is volatile.
<orion__> I see what you are saying.  I will be working on setting up a cross compiler environment on my laptop soon.  I will then be holding my projects both on the laptop and pandaboard so that shouldnt be a problem
<GrueMaster> Can't wait to see your project on youtube.  :P
<pbuckley> orion__: distcc is also fun
<orion__> me too.  We already have 6 ground vehicles working well.  Working on building 2 quadcopters at the moment, but those won't be done until the beginning of summer
<orion__> Anways, I don't want to tie up the board.  I appreciate both of your help.
<pbuckley> come back soon ;)
<orion__> I'll be hanging out.  Still have to see if this goes smoothly
<pbuckley> :D
<orion__> and the download for 12.04 is going very slow today
<Epsilonorion> pbuckley: This will be my main name if I am on
<pbuckley> alright.. ill let him know.. he's in the zone tippity tapping
<Epsilonorion> GrueMaster: Actually one question.  Should I download the current daily build or the alpha 2 version the channel provides a link for
<GrueMaster> Either or.  The daily-preinstalled has a newer kernel with some fixes, mainly for audio.
<Epsilonorion> ok, then I will stick with that one.  Thanks again
<GrueMaster> Ooo, new shiny.  http://makeplaylive.com/
<GrueMaster> Price and specs are comparable to a Nook Tablet.  More usb ports and a camera as well.
#ubuntu-arm 2012-02-17
<suihkulokki> kalikiana: had time try out current gconf/bzip2 ?
<alexeilevitsky> can i install unbuntu on my tablet?
<alexeilevitsky> guys? is there an apk installer for rooted android devices/
<mephisto1911> maybe this can help you http://androlinux.com/android-ubuntu-development/how-to-install-ubuntu-on-android/
<alexeilevitsky> will ubuntu run on 1ghz and 256 mb ram?
<davidm> alexeilevitsky, speed good RAM very tight, will likely want to swap
<alexeilevitsky> can you dualboot android and ubuntu?
<xranby_ac100> janimo`: did you manage to run libreoffice on armel yesterday?
<xranby_ac100> janimo`: ahh.. i get it.. i ran out of stack on my machine.. i had tweaked ulimit -s to only use 256kb of stack by default
<xranby_ac100> when i increased back to ubuntu default then libreoffice launched.
<xranby_ac100> problem partially solved
<ogra_> xranby_ac100, so it works for you ?
<ogra_> from the archive ?
<ogra_> oh, armel ...
<xranby_ac100> ogra_: yes on armel/precise
<ogra_> nevermind
<ogra_> i thought hf
<xranby_ac100> ogra can you wun the armel verion on armhf using multiarch now?
<xranby_ac100> run
<ogra_> i doubt that, feel free to try though
<xranby_ac100> ogra_: hmm i can try the opposite.. to install some armhf app on top of armel
<Epsilonorion> How do I get minicom within Ubuntu server 12.04.  I do not seep to have the correct package for it
<GrueMaster> Epsilonorion: What are you trying to do?
<Epsilonorion> GrueMaster: I am trying to connect to an XBee through minicom, however I am having no luck.
<GrueMaster> Hmm.  Minicom should be installable.
<xranby_ac100> Epsilonorion: personally im using ser2net for all my serial port projects
<xranby_ac100> easier to open a tcp/ip connection from any programming language and let ser2net handle all the serial io
<xranby_ac100> you can then telnet to your serial port if you like
<Epsilonorion> Scratch the minicom issue.  I found another reason why it wasnt working and got it working.  As for ser2net, I haven't tried that one yet.  I already have code that worked on a previous board for XBees, but didn't seem to be working right now.  I planned on using minicom just to make sure I could talk to the XBee
<GrueMaster> TheMuso: I finally have new images for omap4 with the latest alsa stuff and with the kernel patches.  Now seeing an issue when using alsaucm to configure a PandaES.  See http://paste.ubuntu.com/846505.
#ubuntu-arm 2012-02-18
<parin> anyone using qt with sqlite database on pandabaord?
<parin> i am not able to open tha sqlite database
<parin> do i need to configure driver in qt?
<parin> if yes how can i do that?
<ATP> hello everyone, anyone know if lucid 10.04 can recognize touchscreen?
<ATP> i put my usb touchscreen on my beagle and it also gets power but nothing shows up
<ATP> it's supposed to be plug n play....
<xranby_ac100> ATP: touch screens usually gets connected to the system like any input device
<ATP> yeah i know but if i try to pipe any input device to hexdump doesnt give me anything
<ATP> i tried this: sudo cat /dev/input/event0
<ATP> i tried this: sudo cat /dev/input/event0 | hexdump
<ATP> so i got no input either output (screen is black)
<ATP> so what am i supposed to do now? switch to a newer ubuntu?
<ATP> hi again! which 12.04 image do I download for my beagle? just OMAP 3 or with HF?
<Dioxin> hardfloat is generally the better option to go for as it refers to using the hardware implementation of Float
<Dioxin> BUT not everything has been moved over, so the softfloat might be more complete
<ATP> ok thanks for that
<ATP> do I also download the zsync file?
<ATP> what does that do?
<xranby_ac100> ATP: the zsync file are used by some download tools to update an old version to the new version by only download a binary diff
<ATP> a cheers man then I guess i dont need it
<ATP> i will just go for the simple stuff :P
<xranby_ac100> APT: http://zsync.moria.org.uk/
<ATP> ye i saw that, i wont be using it but thanks anyway ^^
<xranby_ac100> ok , did you solve your touch screen issue?
<ATP> well not really yet, im downloading 11.04 image now to check  (when i tried 11.10 and 12.04 i had problems with screen flickering in my main screen)
<xranby_ac100> ATP: screen on hdmi?
<ATP> yes how do u know
<ATP> and it's rolling up and down
<xranby_ac100> you said you had a beagle board.. i guessed
<ATP> i can see ubuntu running but its rolling and hurts my eyes
<ATP> oh ok i thought it was a known bug or something...
<xranby_ac100> do you have more than one monitor to test on?
<xranby_ac100> its a digital signal
<ATP> unfortunately not :(
<ATP> u think it might be the monitor?
<xranby_ac100> i font know
<xranby_ac100> do not know
<ATP> i will check on my neighbor's monitor
<xranby_ac100> ATP: most likely your monitor supports say only interlaced  480i resolution and the beagle sends a 480p resolution..
<ATP> mmmm might be it
<xranby_ac100> same thing for higher resolutions
<xranby_ac100> ATP: you can use a hdmi to dvi adapter and connect the beagle to a dvi monitor
<ATP> xranby_ac100 yes good idea I just have to find a monitor to test
#ubuntu-arm 2012-02-19
<micahg> \o/ chromium built on armel, I'll rebuilt for armhf later this weekend
<micahg> *build
<scientes> what package has the dgb symbols for ld-linux ?
<scientes> E: Unable to locate package binutils-dbg
<scientes> got it nvm
<TheMuso> GrueMaster: I assume this has been going on since the last alsa-utils upload?
<pnphi> joined
<pnphi> please help me ! ! !
<xranby_ac100> pnphi: ask your question directly
<pnphi> i create the image ...but from the step "Setting up xulrunner-1.9.2 (1.9.2.27+build1+nobinonly-0ubuntu0.10.04.1) ...", the process stop ...
<xranby_ac100> pnphi: which arm board are you using and which image
<xranby_ac100> ?
<pnphi> project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 10G --seed ubuntu-desktop,gdm --notarball
<pnphi> i create the image ...but from the step "Setting up xulrunner-1.9.2 (1.9.2.27+build1+nobinonly-0ubuntu0.10.04.1) ...", the process stop ...
<pnphi> E: Sub-process /usr/sbin/dpkg-preconfigure --apt || true returned an error code (100) E: Second stage build in chroot failed ! E: Please see the log to see what went wrong. I: Cleaning up... E: Failure running script /usr/sbin/dpkg-preconfigure --apt || true I: Umounting temporary Image
<pnphi> what errors ?
<scientes> how do i load a program while using libc6-dbg ?
<scientes> I am fallowing this guide: http://lists.linaro.org/pipermail/linaro-dev/2011-January/002022.html how do i use debugging packages?
<xranby_ac100> pnphi: a lot of things can go wrong when you roll your own image,  the xulrunner package got updated recently https://launchpad.net/ubuntu/+source/xulrunner-1.9.2/1.9.2.27+build1+nobinonly-0ubuntu0.10.04.1
<scientes> like libc6-dbg
<scientes> which install to /usr/lib/debug
<scientes> i tried using   LD_LIBRARY_PATH=/usr/lib/debug  or prefixing with the true path of the debug linker and that didn't work
<pnphi> ok thanks and what errors ?
<xranby_ac100> scientes: when you have the debug symbols in place  then debuggers like gdb can give a better backtrace by simply having the debug symbols in that folder
<pnphi> E: Sub-process /usr/sbin/dpkg-preconfigure --apt || true returned an error code (100) E: Second stage build in chroot failed ! E: Please see the log to see what went wrong. I: Cleaning up... E: Failure running script /usr/sbin/dpkg-preconfigure --apt || true I: Umounting temporary Image
<xranby_ac100> pnphi: start by filing a bug against that package
<scientes> xranby, I cant run from gdb cause qemu does not implament ptrace
<scientes> I have to use from gbd target remote localhost:port
<xranby_ac100> and someone who are more familiar with xulrunner can probably locate what went wrong during the dpkg-preconfigure apt step
<xranby_ac100> scientes: do you have any debugger you can use? the binarys on your system know internally that the debug files are put into the /usr/lib/debug path
<scientes>     qemu-arm-static -g 1234 /bin/ls
<scientes> I am using these instructions: http://lists.linaro.org/pipermail/linaro-dev/2011-January/002022.html
<scientes> and i've installed the relevent dbg packages (i believe)
<scientes> for gtk, wxwidgets, and libc6 (probably don't need, but couldn't figure out why i wasn't getting a backtrace)
<scientes> and my main executable is also not stripped
<scientes> ahhh -L to qemu-arm-static
<scientes> hmm, still seeing ??
<ATP> hello everyone, does anyone know how to install a usb touchscreen for ubuntu arm?
<scientes> ATP, you plug it in
<ATP> yes I did so
<scientes> and use xserver-xorg-input-evdev (standard stuff)
<scientes> what model is it?
<ATP> i installed that too
<scientes> see is lsmod gives you the "usbtouchscreen" driver loaded
<ATP> it's LVDS 10" from chalk - elec
<scientes> thats the monitors stuff, not the touchscreen stuff
<ATP> no it's not there the usbtouchscreen
<scientes> I have a mimo 720 and i had to patch the touchscreen driver, because when i plugged it in it was rotated 180 deg
<ATP> i do have usbhid though
<ATP> mine doesnt even display anything
<pnphi> The command " project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 5G --seed xubuntu-desktop --notarball" is right ? ?
<scientes> well, to be honest I havn't gotten mine to work in my x86 box
<scientes> but the kernel stuff works and loads, its a X prob
<ATP> :(
<scientes> X doesn't autoconfigure usb stuff
<ATP> so what do?
<scientes> works fine on my arm box
<scientes> write a proper xorg.conf
<ATP> when i try to Xorg -configure I get error
<scientes> do you get a /dev/fb0 ?
<ATP> "segmentation fault"
<scientes> ATP, as i said, it doesn't do it automatically
<scientes> (i've tried the same stuff)
<scientes> when you figure out how to dual monitor it I would like to know
<ATP> hehe nice to see someone was at my situation
<scientes> but yeah, I'm pretty sure it takes a proper x.org
<scientes> but I HAVE gotten mine to work on a headless arm box
<ATP> so do i make an xorg from scratch?
<ATP> xorg.conf*
<scientes> however as I said my touchscreen was 180 deg rotated and I had to patch the kernel driver
<scientes> ATP, please figure it out so I can use yours-- google arch displaylink
<ATP> hehe will do
<ATP> if only i can make an xorg.conf
<ATP> that works
<scientes> but you say this is LVDS, that is totally diffn't than my usb monitor (usb framebuffer too)
<scientes> so it might be a differn't problem
<ATP> should I get a sample one, or create a new one with Xorg -configure?
<scientes> do you have a /dev/fb0 ?
<pnphi> excuse me ....
<pnphi> project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 5G --seed xubuntu-desktop --notarball
<pnphi> is right ?
<ATP> how do i see this
<scientes> if you do ATP that means kernel stuff is probably working
<ATP> yes i do have fb0
<ATP> so what do i do now?
<scientes> Xorg -configure doesn't work, as it is the same thing as the automatic stuff
<scientes> so read up on it so i don't have to pls :)---oh wait, is that /dev/fb0 your main monitor or the touchscreen?
<scientes> see if you have TWO fb0, fb1
<scientes> check dmesg
<ATP> i have 3
<ATP> sec
<scientes> oh geeze
<scientes> figure out what is what
<ATP> i can see fb0 fb1 and fb2
<ATP> ok checking now
<ATP> couldnt find which is which
<scientes> dmesg | grep fb
<scientes> unplug it and the plug it in---oh wait it is LVDS
<scientes> cat /var/log/kmsg* | grep /dev/fb
<scientes> *kern.log
<ATP> nothing
<scientes> with cat /var/log/kern.log*
<scientes> ?
<ATP> yes
<ATP> i tried both
<ATP> nothing comes up
<scientes> well then do with /var/log/dmesg
<ATP> nothing again
<scientes> hmmm
<ATP> i only have one fbcvt which says 1280x720@60
<ATP> i check lsusb now
<ATP> meh it wont show there :( so maybe hardware issue :(((
#ubuntu-arm 2013-02-11
<infinity> mdz: Glad we could help. :P
<infinity> mdz: (Not that I'd recommend clang on armhf over gcc)
<mdz> infinity, was building forked-daapd, it seems to default to clang
<infinity> Oh, it may be one of the few that relies on clang's extensions to C.
<infinity> Because when you're tying to write a standards-compliant compiler than can be a drop-in replacement for $CC, the first thing you should do is add incompatible extensions.
<chadbyoung> can someone point me to the channel logs?
<dholbach> good morning
<spyzer> hey everyone, i am facing this issue that my ubuntu 12.04 pandaboard installation reports pvr_dri.so not found
<spyzer> in Xorg.log
<ogra_> did you install the pvr driver ?
<ogra_> in 12.04 it wasnt included by default, it is in 12.10 though
<ogra_> (and its broken in 13.04 currently i think)
<spyzer> ogra_, yes i did apt-get install pvr-omap4
<spyzer> but it doesn't show the file which Xorg is looking for in that directory
<ogra_> ?
<ogra_> which file in what directory ?
<spyzer> ohh sorry my Xorg logs says that it is unable to find /usr/lib/arm-linux-gnueabihf/dri/pvr_dri.so
<ogra_> then the compile failed i guess
<spyzer> no it compiled and is syas build done
<spyzer> everything was successfully installed
<infinity> Potentially not for your running kernel, mind you, if you've upgraded kernels but not rebooted since.
<ogra_> hrw, you dont happen to have a similar hack like the flash one for the hangouts plugin, do you ?
<hrw> ogra_: nope
<ogra_> sad
<hrw> ogra_: flash hack was not mine
<ogra_> flash works so nicely .... i had some hope :)
<ogra_> i know, i saw the bug
<hrw> ogra_: does 720p videos work for you on YT?
<hrw> ogra_: care to create package for flash?
<ogra_> hrw, how should i package that ? its not licensed, it would require to chnage a conffile of another package etc
<hrw> ah, right - forgot that this part is not yet in any tarball on their archive
<hrw> http://commondatastorage.googleapis.com/chromeos-localmirror lists all available sources
<ogra_> This XML file does not appear to have any style information associated with it. The document tree is shown below.
<ogra_> pfft
<ogra_> google fix your pages !
<hrw> all: Nine years ago I bought Sharp Zaurus SL-5500 as my first Linux PDA. And due to this I am where I am.
<hrw> http://marcin.juszkiewicz.com.pl/2013/02/11/nine-years-of-embedded-linux/
<spyzer> hey everyone, is there some command which can tell me what packages are avilable from a particular software source
<hrw> spyzer: apt-cache policy package?
<hrw> or: cd /var/lib/apt/lists/;grep ^Package *Packages|sort
<xnox> hrw: there is dctrl-grep you know ;-)
<hrw> xnox: really?
<hrw> cool
<hrw> there are so many tools nowadays...
<xnox> yeah it does the control file syntax greping across available, installed, packages, etc...... it's quite cool.
<hrw> I remember friend telling me that there are some apps other than mplayer for playing videos - but I do not know can I believe him in it ;D
<jibel> ogra_, hey, I found a very useful tool called pagemap-tool to track memory usage, it provides a more details on memory usage than smem
<ogra_> nice
<ogra_> lool, ^^^^
<jibel> ogra_, I pushed a version that compiles on raring to  lp:~jibel/+junk/pagemap-tools and sample data for the nexus 7 here http://people.canonical.com/~j-lallement/N7/memusage/pagemap/
<ogra_> you should sooo blog about that :)
<jibel> :)
<janimo> ogra_, is X supposed to start in landscape in the Nexus by default
<janimo> ?
<janimo> I thought portrait was default and we had to configure otherwise
<raster> janimo:  yes
<raster> sucky :(
<raster> i reconfigured it to be protrait again
<raster> and the vsync disturbes me
<raster> tearing
<raster> :(
<janimo> raster, we try to orient according to device position, but I thought it was portrait by default for some reason
<janimo> at least the fbdev is
<ogra_> janimo, portrait is default since a while
<janimo> ogra_, I wonder why mine starts in landscape then :)
<ogra_> from an xrandr perspective portrait is "normal"
 * janimo goes debug gsd further
<ogra_> landscape is "right"
<raster> ogra_:  since wehn? my image is from like last year
<raster> i havent updated :)
<raster> i "fixed it"
<ogra_> raster, some time in januar iirc
<raster> aah ok
<raster> so after my install
<raster> :)
<raster> oh
<raster> and xorg has a nasty nast nasty bug
<raster> its deep down in the xinput/evdev subsytstem somewhere methinks
<ogra_> yep
<ogra_> known
<raster> if u do just the right things with mouse grabs
<raster> xallowevents() becomes broken indefinitely
<raster> thus basically a wm doing click to focus stops all mouse press events going to clients
<raster> until u restart x
<ogra_> bug 1068994
<ubot2> Launchpad bug 1068994 in ubuntu-nexus7 "button1 gets stuck after a while" [Critical,Confirmed] https://launchpad.net/bugs/1068994
<raster> i've created a reproduction test case
<ogra_> oh, please attach that case to the bug then
<raster> it doesnt trigger it
<raster> u can trigger ti 100% reliably with e17
<ogra_> its our biggest blocker and seems upstream doesnt really do any work on it
<raster> and my test case was to rpove that aftrer its been triggered the bug affects any x client that does a passive grab + allow events
<raster> so run wm\
<raster> trigger it
<raster> kill wm
<raster> then launch test client
<raster> see that it also cant pass events
<raster> hmm
<raster> i havent got a "Trigger" code yet
<janimo> raster, seems you are furthers ahead in debugging that issue :)
<raster> basically... i can give you a whole toolkit+wm to trigger it
<janimo> furthest
<raster> but i think thats a bit much :)
<janimo> raster, I think this is a clever scheme to get us buying into E17
<raster> basically i know u do work your on unity and i dont want to straddle u with al of that junk
<ogra_> well, it happens under unity as well
<raster> hehehe
<raster> well e17 reiably triggers it in its illume mode
<janimo> ogra_, didn;t we at some point reproduce with lubuntu, only took more time?
<raster> what can i give u to help?
<raster> i know best thing is a "simple x client to repro and prove"
<ogra_> janimo, i havent seen it in lubuntu at all
<raster> e17 is instant
<raster> just press the "menu" butotn on its top indicator bar
<raster> presto
<raster> broken
<raster> 100% reliable for me
<janimo> raster, if you suspect various parts of Xorg being at fault that would be a useful pointer too
<ogra_> but tjallton said it wouldnt be desktop specific, just thaat compiz triggers it more easily
<raster> its not desktop specific for sure
<janimo> I know upstream did some patches in the dark based on our symptoms, but some hints as to where you think the bug is may help them
<raster> if it were then it would go away afgter i killed the wm off
<raster> but my test client proved that wrong
<raster> i spent a lot of time debugging e17 and efl trying to find out what was up
<raster> and narrowed it down this far
<raster> hmm
<raster> i'll try make a test client that also triggers it
<ogra_> well, having allyour findings on the bug will surely help
<janimo> raster, that would be great
<raster> if i can get u a simple xlib based test client that alwasy triggers it
<raster> then debugging for upsteram should be fast
<raster> i know thats what i'd wanty
<janimo> indeed
<raster> thus why i will hesitate to file anyhing more until i have that :)
<raster> i just dont want to annoy ppl :)
<janimo> raster, it would be an annoyance with much higher signal/noise rate though that our usual comments on this bug, so feel free too :)
<raster> hehe
<raster> ok :)
<raster> will do right now
<raster> let me just double-check
<raster> there we go
<raster> triggered
<raster> oh so easy
<janimo> ogra_, uptodate raring and X still starts in landscape (kernel console and plymouth splash are portrait)
<raster> oh btw
<raster> this issue also happens on my exopc
<raster> so its not arm/n7 specific.
<raster> :)
<ogra_> janimo, well, trhat started with your recent changes to acceld and g-s-d
<ogra_> raster, yeah, see the last comment on the bug
<janimo> ogra_, ok so not just my setup then, good to know :)
<janimo> I thought you had portrait by default with fresh raring
<raster> aaah just saw :)
<ogra_> janimo, nobody looked into it yet, the behavior is the same as with acceld in the wrong setup thouogh
<ogra_> janimo, we do
<raster> i should read them.. shouldnt i? :)
<infinity> raster: Reading is wildly overrated.
<raster> yeah
<raster> so i have learned from my users
<raster> :)
<infinity> It's nice to be on the other end of it, isn't it?
<infinity> I sometimes get giddy about filing upstream bugs for that very reason.
<infinity> "Ooo, ooo, I get to be the annoying twit this time, yay!"
<raster> infinity: hehehe
<raster> https://bugs.launchpad.net/ubuntu-nexus7/+bug/1068994/comments/24
<ubot2> Ubuntu bug 1068994 in ubuntu-nexus7 "button1 gets stuck after a while" [Critical,Confirmed]
<raster> there u go
<raster> info
<raster> with "demo that its xallowevents() that is busted"
<raster> ie thats what is actualyl stuck
<raster> actually
<raster> there
<raster> i even read prevbious comments
<raster> :)
<ogra_> i poointed #ubuntu-x to it
<ogra_> lets see
<raster> i wish i had the peferct "just run this small xlib app and presto.. insta-bug"
<raster> thats what they really want
<raster> :)
<raster> dont have it tho
<raster> so sorry :(
<raster> i have "half of it"
<raster> with the other half being all of e17 and a nice little pop up a menu button to get the bug into gear and its pants on and dirty
<raster> :)
<ogra_> but you identified the broken function
<ogra_> that should give some hints
<raster> that bit wasnt that hard
<raster> some xev fun ande i figured out my buttonpress was gone
<raster> WHY was what i was digging into
<raster> :)
<raster> and guessing it was xallowevents was obvious at that point
<raster> but why was eluding me
<ogra_> sure, but you dug deeper than the others already
<raster> i was tyring to disable the xi/xi2/xi2.2 support in efl to see if it was a combo of selecting for xi2.2 touch events and also mouse events
<raster> or if it was some other stupid bug that had crept into efl somewhere
<ogra_> oh, you should note that too, our xorg guys always point to that
<raster> was xallowevents even being called at alll as it should be? (it worked on desktops and other places so it SHOULD be...)
<ogra_> (xi vs xi2 etc)
<raster> it didnt make any difference
<raster> dont actually have any xi support
<raster> just xi2 and 2.2
<ogra_> yeah, i thought so
<raster> but iw as turing that off and hunting thru it to try find out more info
<raster> thus my time sank into that
<ogra_> funnily if it happens for me, i can still use the onscreen kbd to switch apps
<raster> then trying to figure out the "action" that triggered it
<raster> that was pure luck
<raster> :)
<ogra_> and inside these apps touches are recognized
<raster> probably because the kbd isnt a regualr window with click to focus handling on it
<ogra_> for me only all compiz elements die but not the apps themselves
<raster> well either its not regulr
<raster> not managed by the wm
<raster> or wm is not handling click interception on it as it asks not otbe focused
<raster> not sure
<ogra_> it is on top and steals the focus, yeah
<raster> didnt look :)
<raster> e17 has its own vkbd anyway
<raster> which is less annoying (doenst go float on top of apps)
<raster> also the mem footprint of onboard is just silly-pants
<raster> it soaks up like 20-30mb
<ogra_> onboard uses struts now too
<raster> for what.. i know not
<ogra_> and the footprint is similar to maliit (just tried that on the weekend)
<raster> e17's vkbd works more like u'd findin ios/android
<raster> where it slides in
<raster> and resizes the app window to not overlap
<ogra_> right, onboard does the same now
<raster> :(unless the app specifcialyl advertises it supports the overlap protocol stuff)
<raster> aaah thats changed
<raster> :)
<ogra_> yeap
<ogra_> but it still eats 15-20M of your RAM
<ogra_> maliit is closely the same though
<ogra_> probably 1M less or so
<raster> weird
<raster> why so much?
<ogra_> no idea, i only tested it from an enduser POV
<ogra_> didnt dig into code
 * raster shrugs
<raster> oh well
<ogra_> it is a tad faster than onboard ... butu also only has half the amount of keys
<raster> i need to work on our "better touch ui"
<raster> time our touch ui got some love
<raster> ehhee
<raster> starting on board is like watching continental drift
<raster> it takes like.. 5-10 sec or so?
<raster> or thats what i experienced
<ogra_> that should have improved too
<raster> well thats like saying "it should now taste better than drinking badger pee"
<raster> not too hard to get better
<raster> :)
<ogra_> yeah
<ogra_> its still python and still slow
<ogra_> which means you notice every improvement :)
<raster> hehehe
<janimo> ogra_, we had someone commenting often on onboard bugs, giving me the impression he may be upstream or close to it
<janimo> they may know why it takes up so much memory
<janimo> being python is not a good enough excuse for 30M (what I see here)
<ogra_> wow
<ogra_> what do you look at ?
<ogra_> RES should be around 15
<janimo> I'll have a nother look, but that is what I recall from a few days ago
<ogra_> varying between 15 and 20 usually for me
<raster> janimo: i find "its python" to be an excellent excuse for almost anything wrong with a python app. i use that line regularly :)
 * raster is biased
<ogra_> janimo, but yeah, upstream is very busy trying to fix our bugs
<ogra_> its a shame that we will likely switch
<raster> arent u just going to make your own display system?
<raster> :)
<raster> why bother fixing the xorg bugs then ? :)
<ogra_> roumors ... pfft
<raster> well tbh
<raster> u are going ot be in for a hard time with ubuntu phone
<raster> as it has to piggyback off nadroid to work
<ogra_> nah, it will all be fun and unicorns
<ogra_> *bellive* me
<raster> unless u insist soc vendors provide non-android drivers
<ogra_> :)
<raster> eg dri/drm/xorg stuff
<raster> for e3xample
<raster> :)
<raster> wanting THAT will be all fun and unicorns :)
<ogra_> heh
<raster> very few soc vendors will play ball with that
<raster> and gpu vendors
<raster> etc.
<raster> unless u are big big big
<raster> and then u generally just get the "well hers the src.. you go do it"
<raster> :)
<ogra_> we'll see what happens once it is released
<raster> sure
 * ogra_ explicitly stays away from the phone stuff ... i like the surprise of what i have to get in the archive :)
<raster> hahahaha
<lool> jibel, ogra_: Yup; I've read jibel's G+ post on it, couldn't make sense of the raw data from my G+ client though
<raster> fair enuf
<lool> jibel: Looking after files which are only used by a handful of processes is definitely the way to go, I didn't have an easy way to do this with smem short of looking at USS
<infinity> raster: Being given the source to JFDI would be just fine.
<infinity> raster: What I wouldn't give to be able to actually fix bugs in all these blobs.
<raster> infinity: its kind of a poison pil tho
<raster> u oftne get ut.. with nice fat legal restrictions on who can see it etc.
<raster> :)
<infinity> raster: Sure, and it's very not ideal, but not much I can do about it. :/
<raster> i keep my hands off closed src driver internals to make sure i dont get "Tainted"
<raster> like legally
<raster> so if i figure out some behavior
<raster> algorithm oir whastevr - i've done it above bosard from the outside
<infinity> raster: I don't generally work on the same parts of the stack they touch, so taint wouldn't be an issue for me.
<raster> luckily i have "other guys" who get to poke at the internalsd
<raster> i regularly have debates about whose bug it is
<infinity> If something leaked from an nvidia GL driver into my glibc work, the world would be rather topsy-turvy.
<raster> i tend to win most of them and get the drivers fixed :)
<raster> hahyahaha
<raster> true
<raster> actually spekaing of that
<raster> i was looking around ont he weekend
<raster> is there any options/cointrols to enable gpu dithering for tne n7/tegra3?
<raster> i googled around and found some patches for chromebooks
<raster> in the android driver layer
<raster> but nothing else
<infinity> Yeah, no idea.  ogra_ ^
<raster> the n7 has some nasty 18bpp banding :(
<infinity> I've so far managed to stay very far away from that stuff.
<infinity> So far.
<raster> it disturbs me and makes small children cry
<raster> :)
<infinity> Yeah, small children hate banding.
<raster> they do
<infinity> (Have you ever looked at a banded sunset and thought that reality could do with better gradient dithering?)
<raster> yes
<raster> i then curse the clouds at them distrubing my smooth sunset gradient
<raster> and go gimp up some unbanded  sunsets to disdplay on my screen
<infinity> Always takes me back to that great satire article about god choosing the Unreal engine over the Q3 engine for Reality 2.0, and the fake quote from Carmack, "you'd think reality could benefit from curved surfaces".
<raster> hahaha
<ogra_> raster, i dont think there are any options for the tegra xserver beyond some basics (ARGBHWCursor etc)
<raster> yeah
<raster> i found those
<raster> but not much else
<ogra_> /usr/share/X11/xorg.conf.d/61-tegra-gpu.conf
<raster> bugger :(
<raster> yeah
<raster> read that
<raster> found some others around
<ogra_> thats the xorg.conf coming with the tarball
<raster> not much more tho
<ogra_> yup
<raster> rang strings on the tegra xorg driver
<raster> didnt spot anything about dithering
<raster> :)
<raster> boo
<raster> comne on nvidia homies
<raster> give us vsync buffer swaps and dither controls pls :)
<raster> small children are crying here!
<ogra_> they might be there, just not easily found or documented
<raster> banded images and tearing just makes them all so sad
<raster> :(
<ogra_> i think the cursor setting could help a littel here
<raster> well it'd get rid of a flickery cursor
<raster> :)
<raster> tho tbh.. i want to get rid of it in the end anyway
<raster> well for touch stuff
<raster> easy enuf
<ogra_> i think it is supposed to also help marginally with some of the tearing
<raster> tho even if blank/empty./. it'll cause xorg overhead in redrawing an empty box
<ogra_> even if the cursor isnt shown
<ogra_> (there was a bug i cant find atm where an nvidia guy said that)
<raster> hmm
<raster> so a sw cursor forces drawing to not be vsynced?
<ogra_> dunno
<ogra_> i would have to find that bug again
<raster> hmm
<raster> interesting
<ogra_> hand there is also ttps://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra3/+bug/1088372
<raster> hmm
<raster> turning on argb cursors leaves me with a blank screen
<raster> maybe an old xorg/driver?
<raster> as for that bug
<raster> i noticed this first thing i stuck ubuntu onto my n7 last year
<raster> same problem with evas and e17
<raster> aslo asl for swapinterval of 1
<raster> and get tearing
<ogra_> and bug 1080789
<ubot2> Launchpad bug 1080789 in ubuntu-nexus7 "Corruption around mouse cursor when dragged, particularly around Dash, Indicators, window chrome" [Low,Confirmed] https://launchpad.net/bugs/1080789
<ogra_> https://bugs.launchpad.net/ubuntu-nexus7 helps :)
<raster> happens in portrait too
<raster> nb
<raster> it may not be a page flip thing
<raster> depending on gpu/gfx chip setup
<raster> u can sweap buffers part way thru acan
<raster> anr it flips instantly
<raster> depending on gfx subsytstem setup u may have to vsync your buffer swaps too
<raster> but its also slow/sluggish imho
<raster> whihc is hinting at it being sa blit
<raster> it should be much after if it were a swap
<raster> :)
<raster> unless this tegra3 is really that bad...
<janimo> xnox, gsettings set org.gnome.settings-daemon.peripherals.touchscreen orientation-lock true seems to be already there for preventing rotation
<janimo> just does not seem to be exposed in a GUI
<xnox> janimo: nice. as long as it works. I can include that.
<janimo> xnox, works in my tests
<janimo> include where? you needed it in the installer?
<xnox> janimo: yeah. cause when oem-config rotates it can become off-screen.
<janimo> xnox, the only issue I saw with it, is that when set, we don't get proper input coordinates on X startup as the whole rotation/adjustment thing is skipped
<janimo> I need to let my nexus get charged more than 3%. As it is it keeps resetting when doing a debuild. Weird
<fly[ac100]> hi
<fly[ac100]> guys, have you any ideas about artefacts like this: http://i.imgur.com/tpOdrtg.png
<fly[ac100]> it appears only in chromium and xcb-driven apps
<ogra_> cairo ... as i said before
<fly[ac100]> gtk apps works fine))
<fly[ac100]> yeah, may be
<fly[ac100]> but what could I do with it?
<ogra_> try downgrading it and see if it fixes the xcb stuff
<infinity> Print it out and turn it into a stylish hat?
<fly[ac100]> :D
<ogra_> or try compiling a new chromium version and see if it fixes it
<fly[ac100]> is cairo related to xcb?
<fly[ac100]> i mean i use i3 and urxvt
<fly[ac100]> and avaik this apps dont use any cairo)
<fly[ac100]> afaik*
<infinity> cario has many backends, XCB being one of them.
<fly[ac100]> so may be problem related to xorg pixmaps engine or kind of
<qengho> Speaking of compiling chromium, I'm having some trouble.  I compile, link, and run, SEGV before main() is entered, it seems.
<ogra_> if you use aliased fonts in your teminal, cairo is most likely involved somehow
<fly[ac100]> hm
<qengho> My simple helloworld.c runs fine.
<fly[ac100]> yeah, I do
<fly[ac100]> but
<ogra_> qengho, is that with your NEON detection or without ?
<fly[ac100]> dont lxterminal use the same cairo too?
<qengho> ogra_: detection off.
<ogra_> hmm
<ogra_> fly[ac100], just downgrade and see if its cairo :)
<infinity> qengho: Can you get a remotely useful backtrace out of it, or is it just a bunch of useless corrupted frames?
<ogra_> likely quicker than guessing from app to app
<fly[ac100]> downgrade its not so easy in archlinux))
<qengho> no neon. ABI hard float. fpu = vfpv3-d16.
<infinity> If only this was #archlinux-arm
<infinity> qengho: No neon may or may not actually work correctly.  It's an ongoing battle with upstream.
<qengho> infinity: not even a bunch.  _start(), __libc_start_main __libc_csu_init, CRASH.
<infinity> qengho: Oh, I should have done a /whois first, this makes more sense now. :P
<qengho> I need to test in another environment.
<qengho> Just never seen it before.
<infinity> qengho: Crashing in csu_init certainly points at some sort of miscompilation or wrong target.
<infinity> qengho: Given that csu_init is preeeetty simple, and about the only way to segfault it would be to throw it some wildly out-of-range arguments.
<ogra_> did you compile an x86 version with vfpv3-d16 ?
<ogra_> :)
<qengho> infinity: it's in the next (anonymous) frame, not there.
<xnox> janimo: I am using nexus image and that gsetting doesn't do anything for me.
<xnox> (just fully upgraded) or is that not in ubuntu archive yet?
<infinity> qengho: I assume you're running this on real hardware, not emulation?
<ogra_> xnox, because acceld still runs in the user session
<ogra_> try killing it and see if g-s-d takes over then (it doesnt for me)
<qengho> infinity: yes. real. No crosscompile.  12.04 on Chromebook.
<infinity> qengho: Try a build without turning off neon and see if that "fixes" it?
<infinity> qengho: To narrow it down.
<qengho> infinity: right. There's a can of worms. I'll look.
<infinity> I'm so very, very close to just writing an email to devel-announce/release announcing that we just don't give a hoot about non-neon systems anymore.
<infinity> Excepy hallyn will murder me, after I just mailed him my ac100.
<infinity> s/Excepy/Except/
<ogra_> infinity, i would go with that too ... but #ac100 would hate us all
<ogra_> i guess 14.04 is the time to switch
<infinity> ogra_: Yeah.  If only we'd never done anything with ac100s, we could have baselined on v7+neon and been done with it.
<ogra_> and doves
<ogra_> the doves were actually the business case keeping us from it ... not the ac100
<infinity> ogra_: I'd prefer to switch before 14.04, TBH, but this is all a nightmare for the security team if they have to keep maintaining neon-disabling patches for old releases.
<ogra_> they just make us keep it now
<infinity> ogra_: Yeah, the doves were the reason way back when, but not for 12.04.
<ogra_> right
<infinity> ogra_: 12.04, there was no business case, just the community case.
<ogra_> yup
<infinity> I'm still tempted to just, at some point, say "screw it, users of 12.04 on ac100 can't have nice things", and let the security team stop faffing with neon-removal.
<infinity> It's not like we "support" ac100 in any way.
<ogra_> oh, sigh ... so OMAP will become a blackberry thing it seems
<ogra_> there goes the linux support
<infinity> Hrm?
<ogra_> BB hired most of the laid off TI OMAP people
<infinity> The Z10 is an OMAP?
<infinity> Oh.
<ogra_> and the new HW will be all OMAP it seems
<ogra_> ... and QNX :(
<infinity> Maybe some of them will do Linux support in their spare time.
<infinity> Including for the BB hardware, which looks shiny.
<ogra_> sure, still a shame
<infinity> (And pigs may fly)
 * ogra_ finds his nexus4 more shiny than the BB
<infinity> Not that I have anything against QNX, but there's a little part of me that wants to buy a Z10 and jam Android/Ubuntu on it.
<infinity> I like the look of the Z10, I dunno.
<ogra_> pfft
<infinity> The N4 is a little too round for me.
<infinity> LG's sister phone to the N4 is more my style.  But, not a Nexus, so less appealing on the software side.
<ogra_> yeah
<ogra_> well, does it have the rounded touchscreen edges ?
<ogra_> these are really awesome
<infinity> http://shop.windmobile.ca/ProductCatalog/Handsets/default.aspx <-- Good visual comparison, N4 on top, O4X on the bottom.
<ogra_> you can scroll without having your thumb cover any content
<infinity> The O4X is just a little more square and utilitarian, and I like that.
<ogra_> yeah, i know what you mean, i stayed on my S2 because of the ugly shape the S3 has
<xnox> ogra_: so i set acceld to manual (echo manual | sudo tee /etc/init/acceld.override), then boot, then change gsetting, then sudo start acceld and then it respects gsettings value (rotates when lock is false, and doesn't rotate when lock is true)
<ogra_> xnox, no, no !
<ogra_> xnox, you need the upstart job, but dont want the Xsession.d snippet
<infinity> I just wish they'd stop with the value-add fragmentation nonsense. :/
<ogra_> ++
<infinity> If the O4X was also a pure AOSP build, I'd run out and buy one this afternoon.
<ogra_> heh
<infinity> Maybe the way Nexus devices sell like hotcakes might be a wakeup call to these vendors.
<infinity> Maybe that's actually been Google's plan.  Kill fragmentation by proving it's useless.
<ogra_> yeah
<ogra_> and the nexus devices are just great HW ... cant complain about the features
<infinity> Sure, but so are the O4X, SGSIII, etc.
<infinity> In fact, on paper, I'd rather have the O4X too.
<infinity> But, again.  Stupid custom build that will never have updates.
<ogra_> but the non nexus devices cost twice the price
<infinity> At least, if the update history of my current LG phone is anything to go by.
<infinity> ogra_: Nah, check that link.  Almost identical prices.
<janimo> xnox, while I have an upload in the queue, that setting should work without it actually
<ogra_> oh, right "As low as $0 "
<ogra_> cant beat that with a nexus :P
<infinity> ogra_: Oh, wait.  That would be my carrier adding a premium to the N4.  I can get it cheaper from Google Play.
<ogra_> yeah
<infinity> ogra_: (Was looking at the 549 vs 529)
<ogra_> yup
<infinity> But yeah, it's 359 from Google.
<ogra_> or 300 if you take the smaller one
<ogra_> or so
<infinity> No SD slot, don't want the small one.
<infinity> (Another selling feature of the O4X, it has SD)
<xnox> ogra_: janimo: so are we removing the snipped from Xsession.d soon =) ?
<ogra_> xnox, dunno, i was waiting for janimo to finish the transition
<xnox> ah , ok.
<xnox> i'll use just the gsetting then.
<ogra_> Xsession.d should definitely go if you want g-s-d
<ogra_> the upstart job just tellls the kernel to enable the device and sets the defaults
<ogra_> i guess thats something to keep
<ogra_> (if it cant be moved into udev or so)
<janimo> xnox, I thought I had removed that snippets in 0.49 or so
 * xnox checks what I have.
<ogra_> janimo, you didnt... we talked about that already
<janimo> ogra_, g-s-d is working besided the bug that initial input orientation is broken
<janimo> ogra_, I did not remove the acceld daemon but I thought I had removed the xsession hook
 * janimo checks
<ogra_> and when i tested rotation completely died when disabling acceld
<ogra_> (dosabling the xsession bit i mean)
<janimo> https://launchpadlibrarian.net/129949778/ubuntu-defaults-nexus7_0.48_0.49.diff.gz
<ogra_> hmm, funny
<ogra_> ogra@nexus7:~$ dpkg -l ubuntu-defaults-nexus7|grep ii
<ogra_> ii  ubuntu-defaults-nexus7                    0.52                                       all          Default settings for Ubuntu customizations
<ogra_> ogra@nexus7:~$ dpkg -S /etc/X11/Xsession.d/95-acceld_start
<ogra_> ubuntu-defaults-nexus7: /etc/X11/Xsession.d/95-acceld_start
<ogra_> ogra@nexus7:~$
 * ogra_ wonders why the binary disagrees with that patch above
<janimo> ogra_, is that a config file hence not autoremoved?
<ogra_> janimo, well, then dpkg -S shoudl point that out i think
<ogra_> probably a later upload re-added it ...
 * ogra_ checks the diffs
<janimo> ogra_, I am uptodate and do not have it
<janimo> dpkg -L does not show it either
<infinity> Did you rm_conffile it when removing it?
<ogra_> ogra@nexus7:~$ dpkg -L ubuntu-defaults-nexus7|grep Xsession
<ogra_> /etc/X11/Xsession.d/95-acceld_start
<ogra_> infinity, well, even if that was missed, should dpkg still show it as being part of the package ?
<xnox> janimo: is there any event that I can listen to in Gtk+ to find out that the screen size has now changed?
<xnox> when rotating ubiquity everything is ok, apart from the panel is keeping it's original size and doesn't recalculate/expand.
<xnox> (in the installer the panel is a standalone custom/small faked single small C-file executable)
<ogra_> hmm
<ogra_> http://paste.ubuntu.com/1636658/ agrees that the file is gone from the binaries
<ogra_> so i geuss infinity's suggestion is best here
<ogra_> http://wiki.debian.org/DpkgConffileHandling
<ogra_> i still think dpkg should somehow indicate its not shipped by the binary
<infinity> ogra_: There's a dpkg-query invocation that can tell you if a conffile is obsolete, I forget what it is.
<ogra_> well ...
<infinity> Our QA people use it to smack us around with bugs on a regular basis.
<ogra_> i think dpkg -L should eb clever enough to tell me
<ogra_> *be
<janimo> xnox, no idea about screen size change callbacks
<infinity> dpkg-query -W -f='${Conffiles}\n' | grep obsolete
<infinity> And look at that, I have 5 obsolete conffiles on my system.  \o/
<ogra_> oh, thanks !
<ogra_> there are more :)
<ogra_>  /etc/init/alsa-restore.override cf3f2a865fbea819dadd439586eaee31 obsolete
<ogra_>  /etc/init/alsa-store.override cf3f2a865fbea819dadd439586eaee31 obsolete
<ogra_> and
<ogra_>  /etc/cups/cupsd.conf e62a552c7e9e384036b0e0e5df9d46c4 obsolete
<janimo> 44 on my system
<ogra_> your nexus ?
<ogra_> wow
<janimo> nope
<infinity> Yeah, I'm going to clean up cups, qemu, and usb-creator-gtk right now. :P
<infinity> xnox: Unless you plan to reintroduce the usb-creatork-gtk init script that made everyone die inside?
 * xnox has 22
<infinity> You guys clearly have more packages installed than I do...
<xnox> infinity: yes.
<infinity> ogra_: When you do the cleaning, read the manpage carefully.  The version check isn't against the version where it disappeared (well, unless that's when you add the code too), it's against the version you're adding the code to, so upgrades from the interim broken versions also DTRT.
<ogra_> k
<xnox> infinity: shouldn't we be fixing these in the archive....?! aka I have 17 from qemu related stuff
<infinity> xnox: Yes, you have more packages than me, or yes, you intend to reintroduce the scary init job?
<xnox> (qemu libvirt kvm)
<xnox> infinity: both.
<infinity> xnox: We should be fixing them, yes.  I only have 3 from qemu.  Give me your output?
<ogra_> infinity, the init job needs to stay, but in much saner form in the session upstart
<ogra_> (once thats there)
<infinity> If the init job is coming back in the same filename, I won't bother removing that obsolete conffile, it'll sort itself.
<ogra_> well, it will likely not live in /etc/init
<xnox> infinity: http://paste.ubuntu.com/1636688/
<infinity> xnox: Oh, I never had qemu-kvm installed, so I only have the latter two, and one from qemu-system-user.
<infinity> All very ew, this migration.
<xnox> infinity: i remember the fairly recent thread on d-d that there is no sane way to take over a conffile when renaming a package
<xnox> =/
<infinity> There isn't.
<infinity> And that's the problem with some of these.  Hrm.
<infinity> Like the cups one.
<xnox> ugu
<infinity> It's shipped, but not in the same package.
<wookey> I've got 96
<infinity> You win.
<xnox> wookey: how many of those are self-inflicted and didn't come from the archive? =)
<janimo> infinity, so when I removed that file from the package should I have also called some dh helpers too for better purging it?
<infinity> janimo: man dpkg-maintscript-helper
<ogra_> janimo, right, like in the wikipage above
<infinity> Which probably SHOULD have a dh wrapper, but doesn't.
<janimo> so this is something dh could not autodetect and DTRT?
<xnox> janimo: dh doesn't have the previous binary package from the target repository to compare and find out about dropped conffig files
<janimo> ah, works around known dpkg limitations
<xnox> yeah.
<ogra_> well, but it is able to tell me the file is obsolete
<infinity> Well, dpkg's treatment of actually obsolete conffiles is basically functioning as designed.
<infinity> It's just that sometimes that design is really undesirable.
<infinity> The move/takeover bit, though, is a straight up dpkg bug.
<ogra_> conffiles should just die
<infinity> Replaces: overwrites should DTRT and don't.
<ogra_> every package should just ship with a conf.d setup for user overrides
<infinity> ogra_: No, conffiles should just be much smarter, and integrate all the crazy stuff that things like ucf tries to do on a much lower and saner level.
<ogra_> or that
<infinity> (ie: 3-way merges)
<ogra_> yup
#ubuntu-arm 2013-02-12
<scientes> http://nullr0ute.com/2012/11/fedora-arm-on-the-google-chromebook/
<scientes> I havn't been able to boot anything but precise
<scientes> quantal and raring Xorg doesn't load, and when it tries it locks up the computer
<scientes> and i get a plymouth error
<scientes> i found the plymouth assert that is being triggered, but can't really debug more than that
<dholbach> good morning
<scientes> morning
<marvin24> [16:12:03] <ogra_> infinity, i would go with that too ... but #ac100 would hate us all
<marvin24> ^ if chromium is the only reason
<marvin24> instead of fixing it
<ogra_> marvin24, nah, many packages would benefit from using NEON
<marvin24> benchmarks?
<ogra_> not idea where they went, we did some in the past
<marvin24> using multiarch would be another solution
<marvin24> at least for the most important libraries which really care
<ogra_> and there are actually some packages that already have runtime switching ... i.e. pixman
<ogra_> multiarch would mean to have something like armhf-neon
<ogra_> i.e. a full new port just for say 20% of the archive
<ogra_> (or probably less)
<ogra_> marvin24, we will definitely switch some day. the question is just when
<ogra_> there is no more modern armv7 HW that laks NEON
<marvin24> I have no problem with this - I just think you should make sure that it give more than 5% for common apps
<marvin24> and you may lose support for many embedded processors
<ogra_> well
<ogra_> if we wanted to be general purpose (embedded, desktop, server etc) on ARM, we would have just gone with armel
<ogra_> but we focus on a single platform with only the desktop, mobile and server  perspective atm
<ogra_> we never targeted embedded
<marvin24> yes, it is of course up to canonical to decide where to make money ;-)
<ogra_> (and i personally also dont know and new ARMv7 embedded chip that could currently run ubuntu and has no N|EON)
<ogra_> its not a matter of making, but of spending :)
<ogra_> having to hack up apps like firefox or chromium with runtime sitches etc costs time and money for creation of that patch and its mainteance
<ogra_> note that i would also vote for dropping non-NEON support if i wouldnt work for canonical
<ogra_> (and its not something that gets dictated or so, its simply a logical evolution to go along with recent hw changes)
<marvin24> I wonder if there is some code to emulate neon in the kernel
<marvin24> like no-fpu
<infinity> marvin24: neon emulation code in the kernel would be a Bad Idea.
<infinity> marvin24: Because then you'd end up trapping attempts at run-time detection, and run neon code when you should be falling back.
<infinity> marvin24: As for libraries, one doesn't need multiarch, glibc hwcaps already handles neon just fine (do an LD_DEBUG=libs when running a binary and see it search neon directories on your neon-capable CPU, and not on one that isn't).
<infinity> marvin24: But it's usually applications that are the big offenders here and we waste a lot of time on, not libraries.
<marvin24> infinity: ok, maybe those apps could be blacklisted somehow on non-neon platforms
<marvin24> if there is some mechanism already
<infinity> marvin24: There isn't, and you wouldn't want that, given that they comprise the two major web browsers, and a bunch of fun media things.
<marvin24> I still wonder where the problem is with neon in apps
<marvin24> some hand-optimization code?
<infinity> (The status quo right now of patching those projects to tear out neon-by-default works fine, but it's non-trivial to maintain when upstream breaks it differently every 3 weeks)
<infinity> Sometimes it's hand-optimised code with broken (or non-existant) fallbacks, so we get to fix the fallbacks too.
<infinity> Sometimes it's upstreams assuming that v7 == neon, and setting a bunch of compiler flags they shouldn't.  Easy enough to back out, but a non-trivial effort to keep vigilant for.
<marvin24> ok, that's just really sad ...
<infinity> Sad that I don't want to deal with the mess, or sad that upstreams suck?
<infinity> The former is just pragmatism, but I entirely agree with the latter.
<infinity> And I yell at them every time I have to fix something.
<infinity> But some just never learn.
<infinity> And it's tiring.
<ogra_> marvin24, its not like we will switch next week ... but along the way to 14.04 it will happen
<infinity> Well, there's "will happen" and "will happen", too. :P
<marvin24> infinity: it is sad you need to drop non-neon because of broken apps - and not for performance reasons
<infinity> I don't intend to flip on -mfpu=neon as a compiler default.  The auto-vectorization code, at last glance, was actually pretty lousy.
<infinity> But "not bothering to revert every silly upstream assumption" may happen at some point.
<infinity> marvin24: Well, it's *also* for performance, to be fair.  That's just not my primary concern.  It may be for others.
<marvin24> ogra_: there are other distros of course - I will always find a way to boot the latest kernel ;-)
<ogra_> indeed
<infinity> marvin24: precise userspace is supported for another 4+ years, still.  No reason to not be booting the latest kernels there. :P
<ogra_> note that we arent enforcing non-neon (as infinity said above) but will at some point stop to apply hacks
<ogra_> you could try to form a community team to take care of the patches ;)
<infinity> Now, I'll revisit the -mfpu=neon statement if the auto-vectorizer in gcc-4.8 isn't crap.  I haven't had time to benchmark.
<infinity> But for now, it's hand-tuned or GTFO, as far as getting performance from NEON.
<marvin24> the simplest solution would be to upstream the "hacks"
<ogra_> which is whats being tried since 4 years
<marvin24> this way you wouldn't have to put more efforts in fixing it
<infinity> And, if people were willing to put the effort into making every hand-tuned app have proper runtime detection and fallbacks, I'd happily even help push those patches upstream.
<infinity> marvin24: Upstreaming the compiler assumptions tends to fall on deaf ears.
<ogra_> awwww
<infinity> marvin24: Upstreaming fixes to hand-tuned code usually goes over quite well, but in projects like libv8, they just move so quickly that they break three new things after we fix one.
<ogra_> upstream kills pm-utils for systemd
<infinity> marvin24: To be very, very clear here, if there was a compelling movement from various people to make sure this stuff always worked correctly, I wouldn't have any problem whatsoever with keeping the baseline at v7/no-neon forever (though, "correctly" would also mean that anything with neon code should actually RUN that neon code on neon CPUs, so proper runtime detection, not compile-time crippling, etc)
<infinity> marvin24: But I've yet to get that sort of commitment from, well, anyone.  And it's not something we can sink the resources into.
<marvin24> infinity: ok, ok - I got it
<marvin24> just wanted to cry a bit about it
<infinity> Well, it hasn't happened yet. :)
<infinity> I could be talked down from this position too.
<infinity> If someone puts some solid effort into upstreaming proper runtime detection into chrome/firefox, thus easing the burden on our security team, etc, those are the two biggies.
<infinity> And while I don't like having to hack and slash at other minor packages, they're also less likely to "matter" if they're broken, and some keener can fix them when they notice.
<marvin24> infinity: thanks for you efforts!
<ogra_> hrw, do you have suspend working on your cb ? if so, how ? i get kernel messages that it couldnt stop some tasks if i try here
<hrw> ogra_: kernel in NEW queue has suspend working
<ogra_> how do i install that ?
<ogra_> do we have some howto ?
<hrw> grab it from new and build?
 * ogra_ still runs the original cros one
<ogra_> hrw, heh, i know how to build it ... but lack the bits flash-kernel would do with the binary
<ogra_> where do i put it
<ogra_> (and how)
<hrw> ah, signing etc
<hrw> w8 half hour - meeting now
<ogra_> well, signing and i have no clue where i should put it
<ogra_> ok
<ogra_> no hurry at all
<ogra_> i'm not in urgent need of suspend :)
<ogra_> http://paste.ubuntu.com/1639292/
<ogra_> infinity, ^^^ does that look ok to zou ?
<ogra_> *you
<infinity> ogra_: No.
<infinity> ogra_: prior_version should be the one right before the one you're doing.
<ogra_> so 0.52 ?
<infinity> ogra_: 0.52 is what you're doing now, no?
<ogra_> nope. 53 is
<ogra_> havent run dch yet
<infinity> Ahh.
<infinity> Kay.
<ogra_> ok, fixing
<infinity> So, either 0.52 or 0.53~, if you're concerned about forked versions.
<ogra_> tegh filename needs to be the full path ?
<ogra_> the manpage isnt clear with that
<infinity> ogra_: Also, it should be in preinst/postinst/postrm, not just postinst.
<ogra_> three times the same ?
<infinity> ogra_: *and*, don't guard it in the $1 test, just leave it bare.
<ogra_> why do i need that
<infinity> ogra_: Read the manpage to see what it does.
<infinity> Search for "Current implementation".
<infinity> It's not just removing the conffile, it's much more clever.
 * ogra_ sighs about translated manpages
<infinity> And the filename needs to be the full path, yes.
<ogra_> k
<ogra_> aha, ok, its a three step thing, understood now
<ogra_> janimo, can i drop the acceld binary or do you need anything from it for the roataion stuff ?
<janimo> ogra_, you can drop it, thanks
<janimo> all should work fine without it
<ogra_> k
<wookey> xnox: what's the difference between NO_PKGS=-Nfoo  and DH_OPTIONS=-Nfoo ?
<wookey> is there any?
<xnox> DH_OPTIONS should be tolerated by dh_* commands.
<xnox> NO_PKGS sounds like either custom stuff or maybe in cdbs?
 * xnox goes to double check cdbs
<wookey> I saw it in udev
<wookey> loks like doko put it in in 175-0ubuntu16
<xnox> wookey: so it's not exporting a DH_OPTIONS, because it conditionally uses -N for only some dh_* commands in the binary-arch target.
<xnox> but yeah, it's the same - just used as a command line options instead of exporting environment variable.
<wookey> ah yes I see
<xnox> it does some cunning stuff with setting & unsetting DH_OPTIONS and juggling all sorts of packages left and right =)
<wookey> We should write up all this 'best practice' somewhere
<xnox> s/best/worst/
<wookey> because it's not exactly obvious to your average packager wanting to DTRT
 * xnox likes to call it barrier of entry
<wookey> to the elite hall of unfortunate distro cross-build fixers?
<wookey> I don't mind if some more people come and play
<xnox> =))) well more like the torture dungeon =) but it's all fun and dandy.
<wookey> you are very welcome to tell me why perl cross-build works OK, but perl multiarch cross-build doesn't...
<wookey> http://wiki.debian.org/Multiarch/Perl
 * xnox wishes I could apt-get remove --purge perl
<wookey> I'd happily strangle its config system which is v. horrid.
<xnox> your queue ticket number is 4567 to stangle perl's config system.
<wookey> xnox: udev is quite broken. It has no configure: target so relies on configure file being present, but at the end of a dpkg-buildpackage -S build configure is removed.
<wookey> so you can only ever build it once
<wookey> I suspect this happened when autoreconf fooery was added
<ogra_> its udev, who would build it more than once anyway :P
<wookey> I hate packages that only build once - it's increasingly common
<wookey> And I just spent some time wondering why my changes had broken the rules file...
<wookey> they hadn't of course - it just came bust
<ogra_> yeah, systemd will solve that
<xnox> wookey: use bzr ;-) bzr branch lp:ubuntu/udev & then build using $ bzr bd, each time does export of the head with your changes and does a clean build.
 * ogra_ shudders
<wookey> xnox: that is _not_ a solution
<xnox> wookey: that way all my builds are "as if the first one"
<wookey> yeah which is why lots of packages only work once
<wookey> people like you who never try a second time
<xnox> wookey: are you saying that if clean target is invoked between the builds it fails?
<ogra_> is it so hard to add an override in the rules file to keep configure in place ?
<xnox> that's an RC bug.
<xnox> wookey: ./debian/rules clean; ./debian/rules build; fakeroot ./debian/rules binary; cycles work just with with all standard dh_autoreconfigury helpers.
<xnox> s/work just/just work/
<wookey> apt-get source udev; cd udev-175; dpkg-buildpackage -S; dpkg-buildpackage -B fails for me
<wookey> hmm. it's worked now...
<wookey> apt-get source udev; cd udev-175; dpkg-buildpackage -S -sa; dpkg-buildpackage -B fails for me
<wookey> that seems odd
<wookey> but also quite borked
<wookey> OK. I think I've fixed it.
<wookey> OH look a new libffi so my build chroot broke again. Will you lot stop uploading new packages every 5 mins
<ogra_> lol
<wookey> It would be easier if apt produced more helpful messages like "Can't install foo: arches out of sync" rather than just "foo won't be installed"
<wookey> and if you have any moons on sticks that would be good too
<scientes> "cannot install foo: the planets are not aligned"
<ogra_> wookey, i bet patches are accepted ;)
<wookey> ogra_: yeah. I tried to fix something in apt recently and remembered that I totally don't grok C++
<wookey> I had to find someone significantly cleverer to do it for me
<ogra_> haha, i know what you mean
 * ogra_ usually runs if there is C++ involved
<wookey> I've spent 20 years not grokking OOP. I suspect it's too late to change
<ogra_> well, i bet if you really want it you can do it ...
<ogra_> not that i personallys would
<ogra_> -s
<dmart> It's possible that ARM support can answer the question about finding out how much RAM there is -- if the docs don't have it, I don't know how to answer that
<dmart> It's possible that ARM support can answer the question about finding out how much RAM there is -- if the docs don't have it, I don't know how to answer that
<ogra_> dmart, thanks for letting us know :)
 * dmart would an IRC client that automatically guesses the right channel :)
<ogra_> :)
<ogra_> or a WM with "focus follows brain" mode
<dmart> ogra_: nah, that would spray stuff into windows pretty much at random.  Focus follows eyes would be pretty cool though
<ogra_> hehe, true
<davmor2> ogra_: that's a stupidly dangerous suggestion, especially if you happen to working in a coffee shop with your wife beside you :D
<ogra_> LOL
<ogra_> though beside me isnt that bad with a laptop, behind me would be worse
<mosasaur> my image is on a vfat device and can't grow bigger than 4 GB
<mosasaur> suggestions?
<ufsu_> what is the directory that I can access .config file to see what kernel modules are disabled?
<TheMuso> ufsu_: All kernels have their respective config files in /boot.
<TheMuso> At least all kernels shipped in Ubuntu packages.
<ufsu_> TheMuso: e CONFIG_OMAP_RESET_CLOCKS=y is set on the configure file. If I disabled that module on configure file, will that module be disabled on the next boot?
<ufsu_> I am using beagleboard-xm if you need to know
<TheMuso> No.
<TheMuso> You'd have to rebuild the kernel.
<TheMuso> Config files are just a point of references to show whats configured. There may be a way to disable a module, but generally you would have to rebuild a kernel to disable it.
<ufsu_> TheMuso: thank you
<ufsu_> do you know where are the kernel source codes for ubuntu-server for a beagleboard-xm?
<ufsu_> omap3
<TheMuso> You can have a look on kernel.ubuntu.com/git.
<ufsu_> do you have any idea which one is for beagleboard-xm?
<TheMuso> No sorry.
<ufsu_> thank you
<TheMuso> I believe that hardware is OMAP based, so look for an omap tree I guess.
<ufsu_> ogra_ should know if he is there?
<TheMuso> He is probably not around since its past midnight for him.
<TheMuso> Although stranger things have happened in the past. :)
#ubuntu-arm 2013-02-13
<wookey> infinity: udev doesn't (Cross) build with glibc 2.17 in a clean chroot
<wookey> udev/sd-daemon.o: In function `sd_is_mq':
<wookey> /home/wookey/ubuntu/raring/udev-175/build-deb/udev/sd-daemon.c:390: undefined reference to `mq_getattr'
<wookey> fixed by adding -lrt on the command line
<wookey> But it works ok in a well-used chroot
<wookey> I haveno idea what the right fix for this is
<wookey> libtool successfully adds -lsepol -lselinux but not -lrt
<wookey> OK. fixed by adding AC_SEARCH_LIBS([mq_getattr], [rt], [], [AC_MSG_ERROR([POSIX RT library not found])]) to configure.ac
<dholbach> good morning
<ufsu> ogra_: could you tell me where I can find kernel source code for omap3 (beagleboard-xm)?
<ogra_> ufsu, omap3 is built from the main ubunu kernel source
<ogra_> (the same as i386)
<wookey> hmm apt-get install libstdc++6:arm64 wants to remove my cross-toolchain and apt, and thus I cant install libglib2.0:arm64 -> libpcre3-dev:arm64 -> libpcrecpp0:arm64 -> libsdtc++6:arm64
<wookey> so crossbuild-essential-arm64 is still installable but not if you want any useful cross-build-deps. I'm not quite sure what's going on but I think it's a toolchain update without a corresponding crosstoolchain update. Is that right?
<wookey> NO. OK. it's my fault
<wookey> libgcc1 has an epoch but libstdc++6 doesn;t
<wookey> so my attempt to stremaline my equivsd packages builds has gone wrong in rather subtle way
<wookey> <mutter>
<wookey> hah. fixed. bastard thing.
<hrw> ;;D
<ogra_> janimo, better upload that g-s-d fix, on my nexus7 g-s-d accumulated ~150M RES over two days if idling ... it is the worst memory consumer in htop here now
<janimo> ogra_, yes it was a stupid b mistake. seb seems to have uploaded already though
<janimo> I am fighting with a new ubuntu install and a broken monitor
<ogra_> janimo, oh, fun
<ogra_> janimo, seb was a bit grumpy that you didnt commit your changes to bzr ... desktop packages dont use UDD
<janimo> don't or do use UDD?
<ogra_> dont
<janimo> isn't UDD the bzr thing?
<ogra_> they keep the packaging in a separate branch
<janimo> ah
<ogra_> so your uploads need to be committed separately
<janimo> right, it was lame on my part
<ogra_> (they have the right branches in the Vcs-Bzr field in the control file)
<ogra_> well
<ogra_> its pretty non standard what they do
<ogra_> i fell into that trap too already
<janimo> as for review, I was hoping people review paches that go in
<ogra_> (i tend to just use apt-get source .... )
<janimo> there is post commit review too, no need for full merge request, etc overhead
<ogra_> i'm pretty sure seb took a look before uploading
<janimo> yes, I prefer apt-fget source too as it is only one command to remember :(
<janimo> :)
<janimo> silly kbd
<ogra_> yep
<janimo> oh, I know he took a look now, I just thought devs watch their packages and review when they see someone else adding new code
<janimo> actually I was told in my initial uploads that the patch ismissing Bug description and other info
<janimo> so at least some review is being done but maybe not rigurous and not as a rule
<ogra_> yeah
#ubuntu-arm 2013-02-14
<drizzy> hell
<drizzy> hello
<drizzy> what's some of your favorite applications for ubuntu-arm ?
<dholbach> good morning
<diwic> ogra_, good morning, do you know anything about the status of virtualized ppas for arm?
<diwic> ogra_, I mean, will they ever arrive?
<ogra_> diwic, thats in use since a while
<ogra_> if you have a PPA the needs to build arm, you can contact the LP people and have them enable it
<diwic> ogra_, does that mean we can have arm ppa for non-canonical people?
<ogra_> your package should build in a sane time though, nothing that builds several days is allowed etc
<ogra_> yes
<diwic> \o/
<ogra_> there was a mail about that
<ogra_> about two months ago or so
<lilstevie> nice
<lilstevie> about time :p
<diwic> ogra_, what list?
<ogra_> either u-devel or u-devel-discuss
 * ogra_ forgot which one
<diwic> ogra_, looking at both but cannot find it
<diwic> ogra_, maybe they don't have "arm" or "ppa" in the subject line
<ogra_> well, ask in #launchpad, i'm sure they can point you to it (or just enable arm for you)
<ogra_> i cant find it either
<scientes> what are you looking for?
<scientes> ppas build for armhf (raring drops armel, so not sure about that)
<diwic> ogra_, https://dev.launchpad.net/CommunityARMBuilds
<ogra_> yeah, that was in the mail too
<ogra_> great
 * ogra_ bookmarks for the next person asking :)
<scientes> that page should mention armel vs armhf
<ogra_> why ? armel is dead
<scientes> ok your right
<ogra_> it wasnt supported in the last LTS
<ogra_> (it was "just there" though)
<scientes> ogra_, it was release with last LTS
<scientes> but yeah, it was armv7
<ogra_> nope
<ogra_> and nope
<scientes> quantal was armv5
<scientes> but precise armel was armv7
<ogra_> precise armel is v5
<ogra_> but was never released as supported arch
<scientes> fedora is dropping armv5 too
<ogra_> (or v6, dont remember exactly, but not v7)
<scientes> no, precise is armv7
<ogra_> everyone but debian is dropping it
<scientes> for armel
<ogra_> i'm pretty sure we switched it to v6
<scientes> ld.gold is broken upstream for armv5, i fixed it and ian says its good, but its not comitted
<scientes> for quantal AFAIK
<scientes> but anyways that is past
<ogra_> right, we havent supported armel in a while
<ogra_> 11.10 was the last one we claimed to support
<ogra_> everything after that, while armel was still existsing, had no support for it
<ogra_> "best effort community support" :)
<scientes> so, are the arm-linux-gnueabi and arm-linux-gnueabihf toolchains actually differn't in terms of what they target (besides default options)?
<scientes> this is a topic that has confused me
<scientes> or is it just that the multi-arch paths and linker paths are hard coded into them?
<scientes> wait, its the ABI
<ogra_> one builds armel the other armhf
<scientes> would it really add much size to the binary to support both abi's with one compiler?
<ogra_> dunno, ask hrw
<ogra_> he maintains the cross compilers
<hrw> I maintained
<ogra_> oh, i thought you still do it as spare time thing
<hrw> no, doko kind of took over
<hrw> ok, 320GB hdd moved to usb3 case. time for cabling
<hrw> chromebook -> usb3 hub -> (usb3 case -> sata hdd) + usb-ethernet
<hrw> one thing to buy during linaro connect - usb3 cables
<hrw> 76MB/s sounds much better than 23MB/s
<ogra_> arent the cables the same ?
 * ogra_ doesnt need special cables to get the full throughput out of his 3.0 devices
<hrw> ogra_: usb3 cables differ from usb2 cables
<hrw> other connectors (especially at device side)
<hrw> and I want to buy longer A-B, A-microusb, A-A extenders
<hrw> now usb harddrive is faster than internal emmc
<lilstevie> ogra_, usb3.0 is electrically different from usb2
<ogra_> lilstevie, well, then it at least behaves great in compatibility mode :)
 * ogra_ never saw any issues due to having 2.0 cables here, all my disks reach their tech specs
<lilstevie> ogra_, heh
<hrw> real    21m38.431s
<hrw> nice time for rebuilding kernel
<hrw> ogra_: while their tech specs are 30MB/s?
<tjaalton> flashing nexus7 fails here, fastboot flash userdata just says "error: cannot load raring...img"
<tjaalton> even when done manually
<tjaalton> current image
<ogra_> hrw, more like 70-100MB/s
<hrw> ogra_: and you try to say that you get this on usb2 cables?
<tjaalton> same issue with yesterdays image..
<scientes> how can  i debug EGL_NOT_INITIALIZED with mali non-free graphics?
<hrw> scientes: which device?
<scientes> chromebook samsung arm
<hrw> scientes: which kernel you have?
<scientes> i can't get EGL/GLESv2 to work
<scientes> chromeos git tip 3.4
<hrw> scientes: and you do not know about https://launchpad.net/~chromebook-arm/ as well?
<scientes> like rebuilt today
 * ogra_ has it working ... including flash in chromium
<hrw> scientes: which branch
<scientes> hrw, yes i do
<scientes> chromeos-3.4
<hrw> use R25
<hrw> like I did in PPA of that LP project
<scientes> i independantly packages vboot_reference
<hrw> fragmentation happens
<hrw> our vboot-utils got stuck in NEW queue in Debian
<scientes> the printf() patch is wrong
<scientes> in yours
<hrw> patches are welcome?
<hrw> http://anonscm.debian.org/gitweb/?p=collab-maint/vboot-utils.git;a=summary
<scientes> hrw, http://git.debian.org/?p=collab-maint/vboot_reference.git
<hrw> scientes: "git rebase --help" please
<scientes> yeah i can audit your packaging and pull in what i did
<scientes> your copyright file looks much better
<hrw> licencecheck tool is useful
<scientes> have you tried R26?
<hrw> no
<hrw> too many other things to do
<scientes> ok i will
<hrw> 300K diff compared to r25
<hrw> not too much
<scientes> well wondering why chromeos-3.4 doesn't work...
<scientes> also suspend is flaky
<hrw> scientes: if you have lot of time then feel free to find out. if not: R25
<hrw> wow! my fresh 13.04 installation just booted on chromebook
<ogra_> nice
<hrw> no wifi firmware
<hrw> I think that will have to take it from marvell repo and send to linux-firmware repo
<hrw> ok, sent. I hope that dwmw2 will accept ;D
<hrw> http://marcin.juszkiewicz.com.pl/2013/02/14/how-to-install-ubuntu-13-04-on-chromebook/
<ogra_> hrw, fail ... not intrested in using SDs :P
<hrw> ogra_: I do not plan to destroy my working 13.04 installation which I have on internal ;d
<ogra_> pfft, do it for the community !
<hrw> I will check how to upgrade chrubuntu to 13.04 on weekend
<hrw> but also on sd
<ogra_> hrw, i assume to just use your kernel i just need to use all these commands for mmcblk0p1 instead oof 1p1 ?
<hrw> yes
<ogra_> ok
<hrw> moment
<ogra_> i dont want to destroy my install either ... but want to use your kernel
<hrw> s/mmcblk1p1/KERN-x/
<ogra_> ok
 * ogra_ will try on the weekend
<hrw> you need to check which KERN-[ABC] you use and replace kernel in it
<ogra_> i want a kernel with zram
<hrw> http://paste.ubuntu.com/1650688/
<hrw> it is my do-a-kernel.sh
<hrw> http://paste.ubuntu.com/1650692/ - write-a-kernel.sh
<ogra_> dude !
<ogra_> that should be a flash-kernel patch !
<hrw> is flash-kernel able to identify board in other way than /proc/cpuinfo?
<hrw> Hardware        : SAMSUNG EXYNOS5 (Flattened Device Tree)
<ogra_> how do you identify it ?
<hrw> that's chromebook, probably also nexus10, maybe andale
<suihkulokki> that kind of definitions are going to become really common with device tree enabled platforms
<hrw> exactly
<hrw> ogra_: and how flash-kernel have to guess where I keep kernel?
<ogra_> z`z`s/guess/detect/
<ogra_> :)
<hrw>  /dev/mmcblk0p{2,4,6} or /dev/mmcblk1p1 or maybe I use U-Boot in KERN-C and load kernel from /boot/uImage
<hrw> so many options
<ogra_> well, eventually we should add something to f-k
<hrw> feel free - you got code
<ogra_> yeah, but i'm using the device
<hrw> do not forget to add dependencies on cgpt and vboot-utils which are stuck in NEW in Debian
<ogra_> yeah, we'll have to wait anyway
<hrw> we have 3 chromebook packages in NEW in Ubuntu
<ogra_> still ?
<ogra_> slackers !
<hrw> I can wait - they are also in PPA :D
<drizzy> what are some of your favorite applications that you run on ubuntu-arm ?
<ogra_> the same i run on ubuntu x86
<infinity> I don't have favourites: I love all my software equally.
<darkfaded> drizzy: nagios, dhcp, dns :)
<drizzy> basic services are your favorite apps darkfaded?
<drizzy> infinity: that's cute
<darkfaded> drizzy: for the ubuntu/arm: yes - because it silently does its job
<drizzy> i understand
<darkfaded> and the power consumption is so low that i'll never need to think about it again
<drizzy> :)
<darkfaded> what will / are you running on it?
<drizzy> i'm running all the standard daemons
<drizzy> but i also run xchat and audacious on it
<drizzy> i installed gimp
<Tassadar> bootloader update broke kexec-hardboot on Nexus 7, anybody has any idea what might be wrong http://paste.ubuntu.com/1654119/ ?
<Tassadar> hm, looks like it just needs different --mem-min setting, the part of memory is probably erased during reboot or something
<xnox> argh!
<xnox> http://www.androidpolice.com/2013/02/12/new-android-4-2-2-feature-usb-debug-whitelist-prevents-adb-savvy-thieves-from-stealing-your-data-in-some-situations/
<Tassadar> ..yeah :/
<xnox> ogra_: https://gist.github.com/archon810/4772945/raw/c845a6282dbc2b55a6697c5e2ffe831263db3a86/Changelog_android-4.2.1_r1.2_android-4.2.2_r1.txt 4.2.2 details
<Tassadar> hmm, what does kernel cmdline parameter "vmalloc" do?
<Tassadar> it was changed from 128mb to 512mb in new n7 bootloader
#ubuntu-arm 2013-02-15
<isaias> i need help with installing ubuntu on Nexus 7
<isaias> after the Ubuntu logo comes up, the screen goes black and stays black
<isaias> I noticed that while it is flashing, one of the txt says "df: cannot read table of mounted file systems"
<isaias> not sure if that has anything to do with it
<isaias> anyone availible to help?
<TheMuso> isaias: Is this a recent image, like in the last day or so? If so, I believe there are some problems with the code that gets loaded after a fresh flash, i.e the stuff responsible for asking your language and other info etc.
<TheMuso> So in other words, I think things are currently broken.
<TheMuso> isaias: If you try an older image, say from 20120213 on http://cdimage.ubuntu.com/daily-preinstalled, you may have more luck.
<isaias> The requested URL /daily-preinstalled, was not found on this server.
<TheMuso> Sorry, http://cdimage.ubuntu.com/daily-preinstalled/
<isaias> nvm
<isaias> lol, i saw the comma after xD
<TheMuso> heh ok.
<lilstevie> wow a wild TheMuso appears
<TheMuso> I've been around, just not had reason to post in here.
<lilstevie> heh
<lilstevie> long time no chat :p
<TheMuso> Indeed.
 * lilstevie has been busy with another project
<TheMuso> Cool.
 * lilstevie heads off to the rugby
<TheMuso> Enjoy.
<lilstevie> will do
<isaias> TheMuso: Do  I have to have the factory Nexus 7 installed? I have to put it in flash mode to manually install it
<isaias> to manually install ubuntu
<isaias> or by flash do they mean fastboot?
<isaias> which I think they do...
<isaias> maybe. im waiting on my device, lol
<TheMuso> Yes you need to boot the nexus into fastboot mode.
<isaias> terminal is <waiting for device> after I ran $sudo fastboot flash boot /path/to/*.bootimg
<isaias> taking a while, which is why I'm asking, hoping this is normal
<TheMuso> Did you make sure fastboot could see your device fist?
<TheMuso> first
<isaias> yes. it could
<isaias> i deleted user data and stuff
<TheMuso> Hm ok.
<isaias> it shouldn't be waiting, should it? lol
<TheMuso> No.
<isaias> i probably did something xD
<TheMuso> If fastboot could see your device when you ran fastboot devices, then it should go straight ahead and do it.
<isaias> i see what i did wrong
<isaias> "mount: mounting /dev/mmcblk0p9 on /root failed: invalid argument"
<isaias> apperently its not rooted?
<isaias> maybe :P
<TheMuso> Did you oem-unlock the device?
<isaias> its unlocked
<isaias> i have no idea what I'm doing anymore xD
<isaias> where else can i get help?
<dholbach> good morning
<guard> hello
<guard> err
<isaias> there we go
<isaias> is someone available to help me/tell me what I'm doing wrong?
<isaias> I tried installing Ubuntu, the screen goes black after the Ubuntu boot logo comes up
<scientes> isaias, what hardware?
<isaias> im trying to install it on Nexus 7
<apw> isaias, we have had reports of that, rebooting it a few times sometimes resolved it
<apw> it seems to be an install time issue mostly
<isaias> I cant even turn it off right now. i try and it reboots, but it wont start. it stays a black screen
<isaias> a mouse is nessisary, isnt it?
<darkfaded> if you're very patient you can manage w/o mouse, but you'll grow some grey hair :)
<isaias> rowing grey hair withh this not working, so i wouldnt mind waiting as long as its possible to set everything up without it,,,if i can get this to work
<isaias> i have it unlocked. am I supposed to root it?
<ogra_> tjaalton, can we turn back bug 1068994 to not be "incomplete" so it doesnt auto-close
<ubot2> Launchpad bug 1068994 in X.Org X server "button1 gets stuck after a while" [Medium,Confirmed] https://launchpad.net/bugs/1068994
<tjaalton> ogra_: sure
<tjaalton> ogra_: I'm building e17 atm so that I should be able to reproduce it with the new xserver without tegra blob
<ogra_> tjaalton, hmm doesnt raster have packages for that ?
<tjaalton> maybe, but I've pulled source packages from a ppa and building them as-is, seems to work so far
<ogra_> k
<ogra_> well, he isnt around to ask him anyway
<tjaalton> does he hang out here?
<tjaalton> or in general
<ogra_> he hung out here the last months ... but rather randomly (and i think he lives in an asian TZ)
<tjaalton> ok
<isaias> anyone here know how to deal with problems when installing ubuntu on a Nexus 7? Mine screen goes black after the boot logo
<isaias> my screen*
<ogra_> there is a bug in the images atm .... being worked on
<ogra_> try again on the weekend
<isaias> aww, i just bought it yesterday :P
<ogra_> sorry, i try my best but am still poking in the dark to find whats wrong
<isaias> thats alright. im just happy its finally possible
<isaias> so thank you :)
<ogra_> :)
<isaias> ogra_: I'm any way I can help? I'm not so good at debugging or anything like that, at least not yet (still learning to programming). If you do find something I can do, I'd be more than happy to help.
<isaias> typo :p
<ogra_> well, its pretty tricky to debug, you need to change the kernel cmdline to stop booting in the initramfs. then debug from there with an attached keyboard
<Tassadar> ha, ogra_ is here - new n7's bootloader changed vmalloc value in cmdline from 128mb to 512mb, any idea what it might affect?
<isaias> I want to learn all about that xD
<Tassadar> it may have broken plymouth (the Ubuntu with dots image does not show up), but I'm not sure it is just because of the bootloader
<ogra_> Tassadar, nope, no idea
<Walther> I heard there are some bugs with the current images, any ETA on fix? Also, compatible with the recent 4.2.2 release?
<ogra_> plymouth works fine here and i had no reports about it failing (yet)
<ogra_> Walther, no ETA yet, i'm still digging
<isaias> mine shows the ubuntu with dots
<Walther> and too bad i don't have an OTG usb cable (just yet), would've been glad to help debugging
<isaias> is there any way I can look without touching anything?
<Walther> Oh, and btw, any merges going to happen with the Ubuntu Phone project? At least imho even Nexus7 could benefit from the phone-ui as demoed by Mark
<isaias> the code i mean
<isaias> or anything
<Walther> ...aaaand just slightly related, I've not yet installed any version of ubuntu on my nexus, but i've been using it for quite some time already and I've heard unlocking the bootloader will wipe all data - what, if such exists, is a good way of BUpping and restoring everything to the stock jelly bean install?
<ogra_> isaias, press the volume button ... that shows the boot messages
<Walther> I mean, I want to dualboot, at least for now
<ogra_> (not that it would help you much)
<ogra_> Walther, if you want to dualboot you need to use the unsupported image from xda developers
<Walther> is the whole image a custom build, or just a custom bootloader / rom selector?
<Walther> wouldn't it be possible to have the image be ..more generic, and support dualbooting out-of-the-box, via some sort of merge between current image and the xda developers thingy
<Tassadar> are you talking about nexus 7?
<Walther> yup
<Tassadar> http://forum.xda-developers.com/showthread.php?t=2011403
<Tassadar> and I'm using ubuntu daily images
<Walther> yes, i know that thread
<ogra_> Walther, the motivation goes actually in the other direction ...
<Walther> ogra_ just sounded like he was implying "unofficial *images*"
<Walther> ogra_: Oh, hmm?
<ogra_> using the whole disk and completely replacing android
<Walther> of course that works for Canonical's interests, i can see that. Just not very user-friendly for beta testers / kinda makes the entry step a bit steep
<ogra_> well, we need reliable data so the image has to function as any other ubuntu image ... with dual boot you have to jump thopugh hoops that can blur the debugging data
<ogra_> (userspace hacks etc)
<Walther> Anyway, I repeat my earlier question, any thoughts on whether there will be merges between the phone version and nexus build? At least imho it would be really nice to get parts of the phone ui as demoed by Mark at CES
<ogra_> while having dualboot is great and i muchly appreciate Tassadar's work, for serious development you should use the official image ... if you just want to use ubuntu as enduser, go with the dualboot one
<Walther> ogra_: mmh, but Ubuntu supports dualbooting on desktops/laptops as well ;) (don't take it too personally, just that in my opinion official dualboot support would be really nice, even if the ROM manager / bootloader would be unofficial)
<Walther> so just to clarify - are the dualboot things actually different, separate *images* or just a matter of applying a separate bootloader?
<Walther> that's just a question i want to have answered in a very distilled form
<Tassadar> MultiROM is using official ubuntu daily images
<Tassadar> the problem with multi-booting on arm devices is that we usually can't change bootloader, so many hacks are needed
<ogra_> Tassadar, didnt you say you had to change filesystems and apply some userspace changes  ?
<ogra_> or was that just an early image
<Tassadar> heck, on nexus 7, you can't event change partition layout
<ogra_> in any case if we would provide dualboot, we would do it via the mechanism we already have (wubi) and avoid kernel or userspace changes
<Tassadar> I take the image, manually extract root.tar.gz from it, extract root.tar.gz to some folder in /sdcard, apply this patch https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1089038 and remove ac100-installer and disable flash-kernel
<ubot2> Ubuntu bug 1089038 in initramfs-tools (Ubuntu) "[PATCH] Add support for booting from subdirectory in root" [Undecided,Confirmed]
<ogra_> but thats out of discussion atm the images are as they are and wont change for now
<Tassadar> thank's to kexec, I don't have to change that much, which I am happy for
<ogra_> Walther, phone images are developed elsewhere, cccant say much about merging stuff from them in yet
<Tassadar> (and that patch is not even needed if I want to boot from .img file)
<Walther> ogra_: I would *greatly* appreciate if you devs would collaborate
<Walther> and would be extremely glad to help with that
<Walther> as I don't have and don't currently plan to get a nexus 4 or other compatible smartphone
<ogra_> Walther, the nexus7 image isnt for endusers and has a very very specific purpose
<ogra_> for which it currently works ...
<Walther> ogra_: Oh?
<Walther> is the very very specific purpose "internal testing" or what :P
<Walther> or "you'll see it announced later" :P
<ogra_> its to have a device all involved devs use to reduce the footprint of unity
<ogra_> and thats the current sole purpose
<Walther> aha
<Walther> not bad
<ogra_> (and pretty fruitful, we managed to shove off over 200M fRAM usage from the idling desktop)
 * Walther slowclaps
<ogra_> (390 vs >600M)
<Walther> that's *big*
<ogra_> i hope we get down to around 256M
<ogra_> yes, it is, and all arches benefit from it
<Walther> sounds like a good ballpark goal
<ogra_> we could have taken a small x86 device instead of the nexus if that would have been convenient
<Walther> that makes me even more hopeful then that the actual "phone" images will supprot nexus 7 as well as a device
<ogra_> so our focus is totally not on the device or on making it shine for endusers atm
<Walther> understood
<ogra_> but to have a common limited base for everyone
<Walther> then I just have to try to poke the -phone developers and hope they'll make it usable for the nexus 7
<Walther> and yeah, it actually raises my hopes as if nexus7 project was actually being developed for endusers, it could have been harder to convince phone devs to make the nexus7 supported as "it already has an image" etc
<ogra_> well, you can count on the fact that by 14.04 (as announced and planned since years) there will be a nexus7 image for endusers :)
<ogra_> its just not the current focus
<Walther> heh
<Walther> i'm still hoping very strongly that the nexus7 enduser image will contain the phone ui
<Walther> and perhaps have the desktop view behind a launcher, a la "ubuntu for android"
<ogra_> might be, who knows ... time will tell ... there isnt any phone UI in the ubuntu archive yet
<Walther> I can still rewatch the engadget hands on with Mark and the phone and drool over the ui, it's just *so damn slick*
<ogra_> (and the official images only contain components from the archive)
<Walther> yeah
<Walther> it's still a big, big WiP
 * ogra_ personally hopes there will be a nexus4 image soon :)
<ogra_> but first of alll there needs to be a release of the code ... which will happen end of the month
<Walther> and a Nokia N9 image :P
<Walther> yup
<ogra_> heh
<Walther> btw, do you know how much of it will be open and how much will be closed
<ogra_> all should be open afaiik
<ogra_> liek ubuntu ...
<Walther> and if there is going to be "make this image support n devices and make a pull request" or "make your unofficial ports if you want"
<ogra_> you surely have something equivalent to  the nvidia drivers
<Walther> that would certainly be nice, i mean, so far I've got the impression that there would be a nasty bit of "we actually want to work closely with OEMs this time" and bullshit
<ogra_> that will surely happen too once there are OEMs
<Walther> mm
<Walther> But I really don't want to see what happened with android to happen with ubuntu
<Walther> a bucketload of unofficial ports to specific devices
<Walther> instead of centralized, "let's add support for this device as well"
<Walther> Of course with android it might be a bit more understandable ...but it still doesn't make it right
<ogra_> we'll see, i doubt thats something you can massively influence if you provide your stuff in the open
<ogra_> if people want to build their own thing based on it (and add a touchwiz ui on top) you cant really stop them
 * Tassadar will have nightmares about Ubuntu Phone with touchwiz
<ogra_> lol
<ogra_> yeah, was a mean example
<Walther> :D
<Walther> But yeah, i would definitely like an approach similar to the genkernel
<Walther> stuff gets merged, and it supports n+1 devices and platforms
<Walther> imagine if you had to have separate ports for asus/ibm/dell/samsung/whatnot desktops and laptops...
<isaias> what language does this ubuntu use?
<ogra_> lots of languages
<isaias> what language is this version of ubuntu written in?
<ogra_> many :)
<isaias> Objective-C? :P
<ogra_> ubuntu is a distribution of software written by many different people
<ogra_> each developer has his own preference
<isaias> ubuntu-phone is mainly QML and Java
<ogra_> many write stuff in C, some desktop stuff is in vala, there is shell, python, perl and many others
<ogra_> no
<isaias> thats what they told me over there, lol
<ogra_> ubuntu phone uses QML for the UI apps
 * Tassadar imagines packages written in brainfuck
<isaias> got it xD
<ogra_> the system underneath is still ubuntu, so the "many" applies there tooo
<ogra_> for native UI apps on the phone you will use QML and C++ (OML for the visible stuff an app has, C++ for all the backend stuff thats not visible to he user)
<ogra_> beyond that you can create HTML5 apps in HTML and javascript (note, not java)
<ogra_> which are portable to other systems like android etc
<isaias> ogra_: really nice to know :D
<isaias> im learning C++, would hate not being able to add stuff to ubuntu phone, lol
<isaias> keep up the great work! ^_^
<ogra_> we will :)
<isaias> I know this is off topic, so feel free to ignore the question, but does anyone know any good books on C++? or on Operating systems?
<isaias> by operating system, i mean Unix, terminal, etc
<XorA> isaias: anything by Oreilly
<ogra_> ++
<XorA> isaias: http://oreilly.com/
<XorA> easilly identified by the animal picture on the covers
<XorA> which makes me wonder where my In a Nutshell book actually went
<marvin24> I want to disable all non-armhf kernel builds for my kernel package
<marvin24> any hints how to do this?
<marvin24> (the right way (C) of course)
<XorA> donate all your non armhf hardware to me ;)
<ogra_> marvin24, i guess the #ubuntu-kernel channel is better suited
<ogra_> ask apw
<ogra_> oh, he's here too
<marvin24> and no answer from ubuntu-kernel last time I ask
<marvin24> apw: ^
<apw> marvin24, building it where and how
<ogra_> apw, PPA
<marvin24> yes, launchpad always start building the tegra kernel on i386/x86_64
<ogra_> apw, cyrrently it attempts all arches and indeed fails
<apw> clear out the flavours= lines in the rules.d/*.mk for the arches you arn't interested
<apw> if you have none of those, then it is likely only building nothing, ie the 'all' packages for that arch
<marvin24> apw: what mean delete all files there except armhf.mk
<apw> marvin24, no remove the flavour names from the flavours= lines in <arch>.mk for all other arches
<apw> and then it should build anything on those arches
<apw> you may still then need to change Architecture: all in your control.stub.in to prevent launchpad trying and not having anything to do on all the other arches
<apw> changing it to Architecture: armhf or whatever
<marvin24> apw: ok, will try - thanks!
<isaias> hey, I know there is a problem with the img, but would there happen to be an older img I could try out while this one gets fixed?
<Tassadar> isaias: not that I have working image, but what's the problem with it - it shows only black screen, right?
<Lirux> Tassadar, this happens to me to on nexus 7. is there any fix for that?
<Tassadar> I'm just making sure that I didn't break it. I'm sure it will be fixed soon, we just have to be patient
#ubuntu-arm 2013-02-16
 * Snark wonders about ubuntu on asus tf[37]00t
<isaias> good morning :)
<freeflying> wondering is there still a pre-installed image for omap4 in 13.04
<livingdaylight> Hi
<livingdaylight> Have HTC Desire HD, can I install ubuntu on it?
<smartboyhw> ogra_, ping
<ogra_> yes ?
<smartboyhw> ogra_, some time ago I think I heard that you guys wanted a testcase in the ISO QA Tracker right?
<smartboyhw> ogra_, I mean for Nexus 7
 * smartboyhw clearly has missed the most important info:P
<ogra_> yes i know what you mean, can we discuss that not on a weekend ?
<smartboyhw> ogra_, LOL sorry:P Just that I am reporting a bug so the testcase admins team can work on it. Sorry for disrupting your weekend:)
<ogra_> no worries, lets disucss it next week if also people that can add it are around in -release
<smartboyhw> ogra_, k
<smartboyhw> *ok
<Snark> is there a list of recent ARM devices with information on their support? I was wondering about asus tf300t and tf700t this morning, livingdaylight is wondering about htc desire hd...
<isaias> hello again
<Tassadar> isaias_: ping
<hrw> http://marcin.juszkiewicz.com.pl/2013/02/16/how-to-update-chrubuntu-12-04-to-ubuntu-13-04/ for those stuck with 12.04 on chromebook
<xnox> hrw: are you on ubuntu planet?
<hrw> yes
<xnox> ok.
<hrw> xnox: and it landed there as well
<hrw> time to bed
<scientes> hrw, nice
<scientes> i've been stuck as x doesn't come up with precise
<scientes> *with raring or quantal
<hrw> for me all works as it is in blog post
<hrw> I made no edits to rootfs other than those described (do not count installation of openssh-server to login remotely)
<dickmacinnis> is anyone else getting a black screen on boot into 13.04 on nexus7?
#ubuntu-arm 2013-02-17
<Tassadar> yes
<Tassadar> dickmacinnis: are you dual-booting it?
<dickmacinnis> I was, and having noticed that others doing so were getting this bug, I did a wipe and fresh install via the official installer. With the fresh install, I saw the plymouth splash for a little longer, but I get the same end result.
<Tassadar> the image is broken. It happens, this is not stable release after all. I'm sure it will be fixed soon.
<Tassadar> do you want some older working image?
<dickmacinnis> Tassadar: yes, that would be fantastic. I just got my nexus7 yesterday, and can't find an older build anywhere.
<Tassadar> https://www.dropbox.com/s/e8rw999fkcglie9/Ubuntu_13.04_01-30-13.img
<Tassadar> from somebody on XDA
<dickmacinnis> Tassadar: thanks so much! Downloading right now.
<Tassadar> well, thank you for assuring me that it's the image and not multirom)
<joao> hi, so I've just flashed my Nexus 7 using the latest image, however the screen goes black after "localhost login: [Powering wi-fi]". It's stuck for more than 30 minutes now. Any thoughts?
<Tassadar> [01:02] <Tassadar> the image is broken. It happens, this is not stable release after all. I'm sure it will be fixed soon.
<Tassadar> do you want some older working image?
<joao> Tassadar: sure i do, thanks
<Tassadar> https://www.dropbox.com/s/e8rw999fkcglie9/Ubuntu_13.04_01-30-13.img
<Tassadar> from someone on XDA, it's a bit old, so apt-get dist-upgrade will take long if you'll
<joao> ok thanks, i was following this: https://wiki.ubuntu.com/Nexus7/Installation
<joao> now i should do like on manual install?
<Tassadar> yeah
<Tassadar> this is the fastboot image which you would install in step 1 of manual installation
<Tassadar> *download
<joao> ok thanks, i'll give it a try
<joao> what bootimg should i use?
<Tassadar> hmm, you can use the one from daily build
<joao> thanks, i'll try
<joao> great, it's stuck at flashing bootimg -.-
<isaias> hello
<joao> hi
<isaias> how are things comming along with the new img? :)
<Tassadar> mornin'
<isaias> evenin'
<Tassadar> don't know, but I have old image if you wanna)
<joao> what's the english word for being almost 2 am?
<Tassadar> dunno, I used morning)
<isaias> morning is good xD
<isaias> its almost 10 here
<isaias> pm
<isaias> an old image would be amazing. i bought the nexus 7, and havent been able to use it, lol
<Tassadar> https://www.dropbox.com/s/e8rw999fkcglie9/Ubuntu_13.04_01-30-13.img
 * Tassadar hopes that dropbox account won't get banned because of too many downloads)
<joao> i'm trying to flash that one, im stuck for 10min at flashing bootimg tho
<Tassadar> it's stuck, just....reboot nexus and try again
<Tassadar> it shouldn't break anything, it's just boot image
<isaias> is this one boot or userdata?
<Tassadar> userdata
<isaias> thank you :D
<Tassadar> boot from current daily should/could work okay
<joao> retrying, i'm afraid to waste 300â¬ hence didnt reboot :P
<joao> ok, took 1 second now
<Tassadar> yeah, that's how it should be)
<isaias> i can just use the new boot, and the userdata you sent me, right?
<isaias> ok, lol
<joao> it worked :)
<isaias> will i need to learn a specific language to modify (add a usable program/app) for the tablet when the final product come out? or will it be more like PC where i can use whatever?
<isaias> what I mean is, with ubuntu phone, they're telling me I have to learn QML
<Tassadar> well, we still don't really know what the "final" product is in case of Nexus 7
<isaias> will I be able to run a compiler? lol
<Tassadar> yes
<Tassadar> well
<Tassadar> I have no idea
<Tassadar> now you can :D
<isaias> then I'm happy :)
<Tassadar> Ubuntu phone apps will be using c++ and QML
<joao> damn, keyboard doesn't show up lol and i still don't have my usb otg adapter
<Tassadar> joao: are in the "installation wizard"? try to reboot it
<isaias> i'm working on my C++, but they're telling me that for now, apps will only be in QML
<Tassadar> QML is the UI
<joao> yes, trying to put my name and stuff, i'll reboot
<Tassadar> it's more like "scripting language"
<Tassadar> you are not expected to say, render a web page in that language
<isaias> i never heard of QML. fairly new to programming, lol
<Tassadar> but, for example simple actions like "User toggles checkbox -> button gets enabled/disabled" should be in there
<isaias> ok
<Tassadar> it looks much better to me than Android and "Java", that's for sure)
<joao> isnt there a way to reboot while on the "installation wizard" other than "brute force" ?
<isaias> main reason I chose C++ is because I want to do more with my Ubuntu. If Ubuntu-Phone doesnt support apps in C++, it will be kind of dissapointing
<Tassadar> joao: I think not, because your username/password is not yet created, so you can't even log in to console
<joao> it will support C++ afaik
<joao> http://www.ubuntu.com/devices/phone/app-ecosystem
<Tassadar> I just spent whole day trying to write "driver" for USB ACM device using Android USB API, and it's still not working as I would image :/
<scientes> Tassadar, i believe people do android drier development on ubuntu and the like
<Tassadar> I'm sorry, what? ubuntu like channel #ubuntu?
<isaias> Tassadar: hey, if you're scared your dropbox will get deleted because of the downloads, feel free to give out mine
<isaias> Tassadar: https://www.dropbox.com/s/w06cl3llrgccarv/Ubuntu_13.04_01-30-13.img
<Tassadar> isaias: Um...it _might_ not be mine, it's somebody's from XDA
<isaias> ahh
<isaias> either way, you have 2 links, in case one gets deleted xD
<Tassadar> I should go to bed
<Tassadar> well, good night
<joao> gn8, better luck tomorrow :P
<isaias> i can dissconect my nexus7 while its flashing, right?
<joao> i did, nothing bad happened
<isaias> hey, how do i get the onboard keyboard working? im trying to connect to my router
<drizzy> click in the input box
<drizzy> a input box
<isaias> im tapping it, nothing is happenning, lol
<isaias> :(
<isaias> no onboard keyboard is comming up in any input boxes
<isaias> any help with this?
<isaias> i dont have a keybord with a usb that will plug into my nexus
<isaias> :/
<isaias> this keeps crashing
<ashes> i'm curious what you do with your ubuntu-arm machines
<ashes> i have one, and i don't know what to do with it
<ashes> i have another arm machine running as a NAS, so i don't need another
<ashes> i'm in a home environment
<ashes> i have a seagate goflex archlinux NAS. it's able to do what it can do. it's simple. i have a trim slice, which can do a tiny bit more, regardless of being a nvidia cpu. i would like to put the trim slice to use, somehow
<ashes> the goflex is owned. i can run buildroot on it, or cross-linuxfromscratch. it's owned
<ashes> the trimslice begs gpu drivers
<gildean> ashes: the tegra2-driver that's used on the ac100 works fine on the trimslice
<gildean> "fine"
<ashes> i have tried taloring video for the trim slice, and it still doesn't run well
<gildean> as well as nvidia's beta-drivers work
<ashes> it stops
<ashes> i thought it was an i/o problem, and it's something else
<ashes> it means i need a backend to recode stuff
<ashes> video plays, but really badly
<gildean> ashes: which drivers are you sporting?
<ashes> h264
<ashes> if you can give me a link to a video that should play well on a trim slice, and if it plays well, i will shut up about the hardware problems
<ashes> i will figure it out from there
<gildean> h264 is a video-codec, i was asking about which display-drivers are you using?
<gildean> the tegra2 has a hard time playing anything hd, so that's mainly out of the question
<ashes> x11, nvidia.
<ashes> in reality, i will never ever buy nvidia again, like ever. i thought i was finished 10 years ago, and today you will need to spike red hot spikes in me before i agree to this again
<ashes> i am trying to salvage this machine, and its not easy
<ashes> it does shit in 1/8th the time of my laptop
<ashes> so finding a use for it is hard
<ashes> uhm
<ashes> 100/8ths
<ashes> the gpu is the only useful part
<ashes> and it's not usefull
<ashes> nvidia has made me check over every single driver when i buy hardware, to make sure none of it is nvidia
<ashes> they have done the final nail
<ashes> i did this when i bought my laptop
<ashes> and for some reason when i bought my arm system i went retarded
<ashes> 'nvidia, sure, trust them to give me drivers!'
<ashes> or, not
<ashes> i have a machine i paid $250 for, th
<ashes> i have a machine i paid $250 for, with a nvidia cpu/gpu, and it's good for nothing to me
<ashes> it's not a NAS, not a XBMC, not a firewall
<ashes> it is good for nothing
<ashes> it's a paperweight
<ashes> linux doing nothing because nvidia is not cooperating
<ashes> never buy nvidia. do not believe their sales bullshits about supporting new hardware. buy ati
<ashes> never buy nvidia
<ashes> ever
<ashes> you will get fucked
<ogra_> can you stop the vendor bashing please ?
<ashes> i'm fustrated
<ogra_> yes, but its not appropriate for this channel
<ogra_> did you download and install the codecs from nvidia ? we only have the GL drivers in the archive, not the codecs
<ogra_> so while GL apps will be fine, for video playback you will need additional bits
<isaias> any news on the new img?
<mosasaur> debootstrap --arch armhf --foreign --verbose precise http://archive.ubuntu.com/ubuntu
<mosasaur> /usr/sbin/debootstrap: 382: cd: can't cd to http://archive.ubuntu.com
<mosasaur> where can I point debootstrap for an armhf?
<mosasaur> I need a distro with gcc >= 4.6
<boern> hey guys, i just had a problem i would like to share with you..  i installed ubuntu on my nexus 7 (https://wiki.ubuntu.com/Nexus7/Installation) i did in manually..  the part where you flash your userdata normally takes you 80 seconds.. on my computer it took 960 seconds.. i though i did something wrong but now its working..
<boern> it*
<isaias> boern: the new img is out?
<isaias> :o
<ogra_> mosasaur, its http://ports.ubuntu.com/ubuntu-ports
<ogra_> mosasaur, also i would install qemu-user=static and use qemu-debootstrap, thats way smarter for creating a chroot (and you can directly chroot into it after debootstrap is done)
<mosasaur> thanks ogra, but I still can't get it to work
<mosasaur> debootstrap --arch armhf --foreign --verbose precise http://ports.ubuntu.com/ubuntu-ports
<ogra_> erm
<ogra_> you are missing the target dir
<ogra_> debootstrap --arch armhf --foreign --verbose precise /path/to/chroot http://ports.ubuntu.com/ubuntu-ports
<ogra_> mosasaur, ^^
<mosasaur> it works!
 * mosasaur feels very stupid and happy now
<ogra_> but really, use qemu-debootstrap ... saves you the whole second debootstrap run (and you dont need --foreign)
<mosasaur> I'm kind of hacking this to work with ubuntu instead of debian: http://www.mayrhofer.eu.org/debian-on-android
<mosasaur> I had extract the build-arm-chroot script from an old lucid
<mosasaur> but that script is just a thin wrapper around debootstrap it seems
<ogra_> yeah, that became qemu-debootstrap
<mosasaur> thanks a lot ogra_ !
<ogra_> well, its a lot more, the qemu-user-static package establishes a binfmt handler
<ogra_> which qemu-debootstrap uses ... this way you can just chroot into the armhf chroot on an x86 machine
<mosasaur> I had to adapt it to make it think armhf is acceptable
<ogra_> you shouldnt need to
<mosasaur> but indeed I could just do it all by myself, the problem is this is all very new to me
<ogra_> wow, that howto is really using ancient stuff
<mosasaur> the script is so old it doesn't know armhf
<ogra_> yes, i know
 * ogra_ wrote that stuff years ago
<mosasaur> what that is your script :p
<ogra_> but also havent touched it in years, debian adopted it into qemu-user-static
<ogra_> no, build-arm-chroot was mine
<ogra_> and the whole qemu-arm-static stuff
<mosasaur> anyway it still works with a slight mod
<ogra_> right, the new way would be easier though :)
<ogra_> do you plan to have a full desktop install or just a basic environment
<mosasaur> I'm making an image to run in a loop device on my android machine
<mosasaur> the Android sdcard has a 4GB limit, becasue it's vfat
<ogra_> yes, but what do you plan to have inside that image ?
<ogra_> a desktop environment or just a basic commandline system
<mosasaur> I need a gcc >= 4.6 and an armhf kernel to compile rtlsdr
<ogra_> we provide a tarball for armhf with a basic but unconfigured cmdline system
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily/current/
<ogra_> just grab it there
<ogra_> its pretty much what you get with debootstrap
<ogra_> so you can just untar it into your mounted image
<mosasaur> OK thanks, but I was under the impression these are preconfigured for specific devices
<ogra_> nope, they are exactly not preconfigured so you can build images out of them ;)
<ogra_> thats the whole purpose of ubuntu-core
<mosasaur> right I see, that is much easier
<ogra_> http://www.omappedia.com/wiki/OMAP_Ubuntu_Core#Login_in_.22root.22_without_the_need_of_a_password
<ogra_> you might want ths though
<ogra_> (i dont think your howto works without unlocking root ... ubuntu locks it by default)
<mosasaur> I already had root by exploiting an exynos privilege escalation
<mosasaur> but then I installed cyanogenmod and now I have that yellow triangle
<ogra_> i'm talking about your ubuntu environemnt
<ogra_> not about the underlying android
<ogra_> you either need to set a root password or unlick the root account in the image you are building
<ogra_> *unlock
<mosasaur> I am setting a root password while I am still in a chroot on my ubuntu machine
<ogra_> ok
<isaias> ++..................................................................+.
<mosasaur> on the android machine I run it under a VNC
<ogra_> isaias, i fished out teh last known working nexus7 image from a backup  ... http://cdimage.ubuntu.com/daily-preinstalled/last-good-image/
<ogra_> isaias, it shoudl work with the manual install method described on the aiki
<ogra_> *wiki
<mosasaur> but I read about someone making an xserver.apk, could not make it work on my device though
<isaias> I just finished doing it :D
<isaias> thank you!
<ogra_> isaias, you mean you already tried that specific image ?
<isaias> just rebooted to see it works
<isaias> its flashing
 * ogra_ handt announced the url anywhere yet 
<isaias> o, wait
<isaias> its different
<isaias> i went to /current
<ogra_> which one do you use ?
<ogra_> ah
<isaias> it said it was uploaded today
<ogra_> thats likely exposing the same breakage
<isaias> oh
<isaias> ok
<ogra_> yes, i havent found the reason yet, but also havent tried the image from the 17th
<isaias> aww xD
<ogra_> so it would be good if you could let it move on
<isaias> well, I'll try it out :P
<ogra_> to report if its any different
<isaias> anything special you want me to do?
<ogra_> no, just leave it do its thing
<isaias> k
<ogra_> see if you get into the graphical installer after the splash screen or if it stays black
<isaias> ok
<isaias> i had tried an older img but it kept crashing. had to plug it in and wait for the "battery full" to show up to be able to turn it on
<ogra_> ah, yeah, battery should be charged when installing
<isaias> scared me a little when i saw the messed up screen lol
<isaias> battery was fully charged
<ogra_> the device seems to start behaving weird if it is below a certain value
<isaias> ahh
<ogra_> at least for installing ...
<isaias> The screen is black. I'll leave it for a few minutes to see is anything happens
<ogra_> yeah, the installer startup is very slow
<isaias> something should have happenedc by nos
<isaias> now*
<ogra_> yes
<ogra_> it shouldnt take more than 1-2min
<ogra_> i havent tested the "last-good-image" yet, but i think it should be fine
<isaias> website says it would take up to 20 min
<isaias> so I would be testing it?
 * ogra_ is on a slow connection ....
<ogra_> my download will still take 30min ... then i'll test it
<ogra_> if you can get it before, go ahead :)
<isaias> 5 min for me
<isaias> left, i mean
<isaias> lol\
<mosasaur> where can I find /ubuntu/dists/precise/main/binary-armhf/Packages ?
<mosasaur> I mean what do I put in my /etc/apt/sources.list
<ogra_> http://paste.ubuntu.com/1672758/
<mosasaur> thanks ogra that works for precise too
<isaias> waiting for my device to boot
 * ogra_ crosses fingers
<isaias> no boot logo yet
 * ogra_ is flashing
<Tassadar> good thing you're not sparkling yet)
<ogra_> haha
<isaias> back xD
<ogra_> front
<isaias> lol
<isaias> its still not doing anything. You sure it wont take 20min or so?
<isaias> like the website says xD
<ogra_> well, it should be busy unpacking the tarball
<isaias> ok
<ogra_> but it also tells you that it is
<isaias> not doing anything
<ogra_> "preparing the root filesystem, this will take several minutes ..."
<isaias> it said that, then it all went dark
<ogra_> thats the "last good" one ?
<isaias> yep
<ogra_> crap
<isaias> would it be ok to disconect it from my computer after i try it again?
<ogra_> sure
<isaias> while it says "preparing..."
<ogra_> yeah, doesnt do any harm
<isaias> k. wI have to go in about 5 min for an hr or so.
<isaias> but I'll be back. I'll try it again
<isaias> good luck!
<ogra_> thx
<isaias> ogra_: you get it working?
<redtape-renegade> I am seriously thinking about doing this :: http://chromeos-cr48.blogspot.com/2012/11/looking-for-acer-c7-chrubuntu-tester.html
<redtape-renegade> http://www.ebay.co.uk/itm/350716277246?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1438.l2649
<isaias> ogra_: i rebooted a few times and it seems to have booted up just fine this time
<redtape-renegade> isaias: GOOD for you  !! ||  \o/ ||
<isaias> i thought it did
<isaias> its stuck on the weird colors
<redtape-renegade> MMMmm.. not sure I can help .. I'm stuck sitting up-to 1am tonight to get this chromebook  ::::: http://www.ebay.co.uk/itm/350716277246?ssPageName=STRK:MEWAX:IT&_trksid=p3984.m1438.l2649
<k1l> !ot | redtape-renegade
<ubot2> redtape-renegade: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics (though our !guidelines apply there too). Thanks!
<k1l> oh wait, this isnt the main support channel :/ but atleast its not a ARM chromebook so its offtopic :)
<isaias> its working now. its installing
<isaias> ogra_: its working, after several reboots
#ubuntu-arm 2014-02-10
<hvn2> Hi, I've cross-compiled a vanilla kernel on Ubuntu 12.04 using make-kpkg for armhf and omap3. However, the installer on the target says the kernel is not omap architecture. How can I make sure the kernel is built for omap3, apart from configuring the kernel as such ? I already used --subarch=armhf and tried  --subarch=omap
<zacthespack> Hello, is there anyone about that could help me with an issue?
<zacthespack> this is the issue I am having http://askubuntu.com/questions/418991/arm-chroot-installing-xfce-fails-packages-named-different
<ogra_> zacthespack, that smells like you're mixing debian with ubuntu
<ogra_> (are you sure this is an ubuntu chroot at all ?)
<zacthespack> yes I built the rootfs myself
<ogra_> and your package db us up to date (i.e. you ran apt-get update before trying to install anything)
<zacthespack> indeed
<zacthespack> my sources.list has
<zacthespack> deb http://ports.ubuntu.com saucy main restricted universe
<zacthespack> deb-src http://ports.ubuntu.com saucy main restricted universe
<ogra_> try making http://ports.ubuntu.com to actually be http://ports.ubuntu.com/ubuntu-ports
<ogra_> and run apt-get update again
<hvn2> Hi ogra_, can you tell me if this is the right place about cross-compiling for armhf and omap ?
<ogra_> sure
<hvn2> OK ty
<hvn2> my problem is that I take a vanilla kernel, which I patched for xenomai...this goes fine. Then I configure the kernel for omap3 and cross-compile for armhf.
<hvn2> Then I install the kernel on the target, but the target says that the kernel is not an omap kernel
<zacthespack> oagr_ thanks it worked!
<zacthespack> ogra_ thanks it worked!
<hvn2> ogra_: do you have any clue what might be the cause of this ?
<ogra_> no, why dont you just follow the kernel cross building wiki ?
<ogra_> https://wiki.ubuntu.com/KernelTeam/ARMKernelCrossCompile ...
<hvn2> I did follow any kernel cross building wiki and info I could find
<ogra_> the kernel team has vanilla trees on kernel.ubuntu.com i belive ... and there are debs and source debs for these kernels too
<ogra_> #ubuntu-kernel should be able to help you further in that direction
<hvn2> ok, so you say that I should not take a kernel from kernel.org but from kernel.ubuntu.org...because of ?
<ogra_> oh, feel free to take any kernel you want ... it is just easier with a proper package dir
<ogra_> anyway, thats more #ubuntu-kernel than arm
<ogra_> the above wiki definitely works for cross building kernels out of the different trees and source packages i have used before
<hvn2> ah ok
<hvn2> does that work for omap specifics as well ?
<ogra_> the current trusty images use the ubuntu -generic kernel for omap (which should be something like 3.13 without any omap specific patches) ... so i would assume yes
<hvn2> do you know about precise images as well ?
<ogra_> precise didnt use generic kernels ... it had hacked up BSP ones iirc
<ogra_> but ask the kernel team
<hvn2> ok, ty
<ogra_> as for your initial question, i'm pretty sure the kernel version gets overridden during package build (thats a debian thing that ubuntu inherits from there)
<ogra_> i doubt make-kpkg uses that mechanism
<hvn2> does that mean I should or shouldn't use make-kpkg ?
<hvn2> I used make when I started, but I prefer to end up with a .deb package instead of just a uImage without uInitrd
#ubuntu-arm 2014-02-11
<hrw> http://marcin.juszkiewicz.com.pl/2014/02/11/it-is-10-years-of-linux-on-arm-for-me/
#ubuntu-arm 2014-02-13
<ice9> does ubuntu supports ARMv6?
<rbasak> ice9: no
<ice9> so if I want to make Ubuntu image to run on my Android phone that has ARMv6, how do I build it?
#ubuntu-arm 2015-02-09
<HiDeHo-U3> Hi all i have a ubuntu arm os here i am trying to get ubuntu studio repo working
<HiDeHo-U3> there is no ubuntustudio-dvd-live app in repo.  and not much info i can find online on how to set ubuntu studio up.
<infinity> HiDeHo-U3: apt-get install ubuntustudio-desktop might be a good start.
<infinity> HiDeHo-U3: The x86 DVDs install ubuntustudio-desktop ubuntustudio-audio ubuntustudio-font-meta ubuntustudio-graphics ubuntustudio-video ubuntustudio-publishing ubuntustudio-photography
<HiDeHo-U3> infinity: ubuntustudio-font-meta causes errors here. it gives a mesage saying not all dependances will be installed so it wont work ay
#ubuntu-arm 2015-02-10
<jimm223> so whats the deal with ubuntu and the raspberry pi 2
<k1l> so got the rpi2 a SoC that is not too old this time? (didnt follow the rpi2 hype so far)
<ogra_> k1l, yes, and there is a snappy port for it
<k1l> oh nice
<jimm223> is there a regular image or any instructions how to compile one?
<ogra_> no
<ogra_> but the general instructions apply :)
<ogra_> use debootstrap or qemu-debootstrap to create a rootfs ... set up your bootloader and kernel ... push rootfs chroot to SD card ... boot
<jimm223> ogra_: can you point me to where i can find some futher instructions
<ogra_> sudo apt-get install qemu-deboostrap ... sudo qemu-debootstrap --arch armhf trusty my-chroot ... cd my-chroot ... tar cJvf ../my-ubuntu-rootfs.tar.xz *
<ogra_> that creates you a rootfs ... beyond that you need to use the documentation for your board for bootloader setup etc
<jimm223> okay, thanks for your help you have been helpful and I now know what to google
#ubuntu-arm 2015-02-11
<blib> any ideas on how to fix this apt-get dist-upgrade problem -> http://paste.ubuntu.com/10177464/
#ubuntu-arm 2015-02-12
<danners> hey i am running ubuntu on an odroid u2. everytime i reboot i need to run ntpudate to get the correct time. is there a package that stores the current time on shutdown in a file and restores it on bootup? it doesnt have to be the correct time on reboot, i just want a continous time.
<ogra_> danners, by default ntpdate should be run every time a network device is brought up ... is the device not connected ?
<danners> ogra_: not always
<ogra_> well, there is no hwclock on the odroid ...
<ogra_> or rather ... no battery for it
<danners> i seem to have in the back of my head, that there is a debian package that does what i want: save the time to a file and restore it from that on reboot. but i cant find it
<ogra_> (i think i saw a /dev/rtc at least)
<danners> yeah it has no battery for it
<ogra_> we have a snippet in our initrd that sets the clock to the last mount time ...
<ogra_> (which will indeed be off but prevents you from jan 01 1970)
<ogra_> you just have to put "fixrtc" on your kernel cmdline to activate it
#ubuntu-arm 2015-02-15
<davanger> hello, is there an image for ARMv7 and 14.04 TLS?
<troldrik> ep
#ubuntu-arm 2017-02-15
<Simonious> how do I get unzip on my beaglebone?
#ubuntu-arm 2017-02-17
<pvl1> id
#ubuntu-arm 2018-02-13
<Zanthus> Hi, I've installed Ubuntu Core 16 on a Raspberry Pi 3 and I want to change the network settings.  Is it possible to re-run the set up program that runs on first use?
<Zanthus> Found it:  console-conf
#ubuntu-arm 2018-02-14
<igus> hello
<igus> ist jemand da ?
<igus> kann mir jemand evt. beidereinrichtung des omnikey 5422 helfen?
<igus> ist jemand da?
#ubuntu-arm 2020-02-11
<archetech> anybody got aarch64 cross compiler knowledge  for build linux from scratch ona rock64
<archetech> got ubu 18 on it now
<handsome_feng> Hi, ubuntu ARM team,Will ubuntu release ARM desktop version? and if Kylin want to release a ARM desktop image (for huawei hardware), how to archive this? Should we make it by myself or cooperate with ubuntu arm team? And can we released it through Ubuntu official channel? Thanks and sorry for my poor English!
