On 1/28/21 7:19 PM, Chase wrote: > I just did some light research, and it appears that unixware is the one in > the wrong with this issue, rm -f not outputting diagnostics info is POSIX, so > unixware needs to conform to posix. We are CDE, the common desktop > environment, therefor we need to use the common standards. > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22074 > https://www.austingroupbugs.net/view.php?id=542
For what it's worth, a +1 from me... -jon > > Thank you for your time, > -Chase > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, January 28, 2021 8:03 PM, Lev <int...@mailbox.org> wrote: > >> Hi Chase, >> >> I ran autoreconf on Linux and copied it over to my UnixWare system. After >> manually patching the ‘configure' script to work around new build >> requirements like Xinerama, pkg-config, and freetype, the build fails >> because it tries calling the am—refresh target and it can’t find aclocal. >> Touch’ing all the files solved that issue but the automake-generated >> Makefiles contain macros that do not function with UNIX make, like $< >> outside inference rules; this leads make to run commands that are missing >> their arguments. In contrast, cde-2.2.1 mostly works once BOOTSTRAPCFLAGS >> are properly defined. Sadly, I don’t see how this endeavor is going to work >> in the long run, especially if autoconf drops compatibility with the SVR4 >> utilities (the reason for the ‘rm’ warning.) >> >> When I have more time, I think I will pivot towards getting the new ksh93 >> working without regressions on UnixWare and other SVR4 platforms first. >> Perhaps the best approach later is to configure Imake with iffe (possibly >> sync’ing the defines with the autoconf one for source code portability), >> restore Motif's Imake support, and backport bug-fixes to 2.2.1 as part of a >> "CDE classic" project that bundles dependencies like Tcl and patches for >> these systems. >> >> Kind regards, >> Lev >> >>> On Jan 27, 2021, at 19:32, Chase nicetry...@protonmail.ch wrote: >>> Not to my knowledge, no. I wonder, would committing the configure file >>> alleviate any of the issues you have with the autotools? If we commit the >>> configure file, you wouldn't need to install the autotools or m4 (you'd >>> still need it to build nsgmls but hopefully we will get rid of this soon >>> for system onsgmls) to build in theory. I was actually going to propose to >>> do this a while ago so that the future debian package wouldn't depend on >>> the autotools but I was busy with the whole ksh replacement project. >>> Thank you for your time, >>> -Chase >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Tuesday, January 26, 2021 10:23 PM, Lev int...@mailbox.org wrote: >>> >>>> 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 ofX.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 -- 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
