Bug 2080454

Summary: plugin directory not owned by annobin-plugin-gcc on Fedora 36
Product: [Fedora] Fedora Reporter: Andreas Vögele <andreas>
Component: annobinAssignee: Nick Clifton <nickc>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 36CC: fweimer, jakub, nickc, sipoyare, yahmad
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: annobin-10.76-3.fc36 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-01-16 17:58:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andreas Vögele 2022-04-29 16:48:42 UTC
Description of problem:

I get the error message below when I build packages for Fedora 36 with the Open Build Service:

  cc1: fatal error: inaccessible plugin file plugin/annobin.so expanded from short plugin name annobin: No such file or directory

The problem is that the "plugin" directory is not readable in the OBS build environment:

  $ ls -ld /usr/lib/gcc/x86_64-redhat-linux/12/plugin
  drwx------. 2 root root 4096 Apr 29 12:14 /usr/lib/gcc/x86_64-redhat-linux/12/plugin

On Fedora 35, the "plugin" directory belongs to the annobin-plugin-gcc package and is readable:

  $ rpm -q --whatprovides /usr/lib/gcc/x86_64-redhat-linux/11/plugin
  annobin-plugin-gcc-10.66-2.fc35.x86_64
  $ rpm -qlv annobin-plugin-gcc | grep 'plugin$'
  drwxr-xr-x 2 root root 0 Apr 23 22:13 /usr/lib/gcc/x86_64-redhat-linux/11/plugin

On Fedora 36, only the files in the "plugin" directory are owned by the annobin-plugin-gcc package. The directory itself is not owned:

  $ rpm -q --whatprovides /usr/lib/gcc/x86_64-redhat-linux/12/plugin
  file /usr/lib/gcc/x86_64-redhat-linux/12/plugin is not owned by any package

I cannot reproduce the problem with mock, though:

  $ mock -r fedora-36-x86_64 -i annobin-plugin-gcc
  $ ls -ld /var/lib/mock/fedora-36-x86_64/root/usr/lib/gcc/x86_64-redhat-linux/12/plugin
  drwxr-xr-x. 2 root root 4096 29. Apr 15:57 /var/lib/mock/fedora-36-x86_64/root/usr/lib/gcc/x86_64-redhat-linux/12/plugin

So this problem might be caused by an rpm or umask setting specific to OBS. But as far as I can see there's nothing that I can do about this in the OBS settings.

Version-Release number of selected component (if applicable):
annobin-plugin-gcc-10.66-2.fc36.x86_64

How reproducible:
Always in OBS when packages are built with GCC for Fedora 36

Steps to Reproduce:
1. Optionally create a test environment with Fedora 36.
mkdir fedora
cd fedora
vagrant init generic/fedora35
vagrant up
vagrant ssh
sudo dnf install -y dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=36
sudo dnf system-upgrade reboot
# Monitor the progress with a VNC viewer
vagrant ssh

2. Register an account at https://build.opensuse.org/
It seems that you cannot checkout projects without an OBS account.

3. Build an OBS project,
sudo dnf install osc
mkdir obs
cd obs
osc co "home:voegelas" perl-IP-Geolocation-MMDB
cd "home:voegelas/perl-IP-Geolocation-MMDB"
osc build --no-verify Fedora_36
ls -ld /var/tmp/build-root/Fedora_36-x86_64/usr/lib/gcc/x86_64-redhat-linux/12/plugin

The problem is not specific to Perl. But Perl outputs the error message directly to the console instead of a config.log file.

Actual results:
drwx------. 2 root root 103 Apr 29 15:50 /var/tmp/build-root/Fedora_36-x86_64/usr/lib/gcc/x86_64-redhat-linux/12/plugin

Expected results:
drwxr-xr-x. 2 root root 103 Apr 29 15:50 /var/tmp/build-root/Fedora_36-x86_64/usr/lib/gcc/x86_64-redhat-linux/12/plugin

Additional info:
Package list on Fedora 35:
   $ rpm -qlv annobin-plugin-gcc-10.66-2.fc35.x86_64
   drwxr-xr-x 2 root root     0 Apr 23 22:13 /usr/lib/.build-id
   drwxr-xr-x 2 root root     0 Apr 23 22:13 /usr/lib/.build-id/7f
   lrwxrwxrwx 1 root root    70 Apr 23 22:13 /usr/lib/.build-id/7f/fa887d6964d17f67bd783bbcba5af77263c5a0 -> [...]
=> drwxr-xr-x 2 root root     0 Apr 23 22:13 /usr/lib/gcc/x86_64-redhat-linux/11/plugin
   lrwxrwxrwx 1 root root    16 Apr 23 22:13 /usr/lib/gcc/x86_64-redhat-linux/11/plugin/annobin.so -> annobin.so.0.0.0
   lrwxrwxrwx 1 root root    16 Apr 23 22:13 /usr/lib/gcc/x86_64-redhat-linux/11/plugin/annobin.so.0 -> annobin.so.0.0.0
   -rwxr-xr-x 1 root root 53392 Apr 23 22:13 /usr/lib/gcc/x86_64-redhat-linux/11/plugin/annobin.so.0.0.0

Package list on Fedora 36:
   $ rpm -qlv annobin-plugin-gcc-10.66-2.fc36.x86_64
   drwxr-xr-x 2 root root      0 Apr 15 09:22 /usr/lib/.build-id
   drwxr-xr-x 2 root root      0 Apr 15 09:22 /usr/lib/.build-id/ca
   lrwxrwxrwx 1 root root     70 Apr 15 09:22 /usr/lib/.build-id/ca/51bf3646a60e3687cb4b3e681f51a6254cdc57 -> [...]
   -rw-r--r-- 1 root root     28 Apr 15 09:22 /usr/lib/gcc/x86_64-redhat-linux/12/plugin/annobin-plugin-version-info
   lrwxrwxrwx 1 root root     16 Apr 15 09:22 /usr/lib/gcc/x86_64-redhat-linux/12/plugin/annobin.so -> annobin.so.0.0.0
   lrwxrwxrwx 1 root root     16 Apr 15 09:22 /usr/lib/gcc/x86_64-redhat-linux/12/plugin/annobin.so.0 -> annobin.so.0.0.0
   -rwxr-xr-x 1 root root  53392 Apr 15 09:22 /usr/lib/gcc/x86_64-redhat-linux/12/plugin/annobin.so.0.0.0
   -rw-r--r-- 1 root root 850064 Apr 15 09:22 /usr/src/annobin/latest-annobin.tar.xz

Comment 1 Nick Clifton 2022-05-03 11:19:26 UTC
(In reply to Andreas Vögele from comment #0)

> On Fedora 35, the "plugin" directory belongs to the annobin-plugin-gcc
> package and is readable:
 
> On Fedora 36, only the files in the "plugin" directory are owned by the
> annobin-plugin-gcc package. The directory itself is not owned:

Can more than one package own a directory ?  I was under the impression that they could not.

The issue is that, starting with F36, the ownership of the plugin directory has changed from annobin to gcc.  This is because a) it is where gcc looks for all of its plugins, not just annobin, so it makes sense that gcc should own it, and b) gcc now has the ability to build its own version of the annobin plugin, which it stores in the plugin directory.

Comment 2 Andreas Vögele 2022-06-29 07:55:56 UTC
(In reply to Nick Clifton from comment #1)
> (In reply to Andreas Vögele from comment #0)
> 
> > On Fedora 35, the "plugin" directory belongs to the annobin-plugin-gcc
> > package and is readable:
>  
> > On Fedora 36, only the files in the "plugin" directory are owned by the
> > annobin-plugin-gcc package. The directory itself is not owned:
> 
> Can more than one package own a directory ?  I was under the impression that
> they could not.
> 
> The issue is that, starting with F36, the ownership of the plugin directory
> has changed from annobin to gcc.  This is because a) it is where gcc looks
> for all of its plugins, not just annobin, so it makes sense that gcc should
> own it, and b) gcc now has the ability to build its own version of the
> annobin plugin, which it stores in the plugin directory.

But the gcc package doesn't own the plugin directory: rpm -qlv gcc | grep 'plugin$'

I've created a dummy package that owns the directory and gets preinstalled by my OBS project configuration.

Comment 3 Nick Clifton 2022-06-29 16:48:43 UTC
Hi Andreas,

  Right, it looks like the spec file's %dir directive can be used to indicate that
  an rpm uses a directory without necessarily requiring exclusive ownership.  So
  please could you try annobin-10.76-3.fc36 which I hope will solve the problem.

Cheers
  Nick

PS. I cannot build the rawhide version of annobin at the moment because there is
  a PowerPC specific LLVM problem which is stopping ppc64le binaries from building...

PPS.  I have also created a f35 build and a Bodhi request to have these two builds
  pushed out.

Comment 4 Andreas Vögele 2022-06-30 13:26:16 UTC
The %dir directive solves the problem. But I realized that the plugin directory is now owned by the gcc-plugin-annobin package on Fedora 36, which is pulled in by redhat-rpm-config together with annobin-plugin-gcc. Thus the plugin directory will now have the proper permissions anyway. I think that I got confused yesterday as the plugin directory still isn't owned under AlmaLinux 9. My dummy package solves the problem there.