[01:38] <asac> ok lucid build still snaps
[01:38] <asac> :/
[01:39] <asac> "pure virtual method called" still
[01:40] <asac> [6134:6134:3368164813:ERROR:/home/asac/chromium-browser-4.0.263.0~svn20091203r33682/build-tree/src/chrome/browser/renderer_host/render_sandbox_host_linux.cc(288)] Could not get pid
[01:40] <asac> saw that when running in gdm
[01:40] <asac> fta: ^
[01:42] <fta> asac, hm, try with --disable-sandbox
[01:43] <asac> kk
[01:45] <asac> i thnk i have probs with /dev
[01:45] <asac> let me first sort that out
[01:57] <asac> fta: can you run chromium in a chroot well?
[01:58] <fta> never tried
[01:58] <fta> not sure the sandbox will work
[01:59] <fta> it does its own chroot
[03:06] <shenki> awong: ffmpeg builds for arm as of a week or so ago. there was a small preprocessor issue that landed a few days ago, since then it builds from tot
[10:02] <hansdampf> i got a little problem with my beagle boar; i put a ubuntu 9.10 on my board and now i got the following problem: if i plug in a keyboard i get the following error: "hub 1-0:1.0 unable to enumerate USB device on port 2", if i plug in any other device, nothing happens
[10:02] <hansdampf> is this known... or has anybody experiences with this
[10:34] <lool> hansdampf: This is an issue with your kernel; we don't provide beagleboard/OMAP kernels, I would check with whoever provided your kernel
[11:44] <ogra_> nice, seems thumb2 already saves us 20MB in image size
[11:52] <amitk> ogra_: but does the image work? ;)
[11:53] <ogra_> amitk, imx51 boots (which is my main target for an A1 image) but seems to have issues to install on B3.0 (test on 2.5 is just running) ... dove has issues
[11:54] <amitk> niceeee
[11:54] <ogra_> yeah
[13:17] <lool> hey folks
[13:17] <lool> Just talked to a French Freescale guy
[13:17] <lool> who told me that thumb 2 is mostly slower than regular arm code, I was aware the diffence was so significant
[13:18] <lool> Let's hope that the space savings in cache make up for it
[13:18] <lool> and he also told me that thumb 2 was bugged on TO2
[13:18] <lool> So it might cause faultsevery 4 Kb or something he didn't have any detail on
[13:18] <lool> => we should check for erratas from FSL on thumb 2 issues -- it might break random programs
[13:18] <ogra> lool, dusing image install i cant see *any* difference in speed on my bababge with lucid
[13:18] <ogra> *during
[13:19] <ogra> i was actually expecting to see a speedup
[13:19] <ogra> but its as slow/fast as karmic was
[13:25] <armin76> yey
[13:26] <lool> ogra: Ok
[13:27] <ogra> lool, we have lucid babbage images, feel free to take a loo ;)
[13:27] <ogra> and a look as well :P
[13:28] <lool> I don't have any babbage 2.x
[13:28] <lool> only 1
[13:28] <ogra> ah, yeah, you sent them to jamie
[13:29] <lool> and to asac
[13:29] <lool> Well I left the 2.0 in london and think it was sent to asac
[13:29] <ogra> right
[13:29] <ogra> no, he has a 3.0
[13:29] <lool> Bah where is that 2.0 then I wonder
[13:29] <ogra> no idea
[13:30] <ogra> been sold so they can pay your bonus :)
[13:30] <armin76> mine!
[13:30] <ogra> (note tha past tense :) )
[13:30] <ogra> *the
[13:32] <lool> ogra: You've got a bonus?  I thought we were all sitting on our bonus this year due to the financial crisis!
[13:33] <asac> lool: ogra: i got the 2.0 and 3.0 at the same time
[13:34] <asac> which happened because i wasnt aware i was getting the 3.0 any time soon
[13:34] <asac> so i have two atm
[13:34] <asac> which is not really enough itlr
[13:34] <ogra> heh
[13:34] <asac> well. but i would give the 2.0 away if i can get a dove ... which currently is a deep whole in my hardware setup
[13:35] <asac> though i would like to have a dove and two bbg
[13:35] <asac> or two doves .. etc. if i do porting stuff like the chromium thing i cannot do anything else
[13:35] <lool> ogra: I was just kidding BTW
[13:35] <ogra> lool, indeed :)
[13:35] <lool> I hope you felt bad!  :)
[13:36] <ogra> well, *i* will get my bonus ... *you* will have to wait until asac sold your babbage :)
[13:36] <ogra> :P
[13:36] <asac> i am holiding back lool bonus until he releases his dove board ;)
[13:36] <lool> I'm holding back my babbage until asac's dove gets sold to ogra!
[13:36] <asac> haha
[13:37] <armin76> i'm getting all boards
[13:37] <ogra> lol
[13:37] <ogra> soo, how can we end up with 16M initrds now
[13:37] <lool> armin76: Does Gentoo ship/plans to ship pre-build ARM binaries?
[13:38] <lool> armin76: I wonder whether you build for hard float; I think that's not well supported with EABI
[13:38] <lool> *pre-built
[13:38] <armin76> lool: we do already, but we don't support them
[13:38] <armin76> http://tinderbox.dev.gentoo.org/default-linux/
[13:38] <armin76> nope, no hardfloat
[13:38] <lool> armin76: what's your optimization level for your public binaries?
[13:38] <lool> v5/6/7? thumb2?
[13:39] <lool> armv5tel-softfloat-linux-gnueabi
[13:39] <lool> Hmm that's old
[13:39] <lool> I guess you miss hardware for higher than v5
[13:39] <armin76> yep
[13:39] <armin76> why do you think i'm always saying that stuff i say? :)
[13:40] <lool> hehe
[13:42] <armin76> i got an efika mx now, though
[13:42] <lool> The one in a nice case?
[13:42]  * asac runs update-initramfs in verbose mode
[13:42] <armin76> yep, but its a lange board anyway
[13:42] <lool> armin76: Did you get a BSP / linux source code with it?
[13:43] <armin76> lool: yes
[13:44] <armin76> Linux efikamx 2.6.28-ER1-efikamx #4 PREEMPT Sat Nov 28 16:47:52 CST 2009 armv7l GNU/Linux
[13:44] <lool> armin76: Oh nice, so you can easily redistribute these patches right?
[13:44] <lool> asac, ogra: ^ we could at least start from these patches
[13:44] <lool> AFAIK we still have no public patch stack from pegatron
[13:45] <armin76> lool: you should ask neko @ #efika
[13:45] <lool> He came around here once
[13:45] <armin76> there's no patch, only patched source
[13:45] <lool> That's "ok"
[13:45] <lool> The only thing I need is a public source for it
[13:45] <lool> s/I/we
[13:46] <lool> Until now we only had non-publishable patches because of foo or bar
[13:46] <persia> Isn't that why we have diff?
[13:46] <asac> http://pastebin.com/f1b2e2ab5
[13:47] <persia> The Netwalker sources (another i.MX51) are also open and available to the public.
[13:47] <lool> persia: I mean a public location to retrive some form of source
[13:47] <lool> persia: Good luck splitting the imx51 stuff apart with diff though
[13:47] <persia> Well, true, but it's better than nothing, no?
[13:47] <armin76> lool: they aren't public though, they are included in the ssd
[13:48] <ogra> asac, looks dfine to me
[13:48] <asac> ogra: the produced initrd is better:
[13:48] <ogra> weird
[13:48] <asac> oh no
[13:48] <armin76> lool: i'll exchange them with a dove *g*
[13:48] <asac> sorry misread
[13:48] <asac> -rw-r--r-- 1 root root 1196802 2009-12-10 14:43 initrd.img-2.6.31-601-imx51
[13:49] <armin76> s/with/for
[13:49] <ogra> well
[13:49] <ogra> 11M is still better than 16
[13:49] <asac> ack
[13:49] <ogra> asac, i really think we need to compare the contents
[13:49] <lool> that's 1 MB?
[13:49] <lool> 1196802 => 1 196 802
[13:49] <asac> ogra: the contents i already posted
[13:49] <asac> http://pastebin.com/f98ce43d
[13:49] <asac> those are all the modules added
[13:50] <asac> hmm
[13:50] <ogra> i mean unpack both initrd files
[13:50] <ogra> and then run diff on a find output
[13:50] <asac> ogra: i have those unpacked
[13:50] <asac> ogra: thats what the paste is about
[13:50] <asac> just for the modules
[13:51] <ogra> oh, i was confused because it only shows the kernel dir
[13:51] <asac> yes. because the kernel modules dir has a different name
[13:51] <asac> so i ran inside
[13:52] <ogra> ah
[13:52] <ogra> lets compare the two configs
[13:52] <asac> ogra: http://pastebin.com/f7538b9e5
[13:53] <asac> thats the diff for all (ignore the modules)
[13:53] <asac> so for me it feels like this crypt* stuff is a good target
[13:54] <asac> thats all new at least
[13:54] <ogra> ah !
[13:55] <asac> usr/share/initramfs-tools/hooks/cryptopenct  usr/share/initramfs-tools/hooks/cryptpassdev
[13:55] <asac> usr/share/initramfs-tools/hooks/cryptopensc  usr/share/initramfs-tools/hooks/cryptroot
[13:55] <ogra> /lib/frimware ...
[13:55] <ogra> how big is that
[13:55] <asac> # This list needs to be kept in sync with the one defined in passdev.c
[13:55] <asac> for fs in ext3 ext2 vfat reiserfs xfs isofs udf; do manual_add_modules "$fs" > /dev/null 2>&1 || true
[13:55] <asac> done
[13:55] <asac> thats a bunch of new fs modules
[13:55] <asac> i guess
[13:55] <asac> let me check
[13:55] <ogra> ogra@osiris:/var/build/images$ du -hcs /media/bb4fdb28-11f1-4c72-a345-cc7006aa4898/lib/firmware/
[13:55] <ogra> 12M	/media/bb4fdb28-11f1-4c72-a345-cc7006aa4898/lib/firmware/
[13:56] <ogra> thats karmic
[13:56] <ogra> 2M difference in lucid
[13:56] <asac> 13700	lib/firmware/
[13:56] <asac> ogra: all the fs above are definitly one part
[13:57] <ogra> yeah, that adds up :/
[13:57] <ogra> though i dont get why the casper initrd isnt that big then
[13:57] <ogra> image building should have failed
[13:58] <ogra> the casper initrd.lz is 2.8M
[13:58] <asac> cryptroot also adds a bunch of get_device_modules
[13:58] <asac> yes thats odd
[13:58] <ogra> that might shrink by 1M due to lzma
[13:58] <asac> +./kernel/net/netfilter/xt_esp.ko
[13:58] <asac> but all that netfilter module stuff
[13:58] <asac> where got that added?
[13:58] <ogra> but then it would still be only 3.8M
[13:59] <ogra> kernel config
[13:59] <asac> hmm
[14:00] <dmart> Hi all— for those who didn't spot it, I raised a bug on squashfs: https://bugs.launchpad.net/ubuntu/+source/squashfs/+bug/494667
[14:00] <ubot4> Launchpad bug 494667 in squashfs "[armel] non-ISO-C misaligned pointer punning causes slowness and SIGILLs" [Undecided,New]
[14:00] <asac> ogra: but the "net" modules are explicitly listed in hook-functions
[14:01] <asac> so those are pulled in from somewhere else
[14:01] <asac> you say that hook-functions also looks somewhere else?
[14:01] <ogra> you mean the NIC drivers or netfilter ?
[14:01] <asac> ogra: no ... i mean all the netfilter/* modules
[14:01] <asac> they are now added
[14:01] <asac> http://pastebin.com/f98ce43d
[14:01] <asac> +./kernel/net/netfilter/xt_esp.ko
[14:01] <asac> ...
[14:02] <asac> also
[14:02] <asac> +./kernel/net/bridge
[14:02] <asac> ...
[14:02] <ogra> generally modules are added from hook-functions
[14:02] <asac> +./kernel/net/ipv4
[14:02] <asac> ...
[14:02] <dmart> Since we are stuck with the 2.6.28 kernel on the buildds for now, I think the quickest workaround is probably to avoid the mksquashfs crashes is  for __packed__ attributes to be added.  This isn't ideal, because it will result in slower execution, but it should avoid the SIGILLs.
[14:02] <ogra> but every hook script can put additional modules in
[14:02] <cooloney> ogra: i am going to build a BabbageImageFromScratch, but how to get the latest initrd.img?
[14:02] <asac> ogra: really look in this: http://pastebin.com/f98ce43d tats really a huge amount of new modules
[14:02] <asac> ogra: yes. but i dont see netfilter anywhere
[14:03] <asac> feels like it was previously individual files and now its just the full "net" dir
[14:03] <ogra> cooloney, use an old one, boot and run update-initramfs in the running system
[14:03] <cooloney> ogra: ok, thanks, downloading. heh
[14:03] <asac> dmart: thanks. let me read ;)
[14:03] <ogra> cooloney, though if you have anything as module that you need to get the rootfs up, that wont work indeed
[14:04] <persia> ogra: Why not, as long as the module is in the initramfs?
[14:04] <ogra> persia, because you likely have a version mistmatch
[14:05] <persia> ogra: Ah, using an old initramfs with a new kernel.  I thought you were suggesting to boot the old initramfs and old kernel, and then install the new kernel and run update-initramfs.
[14:06] <ogra> right, that works for sure
[14:06] <cooloney> ogra and persia, yeah, if that works, i can build a new disk with my new kernel installed right?
[14:06] <ogra> just drop the modules into /lib/modules and copy the kernel binary over vmlinuz
[14:06] <ogra> then run update-initramfs
[14:06] <ogra> that will just put them into fis
[14:07] <cooloney> ogra: ok, got it.
[14:07] <cooloney> ogra: where can i find the armel rootfs?
[14:07] <asac> dmart: hmm ok.
[14:07] <asac> how laborious is fixing the C code?
[14:07] <ogra> cooloney, you dont have one installed yet ?
[14:08] <cooloney> ogra: i dd the karmice imx51 release image to a SD card.
[14:08] <ogra> oh, you didnt install it ?
[14:08] <cooloney> ogra: so i guess this SD already has the rootfs, right?
[14:09] <cooloney> ogra: i installed it on a sata driver only,
[14:09] <ogra> it only has the livefs
[14:10] <cooloney> ogra: ok, do i need to reinstall i on a SD card or USB disk
[14:10] <ogra> i would recommend USB
[14:11] <cooloney> and that installed usb stick contains the rootfs, right?
[14:11] <persia> cooloney: And a copy of the kernel and the modules, etc.
[14:11] <persia> It's a full installed system (although there is an extra copy of the kernel and initramfs in some boot location)
[14:11] <cooloney> persia: yeah, understand.
[14:12] <cooloney> so how big usb stick is enough for that?
[14:12] <persia> Recommended minimum secondary storage for an Ubuntu installation is 4G.
[14:13] <persia> I know some people have managed it with far less, but there's no promises it works with less.
[14:14] <cooloney> persia and ogra ok, i got it. thanks a lot
[14:30] <asac> JamieBennett: what did we find so far for casper speed? anything we could fix easily?
[14:42] <dmart> asac: To me, it looked very laborious to convert the squashfs C code to do aligned access only, unless someone has a good idea about how to do it— it might require quite a lot of code to be rewritten, and the logic of how the output data is built up might have to change.  This doesn't feel feasible for now :(
[14:42] <asac> kk
[14:43] <asac> we should at least carry tha tupstream though
[14:43] <asac> dmart: why did this start to happen in lucid only? and only on that hardware?
[14:43] <dmart> ... hang on ...
[14:44] <dmart> Building with -marm might work.  The Jaunty kernel can't cope with all unaligned accesses in Thumb, but should cope if the userland code is ARM.
[14:45] <dmart> I've added that suggestion to the bug, and I'll give it a try.
[14:45] <persia> dmart: Would it just be building mksquashfs with -marm, or would the contents matter?
[14:45] <asac> ok. i think -marm feels acceptable. its not something that impacts user machines.
[14:45] <persia> asac: Doesn't it affect rootstock users?
[14:46] <dmart> persia: Do you mean the squashfs contents?  I think that shouldn't matter
[14:46] <asac> yes. but thats development tool ;)
[14:46] <asac> so ... developer machines ... or am missing something ?
[14:46] <persia> Well, most users *are* developers today :)
[14:46] <dmart> Once we have true Karmic/Lucid buildds, we can switch to -mthumb and it should all work.  So -marm would be a temporary measure for this package.
[14:53] <dmart> I just rebuild squashfs-tool with -marm and re-ran my test on one of the nettops, and it ran without SIGILL, so I think this may work as a solution.
[14:58] <asac> thanks dmart
[15:02] <asac> targetted bug ... assigned to dyfet to prepare the debdiff
[15:02]  * persia gets confused by http://packages.qa.debian.org/s/squashfs/news/20091202T163929Z.html
[15:03] <asac> hmm
[15:03] <persia> I found the issue.  cf. http://packages.qa.debian.org/s/squashfs-tools.html
[15:04] <persia> But since we have source/binary namespace issues, we run into the same sort of issues why `apt-get source linux` doesn't actually work.
[15:04] <asac> ack
[15:04] <asac> should get removed from our arch too then
[15:04] <persia> Looks like we need to chase that transition in Ubuntu for other reasons, and so would want to do the -marm stuff at the same time.
[15:04] <asac> hmm
[15:05] <asac> yeah
[15:05] <persia> Might need a poke, as it's source removal but not binary removal (and stuff like that tends to confuse busy archive admins)
[15:05] <asac> dyfet: also look at the package rename at that time maybe
[15:05] <ogra> linux ?
[15:05] <ogra> you cant remove linux from armel, it builds versatile
[15:06] <persia> ogra: apt-get source linux pulls the linux-meta source.  We now have the same issue in that apt-get source squashfs pulls the squashfs source and apt-get source squashfs-tools pulls the squashfs source and apt-get source won't pull the squashfs-tools source without being hit about the head.
[15:06] <ogra> ah
[15:06] <ogra> i missed the meta reference :)
[15:06] <dyfet> Okay...adding -marm itself for arm arch seemed simple enough for squashfs-tools...
[15:06] <dmart> apt-get --source-only source sounds like it should work to solve this, but it never works for me; I usually have to resort to wget
[15:06] <asac> guess there is no way to fire off ubiquity at install stage ?
[15:07] <asac> dyfet: thanks. check if we also want to get the new source from debian or something
[15:07] <persia> (where hitting about the head is the --only-source parameter)
[15:07] <ogra> asac, can you elaborate
[15:07] <asac> maybe two steps
[15:07] <persia> (except this fails for some reason as well :( )
[15:07] <dyfet> asac: is there already a bug for this?
[15:07] <asac> ogra: well. want to trial and error change hooks etc. to see what is adding all those modules
[15:07] <ogra> asac, https://wiki.ubuntu.com/ARM/BabbageInstallVariants only ubiquity ?
[15:08] <asac> ogra: and update-initramfs in chroot yielded a 1.6M initrd only
[15:08] <ogra> ah, thats what you want
[15:08] <asac> ogra: i am in a live sesssion. ... wanted to rerun just the last step that triggers that
[15:08] <ogra> no, it needs to get to the end of the install sadly
[15:08] <ogra> 1.6M seems to small
[15:08] <asac> ogra: so what is different from just running update-initramfs in chroot?
[15:09] <ogra> good question
[15:09] <asac> which is where i had the verbose output
[15:09] <asac> ogra: how to best mount dev?
[15:09] <asac> seems like ubiquity doesnt mount /dev completely
[15:09] <asac> and the crypt hooks complain about /dev/null non-existing
[15:09] <ogra> oh
[15:09] <ogra> that sounds buggy
[15:09] <ogra> did you check /dev in your initramfs ?
[15:09] <ogra> *g*
[15:10] <asac> hmm. not inside it. i checked it in the /target mounted chroot
[15:10] <ogra> probably it copies any virtual fs
[15:10] <asac> and there only /dev/pts is mounted
[15:10] <ogra> yeah, for apt
[15:10] <ogra> it should mount dev and friends dynamiocally
[15:10] <asac> are you saying that the hooks are run even in the initramfs? (e.g. not in the /target) ?
[15:10] <ogra> no
[15:10] <asac> ok
[15:11] <persia> asac: Are you trying to update a live image and then reboot it?
[15:11] <asac> no. i am trying to run the update-initramfs that is run at end of ubiquity before the flashing without running the whole ubiquity
[15:12] <ogra> persia, he tries to find out how update-initramfs is run from ubiquity
[15:12] <ogra> asac, grep the ubioquity code is my best suggestion
[15:12] <asac> i see that its just run. but not sure what env it is run it ;)
[15:12] <ogra> i know i added stuff to mount certain dirs that were missing in karmic, so i know it mounts unmounts dynamically for each command that needs it
[15:13] <asac> also i wonder why there is no /dev/null in /target ;)
[15:13] <asac> ok had to run the install anyway. seems that failing flash busts the SD card somewhat
[15:13] <ogra>  /dev gets bind mounted dynamically
[15:13] <asac> so i had to re dd that
[15:13] <asac> ogra: the full /dev?
[15:13] <asac> odd ... i will check that
[15:14] <asac> only saw devpts mounted
[15:14] <asac> but if its always unmounted that might explain it
[15:14] <asac> will just do it then
[15:14] <ogra> check the code, it should have some function like "prepare_chroot()" or some such
[15:14] <asac> yep
[15:14] <ogra> that calls the mount commands dynamically right before update-initramfs grub-install and other commands that need it
[15:15] <ogra> might be named differently ... prepare_target or so ... i dont remember the actual name
[15:16] <asac> right it bind mounts /dev
[15:16] <asac>         if not os.path.exists(os.path.join(self.target, 'proc/cmdline')):
[15:16] <asac>             self.chrex('mount', '-t', 'proc', 'proc', '/proc')
[15:16] <asac>         if not os.path.exists(os.path.join(self.target, 'sys/devices')):
[15:16] <asac>             self.chrex('mount', '-t', 'sysfs', 'sysfs', '/sys')
[15:16] <asac>         misc.execute('mount', '--bind', '/dev', os.path.join(self.target, 'dev'))
[15:16] <asac> its called chroot_setup
[15:16] <ogra> ah, right
[15:17] <asac> ok great. odd that it it leaves devpts mounts behind though ;)
[15:17] <asac> will check in a few minutes when install failed
[15:17] <ogra> devpts is used by dpkg/apt for logging
[15:17] <ogra> they might be needed at that stage
[15:18] <persia> ogra: To console?
[15:18] <ogra> to nothing ... i dont even think they are actually used
[15:18] <ogra> but dpkg spills errors if it cant find them at the start of a package install
[15:18] <ogra> i think its just kept around to quieten that
[15:18]  * persia thought logs went to /var/log/* and to <stdout>
[15:19] <ogra> i think d-i and ubiquity only log to /var/log/* ... d-i just runs a tail -f on tty4
[15:19] <JamieBennett> asac: just got back, see https://wiki.ubuntu.com/ARM/CasperSpeedup
[15:19] <asac> persia: what is universe-contributor about?
[15:20] <asac> my nm student wants to apply there, but i am not sure if he really should do that rather than motu
[15:21] <asac> JamieBennett: the more detailed analysis is the script content?
[15:21] <asac> like for 10adduser?
[15:21] <persia> asac: #ubuntu-motu or #ubuntu-devel are better places to ask that question, but it's a recognition of significant and sustained work within the Ubuntu development community.
[15:22] <ogra> asac, i think debconf-communicate generally has speed issues
[15:22] <persia> asac: https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu%20Contributing%20Developers
[15:22] <JamieBennett> asac: yeah, the timings are there for each slow part (i.e. a chroot or a locale generation e.t.c)
[15:23] <persia> (and feel free to have someone talk to me directly, either here or on oftc about that stuff)
[15:23] <JamieBennett> asac: next step is to look in more detail exactly what each of these code paths does and see if we can optimise them
[15:23] <asac> persia: but is that really something developers should apply for?
[15:23] <asac> i mean developers that already do development for ubuntu?
[15:23] <JamieBennett> asac: ues
[15:23] <asac> (after that i will go to some other channel ;))
[15:23] <persia> asac: Well, it depends on what they are doing.  Contributing Developers get @ubuntu.com email and authority to represent the Ubuntu project.
[15:24] <persia> There's no related specific upload rights.
[15:24] <persia> Some development teams require Ubuntu Membership prior to application, and since all Contributing Developers are also members, this can be one way to get it.
[15:25] <asac> persia: kk
[15:25] <asac> thx
[15:26] <persia> asac: By the way, I suspect you're a member of the team (likely through inheritance).
[15:26] <armin76> he slacks
[15:26]  * armin76 runs
[15:27] <asac> feels like i keep my old stuff for ever
[15:28] <asac> at least for the next 6 month i dont see any change :(
[15:28] <ogra> just stop doing it :)
[15:28] <ogra> ignorance ftw !
[15:28] <persia> Well, both of you are not likely to care, really, because this is all stuff that matters more to people who don't already have root on tens of millions of systems :)
[15:28] <asac> for NM i can stop and things will survive. for mozilla we all will get fired once the world notices that we are without security updates for year ;)
[15:29] <ogra> who cares, in one year we'll all use armel devices with chromium
[15:29] <asac> yeah. still distro reputation can go down quickly
[15:29]  * persia will probably stick to epiphany
[15:29] <asac> also mozilla sues us ;)
[15:30] <asac> in worst case making our brand damage reponsible for loosing their google money at some point ... that would be expensive ;)
[15:30] <ogra> heh, i would like to see them actually sueing anyone
[15:30] <ogra> did they ever enforce their policy at court ?
[15:30] <asac> trademark?
[15:30] <ogra> yep
[15:30] <asac> no. but they managed to get all distros not using it
[15:30] <asac> but three: ubuntu/suse/redhat
[15:31] <ogra> yep
[15:31] <asac> so i am sure they will be able to enforce it
[15:31] <persia> trademark law has enough precedence that as long as they complain about it properly they don't need to have taken it to court.
[15:31] <asac> right
[15:31] <persia> (well, perhaps not in some jurisdictions, but at least for most of the places they really care about)
[15:31] <asac> and since they are really running around forcing folks to stop doing that you cannot say they handled it to openly
[15:32]  * ogra goes to call sudo make sandwich ... 
[15:32] <asac> enjoy
[15:44] <asac> dyfet: thanks for drafting the ooffice spec. in the work items i added a few options (from minimal to almost-perfect integration)
[15:44] <asac> do those make sense? can you add them to the implementation section too?
[15:47] <asac> hmm. noticed that bindmounting /dev is slightly different from the original /dev
[15:47] <asac> like /dev/shm has different attributes in /dev than in the bindmounted location
[15:47] <asac> odd
[15:47] <asac> bindmounting /dev/shm somewhat fixes this
[15:47] <ogra> shouldnt cause our issues though
[15:47] <dyfet> asac: I realized when reviewing specs that it got lost from when we did the original split....
[15:48] <asac> ogra: no. but it cauess issues for chromium when run in chroot
[15:48] <asac> it uses /dev/shm for sandboxing
[15:48] <ogra> ah
[15:48] <asac> dyfet: right. thanks a lot
[15:49] <asac> dyfet: to make it perfect putting one long sentence for the three integration variants i put into the work items would be great
[15:49] <asac> put that to implementation section
[15:49] <dyfet> ok
[15:49] <asac> problem is that its pretty hard to do the integration compared to mailto:
[15:49] <asac> thats why i want three potential solutions to be in there
[15:49] <dyfet> yea...I was thinking about that issue :)
[15:49] <asac> 1st. simple bookmark+ open browser integration
[15:49] <asac> 2nd. auto import when double clicking (but no back and forth synch)
[15:50] <asac> 3rd. gvfs gdocs mount for Documents folder
[15:50] <asac> i think those are the approaches i put into the work items ... having a sentence for each would be good
[15:54] <dyfet> asac: so your suggesting we turn the document into a browser bookmark entry?
[15:55] <asac> dyfet: no. 1st. approach is simple. it just allows you to open the borwser with gdocs if you click on the "office" launcher icon
[15:55] <asac> no import etc.
[15:55] <asac> also adding a bookmark to the browser might be ok
[15:56] <asac> 2nd. is about importing office documents if you want to open them
[15:56] <asac> using libgdata
[15:56] <asac> and then opening a browser with just gdocs opened and the right folder maybe or even file
[15:56] <asac> if we are really smart we could rename that file at that time and replace it with a link to it in gdocs
[15:56] <asac> but that can get out-of-sync
[15:56] <asac> so i am not sure
[15:57] <asac> rather would wnat to have 3. which would import it on first click and move it to the mounted Documents folder
[15:57] <asac> so starting there it would work to just open it in browser and also we wont get out of sync if you move files in gdocs
[16:01] <dyfet> yes, each has some ugly aspects...
[16:02] <dyfet> though a simple mime helper app could be written in python to do any of these things...
[18:02] <asac> dyfet: well. if you can think of a forth ... potential perfect option feel free to discuss that :)
[18:02] <asac> the gvfs mount in Documents feels for me like the best solution
[18:02] <dyfet> If I can I will
[18:02] <asac> almost perfect.
[18:02] <asac> when you click on a file outside of the moint you would get asked if you want to import it
[18:03] <asac> and then the file would be moved to some "backup" location
[18:03] <asac> so you usually just use the mounted location
[18:04] <asac> dyfet: but imo all close to perfect solutions are off what we can do for lucid (e.g. 3. needs a bunch of work on the gdocs backend for gvfs)
[18:04] <asac> but writing the ideas down makes sense still
[18:04] <dyfet> yes, there is always the option of deferring it, too, in this case
[18:05] <asac> dyfet: let me know when you wrote the 3 ideas down so i can just approve the spec for now ;)
[18:05] <asac> that would make it done imo
[18:05] <dyfet> I initially added it to the spec already, but I think I need to expand on the third one
[18:08] <asac> dyfet: just write one sentence for each outlining the implementation/integration approach
[18:08] <dyfet> thats what I did
[18:08] <asac> ok
[18:08]  * asac checks wiki again
[18:09] <asac> dyfet: maybe make bullet points out of the three approaches
[18:09] <dyfet> okay :)
[18:09] <asac> that improves visual recognizability in the spec
[18:09] <asac> dyfet: the third would also open the browser with the right location after import
[18:09] <asac> also if you click on the mounted documents the browser would be opened too of coures
[18:10] <asac> (or openoffice if user chooses to open with openoffice)
[18:11] <asac> cool. so what i will do is send a request to design team to make a design suggestion for the wizards ... i see three wizards atm: a) select preferred mail handler, b) select preferred office handler, c) import wizard (if we implemnt that)
[18:11] <asac> also we need icons like outlined in the work items
[18:11] <asac> for generic mail ... and office (with option to overlay webservice  branding based on users selection)
[18:34] <asac> ogra: so yeah. cryptroot adds 13.5m of modules
[18:34] <asac> basically all the drivers in the world
[18:34] <asac> now i need to find that package ;)
[18:34] <asac> dpkg -S cryptroot on lucid anyone?
[18:42] <asac> bug 495161 filed
[18:42] <ubot4> Launchpad bug 495161 in cryptsetup "initramfs cryptroot hook bloats armel initrd by adding >13M of compressed modules" [Critical,Triaged] https://launchpad.net/bugs/495161
[18:43]  * persia stops trying to install initramfs-tools on lucid to verify
[18:45] <asac> yeah ;)
[18:46] <persia> I only had another 27 minutes to wait for the download to complete :)
[18:46] <persia> (including dependencies, etc.)
[18:48] <asac> persia: heh. keep on going
[18:48] <asac> having lucid ready will be handy ;)
[18:49] <persia> I have lucids available for about half the architectures I use.  I should get to 75% this weekend, and probably 100% next week.
[18:49] <persia> It's just that I don't currently run any lucid live systems, so need to install the low-level stuff (rather than just forwarding X from a chroot).
[18:50] <persia> (again, I should have at least two running lucid environments by next week)
[19:38] <awong> asac: re the aac.c arm patch for chromium, hclam apparently has a fix open for it, and will be submitting it soon.  The -fPIC change should also land sometime today.  So, things should be good probably by later today or tomorrow.
[19:42] <asac> awong: great. thatnks for the update
[19:42] <asac> awong: so he will land more fixes than for ffmpeg?
[19:42] <awong> no prob. Thanks for bringing it up.
[19:43] <awong> fbarchard had the -fPIC change yestertday but it broke other parts of our build I think, so he had to revert.  hclam is working on various arm things (I actually don't know exactly what) and one of them is that compile fix.  I just asked him to try and submit that compile fix early.
[19:45] <awong> FYI, video performance on arm is probably going to be pretty dismal for chromium right now.  I saw some tests of the performance here, and it super slow/choppy.  There's actually some bugs in our rendering logic that doesn't handle super slow processers well for video and leads to exteremly bad behavior in the frame dropping code.  hclam was working on that last, but don't know his status exactly.
[20:58] <ogra> asac, you rock !
[21:01] <asac> awong: thx. first we need a working build though ;)
[21:16] <awong> asac: completely agree. :)
[21:45] <asac> hmm the installer is quite slow imo
[22:01] <asac> plars: so reformatting existing partitions seems to be buggy. crashes ubiquity. but deleting partition and creating works though
[22:07] <persia> Adjusting partitions on flash tends to do wonky things with the FTL anyway (assuming you're looking at issues installing to USB flash)
[22:13] <plars> plars: hmm, mine crashed even when repartitioning
[22:15] <persia> plars: I tend to have better luck with much abused USB flash doing an erase rather than a write every once in a while.  How this really happens depends on the firmware, but at least for the Elecom keys I prefer, dd if=/dev/zero of=${flash device} bs=${flash eraseblock size} seems to do the right thing.
[22:16] <persia> Then it needs to have a new partition table written from scratch, etc.
[22:37] <asac> plars: yes. reformatting is what makes it choke for me
[22:37] <asac> if i really add parition or something its ok
[22:37] <asac> just if i select previously used partition and set it to / or something
[22:43] <asac> hmm. bad issues ;)
[22:43] <asac> on reboot
[22:43] <plars> asac: were you able to get around the install failure by removing the hook from /target
[22:43] <asac> also usb errors about bad device descriptors
[22:43] <asac> plars: yes. after the "copying files ..." stage
[22:43] <asac> but before "flashing kernel"
[22:44] <asac> you need to remove the cryptroot stuff
[22:44] <asac> or actually comment out one line
[22:46] <plars> gotta reboot, brb
[22:53] <plars> asac: where would the line need to be commented from?
[22:55] <asac> plars: can you paste that file ;)
[22:55] <asac> i just lost it
[22:55] <asac> (and the image even)
[22:57] <asac> plars: are you good at launchpadlib writing ;)?
[22:58] <asac> (by coincident)
[22:59] <plars> asac: good? I wouldn't say so, I've done some basic things though
[22:59] <asac> ;)
[22:59] <plars> asac: if you have ideas for scripts, I'd love to work on them though
[22:59] <asac> for the relesae team report we basically need a script that gives info about lucid targetted bugs added/fixed/triaged in last week with armel tag i guess
[23:00] <asac> https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[23:00] <asac> so that
[23:00] <asac> the RC bugs section basically ;)
[23:00] <asac> somehow automized
[23:02] <asac> not sure if one can easily query if something got closed/etc. in last week though
[23:02] <persia> I don't think that can be queried, but we can get a list e.g. daily or 6-hourly and then compare them periodically.
[23:02] <persia> Needs some client-side storage.
[23:03] <awong> asac: http://src.chromium.org/viewvc/chrome?view=rev&revision=34297  Hopefully that fixes the compile issues
[23:03] <asac> rock on
[23:03] <asac> yeah client side storage is bad ;)
[23:04] <asac> but if thats the only way its better than having to look through all bugs ;)
[23:04] <persia> client-side storage doesn't need to be bad.  There are enough folk about with always-on servers.
[23:04] <asac> awong: great. so fPIC is still waiting for some issues?
[23:05] <persia> I'm not sure I really want to code it, but I certainly could host it if nobody else wished to do so.
[23:05] <asac> thanks persia
[23:05] <asac> so getting a weekly dump of targetted bugs with its state in a filterable/diffable form
[23:05] <asac> would be good i think
[23:06]  * persia wonders what "thanks" is for
[23:08] <asac> for the offer and for caring ;)
[23:08] <awong> asac: nope, that should be fixed too.  http://src.chromium.org/viewvc/chrome?view=rev&revision=34284
[23:08] <persia> Oh, good.  Let me know if nobody else will write it, as it would be an excuse to learn lplib, but hosting is easy.
[23:09] <asac> awong: hmm. there is no PIC mentioned there
[23:10] <awong> asac: yeah, it's int he changelog, but not in the diff.  However, if you look at the ffmpeg.gyp file, it has -fPIC in the cflags section for ['target_arch=="arm"', {.
[23:10] <asac> great
[23:10] <asac> thanks!!
[23:10] <asac> we switched to 4am UTC for daily snapshots so i can copy that to builders for arm right away tomorrow morning
[23:11] <awong> no prob.  I didn't do the work. :)  Let me know if things still don't work for some reason.
[23:11] <asac> hmm. i had one patch for chromium i gave fta
[23:11] <asac> let me check
[23:11] <asac> its basically about brokenness for non armv7=0 builds
[23:11] <asac> ah right
[23:11] <asac> its skia.gyp
[23:12] <asac> the SSE source is not excluded if its not armv7=1
[23:12] <asac> and also the opts are not added
[23:12] <asac> http://paste.ubuntu.com/338225/
[23:13] <awong> Okay.  If fta has the patch, he can submit it for review and the skia guys can have a look.
[23:13] <asac> thats the new block in skia.gyp needed
[23:13] <asac> replacing it in skia.gyp
[23:13]  * asac should get a git tree of chromium i guess
[23:13] <asac> or svn checkout at least ;)
[23:13] <asac> fta: do you need anything from me for the skia.gyp changes?
[23:13] <awong> heh. seeming like it. :)  And we should get you into the authors file to clear all the hurdles.
[23:13] <asac> right.
[23:14] <asac> i will take that as an action ;)
[23:14] <asac> to sign contributor agreement etc.
[23:14] <asac> and setup svn
[23:15] <fta> i don't really have much time atm
[23:15] <asac> all fine ;)
[23:15] <fta> busy with work
[23:17] <asac> plars: what timezone are you in?
[23:21] <persia> ( UTC -6 )
[23:21] <asac> weather clock is sorted by name
[23:21] <asac> not UTC offset :/
[23:21] <asac> what is that? chicago?
[23:21] <persia> I use Morelia for that timezone.
[23:21] <asac> what is morelia
[23:21] <asac> is that in US?
[23:22] <awong> first search result says Mexico.
[23:22] <persia> Yep, that's it.
[23:23] <asac> the region selection in weather clock can be ... erm... improved ;)
[23:23] <asac> its like a zillion scrollable menu ;)
[23:23] <persia> I know.  That's part of why I try to pick odd city names.
[23:24] <asac> morelia is not in there :(
[23:24] <asac> hmm i have dallas
[23:24] <asac> thats enough ;)
[23:24] <persia> Hrm.  Dallas works.
[23:25] <asac> yeah ;)
[23:25] <awong> clearly the right solution woudl be to reduce it down to one choice.  That way the users can't be confused with having too many options.  And ofcourse, that one choice should be something htat's 30minutes off of UTC.
[23:25] <persia> awong: Why choose 30 minutes when 15 and 45 are available?
[23:26] <asac> i think we should just use the ubiquity timezo9n selector
[23:26] <asac> thats great thing
[23:26] <asac> though some cities could deserve a point ;)
[23:26] <asac> i clicked on berlin and got prague or something similar close
[23:27] <asac> timezone is the same though
[23:27] <persia> Except weather doesn't work.
[23:27] <persia> I was very annoyed last week because I couldn't pick a location near where I was, and so couldn't see the weather.
[23:27] <asac> ;)
[23:27] <asac> weather was too broken so i only use it for time now ;)
[23:27] <asac> the old weather thing worked at least
[23:28] <persia> So it's not 5 degrees, feels like 0.4 there?
[23:28] <asac> not sure if they moved to an "open" serive to get weather datra now ;)
[23:31] <awong> persia: are there actually timezones that are 15 and 45 mins off? I only knew of the 30-min ones...
[23:31] <persia> Yes.
[23:31]  * persia hunts one up
[23:32] <persia> http://www.worldtimezone.com/wtz-names/wtz-wct.html is one example
[23:32] <awong> oh fun.
[23:33] <awong> I'm so glad icu exists.
[23:33] <persia> ICU?
[23:34] <awong> http://site.icu-project.org/
[23:35] <persia> Oh, for the timezone calculations?
[23:35] <awong> yeah
[23:35] <persia> heh.
[23:36] <persia> Actually, I can't find any :15 timezones.  Only :00, :30, and :45.  Odd, that.
[23:38] <asac> is there a way to grab the pre-image livefs somewhere?
[23:40] <asac> what timezone is pacific e.g. what city?
[23:40] <persia> Santa Fe
[23:40] <persia> Or Portland
[23:40] <asac> its  not in there
[23:40] <asac> even tokio isnt
[23:40] <persia> Los Angeles?
[23:40] <asac> neither
[23:40] <asac> nor sf
[23:41] <asac> let me check portland
[23:41] <persia> Try Tokyo.  We don't spell it that way anymore.
[23:41] <asac> seattle neither
[23:41] <persia> Vancouver?
[23:41] <asac> persia: well i looked for Tok*
[23:41] <asac> nothing
[23:41] <persia> Mountain View?  Redmond?
[23:41] <persia> Sacramento?
[23:42] <asac> ha
[23:42] <asac> there is a "United states" submenu ;)
[23:42] <asac> with pacific
[23:42] <persia> I'm surprised Tokyo isn't there.  Japan used to have lots of timezones, and settled on Tokyo time (except for Okinawa) about 50 years ago.
[23:42] <persia> Aha!
[23:42] <asac> maybe there is a "japan" submenu
[23:42] <asac> ;)
[23:42] <asac> or asia
[23:42] <persia> Probably Asia/Tokyo
[23:42] <persia> (That's what LP calls my timezone)
[23:43] <asac> but given the length of the top level list thats ridiculous
[23:43] <persia> Indeed.
[23:43] <asac> antartica ;9
[23:43] <asac> is a submenu
[23:43] <asac> australia
[23:43] <asac> too
[23:43] <asac> but no asia ;)
[23:43] <asac> wow
[23:43] <persia> Australia deserves a submenu: there's something like 10 timezones.
[23:43] <asac> even chile and congo are submenus ;)
[23:43] <persia> (because some states do DST and others don't, and there's WCT, etc.)
[23:44] <persia> Chile gets interesting, just because there's something like a 3-hour gap in the middle of the timezones it spans.
[23:44] <asac> ok added taiwan
[23:44] <asac> thats as close as i get to japan ;)
[23:44] <persia> That's not my timezone.
[23:44] <persia> It's off by one.
[23:44] <asac> i know
[23:45] <persia> OK.
[23:45] <asac> what city do you have in weather applet?
[23:45] <persia> Sydney, Tokyo, Berlin, London, Boston, Morelia, Portland
[23:45] <asac> morelia isnt there for me
[23:45] <asac> tokyo neither :(
[23:45] <asac> did you set that by latitude?
[23:45] <persia> Nope, but I set it in Jaunty.
[23:45] <asac> err long...
[23:46]  * persia upgrades rather than reinstalling
[23:46] <asac> ok i give up
[23:46] <asac> enough time wsated scrolling an endless menu ;)
[23:46] <persia> I can give you lat/long if that helps.
[23:46] <asac> guess i am better in my head :)
[23:46] <persia> OK.  About livefs images.
[23:46] <asac> no. i can remember its taiwan + 1 ?
[23:46] <asac> or -1 ?
[23:46] <persia> heh :)
[23:46] <persia> +1
[23:46] <asac> ok
[23:46] <asac> so its 8:45 ;)
[23:46] <asac> quite early :)
[23:47] <persia> They do exist.  They can be accessed, but I think they are only accessible to livefs-builder admins and ubuntu-cdimage by default.
[23:47] <asac> ok livefs is much better ;)
[23:47] <asac> hmm
[23:47] <asac> ok
[23:47] <persia> I tend to just pull them from the image, because that's easier.
[23:47] <asac> have a script ready for that?
[23:47] <asac> or monuted?
[23:47] <persia> (or construct them myself with livecd-rootfs)
[23:48] <asac> do you have a full mirror?
[23:48] <asac> i would like to have something that matches what we produce
[23:48] <asac> not something "close"
[23:48] <persia> `sudo mount src/images/foo.img /mnt; cp /mnt/casper/squashfs.img src/scratch/squashfs.img; sudo umount /mnt`
[23:49] <persia> As long as the archive is consistent, running livecd-rootfs locally will produce the same thing as the livefs-builders, unless there is something odd about them.
[23:50] <persia> (like the mksquashfs bug we were discussing earlier)
[23:50] <asac> persia: hm thought the image cannot be mounted because its has multiple partitions etc.
[23:50] <asac> oh
[23:50] <asac> i will figure ;)
[23:50] <persia> OOps.  script error.
[23:51] <persia>  `sudo mount src/images/foo.img /mnt; cp /mnt/casper/filesystem.squashfs  src/scratch/squashfs.img; sudo umount /mnt`
[23:51] <persia> Oh, if you're working with the multipartitioned SD image, just use losetup.
[23:51]  * persia hunts up kirkland's excellent blog post
[23:52] <persia> http://blog.dustinkirkland.com/2008/10/mounting-kvm-disk-image.html
[23:55] <persia> So, you run losetup and kpartx before my script, and mount /dev/loopN to /mnt
[23:55] <asac> yeah
[23:55] <asac> that will do i guess
[23:55] <asac> great
[23:55] <asac> bookmarked till i try