=== bjf is now known as bjf-afk === asac_ is now known as asac [01:38] ok lucid build still snaps [01:38] :/ [01:39] "pure virtual method called" still [01:40] [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] saw that when running in gdm [01:40] fta: ^ [01:42] asac, hm, try with --disable-sandbox [01:43] kk [01:45] i thnk i have probs with /dev [01:45] let me first sort that out [01:57] fta: can you run chromium in a chroot well? [01:58] never tried [01:58] not sure the sandbox will work [01:59] it does its own chroot [03:06] 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] 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] is this known... or has anybody experiences with this [10:34] 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] nice, seems thumb2 already saves us 20MB in image size [11:52] ogra_: but does the image work? ;) [11:53] 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] niceeee [11:54] yeah === ogra_ is now known as ogra [13:17] hey folks [13:17] Just talked to a French Freescale guy [13:17] who told me that thumb 2 is mostly slower than regular arm code, I was aware the diffence was so significant [13:18] Let's hope that the space savings in cache make up for it [13:18] and he also told me that thumb 2 was bugged on TO2 [13:18] So it might cause faultsevery 4 Kb or something he didn't have any detail on [13:18] => we should check for erratas from FSL on thumb 2 issues -- it might break random programs [13:18] lool, dusing image install i cant see *any* difference in speed on my bababge with lucid [13:18] *during [13:19] i was actually expecting to see a speedup [13:19] but its as slow/fast as karmic was [13:25] yey [13:26] ogra: Ok [13:27] lool, we have lucid babbage images, feel free to take a loo ;) [13:27] and a look as well :P [13:28] I don't have any babbage 2.x [13:28] only 1 [13:28] ah, yeah, you sent them to jamie [13:29] and to asac [13:29] Well I left the 2.0 in london and think it was sent to asac [13:29] right [13:29] no, he has a 3.0 [13:29] Bah where is that 2.0 then I wonder [13:29] no idea [13:30] been sold so they can pay your bonus :) [13:30] mine! [13:30] (note tha past tense :) ) [13:30] *the [13:32] ogra: You've got a bonus? I thought we were all sitting on our bonus this year due to the financial crisis! [13:33] lool: ogra: i got the 2.0 and 3.0 at the same time [13:34] which happened because i wasnt aware i was getting the 3.0 any time soon [13:34] so i have two atm [13:34] which is not really enough itlr [13:34] heh [13:34] 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] though i would like to have a dove and two bbg [13:35] or two doves .. etc. if i do porting stuff like the chromium thing i cannot do anything else [13:35] ogra: I was just kidding BTW [13:35] lool, indeed :) [13:35] I hope you felt bad! :) [13:36] well, *i* will get my bonus ... *you* will have to wait until asac sold your babbage :) [13:36] :P [13:36] i am holiding back lool bonus until he releases his dove board ;) [13:36] I'm holding back my babbage until asac's dove gets sold to ogra! [13:36] haha [13:37] i'm getting all boards [13:37] lol [13:37] soo, how can we end up with 16M initrds now [13:37] armin76: Does Gentoo ship/plans to ship pre-build ARM binaries? [13:38] armin76: I wonder whether you build for hard float; I think that's not well supported with EABI [13:38] *pre-built [13:38] lool: we do already, but we don't support them [13:38] http://tinderbox.dev.gentoo.org/default-linux/ [13:38] nope, no hardfloat [13:38] armin76: what's your optimization level for your public binaries? [13:38] v5/6/7? thumb2? [13:39] armv5tel-softfloat-linux-gnueabi [13:39] Hmm that's old [13:39] I guess you miss hardware for higher than v5 [13:39] yep [13:39] why do you think i'm always saying that stuff i say? :) [13:40] hehe [13:42] i got an efika mx now, though [13:42] The one in a nice case? [13:42] * asac runs update-initramfs in verbose mode [13:42] yep, but its a lange board anyway [13:42] armin76: Did you get a BSP / linux source code with it? [13:43] lool: yes [13:44] Linux efikamx 2.6.28-ER1-efikamx #4 PREEMPT Sat Nov 28 16:47:52 CST 2009 armv7l GNU/Linux [13:44] armin76: Oh nice, so you can easily redistribute these patches right? [13:44] asac, ogra: ^ we could at least start from these patches [13:44] AFAIK we still have no public patch stack from pegatron [13:45] lool: you should ask neko @ #efika [13:45] He came around here once [13:45] there's no patch, only patched source [13:45] That's "ok" [13:45] The only thing I need is a public source for it [13:45] s/I/we [13:46] Until now we only had non-publishable patches because of foo or bar [13:46] Isn't that why we have diff? [13:46] http://pastebin.com/f1b2e2ab5 [13:47] The Netwalker sources (another i.MX51) are also open and available to the public. [13:47] persia: I mean a public location to retrive some form of source [13:47] persia: Good luck splitting the imx51 stuff apart with diff though [13:47] Well, true, but it's better than nothing, no? [13:47] lool: they aren't public though, they are included in the ssd [13:48] asac, looks dfine to me [13:48] ogra: the produced initrd is better: [13:48] weird [13:48] oh no [13:48] lool: i'll exchange them with a dove *g* [13:48] sorry misread [13:48] -rw-r--r-- 1 root root 1196802 2009-12-10 14:43 initrd.img-2.6.31-601-imx51 [13:49] s/with/for [13:49] well [13:49] 11M is still better than 16 [13:49] ack [13:49] asac, i really think we need to compare the contents [13:49] that's 1 MB? [13:49] 1196802 => 1 196 802 [13:49] ogra: the contents i already posted [13:49] http://pastebin.com/f98ce43d [13:49] those are all the modules added [13:50] hmm [13:50] i mean unpack both initrd files [13:50] and then run diff on a find output [13:50] ogra: i have those unpacked [13:50] ogra: thats what the paste is about [13:50] just for the modules [13:51] oh, i was confused because it only shows the kernel dir [13:51] yes. because the kernel modules dir has a different name [13:51] so i ran inside [13:52] ah [13:52] lets compare the two configs [13:52] ogra: http://pastebin.com/f7538b9e5 [13:53] thats the diff for all (ignore the modules) [13:53] so for me it feels like this crypt* stuff is a good target [13:54] thats all new at least [13:54] ah ! [13:55] usr/share/initramfs-tools/hooks/cryptopenct usr/share/initramfs-tools/hooks/cryptpassdev [13:55] usr/share/initramfs-tools/hooks/cryptopensc usr/share/initramfs-tools/hooks/cryptroot [13:55] /lib/frimware ... [13:55] how big is that [13:55] # This list needs to be kept in sync with the one defined in passdev.c [13:55] for fs in ext3 ext2 vfat reiserfs xfs isofs udf; do manual_add_modules "$fs" > /dev/null 2>&1 || true [13:55] done [13:55] thats a bunch of new fs modules [13:55] i guess [13:55] let me check [13:55] ogra@osiris:/var/build/images$ du -hcs /media/bb4fdb28-11f1-4c72-a345-cc7006aa4898/lib/firmware/ [13:55] 12M /media/bb4fdb28-11f1-4c72-a345-cc7006aa4898/lib/firmware/ [13:56] thats karmic [13:56] 2M difference in lucid [13:56] 13700 lib/firmware/ [13:56] ogra: all the fs above are definitly one part [13:57] yeah, that adds up :/ [13:57] though i dont get why the casper initrd isnt that big then [13:57] image building should have failed [13:58] the casper initrd.lz is 2.8M [13:58] cryptroot also adds a bunch of get_device_modules [13:58] yes thats odd [13:58] that might shrink by 1M due to lzma [13:58] +./kernel/net/netfilter/xt_esp.ko [13:58] but all that netfilter module stuff [13:58] where got that added? [13:58] but then it would still be only 3.8M [13:59] kernel config [13:59] hmm [14:00] 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] Launchpad bug 494667 in squashfs "[armel] non-ISO-C misaligned pointer punning causes slowness and SIGILLs" [Undecided,New] [14:00] ogra: but the "net" modules are explicitly listed in hook-functions [14:01] so those are pulled in from somewhere else [14:01] you say that hook-functions also looks somewhere else? [14:01] you mean the NIC drivers or netfilter ? [14:01] ogra: no ... i mean all the netfilter/* modules [14:01] they are now added [14:01] http://pastebin.com/f98ce43d [14:01] +./kernel/net/netfilter/xt_esp.ko [14:01] ... [14:02] also [14:02] +./kernel/net/bridge [14:02] ... [14:02] generally modules are added from hook-functions [14:02] +./kernel/net/ipv4 [14:02] ... [14:02] 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] but every hook script can put additional modules in [14:02] ogra: i am going to build a BabbageImageFromScratch, but how to get the latest initrd.img? [14:02] ogra: really look in this: http://pastebin.com/f98ce43d tats really a huge amount of new modules [14:02] ogra: yes. but i dont see netfilter anywhere [14:03] feels like it was previously individual files and now its just the full "net" dir [14:03] cooloney, use an old one, boot and run update-initramfs in the running system [14:03] ogra: ok, thanks, downloading. heh [14:03] dmart: thanks. let me read ;) [14:03] cooloney, though if you have anything as module that you need to get the rootfs up, that wont work indeed [14:04] ogra: Why not, as long as the module is in the initramfs? [14:04] persia, because you likely have a version mistmatch [14:05] 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] right, that works for sure [14:06] ogra and persia, yeah, if that works, i can build a new disk with my new kernel installed right? [14:06] just drop the modules into /lib/modules and copy the kernel binary over vmlinuz [14:06] then run update-initramfs [14:06] that will just put them into fis [14:07] ogra: ok, got it. [14:07] ogra: where can i find the armel rootfs? [14:07] dmart: hmm ok. [14:07] how laborious is fixing the C code? [14:07] cooloney, you dont have one installed yet ? [14:08] ogra: i dd the karmice imx51 release image to a SD card. [14:08] oh, you didnt install it ? [14:08] ogra: so i guess this SD already has the rootfs, right? [14:09] ogra: i installed it on a sata driver only, [14:09] it only has the livefs [14:10] ogra: ok, do i need to reinstall i on a SD card or USB disk [14:10] i would recommend USB [14:11] and that installed usb stick contains the rootfs, right? [14:11] cooloney: And a copy of the kernel and the modules, etc. [14:11] It's a full installed system (although there is an extra copy of the kernel and initramfs in some boot location) [14:11] persia: yeah, understand. [14:12] so how big usb stick is enough for that? [14:12] Recommended minimum secondary storage for an Ubuntu installation is 4G. [14:13] I know some people have managed it with far less, but there's no promises it works with less. [14:14] persia and ogra ok, i got it. thanks a lot [14:30] JamieBennett: what did we find so far for casper speed? anything we could fix easily? [14:42] 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] kk [14:43] we should at least carry tha tupstream though [14:43] dmart: why did this start to happen in lucid only? and only on that hardware? [14:43] ... hang on ... [14:44] 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] I've added that suggestion to the bug, and I'll give it a try. [14:45] dmart: Would it just be building mksquashfs with -marm, or would the contents matter? [14:45] ok. i think -marm feels acceptable. its not something that impacts user machines. [14:45] asac: Doesn't it affect rootstock users? [14:46] persia: Do you mean the squashfs contents? I think that shouldn't matter [14:46] yes. but thats development tool ;) [14:46] so ... developer machines ... or am missing something ? [14:46] Well, most users *are* developers today :) [14:46] 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] 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] thanks dmart [15:02] 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] hmm [15:03] I found the issue. cf. http://packages.qa.debian.org/s/squashfs-tools.html [15:04] 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] ack [15:04] should get removed from our arch too then [15:04] 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] hmm [15:05] yeah [15:05] 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] dyfet: also look at the package rename at that time maybe [15:05] linux ? [15:05] you cant remove linux from armel, it builds versatile [15:06] 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] ah [15:06] i missed the meta reference :) [15:06] Okay...adding -marm itself for arm arch seemed simple enough for squashfs-tools... [15:06] 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] guess there is no way to fire off ubiquity at install stage ? [15:07] dyfet: thanks. check if we also want to get the new source from debian or something [15:07] (where hitting about the head is the --only-source parameter) [15:07] asac, can you elaborate [15:07] maybe two steps [15:07] (except this fails for some reason as well :( ) [15:07] asac: is there already a bug for this? [15:07] ogra: well. want to trial and error change hooks etc. to see what is adding all those modules [15:07] asac, https://wiki.ubuntu.com/ARM/BabbageInstallVariants only ubiquity ? [15:08] ogra: and update-initramfs in chroot yielded a 1.6M initrd only [15:08] ah, thats what you want [15:08] ogra: i am in a live sesssion. ... wanted to rerun just the last step that triggers that [15:08] no, it needs to get to the end of the install sadly [15:08] 1.6M seems to small [15:08] ogra: so what is different from just running update-initramfs in chroot? [15:09] good question [15:09] which is where i had the verbose output [15:09] ogra: how to best mount dev? [15:09] seems like ubiquity doesnt mount /dev completely [15:09] and the crypt hooks complain about /dev/null non-existing [15:09] oh [15:09] that sounds buggy [15:09] did you check /dev in your initramfs ? [15:09] *g* [15:10] hmm. not inside it. i checked it in the /target mounted chroot [15:10] probably it copies any virtual fs [15:10] and there only /dev/pts is mounted [15:10] yeah, for apt [15:10] it should mount dev and friends dynamiocally [15:10] are you saying that the hooks are run even in the initramfs? (e.g. not in the /target) ? [15:10] no [15:10] ok [15:11] asac: Are you trying to update a live image and then reboot it? [15:11] 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] persia, he tries to find out how update-initramfs is run from ubiquity [15:12] asac, grep the ubioquity code is my best suggestion [15:12] i see that its just run. but not sure what env it is run it ;) [15:12] 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] also i wonder why there is no /dev/null in /target ;) [15:13] ok had to run the install anyway. seems that failing flash busts the SD card somewhat [15:13] /dev gets bind mounted dynamically [15:13] so i had to re dd that [15:13] ogra: the full /dev? [15:13] odd ... i will check that [15:14] only saw devpts mounted [15:14] but if its always unmounted that might explain it [15:14] will just do it then [15:14] check the code, it should have some function like "prepare_chroot()" or some such [15:14] yep [15:14] that calls the mount commands dynamically right before update-initramfs grub-install and other commands that need it [15:15] might be named differently ... prepare_target or so ... i dont remember the actual name [15:16] right it bind mounts /dev [15:16] if not os.path.exists(os.path.join(self.target, 'proc/cmdline')): [15:16] self.chrex('mount', '-t', 'proc', 'proc', '/proc') [15:16] if not os.path.exists(os.path.join(self.target, 'sys/devices')): [15:16] self.chrex('mount', '-t', 'sysfs', 'sysfs', '/sys') [15:16] misc.execute('mount', '--bind', '/dev', os.path.join(self.target, 'dev')) [15:16] its called chroot_setup [15:16] ah, right [15:17] ok great. odd that it it leaves devpts mounts behind though ;) [15:17] will check in a few minutes when install failed [15:17] devpts is used by dpkg/apt for logging [15:17] they might be needed at that stage [15:18] ogra: To console? [15:18] to nothing ... i dont even think they are actually used [15:18] but dpkg spills errors if it cant find them at the start of a package install [15:18] i think its just kept around to quieten that [15:18] * persia thought logs went to /var/log/* and to [15:19] i think d-i and ubiquity only log to /var/log/* ... d-i just runs a tail -f on tty4 [15:19] asac: just got back, see https://wiki.ubuntu.com/ARM/CasperSpeedup [15:19] persia: what is universe-contributor about? [15:20] my nm student wants to apply there, but i am not sure if he really should do that rather than motu [15:21] JamieBennett: the more detailed analysis is the script content? [15:21] like for 10adduser? [15:21] 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] asac, i think debconf-communicate generally has speed issues [15:22] asac: https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu%20Contributing%20Developers [15:22] asac: yeah, the timings are there for each slow part (i.e. a chroot or a locale generation e.t.c) [15:23] (and feel free to have someone talk to me directly, either here or on oftc about that stuff) [15:23] 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] persia: but is that really something developers should apply for? [15:23] i mean developers that already do development for ubuntu? [15:23] asac: ues [15:23] (after that i will go to some other channel ;)) [15:23] asac: Well, it depends on what they are doing. Contributing Developers get @ubuntu.com email and authority to represent the Ubuntu project. [15:24] There's no related specific upload rights. [15:24] 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] persia: kk [15:25] thx [15:26] asac: By the way, I suspect you're a member of the team (likely through inheritance). [15:26] he slacks [15:26] * armin76 runs === bjf-afk is now known as bjf [15:27] feels like i keep my old stuff for ever [15:28] at least for the next 6 month i dont see any change :( [15:28] just stop doing it :) [15:28] ignorance ftw ! [15:28] 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] 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] who cares, in one year we'll all use armel devices with chromium [15:29] yeah. still distro reputation can go down quickly [15:29] * persia will probably stick to epiphany [15:29] also mozilla sues us ;) [15:30] in worst case making our brand damage reponsible for loosing their google money at some point ... that would be expensive ;) [15:30] heh, i would like to see them actually sueing anyone [15:30] did they ever enforce their policy at court ? [15:30] trademark? [15:30] yep [15:30] no. but they managed to get all distros not using it [15:30] but three: ubuntu/suse/redhat [15:31] yep [15:31] so i am sure they will be able to enforce it [15:31] 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] right [15:31] (well, perhaps not in some jurisdictions, but at least for most of the places they really care about) [15:31] 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] enjoy [15:44] dyfet: thanks for drafting the ooffice spec. in the work items i added a few options (from minimal to almost-perfect integration) [15:44] do those make sense? can you add them to the implementation section too? [15:47] hmm. noticed that bindmounting /dev is slightly different from the original /dev [15:47] like /dev/shm has different attributes in /dev than in the bindmounted location [15:47] odd [15:47] bindmounting /dev/shm somewhat fixes this [15:47] shouldnt cause our issues though [15:47] asac: I realized when reviewing specs that it got lost from when we did the original split.... [15:48] ogra: no. but it cauess issues for chromium when run in chroot [15:48] it uses /dev/shm for sandboxing [15:48] ah [15:48] dyfet: right. thanks a lot [15:49] 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] put that to implementation section [15:49] ok [15:49] problem is that its pretty hard to do the integration compared to mailto: [15:49] thats why i want three potential solutions to be in there [15:49] yea...I was thinking about that issue :) [15:49] 1st. simple bookmark+ open browser integration [15:49] 2nd. auto import when double clicking (but no back and forth synch) [15:50] 3rd. gvfs gdocs mount for Documents folder [15:50] i think those are the approaches i put into the work items ... having a sentence for each would be good [15:54] asac: so your suggesting we turn the document into a browser bookmark entry? [15:55] 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] no import etc. [15:55]