Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (46 - 48 of 431)

Ticket Resolution Summary Owner Reporter
#1082 duplicate IZ141: implement cvs update hooks for testsuite crei
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=141]

        Issue #:      141             Platform:     Sun           Reporter: crei (crei)
       Component:     testsuite          OS:        All
     Subcomponent:    framework       Version:      current          CC:    None defined
        Status:       RESOLVED        Priority:     P3
      Resolution:     DUPLICATE      Issue type:    ENHANCEMENT
                                  Target milestone: milestone 1
      Assigned to:    issues@testsuite
      QA Contact:     joga
          URL:
       * Summary:     implement cvs update hooks for testsuite
   Status whiteboard:
      Attachments:

     Issue 141 blocks:
   Votes for issue 141:     Vote for this issue


   Opened: Tue Aug 14 08:32:00 -0700 2007 
------------------------


The current cvs update feature of the testsuite only works for the
GE sources. It would be nice to have this feature also for additional
checktrees.

See also: http://hedeby.sunsource.net/issues/show_bug.cgi?id=82

   ------- Additional comments from crei Mon Mar 3 02:28:44 -0700 2008 -------
duplicate issue

*** This issue has been marked as a duplicate of 176 ***
#224 fixed IZ1443: code cleanup in builtin_starter.c:start_command() Dave Love <d.love@…> uddeborg
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=1443]

        Issue #:      1443             Platform:     All     Reporter: uddeborg (uddeborg)
       Component:     gridengine          OS:        All
     Subcomponent:    execution        Version:      6.0u3      CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    TASK
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     pollinger
          URL:
       * Summary:     code cleanup in builtin_starter.c:start_command()
   Status whiteboard:
      Attachments:
                      Date/filename:                     Description:                                                              Submitted by:
                      Fri Jan 28 07:36:00 -0700 2005: #  Patch to remove the pre_args_ptr completely. (text/plain)                 uddeborg
                      Fri Jan 28 07:38:00 -0700 2005: #2 Patch to use *pre_args_ptr++ as the technique to assign args (text/plain) uddeborg

     Issue 1443 blocks:
   Votes for issue 1443:


   Opened: Fri Jan 28 07:35:00 -0700 2005 
------------------------


While investigating a problem with submitting
commands (issue 1442) I was confused bu tye use of
a pointer pre_args_ptr in the function
start_command in
source/daemons/shepherd/builtin_starter.c.  It is
set to point to the first element of pre_args, but
is then used as an array.  This original array
pre_args could be used instead.  I get the
impression that somebody intended to assign
successive values with the "*ptr++" idiom, but
then changed his mind and used ordinary array
indexing instead, without removing the pointer
variable from the code.

It was a bit confusing when reading the code, so I
would suggest cleaning it up.  It could be changed
in one of two ways.  Either the pre_args_ptr could
be removed, and all indexing could be done from
the original array.  Or the *ptr++ technique could
be used.  I'll attach two possible patches, one
for each case.

   ------- Additional comments from uddeborg Fri Jan 28 07:36:44 -0700 2005 -------
Created an attachment (id=36)
Patch to remove the pre_args_ptr completely.

   ------- Additional comments from uddeborg Fri Jan 28 07:38:31 -0700 2005 -------
Created an attachment (id=37)
Patch to use *pre_args_ptr++ as the technique to assign args

   ------- Additional comments from uddeborg Fri Jan 28 07:40:33 -0700 2005 -------
Oh, please note that these patches also include the bug fix I suggest
in issue 1442.  Sorry for mixing the two things together.

   ------- Additional comments from sgrell Tue Dec 6 08:17:23 -0700 2005 -------
Changed the Subcomponent.

Stephan

   ------- Additional comments from pollinger Tue Mar 7 02:24:51 -0700 2006 -------
Changed "Issue type" to task
#227 wontfix IZ1476: Error from "settings.sh" when set -u is set coffman
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=1476]

        Issue #:      1476             Platform:     HP       Reporter: coffman (coffman)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.0         CC:    None defined
        Status:       NEW              Priority:     P4
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     dom
          URL:
       * Summary:     Error from "settings.sh" when set -u is set
   Status whiteboard:
      Attachments:

     Issue 1476 blocks:
   Votes for issue 1476:


   Opened: Wed Mar 2 12:47:00 -0700 2005 
------------------------


When a user has set -u set in their environment
with SHLIB_PATH not set and they run the
util/arch, an error

SHLIB_PATH: parameter not set

To prevent this error message on hpux, the
variable should be tested before referenced...

   ------- Additional comments from andy Thu Mar 3 05:11:17 -0700 2005 -------
Changing "summary", "OS" and "version" and "subcomponent". Problem
occurs in 5.3 and 6.0 as well.

This is not a HPUX only problem, nor a problem of SGE_ROOT/util/arch.

The problem occurs when in the user shell "-u" is set ("set -u") and
the "settings.sh" file is sourced, e.g. on Solaris the error messages
is similar:

$  $SGE_ROOT/util/arch
sol-sparc64
$  $SGE_ROOT/util/arch -lib
LD_LIBRARY_PATH
$  . $SGE_ROOT/default/common/settings.sh
LD_LIBRARY_PATH: parameter not set


The scripts are designed that the default behavior of the Bourne shell
(no errror when unset variables are used) is implicitely used. Since
the "settings.sh" file is sourced (and not called) there can be a
conflict with the current user settings.

The solution would be to check if the variable is set (like in
"settings.csh").

Adding a line "set +u" is not an option since it would affect the
current shell behavior due to the sourcing if "settings.sh"


Workaround: "set +u" before sourcing the settings.sh file.


Note: See TracQuery for help on using queries.