Re: [cdesktopenv-devel] Cannot compile CDE on Debian 11
I've seen a thread from 2020 about the same error. It seemed to be
connected to ksh. What ksh version are you using?
On Wed, 15 Nov 2023 at 01:26, TCH via cdesktopenv-devel
wrote:
>
> Hello,
>
> Yes, it is installed, at least there is an rpcgen binary in /usr/bin,
> installed by the package libc-dev-bin.
>
> - TCH
>
> Sent with Proton Mail secure email.
>
> On Tuesday, November 14th, 2023 at 8:41 PM, Jon Trulson
> wrote:
>
>
> > On 11/14/23 09:30, TCH via cdesktopenv-devel wrote:
> >
> > > Hello,
> >
> >
> > Hi,
> >
> > Just taking a stab here, but do you have rpcgen installed? It should build
> > on debian 11. debian 12 requires you pull from master git.
> >
> > -jon
> >
> >
> > > I've tried to compile CDE on Debian 11 (x86_64), following the build
> > > instructions to the letter (installing all required packages, etc.) and
> > > compiling with ./autogen.sh, ./configure and make, but the compiler
> > > cannot compile it, due missing definitions/constants/etc.
> > > The compiler is GCC 10.2.1, Motif is 2.3.8. The error messages were the
> > > following:
> > >
> > > agent.c: In function ‘_DtCm_init_agent’:
> > > agent.c:145:43: error: ‘AGENTVERS’ undeclared (first use in this
> > > function); did you mean ‘AGENTVERS_2’?
> > > 145 | (void)pmap_unset(_DtCm_transient, AGENTVERS);
> > > | ^
> > > | AGENTVERS_2
> > > agent.c:145:43: note: each undeclared identifier is reported only once
> > > for each function it appears in
> > > agent.c:152:46: error: ‘update_callback’ undeclared (first use in this
> > > function)
> > > 152 | if (registerrpc(_DtCm_transient, AGENTVERS, update_callback,
> > > | ^~~
> > > agent.c:153:25: error: ‘_DtCm_update_callback_1’ undeclared (first use in
> > > this function); did you mean ‘cmcb_update_callback_2’?
> > > 153 | (char *(*)(char *))_DtCm_update_callback_1,
> > > (xdrproc_t)_DtCm_xdr_Table_Res_4,
> > > | ^~~
> > > | cmcb_update_callback_2
> > > agent.c:154:17: error: ‘_DtCm_xdr_Update_Status’ undeclared (first use in
> > > this function); did you mean ‘_DtCm_xdr_Appt_Status_4’?
> > > 154 | (xdrproc_t)_DtCm_xdr_Update_Status) == -1) {
> > > | ^~~
> > > | _DtCm_xdr_Appt_Status_4
> > > agent.c: In function ‘_DtCm_destroy_agent’:
> > > agent.c:187:44: error: ‘AGENTVERS’ undeclared (first use in this
> > > function); did you mean ‘AGENTVERS_2’?
> > > 187 | (void) pmap_unset(_DtCm_transient, AGENTVERS);
> > > |^
> > > |AGENTVERS_2
> > > agent.c: At top level:
> > > agent.c:292:1: error: unknown type name ‘Update_Status’
> > > 292 | Update_Status *
> > > | ^
> > > agent.c: In function ‘_DtCm_update_callback_1’:
> > > agent.c:295:9: error: unknown type name ‘Update_Status’
> > > 295 | static Update_Status status = update_succeeded;
> > > | ^
> > > agent.c:295:32: error: ‘update_succeeded’ undeclared (first use in this
> > > function)
> > > 295 | static Update_Status status = update_succeeded;
> > > |^~~~
> > > agent.c:307:15: error: ‘AGENTVERS’ undeclared (first use in this
> > > function); did you mean ‘AGENTVERS_2’?
> > > 307 | cbi->vers = AGENTVERS;
> > > | ^
> > > | AGENTVERS_2
> > > agent.c: In function ‘_DtCm_handle_callback’:
> > > agent.c:467:20: error: ‘AGENTVERS’ undeclared (first use in this
> > > function); did you mean ‘AGENTVERS_2’?
> > > 467 | if (ptr->vers == AGENTVERS)
> > > |^
> > > |AGENTVERS_2
> > >
> > > Is this a bug, or on Debian 11, something else is needed?
> > >
> > > - TCH
> > >
> > > Sent with Proton Mail secure email.
> > >
> > >
> > > ___
> > > 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
___
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
Re: [cdesktopenv-devel] Port of CDE to the musl C library
As far as I remember Lesstif has always been unsuitable to build CDE. I think one of the OS specific build pages even explicitely mentions not to use Lesstif, but open-motif instead. Since the day Motif has been opensourced there is no real point in using lesstif imho. On Mon, 11 Jan 2021 at 22:56, Lev wrote: > > Hi, > > In case it would make sense to test everything at once, here are the > remaining musl patches. > > I have a couple of concerns with the internationalization refactoring: > > - Dt11GetMessage and DtCatgets both call XtProcessLock. > I don’t have access to a threading implementation of Xlib, but I’ve read some > sources state that Motif 2 allows for recursive calls. LessTif apparently > will deadlock. > > - The application builder will now include MsgCatP.h, a private header, > instead of nl_types.h. > Perhaps this header should be made public? > > Additionally, I am not sure I solved the TCGETS issue in the Desktop Korn > Shell in the cleanest way. > > Kind regards, > Lev > > > > > On Jan 11, 2021, at 14:04, Danilo Pecher > > wrote: > > > > I could try the BSD builds on the weekend. Currently a bit too busy at > > work to do it on week days., > > > > On Mon, 11 Jan 2021 at 02:24, Jon Trulson wrote: > >> > >> Hi, > >> > >> Thanks for your contribution. At a first glance it looks ok, except for > >> patch 0003: > >> > >> Author: Lev Kujawski > >> > >> Date: Wed Jan 6 12:13:40 2021 -0700 > >> > >>Define time_t within AccessI.h by including . > >> > >> diff --git a/cde/lib/DtHelp/AccessI.h b/cde/lib/DtHelp/AccessI.h > >> > >> index 4dcc6270..206135e5 100644 > >> > >> --- a/cde/lib/DtHelp/AccessI.h > >> > >> +++ b/cde/lib/DtHelp/AccessI.h > >> > >> @@ -44,6 +44,7 @@ > >> > >> #ifndef _DtHelpAccessI_h > >> > >> #define _DtHelpAccessI_h > >> > >> > >> > >> +#include > >> > >> > >> > >> #ifndef_XtIntrinsic_h > >> > >> /* > >> > >> > >> > >> I think this should be: > >> > >> #include > >> > >> > >> ... at least for Linux, but definitely not sys/stat.h, which probably > >> includes time.h indirectly. Could you try that change and resubmit that > >> patch? > >> > >> I've applied the others, thanks! > >> > >> I have not tried a BSD build. > >> > >> -jon > >> > >> On 1/6/21 7:36 PM, Lev via cdesktopenv-devel wrote: > >> > >> Hello, > >> > >> The attached patches are the first of a set fixing various > >> incompatibilities between CDE and the musl C library. Musl has become a > >> popular alternative to glibc and uClibc, with distributions like Void > >> already supporting it for desktop use. > >> > >> Advantages of musl include the ease of creating truly standalone static > >> binaries (e.g., no attempts to dlopen() incompatible NSS modules), its MIT > >> license, its strict conformance to contemporary POSIX standards, and its > >> small size. > >> > >> Everything within CDE (including documentation) builds successfully, with > >> only one minor functional deficiency in the CDE Print Manager, which can > >> no longer bind privileged client ports using rresvport(). > >> > >> Kind regards, > >> Lev > >> > >> I > >> > >> > >> > >> ___ > >> cdesktopenv-devel mailing list > >> cdesktopenv-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > >> > >> > >> -- > >> Jon Trulson > >> > >> "Entropy. It isn't what it used to be." > >> -- Sheldon > >> > >> ___ > >> cdesktopenv-devel mailing list > >> cdesktopenv-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > > > > > ___ > > cdesktopenv-devel mailing list > > cdesktopenv-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Port of CDE to the musl C library
I could try the BSD builds on the weekend. Currently a bit too busy at work to do it on week days., On Mon, 11 Jan 2021 at 02:24, Jon Trulson wrote: > > Hi, > > Thanks for your contribution. At a first glance it looks ok, except for > patch 0003: > > Author: Lev Kujawski > > Date: Wed Jan 6 12:13:40 2021 -0700 > > Define time_t within AccessI.h by including . > > diff --git a/cde/lib/DtHelp/AccessI.h b/cde/lib/DtHelp/AccessI.h > > index 4dcc6270..206135e5 100644 > > --- a/cde/lib/DtHelp/AccessI.h > > +++ b/cde/lib/DtHelp/AccessI.h > > @@ -44,6 +44,7 @@ > > #ifndef _DtHelpAccessI_h > > #define _DtHelpAccessI_h > > > > +#include > > > > #ifndef_XtIntrinsic_h > > /* > > > > I think this should be: > > #include > > > ... at least for Linux, but definitely not sys/stat.h, which probably > includes time.h indirectly. Could you try that change and resubmit that > patch? > > I've applied the others, thanks! > > I have not tried a BSD build. > > -jon > > On 1/6/21 7:36 PM, Lev via cdesktopenv-devel wrote: > > Hello, > > The attached patches are the first of a set fixing various incompatibilities > between CDE and the musl C library. Musl has become a popular alternative to > glibc and uClibc, with distributions like Void already supporting it for > desktop use. > > Advantages of musl include the ease of creating truly standalone static > binaries (e.g., no attempts to dlopen() incompatible NSS modules), its MIT > license, its strict conformance to contemporary POSIX standards, and its > small size. > > Everything within CDE (including documentation) builds successfully, with > only one minor functional deficiency in the CDE Print Manager, which can no > longer bind privileged client ports using rresvport(). > > Kind regards, > Lev > > I > > > > ___ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > > -- > Jon Trulson > > "Entropy. It isn't what it used to be." >-- Sheldon > > ___ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Release Strategy
I'll change the wiki pages accordingly when I have the time (probs tomorrow). I would suggest that once a major change has been done (like recently solving the gcc 10 breakage) we test on all platforms and push out a new source package. That way we've always got a safe release for new users or people like me who actually use CDE in everyday work. Btw, Jon, you probably installed the binary packages, but that can leave you with fairly outdated packages in the older FSBDs that are still in support (9x, 10x). I was talking about building from source. If you use precompiled packages, you can actually use the binary CDE package just as well. FreeBSD is the only distro that comes with a precompiled CDE. They're currently providing 2.3.1. Cheers, Danilo On Sun, 29 Nov 2020 at 01:21, Jon Trulson wrote: > On 11/28/20 3:54 PM, Danilo Pecher wrote: > > Hi folks, > > May I offer a suggestion? We need something of a release strategy. We > should depart from the "pull stuff from the git repo" strategy in the > Wikis, because we keep breaking our build by pushing untested stuff. > > As I build CDE daily on several platforms to test the builds, I can pretty > much pinpoint the latest breakage to Thursday. On Wednesday it built on > FreeBSD, NetBSD, Raspbian, Ubuntu, Fedora and CentOS - on Friday it was > broken on all of them because of the breakage I reported earlier today. > > > This is going to happen... The issue is not a release strategy problem, > it's a lack of CI problem. Of course the mistake in the above issue was > committing a change that had not been tested in a full CDE build. That is > something we try very hard to avoid, but apparently that did not happen > with the libcsa changes. > > But a problem is that that even if it had, and lets say it worked on the > linuxen - there is no guarantee it would not break on the BSD's or Solaris > for example since people will (hopefully) test on the OS/hardware they > have, and that will be good enough for them. > > Ideally, when someone comes across a problem on a platform, they should > send a patch along that fixes it. But not too many people do that. As a > matter of fact, it's pretty rare these days. > > And I can only speak for myself, but I have a day job - so I don't get a > lot of time anymore to 'play' with CDE, and write patches for people who > can't be bothered to write and submit them themselves. > > Having some sort of CI would be a good interim solution for that, but > alas, there is no such animal with SF. It would be up to people (like you) > who can/do run multiple OS's and can identify problems. But then depending > on that has it's own issues as people enter and leave the project. > > I'm not really sure how to resolve that problem, other than setting up > some sort of setup like you have and using jenkins or some such to test all > builds (based on a commit) and send a status somewhere indicating failure. > But that will take more time than I currently have, and money too. > > Master should generally always be considered 'unstable' - though it should > ALWAYS be build-able on linux (ubuntu LTS). Though I will admit - if you > send a patch or commit one, you should certainly make sure it doesn't break > things. But as I mentioned above, without some kind of formal CI > infrastructure we can't really 'enforce' that. > > For me personally that isn't much of a big deal, but I'm out there banging > the drum for the project and I look a bit of a berk if people then run into > a broken build by following our Wiki instructions. Wouldn't it be better if > we regularly released tested tar.gz releases and left the bleeding edge git > stuff to internal testing? It would also greatly reduce the > pre-requirements, especially on FreeBSD where, due to the rampant > dependency bloat in the ports collection, just compiling git can easily > hand you a 3-hour time penalty. > > > Odd... I was test building on FBSD some months ago for the autotools > branch, and I just installed the relevant packages. IIRC, there was very > little I had to actually build via the ports collection, and when I did, I > only needed to do it once. Don't recall off-hand what I built vs. what I > installed via the package manager. I believe I just followed the wiki :) > And building git cannot be more expensive than building CDE... > > Also, 2020 has been somewhat of a challenging year :) > > -jon > > > > > Cheers, > Danilo > > > ___ > cdesktopenv-devel mailing > listcdesktopenv-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > > -- > Jon Trulson > > "Entropy. It isn't what it used to be." >
Re: [cdesktopenv-devel] Builds broken again
Hi, The build does now work again on all platforms, but a new problem has arrived. The startup on NetBSD i386 takes hilariously long - nearly 10 minutes and my suspicion is that it is down to ttsession. Is there a way to create as trace of the startup to find out where it is getting stuck? I already tried reverting rpcbind back to running in insecure mode, but the result is, as near as makes no difference, the same. There's a lot of processes in 'wait' state in top until it finally decides to start. On Sun, 29 Nov 2020 at 03:04, Peter Howkins wrote: > On Sat, 28 Nov 2020 at 23:56, Jon Trulson wrote: > >> On 11/28/20 7:21 AM, Danilo Pecher wrote: >> >> dtcm build is broken on NetBSD, GreeBSD and Ubuntu. What was changed? >> >> > Git history is here; > > https://sourceforge.net/p/cdesktopenv/code/ci/master/tree/ > > and click on the History button. > > > This was the change that caused the issue; > > > https://sourceforge.net/p/cdesktopenv/code/ci/c62a5049ed63fc5900455c2fdcc7d914bf029b00/#diff-2 > > I removed a macro (P) from a library, and all instances of it being used > there. However I forgot to check for that macro where the library was being > used. > > I've pushed a fix for dtcm now. > > Peter > > -- > Peter Howkins > peter.howk...@marutan.net > https://www.marutan.net/ > ___ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
[cdesktopenv-devel] Release Strategy
Hi folks, May I offer a suggestion? We need something of a release strategy. We should depart from the "pull stuff from the git repo" strategy in the Wikis, because we keep breaking our build by pushing untested stuff. As I build CDE daily on several platforms to test the builds, I can pretty much pinpoint the latest breakage to Thursday. On Wednesday it built on FreeBSD, NetBSD, Raspbian, Ubuntu, Fedora and CentOS - on Friday it was broken on all of them because of the breakage I reported earlier today. For me personally that isn't much of a big deal, but I'm out there banging the drum for the project and I look a bit of a berk if people then run into a broken build by following our Wiki instructions. Wouldn't it be better if we regularly released tested tar.gz releases and left the bleeding edge git stuff to internal testing? It would also greatly reduce the pre-requirements, especially on FreeBSD where, due to the rampant dependency bloat in the ports collection, just compiling git can easily hand you a 3-hour time penalty. Cheers, Danilo ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
[cdesktopenv-devel] Builds broken again
dtcm build is broken on NetBSD, GreeBSD and Ubuntu. What was changed? cm_tty.h:222:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'P' extern Validate_op validate_appt P((Dtcvm_appointment*, Cheers, Danilo ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
[cdesktopenv-devel] CDE Builds
Hi everybody, I'd like to summarize some of the things we've learned over the last three days: 1. The good news - most of the Builds have been repaired. NetBSD, Fedora, CentOS and some intransigent Debian derivatives build again. If you still run into problems, please make sure to produce a log files, so it can be looked at by using this sequence to build : make World 2>$1 | tee cde-make.log Please note: on BSD variants, you might need to build and use bash for the stderr->stdout redirection to work. If you want to investigate the log file yourself, search for the sequences *error:*and [ * to find any possible errors. Not all break the build, but will result in missing files during installation. One error that recently came up is the failure to build libcsa. If you see that error, your system lacks a tool called rpcgen. failure to build libcsa in turn breaks the build of the documentation files, which was the main reason for so many platforms failing to build. Speaking of which: I've tested between several platforms and could confirm that the documentation files are platform independent. That means we can take them out of the build process in the autotool conversion and just ship a pre-processed package. I'll prepare such a package over the weekend. Cheers, Danilo ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Fedora Build repaired (sort of)
That error means you don't have the rpcbind service running On Tue, 24 Nov 2020 at 17:54, Antonis Tsolomitis < antonis.tsolomi...@gmail.com> wrote: > > > True. So the package > > rpcsvc-proto > > needs to be installed on Arch/Manjaro. This information is missing from > > > https://sourceforge.net/p/cdesktopenv/wiki/Archlinux_Build/#install-packages > > Can it be added? > > Now libcsa has been compiled and installed. The problem however persists > on Manjaro. > ttsession (although build and installed): > > "The desktop messaging system could not be started" > 1. Click OK etc etc > > On another window: > "A ToolTalk connection could not be established.. no ttsession > process is running". > > These are typical errors for CDE from the past. So what to look for should > be known to > experts of the CDE code. So, any idea how to debug? > > Antonis. > > > On 11/24/20 3:25 PM, Danilo Pecher wrote: > > If libcsa isn't built, you're most likely missing rpcgen on your system > > On Tue, 24 Nov 2020 at 14:20, Antonis Tsolomitis < > antonis.tsolomi...@gmail.com> wrote: > >> On 11/24/20 7:57 AM, Peter Howkins wrote: >> >> >> I've pushed a series of patches to master that should resolve the GCC 10 >> build issues. Hopefully that will be enough to get the Fedora build >> working, but I've only tested it on Debian. >> >> Peter >> >> -- >> Peter Howkins >> peter.howk...@marutan.net >> https://www.marutan.net/ >> >> >> >> >> Yes it compiles on Debian testing. However there are some problems in >> dtterm shown in attached screenshot. >> I remember this is an old problem but I forgot its solution. At the >> beggining of the screenshot I enabled Return and Line feed >> so no stairs get priduced. But then I can not use mv -i as I get the >> prompt immediately after the overwrite question. >> >> On ManjaroLinux/Arch it compiles but libcsa does not get produced. >> The make log for Manjaro is located here >> https://myria.math.aegean.gr/~atsol/tmp/make.log >> >> Moreover, the desktop does not start on Manjaro/Arch... it complains >> about /etc/hosts and the messaging system that does not get started. >> I do not know if this is related to libcsa. >> >> Antonis. >> ___ >> cdesktopenv-devel mailing list >> cdesktopenv-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >> > > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Fedora Build repaired (sort of)
If libcsa isn't built, you're most likely missing rpcgen on your system On Tue, 24 Nov 2020 at 14:20, Antonis Tsolomitis < antonis.tsolomi...@gmail.com> wrote: > On 11/24/20 7:57 AM, Peter Howkins wrote: > > > I've pushed a series of patches to master that should resolve the GCC 10 > build issues. Hopefully that will be enough to get the Fedora build > working, but I've only tested it on Debian. > > Peter > > -- > Peter Howkins > peter.howk...@marutan.net > https://www.marutan.net/ > > > > > Yes it compiles on Debian testing. However there are some problems in > dtterm shown in attached screenshot. > I remember this is an old problem but I forgot its solution. At the > beggining of the screenshot I enabled Return and Line feed > so no stairs get priduced. But then I can not use mv -i as I get the > prompt immediately after the overwrite question. > > On ManjaroLinux/Arch it compiles but libcsa does not get produced. > The make log for Manjaro is located here > https://myria.math.aegean.gr/~atsol/tmp/make.log > > Moreover, the desktop does not start on Manjaro/Arch... it complains about > /etc/hosts and the messaging system that does not get started. > I do not know if this is related to libcsa. > > Antonis. > ___ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] git version fails to build on Debian derivative PureOS
I think it was Marcin, who had that idea yesterday, and I extended it to the C++ command as well. I noticed you ran into the same errors as the broken Fedorabuild, which are ultimately down to GCC 10. Good to hear that it works again for you :) On Mon, 23 Nov 2020 at 23:04, Antonis Tsolomitis < antonis.tsolomi...@gmail.com> wrote: > > YES! This modification makes the compilation of the docs successful. > > So please add this to git > > I get a successful build although it reports that it compiled CDE 2.3.1a > (stable was 2.3.2) > The help system works fine once again. > > I will compile on Arch tomorrow and report back. > > The make.log is here: > > https://myria.math.aegean.gr/~atsol/tmp/make.log > > Antonis. > > > > > > On 11/23/20 11:09 PM, Danilo Pecher wrote: > > Find these two lines in config/cf/linux.cf > > #define CcCmd gcc -g -pipe > #define CplusplusCmdg++ -g -pipe > > and change them to > > #define CcCmd gcc -g -pipe -fcommon > #define CplusplusCmdg++ -g -pipe -fcommon > > then > > make clean && make World 2>&1 | tee make.log > > On Mon, 23 Nov 2020 at 21:08, Antonis Tsolomitis < > antonis.tsolomi...@gmail.com> wrote: > >> On 11/23/20 8:38 PM, Peter Howkins wrote: >> >> On Mon, 23 Nov 2020 at 18:36, Antonis Tsolomitis < >> antonis.tsolomi...@gmail.com> wrote: >> >>> On 11/23/20 8:32 PM, Peter Howkins wrote: >>> >>> >>> >>> On Mon, 23 Nov 2020 at 14:50, Antonis Tsolomitis < >>> antonis.tsolomi...@gmail.com> wrote: >>> >>>> >>>> OK, I run the above modified command. Here is the build log: >>>> >>>> https://myria.math.aegean.gr/~atsol/tmp/cde-make.log >>>> >>>> dtstyle does not get build. >>>> >>> >>> Thanks for making this log, I've pushed a fix to git head that should >>> fix this dtstyle problem, but if you could test it and confirm the fix that >>> would be useful. >>> >>> >>> Sure I can test. So I just get the git version and compile? >>> >> >> Yep :) checkout the git version and compile and install using the same >> commands as before. >> >> Peter >> >> >> I verify that CDE from git compiles including dtstyle on PureOS (Debian) >> and works fine othat than docs. >> I do not see dtinfo and dthelpview. Help is not available. >> >> New compilation log is again here: >> >> https://myria.math.aegean.gr/~atsol/tmp/cde-make.log >> >> I will also try on Arch and Manjaro. >> >> thanks a lot, I will start configuring it for my daily use. >> >> Antonis. >> >> >> ___ >> cdesktopenv-devel mailing list >> cdesktopenv-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel >> > > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
[cdesktopenv-devel] Fedora Build repaired (sort of)
Moin, Okay, I got CDE to compile cleanly under Fedora 33. The two main problems were that Fedora splatters the depedencies all over the place and second, the breakage introduced by gcc 10. Mucking up other people's code seems to be the norm these days ind Linux-land. Here's how to compile cleanly in Fedora: 1. Install dependencies --- cat > pkgs << EOF git gcc g++ binutils make patch libXp-devel libXt-devel libXinerama-devel libXpm-devel libXft-devel libXmu-devel motif-devel libXaw-devel libX11-devel libXScrnSaver-devel libtirpc-devel xorg-x11-server-utils libjpeg-turbo-devel freetype-devel openssl-devel tcl-devel ksh m4 ncompress xorg-x11-fonts-100dpi xorg-x11-fonts-75dpi rpcbind bison glibc-locale-source libXdmcp-devel rpcgen EOF sudo dnf -y install $(cat pkgs | tr '\n' ' ') 2. Add -fcommon to linux.cf in cdesktopenv-code/cde/config/cf/linux.cf #define CcCmd gcc -g -pipe -fcommon #define CplusplusCmdg++ -g -pipe -fcommon 3. Build and install as usual The package compiles nearly cleanly. There's a single WARF error, that has to do with the debug data, but doesn't break the build. When executing installCDE I get some weird awk-errors like these awk: /tmp/awkFHstQzL9zy9NSEvQGH3gZ:370: (FILENAME=/usr/local/src/cdesktopenv-code/cde//databases/CDE-RUN.udb FNR=10) warning: regexp escape sequence `\:' is not a known regexp operator awk: /tmp/awkFHstQzL9zy9NSEvQGH3gZ:371: (FILENAME=/usr/local/src/cdesktopenv-code/cde//databases/CDE-RUN.udb FNR=10) warning: regexp escape sequence `\;' is not a known regexp operator awk: /tmp/awkFHstQzL9zy9NSEvQGH3gZ:372: (FILENAME=/usr/local/src/cdesktopenv-code/cde//databases/CDE-RUN.udb FNR=10) warning: regexp escape sequence `\=' is not a known regexp operator Again, they don't seem to break the install. I'm still investigating those. Cheers, Danilo ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Fedora build is utterly broken
Yep, it would work as a stop-gap measure, but since the next gcc release will be just around the corner and will break more stuff, as they usually do with every realease, I think a more thorough code review might be more helpful. While we're at it, we might also try to get rid of the thousands of warnings that Clang throws under FreeBSD. All those recent C++ standards really hake a machete to legacy code :( On Sun, 2020-11-22 at 22:22 +, Marcin Cieslak wrote: > On Sun, 22 Nov 2020, Marcin Cieslak wrote: > > > On Sun, 22 Nov 2020, Danilo Pecher via cdesktopenv-devel wrote: > > > > > Yep. gccc 10.2. Bloody hell, why can't people just stop breaking > > > things > > > with feature creep. I'll have a look tomorrow if I can use > > > Marcin's > > > method to get this to compile. > > Adding -fcommon for CcCmd in linux.cf (there must be a better place > for this) worked, > I only get this DWARF error, but dtmail gets built anyway > > g++ -g -pipe -o dtmail -O2 -fno-strict-aliasing -Wno-write- > strings -Wno-unused-result -L../../../exports/lib - > L/usr/lib AliasListUiItem.o AlternatesListUiItem.o > AntiCheckBoxUiItem.o AttachArea > .o Attachment.o CheckBoxUiItem.o > CheckForMailUiItem.o ComposeCmds.o > CustomListUiItem.o Dialog.o > DialogShell.o DmxMailbox.o DmxMessage.o > DmxPrintJob.o DmxPrintOptions.o > DmxPrintOutput.o DmxPrintSetup.o > DmxUtils.o DtEditor.o > DtMailEditor.o DtMailGenDialog.o DtMail > WDM.o Editor.o > EncryptedTextFieldUiItem.o FindDialog.o > Fonts.o Icon.o > IgnoreListUiItem.o Image.o > InboxTextFieldUiItem.o IndexedOptionMen > u.o IndexedOptionMenuUiItem.o ListUiItem.o > MailRcSource.o MailRetrievalOptions.o > MailSession.o MoveMenuListUiItem.o MsgHndArray.o > MsgScrollingList.o NoOpCmd.o Op > tCmd.o PasswordDialogManager.o > PropUi.o QueryDialogManager.o > RoamApp.o RoamCmds.o > RoamInterruptibleCmd.o RoamMenuWindow.o Scal > eUiItem.o SendMsgDialog.o > Sort.o SortCmd.o > SpinBoxUiItem.o StringTab.o > TemplateListUiItem.o TextFieldUiItem.o Undelete.o > ViewMsgDialog.o > WMSaveSession.o XmStrCollector.o > XmTextEditor.o XtArgCollector.o > dtb_utils.o options_stubs.o options_ui.o > options_util.o ../libDtMail/libDtMail.a > ../MotifApp/libMotifApp.a -lDtPrint -lDtHelp -lDtWidget -lDtSvc -ltt > -lXm -lXt -lSM -lICE -lXext -lX11 -L/usr/dt/lib -L/usr/lib - > lm -Wl,-rpath,/usr/dt/lib:/usr/li > b > /usr/bin/ld: /usr/bin/ld: DWARF error: could not find variable > specification at offset 6715 > RoamApp.o: in function `tooltalk_save_buffer_to_file(unsigned char*, > int)': > /home/saper/space/cdesktopenv/code/cde/programs/dtmail/dtmail/RoamApp > .C:515: warning: the use of `tempnam' is dangerous, better use > `mkstemp' > /usr/bin/ld: ../libDtMail/libDtMail.a(RFCMailBox.o): in function > `RFCMailBox::lockFile(DtMailEnv&)': > /home/saper/space/cdesktopenv/code/cde/programs/dtmail/libDtMail/RFC/ > RFCMailBox.C:3947: warning: the use of `mktemp' is dangerous, better > use `mkstemp' or `mkdtemp' > make[4]: Leaving directory > '/home/saper/space/cdesktopenv/code/cde/programs/dtmail/dtmail' ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Fedora build is utterly broken
Yep. gccc 10.2. Bloody hell, why can't people just stop breaking things with feature creep. I'll have a look tomorrow if I can use Marcin's method to get this to compile. On Sun, 2020-11-22 at 21:21 +, Adam Sampson wrote: > Danilo Pecher via cdesktopenv-devel > writes: > > > The Fedora builds seem to be completely broken, and for the moment > > I > > haven't got the faintest clue why. Linkage is broken with massive > > error > > blocks like these. > [...] > > /usr/bin/ld: raima/cmtype.o:/usr/local/src/cdesktopenv- > > code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of > > `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- > > code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here > > Has the build environment been upgraded to GCC 10? If so, that's why: > it > defaults to -fno-common, so it doesn't automatically merge multiple > definitions of the same symbol. > > This particular error is because the definition of the variable > __SK__ > in the header file is missing an "extern", so it emits a separate > definition in every file that includes that header. (Although it > looks > like nothing uses __SK__ anyway, so it could just be simplified to a > definition of "struct sk".) > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
[cdesktopenv-devel] Fedora build is utterly broken
The Fedora builds seem to be completely broken, and for the moment I haven't got the faintest clue why. Linkage is broken with massive error blocks like these. (cd .; T=`echo libDtSearch.so.2.1 | sed 's/\.[^\.]*$//'`; gcc -g -pipe -o ./libDtSearch.so.2.1~ -shared -Wl,-soname,$T apndext.oausdopen.oausexit.obmstrstr.oboolpars.oboolsrch.oboolyac.ocuslang.odbchange.odberr.odelspace.odtoe.odtoeinit.odtsrapi.odtsrdbrec.odtsrjoint.odtsrswab.odtsrutil.odtsrve.oendslash.ofileman.oglobals.ohdecode.ohencode.ohilite.oiscompat.oisduprec.ojpn.olang.olangmap.omsgs.omsgutil.oobjdate.oocf.oopendblk.oophuf.oreadchar.ostrupr.ouserint.ovedelete.ovestatis.ovstfunct.oraima/alloc.oraima/cmtype.oraima/connect.oraima/cotype.oraima/crget.oraima/crread.oraima/crset.oraima/crtype.oraima/crwrite.oraima/csmget.oraima/csmread.oraima/csmset.oraima/csmwrite.oraima/csoget.oraima/csoread.oraima/csoset.oraima/csowrite.oraima/dbacode.oraima/dbdpath.oraima/dbfpath.oraima/dblfcns.oraima/dbswab.oraima/dbuserid.oraima/delete.oraima/destroy.oraima/dio.oraima/discon.oraima/disdel.oraima/fillnew.oraima/findco.oraima/findfm.oraima/findlm.oraima/findnm.oraima/findpm.oraima/initial.oraima/inittab.oraima/ismember.oraima/isowner.oraima/keydel.oraima/keyexist.oraima/keyfcns.oraima/keyfind.oraima/keyfrst.oraima/keylast.oraima/keynext.oraima/keyprev.oraima/keystore.oraima/libfcns.oraima/makenew.oraima/mapchar.oraima/members.oraima/oflag.oraima/opens.oraima/options.oraima/pathfcns.oraima/recfcns.oraima/recfrst.oraima/reclast.oraima/recnext.oraima/recprev.oraima/recread.oraima/recset.oraima/recwrite.oraima/renfile.oraima/rwcurr.oraima/setdb.oraima/setmm.oraima/setmo.oraima/setmr.oraima/setom.oraima/setoo.oraima/setor.oraima/setrm.oraima/setro.oraima/startup.o-lm; rm-f$T&$T) /usr/bin/ld: raima/cmtype.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/connect.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/cotype.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/crget.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/crread.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/crset.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/crtype.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/crwrite.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/csmget.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/csmread.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/csmset.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/csmwrite.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/csoget.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__'; raima/alloc.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: first defined here /usr/bin/ld: raima/csoread.o:/usr/local/src/cdesktopenv- code/cde/lib/DtSearch/raima/dbtype.h:410: multiple definition of `__SK__';
Re: [cdesktopenv-devel] git version fails to build on Debian derivative PureOS
These problems are sadly occurring on several problems, including NetBSD, OpenBSD and cygwin. Unfortunately the doc tools don't give much away in the way of error messages. It may be a prudent idea to split the doc files off from the actual build. After all, they are supposed to be platform-independent, so why not provide a package of ready-made documentation files, which I would hazard a guess don't change too often anyway. It doesn't make sense to rebuild them every time, especially since that seems to be the single most frequent reason for build-breakage. On Thu, 12 Nov 2020 at 10:55, Antonis Tsolomitis < antonis.tsolomi...@gmail.com> wrote: > > Both stable and git versions have the same problems on both PureOS > (=Debian testing) and Manjaro Linux. > It is not only documentation that does not get build. dtstyle does not get > build either. dthelpview and all doc programs. > But dtstyle why? It has nothing ti do with locale. Does it? > > The stable version ends up with a success message although earlier it has > errors. > For example: > > make[4]: Entering directory '/home/atsol/Downloads/cde-2.3.2/doc/C/guides' > LANG=C SGML_SEARCH_PATH=".:.." > LD_LIBRARY_PATH=../../../exports/lib:/usr/dt/lib:/usr/lib > DTLCXSEARCHPATH=../../../lib/DtHelp > DTINFO_HOME=../../../programs/dtinfo/dtinfogen > DTINFO_BIN=../../../programs/dtinfo/dtinfogen/install:../../../programs/dtinfo/dtinfogen/mmdb/StyleSheet:../../../programs/dtinfo/dtinfogen/mmdb/src:../../../programs/nsgmls:../../../programs/dtsr > ../../../programs/dtinfo/dtinfogen/infolib/etc/dtinfogen tocgen -T > ../../../doc/tmp -n cde -d "CDE and Motif Information Library" -f > usersGuide/TOC.sgm -id cde.usersGuide.toc -title "User's Guide" > usersGuide/book.sgm > *dtinfogen: dtsrcreate not found* > make[4]: *** [Makefile:767: usersGuide/TOC.sgm] Error 255 > > blah blah blah (=errors for locales) and then: > > Full build of Release 2.3.2 of CDE complete. > > In the wiki there are instructions for Arch which I used for Manjaro. But > I will try Arch too although I do not think > that this is the problem. I expected to compile on Debian testing but it > does not. > > Antonis. > > > On 11/9/20 7:38 AM, Brian Cole wrote: > > Aha! I can, however, also reproduce your solution:) > https://builds.sr.ht/~yjftsjthsd/job/337668 is the same as before, except > that it starts by running: > > sudo locale-gen de_DE > sudo locale-gen es_ES > sudo locale-gen fr_FR > sudo locale-gen it_IT > sudo update-locale > > > And that works:) I'm not convinced that it makes sense to require having > all that (can we do a CDE build with just C/en_US?), but it does work. If > we do want that to be The Solution, then at a minimum the wiki should be > updated and we should find out what the equivalent is on other supported > OSs. > > On Sun, Nov 8, 2020, at 11:46 PM, Brian Cole wrote: > > FWIW, I can easily reproduce this building from master on Ubuntu 18.04; > * https://builds.sr.ht/~yjftsjthsd/job/337574 is a build with just `make > World` and fails > * https://builds.sr.ht/~yjftsjthsd/job/337610 is a build with `make > World.dev` and succeeds > * https://builds.sr.ht/~yjftsjthsd/job/337637 is a build with `make > World` preceeded by `export LANG=C` and fails > * https://builds.sr.ht/~yjftsjthsd/job/337644 is a build with `make > World` preceeded by `export LANG=it_IT.ISO8859-1` and fails > > (you can hit "view manifest" on the left to see the exact commands in each > build) > > On Sun, Nov 8, 2020, at 6:01 AM, Edmond Orignac wrote: > > Is the italian locale installed ? on Ubuntu 20.04, locale -a |grep -i > iso8859 gives > > > de_DE.iso88591 > es_ES.iso88591 > fr_FR.iso88591 > it_IT.iso88591 > > > and the CDE build succeeds. > > Another possibility is that the build of the documentation fails when the > locale is UTF-8. > > You could try to do export LANG=C or export LANG=it_IT.ISO8859-1 before > make World > > to see if the build succeeds. > > As a last option, you could try to do make World.dev to exclude building > the documentation. > > I expect the developpers will have better ideas to try out. > > Best, > > E. Orignac > > > Le 08/11/2020 à 11:23, Antonis Tsolomitis a écrit : > > > I just saw that Mike T. has the same problem in Arch. So it is not a > Debian/PureOS problem. > > Antonis. > > > > On 11/8/20 12:04 PM, Antonis Tsolomitis wrote: > > I am trying to compile CDE on a Librem13 Laptop with the latest PureOS. > > PureOS is a Debian derivative by Purism who produces these latops, and I > have > enabled their rolling system, which is essentially Debian testing. > So I follow the Debian instructions. > > Compilation stops with the following error. How to fix this? It does not > like Italian?:-) > > thank you, > > Antonis. > > LANG=it_IT.ISO8859-1 SGML_SEARCH_PATH=".:.." > LD_LIBRARY_PATH=../../../exports/lib:/usr/dt/lib:/usr/lib > DTLCXSEARCHPATH=../../../lib/DtHelp /bin/ksh > ../../../programs/dtdocbook/doc2sdl/dtdocbook -t >
[cdesktopenv-devel] Minor site corrections and Broken builds
Hi everybody, I've made some minor corrections to the Wiki build pages concerning the git cloning which doesn't work with the https protocol on some BSDs. Apart from that, NetBSD build seems to be currently broken, it bombs out trying to build the Italian documents, I'll try to find out what's wrong there. Also, I finally took delivery of my shiny new ESX server so I do have now a whole server farm of all major Linux Distros and BSDs to text the building process on each. I'll report back over the next days, which ones work or don't and will edit the build pages accordingly. Cheers, Danilo ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] ArchLinux Build
I noticed the same on some systems. I wasn't yet able to pin down the reason, but a simple 'reset' command resets the shell to sane beaviour. It's a workaround for the time being. On Sun, 24 Mar 2019 at 13:28, Antonis Tsolomitis < antonis.tsolomi...@gmail.com> wrote: > > I tried on ArchLinux (cde 2.3.0) and I have the following problem. > Dtterm behaves strange after pressing Return (see screenshot). > > If I go to Terminal Options it says that Newline sequence is Return only. > > If I change this to Return/Linefeed the problem is corrected. However > it applies only to the current terminal. > > So, is this a bug? > > How do I set this to the correct choice as a default for all dtterms ? > > Antonis. > ___ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] NetBSD TCL patch
Hi Jon, I'll have a look into creating a git patch, but that may take a day or two as I'm on a business trip for the next days. As for the gencat issue: Many non-Linux systems use their own standard tools. gencat is part of the C-Library, and the BSDs use their own implementation instead of glibc. I'll try your suggested fix when I have the time, We'll have to check for Solaris and OpenIndiana too, as I would hazard a guess that Ulrich hasn't made that change out of boredom. cheers, Danilo On Sat, 23 Feb 2019 at 21:04, Jon Trulson wrote: > On 2/22/19 11:57 PM, Danilo Pecher wrote: > > Moin, > > > > I've done the proposed change to enable using the system TCL on NetBSD, > > and that fixes the build, mostly. There are still the nls errors to deal > > Hi, could you resend that in git format-patch format? This is just a > diff, which requires me to create the commit (and claim all credit for > it :) myself. > > > with. I've attached the build log (just search for '10040') They all > > come from a single common sgml per language, but spread to over 300 > files. > > > > The only fix I know of is substituting \\\" for a simple ´. That fixes > > it for me. > > > > cde/programs/localized/C/types/_common.dt.tmsg > > Well, it looks like this was changed from ' to \\\" in commit 01d6c36 by > Ulrich Wilkens for OpenIndiana and Solaris way back in Oct 2014. GNU > gencat seems ok with either. > > I wonder if something like this might work for all systems: > > $quote " > 10040 ERROR: "%(File)Arg_1%" is not a folder. > $quote > > I made the change and tested on ubuntu 18.04 without issues... > > ? Ulrich? > > -jon > > > cheers, Hippo > > > > > > ___ > > cdesktopenv-devel mailing list > > cdesktopenv-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > > > > -- > Jon Trulson > > "The Party told you to reject the evidence of your eyes and ears. >It was their final, most essential command." > >-- 1984 > > > ___ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] NetBSD build broken
I'm setting up a new i386 8.0 VBox as we speak and will try to fiddle with the build tomorrow. The main cf file will need some major rework as it has a lot of stuff unnecessarily hardcoded, which dooms the whole attempt as soon as you try something as nefarious as bootstrapping pkgsrc somewhere else but /usr/pkg, like, let's say /usr/local. The NetBSD gencat is a problem too, as it doesn't recognize some escape sequences like \\\". Unfortunately that one's used for message 10040 in a common dt file linked to by over 300 other files and effectively nukes the whole documentation side of the build. I don't think we'll get away with a single weekend of work on that one. ;) I have an ancient Compaq nx8220 that's been running NetBSD since the Romans left, and CDE has been its Desktop since it was open-source'd. Getting that back into running order is a personal thing ;-) Cheers. Hippo On Fri, 22 Feb 2019 at 21:35, Swift Griggs wrote: > On Fri, 22 Feb 2019, Danilo Pecher via cdesktopenv-devel wrote: > > Ah, that would explain it. The whole NetBSD configuration is ancient to > > begin with. The imake config file still caters for oddities of NetBSD > > 1.1 (!!). I'll have a look into it. > > Yes, it's a good hint. I can give it a try, too (on 8.0 AMD64), but not > until later this weekend. If you get it fixed first, shoot a note to the > list if you have time. > > Thanks, >Swift > > > ___ > cdesktopenv-devel mailing list > cdesktopenv-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel > ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
[cdesktopenv-devel] New supported Platform
Moin, We can add CentOS to the list of supported platforms. The build went very well on my C7 rig. Build instructions are up in the wiki https://sourceforge.net/p/cdesktopenv/wiki/CentOSBuild/ It also contains instructions on how to create a systemd unit for dtlogin, for distros that have gone svchost.exe, like Debian and recent Ubuntu's. Cheers, Hippo ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] NetBSD build broken
Ah, that would explain it. The whole NetBSD configuration is ancient to begin with. The imake config file still caters for oddities of NetBSD 1.1 (!!). I'll have a look into it. Thanx for the hint. Using the system-provided version won't even introduce any new dependencies as tcl is a dependency of git anyway. Cheers- Hippo On Fri, 2019-02-22 at 17:49 +, Chase wrote: > 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: > https://sourceforge.net/p/cdesktopenv/code/ci/master/tree/cde/programs/dtdocbook/instant/Imakefile > > Thank you for your time, > -Chase > > > > > ‐‐‐ Original Message ‐‐‐ > On Friday, February 22, 2019 9:58 AM, Danilo Pecher < > danilo.pec...@data-experts.biz> wrote: > > > Hi all, > > > > At the time the CDE build on all NetBSD variants seems to be > > broken. The programs build fine if one uses the ancient binary > > build of ast-ksh, but none of the documentation builds. Build > > process stops without any meaningful error message whatsoever : > > > > dtdocbook fatal error: > > Error processing book.out.sdl by > > ../../../programs/dthelp/parser/pass2/htag2 > > > > That happens for all languages != C > > > > I seem to remember that we had something like that in the past > > already.. > > > > Cheers, Hippo ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
[cdesktopenv-devel] NetBSD build broken
Hi all, At the time the CDE build on all NetBSD variants seems to be broken. The programs build fine if one uses the ancient binary build of ast-ksh, but none of the documentation builds. Build process stops without any meaningful error message whatsoever : dtdocbook fatal error: Error processing book.out.sdl by ../../../programs/dthelp/parser/pass2/htag2 That happens for all languages != C I seem to remember that we had something like that in the past already.. Cheers, Hippo ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
Re: [cdesktopenv-devel] Back in the flock
Hi all, Thanks for the replies. I was expecting calls to bring back CDEbian, but I'm somewhat torn on that, since Debian, like far too many distros has gone to the dark side and switched to systemd, which turns a perfectly servicable Linux into Windows 9 Linux OS, so it's either a fork from debian or going the full mile and make a distro based on LFS, which also has the added bonus of being tailor made for the architecture. I have a test rig with a Ryzen 5 2500U octo-core, which has both Ubuntu 18.04 and my current nightly build of "CDELfs" on it. Ubuntu doesn't even boot without deactivating half the processor's features by kernel command line. The LFS instead takes about 4 hours to compile and install, which is certainly a point to be made in its disfavour, but it boots cleanly and in comparison to the generic code in the Ubuntu install, the optimized LFS binaries are almost comically fast. for instance the build times for CDE: On Ubuntu 18.04: 6 minutes, 34 seconds On LFS: 2 minutes, 16 seconds. So I'm leaning towards LFS, but the lack of a package manager is a a severe drawback. Currently I'm evaluating two possible candidates : pkgsrc and portage-index, which might mitigate that. dtmail will most certainly get a hefty refresh, but it will have to be a rewrite, as I know of no halfway up-to-date motif based email client that one could start with. In a first step I'm planning on a plain-text only version as I also don't know of any halfway decent motif-based web engine and introducing masses of gome or kde dependencies would beat the purpose of CDE. Cheers, Hippo On Wed, 2019-02-20 at 23:27 -0600, Matthew R. Trower wrote: > Additionally, ninja or meson would severely restrict platform > support. CMake could be alright. > > It would be great to see DtMail given new life. > > -mrt > > From: Christopher Turkel > Sent: Wednesday, February 20, 2019 20:50 > To: CDE development > Subject: Re: [cdesktopenv-devel] Back in the flock > > Bring back CDEbian, that would be great! > > CDE still builds on OpenBSD just fine, since that's what I use these > days. > > On Wed, Feb 20, 2019 at 9:47 PM Jon Trulson wrote: > > On 2/20/19 1:53 PM, Danilo Pecher wrote: > > > Hi everybody, > > > > > > I've been away for quite a while from CDE related work, so long > > in fact, > > > I don't even have the same name anymore. Back then I was going by > > the > > > name of Danilo Schöneberg, now I'm Danilo Pecher. The reason for > > that is > > > simple: I got married at the tender young age of 44. > > > > > > > Congratulations! :) > > > > > Now that I'm getting back to contributing, I've got a few things > > in mind > > > to work on in the near future, and would like some input from > > others: > > > > > > 1. One of the first things I'll be doing is streamlining the > > build > > > instruction pages. They've become cluttered a bit and I want to > > test if > > > some of them are still working. Especially NetBSD is a bit of a > > tricky > > > patient here. On 7.2 everything works and on 8.0 half the stuff > > is > > > broken. Some work to do there. For most systems I'll probably > > provide > > > automated build-scripts. > > > > > > > Quite possible - I've only been testing with FreeBSD 11 in addition > > to > > the Ubuntus. > > > > > 2. Although I've been rather inactive on the project itself, I've > > not > > > been completely idle. I'm about 75% done in creating a CDE-based > > Linux > > > distro based on LFS, complete with automated build. What do > > people > > > think? Would there be a "market" for that? > > > > > > > Linux From Scratch? Probably... I've heard several people wanting > > the > > CDEbian distro to be resurrected/maintained, so I assume there are > > those > > what would love a one-stop solution. > > > > > 3. Point 2 sort of exposes that we've got a massive problem in > > terms of > > > applications. Except for editors (both VIM and Emacs come with > > Motif > > > GUIs and integrate nicely) we've got close to no apps that really > > > integrate seamlessly. Well, we can probably agree that there'll > > never be > > > a dtwww web browser, unless someone wants to take leave of > > his/her > > > social life to write a motif based web engine, but I think we > > should be > > > able to modernize dtmail and ship in a slightly more versatile > > default > > > text editor (you may take that as me volunteering) > > > > > > > Yay :) I think dt
[cdesktopenv-devel] Back in the flock
Hi everybody, I've been away for quite a while from CDE related work, so long in fact, I don't even have the same name anymore. Back then I was going by the name of Danilo Schöneberg, now I'm Danilo Pecher. The reason for that is simple: I got married at the tender young age of 44. Now that I'm getting back to contributing, I've got a few things in mind to work on in the near future, and would like some input from others: 1. One of the first things I'll be doing is streamlining the build instruction pages. They've become cluttered a bit and I want to test if some of them are still working. Especially NetBSD is a bit of a tricky patient here. On 7.2 everything works and on 8.0 half the stuff is broken. Some work to do there. For most systems I'll probably provide automated build-scripts. 2. Although I've been rather inactive on the project itself, I've not been completely idle. I'm about 75% done in creating a CDE-based Linux distro based on LFS, complete with automated build. What do people think? Would there be a "market" for that? 3. Point 2 sort of exposes that we've got a massive problem in terms of applications. Except for editors (both VIM and Emacs come with Motif GUIs and integrate nicely) we've got close to no apps that really integrate seamlessly. Well, we can probably agree that there'll never be a dtwww web browser, unless someone wants to take leave of his/her social life to write a motif based web engine, but I think we should be able to modernize dtmail and ship in a slightly more versatile default text editor (you may take that as me volunteering) 4. I know work is going on for an autotools conversion. In that regard, I'd like to ask if we aren't going to end up being Betamax-man again. At least by the look of it, cmake/ninja/meson seem to be taking over in a growing number of projects. While we're at that, I'm going to set the cat among the pidgeons a bit. Would it not be a better idea to make a hard break with the current (chaotic and nigh-on impossible to comprehend) build system and switch to a clean-sheet rebuild for a 3.x release? Perhaps, if we do that, we might also get a chance of getting rid of the ksh-dependency for dtterm. That's been giving me rabies since 2016. ast-ksh seems to be all but unmaintained. and that's the only suitable candidate on a variety of platforms (BSD mainly, but also LFS, slackware and serveral other Linux variants on which it only builds on a sunny day with less than 3 knots of wind) Okay, so much for now, I'll start firing up my test boxes to see which systems we correctly build on. Ubuntu 14.04, 16.04 and 18.04 successfully checked out today. Cheers, Danilo aka Hippo. ___ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
