| Summary: | Full unicode support in ncurses | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | prezi77 |
| Component: | Other | Assignee: | Gustavo Zacarias <gustavo> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | buildroot |
| Priority: | P5 | ||
| Version: | 2014.02 | ||
| Target Milestone: | 2014.11 | ||
| Hardware: | All | ||
| OS: | All | ||
| Host: | Target: | ||
| Build: | |||
|
Description
prezi77
2014-03-12 10:50:16 UTC
Patches for ncurses wide support have been proposed before, last version by Jeremy Kerr: http://patchwork.ozlabs.org/patch/329289/ The topic has been discussed here too: http://lists.busybox.net/pipermail/buildroot/2013-October/080673.html From this discussion, I don't see a blocking problem in accepting the mentioned patch. There was some debate about the fact that ncurses allows to either build non-widechar, or widechar, but not both at the same time. In Jeremy's patch, the user has to choose which one he wants. An alternative solution was to create two separate packages: ncurses and ncursesw. So according to me, we either accept Jeremy's patch (possible refreshed) or someone should implement the split package approach. Input? (In reply to comment #1) > So according to me, we either accept Jeremy's patch (possible refreshed) or > someone should implement the split package approach. > I suggest you to use Jeremy's patch. It has one import advantage: it exists. Ncurses is uses by approximately 60 packages: alsa-utils aumix avrdude bash bmon bwm-ng cvs dialog dropwatch erlang gdb gnupg gpm gpsd gptfdisk htop httping iftop joe kismet lame latencytop lcdproc less libcdio libedit liboping lua luaposix lvm2 minicom mtr mutt mysql nano ncdu ncftp ncmpcpp ncurses ola procps proftpd psmisc python python3 readline rtorrent ruby screen sqlcipher sqlite statserial tmux tn5250 uemacs util-linux vim xterm zsh I suppose it is possible to patch makefiles to link to ncursesw. Some of them uses ncursesw natively. After discussing with Gustavo on IRC, the split package approach seems best. Hopefully this can be finished by 2014.08 (doing this in the upcoming release 2014.05 is no longer possible.) Gustavo has sent a few patches to the list to implement the shared package approach. However, I lost track of the overall status of this. Gustavo, could you summarize the status, and make an assessment of whether this could still be done for 2014.08 or whether we better go for -next? Jeremy's patch http://patchwork.ozlabs.org/patch/360317/ is mostly ok but it doesn't consider the static lib scenario as mentioned in the thread. I've run an allyespackageconfig with ncursesw enabled and fixed some packages, however nano needs a patch http://patchwork.ozlabs.org/patch/367145/ that depends on the config option being present (hence not committed yet). I can respin Jeremy's patch if he doesn't do or just add a fix patch after his one is committed for the static libs (+nano ncursesw). This is all pretty safe according to my tests, however the usual policy is no feature patches in release candidate (frozen) state, so i'm defering this to the 2014.11 milestone. The patches from Jeremy and Gustavo have been committed: http://git.buildroot.net/buildroot/commit/?id=74efae025371fbb0540f3184c66a1fd0a3c34abd. Marking bug as fixed. |