I know next to nothing about rpm based packaging, perhaps you should submit a
pull request with your changes so we could see an official rpm in the centos is
repos and collaborate with one another. I am the main guy spearheading
development on the Debian package, but I would really like to see o
> On Jun 20, 2018, at 20:28, Jon Trulson wrote:
>
[...]
>> Would switching to autotools also solve the rpath problem?
>
> Possibly, as I understand libtool changed it's behavior WRT to rpath.
>
> In CDE for linux, rpath is added via ExtraLoadFlags in
> config/cf/lnxLib.rules. You could prob
I will state what my personal goals are for the project if it gives perspective:
Building a Debian package (1st priority!)
Cutting out cruft (OS support for OSs that have no chance of ever being
revived, and have no active maintainers, honestly if we could've found active
maintainers for the OSs
Marcin Cieslak writes:
> On Wed, 20 Jun 2018, Jon Trulson wrote:
>
>> On 06/20/2018 06:01 PM, Chase wrote:
>>
>> The next release will be 2.3, because things.
>>
>> Autotools will take a while, before it's functional. There are many steps to
>> building CDE, it will not be a trivial task to re
> As for dtudc*, why? Who needs it?
> If you really want it, there is no reason it could not just be
> maintained outside of CDE as a separate project -- just requiring a
> X11/Motif/CDE dev environment to build.
Is there some strong reason we need to kill it? I understand why there
might not be
On Wed, 20 Jun 2018, Jon Trulson wrote:
> On 06/20/2018 06:01 PM, Chase wrote:
>
> The next release will be 2.3, because things.
>
> Autotools will take a while, before it's functional. There are many steps to
> building CDE, it will not be a trivial task to replicate in autotools.
There are s
On 06/20/2018 06:01 PM, Chase wrote:
I say that if we are going to push out one last release before the transition,
make it 2.2.5, and then the autotools release can be 2.3. Can we also reenable
the font editor and try to debug it after 2.2.5? If it's only problem is
renamed x11 headers and co
I say that if we are going to push out one last release before the transition,
make it 2.2.5, and then the autotools release can be 2.3. Can we also reenable
the font editor and try to debug it after 2.2.5? If it's only problem is
renamed x11 headers and compiler warnings, that is a relatively e
On 06/20/2018 04:03 PM, Matthew R. Trower wrote:
Jon Trulson writes:
Imake is dead, and I see no point in trying to "take over" and improve
it. Autotools (as others have also mentioned in this thread) is the
way to go moving forward. We might be able to leverage some of the
work X11 did ther
I've just pushed a fix for libtt that should hopefully solve a long
standing problem with machines having a hostname that does not have an
IP address associated with it.
When TT runs across this, it just fails.
Now when this happens, a default of "localhost" will be used. I have
tested this o
Jon Trulson writes:
> Imake is dead, and I see no point in trying to "take over" and improve
> it. Autotools (as others have also mentioned in this thread) is the
> way to go moving forward. We might be able to leverage some of the
> work X11 did there as well.
Well, my expectation was that we
Jon Trulson writes:
> I used the first patch. The second one failed for fbsd/clang (static
> definition should only be in class definition, not function
> definition). Gcc didn't complain. At anyrate, applied to master.
Oh... Yeah, SunPro warned me about that being an anachronism. I didn't
wa
Applied to master, thanks!
-jon
On 06/19/2018 03:08 PM, Matthew R. Trower wrote:
This patch makes minor corrections and cleanup to sun.cf
As part of this is reverting some text (Solaris 5.x to Solaris 2.x),
some explanation of Solaris versioning is probably in order
Kernel OS
On 06/19/2018 02:56 PM, Matthew R. Trower wrote:
DtMail attempts to detect whether the non-standard strcasestr() is
available, and defines it if it is not. Unfortunately, the detection
code is imperfect. Fortunately, we can make it a class method to avoid
collision even if it does exist.
I off
On 06/19/2018 09:33 PM, Chase via cdesktopenv-devel wrote:
Hi all,
Matthew T. and I have had a conversation about imake and whether or not
it would be a good idea to merge with master or not. After doing a bit
of discussion, I sent a message to alan coopersmith to see if anyone at
the imake te
I think autotools is a good choice, imake iscranky.
On Wed, Jun 20, 2018 at 4:52 AM Matthew R. Trower
wrote:
> I don't think imake is so bad, but it does have its limitations. If the
> consensus is that we should move to autotools (the only reasonable
> alternative that I'm aware of), I wo
I don't think imake is so bad, but it does have its limitations. If the consensus is that we should move to autotools (the only reasonable alternative that I'm aware of), I would be willing to take a stab at the
Hi all.
IMHO GNU autotools is the right way. Xorg moved from old "imake-make
World" to GNU autotools and modular packing. Motif moved in a similar
way. I think the third traditional actor of the old robust desktop, CDE,
must follow the same way.
If I may help you in any way, please let me kn
18 matches
Mail list logo
