[11:06] <ogra> asac, so did you bring up your babbage already ?
[11:08] <asac> ogra: yes and no ;) ... default image boots ... karmic image doesnt get really far
[11:08] <asac> need to get serial adapter ;)
[11:09] <asac> but i think karmic image is not supposed to work?
[11:09] <ogra> it is
[11:09] <asac> yeah
[11:09] <ogra> and the others (i.e. JamieBennett, dyfet and plars ) use it
[11:09] <asac> hmm
[11:09] <asac> i get splash
[11:09] <ogra> and then ?
[11:10] <asac> in contrast to factory image the keyboard works
[11:10] <asac> but it doesnt get further ... getting IO errors
[11:10]  * ogra points to https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-une-casper-speedup
[11:10] <ogra> give it 5 min
[11:10] <JamieBennett> asac, works fine here
[11:10] <ogra> IO errors ?
[11:10] <asac> hmm. five minutes ;) ... i waited quite some time
[11:10] <JamieBennett> CF card problems?
[11:11] <ogra> how did you write the image to SD
[11:11] <asac> using instructions on wiki
[11:11] <asac> https://wiki.ubuntu.com/ARM/BabbageKarmicInstall
[11:11] <ogra> yeah, that should just work
[11:12]  * JamieBennett uses ImageWriter :)
[11:12] <ogra> which way did you use to write the image ?
[11:12] <asac> dd
[11:12] <ogra> imagewriter is essentially dd
[11:12] <JamieBennett> ogra: yes
[11:12] <JamieBennett> but prettier
[11:12] <asac> http://releases.ubuntu.com/9.10/ubuntu-9.10-desktop-armel+imx51.img
[11:12] <ogra> though it doesnt use bs=16M
[11:12] <ogra> no idea who added that
[11:12] <ogra> try witrhout the bs=16M
[11:13] <asac> checking
[11:13] <ogra> bs=1024 is the default in imagewriter
[11:13]  * ogra just checked the source
[11:14] <asac> ok using bs=1024
[11:15] <ogra> what kind of SD is that ? (brand/model)
[11:15] <asac> only thing the dealer had
[11:15] <ogra> former versions of the babbage (i.e. the B1) had probs with some cheapo SDs
[11:15] <asac> sandisk wasnt there ;)
[11:16] <asac> hmm
[11:16] <ogra> but that should be fixed since 2.0
[11:16] <asac> have to check when its not in my laptop
[11:16] <persia> asac: You might want to hunt up the specs on the card.  I've found that using bs=${NATIVE_BLOCKSIZE} causes faster and more accurate writes.
[11:16] <asac> i think its Trans* something
[11:16] <persia> Transcend probably
[11:16] <ogra> transcend
[11:16] <asac> yeah
[11:16] <ogra> bah, persia beats me :P
[11:16] <asac> sounds right
[11:17]  * persia just happened to have a transchend box at eye-level
[11:17]  * ogra doesnt think he has transcend around to test
[11:20] <asac> ok at least i dont see any I/O error atm
[11:21] <asac> it says "writing IMID and MAP to secure the partition"
[11:21] <asac> UMID
[11:22] <asac> ogra: does that sound familiar?
[11:22] <asac> JamieBennett: ?
[11:22] <JamieBennett> asac: you have a serial adapter now?
[11:23] <JamieBennett> or is that on the screen
[11:23] <JamieBennett> ?
[11:23] <asac> screen
[11:23] <asac> no serial adapter
[11:23] <asac> need to figure that during lunch i guess ;)
[11:23] <JamieBennett> That should take around 90 seconds then it continues to boot
[11:23] <asac> now i have like udevd.*worker.*failed...
[11:24] <JamieBennett> That shouldn't happen ;)
[11:24] <ogra> thats a kernel message
[11:24] <asac> yeah. seems it cannot handle the partitions somehow
[11:24] <ogra> so your kernel boots :)
[11:24] <ogra> no
[11:24] <ogra> that partition thing belongs to an encryption device in the SoC
[11:24] <ogra> just ignore it, we dont use that device
[11:24] <ogra> just be patient :)
[11:25]  * asac patient ;)
[11:25] <asac> ok if this is right there is definitly room for improving the image experience ;)
[11:26]  * ogra had patches to get that noisy messages away 
[11:26] <asac> no i got "stadin: I/O error"
[11:26] <ogra> but the kernel team refused
[11:26] <asac> stdin: I/O error
[11:26] <asac> not sure if that is missing serial
[11:27] <ogra> freescale likes to use KERN_CRIT where it only needs KERN_INFO in many areas
[11:27] <asac> with my previous dd'ed image i only got those
[11:27] <JamieBennett> Have you tried another CF card to make sure its not that? Most of the problems seem to stem from some breakage there.
[11:27] <ogra> strange
[11:27] <asac> whats the md5sum of the .img file?
[11:28] <ogra> 297875d2a7531824a0fb08f241d33e8
[11:28] <asac> 297875d2a7531824a0fb08f241d33e85  ubuntu-9.10-desktop-armel+imx51.img
[11:28] <ogra> http://releases.ubuntu.com/9.10/MD5SUMS
[11:28] <asac> hmm seems right
[11:28] <ogra> whoops paste error
[11:29] <asac> anyone uses this without a serial console attached ;)?
[11:29] <asac> ok got another SD out of the bag from same brand though ;)
[11:30] <ogra> i never use a serial console if i dont have to
[11:30] <asac> the other option would be to kill the windows CE sandisk thing that was delivered ;)
[11:30] <ogra> and i only have to when i create new bootloader setups
[11:30] <ogra> windows CE ?
[11:30] <asac> yes
[11:30] <ogra> ugh
[11:30] <ogra> well, dd it off the SD
[11:30] <asac> two SD things where there: linux ... and windows CE
[11:30] <asac> hey... there even is a license ;)
[11:30] <ogra> and overwrite the SD then
[11:31] <ogra> you can always dd it back
[11:31] <asac> yeah
[11:31] <ogra> and order some sandisk cards ;)
[11:31] <asac> if thats the reason
[11:31] <ogra> you dont have a mediamarkt around in hamburg ?
[11:31] <asac> i have
[11:31] <ogra> they usually have multiple brands
[11:31] <asac> also saturn ;)
[11:32] <ogra> they too
[11:32] <asac> do they have usb to serial adapters ;)?
[11:32] <ogra> just buy three different ones
[11:32] <asac> hehe
[11:32] <ogra> sure
[11:32] <asac> sure ... i wouldnt say that for saturn
[11:32] <asac> they really have close to nothing
[11:32] <asac> nothing == everything that is too low level for main stream customer is missing
[11:33] <ogra> wow, the kassel saturn seems to be better then
[11:33] <persia> asac: That's just a call to change the needs of the "main stream consumer" :)
[11:34] <ogra> heh
[11:34] <ogra> yeah, just buy 10000 SD cards and you will change them
[11:35] <persia> Or start a local digital photo group for students, and get them to buy cards (this costs a few hours a week, rather than money)
[11:36] <ogra> you mean saturn would give away the cards for free to students ?
[11:36]  * ogra wonders how japan does business these days *g*
[11:36] <persia> No, but the students would pay rather than the instigator.
[11:36] <ogra> ah
[11:36] <asac> hah
[11:36] <asac> the other SD card worked ;)
[11:37] <asac> ubuntu X is starting ;)
[11:37] <persia> Saturn *might* give away cards, if it was part of some special program: I don't know enough about German tax provisions.
[11:37] <persia> \o/
[11:37] <asac> saturn is a rip-of-company ... say that they sell stuff cheap, but then you see the cheapest wireless router is 60 EUR
[11:37] <asac> while i get one at my dealer of same brand for 39 EUR
[11:37] <ogra> yeah
[11:38] <ogra> asac, congrats !
[11:38] <ogra> asac, install should take up to 1h
[11:38] <ogra> depending on the speed of your USB device
[11:39] <JamieBennett> (or more I have found)
[11:39]  * ogra takes a break
[11:58] <asac> hmm found out that the image kernel doesnt like my usb mass storage thing
[11:59] <asac> on x86 is fine with karmic kernel
[16:24] <asac> dmart: you said initially you have some ideas about the mksquashfs issue? current bt is: http://paste.ubuntu.com/337345/
[16:36] <asac> dmart: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3
[16:39] <asac> dmart: so you need to download the .deb files and force install them because the codec package (just something dloaded) isnt there for chromium
[16:40] <asac> of course all depends but chromium...-ffmpeg should get installed ;)
[16:41] <ogra> did you build that yesterday ?
[16:42] <asac> right
[16:42] <asac> let me check if that worked ;)
[16:42] <asac> nope. failied to build
[16:42] <asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1384064
[16:43] <asac> worked everywhere else, but arm as it seems
[16:43] <asac> ogra: is that the same error we get on ffmpeg in archive?
[16:43] <asac> fno-signed-zeros        -c -o libavformat/oggparseogm.o libavformat/oggparseogm.c
[16:43] <asac> In file included from libavformat/oggparseogm.c:27:
[16:43] <asac> ./libavcodec/get_bits.h:93:2: error: invalid preprocessing directive #warn
[16:43] <asac> hmm
[16:45] <ogra> to be honest i havent looked at ffmprg yet
[16:45] <ogra> *ffmpeg
[16:45] <ogra> post A1 stuff :)
[16:45] <asac> sure
[16:46] <asac> ogra: i think from the start of the call it felt like dmart had an idea on the mksquashfs thing ... lets wait what he says ;)
[16:46] <ogra> yeah
[16:46] <asac> ogra: upgrading karmic image yields a Read-only file system error
[16:47] <asac> when flashing kernel
[16:47] <asac> is that known?
[16:47] <asac> is mounted rw from what i can see
[16:47] <ogra> upgrading to what ?
[16:47] <asac> ogra: just upgrading to karmic-security/-updates
[16:47] <ogra> just security fixes ?
[16:47] <asac> yes
[16:47] <dmart> I have no particular idea on mksquashfs yet, but I'd be intrested in reproducing the bug if you can give me a test case
[16:47] <ogra> dmart, you have a pegatron nettop, right ?
[16:48] <asac> dmart: http://paste.ubuntu.com/337345/ thats the backtrace without symbols
[16:48] <ogra> dmart, just create a lucid chroot ... chroot into it and run mksquashfs on any dir you like
[16:48] <ogra> it will fail with SIGILL
[16:48] <asac> in some mutex stuff. though i doubt that pthread mutex can be broken completely
[16:49] <asac> but ... we can something similar for dchroot on the porter box which is also a pegatron afaik
[16:49] <asac> but not a sigill ;)
[16:49] <asac> dchroot -c lucid
[16:49] <asac> dchroot: pthread_mutex_lock.c:87: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
[16:49] <asac> Aborted
[16:51] <ogra> is your call over ?
[16:51] <asac> yes
[16:54] <dmart> asac, can you throw me a link to the Chromium build and logs?
[16:54] <asac> dmart: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+packages
[16:54] <asac> dmart: you can access the build logs there
[16:54] <asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1377663
[16:54] <asac> dmart: ^^
[16:55] <asac> dmart: the .debs are on the +packages page
[16:55] <asac> just the unfold the topmost build
[16:55] <dmart> Oh, right.  "mozilla" confused me ;)
[16:55] <asac> sorry
[16:55] <asac> was the only place i had spare that has native ppa capabilities ;)
[16:55] <asac> will get a better place
[16:56] <dmart> Cheers
[17:03] <asac> ogra: where is this "Flashing kernel..." done?
[17:03] <asac> FIS create failed.
[17:03] <ogra> create ?
[17:03] <ogra> what are you doing there ?
[17:04] <asac> triggers update-initramfs
[17:04] <asac> ogra: i dist-upgraded ... kernel wants to update initramfs etc.
[17:04] <ogra> update-initramfs calls flash-kernel
[17:04] <asac> then it says "flashing kernel"
[17:04] <asac> yeah
[17:04] <asac> i want to add debug statement to see which device it tries to write to
[17:04] <asac> but found it in triggers now
[17:04] <ogra> and flash-kernel replaces the initramfs in the existing fis
[17:04] <ogra> the device is defined in /etc/flash-kernel.conf
[17:05] <ogra> as well as the offset and lenght
[17:05] <asac> hmm its wrong
[17:05] <asac> i still have the sd card with installer in the first slot
[17:05] <asac> is that wrong?
[17:05] <asac> the install SD card didnt boot on its own
[17:05] <ogra> the SD turns into a boot floppy
[17:05] <ogra> after install
[17:06] <dmart> asac, ogra: I tried running mksquashfs /etc etc.squash --- didn't crash for me.  Do I need a heavier test?
[17:06] <ogra> it needs to stay where it was when you installed
[17:06] <asac> dmart: it only happens on pegatron lucid
[17:06] <asac> are you trying that?
[17:06] <asac> afaik it doesnt happen on babbage etc.
[17:06] <asac> ogra: right. so the flash-kernel.conf is wrong ... unless thats the define it is supposed to be flashed to
[17:06] <ogra> dmart, you need a lucid chroot and be chrooted and do all that on a nettop
[17:06] <asac> s/define/device/
[17:06] <ogra> asac, what does it contain ?
[17:07] <asac> it contains mmm.*0 ... but the actual SD card the main install is on is mm.*1
[17:07] <ogra> fis_dev=/dev/mmcblk0
[17:07] <ogra> fis_offset_hex=0x40000
[17:07] <ogra> fis_size_hex="0x1F000"
[17:07] <asac> yes thats what i have
[17:07] <ogra> thats the default
[17:07] <dmart> ogra, I'm doing that except in a Babbage2.0 board...  I'll try one of the nettops.
[17:07] <asac> but the actual install is on mmcblk1
[17:07] <asac> blk0 is the boot floppy thing ... which is read-only as it seems
[17:07] <ogra> asac, not your bootloader
[17:07] <asac> yeah
[17:07] <asac> so 0 is correct i guess
[17:08] <asac> wonder if all is lost now ;)
[17:08] <ogra> yes
[17:08] <ogra> no
[17:08] <ogra> it just doesnt use the new initramfs
[17:08] <ogra> did you lock the card physically ?
[17:08] <asac> right. thats why i want to shutdown now ... to check
[17:08] <asac> or is it safe to remove it while running ;)?
[17:09] <ogra> you can remove the "bootfloppy" any time you dont boot or run flash-kernel
[17:09] <asac> oh ok
[17:09]  * ogra needs to go for dinner ...
[17:09] <ogra> back soon
[17:09] <asac> hmm removing and adding worked
[17:10] <asac> odd
[17:10] <asac> let me try the trigger again
[17:10] <asac> ok cool
[17:10] <asac> the issue just flew away ;)
[17:10]  * asac reboots and hopes that the mass storage thing is fixed in latest kernel
[17:29] <dmart> asac, ogra: OK, I see the mksquashfs bug now.  Weeeird, I wonder what's different from the other platforms :O
[17:46] <asac> dmart: how sure are we that the mutex stuff in libc is correctly ported?
[17:46] <asac> i couldnt even find the arm specific code for that on quick glance ... but then i looked in redhat libc - which isnt what we use anyway
[17:50] <asac> hmm ... i constantly get complains about expired password
[18:39] <dmart> ogra, lool: ping
[18:40] <ogra> dmart, yup
[18:40] <dmart> Hi there... looks like I may have some info on the mksquashfs problem
[18:40] <ogra> ah, cool
[18:41] <dmart> mksquashfs contains a misaligned multi-register store instruction
[18:41] <ogra> misaligned in which way ?
[18:41] <ogra> i mean it works with the right kernel
[18:42] <dmart> STM with base register not a multiple of 4 (which might itself be due to a bug)
[18:42] <ogra> hmm
[18:42] <dmart> The kernel traps and emulates certain kinds of misaligned memory access, but the emulation for Thumb is not complete in 2.6.28
[18:42] <ogra> i find it significant that it only happens with the pegatron kernel
[18:43] <ogra> ah
[18:43] <dmart> So for "proper" karmic, it works
[18:43] <ogra> right
[18:43] <dmart> I think NCommander's error in GCC may have been similar
[18:43] <ogra> well, he used a karmic kernel iirc
[18:43] <ogra> but lucid userspace
[18:44] <ojn> Why is it generated in the first place though, the toolchain should avoid it if it can right?
[18:44] <ojn> (misaligned stores, that is)
[18:45] <dmart> Yeah, we'd have to check what NCommander was doing.
[18:46] <dmart> The compiler should not generate misaligned stores, so either it's a compiler code gen bug, or a pointer is getting corrupted due to a C bug
[18:46] <ogra> ojn, the issue is with a 2.6.28 kernel that was compiled for ARMv5 and userspace tools that are v7, the userspce toold for squashfs are very closely connected to the kernel module
[18:47] <ojn> ogra: Right, but like dmart says gcc should avoid operations with performance penalties such as trapped and emulated loads/stores.
[18:47] <ogra> yeah, iondeed
[18:47] <dmart> The SIGILL goes away with -O0
[18:48] <ogra> ah
[18:48] <ogra> good pointer
[18:49] <asac> cool
[18:49] <dmart> When you do something like int *p; *p = x; GCC knows ints are aligned and so can assume that p is properly aligned, but if p gets corrupted, this assumption may break
[18:49] <ogra> yeah
[19:37] <asac> ogra: is the hardware clock supposed to work?
[19:37] <asac> for bbg?
[19:37] <ogra> yes
[19:37] <asac> seems mine always goes back to 1970 ... which then causes
[19:37] <asac> password for auto login to expire
[19:37] <ogra> note that the battery needs about 8h
[19:37] <asac> and autologin breaking
[19:37] <asac> ah
[19:38] <asac> hmm
[19:38] <ogra> wait until tomorrow, if it still doesnt work thats a 3.0 issue
[19:38] <asac> kk
[19:38] <ogra> we had issues on 2.5 but we solved them#
[19:40] <asac> we solved them?
[19:40] <asac> so its not battery related?
[19:40] <asac> hmm
[19:40] <asac> i remember something sourrounding hwclock by scott
[19:40] <ogra> there were battery related and non battery related issues
[19:41] <asac> he basically broke my laptop to always bail out when it got a power off shutdown
[19:41] <ogra> the battery related ones pointed out that you need to run the board for 8h first
[19:41] <ogra> we solved the non battery related ones though
[19:41] <asac> ok. so really running or just with power plugged in?
[19:41] <ogra> its the kernel, not the hwclock userspce proggy
[19:42] <ogra> it can well be that the 3.0 hwclock driver isnt fully functional
[19:42] <asac> why do we ask for password renewal at all?
[19:42] <ogra> since we didnt have 3.0 boards to even test
[19:42] <asac> how can i turn that off for now? is that a gdm config?
[19:42] <asac> i didnt even change the clock. but still it resets to time=0 all the time
[19:42] <asac> and logging in becomes highly painful ;)
[19:42] <ogra> how do you restart ?
[19:42] <asac> even sudo
[19:43] <ogra> do you power off the board completely ?
[19:43] <asac> this time i restarted as pusing the installer button
[19:43] <asac> previously i also powered off completely
[19:43] <ogra> and are you sure the clock is at 1970 ?
[19:43] <asac> yes. 1st jan 1970
[19:43] <ogra> we had an issue where the board set the clock to something like 1939 ...
[19:43] <asac> 2:38am now
[19:43] <asac> (probably 1:38 sincei started it)
[19:43] <ogra> which nohting could cope with (pre epoch)
[19:43] <asac> hmm
[19:44] <asac> let me check on terminal. i only look at gnome clock atm
[19:44] <JamieBennett> ogra: it had problems with passwords too
[19:44] <asac> yes its 1st jan 1970
[19:44] <asac> and gets reset on reboot
[19:44] <JamieBennett> yup, sounds right
[19:44] <asac> so not even full power cycle
[19:44] <asac> is needed
[19:44] <ogra> one thing to make sure the clock is right is to use ethernet :)
[19:44] <asac> JamieBennett: ogra says it needs to be 8h power on
[19:44] <ogra> ntpdate runs on ifup
[19:44] <asac> though i cannot see how a quick power off needs a full 8h
[19:44] <asac> ;)
[19:45] <asac> its just for a minute or two off
[19:45] <ogra> but the battery doent have the needed voltage yet
[19:45] <asac> hmm. i didnt brin gup network for install this time
[19:45] <JamieBennett> asac: mine has been plugged in for more than 8hrs, whats the betting it keeps its time?
[19:45] <ogra> it needs to be at 2.6V or some such
[19:45] <asac> JamieBennett: my guess is that it will get reset ;)
[19:45] <JamieBennett> :)
[19:45] <asac> ogra might want to bet against ;)
[19:46] <ogra> well, in any case ntpdate fixes it ... so ethernet on boot helps a lot
[19:46] <JamieBennett> or just set the time ;)
[19:46] <ogra> no, i wouldnt bet on anything for a board i have never seen :)
[19:46]  * JamieBennett goes to check
[19:46] <ogra> i can only talk about B2.5
[19:46] <asac> the password is too simple thing is also just annoying ;)
[19:46] <asac> ogra: you saw a pic ;)
[19:46] <ogra> and i know we had massive issues with the hwclock driver during karmic ... but for the 2.5 they were solved
[19:47] <ogra> asac, there was no arrow pointing to the RTC chip on it !
[19:47] <ogra> how am i supposed to know it works without that !
[19:48]  * ogra needs arrows on pics
[19:48] <asac> its super annoying
[19:48] <asac> i have to change password everytime i run sudo
[19:48] <ogra> plug in ethernet
[19:49] <asac> i am online ;)
[19:49] <asac> oh right
[19:49] <asac> thats the reason why
[19:49] <asac> i just got beamed to present ;)
[19:49] <asac> how can i disable this shitty password expiry feature ;)?
[19:49]  * asac checks passwd
[19:49] <ogra> its a bug in shadow
[19:50] <ogra> and i'm sure it was fixed once so it doesnt ask for passwords if it recognizes that timestamp
[19:50] <asac> its a bug that we have it enabled at all?
[19:50] <ogra> probably the patch got lost
[19:50] <ogra> yes imho
[19:50] <ogra> talk to colin, i think he applied the patch back sometime between hardy and jaunty
[19:51] <ogra> (it was my bug actually, but i didnt do the fix)
[19:51] <asac> lets see if setting --maxdays=0 helps
[19:53] <ogra> just make sure to have the ethernet cable plugged in on boot :)
[19:54] <asac> hmm
[19:54] <asac> let me setup nm to startup wifi on boot
[19:54] <asac> eth is just too spartanic ;)
[19:55] <ogra> heh
[19:55] <ogra> its reliable ...
[19:55] <ogra> no microwaves can interfere
[20:28] <asac> my microwave fried itself a year ago ... never got a new one ;)
[20:29] <kblin> but how do you melt chocolate then?
[20:48] <fta> bain-marie
[20:48] <fta> asac, did you copy the codecs just yet?
[20:53] <asac> fta: not yet. shall i?
[20:53] <asac> last time i looked they were 15h old
[20:54] <fta> that's ok, it's the one
[20:54] <asac> not sure if those are the bits i should give a spin
[20:54]  * asac checks
[20:55] <asac> 18h
[20:55] <asac> fta:  chromium-codecs-ffmpeg - 0.5+svn20091208r34028-0ubuntu1~ucd1
[20:55] <asac> please confirm so i dont waste built time ;)
[20:55] <fta> yes, correct
[20:56] <asac> ok let me copy existing binaries so it doesnt steal amd64 time
[20:56] <asac> ok copied
[20:56] <asac> and failed to copy binaries ;)
[20:57] <asac> hmmm ... instantly got a buildd
[20:57] <asac> odd scheduling
[20:57] <asac> https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+build/1386748
[21:38] <asac> dyfet: did you manage to get the strace and backtrace for chromium?
[21:38] <asac> would be really helpful ;)
[21:44] <asac> fta: no luck: http://launchpadlibrarian.net/36600814/buildlog_ubuntu-lucid-armel.chromium-codecs-ffmpeg_0.5%2Bsvn20091208r34028-0ubuntu1~ucd1_FAILEDTOBUILD.txt.gz
[22:04] <fta> asac, hm, grr, thanks, will have a look
[22:05] <fta> fighting to setup a beta channel ppa right now
[22:12] <dyfet> asac: it died in the strace, somewhere on a poll, just froze, long before any window opened, so it did not seem to go through the actual crash
[22:13] <dyfet> but I can send you that file right now
[22:15] <asac> plese not in my email ;)
[22:15] <asac> fta: i can fix it by adding -fPIC
[22:15] <asac> just tried
[22:15] <asac> by accing $(PIC) to CFLAGS in common.mak actually
[22:15] <asac> by adding
[22:15] <dyfet> it wasnt that long before strace...stopped...but if you have a new build, I could try that right now
[22:16] <asac> not sure if that would break anything somewhere ese
[22:16] <asac> dyfet: we have a lucid build. have you been trying that?
[22:16] <asac> dyfet: without strace ... do you see it start?
[22:16] <asac> dyfet: i assume you directed the strace output in a file?
[22:16] <dyfet> no on karmic.  Without strace, it starts, opens the main window, then has the pure virtual function call error and dies
[22:17] <dyfet> with strace, it just "stops" on a poll call it cannot seem to print out completely...
[22:17] <fta> asac, with the sumo change, i will no longer use the upstream build system (autoconf) but use the gyp file provided by chromium, so it has their own optimizations
[22:18] <asac> hmm
[22:18] <asac> fta: when is sumo change?
[22:19] <fta> asac, not today
[22:19] <asac> close, far ?
[22:26] <fta> not much, i have http://codereview.chromium.org/463050/show and i need http://code.google.com/p/gyp/issues/detail?id=119
[22:27] <fta> the 1st just landed, the 2nd is in progress
[23:09] <asac> fta: also: libavcodec/get_bits.h:93:2: warning: #warning TODO - secure this against read overrun
[23:09] <asac> libavcodec/aac.c: In function 'aac_decode_frame':
[23:09] <asac> libavcodec/aac.c:1634: error: 'GetBitContext' has no member named 'index'
[23:10] <asac> after fPIC
[23:10] <asac> that seems to be some code path that is usually not used ... :/
[23:10] <asac> guess the gyp thing might help here
[23:10] <fta> the TODO is from a patch
[23:10] <asac> yeah
[23:10] <asac> that patch is probably bogus
[23:10] <asac> where did you get that from?
[23:11] <asac> hmm which patch ;)
[23:11] <asac> i thought i found it at some point. now i dont see it
[23:12] <asac> ./patches/ugly/17_get_bits_overrun.patch
[23:12] <asac> dont see that this patch introduces that issue
[23:12] <asac> its really that ALT_BITSTREAM_READER
[23:13] <asac> is probably set usually
[23:13] <asac> but here we have some other reader
[23:14] <asac> ah ... so my patch about right
[23:14] <asac> they do it for other ->index refereces too
[23:17] <asac> dyfet: so did you direct the output of strace to a file rather than to stdout/err?
[23:22] <dyfet> Yes
[23:23] <asac> ok and that stalled still?
[23:23] <dyfet> Yes
[23:23] <asac> hmm. maybe try just strace -eopen -f ...
[23:23] <asac> that doesnt dump that many data
[23:23] <asac> and the gdb/bt ?
[23:24] <asac> also to no success?
[23:24] <asac> dyfet: ?
[23:24] <dyfet> that I can still do also
[23:24] <dyfet> I thought you had asked me not too :)
[23:25] <asac> no. i wanted strace first ;)
[23:25] <asac> but since that failed we reach for the other straw ;)
[23:25] <asac> anyway
[23:26] <asac> dyfet: we want to understand whats going on ... sudo apt-get install -f ... what does that suggest you?
[23:26] <asac> only complaining aobut the ffmpeg things missing?
[23:27] <dyfet> Yes.  They were the chromium version of ffmpeg it was complaining about
[23:27] <asac> only that?
[23:27] <asac> sure you have everything else?
[23:28] <dyfet> about to check
[23:29] <dyfet>   Package chromium-codecs-ffmpeg is not installed.
[23:29] <dyfet>   Package chromium-codecs-ffmpeg-nonfree is not installed.
[23:31] <dyfet> and strace so far is still not being very friendly...
[23:34] <dyfet> I can run it but if I go anywhere, I get a sad face and a pure virtual method called.  But if I use strace, it never even comes up to an initial screen...
[23:34] <dyfet> I am adding dbg package now
[23:37] <dyfet> asac: its taking its time coming up with gdb...
[23:38] <asac> yeah
[23:45] <dyfet> asac: https://pastebin.canonical.com/25504/
[23:45] <asac> S32A_Opaque_BlitRow32_neon
[23:45] <asac> neon
[23:45] <asac> doesnt work i guess
[23:45] <asac> fta: ^^ ... does the armv7 switch enable neon?
[23:46] <dyfet> nope. doesnt seem to...
[23:46] <asac> looked in chromium sure?
[23:47] <dyfet> I did not snag your sources at the time, only the debs...
[23:47] <rcn-ee> asac, add -mfpu=neon
[23:49] <asac> whats the current default?
[23:49] <asac> hmm seems that is bogus i guess
[23:50] <fta> armv7==1 sets the following:
[23:50] <fta>                       '-march=armv7-a',
[23:50] <fta>                       '-mtune=cortex-a8',
[23:50] <fta>                       '-mfpu=neon',
[23:50] <fta>                       '-mfloat-abi=softfp',
[23:50] <asac> yes. i think =neon is bad
[23:51] <asac> fta: i see that ffmpeg in chromium source already has a gyp
[23:51] <asac> so its already done there?
[23:51] <fta> yes
[23:52] <asac> ok .... so we need to remove the =neon somewhere
[23:52] <asac> seems there is no way around a quick and dirty patch
[23:52] <asac> well there is, but not quickly :)
[23:52] <asac> -march=armv7-a -mthumb -mfpu=vfpv3-d16 -mfloat-abi=softfp -Wa,-mimplicit-it=thumb
[23:52] <fta> build/common.gypi but you might want to file a bug and explain why it's bad, i know nothing about =neon
[23:52] <asac> thats what we use by default
[23:53] <fta> -Wa,-mimplicit-it=thumb is set when arm_thumb == 1
[23:53] <asac> neon is not available on all armv7
[23:53] <fta> oh
[23:53] <asac> i actually think we just want what we have set by default
[23:54] <asac> maybe we should just build without armv7
[23:54] <asac> let me kill the build and try that  over night
[23:54] <asac> yay
[23:54] <asac> ffmpeg builds now
[23:55] <asac> though there seem to be switches somewhere that made it fail without armv7
[23:55] <asac> imo the CFLAGS should get decoupled from that switch somehow
[23:59] <asac> fta: so i added CFLAGS = -fPIC -DPIC to rules (for armel most likely - not sure why there only)
[23:59] <asac> and i added this patch:
[23:59] <asac> patches/ugly/51_get_aac_build_for_arm.patch:
[23:59] <asac> http://pastebin.com/f65476f12