In message <35109be0-4d7c-0e9d-f03e-b1213c437...@radscan.com>, Jon Trulson writ es: > This is a multi-part message in MIME format. > --===============3445952125607115813== > Content-Type: multipart/alternative; > boundary="------------gk9Qmvy2hZOT1KTlo52R5nsS" > Content-Language: en-US > > This is a multi-part message in MIME format. > --------------gk9Qmvy2hZOT1KTlo52R5nsS > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > On 2/16/23 08:50, Cy Schubert wrote: > > On Thu, 16 Feb 2023 14:30:41 +0000 > > Chase<nicetry...@protonmail.ch> wrote: > > > >> You must not directly edit any file under ksh93, instead, pull the newest > point release from the source and merge it. Its a git subtree so I'm not quit > e sure how that works. > > I know how it works. We at FreeBSD use subtrees for vendor branches > > (contributed code). (We have ATM decided to use subtrees instead > > of submodules but that may change in the future.) Though, we sometimes > > apply our own patches to /usr/src/contrib which are eventually > > upstreamed, while other times we submit a patch and wait. > > > > I've updated the FreeBSD ksh ports with the same atomics patch. I plan > > on upstreaming that too. Just haven't gotten around to it yet. > > > > I'll resubmit the patch minus the ksh bit. > > > > I think I will apply this patch as-is for now. Chase has a point in > that it causes conflicts the next time we want to resync with upstream > ksh, but I have no idea how long it will take for: > > - the patch to make it into ksh (https://github.com/ksh93/ksh/pull/601) > - CDE to resync with upstream > > Plus this issue causes FTBFS > > So, let's throw all caution to the wind and apply it for now. > > Though I am suspicious of the ksh fix - it seems incongruous to check > for defined(_aso_casptr), but then instead use _aso_cas64()... So not > sure if that will be considered correct from a ksh maintainer > perspective. Guess we will see :)
As maintainer of the FreeBSD ksh family of ports, a ksh pull request has also been submitted. No reply so far. The alternative is -Wno-int-conversion when building aso.c until the error is fixed. -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0 _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel