Re: Testing Newlib patches

2020-04-22 Thread Eshan Dhawan 
On Wed, Apr 22, 2020 at 5:09 AM Gedare Bloom  wrote:

> On Tue, Apr 21, 2020 at 3:48 PM Eshan Dhawan 
> wrote:
> >
> > Found it :)
> >
>
> Share it for posterity.
>
The blog written by @Vaibhav Gupta 
apply-newlib-patch-to-rtems-source-builder


>
> > Thanks
> >
> >
> > > On 22-Apr-2020, at 2:43 AM, Gedare Bloom  wrote:
> > >
> > > I think Aditya wrote something about this before? Maybe Vaibhav?
> > >
> > >> On Tue, Apr 21, 2020 at 2:27 PM Eshan Dhawan 
> wrote:
> > >>
> > >> hello everyone,
> > >> After making changes in Newlib.
> > >> How can I test /build Newlib patches against rtems?
> > >>
> > >> thanks
> > >> -Eshan
> > >> ___
> > >> devel mailing list
> > >> devel@rtems.org
> > >> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Small doubt in a build time warning of sp test of leon3

2020-04-22 Thread Richi Dubey 
Dear Dr. Joel,

Thank you for your reply. I did a grep on the root rtems folder and I came
to know that ISR_LOCK_INITIALIZER is being used by intr.h and isrlock.h
inside leon3's include directory.  It includes various macros like :

#if defined( RTEMS_SMP )
  #define ISR_LOCK_INITIALIZER( _name ) \

and

#define RTEMS_INTERRUPT_LOCK_INITIALIZER( _name ) ISR_LOCK_INITIALIZER(
_name )

I couldn't find the implementation of the function  ISR_LOCK_INITIALIZER( )
anywhere. Is there a isrlock.c present somewhere? I couldn't find any
helpful references for RTEMS_INTERRUPT_LOCK_INITIALIZER too. Am i missing
something?

Please let me know.

Thanks,
Richi.



On Sun, Apr 19, 2020 at 10:52 PM Joel Sherrill  wrote:

>
>
> On Sun, Apr 19, 2020, 9:59 AM Richi Dubey  wrote:
>
>> Hey everyone,
>>
>> In the Covid Code-in update by Dr. Joel, he mentioned that the RTEMS
>> could use some help to remove warnings from the code. In the link(
>> https://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-5-20200408/warnings-all-5-20200408.txt)
>> of warnings for RTEMS 5, one of the warning is:
>>
>> log/sparc-leon3.log:../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c:172:21:
>> warning: unused variable 'name' [-Wunused-variable]
>> log/sparc-leon3.log:../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c:172:21:
>> warning: 'name' defined but not used [-Wunused-const-variable=]
>>
>>
>> On opening init.c from ~/quick-start/src/rtems/testsuites/sptests/sp37/.
>> Lines 172 to 175 are:
>>
>>  static const char name[] = "test";
>>   ISR_Level normal_interrupt_level = _ISR_Get_level();
>>   ISR_lock_Control initialized = ISR_LOCK_INITIALIZER( name );
>>   ISR_lock_Control zero_initialized;
>>
>> We can see that the name variable is being used in line 174(and later on
>> 3 more times, outside any conditional blocks). Why would Dr. Joel get such
>> a warning then?
>>
>
> Does ISR_LOCK_INITIALIZER actually use the name? It possibly only uses it
> when RTEMS_DEBUG is enabled. Check that.
>
>>
>> Thanks,
>> Richi.
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Small doubt in a build time warning of sp test of leon3

2020-04-22 Thread Joel Sherrill 
On Wed, Apr 22, 2020 at 8:06 AM Richi Dubey  wrote:

> Dear Dr. Joel,
>
> Thank you for your reply. I did a grep on the root rtems folder and I came
> to know that ISR_LOCK_INITIALIZER is being used by intr.h and isrlock.h
> inside leon3's include directory.  It includes various macros like :
>
> #if defined( RTEMS_SMP )
>   #define ISR_LOCK_INITIALIZER( _name ) \
>
> and
>
> #define RTEMS_INTERRUPT_LOCK_INITIALIZER( _name ) ISR_LOCK_INITIALIZER(
> _name )
>
> I couldn't find the implementation of the function  ISR_LOCK_INITIALIZER(
> ) anywhere. Is there a isrlock.c present somewhere? I couldn't find any
> helpful references for RTEMS_INTERRUPT_LOCK_INITIALIZER too. Am i missing
> something?
>

If you are building without SMP enabled, then this should fix it. The
parameter _name is clearly not used unless you have SMP enabled. the code I
added is an accepted idiom for telling the compiler a variable or parameter
is used for its analysis purposes. Does this make sense?

diff --git a/cpukit/include/rtems/score/isrlock.h
b/cpukit/include/rtems/score/i
index 14ea88b..52645a3 100644
--- a/cpukit/include/rtems/score/isrlock.h
+++ b/cpukit/include/rtems/score/isrlock.h
@@ -147,7 +147,7 @@ typedef struct {
 { SMP_LOCK_INITIALIZER( _name ) }
 #else
   #define ISR_LOCK_INITIALIZER( _name ) \
-{ }
+{ (void) (_name); }
 #endif

 /**


>
> Please let me know.
>
> Thanks,
> Richi.
>
>
>
> On Sun, Apr 19, 2020 at 10:52 PM Joel Sherrill  wrote:
>
>>
>>
>> On Sun, Apr 19, 2020, 9:59 AM Richi Dubey  wrote:
>>
>>> Hey everyone,
>>>
>>> In the Covid Code-in update by Dr. Joel, he mentioned that the RTEMS
>>> could use some help to remove warnings from the code. In the link(
>>> https://ftp.rtems.org/pub/rtems/people/joel/warnings/warnings-5-20200408/warnings-all-5-20200408.txt)
>>> of warnings for RTEMS 5, one of the warning is:
>>>
>>> log/sparc-leon3.log:../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c:172:21:
>>> warning: unused variable 'name' [-Wunused-variable]
>>> log/sparc-leon3.log:../../../../../../rtems/c/src/../../testsuites/sptests/sp37/init.c:172:21:
>>> warning: 'name' defined but not used [-Wunused-const-variable=]
>>>
>>>
>>> On opening init.c from ~/quick-start/src/rtems/testsuites/sptests/sp37/.
>>> Lines 172 to 175 are:
>>>
>>>  static const char name[] = "test";
>>>   ISR_Level normal_interrupt_level = _ISR_Get_level();
>>>   ISR_lock_Control initialized = ISR_LOCK_INITIALIZER( name );
>>>   ISR_lock_Control zero_initialized;
>>>
>>> We can see that the name variable is being used in line 174(and later on
>>> 3 more times, outside any conditional blocks). Why would Dr. Joel get such
>>> a warning then?
>>>
>>
>> Does ISR_LOCK_INITIALIZER actually use the name? It possibly only uses
>> it when RTEMS_DEBUG is enabled. Check that.
>>
>>>
>>> Thanks,
>>> Richi.
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] Test for clock_nanosleep() with CLOCK_MONOTONIC option.

2020-04-22 Thread Utkarsh Rai 
Rationale for a new test-

>Although most of the test cases for this test have been taken from 
>clockrealtime,
adding it to the current test with CLOCK_MONOTONIC may break the existing cases.

>This test has a new case which tests for no change of delay with monotonic 
>clock when
the realtime clock has been modified, this is easier to add in a new test.
---
 testsuites/psxtests/Makefile.am   |  10 ++
 testsuites/psxtests/configure.ac  |   1 +
 .../psxtests/psxclocknanosleep01/init.c   | 155 ++
 .../psxclocknanosleep01.doc   |  15 ++
 .../psxclocknanosleep01.scn   |  14 ++
 5 files changed, 195 insertions(+)
 create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
 create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 1f9e4233ec..ba79804be7 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -312,6 +312,16 @@ psxclock01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxclock01) \
$(support_includes) -I$(top_srcdir)/include
 endif
 
+
+if TEST_psxclocknanosleep01
+psx_tests += psxclocknanosleep01
+psx_screens += psxclocknanosleep01/psxclocknanosleep01.scn
+psx_docs += psxclocknanosleep01/psxclocknanosleep01.doc
+psxclocknanosleep01_SOURCES = psxclocknanosleep01/init.c
+psxclocknanosleep01_CPPFLAGS = $(AM_CPPFLAGS) \
+   $(TEST_FLAGS_psxclocknanosleep01) $(support_includes)
+endif
+
 if TEST_psxclockrealtime01
 psx_tests += psxclockrealtime01
 psx_screens += psxclockrealtime01/psxclockrealtime01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 139787cccb..9bfe8e2c0b 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -75,6 +75,7 @@ RTEMS_TEST_CHECK([psxcleanup01])
 RTEMS_TEST_CHECK([psxcleanup02])
 RTEMS_TEST_CHECK([psxclock])
 RTEMS_TEST_CHECK([psxclock01])
+RTEMS_TEST_CHECK([psxclocknanosleep01])
 RTEMS_TEST_CHECK([psxclockrealtime01])
 RTEMS_TEST_CHECK([psxconcurrency01])
 RTEMS_TEST_CHECK([psxcond01])
diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c 
b/testsuites/psxtests/psxclocknanosleep01/init.c
new file mode 100644
index 00..c1f10b9eb9
--- /dev/null
+++ b/testsuites/psxtests/psxclocknanosleep01/init.c
@@ -0,0 +1,155 @@
+/*
+ *  Copyright (c) 2020 Utkarsh Rai.
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef enum {
+  MODE_TIMEOUT_FINITE,
+  MODE_TIMEOUT_NEGATIVE_SEC,
+  MODE_TIMEOUT_NEGATIVE_NSEC,
+  MODE_TIMEOUT_NEGATIVE_SEC_NSEC,
+  MODE_TIMEOUT_HUGE_NSEC,
+  MODE_TIMEOUT_CLOCK_MODIFY
+} test_mode;
+
+static void assert_eno(const char *hint, int eno, int expected_eno)
+{
+  const char *warn = "";
+
+  if ( eno != expected_eno ) {
+warn = "WARNING: ";
+  }
+
+  printf(
+"%s%s: actual '%s', expected '%s'\n",
+warn,
+hint,
+strerror(eno),
+strerror(expected_eno)
+  );
+
+  rtems_test_assert( eno == expected_eno );
+}
+
+
+static void assert_rv(const char *hint, int rv, int expected_eno)
+{
+  int eno;
+
+  if ( rv != 0 ) {
+eno = EINVAL;
+  } else {
+eno = 0;
+  }
+
+  assert_eno( hint, eno, expected_eno );
+}
+
+static void run(test_mode mode, const char* test_name)
+{
+ struct timespec  delay_time;
+ struct timespec  configure_time;
+ int rv;
+ int expected_eno;
+
+ printf("***%s*\n", test_name);
+
+ switch (mode) {
+   case MODE_TIMEOUT_FINITE:
+ rv = clock_gettime( CLOCK_MONOTONIC, &delay_time );
+ rtems_test_assert( rv == 0 );
+
+ delay_time.tv_sec += 1;
+ delay_time.tv_nsec += 1;
+ expected_eno = ETIMEDOUT;
+ break;
+
+   case MODE_TIMEOUT_HUGE_NSEC:
+ delay_time.tv_sec = 1;
+ delay_time.tv_nsec = LONG_MAX;
+ expected_eno = EINVAL;
+ break;
+
+   case MODE_TIMEOUT_NEGATIVE_NSEC:
+ delay_time.tv_sec = 1;
+ delay_time.tv_nsec = -1;
+ expected_eno = EINVAL;
+ break;
+
+   case MODE_TIMEOUT_NEGATIVE_SEC_NSEC:
+ delay_time.tv_sec = -1;
+ delay_time.tv_nsec = -1;
+ expected_eno = EINVAL;
+ break;
+
+   case MODE_TIMEOUT_NEGATIVE_SEC:
+ delay_time.tv_sec = -1;
+ delay_time.tv_nsec = 1;
+ expected_eno = ETIMEDOUT;
+ break;
+
+   case MODE_TIMEOUT_CLOCK_MODIFY:
+ rv = clock_gettime( CLOCK_REALTIME, &configure_time );
+ rtems_test_assert( rv == 0 );
+
+ configure_time.tv_sec += 3600;
+ rv = clock_settime( CLOCK_REALTIME, &configure_time );
+ rtems_test_assert( rv == 0 );
+
+ rv = clock_gettime( CLOCK_MONOTONIC, &delay_time );
+ rtems_test_assert( rv == 0 );
+
+ delay_time.tv_sec +=

Re: [PATCH v2] Test for clock_nanosleep() with CLOCK_MONOTONIC option.

2020-04-22 Thread Sebastian Huber 

On 22/04/2020 17:53, Utkarsh Rai wrote:


Rationale for a new test-


Although most of the test cases for this test have been taken from 
clockrealtime,

adding it to the current test with CLOCK_MONOTONIC may break the existing cases.


This test has a new case which tests for no change of delay with monotonic 
clock when

the realtime clock has been modified, this is easier to add in a new test.
---
  testsuites/psxtests/Makefile.am   |  10 ++
  testsuites/psxtests/configure.ac  |   1 +
  .../psxtests/psxclocknanosleep01/init.c   | 155 ++
  .../psxclocknanosleep01.doc   |  15 ++
  .../psxclocknanosleep01.scn   |  14 ++
  5 files changed, 195 insertions(+)
  create mode 100644 testsuites/psxtests/psxclocknanosleep01/init.c
  create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.doc
  create mode 100644 
testsuites/psxtests/psxclocknanosleep01/psxclocknanosleep01.scn

diff --git a/testsuites/psxtests/Makefile.am b/testsuites/psxtests/Makefile.am
index 1f9e4233ec..ba79804be7 100755
--- a/testsuites/psxtests/Makefile.am
+++ b/testsuites/psxtests/Makefile.am
@@ -312,6 +312,16 @@ psxclock01_CPPFLAGS = $(AM_CPPFLAGS) 
$(TEST_FLAGS_psxclock01) \
$(support_includes) -I$(top_srcdir)/include
  endif
  
+

+if TEST_psxclocknanosleep01
+psx_tests += psxclocknanosleep01
+psx_screens += psxclocknanosleep01/psxclocknanosleep01.scn
+psx_docs += psxclocknanosleep01/psxclocknanosleep01.doc
+psxclocknanosleep01_SOURCES = psxclocknanosleep01/init.c
+psxclocknanosleep01_CPPFLAGS = $(AM_CPPFLAGS) \
+   $(TEST_FLAGS_psxclocknanosleep01) $(support_includes)
+endif
+
  if TEST_psxclockrealtime01
  psx_tests += psxclockrealtime01
  psx_screens += psxclockrealtime01/psxclockrealtime01.scn
diff --git a/testsuites/psxtests/configure.ac b/testsuites/psxtests/configure.ac
index 139787cccb..9bfe8e2c0b 100644
--- a/testsuites/psxtests/configure.ac
+++ b/testsuites/psxtests/configure.ac
@@ -75,6 +75,7 @@ RTEMS_TEST_CHECK([psxcleanup01])
  RTEMS_TEST_CHECK([psxcleanup02])
  RTEMS_TEST_CHECK([psxclock])
  RTEMS_TEST_CHECK([psxclock01])
+RTEMS_TEST_CHECK([psxclocknanosleep01])
  RTEMS_TEST_CHECK([psxclockrealtime01])
  RTEMS_TEST_CHECK([psxconcurrency01])
  RTEMS_TEST_CHECK([psxcond01])
diff --git a/testsuites/psxtests/psxclocknanosleep01/init.c 
b/testsuites/psxtests/psxclocknanosleep01/init.c
new file mode 100644
index 00..c1f10b9eb9
--- /dev/null
+++ b/testsuites/psxtests/psxclocknanosleep01/init.c
@@ -0,0 +1,155 @@
+/*
+ *  Copyright (c) 2020 Utkarsh Rai.
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */


Please use this template for new files (BSD-2-Clause license):

https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#c-c-assembler-source-file-template


+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+typedef enum {
+  MODE_TIMEOUT_FINITE,
+  MODE_TIMEOUT_NEGATIVE_SEC,
+  MODE_TIMEOUT_NEGATIVE_NSEC,
+  MODE_TIMEOUT_NEGATIVE_SEC_NSEC,
+  MODE_TIMEOUT_HUGE_NSEC,
+  MODE_TIMEOUT_CLOCK_MODIFY
+} test_mode;
+
+static void assert_eno(const char *hint, int eno, int expected_eno)
+{
+  const char *warn = "";
+
+  if ( eno != expected_eno ) {
+warn = "WARNING: ";
+  }
+
+  printf(
+"%s%s: actual '%s', expected '%s'\n",
+warn,
+hint,
+strerror(eno),
+strerror(expected_eno)
+  );
+
+  rtems_test_assert( eno == expected_eno );
+}
+
+
+static void assert_rv(const char *hint, int rv, int expected_eno)
+{
+  int eno;
+
+  if ( rv != 0 ) {
+eno = EINVAL;
+  } else {
+eno = 0;
+  }
+
+  assert_eno( hint, eno, expected_eno );
+}


I am not in favour of adding new test support code like this. The new 
test framework has for example:


https://docs.rtems.org/branches/master/eng/test-framework.html#posix-error-numbers


+
+static void run(test_mode mode, const char* test_name)
+{
+ struct timespec  delay_time;
+ struct timespec  configure_time;
+ int rv;
+ int expected_eno;
+
+ printf("***%s*\n", test_name);

The new test framework prints stuff like this in a format easy to parse.

+
+ switch (mode) {
+   case MODE_TIMEOUT_FINITE:
+ rv = clock_gettime( CLOCK_MONOTONIC, &delay_time );
+ rtems_test_assert( rv == 0 );
+
+ delay_time.tv_sec += 1;
+ delay_time.tv_nsec += 1;
+ expected_eno = ETIMEDOUT;
+ break;


I think this switch case just make the code harder to read. What is the 
benefit? In the new test framework one of the test cases could look like:


T_TEST_CASE(POSIXClockGettimeTimeoutFinite)
{
    struct timespec delay_time;
    int eno;

    eno = clock_gettime( CLOCK_MONOTONIC, &delay_time );
    T_eno_success( eno );

    delay_time.tv_sec += 1;
    delay_time.tv_nsec += 1; // This can result in an invalid time, 
e.g. if 1.9 before the addition


    e

Re: Small doubt in a build time warning of sp test of leon3

2020-04-22 Thread Sebastian Huber 

On 22/04/2020 16:12, Joel Sherrill wrote:

the code I added is an accepted idiom for telling the compiler a 
variable or parameter is used for its analysis purposes. Does this 
make sense?


diff --git a/cpukit/include/rtems/score/isrlock.h 
b/cpukit/include/rtems/score/i

index 14ea88b..52645a3 100644
--- a/cpukit/include/rtems/score/isrlock.h
+++ b/cpukit/include/rtems/score/isrlock.h
@@ -147,7 +147,7 @@ typedef struct {
     { SMP_LOCK_INITIALIZER( _name ) }
 #else
   #define ISR_LOCK_INITIALIZER( _name ) \
-    { }
+    { (void) (_name); }
 #endif
For a function-like macro it would be all right, however, this if an 
initializer macro. I guess this test needs some #ifdef RTEMS_SMP to fix 
the warnings.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Small doubt in a build time warning of sp test of leon3

2020-04-22 Thread Joel Sherrill 
On Wed, Apr 22, 2020 at 1:55 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 22/04/2020 16:12, Joel Sherrill wrote:
>
> > the code I added is an accepted idiom for telling the compiler a
> > variable or parameter is used for its analysis purposes. Does this
> > make sense?
> >
> > diff --git a/cpukit/include/rtems/score/isrlock.h
> > b/cpukit/include/rtems/score/i
> > index 14ea88b..52645a3 100644
> > --- a/cpukit/include/rtems/score/isrlock.h
> > +++ b/cpukit/include/rtems/score/isrlock.h
> > @@ -147,7 +147,7 @@ typedef struct {
> >  { SMP_LOCK_INITIALIZER( _name ) }
> >  #else
> >#define ISR_LOCK_INITIALIZER( _name ) \
> > -{ }
> > +{ (void) (_name); }
> >  #endif
> For a function-like macro it would be all right, however, this if an
> initializer macro. I guess this test needs some #ifdef RTEMS_SMP to fix
> the warnings.
>

Yeah. I didn't actually compile it. It looked like a function macro
and terminated for uniprocessor systems like that. Other cases
may need indicate something else.

Just another example of how warnings can look easy. :)

--joel

> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Release task request for help

2020-04-22 Thread Chris Johns 

Hello,

I need a script to be used in the release process and I was wondering if 
a GSoC student would be able to help.


The release process is started by branching all the required repos. 
These are listed in the Software Engineering manual ...


https://docs.rtems.org/branches/master/eng/release-process.html#release-repositories

I need a script along the lines of the `rtems-release-tag` script called 
`rtems-release-branch` that will branch with a push all the release 
repositories.


If you are interested in helping please let me know. The doco here ..

https://docs.rtems.org/branches/master/eng/release-process.html#

... should provide a context.

Thanks
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

adding aio.h to newlib

2020-04-22 Thread Eshan Dhawan 
Hello everyone,
After adding aio.h to newlib/libc/include and running  configure for
target=sparc-rtems5 and running make all
it shows no errors
How do I know that newlib was able to make aio.h?

-Thanks
Eshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Release task request for help

2020-04-22 Thread Niteesh G. S. 
Hello Chris,


> Message: 4
> Date: Thu, 23 Apr 2020 14:35:12 +1000
> From: Chris Johns 
> To: RTEMS Devel 
> Subject: Release task request for help
> Message-ID: <7976c497-cff1-7c73-f673-596dd831c...@rtems.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hello,
>
> I need a script to be used in the release process and I was wondering if
> a GSoC student would be able to help.
>

I am willing to help with this. I went through the docs you mentioned.
I also had a look at the rtems-release-tag script.

I have a question, why is it shell script instead of python?


> The release process is started by branching all the required repos.
> These are listed in the Software Engineering manual ...
>
>
> https://docs.rtems.org/branches/master/eng/release-process.html#release-repositories
>
> I need a script along the lines of the `rtems-release-tag` script called
> `rtems-release-branch` that will branch with a push all the release
> repositories.
>
> If you are interested in helping please let me know. The doco here ..
>
> https://docs.rtems.org/branches/master/eng/release-process.html#
>
> ... should provide a context.
>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel