[arch-dev-public] [makepkg] permission issue when stripping
I get this weird permission issue in go-oo build makepkg: Packaging succeeded /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1/build/ooo320-m8/dictionaries/unxlngx6.pro/bin /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1/build/ooo320-m8/solver/320/unxlngx6.pro/bin /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 ==> Tidying install... -> Purging other files... -> Compressing man and info pages... -> Stripping debugging symbols from binaries and libraries... /usr/bin/strip: unable to copy file 'usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3'; reason: Permission denied real 89m57.478s user 215m13.768s sys 22m56.040s It's reproducible. File permissions are the same like in the last go-oo release that built fine. It happens in my testing chroot. pkg working on my laptop that built fine: [andyrtr@laptop64 tmp]$ ls -lha /usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3 -r--r--r-- 1 root root 1,8M 28. Nov 14:43 /usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3 in my chroot right after the build failure: -r--r--r-- 1 andyrtr users 2.0M Dec 28 12:47 pkg/usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3 The pkg is not a splitted pkgbuild! Just plain oldschool build{} Any idea? May this be smp related? -Andy
On Mon, Dec 28, 2009 at 8:34 AM, Andreas Radke <a.radke@arcor.de> wrote:
I get this weird permission issue in go-oo build makepkg:
Packaging succeeded /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1/build/ooo320-m8/dictionaries/unxlngx6.pro/bin /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1/build/ooo320-m8/solver/320/unxlngx6.pro/bin /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 ==> Tidying install... -> Purging other files... -> Compressing man and info pages... -> Stripping debugging symbols from binaries and libraries... /usr/bin/strip: unable to copy file 'usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3'; reason: Permission denied
real 89m57.478s user 215m13.768s sys 22m56.040s
It's reproducible. File permissions are the same like in the last go-oo release that built fine. It happens in my testing chroot.
pkg working on my laptop that built fine:
[andyrtr@laptop64 tmp]$ ls -lha /usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3 -r--r--r-- 1 root root 1,8M 28. Nov 14:43 /usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3
in my chroot right after the build failure: -r--r--r-- 1 andyrtr users 2.0M Dec 28 12:47 pkg/usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3
The pkg is not a splitted pkgbuild! Just plain oldschool build{}
Any idea? May this be smp related?
Hmm, I've had problems on other Unicies like this (with strip), but that was typically caused when using GNU's strip against binaries created by other crazy compilers. Is this .so created by gcc?
On Mon, Dec 28, 2009 at 8:34 AM, Andreas Radke <a.radke@arcor.de> wrote:
I get this weird permission issue in go-oo build makepkg:
Packaging succeeded /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1/build/ooo320-m8/dictionaries/unxlngx6.pro/bin /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1/build/ooo320-m8/solver/320/unxlngx6.pro/bin /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 /tmp/go-openoffice/trunk/src/ooo-build-3.2.0.1 ==> Tidying install... -> Purging other files... -> Compressing man and info pages... -> Stripping debugging symbols from binaries and libraries... /usr/bin/strip: unable to copy file 'usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3'; reason: Permission denied
real 89m57.478s user 215m13.768s sys 22m56.040s
It's reproducible. File permissions are the same like in the last go-oo release that built fine. It happens in my testing chroot.
pkg working on my laptop that built fine:
[andyrtr@laptop64 tmp]$ ls -lha /usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3 -r--r--r-- 1 root root 1,8M 28. Nov 14:43 /usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3
in my chroot right after the build failure: -r--r--r-- 1 andyrtr users 2.0M Dec 28 12:47 pkg/usr/lib/go-openoffice/ure/lib/libuno_sal_textenc.so.3
The pkg is not a splitted pkgbuild! Just plain oldschool build{}
Any idea? May this be smp related?
What is the permission on the containing directory? It looks like it might be trying to create a temp file there and failing. -Dan
Am Mon, 28 Dec 2009 13:13:33 -0600 schrieb Dan McGee <dpmcgee@gmail.com>:
What is the permission on the containing directory? It looks like it might be trying to create a temp file there and failing.
-Dan
I'm using our toolchain. Gcc should be fine. I'm building not with mkchrootpkg but with my own chroot. I build in /tmp and use tmpfs. That never gave problems so far. Enough space is there extending with swap. I've build several packages the last days. This is the only one failing. I already cleaned the build dir and rebooted the system. It would take a while but it's possible to do again. I doubt the parent directory is important. There were other libs in it that didn't made strip fail. I also remember last kernel and udev brought changes. Not sure if it was tmpfs or /dev or something simliar. Is it possible to do the stripping more verbose? -Andy
On Mon, Dec 28, 2009 at 2:02 PM, Andreas Radke <a.radke@arcor.de> wrote:
Am Mon, 28 Dec 2009 13:13:33 -0600 schrieb Dan McGee <dpmcgee@gmail.com>:
What is the permission on the containing directory? It looks like it might be trying to create a temp file there and failing.
-Dan
I'm using our toolchain. Gcc should be fine.
I'm building not with mkchrootpkg but with my own chroot. I build in /tmp and use tmpfs. That never gave problems so far. Enough space is there extending with swap.
I've build several packages the last days. This is the only one failing. I already cleaned the build dir and rebooted the system. It would take a while but it's possible to do again. I doubt the parent directory is important. There were other libs in it that didn't made strip fail.
I also remember last kernel and udev brought changes. Not sure if it was tmpfs or /dev or something simliar.
Is it possible to do the stripping more verbose?
As a test, does it succeed if it's NOT built in tmpfs?
Am Mon, 28 Dec 2009 14:38:25 -0600 schrieb Aaron Griffin <aaronmgriffin@gmail.com>:
As a test, does it succeed if it's NOT built in tmpfs?
Yes, built now in /var/abs and it also failed the same way. I'll keep the build. What directory should I check for permission? [andyrtr@workstation64 trunk]$ ls -lha /tmp/ total 53K drwxrwxrwt 12 root root 520 Dec 29 10:49 . drwxr-xr-x 20 root root 480 Dec 21 16:27 .. drwxrwxrwt 2 root root 60 Dec 28 18:31 .ICE-unix -r--r--r-- 1 andyrtr users 11 Dec 28 18:31 .X1000-lock drwxrwxrwt 2 root root 60 Dec 28 18:31 .X11-unix drwx------ 2 andyrtr users 40 Dec 28 18:31 .esd-1000 -rw------- 1 1002 1002 0 Dec 28 18:31 .nX1000-lock -rw------- 1 andyrtr users 434 Dec 28 18:31 .xfsm-ICE-O3KS5U -rw-r--r-- 1 andyrtr users 6 Dec 28 18:31 blueman-applet-1000 drwxr-xr-x 5 andyrtr users 100 Dec 28 18:33 gcin drwxr-xr-x 2 andyrtr users 60 Dec 29 10:49 hsperfdata_andyrtr drwxr-xr-x 2 andyrtr users 40 Dec 29 10:49 hsperfdata_root -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-0whcIx.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-CtFG1Y.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-E7PqCX.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-Enxcbq.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-M8LI0P.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-Qznkxi.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-WlHRGH.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-XnGYjv.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-tII6ea.err -rw-r--r-- 1 andyrtr users 112 Dec 29 09:28 localize-ooo-sdf-filtered-vJS8C9.err drwxrwxrwx 2 andyrtr users 40 Dec 29 10:52 ooopackaging drwx------ 2 andyrtr users 140 Dec 28 18:32 orbit-andyrtr drwx------ 2 andyrtr users 40 Dec 28 18:31 pulse-gCKnqYXkmCK6 drwx------ 2 andyrtr users 60 Dec 28 18:31 ssh-pWSvkj4778
On Tue, Dec 29, 2009 at 4:56 AM, Andreas Radke <a.radke@arcor.de> wrote:
Am Mon, 28 Dec 2009 14:38:25 -0600 schrieb Aaron Griffin <aaronmgriffin@gmail.com>:
As a test, does it succeed if it's NOT built in tmpfs?
Yes, built now in /var/abs and it also failed the same way. I'll keep the build. What directory should I check for permission?
[andyrtr@workstation64 trunk]$ ls -lha /tmp/
You mentioned /var/tmp/ in one sentence but then ls-ed /tmp/
After some short tests we found strip failing for any regular user as well inside fakeroot on files with permission 444 or 555: $ cp /lib/libacl.so.1 /tmp/testlib.so; chmod 444 /tmp/testlib.so; /usr/bin/strip /tmp/testlib.so /usr/bin/strip: unable to copy file '/tmp/testlib.so'; reason: Permission denied Dan could confirm this on his system.
On Tue, Dec 29, 2009 at 8:53 AM, Andreas Radke <a.radke@arcor.de> wrote:
After some short tests we found strip failing for any regular user as well inside fakeroot on files with permission 444 or 555:
$ cp /lib/libacl.so.1 /tmp/testlib.so; chmod 444 /tmp/testlib.so; /usr/bin/strip /tmp/testlib.so /usr/bin/strip: unable to copy file '/tmp/testlib.so'; reason: Permission denied
Dan could confirm this on his system.
That is expected. Both 444 and 555 are missing write permissions, and strip re-writes the file.
Am Wed, 30 Dec 2009 15:13:40 -0600 schrieb Aaron Griffin <aaronmgriffin@gmail.com>:
On Tue, Dec 29, 2009 at 8:53 AM, Andreas Radke <a.radke@arcor.de> wrote:
After some short tests we found strip failing for any regular user as well inside fakeroot on files with permission 444 or 555:
$ cp /lib/libacl.so.1 /tmp/testlib.so; chmod 444 /tmp/testlib.so; /usr/bin/strip /tmp/testlib.so /usr/bin/strip: unable to copy file '/tmp/testlib.so'; reason: Permission denied
Dan could confirm this on his system.
That is expected. Both 444 and 555 are missing write permissions, and strip re-writes the file.
Yes. But somehow we get files (unwanted?) with such permissions into our systems. I'm not sure if fakeroot causes this. I have several files on my system with 444/555 permission that all should have given my stripping issue. Either stripping worked in the past or whatever happened lately. I filed a bug today http://bugs.archlinux.org/task/17656 -Andy
participants (3)
-
Aaron Griffin
-
Andreas Radke
-
Dan McGee