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