Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 811462 - sys-apps/portage: fails to sometimes preserve library (libffi.so.7) (ImportError: libffi.so.7: cannot open shared object file: No such file or directory)
Summary: sys-apps/portage: fails to sometimes preserve library (libffi.so.7) (ImportEr...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: PullRequest
: 815874 (view as bug list)
Depends on: 815877
Blocks: preserve-libs 813756 813759
  Show dependency tree
 
Reported: 2021-09-03 02:31 UTC by Sam James
Modified: 2022-04-25 22:07 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
libffi-3.4.2-build.log (file_811462.txt,60.24 KB, text/plain)
2021-09-03 02:33 UTC, Sam James
Details
the critical part of the build.log with --debug after patch for preserve_libs.eclass applied (emerge_debug_libffi.txt,1.52 KB, text/plain)
2021-10-03 15:44 UTC, fkhp
Details
the patch (preserve-libs.eclass.patch,792 bytes, patch)
2021-10-03 16:09 UTC, fkhp
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-09-03 02:31:46 UTC
Portage doesn't preserve libffi.so.7 in some cases when upgrading dev-libs/libffi-3.3-r2 (0/7) -> dev-libs/libffi-3.4.2 (0/8).

I've seen reports of this sporadically but until now, it's been from users who have then immediately "fixed" the problem and have no backups to roll back to a pre-broken state in [0]. Fortunately, I've now got access to a case where we can reproduce it reliably thanks to some backups and well-timed snapshots.

In this case, FEATURES="preserved-libs" is definitely enabled which helps matters too (it's not always been clear in other reports).

This would be a valid bug anyway, but it's especially problematic given dev-lang/python depends on libffi and this causes both emerge and revdep-rebuild to be broken:
```
# emerge --info python
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.8/emerge", line 46, in <module>
    from _emerge.main import emerge_main
  File "/usr/lib/python3.8/site-packages/_emerge/main.py", line 21, in <module>
    from portage.sync import _SUBMODULE_PATH_MAP
  File "/usr/lib/python3.8/site-packages/portage/sync/__init__.py", line 9, in <module>
    from portage.sync.controller import SyncManager
  File "/usr/lib/python3.8/site-packages/portage/sync/controller.py", line 21, in <module>
    from portage.package.ebuild.doebuild import _check_temp_dir
  File "/usr/lib/python3.8/site-packages/portage/package/ebuild/doebuild.py", line 81, in <module>
    from portage.util.compression_probe import _compressors
  File "/usr/lib/python3.8/site-packages/portage/util/compression_probe.py", line 4, in <module>
    import ctypes
  File "/usr/lib/python3.8/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: libffi.so.7: cannot open shared object file: No such file or directory

```

Findings so far:
- The VDB is intact before and after the failure-to-preserve:
```
/var/db/pkg # egrep libffi */*/NEEDED.ELF.2
dev-lang/python-3.8.10/NEEDED.ELF.2:X86_64;/usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-x86_64-linux-gnu.so;_ctypes.cpython-38-x86_64-linux-gnu.so;;libffi.so.7,libdl.so.2,libpthread.so.0,libc.so.6;x86_64
dev-libs/glib-2.68.1/NEEDED.ELF.2:X86_64;/usr/lib64/libgobject-2.0.so.0.6800.1;libgobject-2.0.so.0;;libglib-2.0.so.0,libffi.so.7,libc.so.6;x86_64
dev-libs/glib-2.68.1/NEEDED.ELF.2:386;/usr/lib/libgobject-2.0.so.0.6800.1;libgobject-2.0.so.0;;libglib-2.0.so.0,libffi.so.7,libc.so.6;x86_32
dev-libs/libffi-3.4.2/NEEDED.ELF.2:X86_64;/usr/lib64/libffi.so.8.1.0;libffi.so.8;;libc.so.6;x86_64
dev-libs/libffi-3.4.2/NEEDED.ELF.2:386;/usr/lib/libffi.so.8.1.0;libffi.so.8;;libc.so.6;x86_32
dev-libs/libffi-3.4.2/NEEDED.ELF.2:X86_64;/usr/lib/debug/usr/lib64/libffi.so.8.1.0.debug;libffi.so.8.1.0.debug;;;x86_64
dev-libs/libffi-3.4.2/NEEDED.ELF.2:386;/usr/lib/debug/usr/lib/libffi.so.8.1.0.debug;libffi.so.8.1.0.debug;;;x86_32
dev-python/cffi-1.14.5/NEEDED.ELF.2:X86_64;/usr/lib/python3.8/site-packages/_cffi_backend.cpython-38-x86_64-linux-gnu.so;_cffi_backend.cpython-38-x86_64-linux-gnu.so;;libffi.so.7,libc.so.6,ld-linux-x86-64.so.2;x86_64
```

(I'd previously speculated it was related to e.g. glibc upgrade and pax-utils being unable to correctly populate NEEDED and it being in a corrupted state)

- preserve-libs is working for other packages during this time, as libcrypt is preserved when going through
the libxcrypt migration.

[0] https://marc.info/?l=gentoo-user&m=162943441928898&w=4
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-09-03 02:33:09 UTC
Created attachment 737203 [details]
libffi-3.4.2-build.log
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-09-03 02:35:08 UTC
(In reply to Sam James from comment #1)
> Created attachment 737203 [details]
> libffi-3.4.2-build.log

We can see that Portage unmerges and doesn't think .so.7 is needed:
>--- replaced obj /usr/lib64/libffi/include/ffitarget.h
>--- replaced obj /usr/lib64/libffi/include/ffi.h
>--- replaced dir /usr/lib64/libffi/include
><<<          obj /usr/lib64/libffi.so.7.1.0
><<<          sym /usr/lib64/libffi.so.7
>--- replaced sym /usr/lib64/libffi.so
>--- replaced dir /usr/lib64/libffi

The expected (and normal) output is something like:
>--- replaced obj /usr/lib64/libffi/include/ffitarget.h
>--- replaced obj /usr/lib64/libffi/include/ffi.h
>--- replaced dir /usr/lib64/libffi/include
>>>> needed   sym /usr/lib64/libffi.so.7
>>>> needed   obj /usr/lib64/libffi.so.7.1.0
>--- replaced sym /usr/lib64/libffi.so
>--- replaced dir /usr/lib64/libffi
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-09-03 02:38:47 UTC
[Blocking libxcrypt migration because I'm not comfortable proceeding with unleashing it onto stable users until we've figured out whatever issue is going on with preserve-libs.]

Additional notes:
- Using a stage3 from 2021-05-02 [0] and a Portage snapshot from the same day [1] (emulating the state of the original box which hit this) wasn't enough to reproduce. The original box was ~arch so I upgraded to that too (using the same tree snapshot).

- Using a set of binpkgs from the broken box on top of ^^ does reproduce it, but no idea which trigger it yet.

[0] https://mirror.reenigne.net/gentoo-snapshots/2021-05-20-0600/releases/amd64/autobuilds/20210502T214503Z/hardened/stage3-amd64-hardened-20210502T214503Z.tar.xz
[1] https://mirror.reenigne.net/gentoo-snapshots/2021-05-02-0600/snapshots/gentoo-20210501.tar.xz
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-09-04 02:24:53 UTC
With a ridiculous number of print()s, I've at least identified where things go wrong (but it's kind of obvious, I guess) [0]:

>objs = set([obj])
>obj_key = self._obj_key(obj)
>if obj_key not in self._obj_properties:
>	raise KeyError("%s (%s) not in object list" % >(obj_key, obj))

Currently trying to understand the _ObjectKey [1] and self._obj_properties structures (although I'm not really getting the later yet).

Note that I mentioned in #gentoo-toolchain previously that this wasn't reproducible with a standalone emerge -v1O libffi, but it is (at least now). I've currently got a snapshot of the chroot which I can revert back to before upgrading libffi, upgrade libffi, then it breaks.

Further avenues that could be taken:
- Obviously try to figure out why self.obj_properties doesn't end up containing libffi.so.7 or w/e.
- Try with/without each binpkg from the contaminated/broken host;
- See if this still occurs after rebuilding world (twice? to avoid contamination).

Note that bug 521968 touches the same exception but it's probably not relevant?

Bit stuck for now.

[0] https://github.com/gentoo/portage/blob/5ec443ed7dab583f3c654ee81fff563cbda5a9d4/lib/portage/util/_dyn_libs/LinkageMapELF.py#L857
[1] https://github.com/gentoo/portage/blob/5ec443ed7dab583f3c654ee81fff563cbda5a9d4/lib/portage/util/_dyn_libs/LinkageMapELF.py#L104
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-09-04 07:52:23 UTC
1. check if you have any bundled copy of libffi on your system, i.e.:

   find / -name 'libffi.so*'

2. grep vardb for libffi:

   grep -R libffi.so /var/db/pkg

Not saying you should paste the latter, just analyze its output for libffi.so.7 vs libffi.so.8.
Comment 6 Larry the Git Cow gentoo-dev 2021-09-05 05:48:30 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9860542af9f167452bb551237115e2100d87c7b

commit e9860542af9f167452bb551237115e2100d87c7b
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-09-05 05:32:14 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-09-05 05:47:48 +0000

    app-misc/pax-utils: add note to adjust glibc ebuild on bumps
    
    If we're bumping pax-utils to add new syscalls/reflect changing
    syscalls used by glibc, we need to make sure to update the glibc
    ebuild too to ensure the right version is used and avoid
    possible VDB corruption (e.g. when Portage calls scanelf).
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 app-misc/pax-utils/pax-utils-1.3.3.ebuild | 3 +++
 1 file changed, 3 insertions(+)

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dc67add1a5356531eaaec698807661461abc27e4

commit dc67add1a5356531eaaec698807661461abc27e4
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-09-05 05:28:55 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-09-05 05:47:47 +0000

    sys-libs/glibc: add comment on bumping pax-utils bound
    
    It's important that we remember to do this when bumping
    glibc releases. Added a comment as a reminder and used
    a variable so that both uses are consistent within *DEPEND.
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/glibc/glibc-2.34.ebuild |  7 +++++--
 sys-libs/glibc/glibc-9999.ebuild | 11 +++++++----
 2 files changed, 12 insertions(+), 6 deletions(-)
Comment 7 Larry the Git Cow gentoo-dev 2021-09-08 23:48:15 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1ee6e5850273f238a83f71426d60f08c48d32659

commit 1ee6e5850273f238a83f71426d60f08c48d32659
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-09-08 23:47:24 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-09-08 23:48:07 +0000

    sys-libs/glibc: add comment referencing wiki page
    
    .. to refer to a list of things to do when bumping
    glibc.
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-libs/glibc/glibc-2.34.ebuild | 3 +++
 sys-libs/glibc/glibc-9999.ebuild | 3 +++
 2 files changed, 6 insertions(+)
Comment 8 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-09-08 23:50:03 UTC
Fairly sure at this point that it's caused by scanelf corrupting the VDB. Working on Portage patches now.

Also looking at somewhat of a recovery tool to detect (and correct?) such situations if you're already a victim.

(In reply to Sam James from comment #0)
> [...]
> (I'd previously speculated it was related to e.g. glibc upgrade and
> pax-utils being unable to correctly populate NEEDED and it being in a
> corrupted state)
> 

Lesson learned: double check the data. emerge.log from a few victim boxes showed the timeline matches (glibc, (many packages), pax-utils). Packages in-between have a corrupt VDB.
Comment 9 Larry the Git Cow gentoo-dev 2021-09-12 23:19:21 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e90110a0a63cb9177bb529d61b3a70f9797b82d6

commit e90110a0a63cb9177bb529d61b3a70f9797b82d6
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-09-08 21:55:12 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-09-12 23:19:01 +0000

    dev-libs/libffi: use preserve-libs.eclass
    
    1. Revision bump to re-install libffi now that
       glibc definitely has the correct version bounds
       on pax-utils. See linked bug for more information.
    
       This is unrelated to the preserve-libs eclass change,
       but we figured we should do this just as a nudge
       to help people in a "damaged" situation (see bug).
    
    2. Use preserved-libs.eclass because SONAME of libffi
       changed from 7 -> 8. FEATURES="preserved-libs" (distinct from
       the eclass) is not required to be used (even if encouraged)
       and is not part of PMS, so alternative package managers
       to Portage don't have to implement it.
    
       Use the eclass to perserve libffi.so.7 to keep dev-lang/python
       working. Runtime failures will occur without Python being rebuilt
       in time.
    
       (Unfortunately, the same is true for the rewritten-in-Python
       revdep-rebuild, so revdep-rebuild.sh may help folks who are
       already bitten by this.)
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>
    Closes: https://github.com/gentoo/gentoo/pull/22247
    Signed-off-by: Sam James <sam@gentoo.org>

 .../{libffi-3.4.2.ebuild => libffi-3.4.2-r1.ebuild} | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)
Comment 10 Larry the Git Cow gentoo-dev 2021-09-20 21:11:25 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=987fa4cca49b3a230588fb785b606a6b0bb99ab6

commit 987fa4cca49b3a230588fb785b606a6b0bb99ab6
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-09-20 21:10:34 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-09-20 21:11:10 +0000

    app-portage/recover-broken-vdb: initial import
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 app-portage/recover-broken-vdb/metadata.xml        | 17 ++++++++++++++
 .../recover-broken-vdb-9999.ebuild                 | 27 ++++++++++++++++++++++
 2 files changed, 44 insertions(+)
Comment 11 Larry the Git Cow gentoo-dev 2021-09-21 17:27:49 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=83af7270fafbd7b1eed0031a5e06836ad1edf06d

commit 83af7270fafbd7b1eed0031a5e06836ad1edf06d
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-09-21 00:56:36 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-09-21 17:27:39 +0000

    bin/misc-function.sh: check scanelf return code
    
    This is part of a series of fixes for the linked bug (failure
    to preserve libraries in some situations).
    
    We need to check if scanelf failed when calling it in the
    installed-files QA check as we later use it to populate the VDB.
    
    Silently continuing results in either blank e.g. PROVIDES,
    NEEDED{,.ELF.2} or those files may be missing entirely,
    resulting in a corrupt state both on the system and in
    any generated binpkgs.
    
    Adds an escape variable (PORTAGE_NO_SCANELF_CHECK) to allow
    re-emerging pax-utils if it's broken.
    
    Bug: https://bugs.gentoo.org/811462
    See: https://github.com/gentoo/portage/pull/744
    Closes: https://github.com/gentoo/portage/pull/750
    Signed-off-by: Sam James <sam@gentoo.org>

 bin/misc-functions.sh | 64 ++++++++++++++++++++++++++++++++++++++++-----------
 1 file changed, 50 insertions(+), 14 deletions(-)
Comment 12 Larry the Git Cow gentoo-dev 2021-09-29 14:32:28 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=1a196bdef62565e377e90807b8b324547e7d4814

commit 1a196bdef62565e377e90807b8b324547e7d4814
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-09-20 21:13:21 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-09-29 14:32:18 +0000

    2021-09-24-possible-failure-to-preserve-libraries: add item
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Hank Leininger <hlein@korelogic.com>
    Signed-off-by: Sam James <sam@gentoo.org>

 ...9-possible-failure-to-preserve-libraries.en.txt | 101 +++++++++++++++++++++
 1 file changed, 101 insertions(+)
Comment 13 Gleb 2021-09-30 08:57:12 UTC
I tried to follow the guide, and `recover-broken-vdb` produces empty directory in /tmp, so I'm not sure how to proceed.

The output of recover-broken-vdb-find-broken.sh | tee broken_vdb_packages was this line:
=app-text/qpdfview-0.4.18
Comment 14 Ionen Wolkens gentoo-dev 2021-09-30 10:55:27 UTC
(In reply to Gleb from comment #13)
> I tried to follow the guide, and `recover-broken-vdb` produces empty
> directory in /tmp, so I'm not sure how to proceed.
> 
> The output of recover-broken-vdb-find-broken.sh | tee broken_vdb_packages
> was this line:
> =app-text/qpdfview-0.4.18
What version of recover-broken-vdb? Not very familiar with its issues yet but seen someone have a similar-sounding problem with 0.0.5 and upgrading to 0.0.7 fixed it.
Comment 15 Gleb 2021-09-30 13:22:43 UTC
(In reply to Ionen Wolkens from comment #14)
> What version of recover-broken-vdb? Not very familiar with its issues yet
> but seen someone have a similar-sounding problem with 0.0.5 and upgrading to
> 0.0.7 fixed it.
It was 0.0.5, I updated it to 0.0.7 and now this first command produces no output at all.
$ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages

So I suppose there's nothing to fix?
Comment 16 Ionen Wolkens gentoo-dev 2021-09-30 13:48:48 UTC
(In reply to Gleb from comment #15)
> It was 0.0.5, I updated it to 0.0.7 and now this first command produces no
> output at all.
> $ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages
> 
> So I suppose there's nothing to fix?
I assume there was still the "Checking installed..." status message, but yes. Can forget this tool and carry on with your non-broken Gentoo.
Comment 17 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-03 04:15:34 UTC
*** Bug 815874 has been marked as a duplicate of this bug. ***
Comment 18 fkhp 2021-10-03 15:20:12 UTC Comment hidden (obsolete)
Comment 19 fkhp 2021-10-03 15:23:29 UTC Comment hidden (obsolete)
Comment 20 fkhp 2021-10-03 15:34:35 UTC Comment hidden (obsolete)
Comment 21 fkhp 2021-10-03 15:44:15 UTC Comment hidden (obsolete)
Comment 22 fkhp 2021-10-03 16:09:55 UTC Comment hidden (obsolete)
Comment 23 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-03 19:25:31 UTC Comment hidden (obsolete)
Comment 24 Lukas Oliva 2021-10-05 17:08:11 UTC
Following the procedure in 2021-09-29-possible-failure-to-preserve-libraries, I believe that the step

$ emerge --ask --verbose --oneshot --usepkg=n $(cat broken_vdb_packages)

should be 

$ emerge --ask --verbose --oneshot --usepkg=n $(grep -v '#' broken_vdb_packages)

considering that the broken_vdb_packages file contains a comment in the beginning:

$ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages

# Checking installed packages for inconsistent VDB...
=app-admin/gnome-system-log-3.9.90
...
Comment 25 Larry the Git Cow gentoo-dev 2021-10-06 01:34:17 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=b799e9ed123d65d007fa6496e8b5c5ee4073efbd

commit b799e9ed123d65d007fa6496e8b5c5ee4073efbd
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-10-06 01:34:00 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-10-06 01:34:00 +0000

    2021-09-29-possible-failure-to-preserve-libraries: fix command for comment
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-09-29-possible-failure-to-preserve-libraries.en.txt            | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 26 Larry the Git Cow gentoo-dev 2021-10-28 04:52:37 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=216e962ae494e8291b667665007d045788b3e391

commit 216e962ae494e8291b667665007d045788b3e391
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-10-28 04:40:09 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-10-28 04:52:32 +0000

    Binpkg.py: check for inconsistent PROVIDES/image when unpacking binpkg
    
    This is part of a series of fixes for the linked bug (failure
    to preserve libraries in some situations).
    
    When unpacking a binpkg to be installed, we should check
    for the existence of PROVIDES if we're installing any
    dynamic libraries. If PROVIDES does not exist in that case,
    this suggests that e.g. scanelf malfunctioned or some corruption occurred.
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 lib/_emerge/Binpkg.py | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

https://gitweb.gentoo.org/proj/portage.git/commit/?id=98a8a4af2c77477c327b22621b8a0aed6d15f574

commit 98a8a4af2c77477c327b22621b8a0aed6d15f574
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-10-28 04:40:09 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-10-28 04:52:22 +0000

    doebuild.py: check for inconsistent PROVIDES/image post-src_install
    
    This is part of a series of fixes for the linked bug (failure
    to preserve libraries in some situations).
    
    At the point of installation (even if not merging), we need
    to detect inconsistent metadata: PROVIDES should be populated
    if we're installing any dynamic libraries. This suggests that
    e.g. scanelf malfunctioned or some corruption occurred.
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 lib/portage/package/ebuild/doebuild.py | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

https://gitweb.gentoo.org/proj/portage.git/commit/?id=cba2156dba89a22f2858238013469b4d80208854

commit cba2156dba89a22f2858238013469b4d80208854
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-10-28 04:40:09 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-10-28 04:52:18 +0000

    portage/util/_dyn_libs/dyn_libs.py: add helper
    
    Needed for binpkg/image verification commits coming...
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 lib/portage/util/_dyn_libs/dyn_libs.py | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
Comment 27 Andreas K. Hüttel archtester gentoo-dev 2021-10-30 15:53:35 UTC
I guess we've done enough here so the libxcrypt transition can go stable. Not blocking anymore.
Comment 28 Larry the Git Cow gentoo-dev 2021-11-22 06:32:04 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=ef0cfc2c0e68299ddfa355732c76cf7d9ed83fcb

commit ef0cfc2c0e68299ddfa355732c76cf7d9ed83fcb
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-11-22 06:30:45 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-11-22 06:31:58 +0000

    2021-09-29-possible-failure-to-preserve-libraries: mention when it's ok to skip -e
    
    It should be okay to skip -e @world and instead only rebuild libraries +
    their consumers in some cases.
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 .../2021-09-29-possible-failure-to-preserve-libraries.en.txt       | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
Comment 29 Larry the Git Cow gentoo-dev 2021-12-11 02:54:08 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=c36f878509108c970907dc391d6562297881b400

commit c36f878509108c970907dc391d6562297881b400
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-12-11 02:47:50 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-12-11 02:54:00 +0000

    lib/portage/package/ebuild/doebuild.py: use 'eerror' for blank PROVIDES message
    
    This means that it's much harder to miss the error.
    
    Bug: https://bugs.gentoo.org/811462
    Reported-by: Brian Dolbec <dolsen@gentoo.org>
    Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
    Signed-off-by: Sam James <sam@gentoo.org>

 lib/portage/package/ebuild/doebuild.py | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)
Comment 30 Larry the Git Cow gentoo-dev 2021-12-14 05:26:29 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=36d5f8de514f2b0ff95ccaf75c60e87441f8c009

commit 36d5f8de514f2b0ff95ccaf75c60e87441f8c009
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2021-12-14 05:26:05 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2021-12-14 05:26:05 +0000

    profiles: add pax-utils to info_pkgs
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 profiles/info_pkgs | 1 +
 1 file changed, 1 insertion(+)
Comment 31 Larry the Git Cow gentoo-dev 2022-01-04 12:18:19 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b33da36a7d896d504132b20b4ef0232fbd0b880f

commit b33da36a7d896d504132b20b4ef0232fbd0b880f
Author:     Sam James <sam@gentoo.org>
AuthorDate: 2022-01-04 12:17:09 +0000
Commit:     Sam James <sam@gentoo.org>
CommitDate: 2022-01-04 12:18:04 +0000

    sys-apps/portage: add file PDEPEND (partly for seccomp)
    
    We use it in QA checks / postinst bits for NEEDED and such for
    a start, but we also need a minimum good version to
    avoid "bad system call" errors with e.g. newer glibc.
    
    Bug: https://bugs.gentoo.org/811462
    Signed-off-by: Sam James <sam@gentoo.org>

 sys-apps/portage/portage-3.0.18.ebuild    | 1 +
 sys-apps/portage/portage-3.0.20-r6.ebuild | 1 +
 sys-apps/portage/portage-3.0.28-r1.ebuild | 1 +
 sys-apps/portage/portage-3.0.29.ebuild    | 1 +
 sys-apps/portage/portage-3.0.30-r1.ebuild | 1 +
 sys-apps/portage/portage-9999.ebuild      | 1 +
 6 files changed, 6 insertions(+)
Comment 32 Andreas K. Hüttel archtester gentoo-dev 2022-04-25 22:07:23 UTC
We should be able to close this now.