Hmm. I used git format-patch for this. Using git-2.45.1. Sometimes git
am and git apply fail and I resort to using patch(1). Then git commit
--author='...' in such circumstances. We get a lot of
Thanks for applying the patch. I'll remove the temporary workaround
from the cde-devel port next time
On 6/2/24 15:56, Cy Schubert wrote:
FreeBSD bb421be6c117 moved ftime(3) from libcompat to libutil. This
results in the following error,
Hi, I applied this patch, though I had to do it manually as git could
not seem to understand the diff format used. Anyway, it's in and thanks
for the patch
FreeBSD bb421be6c117 moved ftime(3) from libcompat to libutil. This
results in the following error,
ld: error: undefined symbol: ftime
>>> referenced by getdate.c
>>> libDtCmP_a-getdate.o:(cm_getdate) in archive
../libDtCmP/libDtCmP.a
>>> did you mean: ctime
Signed off by: Cy Schu
On 2/26/24 05:42, Paul via cdesktopenv-devel wrote:
Howdy all,
This patch aims to fix an issue where dtterm replies with "%s" when
given either 'CSI 20 t' or 'CSI 21 t'.
Patch applied, thanks!
-jon
Example of wrong behaviour:
$ echo "^[[21t"
$ l%s
Example of correct behaviour:
$ echo "
Howdy all,
This patch aims to fix an issue where dtterm replies with "%s" when given
either 'CSI 20 t' or 'CSI 21 t'.
Example of wrong behaviour:
$ echo "^[[21t"
$ l%s
Example of correct behaviour:
$ echo "^[[21t"
$ lTerminal
Regards,
Paul.
0001-dtterm-fix-title-and-icon-Sun-esc_seqs.patch
De
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 i
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 FreeB
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_* l
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 branche
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.
Thank you for your time,
-Chase
Sent with Proton Mail secure email.
--- Original Message ---
On Wednesday, Feb
Fix many -Wint-conversion errors such as the example below, including
an aso atomics error.
connect.c:87:12: error: incompatible pointer to integer conversion
initializing 'LONG' (aka 'int') with an expression of type 'void *'
[-Wint-conversion]
DB_ADDR mdba = NULL; /* db address of current
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
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 manpa
The shebang of dtlp is /usr/dt/bin/dtksh.
If cde is configured with --prefix=/usr
and an rpm is created, such rpm fails to install
with the error:
nothing provides /usr/dt/bin/dtksh
Make the shebang of dtlp correspond to the
true location of dtksh
diff -Nraub cde-2.5.1.ori/programs/dtprintegrate/
If cde is configured with
./configure --prefix=/usr
the binaries are located in /usr/bin.
However /usr/dt/bin is hardcoded in so many places
that if it doesn't exist cde does not even start.
Create /usr/dt/bin link if necessary.
diff -Nraub cde-2.5.1.ori/programs/Makefile.am cde-2.5.1/programs/Ma
dtopen_* links should be created in $(DESTDIR)$(bindir),
the same place where dtopen is located
diff -Nraub cde-2.5.1.ori/programs/dtopen/Makefile.am
cde-2.5.1/programs/dtopen/Makefile.am
--- cde-2.5.1.ori/programs/dtopen/Makefile.am 2022-10-01 13:18:27.0
-0400
+++ cde-2.5.1/programs/d
The value of MANDIR from dtsearchpath is missing the CDE man directory.
Restore it.
diff -Nraub cde-2.5.1.ori/doc/Makefile.am cde-2.5.1/doc/Makefile.am
--- cde-2.5.1.ori/doc/Makefile.am 2022-10-01 13:18:27.0 -0400
+++ cde-2.5.1/doc/Makefile.am 2023-01-26 13:32:16.402454621 -0400
@@
On 8/4/22 08:03, Chase via cdesktopenv-devel wrote:
3 Patches:
1. remove manual lcrypt flags, since we detect them in autotools,
also removed manually linking libc in some solaris defines, as
doing so violates posix and even then autotools can handle this
directly without us.
2. C
3 Patches:
- remove manual lcrypt flags, since we detect them in autotools, also removed
manually linking libc in some solaris defines, as doing so violates posix and
even then autotools can handle this directly without us.
- Clean up some defines in DtTerm, these were mostly duplicates of OS d
On 7/30/22 19:58, Chase via cdesktopenv-devel wrote:
This is based off of current master instead of the libmd patch as it
doesn't seem like it will be merged (though I could edit it to build
on all systems except linux so no wiki edits need be made).
Thank you for your time,
I've merged this
On 7/27/22 22:09, Chase wrote:
NetBSD and OpenBSD have this function in their libc, FreeBSD and
opensolaris have this function in a bundled libmd with the system.
Linux is the only system it doesn't come with and it can be installed
on most systems as libmd or libbsd (this one is deprecated). I
On 7/30/22 18:48, Chase via cdesktopenv-devel wrote:
This removes a lot of code that either wasn't being compiled or wasn't
used in the code. I would like to eventually refactor this code to use
standard posix calls and merge all the sources into one with ifdefs
for each program.
Thank you fo
This is based off of current master instead of the libmd patch as it doesn't
seem like it will be merged (though I could edit it to build on all systems
except linux so no wiki edits need be made).
Thank you for your time,
-Chase
Sent with [Proton Mail](https://proton.me/) secure email.From b9c
NetBSD and OpenBSD have this function in their libc, FreeBSD and opensolaris
have this function in a bundled libmd with the system. Linux is the only system
it doesn't come with and it can be installed on most systems as libmd or libbsd
(this one is deprecated). It's not a very painful band-aid
On 7/27/22 14:52, Chase via cdesktopenv-devel wrote:
I made a second attempt at this and made the configure script detect
which library has md5, this manages to work for dtcm and dtmail, it
should be much more portable than before. I don't think that ~1300 LOC
that we no longer have to maintain
I made a second attempt at this and made the configure script detect which
library has md5, this manages to work for dtcm and dtmail, it should be much
more portable than before. I don't think that ~1300 LOC that we no longer have
to maintain is a small gain, there is already a huge amount of co
I'm in favor of dropping all those!
On Sat, Jul 23, 2022 at 7:50 PM Jon Trulson wrote:
> On 7/22/22 21:02, Chase via cdesktopenv-devel wrote:
>
> This is actually four patches:
>
>1. remove the patch requirement, this was made obsolete with the
>newly pulled in ksh, I also cleaned up th
On 7/22/22 21:02, Chase via cdesktopenv-devel wrote:
This is actually four patches:
1. remove the patch requirement, this was made obsolete with the
newly pulled in ksh, I also cleaned up the dtksh makefile a bit.
2. Use the system md5 library instead of a builtin one for dtcm,
there
On 12/27/21 9:48 AM, Chase via cdesktopenv-devel wrote:
Fair warning, I have only tested this on linux.
Right - so it's more assigned work for me when I get the time :) So, I'm
going to hold on it for awhile until I'm ready. Thanks.
-jon
Thank you for your time,
-Chase
Nice, I was thinking of taking this up but you did this nicely. A question for
you, apparently our code uses a "LockKshFileDescriptors" function that locks
the first 10 file descriptors, is this still necessary with the new ksh?
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
O
Fair warning, I have only tested this on linux.
Thank you for your time,
-Chase
0001-Use-built-in-onsgml-parser-versus-our-old-one.patch
Description: Binary data
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.so
Ha, never mind. I've applied them - not used to getting properly
formatted patches in the mail body :)
-jon
On 7/4/21 1:05 PM, Jon Trulson wrote:
Hi, could you send these patches (this one and the following 2
patches) in the proper git format-patch format?
Otherwise I have to manually apply
Hi, could you send these patches (this one and the following 2 patches)
in the proper git format-patch format?
Otherwise I have to manually apply them, create a commit message for
them, etc... I don't have that kind of time.
-jon
On 7/4/21 8:22 AM, Adam Sampson wrote:
When building a progra
---
cde/lib/DtSvc/DtUtil2/SunDtHelp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cde/lib/DtSvc/DtUtil2/SunDtHelp.c
b/cde/lib/DtSvc/DtUtil2/SunDtHelp.c
index aa7a15fc5..759a87554 100644
--- a/cde/lib/DtSvc/DtUtil2/SunDtHelp.c
+++ b/cde/lib/DtSvc/DtUtil2/SunDtHelp.c
@@ -49,6 +49,7 @@
*+E
return(NULL) is correct for the other functions here but not for this
one, since it's meant to return a DtHELP_ error code. The man page also
says it should also set *widget to NULL on error.
---
cde/lib/DtSvc/DtUtil2/SunDtHelp.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --
When building a program foo in-tree, libtool 2.4.6 generates an
executable called lt-foo with a wrapper script called foo. This
means that argv[0] inside the program is lt-foo rather than foo.
This is a problem for dtcodegen, which uses the program name for various
purposes including the "generate
Merged, thanks!
-jon
On 4/3/21 2:44 PM, Edmond Orignac wrote:
When the current locale is ja_JP.eucjp or zh_CN, dtcm crashes on
startup as a subroutine
tries to dereference a null pointer. This trivial patch checks that
string!=NULL before dereferencing it.
After that correction, dtcm is wo
When the current locale is ja_JP.eucjp or zh_CN, dtcm crashes on startup
as a subroutine
tries to dereference a null pointer. This trivial patch checks that
string!=NULL before dereferencing it.
After that correction, dtcm is working with the ja_JP locale. Some
problems remain:
* The year
On 3/28/21 4:48 PM, Chase wrote:
Well if you had it working before that is a bit concerning, but I am
not sure if it is a regression or something wrong with my environment.
I would like a jenkins setup if possible. As for only doing work on
linux, since I am pretty much the only one doing work
Well if you had it working before that is a bit concerning, but I am not sure
if it is a regression or something wrong with my environment. I would like a
jenkins setup if possible. As for only doing work on linux, since I am pretty
much the only one doing work on the autotools branch right now,
On 3/28/21 2:39 PM, Chase wrote:
Just attempted it and I can't build anything with or without the
patch, aclocal says it needs gnu m4, but I already have gnu m4
installed...
Thank you for your time,
-Chase
Well, crap. I had been testing it occasionally (needed gmake though)
with success,
Just attempted it and I can't build anything with or without the patch, aclocal
says it needs gnu m4, but I already have gnu m4 installed...
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Sunday, March 28, 2021 1:55 PM, Jon Trulson wrote:
> On 3/28/21 9:52 AM, Chase wrote:
On 3/28/21 9:52 AM, Chase wrote:
So it sounds like the makefile incompatibilities have been solved, and now it's
an issue of the code itself having problems with compatibility, so if you would
like to fix and maintain unixware support, be my guest. The makefiles appear to
have incompatibilites
So it sounds like the makefile incompatibilities have been solved, and now it's
an issue of the code itself having problems with compatibility, so if you would
like to fix and maintain unixware support, be my guest. The makefiles appear to
have incompatibilites commented out and replaced with po
Hi, sorry for the delay...
I am not able to apply this - it fails on line 16 of control, which in
master has libtirpsc on it, not libjpeg...
Applying: Fix building in pbuilder/pdebuild
error: patch failed: cde/debian/control:16
error: cde/debian/control: patch does not apply
Patch failed at 00
Hi,
I've included a patch to fix building in pbuilder or pdebuild on Debian and
Ubuntu, and bumped the debian/control version number while I was there.
I've also included the patch as an attachment, in case my mail client breaks
the inline version.
All the best,
Anthony
---
cde/debian/change
Some notes:
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Sunday, March 14, 2021 4:48 PM, Jon Trulson wrote:
> Go ahead and post a patch... Not sure when I can take a look, but the likely
> issue is the order of the libraries on the link line.
>
> -jon
>
> On 3/11/21 4:06
Go ahead and post a patch... Not sure when I can take a look, but the
likely issue is the order of the libraries on the link line.
-jon
On 3/11/21 4:06 PM, Chase via cdesktopenv-devel wrote:
> By the way, I have made Makefile.am for the dtinfo program (not
> dtinfogen) that compile, but I can't g
On 3/9/21 5:15 PM, Chase via cdesktopenv-devel wrote:
> The wiki says the user should create /var/spool/calendar for proper
> calendar functioning, lets do this for the user instead upon installation.
>
Merged... I guess someday we should rethink the reasoning for this - ie
sharing calendars for m
By the way, I have made Makefile.am for the dtinfo program (not dtinfogen) that
compile, but I can't get the convenience libraries to work, they keep
outputting missing symbols as errors. I can provide a patch if anyone is
interested/willing to take a look.
Thank you for your time,
-Chase
The wiki says the user should create /var/spool/calendar for proper calendar
functioning, lets do this for the user instead upon installation.
Thank you for your time,
-ChaseFrom 418144f7902355f39851451dc28ef7d2058bb98b Mon Sep 17 00:00:00 2001
From: Chase
Date: Tue, 9 Mar 2021 17:59:00 -0600
Su
On 2/27/21 8:26 PM, Chase via cdesktopenv-devel wrote:
> Along with this, I did get a rare build failure in dthelp again, in
> pass1/build, it looked the same as the errors I was getting in
> canon1/build and pass2/build, so I am disabling parallel building
> there too. dtinfo and dtinfogen still l
Along with this, I did get a rare build failure in dthelp again, in
pass1/build, it looked the same as the errors I was getting in canon1/build and
pass2/build, so I am disabling parallel building there too. dtinfo and
dtinfogen still look fairly complex, I think I am going to try and find out w
Merged, thanks!
I had the same problem with pass1. It usually worked, but would
randomly fail.
-jon
On 2/22/21 5:24 PM, Chase via cdesktopenv-devel wrote:
> Sometimes when compiling dthelp, the targets somehow get run out of
> order and files aren't being generated, so I am disabling parallel
>
Sometimes when compiling dthelp, the targets somehow get run out of order and
files aren't being generated, so I am disabling parallel building in the build
directory of the pass2 and canon1 parsers.
Thank you for your time,
-ChaseFrom b78fcd5ce58fb11221c59850883400a326e78222 Mon Sep 17 00:00:00
On 2/21/21 12:42 PM, Chase via cdesktopenv-devel wrote:
> I was trying to find a way to make dtappbuilder stop rebuilding itself
> every time, I thought this would solve it but it didn't, however it
> does let us build it in parallel.
>
merged, thanks! yeah - I think there is something just missi
I was trying to find a way to make dtappbuilder stop rebuilding itself every
time, I thought this would solve it but it didn't, however it does let us build
it in parallel.
Thank you for your time,
-ChaseFrom 3e67f92766ac3ee0f00dc36cbb9cf059ae4b7279 Mon Sep 17 00:00:00 2001
From: Chase
Date: Su
You can find dtwmcmd in this thread:
https://sourceforge.net/p/cdesktopenv/mailman/cdesktopenv-devel/thread/be174e7b-9644-199c-bf90-f4a274c763bf%40radscan.com/
Best regards,
Juergen.
Am 15.02.21 um 19:14 schrieb cyrus torros:
Does anyone know how I can use f.action ExitSession
in a script?
Does anyone know how I can use f.action ExitSession
in a script? I am trying to chain that together with shut down because
its the only thing that saves my session properly.
On 2/13/21, Jon Trulson wrote:
> On 2/12/21 9:08 AM, Chase via cdesktopenv-devel wrote:
>> This patch allows dtksh to be b
On 2/12/21 9:08 AM, Chase via cdesktopenv-devel wrote:
> This patch allows dtksh to be built in parallel in the autotools branch.
>
It sure does :) Applied, thanks!
-jon
> Thank you for your time,
> -Chase
>
>
>
>
> ___
> cdesktopenv-devel mailing lis
On 2/10/21 3:29 PM, Chase via cdesktopenv-devel wrote:
> Attempt #2, this time properly tested with parallel building
>
Thanks! Patch applied.
There is still an issue with dtappbuilder trying to build a portion of
itself during a make install, but this issue I also see in master.
We'll have to
This patch allows dtksh to be built in parallel in the autotools branch.
Thank you for your time,
-ChaseFrom 733dd2cff4a860dc8e3d4970e91a6139a560fa36 Mon Sep 17 00:00:00 2001
From: Chase
Date: Fri, 12 Feb 2021 10:06:33 -0600
Subject: [PATCH] dtksh: allow parallel building
---
cde/.gitignore
Attempt #2, this time properly tested with parallel building
Thank you for your time,
-ChaseFrom 652de3d0cb01506d922538e0acaa1be4f51ab639 Mon Sep 17 00:00:00 2001
From: Chase
Date: Wed, 10 Feb 2021 16:28:52 -0600
Subject: [PATCH] ttsnoop: make it build under autotools
---
cde/.gitignore
On 2/7/21 1:54 PM, Chase via cdesktopenv-devel wrote:
> So, this was an easy task, however, I do not think that I am capable
> of doing the rest of dthelp, is is some complex stuff. As for dtinfo,
> I still need to investigate it more...
>
I've applied this. Yes, I did parser/pass1... I think onl
On 2/7/21 8:39 AM, Chase via cdesktopenv-devel wrote:
> Only two programs left...
>
Yeah, getting closer... Once those are done, then docs, then profit!
I cannot apply this patch though as it breaks multicore builds:
depbase=`echo stringChooser_stubs.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
c++ -
So, this was an easy task, however, I do not think that I am capable of doing
the rest of dthelp, is is some complex stuff. As for dtinfo, I still need to
investigate it more...
Thank you for your time,
-ChaseFrom 1504a82780e979262249263d56077ec8f024404f Mon Sep 17 00:00:00 2001
From: Chase
Dat
Only two programs left...
Thank you for your time,
-ChaseFrom 51e10c0b4c5b7c980ea48e7e0181e75c7a5bbf9b Mon Sep 17 00:00:00 2001
From: Chase
Date: Sun, 7 Feb 2021 09:37:41 -0600
Subject: [PATCH] ttsnoop: make it build under autotools
---
cde/configure.ac | 2 +
cde/programs/Mak
On 1/31/21 10:19 AM, Chase via cdesktopenv-devel wrote:
> Fedora and family don't install patch by default, so we need to
> specifically test for it. Also, apparently distclean crashes when it
> reaches the JP locale.
>
I've applied these, though I had to make a change - in the future,
please test
Fedora and family don't install patch by default, so we need to specifically
test for it. Also, apparently distclean crashes when it reaches the JP locale.
On a side note, I am still of the opinion that we should replace tradcpp with
sed wherever possible, it would be one less program that we wo
I think you could also use
git clone --recurse-submodules
to clone in the source and the submodule in the same pass.
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Sunday, January 24, 2021 1:37 PM, Jon Trulson wrote:
> On 1/23/21 8:36 PM, Chase wrote:
>
>> Jon,
>> Hmm, If
On 1/23/21 8:36 PM, Chase wrote:
> Jon,
> Hmm, If I am understanding you correctly (which I don't think I am),
> git wouldn't properly clone the submodule into the ksh93 directory?
> Maybe if thats the case, it could be fixed with adding in an empty
> ksh93 directory for it to clone into to the rep
Jon,
Hmm, If I am understanding you correctly (which I don't think I am), git
wouldn't properly clone the submodule into the ksh93 directory? Maybe if thats
the case, it could be fixed with adding in an empty ksh93 directory for it to
clone into to the repo. It is worth noting however that git s
On 1/22/21 4:41 PM, Chase via cdesktopenv-devel wrote:
> Since Lev fixed the errors in upstream for musl and upstreamed them,
> lets pull that in so any potential merge to master also can safely
> build on musl (thus the old changes from Lev we would throw away for
> old ksh would be replaced with
The new ksh93 maintainer seems amenable to getting it working on every Unix
system, so that allays my earlier concerns. I still think it would be nice to
get some feedback from someone running NetBSD on whether the new shell is worse
or broken compared to the existing one. Perhaps we could maint
Since Lev fixed the errors in upstream for musl and upstreamed them, lets pull
that in so any potential merge to master also can safely build on musl (thus
the old changes from Lev we would throw away for old ksh would be replaced with
the new changes)l. I also threw in compiler warning fixes fo
On 1/18/21 6:13 PM, Lev wrote:
> Hi Jon,
>
> Thanks for the explanation, I can understand wanting to switch to a more
> common build system. Could I volunteer to maintain a branch of CDE for what
> might be considered legacy systems? I would really like the opportunity to
> work on improving CDE
Hi Chase,
That patch wasn’t intended for submission upstream, it was a quick hack (always
disabling that section of the code) to expose other errors. My pull request is
at https://github.com/ksh93/ksh/pull/156.
Kind regards,
Lev
> On Jan 19, 2021, at 19:43, Chase wrote:
>
> Lev,
> I git-ifie
Lev,
I git-ified you patch and sent it upstream, but in the future, if you make more
changes to ksh, push them upstream to https://github.com/ksh93/ksh where the
new ksh lives, they do no good simply sitting in our mailing list. I've also
seen some talk about using the old at&t ksh, but this sim
Hi Marcin,
Thanks for the idea. I was able to workaround the LFS64 issue (see the attached
patch) with the new ksh 93u, but I ran into some other issues with localization
(iswalpha is redefined for some reason) and ulimit support that are going to
take some time to resolve.
I haven’t had a cha
Hi Jon,
Thanks for the explanation, I can understand wanting to switch to a more common
build system. Could I volunteer to maintain a branch of CDE for what might be
considered legacy systems? I would really like the opportunity to work on
improving CDE, including making dtterm more VT100 compa
On 1/18/21 5:58 PM, Chase wrote:
> I would like master to be merged, yes. I am a bit confused though,
> what constitutes a path forward? I have satisfied all of the testing
> requirements (minus NetBSD), and I can't find any of the regression
> test faults that Marcin was talking about by using lib
Also, excellent work on that :)
-jon
On 1/17/21 1:30 PM, Chase via cdesktopenv-devel wrote:
> So here is where I am at with testing alternate platforms with the new
> imported ksh:
> Working:
> Linux Mint 20
> CentOS 8 (patch needs to be explicitly installed for some reason, even
> though it is a
Hi, I went ahead and merged these to your master-ksh93-upgrade branch,
in addition to the one switching to std malloc.
-jon
On 1/17/21 1:30 PM, Chase via cdesktopenv-devel wrote:
> So here is where I am at with testing alternate platforms with the new
> imported ksh:
> Working:
> Linux Mint 20
>
I would like master to be merged, yes. I am a bit confused though, what
constitutes a path forward? I have satisfied all of the testing requirements
(minus NetBSD), and I can't find any of the regression test faults that Marcin
was talking about by using libc malloc. This would eliminate our nee
On 1/18/21 9:31 AM, Lev via cdesktopenv-devel wrote:
> Hi Chase,
>
> Thanks to your advice about the submodule, I was able to make some progress.
> Unfortunately, I am now getting a lot of errors from the headers, e.g.:
> [...]
> I had been hoping to get a Motif 2.1 compatible version of CDE worki
On Mon, 18 Jan 2021, Lev wrote:
What would your advice be for anyone wanting to continue using CDE on platforms
that are unsupported by the autotools or ksh?
Would the original ksh93u work for those platforms?
Or https://github.com/att/ast master which is close?
ksh93 has its own autoconfig
Hi Chase,
Thanks to your advice about the submodule, I was able to make some progress.
Unfortunately, I am now getting a lot of errors from the headers, e.g.:
./ast_fs.h:147:18: warning: 'struct statvfs64' declared inside parameter list
will not be visible outside of this definition or declarat
I would not get too ahead of yourself with that, we are planning on making the
jump to the gnu autotools pretty soon, imake has a multitude of issues that, if
we want to see significant progress in the fields of OS packaging and cross
compiling, it will need to be done away with. Upstream might
Hi Chase,
I am thinking of revamping the bundled dtksh to build directly with imake
instead of nmake, using a ksh93 configure script to generate a .cf file with
the appropriate defines as a replacement for iffe. If this isn’t the ksh 2020
fork but the new ksh 93u one, backporting the fixes shou
Marcin,
I just ran the test suite and had no failures related to memory allocation, the
only failure I ran into was this one:
test path begins at 2021-01-17+18:15:48
path.sh[356]: $SHELL -c of unreadable empty script should fail --
expected 126, got /tmp/ksh93.shtests.19281.6143/path.C/sc
Hi Chase,
I just tried to get the upgraded dtksh on the master-ksh93-upgrade branch to
build with musl and it fails because bin/package is missing. If you are looking
for a traditional SVR4 host to test, I have access to UnixWare.
Kind regards,
Lev
> On Jan 17, 2021, at 16:24, Chase via cdeskt
On Sun, 17 Jan 2021, Chase wrote:
Marcin you were right, it was ast malloc causing problems, I asked the leader
of ksh if there was any way to disable it and he told me to pass -D_std_malloc.
OpenBSD works perfectly now. Patch attached. I think we could safely merge this
branch now if there a
Marcin you were right, it was ast malloc causing problems, I asked the leader
of ksh if there was any way to disable it and he told me to pass -D_std_malloc.
OpenBSD works perfectly now. Patch attached. I think we could safely merge this
branch now if there are no further objections...
Thank y
It could be, I am not sure, I think the callback pointer might have gotten
corrupted somehow, here is a paste of the backtrace from ./dtksh
examples/XdrawTest, the script specifically segfaults when the "clear window"
button is used.
Here is a paste of the backtrace from gdb:
host# ./dtksh exa
On Sun, 17 Jan 2021, Chase via cdesktopenv-devel wrote:
Not Working:
OpenBSD 6.7, segfaults whenever free() is called, but this does work with the
old version, so it is a regression, but OpenBSD couldn't even boot when I
compiled normal master, it hung at dthello
Is this free() used in ksh,
So here is where I am at with testing alternate platforms with the new imported
ksh:
Working:
Linux Mint 20
CentOS 8 (patch needs to be explicitly installed for some reason, even though
it is a POSIX utility)
FreeBSD 12.1
Openindiana hipster* (I needed to add a custom patch in dtdocbook that poin
Hi,
All three of these have been merged to the master-ksh93-upgrade branch,
thanks!
-jon
On 1/1/21 1:48 PM, Chase via cdesktopenv-devel wrote:
> apologies for all the noise, but I noticed that my last patch still
> wasn't fixing the error so I rewrote part of it, here are all the
> patches in or
Actually, ignore that last patch, I have an even better one: this one gets rid
of init.c entirely and instead uses a patch file to augment it when the
makefile copies it over, thus avoiding the error and allowing us to keep
./bin/package flat make in the dtksh Imakefile where it belongs. Merge t
I appear to have missed a non-fatal error in the depend process. I will need to
move building ksh back to the top makefile, however this will probably be able
to be moved back when I port it to autotools. Patch attached (merge this after
the first patch I attached).
Thank you for your time,
-Ch
Marcin pointed out to me that the shell command in make is a gnu extension and
is thus not portable. The solution to this was to use "flat make" that puts the
ksh binary in a static directory, which also allowed me to undo the weird
workaround I had to implement in the topmost makefile. This com
1 - 100 of 870 matches
Mail list logo
