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

Reply via email to