Hi Jon and Chase,
> On Jan 26, 2021, at 18:56, Jon Trulson <j...@radscan.com> wrote: > > On 1/25/21 8:54 PM, Lev wrote: >> Hi Jon, >> >> Thank you for committing that, it should be the last ksh93 patch. Did you >> get a chance to look at the other five patches I sent on 17th? I don’t >> believe they are in yet. >> > > I must have missed them... I remember skipping some of them because I had > already applied them. If I look at the log in master, there are several > patched from you regarding musl... > > If there are some I missed (possible since some of them were embedded in > threads), re-send them (minus any ksh stuff) and I'll merge them. Thanks, I’ve attached the (rebased) patches. > >> I don’t know if this got lost in the shuffle, but since you mentioned >> potentially fixing autoconf as an alternative to imake, I am curious if you >> have any thoughts on Thomas Dickey’s fork of autoconf 2.59 >> (https://invisible-island.net/autoconf/ >> ). I doubt I would be able to match the excellent work he’s done in order to >> keep xterm and ncurses compiling everywhere (even OS/2 and VMS), but as far >> as I can tell, upstream is not interested in these patches. >> > > Ahh... no I wasn't proposing to take over autoconf development :) > > There is another CDE branch called autotools-conversion. A lot of work is > already done and most of CDE can be built. I just need to get that finished > and then the imake support would be removed and the result merged into > master. This probably won't happen for awhile, so imake is safe for now :) Alright, I think that was a misunderstanding on my part on then. The incompatibilities aren’t with CDE’s autotools support but the autotools themselves. About the ‘adopting imake’ comment: I tried to get some context on what spurred the autotools conversion in the first place and found ’The sorry state of imake’ thread. Chase, if you wouldn’t mind, was Alan Coopersmith still looking for a maintainer last time you spoke? > >> Also, if you don’t mind my asking, whatever happened to Accelerated-X? It >> seems that X.org >> development is slowing considerably with the ascendance of Wayland. >> > > XiG died in 2012... It was a good run. It's the second company I worked for > that I got in early, and then had the misfortune to ride it down into the > dirt. I have several million shares if anyone's interested... :D > > But WRT Wayland, I've been hearing that it's going to kill X11 for over a > decade now. I will believe it when I see it :) > > But yeah - no one is 'innovating' in X11 anymore, it's "Done". > > One thing I really depend on a lot is the ability to run X11 apps over the > network. I do not think that is possible in wayland - maybe via their > Xwayland stuff? Haven't really looked very deep into Wayland in a few years. > > -jon Sorry to hear that. Did anything survive regarding its architecture? I remember it required a kernel module, but I can’t remember the reason why instead of writing to the card’s framebuffer in /dev/mem. I wonder if X11 could have taken a different path, and I imagine you have a unique knowledge of the history behind the X Consortium, XFree86, and the rebranding/merger of X.org. As a software engineer, did you have any impressions/opinions regarding XIE, STSF, and Display Postscript? XRender and Xft do not really seem to mesh well with X11’s client-server architecture. Kind regards, Lev > >> Kind regards, >> Lev >> >> >>> On Jan 23, 2021, at 17:11, Jon Trulson <j...@radscan.com> >>> wrote: >>> >>> On 1/18/21 8:21 AM, Lev via cdesktopenv-devel wrote: >>> >>>> Here’s a revised copy of the ksh fixes I submitted before that properly >>>> tests for POSIX-compliant terminal handling capabilities rather than >>>> attempting to get OLDTERMIO working. I think these patches are ready to be >>>> committed. >>>> >>>> >>> Sorry I missed this one. I've added it to master. However, I think any >>> future ksh changes should go to the ksh93 maintainer... I'd like to get >>> Chase's ksh tree merged to master soon... >>> >>> Thanks! >>> >>> -jon >>> >>> >>> >>> >>>> Kind regards, >>>> Lev >>>> >>>> >>>> >>>> >>>>> On Jan 17, 2021, at 19:17, Lev via cdesktopenv-devel >>>>> <cdesktopenv-devel@lists.sourceforge.net> >>>>> >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> I am now able to compile CDE on Void PPC with musl. In the future, it >>>>> might make sense to create a PpcLeArchitecture for Alpine Linux (also >>>>> using musl) for CI with a minimal image. >>>>> >>>>> Kind regards, >>>>> Lev >>>>> >>>>> <0001-Fix-warnings-on-PowerPC-builds-and-correct-a-compile.patch><0002-The-musl-C-library-does-not-define-MAXNAMLEN-but-we-.patch><0003-The-musl-C-library-requires-the-inclusion-of-the-SVR.patch><0004-Include-config.h-for-the-definition-of-u_int.-Proper.patch><0005-Disable-binding-a-privileged-client-port-with-rresvp.patch>_______________________________________________ >>>>> cdesktopenv-devel mailing list >>>>> >>>>> >>>>> cdesktopenv-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >>>> >>>> _______________________________________________ >>>> cdesktopenv-devel mailing list >>>> >>>> >>>> cdesktopenv-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >>> -- >>> Jon Trulson >>> >>> "Entropy. It isn't what it used to be." >>> -- Sheldon >>> >>> _______________________________________________ >>> cdesktopenv-devel mailing list >>> >>> cdesktopenv-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > -- > Jon Trulson > > "Entropy. It isn't what it used to be." > -- Sheldon >
0001-Fix-warnings-on-PowerPC-builds-and-correct-a-compile.patch
Description: Binary data
0002-The-musl-C-library-does-not-define-MAXNAMLEN-but-we-.patch
Description: Binary data
0003-The-musl-C-library-requires-the-inclusion-of-the-SVR.patch
Description: Binary data
0004-Include-config.h-for-the-definition-of-u_int.-Proper.patch
Description: Binary data
0005-Disable-binding-a-privileged-client-port-with-rresvp.patch
Description: Binary data
_______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
