**** BEGIN LOGGING AT Tue Oct 15 02:59:58 2013
Oct 15 09:11:03 <ant_work> bluelightning: gm
Oct 15 09:11:14 <bluelightning> hi ant_work
Oct 15 09:11:59 <ant_work> bluelightning: one more patch to fix jffs2 summary images and the flow is finished ;)
Oct 15 09:13:36 <ant_work> (not that anyone apart zaurus uses sum.jffs2 image fstype. well, yes, hx4700)
Oct 15 09:13:58 <ant_work> the summary adds 6 MB :/
Oct 15 11:12:15 <ant_work> bluelightning: heh, it was an old patch of mine :/
Oct 15 11:12:17 <ant_work> http://cgit.openembedded.org/openembedded-core/commit/meta/classes/image_types.bbclass?id=70a276509f0f006fcc269296afc3dcc88d2825e1
Oct 15 11:12:38 <ant_work> collie has NOR, not NAND, and doesn't need the '-n'
Oct 15 11:13:13 <ant_work> I guess it is wiser to let it as it is (NOR is obsoleted practically)
Oct 15 11:13:25 <ant_work> and rewrite a specific string for collie
Oct 15 11:14:38 <ant_work> ..unfortunately once added '-n' it is not possible to override it adding i.e. '-c 12' opposite option
Oct 15 11:34:38 <ant_work> btw, iPAQ h3100/h3600 had NOR
Oct 15 13:50:31 <ant_work> bluelightning: some machines don't even declare the JFFS2_ERASEBLOCK. I suppose that's because it is '0X40000' as in default in image_types.bbclass
Oct 15 13:50:57 <ant_work> if so, I'm tempted to remove the lines repeating the default value
Oct 15 13:51:08 <bluelightning> what if the default changes?
Oct 15 13:51:17 <bluelightning> (not sure how likely that is, but...)
Oct 15 13:51:19 <ant_work> I'm talking now about th elast patch
Oct 15 13:51:34 <ant_work> +JFFS2_ERASEBLOCK = "0x40000"
Oct 15 13:51:54 <ant_work> is pointless (unless the class changes...)
Oct 15 13:54:12 <ant_work> maybe put it in the common.inc is the best/sure thing to do
Oct 15 13:55:10 <ant_work> bluelightning: anyway, at the end we should have removed many lines from meta-hh ;)
Oct 15 13:55:57 <ant_work> and it still builds for zaurus + h1940 + h3600 + hx4700
Oct 15 13:55:59 <ant_work> :p
Oct 15 14:07:33 <ant_work> bluelightning: oh, what was the command to remove a single item from a list?
Oct 15 14:07:48 <bluelightning> ant_work: command?
Oct 15 14:08:18 <ant_work> topic was how to remove a package from IMAGE_INSTALL iirc
Oct 15 14:09:10 <ant_work> here I'd like to remove '-m' from IMAGE_CMD_jffs2
Oct 15 14:09:27 <ant_work> w/out redeclaring the var
Oct 15 14:09:52 <ant_work> (not that there is way, is in the class...)
Oct 15 14:10:29 <ant_work> actually it does work even with '-m' on collie
Oct 15 14:10:39 <ant_work> so it is not urgent issue at all ;)
Oct 15 14:10:50 <ant_work> seems there is longer boot time
Oct 15 14:10:58 <ant_work> just this
Oct 15 14:12:13 <ant_work> there was a bb function iirc..will check later on
Oct 15 14:25:11 <bluelightning> those are two separate things - PACKAGE_EXCLUDE is for removing packages from the image
Oct 15 14:25:21 <bluelightning> then at the bitbake level there is the _remove operator
Oct 15 14:26:25 <ant_work> ah, ok, mixing things
Oct 15 14:27:14 <ant_work> the point is, devices with NAND need  '-n' while other with NOR supposedly not
Oct 15 14:27:41 <ant_work> now, my old patch made it mandatory for all
Oct 15 14:28:42 <ant_work> I need to test again and see if it really makes difference on collie (h3600)
Oct 15 14:29:30 <ant_work> atm I have a jffs2 read-only image built with '-n' in collie NOR
Oct 15 14:29:51 <ant_work> so the default 'works' at least
Oct 15 14:31:07 <ant_work> I guess many older ipaq do have NOR, seems NAND spread up some years later
Oct 15 16:40:31 <ant_work> bbl
Oct 15 21:20:18 <ant_home> hi bluelightning
Oct 15 21:20:26 <ant_home> patch flood has finished
Oct 15 21:20:54 <ant_home> I'm rebuilding from scratch to retest
Oct 15 21:31:48 <ant_home> bluelightning: once you've seen, we can think about 'securing' the values for JFFS2 now set as defaults in image_types.bbclass
Oct 15 21:32:29 <ant_home> I've minimized the code relying on that defaults
Oct 15 21:32:57 <ant_home> brb
Oct 15 21:32:59 <bluelightning> ok
Oct 15 21:41:13 <ant_home> can we think to group some recipes-bsp in ipaq-utils like done for Z?
Oct 15 21:43:21 <bluelightning> I'm not sure that's the right thing to do
Oct 15 21:43:50 <bluelightning> to be honest I prefer having one recipe (or at least, one upstream) per recipe directory
Oct 15 21:44:35 <ant_home> ok but this layer hosts at least 3 species
Oct 15 21:44:56 <ant_home> technically we'd need two or three layers
Oct 15 21:45:05 <ant_home> BSP
Oct 15 21:45:16 <bluelightning> if we had separate maintainers I'd agree with you...
Oct 15 21:45:19 <ant_home> heh
Oct 15 21:45:35 <bluelightning> I know the ipaq stuff has languished, and that's been my fault
Oct 15 21:45:42 <bluelightning> I really appreciate your cleanup efforts
Oct 15 21:45:43 <ant_home> here one can easily grep at least
Oct 15 21:46:14 <ant_home> what I did NOT test are the 2.6 kernels
Oct 15 21:46:23 <ant_home> I doubt they still build :/
Oct 15 21:54:52 <bluelightning> very likely
Oct 15 21:55:23 <bluelightning> if nothing else they probably don't build properly with make 3.82
Oct 15 22:14:56 <ant_home> btw: The recipe shadow-native is trying ... build from scratch
Oct 15 22:14:57 <ant_home> TARGET_SYS        = "arm-oe-linux-gnueabi"
Oct 15 22:14:57 <ant_home> MACHINE           = "poodle"
Oct 15 22:14:57 <ant_home> DISTRO_VERSION    = "oe-core.0"
Oct 15 22:15:52 <bluelightning> sorry, I'm not following...
Oct 15 22:16:03 <bluelightning> ?
Oct 15 22:16:04 <ant_home> the Yocto #bug you opened
Oct 15 22:16:26 <ant_home> you don't necessarly need to install one after the other
Oct 15 22:16:35 <ant_home> all happens automagically ;)
Oct 15 22:16:54 <bluelightning> sure, I just gave a way to definitely reproduce it
Oct 15 22:17:03 <ant_home> I guess the distinctive factor is DISTRO_VERSION    = "oe-core.0"
Oct 15 22:17:16 <bluelightning> I can see how it could happen without that though if both were scheduled to be built
Oct 15 22:17:39 <ant_home> here it always builds in that order
Oct 15 22:52:08 <bluelightning> ant_home: er, you know those MACHINE_DISPLAY_* variables you killed? removing those will have broken meta-opie...
Oct 15 22:53:03 <ant_home> ouch :/ can you use infos from formfactor?
Oct 15 22:53:21 <bluelightning> I don't know
Oct 15 22:53:36 <bluelightning> probably not if it's not available at parse time...
Oct 15 22:54:38 <bluelightning> same with GUI_MACHINE_CLASS
Oct 15 22:55:27 <ant_home> how many occurrences do you see ?
Oct 15 22:55:39 <bluelightning> well, just one in either case
Oct 15 22:55:53 <bluelightning> doesn't make it any easier to work around
Oct 15 22:56:50 <ant_home> bigscreen/smallscreen is debatable..see how it was used
Oct 15 22:57:11 <ant_home> we have MACHINE_FEATURE qvga, though
Oct 15 22:57:38 <bluelightning> it was used to determine whether large or small icons should be used
Oct 15 22:57:58 <bluelightning> basically bigscreen -> high res icons, otherwise standard
Oct 15 22:58:00 <ant_home> qvga = smallscreen
Oct 15 22:58:17 <ant_home> there are some strange 640x240 half-vga iirc
Oct 15 23:04:45 <ant_home> ok, opie.pics is easy to fix
Oct 15 23:05:43 <ant_home> packagegroup-opie.bb is a bit more troublesome but you could rely on M_F qvga presence as well
Oct 15 23:09:10 <ant_home> bluelightning: build finished well
Oct 15 23:09:12 <ant_home> | core-image-base-poodle-20131015213741.rootfs.jffs2                  | 16496K|Oct 16 01:07|
Oct 15 23:09:12 <ant_home> | core-image-base-poodle-20131015213741.rootfs.sum.jffs2              | 22816K|Oct 16 01:07|
Oct 15 23:09:31 <ant_home> the usual overhead...it means the patches are ok
Oct 15 23:10:18 <ant_home> time to sleep
Oct 15 23:10:20 <ant_home> gn
Oct 15 23:10:25 <bluelightning> cya
**** ENDING LOGGING AT Wed Oct 16 02:59:58 2013