Re: [gentoo-portage-dev] [PATCH 2/2] Binpkg.py: check for inconsistent PROVIDES/image when unpacking binpkg

2021-10-04 Thread Alec Warner
On Sat, Oct 2, 2021 at 1:11 PM Sam James  wrote:
>
> 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 
> ---
>  lib/_emerge/Binpkg.py | 28 +++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/lib/_emerge/Binpkg.py b/lib/_emerge/Binpkg.py
> index c7dde69bd..9b876f354 100644
> --- a/lib/_emerge/Binpkg.py
> +++ b/lib/_emerge/Binpkg.py
> @@ -2,7 +2,7 @@
>  # Distributed under the terms of the GNU General Public License v2
>
>  import functools
> -
> +import glob
>  import _emerge.emergelog
>  from _emerge.EbuildPhase import EbuildPhase
>  from _emerge.BinpkgFetcher import BinpkgFetcher
> @@ -13,6 +13,7 @@ from _emerge.EbuildMerge import EbuildMerge
>  from _emerge.EbuildBuildDir import EbuildBuildDir
>  from _emerge.SpawnProcess import SpawnProcess
>  from portage.eapi import eapi_exports_replace_vars
> +from portage.output import colorize
>  from portage.util import ensure_dirs
>  from portage.util._async.AsyncTaskFuture import AsyncTaskFuture
>  import portage
> @@ -425,6 +426,31 @@ class Binpkg(CompositeTask):
>  self._async_unlock_builddir(returncode=self.returncode)
>  return
>
> +# Before anything else, let's do an integrity check.
> +(provides,) = self._bintree.dbapi.aux_get(self.pkg.cpv, ["PROVIDES"])
> +if not provides:
> +# Let's check if we've got inconsistent results.
> +# If we're installing dynamic libraries (.so files), we should
> +# really have a PROVIDES.
> +# (This is a complementary check at the point of ingestion for 
> the
> +# creation check in doebuild.py)
> +# Note: we could check a non-empty PROVIDES against the list of 
> .sos,
> +# but this doesn't gain us anything. We're interested in failure
> +# to properly parse the installed files at all, which should 
> really
> +# be a global problem (e.g. bug #811462)
> +installed_dynlibs = glob.glob(
> +self.settings["D"] + "/**/*.so", recursive=True
> +)
> +if installed_dynlibs:
> +self._writemsg_level(
> +colorize(
> +"BAD",
> +"!!! Error! Installing dynamic libraries (.so) with 
> blank PROVIDES!",
> +),
> +noiselevel=-1,
> +level=logging.ERROR,
> +)
> +

Here you have written the same code (and long comment block) as the
last patch...I'd take that as an argument to extract it into a
function (check_provides or whatever) and not copy and paste the code
around.

-A

>  try:
>  with io.open(
>  _unicode_encode(
> --
> 2.33.0
>
>



[gentoo-portage-dev] [PATCH 2/2] Binpkg.py: check for inconsistent PROVIDES/image when unpacking binpkg

2021-10-02 Thread Sam James
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 
---
 lib/_emerge/Binpkg.py | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/lib/_emerge/Binpkg.py b/lib/_emerge/Binpkg.py
index c7dde69bd..9b876f354 100644
--- a/lib/_emerge/Binpkg.py
+++ b/lib/_emerge/Binpkg.py
@@ -2,7 +2,7 @@
 # Distributed under the terms of the GNU General Public License v2
 
 import functools
-
+import glob
 import _emerge.emergelog
 from _emerge.EbuildPhase import EbuildPhase
 from _emerge.BinpkgFetcher import BinpkgFetcher
@@ -13,6 +13,7 @@ from _emerge.EbuildMerge import EbuildMerge
 from _emerge.EbuildBuildDir import EbuildBuildDir
 from _emerge.SpawnProcess import SpawnProcess
 from portage.eapi import eapi_exports_replace_vars
+from portage.output import colorize
 from portage.util import ensure_dirs
 from portage.util._async.AsyncTaskFuture import AsyncTaskFuture
 import portage
@@ -425,6 +426,31 @@ class Binpkg(CompositeTask):
 self._async_unlock_builddir(returncode=self.returncode)
 return
 
+# Before anything else, let's do an integrity check.
+(provides,) = self._bintree.dbapi.aux_get(self.pkg.cpv, ["PROVIDES"])
+if not provides:
+# Let's check if we've got inconsistent results.
+# If we're installing dynamic libraries (.so files), we should
+# really have a PROVIDES.
+# (This is a complementary check at the point of ingestion for the
+# creation check in doebuild.py)
+# Note: we could check a non-empty PROVIDES against the list of 
.sos,
+# but this doesn't gain us anything. We're interested in failure
+# to properly parse the installed files at all, which should really
+# be a global problem (e.g. bug #811462)
+installed_dynlibs = glob.glob(
+self.settings["D"] + "/**/*.so", recursive=True
+)
+if installed_dynlibs:
+self._writemsg_level(
+colorize(
+"BAD",
+"!!! Error! Installing dynamic libraries (.so) with 
blank PROVIDES!",
+),
+noiselevel=-1,
+level=logging.ERROR,
+)
+
 try:
 with io.open(
 _unicode_encode(
-- 
2.33.0