Opened on 06/14/17 at 06:25:49

Last modified on 06/14/17 at 10:12:39

#3048 new defect

RSB cannot overwrite read-only files

Reported by: Sebastian Huber Owned by: Chris Johns
Priority: normal Milestone: Indefinite
Component: tool/rsb Version:
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

Lets suppose in the prefix is already a tool chain installed. The the following error happens:

../source-builder/sb-set-builder --prefix=/build/rtems-4.12 4.12/rtems-arm --with-ada
RTEMS Source Builder - Set Builder, 4.12 (0ba8934976c2)
warning: exe: absolute exe found in path: (__chown) /usr/sbin/chown
Build Set: 4.12/rtems-arm
Build Set: 4.12/rtems-autotools.bset
Build Set: 4.12/rtems-autotools-internal.bset
config: tools/rtems-autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-linux-gnu-1
building: autoconf-2.69-x86_64-linux-gnu-1
config: tools/rtems-automake-1.12.6-1.cfg
package: automake-1.12.6-x86_64-linux-gnu-1
building: automake-1.12.6-x86_64-linux-gnu-1
cleaning: autoconf-2.69-x86_64-linux-gnu-1
cleaning: automake-1.12.6-x86_64-linux-gnu-1
Build Set: Time 0:00:06.718931
Build Set: 4.12/rtems-autotools-base.bset
config: tools/rtems-autoconf-2.69-1.cfg
package: autoconf-2.69-x86_64-linux-gnu-1
building: autoconf-2.69-x86_64-linux-gnu-1
reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-linux-gnu-1.txt
reporting: tools/rtems-autoconf-2.69-1.cfg -> autoconf-2.69-x86_64-linux-gnu-1.xml
config: tools/rtems-automake-1.12.6-1.cfg
package: automake-1.12.6-x86_64-linux-gnu-1
building: automake-1.12.6-x86_64-linux-gnu-1
reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-linux-gnu-1.txt
reporting: tools/rtems-automake-1.12.6-1.cfg -> automake-1.12.6-x86_64-linux-gnu-1.xml
installing: autoconf-2.69-x86_64-linux-gnu-1 -> /build/rtems-4.12
installing: automake-1.12.6-x86_64-linux-gnu-1 -> /build/rtems-4.12
cleaning: autoconf-2.69-x86_64-linux-gnu-1
cleaning: automake-1.12.6-x86_64-linux-gnu-1
Build Set: Time 0:00:09.502426
Build Set: Time 0:00:16.224575
config: devel/expat-2.1.0-1.cfg
package: expat-2.1.0-x86_64-linux-gnu-1
building: expat-2.1.0-x86_64-linux-gnu-1
reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.txt
reporting: devel/expat-2.1.0-1.cfg -> expat-2.1.0-x86_64-linux-gnu-1.xml
config: tools/rtems-binutils-2.28-1.cfg
package: arm-rtems4.12-binutils-2.28-x86_64-linux-gnu-1
building: arm-rtems4.12-binutils-2.28-x86_64-linux-gnu-1
reporting: tools/rtems-binutils-2.28-1.cfg -> arm-rtems4.12-binutils-2.28-x86_64-linux-gnu-1.txt
reporting: tools/rtems-binutils-2.28-1.cfg -> arm-rtems4.12-binutils-2.28-x86_64-linux-gnu-1.xml
config: tools/rtems-gcc-7.1.0-newlib-2.5.0.20170519-1.cfg
package: arm-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-linux-gnu-1
building: arm-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-linux-gnu-1
reporting: tools/rtems-gcc-7.1.0-newlib-2.5.0.20170519-1.cfg -> arm-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-linux-gnu-1.txt
reporting: tools/rtems-gcc-7.1.0-newlib-2.5.0.20170519-1.cfg -> arm-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-linux-gnu-1.xml
config: tools/rtems-gdb-7.12-1.cfg
package: arm-rtems4.12-gdb-7.12-x86_64-linux-gnu-1
building: arm-rtems4.12-gdb-7.12-x86_64-linux-gnu-1
reporting: tools/rtems-gdb-7.12-1.cfg -> arm-rtems4.12-gdb-7.12-x86_64-linux-gnu-1.txt
reporting: tools/rtems-gdb-7.12-1.cfg -> arm-rtems4.12-gdb-7.12-x86_64-linux-gnu-1.xml
config: tools/rtems-tools-4.12-1.cfg
package: rtems-tools-HEAD-1
git: reset: git://git.rtems.org/rtems-tools.git
git: fetch: git://git.rtems.org/rtems-tools.git -> sources/git/rtems-tools.git
git: checkout: git://git.rtems.org/rtems-tools.git => HEAD
git: pull: git://git.rtems.org/rtems-tools.git
building: rtems-tools-HEAD-1
reporting: tools/rtems-tools-4.12-1.cfg -> rtems-tools-HEAD-1.txt
reporting: tools/rtems-tools-4.12-1.cfg -> rtems-tools-HEAD-1.xml
config: tools/rtems-kernel-4.12.cfg
package: arm-rtems4.12-kernel-4.12-1
building: arm-rtems4.12-kernel-4.12-1
reporting: tools/rtems-kernel-4.12.cfg -> arm-rtems4.12-kernel-4.12-1.txt
reporting: tools/rtems-kernel-4.12.cfg -> arm-rtems4.12-kernel-4.12-1.xml
installing: expat-2.1.0-x86_64-linux-gnu-1 -> /build/rtems-4.12
installing: arm-rtems4.12-binutils-2.28-x86_64-linux-gnu-1 -> /build/rtems-4.12
installing: arm-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-linux-gnu-1 -> /build/rtems-4.12
error: copying tree: /scratch/git-rtems-source-builder/rtems/build/tmp/arm-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-linux-gnu-1-root-sebastian_h/build/rtems-4.12/lib/gcc/arm-rtems4.12/7.1.0/thumb/armv6-m/adalib/g-spchge.ali -> /build/rtems-4.12/lib/gcc/arm-rtems4.12/7.1.0/thumb/armv6-m/adalib/g-spchge.ali: [Errno 13] Permission denied: '/build/rtems-4.12/lib/gcc/arm-rtems4.12/7.1.0/thumb/armv6-m/adalib/g-spchge.ali'
Build Set: Time 0:37:12.690249
Build FAILED
self:/scratch/git-rtems-source-builder/rtems (master) > ll /build/rtems-4.12/lib/gcc/arm-rtems4.12/7.1.0/thumb/armv6-m/adalib/g-spchge.ali
-r--r--r-- 1 sebastian_h domain users 2070 Jun 13 14:03 /build/rtems-4.12/lib/gcc/arm-rtems4.12/7.1.0/thumb/armv6-m/adalib/g-spchge.ali
self:/scratch/git-rtems-source-builder/rtems (master) > ll /scratch/git-rtems-source-builder/rtems/build/tmp/arm-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-linux-gnu-1-root-sebastian_h/build/rtems-4.12/lib/gcc/arm-rtems4.12/7.1.0/thumb/armv6-m/adalib/g-spchge.ali
-r--r--r-- 1 sebastian_h domain users 2070 Jun 14 07:53 /scratch/git-rtems-source-builder/rtems/build/tmp/arm-rtems4.12-gcc-7.1.0-newlib-2.5.0.20170519-x86_64-linux-gnu-1-root-sebastian_h/build/rtems-4.12/lib/gcc/arm-rtems4.12/7.1.0/thumb/armv6-m/adalib/g-spchge.ali

Change History (11)

comment:1 Changed on 06/14/17 at 06:36:39 by Chris Johns

Why is the packaging being built installing read-only files? Is this an upstream bug?

Consider:

$ mkdir /tmp/xya
$ mkdir /tmp/xya/abz
$ touch /tmp/xya/abz/129
$ ls -las /tmp/xya/abz/129
0 -rw-r--r--  1 chris  wheel  0 Jun 14 16:30 /tmp/xya/abz/129
$ chmod 444 /tmp/xya/abz/129                                                                                                                                                                                                                                                                                                                            
$ ls -las /tmp/xya/abz/129
0 -r--r--r--  1 chris  wheel  0 Jun 14 16:30 /tmp/xya/abz/129
$ rm -r /tmp/xya
override r--r--r--  chris/wheel for /tmp/xya/abz/129?

Removing read-only files is not "expected" behaviour.
I suppose with the RSB and a package and package we could so this.

Note, the path.py code from the 4.11 patch I just posted needs to be ported to master. It has a better removeall. I plan to do this once merged on to the 4.11 branch.

Version 0, edited on 06/14/17 at 06:36:39 by Chris Johns (next)

comment:2 in reply to:  1 Changed on 06/14/17 at 06:51:47 by Sebastian Huber

Replying to Chris Johns:

Why is the packaging being built installing read-only files? Is this an upstream bug?

​https://gcc.gnu.org/ml/gcc/2017-06/msg00086.html

comment:3 Changed on 06/14/17 at 07:01:12 by Sebastian Huber

The problem exists also in case I delete the prefix first. This is quite a show stopper for the Ada support.

comment:4 in reply to:  3 ; Changed on 06/14/17 at 07:02:55 by Chris Johns

Replying to Sebastian Huber:

The problem exists also in case I delete the prefix first.

How did the files get installed in the first place?

This is quite a show stopper for the Ada support.

Yes it is awkward in a number of ways.

comment:5 Changed on 06/14/17 at 07:03:21 by Sebastian Huber

The Ada maintainer confirmed that the access permissions for the *.ali files are intentional:

​https://gcc.gnu.org/ml/gcc/2017-06/msg00087.html

comment:6 in reply to:  4 ; Changed on 06/14/17 at 07:04:18 by Sebastian Huber

Replying to Chris Johns:

Replying to Sebastian Huber:

The problem exists also in case I delete the prefix first.

How did the files get installed in the first place?

Manually, via make install.

comment:7 in reply to:  6 Changed on 06/14/17 at 07:16:46 by Chris Johns

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

The problem exists also in case I delete the prefix first.

How did the files get installed in the first place?

Manually, via make install.

And I suppose doing another make install works.

It must be something in the python shutil module we are tripping over.

comment:8 Changed on 06/14/17 at 09:29:10 by Sebastian Huber

If I delete the build directory of the RSB, then the tool chain build works. This suggests that there is a serious issue with the RSB: it re-uses a directory tree of a previous build.

comment:9 in reply to:  8 ; Changed on 06/14/17 at 09:54:41 by Chris Johns

Replying to Sebastian Huber:

If I delete the build directory of the RSB, then the tool chain build works. This suggests that there is a serious issue with the RSB: it re-uses a directory tree of a previous build.

Could this be related to a build that fails and so not cleaned?

comment:10 in reply to:  9 ; Changed on 06/14/17 at 09:56:32 by Sebastian Huber

Replying to Chris Johns:

Replying to Sebastian Huber:

If I delete the build directory of the RSB, then the tool chain build works. This suggests that there is a serious issue with the RSB: it re-uses a directory tree of a previous build.

Could this be related to a build that fails and so not cleaned?

Could be. I did so many builds in the last couple of days that I lost a bit track what I did actually.

Would it make sense to ensure that everything is clean before we start the build?

comment:11 in reply to:  10 Changed on 06/14/17 at 10:12:39 by Chris Johns

Replying to Sebastian Huber:

Replying to Chris Johns:

Replying to Sebastian Huber:

If I delete the build directory of the RSB, then the tool chain build works. This suggests that there is a serious issue with the RSB: it re-uses a directory tree of a previous build.

Could this be related to a build that fails and so not cleaned?

Could be. I did so many builds in the last couple of days that I lost a bit track what I did actually.

Would it make sense to ensure that everything is clean before we start the build?

Yes this make sense and is important. It needs to be mapped to the specific build or '--keep-going' failed build tees are lost.

Note: See TracTickets for help on using tickets.