Re: [gentoo-portage-dev] [PATCH gentoolkit 1/2] eclean: Rewrite findPackages()
On 21/02/20 05:29, Matt Turner wrote: > I found the original code to be nearly incomprehensible. Instead of > populating a dict of potential binpkgs to remove and then removing from > the to-be-removed list, just selectively add to-be-removed packages. > > Signed-off-by: Matt Turner > --- > I switched from tabs to spaces in the process. I can revert back if > desired. > Probably best to stick to tabs for consistency with the other portage code, although naturally Zac probably better to ACK/NACK that. Otherwise I think this is a good refresh. +1. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] Add QA check for unresolved soname dependencies (bug 704320)
On 06/01/20 06:38, Zac Medico wrote:
> Example output for maven-bin-3.6.2 (bug 704618):
>
> * QA Notice: Unresolved soname dependencies:
> *
> */usr/share/maven-bin-3.6/lib/jansi-native/freebsd32/libjansi.so:
> libc.so.7 libutil.so.9
> */usr/share/maven-bin-3.6/lib/jansi-native/freebsd64/libjansi.so:
> libc.so.7 libutil.so.9
> *
>
> This warning comes up when a library or executable has one or
> more soname dependencies (found in its NEEDED.ELF.2 metadata)
> that could not be resolved by usual means. If you run ldd
> on files like these then it will report a "not found" error
> for each unresolved soname dependency. In order to correct
> problems with soname dependency resolution, use one or more
> of the approaches described in the following sections.
>
> Content of the NEEDED.ELF.2 metadata file may be useful
> for debugging purposes. Find the NEEDED.ELF.2 file in the
> ${D}/../build-info/ directory after the ebuild src_install
> phase completes, or in the /var/db/pkg/*/*/ directory for an
> installed package. Each line of the NEEDED.ELF.2 file contains
> semicolon separated values for a single ELF file. The soname
> dependencies are found in the DT_NEEDED column:
>
> E_MACHINE;path;DT_SONAME;DT_RUNPATH;DT_NEEDED;multilib category
>
> External dependencies
>
> For packages that install pre-built binaries, it may be possible
> to resolve soname dependencies simply by adding dependencies
> for one or more other packages that are known to provide the
> needed sonames.
>
> Removal of unecessary files
>
> For packages that install pre-built binaries, it may be possible
> to resolve soname dependencies simply by removing unnecessary
> files which have unresolved soname dependencies. For example,
> some pre-built binary packages include binaries intended for
> irrelevant architectures or operating systems, and these files
> can simply be removed because they are unnecessary.
>
> Addition of DT_RUNPATH entries
>
> If the relevant dependencies are installed in a location that
> is not included in the dynamic linker search path, then it's
> necessary for files to include a DT_RUNPATH entry which refers
> to the appropriate directory. The special $ORIGIN value can
> be used to create a relative path reference in DT_RUNPATH,
> where $ORIGIN is a placeholder for the directory where the
> file having the DT_RUNPATH entry is located.
>
> For pre-built binaries, it may be necessary to fix up
> DT_RUNPATH using patchelf --set-rpath. For example, use
> patchelf --set-rpath '$ORIGIN' if a given binary should link
> to libraries found in the same directory as the binary itself,
> or use patchelf --set-rpath '$ORIGIN/libs' if a given binary
> should link to libraries found in a subdirectory named libs
> found in the same directory as the binary itself.
>
> For binaries built from source, a flag like
> -Wl,-rpath,/path/of/directory/containing/libs will create
> binaries with the desired DT_RUNPATH entry.
>
> Bug: https://bugs.gentoo.org/704320
> Signed-off-by: Zac Medico
> ---
Looks awesome!
One comment: would it be helpful for developers/maintainers to have some
indication of what's going on here, and what attempts portage is making in
this regard? Something like a 'verbose' option that would spit out some
debugging info so that /if/ something goes wrong, or the outcome wasn't
what was intended, then this can be picked up and corrected somehow else?
I think automation is great for picking these issues up, and shining a
light on where/why something goes wrong, but sometimes it needs a few
minutes of human intervention to achieve the sane outcome in many
circumstances.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH gentoolkit 1/2] eclean: Fix typos
On 02/01/20 18:57, Matt Turner wrote:
> Signed-off-by: Matt Turner
> ---
> pym/gentoolkit/eclean/cli.py| 4 ++--
> pym/gentoolkit/eclean/search.py | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/pym/gentoolkit/eclean/cli.py b/pym/gentoolkit/eclean/cli.py
> index 1d2f52b..1a99b3e 100644
> --- a/pym/gentoolkit/eclean/cli.py
> +++ b/pym/gentoolkit/eclean/cli.py
> @@ -304,7 +304,7 @@ def parseArgs(options={}):
> options['size-limit'] = 0
> options['verbose'] = False
> options['ignore-failure'] = False
> - # if called by a well-named symlink, set the acction accordingly:
> + # if called by a well-named symlink, set the action accordingly:
> action = None
> # temp print line to ensure it is the svn/branch code running, etc..
> #print( "## svn/branch/gentoolkit_eclean ### ==> ",
> os.path.basename(sys.argv[0]))
> @@ -400,7 +400,7 @@ def doAction(action,options,exclude={}, output=None):
> )
>
> # initialize our cleaner
> - cleaner = CleanUp( output.progress_controller)
> + cleaner = CleanUp(output.progress_controller)
>
> # actually clean files if something was found
> if clean_me:
> diff --git a/pym/gentoolkit/eclean/search.py b/pym/gentoolkit/eclean/search.py
> index ce455a3..58bd97e 100644
> --- a/pym/gentoolkit/eclean/search.py
> +++ b/pym/gentoolkit/eclean/search.py
> @@ -574,7 +574,7 @@ def findPackages(
> del clean_me[cpv]
> continue
> if portage.cpv_getkey(cpv) in cp_all and
> port_dbapi.cpv_exists(cpv):
> - # exlusion because of --package-names
> + # exclusion because of --package-names
> del clean_me[cpv]
>
> # the getname method correctly supports FEATURES=binpkg-multi-instance,
LGTM fwiw.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Build path abi missing in qemu-user
On 18/12/19 17:36, Joakim Tjernlund wrote: > On Wed, 2019-12-18 at 11:22 -0500, Mike Gilbert wrote: >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you recognize the sender and know the >> content is safe. >> >> >> On Thu, Dec 12, 2019 at 10:18 AM Joakim Tjernlund >> wrote: >>> When build in a qemu-user chroot I get odd build paths: >>> /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc >>> >>> This path is missing the abi_ppc_32 like so: >>> >>> /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-abi_ppc_32.ppc >>> >>> I struggle to find out why this happens, any ideas? >> I would guess you are using a profile that doesn't define the ABI_PPC >> USE_EXPAND variable properly. >> > # portageq envvar USE_EXPAND > ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS > CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 CROSSCOMPILE_OPTS > CURL_SSL DRACUT_MODULES > DVB_CARDS ELIBC ENLIGHTENMENT_MODULES FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES > FRITZCAPI_CARDS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL > LCD_DEVICES LIBREOFFICE_EXTENSIONS > LINGUAS LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP > NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS > OPENMPI_OFED_FEATURES OPENMPI_RM > PHP_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS > QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND > UWSGI_PLUGINS VIDEO_CARDS > VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS > cu3-jocke fs # portageq envvar ABI_PPC > 32 > cu3-jocke fs # eselect profile list > Available profile symlink targets: > [1] default/linux/powerpc/ppc32/13.0 > [2] default/linux/powerpc/ppc32/13.0/desktop > [3] default/linux/powerpc/ppc32/13.0/desktop/gnome > [4] default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd > [5] default/linux/powerpc/ppc32/13.0/desktop/kde > [6] default/linux/powerpc/ppc32/13.0/desktop/kde/systemd > [7] default/linux/powerpc/ppc32/13.0/developer > [8] default/linux/powerpc/ppc64/13.0/32bit-userland > [9] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop > [10] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome > [11] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd > [12] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde > [13] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd > [14] default/linux/powerpc/ppc64/13.0/32bit-userland/developer > [15] hardened/linux/powerpc/ppc32 > [16] hardened/linux/powerpc/ppc64/32bit-userland > [17] hardened/linux/musl/ppc > [18] default/linux/uclibc/ppc > [19] hardened/linux/uclibc/ppc > [20] tmv3-target-overlay:cusfpv3 * > > cusfpv3 inherits default/linux/powerpc/ppc32/13.0 > > Jocke > Haven't 13.0 profiles been deprecated? (and/or deleted by now ...) signature.asc Description: OpenPGP digital signature
[gentoo-portage-dev] RFC: [QA] notice with 'failed' seds [was PATCH: eapply drop -s option]
On 13/12/19 20:36, Michał Górny wrote [excerpted]: > > Is this really an argument for or *against* it? Developers are entirely > capable of keeping seds that do nothing for years, as well as patches > that -- while apparently applying correctly -- are entirely meaningless. I think there is some merit in some kind of feedback when sed's are doing nothing, although how feasible it is to generate any useful feedback I can't say. I wouldn't say it needs to explicitly fail or make lots of noise, just an info message that could prompt some further investigation. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On 13/12/19 21:59, Michał Górny wrote: > On Fri, 2019-12-13 at 21:56 +0000, Michael 'veremitz' Everitt wrote: >> On 13/12/19 21:42, Michał Górny wrote: >>> On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: >>>> On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: >>>>> Just like 'many of the proposals lately', developers are going to be >>>>> the ones disabling it (because they don't care), and users will be the >>>>> ones enabling it (because they do care), just to learn that developers >>>>> don't care and go complaining to the mailing lists that users dare >>>>> report issues they don't care about. >>>> I care if the patch is actually broken, which the warning doesn't >>>> really tell me. It's just not a very reliable indicator, and will >>>> produce false-positives frequently. >>>> >>> You can also take less context into the patch and use -F0. Then you'll >>> have the same effect, no warnings to bother you and no pretending that >>> the patch applies when it doesn't. >>> >> Is there any mileage in having a similar scheme to which we already apply >> '-p' increments to the -F variable? >> eg. >> 1) attempt patch with -F0 >> 2) if (1) fails, attempt with -F2/3 & display 'yellow' warning & QA notice > That is precisely what my patch does and what people are complaining > about. Ah, apologies for the failure to grok. Tangentially, but also brought up on the thread, I'm actually even moderately concerned about the ghost seds that may never apply. Topic for another thread though I feel. >> 3) if (2) fails, attempt with, say, -F10 & display big fat 'red' warning >> and QA notice > That makes no sense as it exceeds context provided in most patches. > Fair .. hadn't thought of that - depends very much if you're using unified diffs, which I believe we largely are. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.
On 13/12/19 21:42, Michał Górny wrote: > On Fri, 2019-12-13 at 16:37 -0500, Mike Gilbert wrote: >> On Fri, Dec 13, 2019 at 3:36 PM Michał Górny wrote: >>> Just like 'many of the proposals lately', developers are going to be >>> the ones disabling it (because they don't care), and users will be the >>> ones enabling it (because they do care), just to learn that developers >>> don't care and go complaining to the mailing lists that users dare >>> report issues they don't care about. >> I care if the patch is actually broken, which the warning doesn't >> really tell me. It's just not a very reliable indicator, and will >> produce false-positives frequently. >> > You can also take less context into the patch and use -F0. Then you'll > have the same effect, no warnings to bother you and no pretending that > the patch applies when it doesn't. > Is there any mileage in having a similar scheme to which we already apply '-p' increments to the -F variable? eg. 1) attempt patch with -F0 2) if (1) fails, attempt with -F2/3 & display 'yellow' warning & QA notice 3) if (2) fails, attempt with, say, -F10 & display big fat 'red' warning and QA notice 4) Fail and abort Regards, veremitz/Michael. signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Re: seed emerge with old /var/db/pkg ?
On 13/11/19 19:07, Zac Medico wrote: > On 11/8/19 9:09 AM, Joakim Tjernlund wrote: >> On Fri, 2019-11-08 at 01:57 +0100, Joakim Tjernlund wrote: >>> I am looking for a way to seed emerge with an older pkg db so emerge can >>> calculate >>> which packages needs to be rebuild/upgraded in order to get to the same >>> state as the system pkg db, >>> Is that possible? >>> >>> Also, is there some tool that allows med to copy just files needed for a >>> profile? >>> Something like "cp" /etc/portage/make.profile /my/destination >>> >> portage-utils has variables Q_VDB and Q_EDB which allows qmerge to use >> different VDBs/EDBs >> Does portage have something similar? > No, nothing like either of those things. > > However, if you want to operate on an old system then the usual > recommendation is to unpack a stage3 and bind mount the old system root > into the stage3 so that you can chroot into the stage3 and run something > like this: > > emerge --root /mnt/old-system portage In the interests of clarity, what does this achieve, and what would the next couple of steps look like? (actual commands not necessary, pseudo-code WFM) signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH] install-qa-check.d: remove check that bans libtool files and static libs from /
On 03/11/19 21:37, Michał Górny wrote: > On Sun, 2019-11-03 at 15:26 -0600, William Hubbs wrote: >> >> You being a qa member doesn't have a lot to do with this mgorny. you >> know there was no official policy when I posted this, and as far as I >> know there is not one now. >> > That is a really poor argument. Something that's respected for 10+ > years and reported as QA violation is a standing policy as far as I'm > concerned. Just because it isn't backed by a formally stamped policy > (at least as far as we know -- maybe it was actually stamped somewhere > in the past?) doesn't mean you it's fine for one person to change it ad- > hoc because it stands in his way. > > I should point that I'm very concerned that you're pushing this forward > even though: > > 1) I've objected to the change itself, > > 2) I've pointed out that it's been sent to the wrong mailing list, > and that this explicitly prevents a number of developers from even > knowing that this is happening, > > 3) removing it provides a way for regressions that can have major impact > on users and that involve much effort in reverting that. > > So if I send a revert patch afterwards, and you object, should the patch > be accepted because only one person objected? > Children, please take this off-list ... signature.asc Description: OpenPGP digital signature
