Re: [cdesktopenv-devel] [PATCH] Fix build under LLVM15
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 + > > Chase 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 FreeBSD UNIX: Web: https://FreeBSD.org NTP: 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
Re: [cdesktopenv-devel] [PATCH] fix MANDIR output from dtsearchpath
On 2/6/23 22:50, Giacomo Comes wrote: On Sat, Feb 04, 2023 at 01:29:26PM -0700, Jon Trulson wrote: On 1/31/23 23:21, Giacomo Comes wrote: The value of MANDIR from dtsearchpath is missing the CDE man directory. Restore it. Hi, I've applied this, and the following patches: - missing dtopen_* links - /usr/dt/bin is always needed - fix DTKORNSHELL output for dtlp I did not apply the ksh manpage rename patch since there is already a fix in master for this: Since we do not install ksh, we will no longer install the manpage for it at all. I disagree. You do install ksh and it is called dtksh. The man page dtksh.1 only refers to the dt extensions. For options, operands, input files, etc, such man page points to the (k)sh.1 man page. Since the version of ksh installed with the OS is different from the one used to build dtksh, the correct documantation of dtksh can be found only in cde's ksh man page. To avoid any conflict or confusion, my patch renames cde's ksh.1 as ksh-cde.1 That's an excellent point. I've gone ahead and applied this. --jon Giacomo However, in the future please use /git format-patch .../ to send patches to the list, OR use SourceForge's MR mechanism to submit merge requests. See:https://sourceforge.net/p/cdesktopenv/wiki/Contributing%20to%20CDE/ I generally ignore malformed submissions as I don't have the time to do the work for you, but these seem reasonable and at some point I'd really like to be able to allow CDE to be installed anywhere rather than a hardcoded /usr/dt. This is a big job to do correctly however. Thanks! ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel -- Jon Trulson "The less you know, the more you believe." -- Bono ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel -- Jon Trulson "The less you know, the more you believe." -- Bono ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] [PATCH] Fix build under LLVM15
On 2/16/23 08:50, Cy Schubert wrote: On Thu, 16 Feb 2023 14:30:41 + Chase 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 quite 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 :) -- Jon Trulson "The less you know, the more you believe." -- Bono ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Various issues with cde 2.5.1
On 2/13/23 23:09, Giacomo Comes wrote:
Hi,
I'm in the process of packaging CDE for opensuse.
While doing that I have found some issues and I have some doubts
that I would like to share with you.
Gulp.
1) CDE does not compile with gcc12. In many places it throws the error:
error: control reaches end of non-void function [-Werror=return-type]
Attached there is a patch that makes CDE 2.5.1 compile with gcc12.
Please use such patch only as reference to see which functions
have problems. Do not consider the patch correct C code.
I just put some return statements here and there assuming
that whatever value was returned it would be ignored.
The purpose was only to have the build process proceed without errors
in order to find all the troubling functions.
While now urgent, this task needs to be done at some point.
Yeah, and the patch is not in git 'format-patch' format either which as
I mentioned earlier causes more work to integrate, so I will not apply.
I can see that at least one of those changes is wrong anyway:
static void *strmove(void *dest, const void *src) {
memmove(dest, src, strlen(src) + 1);
+ return(0);
}
This function should just:
return memmove(dest, src, strlen(src) + 1);
I'll fix that one myself.
2) If CDE is build with --prefix=/ust/dt (the default),
many binaries have rpath set. Since that is forbidden
by opensuse packaging rules, I'm forced to use the command
chrpath on such binaries.
configure has the option '--disable-rpath' but it does not seems to
work. Using such options or not does not make any difference.
Perhaps some Makefile.am needs adjust?
Hmmm... That will require investigation.
Seems this is handled by libtool, and apparently not very well. Post
processing with chrpath might be the only way.
3) I have seen that in 2.5.1 only dtappgather is setuid.
In the past the list was bigger. Is that correct?
Is there any possibility that in the future no setuid
program will be necessary?
Yes, we've slowly been whittling these down. only appgather is suid
root now. I think the fix for that is to not bother setting up the
application symlinks in /var/dt - rather just set them up in the user's
.dt/... directory hierarchy somehwere and have dtfile, etc look there
instead.
A patch(es) is welcome.
I'll probably tackle it someday when I get the time.
4) When I run dtbuilder, if I click on any widget in the main
window the program crashes showing the following error messages:
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 14181
Current serial number in output stream: 14184
No idea on that one. dtbuilder needs a lot of work.
5) Since 2.5.0 if I start from a terminal some CDE programs
(dtterm, dtpad, dtinfo, etc.) the following warning appears:
Warning: Missing charset in String to FontSet conversion
Warning: Missing charset in String to FontSet conversion
That didn't happens in CDE up to 2.4.0
I've seen that too and is probably the result of some of the recent font
changes that went in for utf8 support. Would be nice to know what
charsets are actually 'missing' here.
Unfortunately I'm not a font guy. Not sure what's missing and what it
would take to fix.
6) In the file contrib/desktopentry/cde.desktop
it would be a good idea to add the line:
DesktopNames=CDE
In this way, after a login, the desktop manager will set the environment
variables:
XDG_CURRENT_DESKTOP and XDG_SESSION_DESKTOP
Done.
7) In the file programs/types/pgadmin.dt the line:
ICON pgadmin
should be:
ICON pgadmin3
Done.
8) /usr/dt/bin/dterror.ds does not work properly in CDE 2.5.x
It is build using programs/dtfile/dterror.src as source,
but is should be using programs/types/error.ds.src as source.
See databases/CDE-RUN.src in CDE up to 2.4.0
Hmm. yes, that one has the interpreter line set incorrectly to /etc/dt/...
Fixed.
But these scripts are not the same. They could possibly be made the same
someday. Patch (in git's format-patch format please) welcome.
9) the command:
ksh -c 'echo "\n"'
prints a new line as output. So did the command:
dtksh -c 'echo "\n"'
in CDE up to 2.3.2.
Since 2.4.0 instead the same dtksh command prints: \n
To restore the correct behavior ECHOPRINT=1 must be set
in programs/dtksh/ksh93/src/cmd/ksh93/SHOPT.sh
This option might have been lost when I redid the way we set SHOPTS for
the ksh93 build.
Fixed.
10) If, for example, I execure the action:
ApplicationManager/Desktop_Tools/Environment Variables,
in the output window I see at the end:
\n*** Select Close or Exit from the window menu to close this window ***
instead of:
*** Select Close or Exit from the window menu to close this window ***
The problem seems to be that many dtactions use: sh -c '...; echo ...\n...'
in order to print a new
