[LU-204] building e2fsprogs on rhel6 : $BUILDROOT/e2fsprogs-1.41.90.wc1-0redhat.x86_64/usr/lib64/libcom_err.a'; reason: Permission denied

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.1.0
• Type: Bug
• Priority: Minor
• Reporter: Brian Murrell (Inactive)
• Assignee: Brian Murrell (Inactive)
• Resolution: Duplicate

Environment

rhel6

• Severity: 3

Description

When trying to build e2fsprogs on rhel6/x86_64 the rpm build fails with:

+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
/usr/bin/strip: unable to copy file '/var/lib/jenkins/workspace/e2fsprogs-master/arch/x86_64/distro/el6/_topdir/BUILDROOT/e2fsprogs-1.41.90.wc1-0redhat.x86_64/usr/lib64/libcom_err.a'; reason: Permission denied
/usr/bin/strip: unable to copy file '/var/lib/jenkins/workspace/e2fsprogs-master/arch/x86_64/distro/el6/_topdir/BUILDROOT/e2fsprogs-1.41.90.wc1-0redhat.x86_64/usr/lib64/libext2fs.a'; reason: Permission denied
/usr/bin/strip: unable to copy file '/var/lib/jenkins/workspace/e2fsprogs-master/arch/x86_64/distro/el6/_topdir/BUILDROOT/e2fsprogs-1.41.90.wc1-0redhat.x86_64/usr/lib64/libss.a'; reason: Permission denied
/usr/bin/strip: unable to copy file '/var/lib/jenkins/workspace/e2fsprogs-master/arch/x86_64/distro/el6/_topdir/BUILDROOT/e2fsprogs-1.41.90.wc1-0redhat.x86_64/usr/lib64/libuuid.a'; reason: Permission denied
/usr/bin/strip: unable to copy file '/var/lib/jenkins/workspace/e2fsprogs-master/arch/x86_64/distro/el6/_topdir/BUILDROOT/e2fsprogs-1.41.90.wc1-0redhat.x86_64/usr/lib64/libe2p.a'; reason: Permission denied
/usr/bin/strip: unable to copy file '/var/lib/jenkins/workspace/e2fsprogs-master/arch/x86_64/distro/el6/_topdir/BUILDROOT/e2fsprogs-1.41.90.wc1-0redhat.x86_64/usr/lib64/libblkid.a'; reason: Permission denied

in %install. Looking at the files in that directory:

total 3080
-rwxr-xr-x 1 jenkins jenkins   10008 Apr  8 13:32 e2initrd_helper
-r--r--r-- 1 jenkins jenkins  315942 Apr  8 13:32 libblkid.a
lrwxrwxrwx 1 jenkins jenkins      20 Apr  8 13:32 libblkid.so -> /lib64/libblkid.so.1
-r--r--r-- 1 jenkins jenkins   48488 Apr  8 13:32 libcom_err.a
lrwxrwxrwx 1 jenkins jenkins      22 Apr  8 13:32 libcom_err.so -> /lib64/libcom_err.so.2
-r--r--r-- 1 jenkins jenkins  258568 Apr  8 13:32 libe2p.a
lrwxrwxrwx 1 jenkins jenkins      18 Apr  8 13:32 libe2p.so -> /lib64/libe2p.so.2
-r--r--r-- 1 jenkins jenkins 2205314 Apr  8 13:32 libext2fs.a
lrwxrwxrwx 1 jenkins jenkins      21 Apr  8 13:32 libext2fs.so -> /lib64/libext2fs.so.2
-r--r--r-- 1 jenkins jenkins  185240 Apr  8 13:32 libss.a
lrwxrwxrwx 1 jenkins jenkins      17 Apr  8 13:32 libss.so -> /lib64/libss.so.2
-r--r--r-- 1 jenkins jenkins  106908 Apr  8 13:32 libuuid.a
lrwxrwxrwx 1 jenkins jenkins      19 Apr  8 13:32 libuuid.so -> /lib64/libuuid.so.1
drwxr-xr-x 2 jenkins jenkins    4096 Apr  8 13:32 pkgconfig

We can see that this is likely due to the lack of write permissions on the file. IMHO, /usr/lib/rpm/redhat/brp-strip-static-archive should deal with that, temporarily adding write permission or using a temporary file. I suppose seeing how e2fsprogs is packaged natively on rhel6 might be educational in resolving this issue in our own packaging.

Comments

[Michael MacDonald (Inactive)]

We really should be using the vendor packaging methodology for such a critical piece of the system. Our packages should be drop-in replacements for the vendor packages. If we need to maintain separate .spec files for each platform, then that is probably the lesser evil compared to trying to write some wickedly complex common specfile that sort-of works across the various rhel/sles flavors.

[Brian Murrell (Inactive)]

Mike, I completely agree, which is why I laid the groundwork for this to happen and even provided an example of how that groundwork can be used by doing the work for one of the SLESes (10 or 11, I don't recall). Unfortunately since then, nobody who has been maintaining e2fsprogs has taken the ball and did the same for our other supported distros.

It's too bad at the time I did that work that our itch was SLES and not RHEL or we'd have at least RHEL using vendor building.

All of this "not using the vendor spec" is what is leading to LU-113 also.

[Andreas Dilger]

I believe this is a duplicate of LU-133. Once we no longer try to build/install the "split" libraries of e2fsprogs (now packaged as part of util-linuxNG) this problem should disappear.

[Brian Murrell (Inactive)]

I believe this is a duplicate of LU-133

I can't seem to find an LU-133.