On 1/28/21 7:59 PM, Lev wrote: > Hi Chase, > > It’s not just UnixWare - all systems based on SVR4 inherited this behavior > (e.g., see https://www.mail-archive.com/bug-automake@gnu.org/msg04745.html > for OpenSolaris). CDE worked well on these systems. They were, in fact, the > reference platforms for CDE. I am offering to support these systems, which > seems like a mutually beneficial arrangement. This project will be less > encumbered to pursue new developments, and people looking for a CDE with > stability fixes and Motif 2.1 on older systems will be able to obtain that > too.
I guess I would suggest patches that can make it work on these systems again, either to CDE or the OS in question. Is unixware even available anywhere? Last I see is a version 7.1 released in 1999... I found a page listing license codes(?) for it: https://archive.org/details/UnixWare71 I have no objection to at least attempting to support that via patches, but I do not want to limit CDE's code base based on what Unixware or other ancient OSs support. It should be possible via automake to support them all, since I can certainly remember running ./configure back when I used unixware. I am not keeping imake though. It's gone as soon as I can get rid of it. If you really want it, maybe you could support a repo that just contains a pile of patches to make it work on whatever given OS you want it to work on. Someone could then get CDE code, apply your patches to make it build and run on that OS (including imake if you insist :)... You could do whatever is required. Of course, then you would need to maintain it. -jon > Kind regards, > Lev > >> On Jan 28, 2021, at 19:19, Chase <nicetry...@protonmail.ch> 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 >> >> >> 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
