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,
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
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
to rip off.
Thank you for your time,
-Chase
Sent with [Proton Mail](https://proton.me/) secure email.
--- Original Message ---
On Wednesday, July 27th, 2022 at 6:42 PM, Jon Trulson wrote:
> On 7/27/22 14:52, Chase via cdesktopenv-devel wrote:
>
>> I made a se
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
I don't think it's a good idea, Fedora 36 doesn't work according to
https://sourceforge.net/p/cdesktopenv/discussion/general/thread/2b0bd87053/
It's a problem with KSH93, upstream has already fixed it. I don't know how to
work with subtrees so I can't really update it myself.
Thank you for
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 ‐‐‐
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
Could you post your full build log?
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Wednesday, October 6th, 2021 at 8:00 PM, Marco Diego Aurélio Mesquita
wrote:
> Minor progress: got it to compile with:
>
> cc -o project project.o dtb_utils.o main_ui.o main_stubs.o
>
>
t;>>> FT_LOAD_MONOCHROME */
>>>>>
>>>>> - FT_Int32 load_flags = FT_LOAD_TARGET_MONO; /* orig: FT_LOAD_RENDER |
>>>>> FT_LOAD_MONOCHROME */
>>>>> char dynStrRealFileName = NULL; / foo.ttc */
>>>>> char dynStrFTFil
ase
>>>> ‐‐‐ Original Message ‐‐‐
>>>> On Sunday, March 14, 2021 6:52 PM, Chase via cdesktopenv-devel
>>>> cdesktopenv-devel@lists.sourceforge.net
>>>> wrote:
>>>>
>>>>> ugh, CTRL+enter is never consistent between apps.
>>&g
ures support for recursively scanning includes for IFFE
> headers and generating the appropriate configuration.
> It's on GitHub at lkujaw/jam.
>
> Chase writes:
>
> > Here is also another patch that might hopefully make some progress on
> > generating makefiles with unportable sta
@zeke it seems like you are conflating the submodule with the ksh program
itself. The submodule is not going anywhere and it not required to build CDE as
a whole but is a program that helps give CDE it's value. Requiring ksh as a
standalone program however, was originally required to run ksh's
> 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 get the convenience libraries to work, they keep
>> outputting missing symbols as errors. I can provide a pa
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
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
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:
Well thats it for dthelp, the final boss seems to be dtinfo, seems extremely
complicated from the glance I took at it...
Thank you for your time,
-ChaseFrom e63a070a4a101c816d3d7a442f0b5ad2c81591da Mon Sep 17 00:00:00 2001
From: Chase
Date: Mon, 15 Feb 2021 21:31:52 -0600
Subject: [PATCH]
Title is self explainatory.
Thank you for your time,
-ChaseFrom 04a7b4c8e33c721453c2e0cc311d96460e8d8f1b Mon Sep 17 00:00:00 2001
From: Chase
Date: Mon, 15 Feb 2021 19:27:54 -0600
Subject: [PATCH] dthelp/parser/canon1: get it to build
---
cde/.gitignore| 41
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
Hello,
Please take a look at the wiki article for backdrops:
https://sourceforge.net/p/cdesktopenv/wiki/Setting%20Your%20Own%20Backdrop/
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Wednesday, February 10, 2021 4:02 AM, cyrus torros
wrote:
> I am looking for a way to
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
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 +
My purpose is not to decrease supported operating systems with the introduction
of automake. Automake was (at least in theory) supposed to be a build system
that we wouldn't have to maintain ourselves with the most supported operating
systems that could be build projects without the tools even
Keyword directory. An empty argument != directory. I have a hard time believing
that Xinuos would let their OS become unusable for automake, have you emailed
them at all about the issues you've been facing?
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Saturday, February
I can get behind this, I know there was talk of using motif's XFT support for a
bit, but I don't think anything ever came of it...
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Saturday, February 6, 2021 1:20 PM, Lev via cdesktopenv-devel
wrote:
> Hello,
>
> I would
While this is impressive, it still won't be relevant for very long due to our
impending transition to autotools, did you ever get that make=gmake hack to
work? I was also thinking that a good way to solve the rm problem would be to
build the upstream ksh and link it to /bin/sh, since their rm
Feb 2021, Chase via cdesktopenv-devel wrote:
>
> > Personally, I think that your time would be used better if you helped us
> > test and fix any issues with the AIX and HPUX port.
>
> I have access to POWER hardware but only Power7 and older stuff (I have
> some POWER6 a
These patches would also need to be ported to automake. Its a shame that all
these new contributors show up when we are almost done with automake and are
making their contributions targeted for imake...
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Wednesday, February 3,
1. I've heard about a test suite in the wiki, but I have little knowledge about
it, is this what the examples directory is for?
2. While getting SPI on board would be nice, I doubt they would be interested
in a niche project like ours.
3. MIT licensing isn't happening from what I've been told,
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
Very nice, could you also merge it with autotools-conversion so I can work on
autotooling it?
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Saturday, January 30, 2021 6:07 PM, Jon Trulson wrote:
> Hi,
>
> The master-ksh93-upgrade branch has been merged into master and
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.
Have you tried reporting any of these issues to the GNU project? I feel like
reporting/fixing it upstream would be significantly less of a time sync and
would be beneficial for everyone to have the makefiles be posix compliant and
such.
Thank you for your time,
-Chase
‐‐‐ Original
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
;
> The 'Download' button on the CDE summary page does download 2.3.2...
>
> -jon
>
>> The git command looks good. All in all, seems like a solid plan, looking
>> forward to it!
>>
>> Thank you for your time,
>> -Chase
>>
>> ‐‐‐‐‐‐‐ Original Message
a solid plan, looking
forward to it!
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Saturday, January 23, 2021 8:17 PM, Jon Trulson wrote:
> On 1/22/21 4:41 PM, Chase via cdesktopenv-devel wrote:
>
>> Since Lev fixed the errors in upstream for musl and upstreame
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
Lev,
I just don't understand what the big issue with autotools is. We gutted a lot
of the legacy OS code a few years ago (ultrix, unixware, even weird ones like
uxpds), but if someone were to want these platforms back, I feel that using
autotools would be an even better solution, since
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 ksh, but this
v
>>> [](mailto:int...@mailbox.org)
>>> wrote:
>>>
>>>> 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
&g
u one, backporting the fixes shouldn’t be too
> difficult because they basically started from scratch to my understanding.
>
> Kind regards,
> Lev
>
> > On Jan 17, 2021, at 17:28, Chase via cdesktopenv-devel
> > cdesktopenv-devel@lists.sourceforge.net wrote:
> > L
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
you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Sunday, January 17, 2021 2:48 PM, Marcin Cieslak wrote:
> 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
>
8)
at /home/cde/cde/programs/dtksh/ksh93/src/cmd/ksh93/sh/pmain.c:45
Current language: auto; currently asm
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Sunday, January 17, 2021 2:48 PM, Marcin Cieslak wrote:
> On Sun, 17 Jan 2021, 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 POSIX utility)
FreeBSD 12.1
Openindiana hipster* (I needed to add a custom patch in dtdocbook that
h 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,
> -Chase
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, December 28, 2020 1
,
-Chase
‐‐‐ Original Message ‐‐‐
On Monday, December 28, 2020 10:49 PM, Chase via cdesktopenv-devel
wrote:
> 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
>
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
The maintainer of ksh93 suggested that I use the Empty macro (" \t\n"+3)
instead of an empty string, both function the exact same but apparently there
is a chance "" could conflict with some ksh93 internals, so I am fixing it.
Thank you for your time,
-ChaseFrom
Antonis,
For your locale error, if you would simply like to install CDE with english
only, you can actually ignore that error, I always build CDE and installed it
with this error present, as I refuse to install the other locales as I dont
want them taking up useless space on my disk. I have not
Nina,
This appears to be an issue with the old outdated ksh that we use, this problem
shouldn't exist on the updated master-ksh93-upgrade branch if you would like to
try using that for the time being until it gets merged.
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On
t I understand asking for work is a no-no.
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Monday, October 19, 2020 7:45 PM, Jon Trulson wrote:
> On 10/18/20 11:58 AM, Chase via cdesktopenv-devel wrote:
>
> Hi,
>
>> So, the first patch removes a lot of our custom
This fixes a segfault when doing callback routines, however there are still
more I need to work on.
Thank you for your time,
-ChaseFrom 03bcd6fbb3f91951ab7f797f0d2dfeb11ddbfcd2 Mon Sep 17 00:00:00 2001
From: Chase
Date: Fri, 9 Oct 2020 16:40:50 -0500
Subject: [PATCH] dtkcmds.c: add extra field
or your time,
> -Chase
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, September 10, 2020 10:33 PM, Chase via cdesktopenv-devel
> wrote:
>
>> Here is a patch to keep ksh up to speed with master, also, I have attached
>> logs of valgrind and gdb for running ./
for some reason my email client appened .bin to gdberrors and valgrinderrors,
ignore this, they are text files
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Thursday, September 10, 2020 10:33 PM, Chase via cdesktopenv-devel
wrote:
> Here is a patch to keep ksh
Here is a patch to keep ksh up to speed with master, also, I have attached logs
of valgrind and gdb for running ./dtksh examples/CallDataTest4, it seems that
variables without a period in them work fine, but for some reason a period
causes it to crash (at this line specifically:)
echo
This was a lot of fun (read: pain) to get working. bil_parser.y wanted -Nm set
for HPUX and AIX, but autotools complained that yacc options can't be
variables, and I seriously doubt that either AIX or HPUX build even on Imake,
so I left them out.
Thank you for your time,
-ChaseFrom
things, but also mention a lack of activity.
>
> News: https://github.com/ksh93/ksh/blame/master/NEWS
>
> TODO: https://github.com/ksh93/ksh/blob/master/TODO
>
> Seems promising, and no doubt our ksh is on the old side, so it would be good
> to get this going if we can...
>
It looks like you didn't generate the extra locales needed, from the wiki:
Run dpkg-reconfigure locales and select the following off the list
- de_DE ISO-8859-1
- es_ES ISO-8859-1
- fr_FR ISO-8859-1
- it_IT ISO-8859-1
Then run the locale-gen to generate them
locale
-
gen
Thank you for your
gt; also works well...
>>>
>>> http://www.brendangregg.com/dtkshdemos.html
>>>
>>> For the xplot test, I ran (ubuntu 18.04):
>>>
>>> vmstat 1 | ~/src/xplot.dtksh -f 11 -hi 100 -t \"user\"
>>>
>>> -jon
>>>
>
e:
> Hi,
>
> forgot to mention, I also tried 'xplot' demo from thie following page - it
> also works well...
>
> http://www.brendangregg.com/dtkshdemos.html
>
> For the xplot test, I ran (ubuntu 18.04):
>
> vmstat 1 | ~/src/xplot.dtksh -f 11 -hi 100 -t \"user\
Hi all,
In my attempt to port in a new ksh, I ran through the test cases with the
current shell to compare to the new one, and 3 of them do not work, DtWsTest1,
PipeTest and XCursorTest1. At least with PipeTest and XCursorTest1, these seem
to be caused by a missing command named "call", which
So upstream ksh has gotten rid of their predefined aliases, meaning we had to
switch them over to builtins if we ever plan on updating ksh, the patch also
got rid of the BLT_SPC flag for reasons best explained in this email sent by
the ksh maintainers:
"Default aliases are an ugly hack that
own
and instead just specify -DBUILD_DTKSH. Thoughts?
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Friday, July 3, 2020 11:27 PM, Chase via cdesktopenv-devel
wrote:
> Hi all,
> Recently I was attempting to fix and old patch of mine that switches ksh's
> hash f
Hi all,
Recently I was attempting to fix and old patch of mine that switches ksh's hash
for DtHash, our builtin substitution in order to import upstream ksh. I looked
at ksh's github and everything seems to have imploded there. AT have stepped
in and reverted all major commits since 2012, a
So technically I have made debian packaging, you can even see it in the source
tree under /debian, if you are referring to getting it packaged for debian,
this will be a much longer process that is actively being worked on. Debian has
strict requirements on what software is allowed to do, where
cleanups" here...
>
> What exactly are you cleaning up?
>
> -jon
>
> On 2/1/20 12:00 PM, Chase via cdesktopenv-devel wrote:
>
>> minor cleanup
>>
>> Thank you for your time,
>> -Chase
>>
>>
more cleanup
Thank you for your time,
-ChaseFrom 9b5f92f93718daaf629b42d185ee4e84ad3e530b Mon Sep 17 00:00:00 2001
From: Chase
Date: Sat, 1 Feb 2020 13:48:33 -0600
Subject: [PATCH] dtspcd: use sed instead of GENCPP
---
cde/programs/dtspcd/Makefile.am | 12 +++---
minor cleanup
Thank you for your time,
-ChaseFrom 743714ad7a190d7aaa505c80edaad3fb36fd420d Mon Sep 17 00:00:00 2001
From: Chase
Date: Sat, 1 Feb 2020 12:51:11 -0600
Subject: [PATCH] dtopen: replace GENCPP with sed
---
cde/programs/dtopen/Makefile.am | 8 +++---
cde/programs/dtopen/dtopen.src
upon further inspection, we will need to get rid of XCOMM since sed allows
comments for some reason, I could work around it but I'm too lazy, here is the
new patches
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Friday, January 31, 2020 8:44 PM, Chase via cdesktopenv
So I think that, if gcc -E isnt functioning in the way we want it anymore, we
should work towards moving them to sed scripts, as maintaining our own forked
cpp is clunky, from now on I will be using sed scripts to build scripts and
datafiles.
Thank you for your time,
-ChaseFrom
So this patch will be necessary for the autotooling of ksh (or at least the
updating of it then the subsequent autotooling), as ksh no longer provides its
hashing library this will be necessary if we want to update it (which would
also end it's dependency on ksh, and in the future we could even
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Sunday, January 26, 2020 1:00 PM, Jon Trulson wrote:
> On 1/20/20 11:39 AM, Chase via cdesktopenv-devel wrote:
>
>> these patches will make installing the manpages much easier via autotools,
>> as we can just u
I found a lot of redundant functions aping the _DtGetHourGlass function in
libDtSvc, so I am replacing them
Thank you for your time,
-ChaseFrom 9b127e0aa7e8d71b5034caf0947a2f9b5a9a014f Mon Sep 17 00:00:00 2001
From: Chase
Date: Tue, 21 Jan 2020 17:11:19 -0600
Subject: [PATCH] Remove redundant
I guess I'll take the silence as a no to my previous question, though as a
programmer I was never good at taking social queues haha.
I feel like the same could be said for this entire project, especially with
wayland right around the corner, but people still like their niches. We should
keep
Now that we have a contact with CERT, could we ask them if VU#179804 and
CA-1999-08 from the wiki still apply to our code?
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Wednesday, January 15, 2020 4:11 PM, Jon Trulson wrote:
> On 1/15/20 3:04 PM, Swift Griggs wrote:
>
>>
Yes, this place is the place to do it, if you need to do it confidentially with
someone, project leader is j...@radscan.com
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Friday, January 10, 2020 2:35 PM, Madison Quinn Oliver
wrote:
> Hi all,
>
> Where is the appropriate
forgot to remove the function prototypes from extra.h, see patch below
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Sunday, December 15, 2019 10:38 AM, Chase via cdesktopenv-devel
wrote:
> These will be my last patches before the holidays, none of these imp
time I
> get.
>
> So, you guys tell me - what is a reasonable plan going forward WRT ksh?
> Is 'hash' the only problem? Am I underestimating the work that might
> be required to autotools any version we end up incorporating? Have
> either of you done any POC testing to
, 2019 3:19 PM, Marcin Cieslak wrote:
> On Mon, 25 Nov 2019, Chase via cdesktopenv-devel wrote:
>
> > So as I was upgrading our ksh, I have ran into a problem, hash.h, commonly
> > found in libast, is no where to be found in the new sources, come to find
> > out that they
So as I was upgrading our ksh, I have ran into a problem, hash.h, commonly
found in libast, is no where to be found in the new sources, come to find out
that they have removed the entire hash part of the library because it was
"unused". The way I see it we have three paths going forward if we
Do you think importing debian's version of instant (docbook2man) would help at
all? https://packages.debian.org/sid/docbook-to-man
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Monday, November 18, 2019 6:51 PM, Jon Trulson wrote:
> Hi,
>
> I've just merged the
e 'new' ksh
> > as a result.
> >
> > > As for us depending on meson, we do not, the branch I chose was one of
> > > the last that functions with the old nmake build system, which only
> > > depends on standard c as far as I am aware.
> >
> > W
gt; With meson, at least temporarily, we could simply have the dtksh
> Makefile call meson to build ksh first :)
>
> I would vastly prefer that than to continuing to rely on old
> unmaintained software (nmake, pax, etc - as well as the 'old' ksh tree
> you decided to import instead
11/14/19 7:26 PM, Chase via cdesktopenv-devel wrote:
>
> > First off, massive apology for the commit size, I did not realize it was
> > going to be that big, and there really wasn't a good way to break it
> > down that I saw.
>
> 38MB, yeah... that's pretty much imposs
I am assuming that admin is going to get nuked once Imake is gone, so lets move
the BuildNotes to somewhere where they make more sense
Thank you for your time,
-ChaseFrom 724387065c23c546572f5175e0c0d517eb553ea1 Mon Sep 17 00:00:00 2001
From: Chase
Date: Thu, 14 Nov 2019 21:25:33 -0600
Subject:
First off, massive apology for the commit size, I did not realize it was going
to be that big, and there really wasn't a good way to break it down that I saw.
A few things to consider before merging:
I am not a lawyer, but it seems that the old ksh version that was provided with
CDE was
Here's also another patch removing some deprecate files from il, they were all
merged into files that we compile or their function was eliminated
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Monday, October 28, 2019 8:31 PM, Chase via cdesktopenv-devel
wrote:
> We o
We only have one internal jpeg header left, and I cant seem to find a suitable
replacement builtin for it, but I'll keep looking
Thank you for your time,
-ChaseFrom 302672b060a9e1cd619b527ff4962795855ecb2d Mon Sep 17 00:00:00 2001
From: Chase
Date: Mon, 28 Oct 2019 20:27:35 -0500
Subject:
> -jon
>
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Message ‐‐‐
> > On Wednesday, October 23, 2019 4:45 PM, Jon Trulson j...@radscan.com wrote:
> >
> > > On 10/23/19 2:56 PM, Chase via cdesktopenv-devel wrote:
> > >
> > > >
imake in the sense that
it uses os detection rather than feature detection.
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Wednesday, October 23, 2019 4:45 PM, Jon Trulson wrote:
> On 10/23/19 2:56 PM, Chase via cdesktopenv-devel wrote:
>
> > I tried to make t
would there be any large consequences of merging these similar programs via
ifdef? this has been holding up my autotools progress.
Thank you for your time,
-Chase___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
A while ago we started using system built in versions of tcl instead of the
ancient copy we built, this was done on all platforms except netbsd, try
writing a patch adding the location for tcl on netbsd and tell me if that
changes anything:
I don't mean to sound discouraging or anything, but does the world really need
a CDE linux distro? Would you be able to maintain such a custom distro? My
primary goal in contributing to the project is to get CDE available in the
debian repos and lay the groundwork for the other distros to
y to implement
> > > > macros, and thus I would have to write a plain Makefile direction for
>
> What do you mean that automake doesn't have an easy way to make macros?
> What macros?
>
> -jon
>
> > Thank you for your time,
> > -Chase
> > ‐‐‐ Original Mes
Was this pushed? I'm not seeing it in git log or on the sourceforge page
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Monday, January 14, 2019 12:11 PM, Jon Trulson wrote:
> Applied to master, thanks!
> -jon
>
> On 1/12/19 4:08 PM, Chase via cdesktopenv
did was move
DtMmdb to lib and disable building of mmdb.
Thank you for your time,
-Chase
‐‐‐ Original Message ‐‐‐
On Monday, January 21, 2019 4:24 PM, Jon Trulson wrote:
> On 1/21/19 2:07 PM, Chase via cdesktopenv-devel wrote:
>
> > Hi all,
> > The further a
1 - 100 of 207 matches
Mail list logo
