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