=== lbt is now known as lbt_ [09:37] cooloney, this is not funny ! everytime i file a bug you already have a fix prepared ... moaning and grumbling isnt fun anymore this way :) [09:37] j/k indeed :) [09:38] thanks for the devtmpfs fix, i'll test it later today [09:38] ogra: Consider it an exercise in testing expectations. The set of solutions may be vast, but you only get that for which you've asked :) [09:39] heh, yeah :) [10:24] persia: do you know why a bunch of channels like -motu etc. require you to be registered now? [10:24] what incident triggered this ... and is that permanent? [10:24] someone said there was a spambot attack on weekend ... [10:25] but i am sure we had that before ;) [10:25] * persia is laggy because of a meeting, but will post the URL [10:26] http://blog.freenode.net/2010/01/javascript-spam/ [10:27] Should be sorted by next week. tsimpson is monitoring and coordinating. [10:30] ok [10:30] but someone must have followed on our side and set +R on the channel [10:30] was there really a big problem? [10:30] i havent seen it and i was more or less regularly online [10:32] It's been a reasonably large issue in some channels. [10:32] tsimpson has been handling things. [10:32] I haven't set +r or +R here yet because I haven't seen spam. [10:33] But I only track ops stuff in -motu, -devel, and -arm, so I may be missing bits. [10:33] * persia should probably go find out the status of -mobile, and handle that as well [10:33] persia: -devel seems to have the problem too [10:33] e.g. i dont autojoin there somewhat [10:33] anymore [10:33] Yes. There was vast quantities of spam, and tsimpson made it go away. [10:33] its -devel -motu -bugs -desktop it seems [10:34] The solution is annoying, but like I said, we only need it until the end of the week. [10:34] And -meeting, at least. [10:34] Probably more. [10:34] hmm ok [10:34] -meeting seems to be ok [10:34] The flags get turned on and off depending on how much we get hit. [10:34] ok, i got hard numbers for uboot vs redboot now: [10:34] You happened to join at the right time. [10:35] Anyway, people are working on it. I'm watching them work on it. It will be all over this weekend :) [10:35] * persia goes back to paying attention to the meeting [10:35] stopwatched to "uncompressing linux" with nearly identical setup (no boot.scr for uboot and the like which adds extra load time) [10:35] uboot: 23 sec [10:35] result? [10:35] redboot: 11sec [10:35] yeah. thats ho wit feels [10:36] :( [10:36] the mmc driver alone takes half of that time at least [10:36] i guess [10:36] the loading isnt the part thats slowing down most though [10:36] its the part wheer it unpacks the uimage/uinitrd that seems to add extra time [10:36] JamieBennett: hi ... did you file the final MIRs for launcher? [10:36] i think there is one still missing? [10:37] netbook-launcher-efl [10:37] asac: should all be there [10:37] ah [10:37] i see it [10:37] bug 512343 [10:37] Launchpad bug 512343 in netbook-launcher-efl "[MIR] netbook-launcher-efl" [Undecided,New] https://launchpad.net/bugs/512343 [10:37] :) [10:37] also redboot doesnt separately initialize HW like uboot does ... i.e. the mmc is initialized directly where uboot needs to exec a command [10:37] asac: now just need to prode someone to review it [10:37] JamieBennett: did the other packages all get accepted now? or are there some with outstanding issues left? [10:38] asac: all accepted [10:38] yes [10:38] just need n-l-e then I'll update the seed [10:39] Does it need wncksync? normal netbook does, which is causing some issues now (needs another MIR) [10:41] persia: no unless someone changed it without me looking [10:41] ok assigned ... lets see [10:42] asac: thanks [10:42] if it doesnt go quick (like by tomorrow) let me know [10:42] will do [10:42] i finally want this to be ready for the flip [10:42] ;) [10:43] as do I along with the casper stuff I'm doing [10:43] right [10:43] JamieBennett: how is the fix going? [10:43] for caching the db/template? [10:43] Really close, hope to have something sometime today. [10:44] really cool [10:44] I think it will shave about 30% off of the live-cd boot time if not more :) [10:45] i hoped for 50% ;) [10:45] j.k. [10:45] maybe ;) [10:46] It takes *3 minutes to boot* so knocking that down to 2 minutes helps :) [10:46] and we have time to improve further [14:18] asac, so, on imx51 after install the SD still has a vfat partition with the livefs that always gets automounted on the desktop ... we cant wipe it during install because its mounted ... i researched a bit and it seems partitions labeled "RECOVERY" will never be automounted, any objections if we make our livefs partition on the imx51 image a recovery one ? [14:19] (filesystem still stays as is, it just gets an extra label (one line change in debian-cd)) [14:22] ogra: does that have other implications? [14:22] like something offering to recover system from there? [14:22] and then everything gets trashed or something? [14:22] well, we could provide a script that turns the SD into a install media again :) [14:23] but by default it simply would not mount the partition [14:23] i just dont want to have the Sd icon on the desktop all the time after install [14:24] and the user could happily reformat the partition to actually make use of the space (the label would be gone then) [14:24] there is nothing that would react on a recovery patition elsewhere [14:25] so nothing would "offer to recover system from there" or some such [14:25] (though we could write somethng easily as i said above and sell that as a feature ;) ) [14:36] sounds pretty useful actually [14:37] the recovery option you mean ? [14:39] or not having the SD mounted all the time [14:43] making use of the recovery partition as both a solution, and an added bonus [14:44] well, as asac said above its a pretty dangerous feature [14:44] so it would require some extra thought how to prevent a user to use it accidentially ... [14:45] for now i just want to prevent mounting ... the idea that we could actually make use of that as a recovery tool just occured to me later [14:45] though that doesnt even require to label the partition [14:45] you just need to flash the initramfs from the casper dir into redboot and change the cmdline back to the livefs one [14:46] ogra: how is the RECOVER feature implemneted? [14:46] thats a three line script [14:46] cant we do the same just for "BOOTFLOPPY" ? [14:46] asac, udev has a rule to ignore all partitions that are labeled in a special way [14:46] we dont needf to do that for BOOTFLOPPY [14:46] it doesnt ahve a filesystem [14:47] i.e. it doesnt get automounted [14:47] # recovery partitions (taken from old hal rules) [14:47] ENV{ID_FS_TYPE}=="ntfs|vfat", \ [14:47] ENV{ID_FS_LABEL}=="RECOVERY|HP_RECOVERY|Recovery Partition|DellUtility|DellRestore|IBM_SERVICE|SERVICEV001|SERVICEV002", \ [14:47] ENV{DKD_PRESENTATION_HIDE}="1" [14:47] thats from /lib/udev/rules.d/95-devkit-disks.rules [14:48] its just to prevent the vfat/ntfs partitions labeled in a special way to get automounted [14:49] ogra: lets take one step back. i think i dont understand whats this about. [14:49] i was under the impression it was aobut the /boot partition on the liveimage [14:49] we planned to have for uboot [14:49] no [14:49] its about the livefs partition we currently use on the imx51 image [14:49] this is a vfat partition containing casper and the squashfs [14:50] because it is mounted during install we cant delete or wipe it [14:50] yes. so i would label it LIVEFS then ;) [14:50] so after install (since you need the SD to boot) that second partition is still there and devkit automounts it on your desktop [14:50] of course we need to ensure it gets still loaded for the live image [14:51] casper doesnt care for labels [14:51] good [14:51] that will only affect the automounting after install [14:51] so why not use CASPERLIVEFS or someting ? [14:51] its a paper cut and a one liner can fix it [14:51] right [14:51] because then i need to patch devkit [14:51] doesnt feel like a big thing [14:51] which i'D like to avoid [14:52] using some other label that doesnt match what we do just because we dont want to touch devdisk isnt great either [14:52] well [14:53] its essentially is a recovery partition [14:53] there is just not anything that makes use of it [14:53] a recovery partition is something else in my book [14:53] usually recovery partitions can be check pointed etc. [14:53] oh that is backup [14:54] so yes. if you are sure that a recovery partition would be a casper partition then its fine [14:54] but only if thats really the case ... is it? [14:54] with a littel script that turns the SD back into a live image it is a recovery partition [14:55] but indeed that would trash your install (as recovery tools often do) [14:55] what i am wondering is if there already is such a thing like ubuntu recovery partitions [14:55] i dont think so [14:55] if there is we shouldnt reinvent the wheel [14:55] i just want to prevent automount for now :) [14:55] we could use an uglier way though [14:55] see type 12 on http://www.win.tue.nl/~aeb/partitions/partition_types-1.html [14:55] for me it feels bad to reuse a label that has a meaning [14:55] if its not true [14:56] rather we should really add a new label [14:56] and getting that into udev-disks doesnt sound that hard [14:56] well, i find it uglier to patch devkit than just adding a pointless label [14:57] but inventing a new one surely works too ... its just more patching in different places [14:57] the current list of labels in devkit are just added as needed [14:57] at least they look like [14:57] # special MBR partition types (EFI, hidden, etc.) [14:57] # see http://www.win.tue.nl/~aeb/partitions/partition_types-1.html [14:57] ENV{DKD_PARTITION_SCHEME}=="mbr", \ [14:57] ENV{DKD_PARTITION_TYPE}=="0x00|0x11|0x12|0x14|0x16|0x17|0x1b|0x1c|0x1e|0x27|0x3d|0x84|0x8d|0x90|0x91|0x92|0x93|0x97|0x98|0x9a|0x9b|0xbb|0xc2|0xc3|0xdd|0xef", \ [14:57] ENV{DKD_PRESENTATION_HIDE}="1" [14:58] i dont see why we cant add UBUNTU_CASPER there [14:58] thats not as needed [14:58] does casper mount 12? [14:58] but i dont want to play with the type if there is an easier way [14:58] casper looks for filesystems [14:58] so type shouldnt matter as long as its vfat [15:00] so yeah. lets use that [15:00] unless you see a reason against that [15:00] ogra: do bootloaders agree? [15:00] like uboot recognizing that? [15:01] does uboot matter ? [15:01] it doesnt use that partition [15:01] initramfs is the only thing that counts here [15:01] i.e. casper [15:01] oh [15:01] well. i thought if we used uboot we could boot the initfs and kernel from the casper cd [15:02] well, you know how uboot works :) [15:02] it loops over the vfat/ext2 partitions it finds [15:02] as long as fatload works it wont care for partitioning or types [15:03] i.e. the FS counts [15:03] ogra: i know that it does that, but i dont know 100% that it doesnt check fs type first [15:03] but if you say it doesnt then i believe you [15:05] it looks for the fat signature, doesnt care for label or type [15:05] so both should be fine to use [15:12] asac, but i dont want to play with the type if there is an easier way [15:12] ah [15:12] well. seems we can do everything on our own udev rule ;) [15:12] i prefer LABEL its less dangerous [15:12] right, so it doesnt matter :) [15:13] we can even use an arch specific label then [15:13] BABBAGE_LIVEFS or some such [15:14] yeah. if that makes most sense, go for it [15:14] yup [15:14] we can make it more generic if needed [15:14] later [15:14] * ogra looks how to do that from casper without slowing it down with additional bloat [15:44] ogra, I thought the goal with imx51 was to have it put its bootloader right into SPI-NOR and remove the need for the boot floppy approach to power up [15:45] NCommander, with uboot, yes [15:45] but we're unlikely to do uboot [15:45] ogra, what was the major hangup with uboot (sorry, I think I missed part of the conversation here yesterday) [15:46] you seem to have missed the whole meeting today :P [15:46] uboot still needs /boot on SD [15:46] ogra, oh, right. [15:46] * NCommander is not quite on his A game this morning [15:47] which would mean we'd need to a) build out images with three partitions and b) still use the bootfloppy [15:47] and that for losing about 15 seconds bootspeed [15:47] * NCommander puts the dunce cap on and stands in the corner [15:48] Oh well, at least we can have a uboot+imx51 spec again for lucid+1, continuing a UDS tradition [15:48] beyond that it would require awful ubiquity hackery to make ubiquity reformat /boot and all during install on a mounted media [15:49] i dont think i'll support uboot until USB support appears ... [15:49] so likely ... never ... [15:49] i.e. likely no lucid+1 spec [15:52] * ogra dist upgrades his arm chroot to build new redboot [16:00] hello Stskeeps, I see you are everywhere :P [16:01] I was going to ask about the default gcc flags used in karmic build [16:03] I was expecting an improvement of performance over 9.04 on a armv6 device [16:03] but it turns out that it is 50% slower [16:03] specially perl and scripting languages [16:04] I guess it is related to vfp, but not sure [17:19] shesh ... we'll do a jump from 200938 to 200952 with redboot [17:25] ogra: It's just ww [17:26] ww ? [17:26] work weeks [17:26] ah [17:26] well, i expect some bbg3.0 additions [17:26] I can assure you there wont be a 200953 :-) [17:26] lol [17:26] So it's effectively 2 months of development or so [17:27] yeah [17:27] well, i didnt expect to touch redboot again at all :) === bjf is now known as _bjf [17:46] * ogra grumbles [17:46] dpkg-source: warning: executable mode 0755 of 'debian/patches/02_freescale_imx51.dpatch' will not be represented in diff [17:46] why the heck do all patch editing tools create them with executable bit then [17:46] tsk [17:46] Only dpatch actually [17:47] Because it's a shell script too [17:47] cdbs-edit-patch too [17:47] Which is why I hate dpatch [17:47] ogra: Really? never seen that [17:47] ogra: Perhaps cdbs-edit-patch if it's a dpatch [17:48] no idea, i only usually edit existing ones with it and afterwards i usually get this warning [17:48] cdbs-edit-patch has no chmod or umask calls so I don't think it's the culprit [17:48] weird [17:49] ok /me crosses fingers that the build fiup patch still applies and runs debuild -b for redboot [17:50] *fixup [17:51] * ogra cries [17:51] /tmp/ccszJnU4.s: Assembler messages: [17:51] /tmp/ccszJnU4.s:473: Error: shift must be constant -- `orr r11,r10,r9,lsl r5' [17:51] The warnings are benign anyway; these are only an issue if you actually want the file to have this mode once installed and no tools ensure it does at build time (such as dh_fixperms or dpkg-builddeb) [17:52] That looks like a broken patch [17:52] no, thats thumb [17:52] needs -marm [17:53] i was expecting it (every other bootloader i built did need -marm) but was hoping to save the time [17:53] Hmm I thought lsl was an instruction but it's actually a register [17:53] Hmm no it's definitely an instruction; I wonder what it's doing in your line [17:54] no idea [17:55] Besides orr is supposed to take two args, bah I don't read arm assembly very well :-( [17:56] orr r0, r2, lsr #8 is like r0 |= (r2 >> 8) [17:56] and you can't shift by a register in thumb mode apparently [17:57] right [17:57] as i said, needs -marm ... [17:57] like apex does as well as uboot does [17:57] i'm happy if its only that though [18:00] root@babbage2:/redboot-imx-200952# chmod a-x debian/patches/* [18:00] dpkg-source: warning: executable mode 0755 of 'debian/patches/03_build_fixups.dpatch' will not be represented in diff [18:00] TSK ! [18:03] Yeah hug dpatch === lbt_ is now known as lbt [18:11] god, so many warnings [18:12] the quality degrades with every release ... but it builds [18:12] dpkg-deb: building package `redboot-imx51-babbage' in `../redboot-imx51-babbage_200952-0ubuntu1_armel.deb' [18:12] ha! [18:12] * ogra takes a break until conf call ... [18:46] 19:45 < Riddell> asac: just accepted chromium, well done again on a heroic license evaluation feet [18:57] wohoo '!!!!! [18:57] congrats [18:57] what does that mean? [18:58] that chromium is in the archive [18:58] oh [19:13] http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=tree;h=refs/heads/imx_2.6.31;hb=imx_2.6.31 <- from #efika === zenvoid_ is now known as zenvoid [19:21] armin76: Cool [19:22] lool, yeah, in case you didnt notice there is http://opensource.freescale.com/git since a few days :) [19:26] Yeah I was looking at that, amazing === bradf is now known as bjf [19:26] :) [19:26] Linking to an obsolete uboot homepage :) [19:26] heh [19:27] ltib -- never heard of that [19:27] Apparently a decently old project [19:28] yeah, it's freescale's own bsp distro [19:28] Oh it's developed by freescale? [19:28] yes [19:28] yeah, they've used it on ppc for quite a while I think [19:28] its also carrying the linux trees of the BSP patches [19:28] never really looked at it, we preferred to ship a regular distro instead. :) [19:29] ogra: in ppc land, those patches were a tall stack of cr*p. :) [19:29] mostly old versions of patches someone else had cleaned up and merged in newer mainline kernels. seems like their arm side isn't as good. :)