bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #23262] sudo -E gmake install tries to run plmerge for aggregate pr


From: Quentin Mathé
Subject: [bug #23262] sudo -E gmake install tries to run plmerge for aggregate project on FreeBSD
Date: Thu, 22 May 2008 20:28:21 +0000
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; fr-fr) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13

Follow-up Comment #3, bug #23262 (project gnustep):

> Do you have a reproducible test case ? 

I can reproduce the problem with one framework and three applications
(aggregate project with plugins) from the Etoile tree on FreeBSD. I don't know
if I can reproduce the issue on Linux though. Some subtle interaction with
sudo may be involved because sudo version on FreeBSD 7 comes with the flag -E.
My Ubuntu install comes with an older version where this flag isn't needed to
preserve the environment. However the latest Ubuntu release (Hardy Heron)
comes with an updated sudo versions that needs the -E flag. There is a mail
from Rubens_Septimus on
gnustep-discuss<http://lists.gnu.org/archive/html/discuss-gnustep/2008-05/msg00090.html>
where he detailed the same sort of error on that latest Ubuntu release. Not
sure it's the same though (could be caused by root owned files) but I thought
it was worth to mention.

Thanks for the explanation about make vs make && make install, I wasn't aware
of that and I would suggest to add a note in gnustep-make documentation.
Usually I always type 'make && sudo make install' since typing only 'sudo make
install' create root owned files in my working copy and force me to later type
'sudo make' for a simple compilation.

As you suggested in your first post, I ran gmake distclean in  the projects I
have trouble with (without warnings about files owned by root). Then I rebuilt
each project like that :
gmake
sudo -E gmake install

By doing that, I got the same issues I reported. 

So I put in attachment the logs for gmake and gmake install for a framework
and an application where sudo -E gmake install still fail:
- http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/IconKit
-
http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Services/Private/MenuServer/

Before running these commands, I built the whole Etoile tree by typing : 
- gmake in http://svn.gna.org/viewcvs/etoile/trunk/Etoile/ for satisfying the
dependencies of the two projects (the dependencies are exported in an
Etoile/Build directory created by etoile.make which is included by the main
GNUmakefile of each project in the source tree)
You can find etoile.make here:
http://svn.gna.org/viewcvs/etoile/trunk/Etoile/etoile.make

then I cleaned the projects for which I was going to collect the logs:
- gmake distclean in IconKit and MenuServer directory
My revision of Etoile tree is 3107, no changes have been done since then to
either IconKit, MenuServer or etoile.make.

What you describe in your last post reminds me that I have observed such
spurious rebuilds of some frameworks when typing: sudo make install. However I
don't have the issue presently on FreeBSD unlike on my Ubuntu install. In the
past, I have also observed that these issues (spurious rebuild, plmerge not
found) were also varying with the level in the source tree where you run make.
For example, running 'make' in etoile/Etoile/Frameworks would succeed when it
would fail if you run in the parent directory etoile/Etoile/. I haven't tested
for a while whether that still holds. It's quite possible this problem has
been solved by past year gnustep-make releases.

>> the following line fails by trying to run plmerge: 

>> sudo -E gmake messages=yes install 

>> when the following line succeeds (plmerge isn't run): 

>> sudo -E gmake install messages=yes 
>
>
 as far as I know the two commands are completely identical. 
>
> Did you try them in sequence ? Then maybe the first one 

> failed because it detected that a rebuilt was needed, 

> did the rebuilt and failed trying to run plmerge 

> (which is the last command), but managed to rebuild enough 

> that the second one thought things were built and it didn't 

> need to build again, so it didn't fail. 

Yes, I tried them in sequence. After trying to run them in a random manner, I
think your explanation is correct.

Thanks Nicola for your very detailed replies. Let me know if you need any
extra informations.


(file #15703, file #15704, file #15705, file #15706)
    _______________________________________________________

Additional Item Attachment:

File name: gmake-iconkit.log              Size:17 KB
File name: gmake-install-menuserver.log   Size:2 KB
File name: gmake-install-iconkit.log      Size:3 KB
File name: gmake-menuserver.log           Size:28 KB


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message posté via/par Savannah
  http://savannah.gnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]