These are scripts from the validation repository used to test various
functions on the board.
* Used standard mplayer (avoid creation of a limited function
mplayer).
* Included kernel modules and wifi firmware.
* Included cpufrequtils.
* Used standard mplayer (avoid creation of a limited function
mplayer).
* Included kernel modules and wifi firmware.
* Included cpufrequtils.+ dosfstools \
+ e2fsprogs \
+ e2fsprogs-mke2fs \
Are those really needed for validation? This is more suited to a rescue fs.
+ mplayer \
The PSP test apps or Sergios test app are a lot smaller. Ask Vaibhav if we can make those utils public, they are really usefull.
+ kernel-modules \
Are those really needed for validation? They only drag in uImage (which we don't need) and lots of optional drivers that aren't needed for validation.
+ nano \
Busybox vi isn't good enough? It's a ramdisk, not a complete distro.
RRECOMMENDS_${PN} += " \
+ rt73-firmware \
+ zd1211-firmware \
Why are those needed? And more importantly, can those actually be distributed in a ramdisk?
regards,
Koen
+SECTION = "devel"
Really?
+PRIORITY = "optional"
That's the default, remove
+PV = "0"
Really?
+PR = "r1"
Initial recipe, so remove PR
Looks OK for the reset, put run it thru contrib/oe-stylize.py for good measure. Oe-stylize isn't 100% correct, but usefull nonetheless.
regards,
Koen
* Used standard mplayer (avoid creation of a limited function
mplayer).
* Included kernel modules and wifi firmware.
* Included cpufrequtils.+ dosfstools \
+ e2fsprogs \
+ e2fsprogs-mke2fs \Are those really needed for validation? This is more suited to a rescue fs.
I think having them for rescue purposes is good justification.
+ mplayer \
The PSP test apps or Sergios test app are a lot smaller. Ask Vaibhav if we can make those utils public, they are really usefull.
We need something ASAP. Any way to trim this one down?
+ kernel-modules \
Are those really needed for validation? They only drag in uImage (which we don't need) and lots of optional drivers that aren't needed for validation.
For people trying out the board, I'd think that having their
peripherals work more often than not is a good thing. Yes, that is
more of a software validation than a hardware validation, but still.
I'll go ahead and remove them for now, but I think it significantly
hurts the experience.
+ nano \
Busybox vi isn't good enough? It's a ramdisk, not a complete distro.
I haven't looked at the size of 'nano', but this is my image where I
get people into a known environment and try to help them through
various issues. Getting them in and out of vi is tough.
RRECOMMENDS_${PN} += " \
+ rt73-firmware \
+ zd1211-firmware \Why are those needed? And more importantly, can those actually be distributed in a ramdisk?
Removed.
+SECTION = "devel"
Really?
Yes, OE really is a confusing mess without a good introduction.
+PRIORITY = "optional"
That's the default, remove
+PV = "0"
Really?
Again, OE really is a confusing mess.
+PR = "r1"
Initial recipe, so remove PR
Looks OK for the reset, put run it thru contrib/oe-stylize.py for good measure. Oe-stylize isn't 100% correct, but usefull nonetheless.
done.
regards,
Koen
opkg stuff seems to take a bunch of space. Any way to reduce that easily?