Re: Problems with automatic start of gdnc, gpbs, and gdomap on Linux...

[Chris B. Vetter]

On 1/29/06, Riccardo <[EMAIL PROTECTED]> wrote:
> On Monday, January 23, 2006, at 03:52 AM, Gregory John Casamento wrote:
> > The subject basically says it. When I log in, it's reporting that it
> > had trouble starting gdnc. Is anyone else having this problem?
[...]
> On other platforms, most notably BSD based ones, there are heavy
> troubles starting things automatically. Since I have now a NetBSD/x86
> box I can exclude also "exotic" architectural problems. I confirm that
> on netbsd I need to start gdomap first, gdnc then. gpbs and others gets
> started fine. INterestingly, if gdnc is started automatically by an
> application it does start (as seen with ps -aux) but it doesn't seem to
> work and the application complains it can't contact gdnc.

On FreeBSD, I start gdomap when the system boots up. When I log in and
fire up X11 (currently no xdm or similar) I start gdnc and gpbs in
~/.xinitrc Though gdnc is complaining about not being able to contact
gdomap, everything is working fine.

OTOH, occasionally, I stop all GNUstep-related tools (usually when
updating GNUstep) and forget to re-launch'em again. But once I fire up
any GNUstep application (Gorm most notably) all required tools are
automatically started without any problems or messages (except those
that they ARE being started).

--
Chris


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Source code move to SVN

[Andy Ruder]

On 1/29/06, Andy Ruder <[EMAIL PROTECTED]> wrote:
> Adam and everybody else,
>
> Gregory and I have been working together to figure out a problem with
> the svn repos.  We have discovered that several hundred of the files
> in CVS have been added without the -kb flag (binary files).  We are
> working to correct this problem, and I think I have made a patch to
> cvs2svn that will mostly correct the conversion issues, but I fear a
> reimport may be needed.

I believe I have corrected this problem by allowing cvs2svn to accept
a list of files which it then can force binary mode.  My preliminary
tests have been positive, but I am going to do a full set of diffs on
every single project to verify that cvs2svn is doing what I hope it
is.  Between the corrupted RCS files, the incorrectly added binary
files, and the mailing lists dying, things have been a little rough
getting this transition made, but I think its nearly there. :)

- Andy

P.S. The patches to cvs2svn are growing rather long:

http://dump.aeruder.net/patches/cvs2svn-everything-gnustep.patch

Makes me very curious how many problems gcc ran into making the
initial transition. :)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Source code move to SVN

[Fred Kiefer]

Andy Ruder wrote:
> 
> Gregory and I have been working together to figure out a problem with
> the svn repos.  We have discovered that several hundred of the files
> in CVS have been added without the -kb flag (binary files).  We are
> working to correct this problem, and I think I have made a patch to
> cvs2svn that will mostly correct the conversion issues, but I fear a
> reimport may be needed.
> 

If you do a reimport, could you please make sure to preserve the changes
I already made inside of SVN? It would be a shame if my changes would be
the victim of the initial SVN problems. Please remember I was the one
that warned that some smaller problems are very likely to pop up in the
first two weeks and that we should not be using SVN without a test
phase. This was voted down, but now I seem to be the only one actually
using SVN :-)

BTW, will we have mails for SVN code changes again? It was a rather nice
feature just to see if an update was worthwhile or not.

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: remote hosting

[Tim McIntosh]

Hi Fred,

Sorry for the confusion.  The specific case that I want to work is as  
follows:  I have a machine running GNUstep (call it 'localhost').  I  
log into this machine from another non-GNUstep machine (call it  
'remotehost') using 'Xnest' (display ":1") to connect to the xdm on  
'localhost'.  Thus, DISPLAY is 'remotehost:1.0' and the GNUstep  
processes are running on 'localhost'.


This "sort of" works without the patch.  The initial processes that  
are launched _without_ the '-NSHost' argument will correctly display  
on 'remotehost:1.0', while printing the warning "NOTE: Only one  
display per host fully supported."  However, the 'NSHost' default  
will be (incorrectly) set to 'remotehost' by the code I've proposed  
deleting.  As I understand it, this default causes the programs to  
look for 'gdnc', 'gpbs', etc. on 'remotehost', instead of  
'localhost', where they are actually running.


The problem gets worse when one of those initial processes (e.g.  
GWorkspace) launches another GNUstep application via the NSWorkspace  
methods.  Since the parent process has the 'NSHost' default set, the  
new process will be launched with the '-NSHost' argument (see  
NSWorkspace.m).  When the -NSHost argument is specified, the code in  
the patched method (_initXContext) ignores the DISPLAY settings.   
Thus, the launched applications will use 'remotehost:0.0' for the  
display.  This leads to some surprising results when 'remotehost:0.0'  
is a valid display.


From looking at the code, I think you would also see a similar  
problem if you attempted to use display ":1" (or any nonzero display)  
on 'localhost', though I haven't tried this.


I think it makes sense for the '-NSHost' argument to override the  
DISPLAY setting, as it does today.  I think the problem is the  
assumption that the 'NSHost' default should be set according to  
DISPLAY if -NSHost was not explicitly specified.  As I see it, the '- 
NSHost' argument says that I want to connect to a remote GNUstep  
session.  If I don't specify -NSHost, I'm saying I want to run  
GNUstep on the local host and display according to the DISPLAY setting.


I realize that this is slightly less convenient in the case where you  
want to use a remote GNUstep session on 'remotehost:0.0' and would  
like to rely on the DISPLAY setting, but I'd rather have more control  
over the display.  Having to specify the -NSHost argument seems  
reasonable, especially considering that you had to do this under  
OPENSTEP and you'd have to do it anyway if you weren't using X11.


Tim


On Jan 30, 2006, at 4:30 AM, Fred Kiefer wrote:


Hi Tim,

I read through your mail and your patch, but still don't quite get the
issue you have. It is a know problem that GNUstep will complain about
multiple displays and it even may not work fully correctly in that  
case,

but what is causing you problems?

What value are you using for DISPLAY? ":0.3" or ":1.0" or
"localhost:1.0"? And in what way does it harm your application that
NSHost gets automatically set? What value does it get set to?
I would expect that having NSHost set to something like "localhost"
would result in the same behaviour as not having it set at all. If  
this

is not the case, we need to look into that.

I am not sure, if your solution, forcing people to set two environment
variable to matching values, is a great idea. It most likely will  
result

in additional problems.

Fred





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Subversion import #2

[Adam Fedor]

In progress. They say it takes a few hours...

On Jan 30, 2006, at 11:28 AM, Andy Ruder wrote:


I believe I am ready for the second try.  I have fixed up what was
remaining and have checked the trunk of every project for binary files
being the same.  The dumpfile is at

http://dump.aeruder.net/svn/gnustep.dump.gz

Sorry about the confusion everybody.  Fred, I manually committed your
last change.  Richard, it looks like the commit you made to svn fixing
the typo in NSApplication.m was picked up this time in the cvs2svn
conversion.

Adam, any chance you can pass this on to the proper authorities at 
gna.org?


- Andy




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Subversion import #2

[Adam Fedor]

OK, I'll let them know.

On Jan 30, 2006, at 11:28 AM, Andy Ruder wrote:


I believe I am ready for the second try.  I have fixed up what was
remaining and have checked the trunk of every project for binary files
being the same.  The dumpfile is at

http://dump.aeruder.net/svn/gnustep.dump.gz

Sorry about the confusion everybody.  Fred, I manually committed your
last change.  Richard, it looks like the commit you made to svn fixing
the typo in NSApplication.m was picked up this time in the cvs2svn
conversion.

Adam, any chance you can pass this on to the proper authorities at 
gna.org?


- Andy




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Source code move to SVN

[David Ayers]

Andy Ruder schrieb:
> 
>>BTW, will we have mails for SVN code changes again? It was a rather nice
>>feature just to see if an update was worthwhile or not.
> 
> 
> I'm pretty sure there is a way to sign up for svn notifications on
> gna.org.  I remember reading about it at one time.
> 

I signed up here:

https://gna.org/mail/?group=gnustep

(gnustep-cvs... yes cvs) and did receive commit mails (from
gnustep-commits with the title [Gnustep-cvs]).

Besides the slightly confusing naming, the only minor issue I have is
that the links provided currently don't show the property changes (from
Andy's and Greg's commits last night).  I'll search the GNA support
mailing lists at some point in time...

Example:

Author: aeruder
Date: Mon Jan 30 04:43:35 2006
New Revision: 22398

URL: http://svn.gna.org/viewcvs/gnustep?rev=22398&view=rev
Log:
Deleting text properties on binary files

Modified:
libs/db/trunk/doc/example-model.diagram2/Colors.clr   (props changed)
libs/db/trunk/doc/example-model.diagram2/Image162   (props changed)
libs/db/trunk/doc/example-model.diagram2/Image164   (props changed)
libs/db/trunk/doc/example-model.diagram2/Image166   (props changed)
libs/db/trunk/doc/example-model.diagram2/Image168   (props changed)
libs/db/trunk/doc/example-model.diagram2/Image181   (props changed)
libs/db/trunk/doc/example-model.diagram2/Image183   (props changed)
libs/db/trunk/doc/example-model.diagram2/PrintInfo   (props changed)
libs/db/trunk/doc/key.tiff   (props changed)
libs/db/trunk/doc/layers.diagram2/Colors.clr   (props changed)
libs/db/trunk/doc/layers.diagram2/PrintInfo   (props changed)
libs/db/trunk/doc/model.diagram2/Colors.clr   (props changed)
libs/db/trunk/doc/model.diagram2/PrintInfo   (props changed)


Cheers,
David





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Source code move to SVN

[Andy Ruder]

> If you do a reimport, could you please make sure to preserve the changes
> I already made inside of SVN? It would be a shame if my changes would be
> the victim of the initial SVN problems. Please remember I was the one
> that warned that some smaller problems are very likely to pop up in the
> first two weeks and that we should not be using SVN without a test
> phase. This was voted down, but now I seem to be the only one actually
> using SVN :-)

True, you did warn of this.  And yes, I have noticed that there are
two patches sent to the new svn repository and a few that were made
after the cvs2svn conversion so I will consolidate everything and make
sure that shows up in the import.

I am (I believe) running the final cvs2svn conversion.  I wrote a
program to diff the differences in trunks between all the subprojects
(CVS vs. svn) and went through the 40,000 diff to see some valid
newline changes (people committing windows-style newlines) and many
were just keyword changes ($Revision$ etc..)  However, there were
still a few "Binary files differ" but I think I have added the changes
for all of these now.  (Ended up being around ~1500 lines of binary
file exceptions, eek).

> BTW, will we have mails for SVN code changes again? It was a rather nice
> feature just to see if an update was worthwhile or not.

I'm pretty sure there is a way to sign up for svn notifications on
gna.org.  I remember reading about it at one time.

- Andy


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Subversion import #2

[David Wetzel]

Hi,

Andy Ruder wrote:

> Also, as the /devmodules is rather wieldy to checkout, I was
> also
> going to suggest that we setup a part of the directory tree
> with:
> 
> /developer//
> 
> where people can play around with subversion and
> such.  

The problem with that sandboxes is that it pushes the revision number up each 
time and people may 
think the 'real' repository has changed.

SVN can do a flat file repository too IIRC. So people could use it on their 
local disks...


-- 
   _  _
 _(_)(_)_  David Wetzel, Turbocat's Development,
(_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG,
  _/  \_   Fax +49 33056 82835 Phone +49 33056 82834
 (__)  http://www.turbocat.de/



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Subversion import #2

[Andy Ruder]

On 1/30/06, David Wetzel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Andy Ruder wrote:
>
> > Also, as the /devmodules is rather wieldy to checkout, I was
> > also
> > going to suggest that we setup a part of the directory tree
> > with:
> >
> > /developer//
> >
> > where people can play around with subversion and
> > such.
>
> The problem with that sandboxes is that it pushes the revision number up each 
> time and people may
> think the 'real' repository has changed.

With all the projects in the repository, people will have to get used
to revision numbers changing.  Subversion handles it nicely by
checking lastchanged revisions on any files it updates...

Subversion doesn't have a flat file repository (it does, but it is
still in a database of sorts, not human readable), and for
experimenting with merging and such, that will HAVE to be done in a
place in the repository...

- Andy


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Source code move to SVN

[Andy Ruder]

On 1/30/06, David Ayers <[EMAIL PROTECTED]> wrote:
> Besides the slightly confusing naming, the only minor issue I have is
> that the links provided currently don't show the property changes (from
> Andy's and Greg's commits last night).  I'll search the GNA support
> mailing lists at some point in time...

This is a major complaint I've always had about all existing web
interfaces.  None of them currently display the properties (AFAIK). 
As important as the properties are, it seems strange to me that none
of them show that.

- Andy


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: remote hosting

[Fred Kiefer]

Hi Tim,

thank you for this long explaination. You did convince me, I am now all
in favour for your patch. Your patch seems to make scenarios possible,
that didn't work before. But this is not my area of expertice, perhaps
Adam and Richard have something to say here?

Fred


Tim McIntosh wrote:
> 
> Sorry for the confusion.  The specific case that I want to work is as 
> follows:  I have a machine running GNUstep (call it 'localhost').  I 
> log into this machine from another non-GNUstep machine (call it 
> 'remotehost') using 'Xnest' (display ":1") to connect to the xdm on 
> 'localhost'.  Thus, DISPLAY is 'remotehost:1.0' and the GNUstep 
> processes are running on 'localhost'.
> 
> This "sort of" works without the patch.  The initial processes that  are
> launched _without_ the '-NSHost' argument will correctly display  on
> 'remotehost:1.0', while printing the warning "NOTE: Only one  display
> per host fully supported."  However, the 'NSHost' default  will be
> (incorrectly) set to 'remotehost' by the code I've proposed  deleting. 
> As I understand it, this default causes the programs to  look for
> 'gdnc', 'gpbs', etc. on 'remotehost', instead of  'localhost', where
> they are actually running.
> 
> The problem gets worse when one of those initial processes (e.g. 
> GWorkspace) launches another GNUstep application via the NSWorkspace 
> methods.  Since the parent process has the 'NSHost' default set, the 
> new process will be launched with the '-NSHost' argument (see 
> NSWorkspace.m).  When the -NSHost argument is specified, the code in 
> the patched method (_initXContext) ignores the DISPLAY settings.   Thus,
> the launched applications will use 'remotehost:0.0' for the  display. 
> This leads to some surprising results when 'remotehost:0.0'  is a valid
> display.
> 
> From looking at the code, I think you would also see a similar  problem
> if you attempted to use display ":1" (or any nonzero display)  on
> 'localhost', though I haven't tried this.
> 
> I think it makes sense for the '-NSHost' argument to override the 
> DISPLAY setting, as it does today.  I think the problem is the 
> assumption that the 'NSHost' default should be set according to  DISPLAY
> if -NSHost was not explicitly specified.  As I see it, the '- NSHost'
> argument says that I want to connect to a remote GNUstep  session.  If I
> don't specify -NSHost, I'm saying I want to run  GNUstep on the local
> host and display according to the DISPLAY setting.
> 
> I realize that this is slightly less convenient in the case where you 
> want to use a remote GNUstep session on 'remotehost:0.0' and would  like
> to rely on the DISPLAY setting, but I'd rather have more control  over
> the display.  Having to specify the -NSHost argument seems  reasonable,
> especially considering that you had to do this under  OPENSTEP and you'd
> have to do it anyway if you weren't using X11.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Subversion import #2

[Andy Ruder]

I believe I am ready for the second try.  I have fixed up what was
remaining and have checked the trunk of every project for binary files
being the same.  The dumpfile is at

http://dump.aeruder.net/svn/gnustep.dump.gz

Sorry about the confusion everybody.  Fred, I manually committed your
last change.  Richard, it looks like the commit you made to svn fixing
the typo in NSApplication.m was picked up this time in the cvs2svn
conversion.

Adam, any chance you can pass this on to the proper authorities at gna.org?

- Andy


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: remote hosting

[Fred Kiefer]

Hi Tim,

I read through your mail and your patch, but still don't quite get the
issue you have. It is a know problem that GNUstep will complain about
multiple displays and it even may not work fully correctly in that case,
but what is causing you problems?

What value are you using for DISPLAY? ":0.3" or ":1.0" or
"localhost:1.0"? And in what way does it harm your application that
NSHost gets automatically set? What value does it get set to?
I would expect that having NSHost set to something like "localhost"
would result in the same behaviour as not having it set at all. If this
is not the case, we need to look into that.

I am not sure, if your solution, forcing people to set two environment
variable to matching values, is a great idea. It most likely will result
in additional problems.

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Subversion import #2

[Quentin Mathé]

Le 30 janv. 06 à 22:13, Andy Ruder a écrit :


On 1/30/06, Adam Fedor <[EMAIL PROTECTED]> wrote:

In progress. They say it takes a few hours...


Ok, everybody, the conversion is complete.  I have started some docs
for us on SVN:

http://mediawiki.gnustep.org/index.php/Using_Subversion


Hi Andy,

thanks to have dealt with this cvs to svn migration.

I have started to write a tutorial/summary on how to work with SVN,  
it is available on Étoilé web site, it is still a bit rough and  
should probably be broken in several sections too. Feel free to reuse  
it if you want to add more documentation on GNUstep wiki.
Here is the link 



Also, as the /devmodules is rather wieldy to checkout, I was also
going to suggest that we setup a part of the directory tree with:

/developer//

where people can play around with subversion and such.


Good idea.


I personally
would use it for setting up an svn:externals to checkout just a few of
the projects (like /libs/{back,base,gui}/trunk /tools/make/trunk and
/apps/gorm/trunk).  What do you think?


Why not. But I'm not sure to understand, is it still possible to  
checkout only 'core' (make, base, gui, back) in one pass ? With  
devmodules/core right ?


Thanks,
Quentin.

--
Quentin Mathé
[EMAIL PROTECTED]



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Subversion import #2

[Andy Ruder]

On 1/30/06, Adam Fedor <[EMAIL PROTECTED]> wrote:
> In progress. They say it takes a few hours...

Ok, everybody, the conversion is complete.  I have started some docs
for us on SVN:

http://mediawiki.gnustep.org/index.php/Using_Subversion

The SVN ssh setup stuff may be informative.  When I get home this
evening I will fire up windows and see if I have any luck getting it
setup in windows.

People will probably need to recheckout:

svn co svn+ssh://svn.gna.org/svn/gnustep/devmodules

If there are any questions/problems, just send things to the list,
I'll be checking back frequently.

Also, as the /devmodules is rather wieldy to checkout, I was also
going to suggest that we setup a part of the directory tree with:

/developer//

where people can play around with subversion and such.  I personally
would use it for setting up an svn:externals to checkout just a few of
the projects (like /libs/{back,base,gui}/trunk /tools/make/trunk and
/apps/gorm/trunk).  What do you think?

- Andy


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev