On Mon, Nov 5, 2012 at 4:18 AM, Marcin Cieslak wrote:
> On Sun, 4 Nov 2012, John Reed wrote:
>
>> Hello Jon,
>>
>> I did follow those steps and it will run but when I go into it via the
>> lightdm, it basically stays at the "Starting the Common Desktop
>> Environment" blue screen with the /usr/dt/
On Fri, Oct 19, 2012 at 5:26 AM, Antonis Tsolomitis
wrote:
> Στις 14/10/2012 12:30 μμ, ο/η miqlas έγραψε:
>> - Man Page Viewer : i don't use it, but looks handy, and like all of
>> the CDE apps, it also can't use the mouse scroll wheel.
>>
>> - Terminal : I like it, but it is useless -for me- with
That's weird. On my machine _UxUxParent is also NULL
but the program runs fine [no segfaults, I can even browse icons
and create new entries for my deskbar now].
On Sat, Sep 29, 2012 at 1:27 PM, Marcin Cieslak wrote:
> On Sat, 29 Sep 2012, Frederic Koehler wrote:
>
>> This is on
On Sat, Sep 29, 2012 at 3:40 AM, Marc Balmer wrote:
> Am 29.09.12 03:29, schrieb Jon Trulson:
>> On Fri, 28 Sep 2012, Marc Balmer wrote:
>>
>>> for patch 1: don't roll your own strfunctions, use strlcpy or so
>>
>> I'm inclined to apply this - strlcpy isn't available on all systems
>> (on linux,
Pretty self-explanatory. Progress marches on!
0001-dthelp-Avoid-undefined-behaviour-in-strcpy.patch
Description: Binary data
0002-dtcreate-Avoid-trying-to-reuse-closed-help-window.patch
Description: Binary data
--
Got v
On Mon, Aug 20, 2012 at 6:40 PM, wrote:
>> I think they should be put together with the "official" ones
>> in $top/imports/motif/include/Xm (they live in the
>> same source directory anyway).
>>
>> There are two possibilities:
>>
>> 1) We can link them:
>>
>> So instead of doing right now
>>
>>
The way I have debugged these cryptic tooltalk messages before is
by doing a bulk replace of "return TT_ERR_*" with something like
> fprintf(stderr, __FILE__ ":%d is going TT_ERR_BLANK!\n", __LINE__); return
> TT_ERR_BLANK;
(better would probably be: _tt_syslog(stderr, LOG_ERR, blahblahblah)
ins
No, see my other changes, I malloced execstr.
On Fri, Aug 17, 2012 at 5:09 AM, Marcin Cieslak wrote:
> On Thu, 16 Aug 2012, Frederic Koehler wrote:
>
>> Fix some more obvious bugs; unfortunately, they don't seem to be behind
>> dtcreate's current brokenness.
&g
This time, there is a broken implementation of basename within dtcreate.
0001-dtcreate-Replace-broken-GetBaseName-with-basename.patch
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will
Fix some more obvious bugs; unfortunately, they don't seem to be behind
dtcreate's current brokenness.
0001-dtcreate-Fix-another-buffer-overflow-issue.patch
Description: Binary data
0002-dtcreate-Fix-some-memory-management-issues.patch
Description: Binary data
--
It's impressive this code ever worked at all. Dtcreate is still not
really working yet.
0001-dtcreate-Fix-major-buffer-overflow.patch
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will
Quite confusing looking. A couple suggestions:
1. Try recompiling CDE without optimizations so you get a complete
backtrace and make sure
gdb isn't getting confused anywhere [which certainly happens].
(I use this sort of command, perhaps there is a better way to do this)
# make CDEBUGFLAGS='-O0
On Wed, Aug 15, 2012 at 1:25 PM, Jon Trulson wrote:
> In IRC yesterday, kpedersen mentioned he had made CDE run under Fedora
> 17. He said he had to install the tirpc (Transport Independant RPC)
> package, as fedora does not include the rpc facility in their glibc
> anymore.
I was a little puzzle
This fixes an issue where dticon hangs for a while on startup
and tt_default_session_set errors.
WARNING: if you live-update libtt.so.2.1 with this patch, it will
cause CDE to crash [especially if you run dticon].
So you should probably logout first.
0001-mp_session-Always-use-global-displayname.
Aug 2012 19:57:12 -0400
>> From: Frederic Koehler
>> Subject: Re: [cdesktopenv-devel] dtbuilder broken?
>> To: j...@radscan.com
>> Cc: CDE development
>> Message-ID:
>>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> I tried runn
I tried running dtbuilder: I didn't get any bad messages, and an
initial window showed up that looked fine,
but clicking on any of the menus caused the program to immediately segfault.
On Sun, Aug 12, 2012 at 7:48 PM, Jon Trulson wrote:
>
> Seems dtbuilder isn't working well - I get:
>
> Warning:
On Sun, Aug 12, 2012 at 4:47 PM, Jon Trulson wrote:
> On Sun, 12 Aug 2012, Frederic Koehler wrote:
>
>> As far as I can tell, tooltalk makes no effort to be binary compatible
>> between different platforms already; e.g. in the patch I recently
>> submitted,
>> that c
As far as I can tell, tooltalk makes no effort to be binary compatible
between different platforms already; e.g. in the patch I recently
submitted,
that code sends part of a message of size uid_t which is not the same
between different platforms. (although rpc itself should be platform
independent)
return without parens).
On Sun, Aug 12, 2012 at 3:52 PM, Jon Trulson wrote:
> On Sun, 12 Aug 2012, Frederic Koehler wrote:
>
>> This patch makes tooltalk useful, letting many features work: logout,
>> virtual desktop switching,
>> and calling the dtfile command while it is
This patch makes tooltalk useful, letting many features work: logout,
virtual desktop switching,
and calling the dtfile command while it is running (which before just
created a hung process).
Before all tooltalk messages failed during sending, giving
TT_ERR_INTERNAL results.
The original code that
The first patch (for tttrace) actually does fix a potential issue
[described in patch].
Still tooltalk does not really work on 64-bit; by using tttrace, you
can see that pretty much whenever
tt_message_send is used, TT_ERR_INTERNAL comes back.
0001-tttrace-Fix-bad-usage-of-va_arg-with-enums.patc
Oh no! I meant tmpnam.
On Thu, Aug 9, 2012 at 10:00 PM, Aaron W. Hsu wrote:
> Frederic Koehler writes:
>
>>Definitely nobody should use mkstemp anyway
>
> What alternative do you suggest instead of mkstemp? The file descriptor
> should be safe as returned by mkstemp(), t
This doesn't really seem to change anything behavior-side, but since
we really need
to kill all implicit function types, might as well start. (Implicit
definitions can be killer
when 64-bit pointers get mauled by passing through a 32-bit return
value. This might
lead to heisenbugs as well.)
Unfort
Hello,
Right now CDE is very buggy on x86_64. As you saw the git version
at least starts up, but it doesn't really "work" yet (I have the same
issues on my computer). I'm guessing your virtual machine instance is 32-bit?
As far as why the error occurs, I think the message comes from inside
the to
On Thu, Aug 9, 2012 at 1:22 PM, Douglas Mencken wrote:
>> sizeof of a string literal
>> should give the number of bytes in it [which is a really
>> weird special case of C, see
>> http://en.wikipedia.org/wiki/Sizeof#Using_sizeof_with_arrays]
>
> Watch it:
>
> char* test1 = (char*)malloc(1000);
> c
On Thu, Aug 9, 2012 at 5:45 AM, Pascal Stumpf wrote:
> On Thu, 09 Aug 2012 10:56:10 +0200, Pascal Stumpf wrote:
>> On Thu, 09 Aug 2012 07:40:43 +0200, Marc Balmer wrote:
>> > A few more sprintf() to snprintf() conversion.
>> >
>> > We need to find a proper way to replace strcpy() and strcat(), may
I think this is a very good idea. CDE isn't even that large anyway (my
/usr/dt is ~80MB).
On Thu, Aug 9, 2012 at 1:21 AM, Marc Balmer wrote:
> I suggest to build CDE with debug symbols on by defaul on Linux. Space
> is not a concern these days, but since we are probably going to a period
> of pa
Hm, I'd be surprised if this patch had any effect: sizeof of a string literal
should give the number of bytes in it [which is a really
weird special case of C, see
http://en.wikipedia.org/wiki/Sizeof#Using_sizeof_with_arrays]
Although, strlen is a lot more obviously correct [curiously,
adding the +
= "$XConsortium: WmWrkspace.c /main/7
1996/10/23 17:26:33 rs
#include "WmGlobal.h"
#include "WmHelp.h"
#include "WmResNames.h"
+#include "WmIPlace.h"
#include
#include "WmICCC.h"
#include
On Tue, 2012-08-07 at 13:28 -0600, Jon Trulson wrote
Definitely nobody should use mkstemp anyway, but it's worth noting why the
segfault happens, because it's tricky: the code calls basename but forgets
to include the right header file -- this being C, the compiler just assumes
its return type is int. However int is on x64 a 32 bit integer, so the
po
Hi, I was trying to figure out why CDE does not want to run on some
distros, including
the latest release of Fedora. These two patches are enough to get dtwm to
run.
The first is important, because it allows ToolTalk to work which dtwm is
reliant on (without the server starting
no tooltalk reliant
31 matches
Mail list logo
