[PATCH] Fix bashism in vc-key.sh
Change "==" to "=", since "==" for comparison is not available in POSIX
sh.
Signed-off-by: Martin Erik Werner
---
cpukit/sapi/vc-key.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpukit/sapi/vc-key.sh b/cpukit/sapi/vc-key.sh
index c628a1e26d..3c8f446d3f 100755
--- a/cpukit/sapi/vc-key.sh
+++ b/cpukit/sapi/vc-key.sh
@@ -15,7 +15,7 @@ if test $# -ge 1; then
cd $repo
if test -n ${git}; then
git rev-parse --git-dir > /dev/null 2>&1
- if test $? == 0; then
+ if test $? = 0; then
git status > /dev/null 2>&1
if git diff-index --quiet HEAD --; then
modified=""
@@ -24,7 +24,7 @@ if test $# -ge 1; then
fi
vc_ident="$(git rev-parse --verify HEAD)${modified}"
if test $# -ge 1; then
- if test "${vc_ident}" == "$1"; then
+ if test "${vc_ident}" = "$1"; then
vc_ident="matches"
fi
fi
--
2.11.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-bsp-builder] 2017-11-10 14:47:44: Profile(s): everything
On Sat, Nov 11, 2017 at 9:46 PM, Chris Johns wrote: > On 12/11/17 4:55 am, j...@rtems.org wrote: > > RTEMS Tools Project - RTEMS Kernel BSP Builder, 5 (9f34b38edf2a) > > > > > > Host: #1 SMP Tue Sep 12 22:26:13 UTC 2017 > > > > command: ./rtems-tools/tester/rtems-bsp-builder > --rtems=/home/joel/rtems-\ > > work/rtems --build-path=build --prefix=/home/joel/rtems- > work/bsps\ > > --log=build.log --warnings-report=warnings.log --mail --mail-\ > > from=j...@rtems.org --mail-to=bu...@rtems.org\ > > --profiles=everything --jobs=8 > > > > Total Time: 21:07:44.882315 for 1565 completed job(s) > > Average BSP Build Time: 0:00:48.603758 > > > > Failures Report > > === > >1 posix-debug arm/altcycv_devkit build: > > configure: /home/joel/rtems-work/rtems/configure > --target=arm-rtems5\ > > --enable-rtemsbsp=altcycv_devkit --prefix=/home/joel/rtems- > work/bsps\ > > --enable-debug --enable-posix > > I ran the same build ... > > https://lists.rtems.org/pipermail/build/2017-November/000221.html > > and I did not get an error. Is there a tool set missing or rtems.git needs > a > bootstrap? > Looks like a race condition. The v850 failed similarly. /usr/bin/install -c -m 644 /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera-cyclone-v/../shared/include/arm-a9mpcore-irq.h ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h /usr/bin/install -c -m 644 /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera-cyclone-v/../shared/include/arm-a9mpcore-irq.h ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h /usr/bin/install: cannot change permissions of ‘../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h’: No such file or directory /usr/bin/install -c -m 644 /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera-cyclone-v/../shared/include/arm-a9mpcore-regs.h ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-regs.h gmake[8]: *** [../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h] Error 1 gmake[8]: Leaving directory `/data/home/joel/rtems-work/build/arm/altcycv_devkit.posix-debug/arm-rtems5/c/altcycv_devkit/lib/libbsp/arm/altera-cyclone-v' gmake[7]: *** [preinstall-altera-cyclone-v] Error 1 Weird that it appears to be inside the middle of install. I assume it copied the file and then couldn't change the permissions. --joel > > Chris > ___ > 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: [rtems-bsp-builder] 2017-11-10 14:47:44: Profile(s): everything
On 13/11/2017 02:42, Joel Sherrill wrote: > > Looks like a race condition. The v850 failed similarly. > > /usr/bin/install -c -m 644 > /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera-cyclone-v/../shared/include/arm-a9mpcore-irq.h > ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h > /usr/bin/install -c -m 644 > /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera-cyclone-v/../shared/include/arm-a9mpcore-irq.h > ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h > /usr/bin/install: cannot change permissions of > ‘../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h’: > No > such file or directory > /usr/bin/install -c -m 644 > /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera-cyclone-v/../shared/include/arm-a9mpcore-regs.h > ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-regs.h > gmake[8]: *** > [../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h] Error > 1 > gmake[8]: Leaving directory > `/data/home/joel/rtems-work/build/arm/altcycv_devkit.posix-debug/arm-rtems5/c/altcycv_devkit/lib/libbsp/arm/altera-cyclone-v' > gmake[7]: *** [preinstall-altera-cyclone-v] Error 1 > > Weird that it appears to be inside the middle of install. I assume it copied > the > file > and then couldn't change the permissions. > That is weird. Is this repeatable? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Fix bashism in vc-key.sh
On 13/11/2017 01:39, Martin Erik Werner wrote: > Change "==" to "=", since "==" for comparison is not available in POSIX > sh. Thank you. I have pushed this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-bsp-builder] 2017-11-10 14:47:44: Profile(s): everything
On Sun, Nov 12, 2017 at 3:11 PM, Chris Johns wrote: > On 13/11/2017 02:42, Joel Sherrill wrote: > > > > Looks like a race condition. The v850 failed similarly. > > > > /usr/bin/install -c -m 644 > > /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera- > cyclone-v/../shared/include/arm-a9mpcore-irq.h > > ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h > > /usr/bin/install -c -m 644 > > /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera- > cyclone-v/../shared/include/arm-a9mpcore-irq.h > > ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h > > /usr/bin/install: cannot change permissions of > > ‘../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h’: > No > > such file or directory > > /usr/bin/install -c -m 644 > > /home/joel/rtems-work/rtems/c/src/lib/libbsp/arm/altera- > cyclone-v/../shared/include/arm-a9mpcore-regs.h > > ../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-regs.h > > gmake[8]: *** > > [../../../../../.././altcycv_devkit/lib/include/bsp/arm-a9mpcore-irq.h] > Error 1 > > gmake[8]: Leaving directory > > `/data/home/joel/rtems-work/build/arm/altcycv_devkit. > posix-debug/arm-rtems5/c/altcycv_devkit/lib/libbsp/arm/altera-cyclone-v' > > gmake[7]: *** [preinstall-altera-cyclone-v] Error 1 > > > > Weird that it appears to be inside the middle of install. I assume it > copied the > > file > > and then couldn't change the permissions. > > > > That is weird. Is this repeatable? > Just updated and starting another build overnight. I guess we shall see. I think it is a random problem with -jN. This is what I used to build. nohup time ./rtems-tools/tester/rtems-bsp-builder \ --rtems=/home/joel/rtems-work/rtems \ --build-path=build \ --prefix=/home/joel/rtems-work/bsps \ --log=build.log \ --warnings-report=warnings.log \ --mail \ --mail-from=j...@rtems.org \ --mail-to=bu...@rtems.org \ --profiles=everything \ --jobs=8 \ > nohup.out 2>&1 > > Chris > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Upgrade to 5.0.0
On 11/11/17 22:58, Chris Johns wrote:
On 11/11/17 7:40 pm, Sebastian Huber wrote:
- Am 11. Nov 2017 um 5:06 schrieb Chris Johns chr...@rtems.org:
On 10/11/2017 17:30, Sebastian Huber wrote:
On 09/11/17 23:52, Joel Sherrill wrote:
My question about the version number went unanswered. Is this the point
were we are switching to two digit versions? This thread has 5.0.0 in the
title (3 digits, no change in style) but the current tools are "*-rtems5" which
implies two digit release numbering. Can I get a clarification on that?
Yes, the new number scheme.
Master 5.0.0
First release 5.1.0 (spelled as 5.1 in documents, etc.; exactly one commit has
this version)
Branch after first release 5.1.1
Second release in this series 5.2.0 (spelled as 5.2)
Branch after second release 5.2.1
How do the milestones now work in Trac? I see we have 5.0, 5.1 etc. Will there
be milestones for 5.1.0, 5.1.1, etc?
No, we have 5.1, 5.2 and 6.1 milestones.
How do you plan a release? Do all release branch tickets, ie 5.1, need to be
resolved to make the release, ie 5.1.3? Previously we could assign tickets to
5.1.3 and 5.1.4.
There will be no 5.1.X release with X != 0. We have a version scheme
change and not simply a major version number bump. I think is quite good
explained in the GCC development page how it works (Version Numbering
Scheme for GCC 5 and Up):
https://gcc.gnu.org/develop.html
We need something similar in the new engineering guide.
Next master 6.0.0
Tools use just "5".
I have been wondering about this for a while because I was concerned about
rtems5 and no rtems5.1, rtems5.2, etc as we have had for the 4 series. I think
rtems5 will work if we add configure checks for newlib into the kernel, libbsd
etc.
GCC's interfaces are stable and do not move that much, it is newlib that changes
requiring us to build new tools. If a check for gcc and newlib was added to the
top level configure script of RTEMS we would be able protect users from
attempting to build RTEMS with the wrong version of tools. If this is something
that should happen I can create a ticket.
We already have such a check in RTEMS. If you build the master with the 4.12
tools, you get a configure error which tells you to update the tools via RSB. I
hope that the Newlib/GCC interface stabilizes now. You don't have the C++11
support, POSIX header file move, self-contained POSIX synchronization objects,
OpenMP support, etc. every year. One missing piece is the ucontext support for
Go.
This change means users need to use prefixes when supporting more than one
release. I would need to review the User manual and see what it says.
I think nothing changes here, you need a RTEMS 4.10, 4.11, 4.12 prefix, now its
a 5 prefix.
I must be confused. Before this change we had tools named after the major and
minor version numbers in a release series, for example 4.9, 4.10, and 4.11 which
allowed a common prefix. The tools for 4.11 are $PREFIX/bin/*-rtems4.11-* and
libraries are under $PREFIX/*-rtems4.11. More formally written as:
${PREFIX}/bin/*-rtems${major}.${minor}-*
${PREFIX}/*-rtems${major}.${minor}
With this change we have moved to:
${PREFIX}/bin/*-rtems$[major}-*
${PREFIX}/*-rtems${major}
This is a significant change if you have not used separate prefixes before now.
What do you mean with separate prefixes? I doubt that you can build a
RTEMS 4.1 with the tool chain of RTEMS 4.10 and vice versa.
I assume we are not saying any rtems5 tool set will work with any series 5
release?
Any rtems5 tool must work with any series 5 release. The 5.2, 5.3, ...
are bug fix releases of 5.1.
This is the reason I raised the need to check the supported version of
newlib. It becomes difficult to catch mismatch errors when the tools are all
named after the major version number.
We should define a default prefix pattern and adjust the documentation
accordingly, e.g. $HOME/rtems/$version, or /opt/rtems/$version.
We need to document and educate about this change.
A RTEMS installation supporting several version could look like:
/opt/rtems/4.8
/opt/rtems/4.9
/opt/rtems/4.10/bin/X-rtems4.10-gcc
/opt/rtems/4.11
/opt/rtems/5/bin/X-rtems5-gcc
/opt/rtems/6 (maybe with the new build system)
/opt/rtems/7/bin/X-rtems7-gcc
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
