On 8/4/16 2:20 PM, Brian Avery wrote: > The core issue: > The busybox resize command breaks the eclipse ssh debug stream. This is > because the resize command for busybox sends a set of cursor control > escape sequences to stderr. The resize cfg was added to Krogoth and is > still in master. The point of resize is to set the environment and > terminal settings to the current xterm window size. > > Additional complexity: > eclipse-debug is an IMAGE_FEATURE. If it is turned on by a user in > local.conf via EXTRA_IMAGE_FEATURES then I can conditionally turn off > busybox/resize in the cfg file. Unfortunately, if a user makes a new > image with IMAGE_FEATURES += " eclipse-debug " in it, I do not see this > from the scope of the busybox##.bb recipe. > > So, there are a couple of ways to solve this and I'm not sure which is > the best one. > > 1) conditionally turn off the resize.cfg if eclipse-debug is in > extra-image-features. Also, make a rm_resize.bbclass to rm the > usr/bin/resize from the rootfs in a do_rootfs[postfuncs] which can be > inherited by the various sdk images we build. > > This is problematic since if a user makes a new image recipe of their > own and includes eclipse-debug but doesn't inherit the rm_resize.bbclass > eclipse debug will fail. > > 2) elevate eclipse-debug to a distro feature which would make it visible > to the busybox###.bb recipe. Unfortunately, it is really an image > specific set of packages to be included so elevating it doesn't seem > reasonable. > > 3) use the update-alternatives method (busybox is currently doing this > for syslog) to make a separate busybox-resize package and make an > eclipse friendly resize package that is empty and add the eclipse one to > the eclipse-debug packagegroup. > > 4) Just turn off resize or patch it so it doesn't try to control the > cursor via escape sequences sent to stderr but still sets up the > environment. It's worth noting that the ubuntu resize doesn't send > escape sequences to any of the streams.
this seems to be best option. > > 5) Something else? > > Thanks, > Brian > an Intel employee > > > > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
