headers
Richard Frith-Macdonald | 2 Oct 2009 21:16
Picon

[bug #26437] Base should allow the usual "make && sudo make install"


Update of bug #26437 (project gnustep):

                  Status:                    None => Invalid                
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #4:

I guess this ought to be closed ... it's really very clear that base DOES
allow the usual "make && sudo make install", and the problem here is simply
that gnustep-make has not been installed for general use.

gnustep-base (and all other gnustep libraries and applications) depend on
gnustep-make being installed, and in this respect are no different from any
other software package ... if something the package depends on is not
installed, the package won't build.

Also like most other packages, if the dependency is installed but in the
wrong place so it can't be found, we have a mechanism (setting the environment
variable) to tell it where the thing is.

I note the phrase 'Ubuntu comes with a gnustep-make package'

This presumably means that the gnustep-make supplied with ubuntu does not
install itsself properly (or perhaps is a really old version) so that
gnustep-config is not found in the standard PATH.  Perhaps a note to the
maintainers of the package would be effective in getting that fixed?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Nicola Pero | 3 Oct 2009 12:53
Picon

[bug #26437] Base should allow the usual "make && sudo make install"


Follow-up Comment #5, bug #26437 (project gnustep):

Yes, this is not a gnustep-base problem.

In fact, it's not even a GNUstep problem :-).  You'll have the same problem
with any other software that is installed into a custom, non-native location. 
Eg, if you install some package into /opt/package, you then obviously have to
add /opt/package/bin (or whatever it is) to your PATH before you can use it
properly.  And if you're using 'sudo' to do stuff (an almost identical example
is Python's "sudo setup.py install" if you have your own custom Python
installation), then you need to make sure /opt/package/bin is in root's PATH
as well ;-)

I can see two solutions:

 * install gnustep-make "properly" so that root can use it (either by
installing it using a native filesystem so that gnustep-config automatically
ends up in the PATH, or if it's installed in a non-native setup, by adding the
gnustep paths to the PATH and LD_LIBRARY_PATH in /etc/profile or similar)

 * use 'sudo -E make install' so that root will inherit the 'temporary'
environment from your current user.

I agree with Richard that the best thing we can do is to improve the
documentation.  The error message printed by gnustep-base when gnustep-make
can't be found is a good place to put any helpful explanation as that is most
likely where users would stumble upon this problem. :-)

I agree with closing the bug as I am not sure what more we could do. ;-)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richard Frith-Macdonald | 3 Oct 2009 17:38
Picon

[bug #27128] rootProxy cannot be called twice on an NSConnection


Update of bug #27128 (project gnustep):

                  Status:               Need Info => Fixed                  
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #3:

> So should the rootProxy docs say ... "The returned proxy is not retained by
the
> receiver. If it is deallocated the connection that supplied it is
invalidated"? 

No, I think, while the proxy may be autoreleased and deallocated, as long as
the connection itsself is retained, it should be possible to call -rootproxy
on it again and get a new proxy object.

I've modified the NSConnection code so that if the proxy on one end of the
connection is deallocated, the object at the other end does not get
deallocated if it happens to be the root object.  This should solve the
problem.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27128>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Frith-Macdonald | 3 Oct 2009 17:44
Picon

[bug #26437] Base should allow the usual "make && sudo make install"


Follow-up Comment #6, bug #26437 (project gnustep):

I suppose we could prompt the ubuntu package manager for gnustep-make to
submit a new filesystem layout file defining where gnustep-config should be
put to be in the PATH.  I think the main point of the --with-layout= configure
option was to allow packagers to specify where they want things put, and it
probably makes sense for them to submit their layouts to be part of the
official gnustep-make package rather than keeping them to themselves.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?26437>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 3 comments |
headers
Richard Frith-Macdonald | 3 Oct 2009 18:54
Picon

[bug #27528] app launching on Windows broken


Update of bug #27528 (project gnustep):

                  Status:                    None => Fixed                  
             Open/Closed:                    Open => In Test                

    _______________________________________________________

Follow-up Comment #5:

I think this is working ... seems to work for me anyway.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27528>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 1 comment |
headers
Richard Frith-Macdonald | 3 Oct 2009 20:40
Picon

[bug #27233] GSFFIInvocations share _retval ivar while in -forwardInvocation:


Update of bug #27233 (project gnustep):

                  Status:                    None => Fixed                  
             Open/Closed:                    Open => In Test                

    _______________________________________________________

Follow-up Comment #3:

Sorry for taking so long to get round to this.  I took a look at the issue
and agree with the original analysis (more or less).  The code was trying to
be too clever and store the result (of an invocation created to forward a
message) directly to the callers memory ... which is obviously a problem if
the receiver saves the invocation to use itsself later.

I believe I have fixed this in svn trunk.  it passes the simple testcase for

me, and our regression tests for nsinvocation continue to work, but it would
be good if you could check this too and confirm that it's fixed.

Thanks very much for this bug report ... the bug is obscure and I imagine
could have resulted in some problems which would be very hard to track down.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27233>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Nicola Pero | 3 Oct 2009 23:25
Picon

[bug #26437] Base should allow the usual "make && sudo make install"


Follow-up Comment #7, bug #26437 (project gnustep):

> I suppose we could prompt the ubuntu package manager for 
> gnustep-make to submit a new filesystem layout file defining 
> where gnustep-config should be put to be in the PATH.

I actually think they should either use the FHS layout, so that
gnustep-config is in /usr/bin, or, if they use the GNUstep layout, they should
add /usr/GNUstep/System/Tools and /usr/GNUstep/Local/Tools to the PATH.

Having just gnustep-config in the PATH is pretty useless ... I mean when
users install Gorm, how are they going to run it if the Gorm executable is not
in the PATH ?

It's obvious that the location of GNUstep executables should be in the PATH
for any working installation.  That includes gnustep-config, but more
importantly includes all the GNUstep tools and applications that users are
likely to install and use.

I personally don't see much point in having gnustep-config in the PATH but
not having other GNUstep tools/applications in the PATH.

So, they really need to fix how they install and setup GNUstep so that
GNUstep tools/apps are in the PATH and users can use them :-)

Thanks

    _______________________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Markus Hitter | 4 Oct 2009 00:20
Picon

Re: [bug #26437] Base should allow the usual "make && sudo make install"

> Having just gnustep-config in the PATH is pretty useless ... I mean  
> when
> users install Gorm, how are they going to run it if the Gorm  
> executable is not
> in the PATH ?

Well, either by typing "Gorm" in a terminal or by selecting Gorm from  
the application menu.

For the former, there's a link installed by the package:

$ ls -l /usr/bin/Gorm
lrwxrwxrwx 1 mah mah 41 2009-10-04 00:01 /usr/bin/Gorm -> ../lib/ 
GNUstep/Applications/Gorm.app/Gorm

The latter, however, is the preferred method. Application menu  
entries execute a one-line shell script, IIRC.
Permalink | Reply | 1 comment |
headers
Richard Frith-Macdonald | 4 Oct 2009 00:51
Picon

Re: [bug #26437] Base should allow the usual "make && sudo make install"


On 3 Oct 2009, at 23:20, Markus Hitter wrote:

>> Having just gnustep-config in the PATH is pretty useless ... I mean  
>> when
>> users install Gorm, how are they going to run it if the Gorm  
>> executable is not
>> in the PATH ?
>
> Well, either by typing "Gorm" in a terminal

That only works if Gorm is in the PATH of course.

> or by selecting Gorm from the application menu.
>
> For the former, there's a link installed by the package:
>
> $ ls -l /usr/bin/Gorm
> lrwxrwxrwx 1 mah mah 41 2009-10-04 00:01 /usr/bin/Gorm -> ../lib/ 
> GNUstep/Applications/Gorm.app/Gorm
>
> The latter, however, is the preferred method. Application menu  
> entries execute a one-line shell script, IIRC.

All of this is rather nit-picking evasion of the point though (who  
cares whether the executable is in the path directly, or via a link,  
or via a script) ...

The point is that a problem caused by a faulty installation of gnustep  
make is an issue which should be cured by installing gnustep-make
(Continue reading)

Permalink | Reply | 0 comments |
headers
Riccardo mottola | 5 Oct 2009 11:02
Picon

[bug #27528] app launching on Windows broken


Update of bug #27528 (project gnustep):

             Open/Closed:                 In Test => Closed                 

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?27528>

_______________________________________________
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/
Permalink | Reply | 0 comments |

Gmane