[gentoo-portage-dev] [PATCH] _doebuild_path: Respect order defined in ROOTPATH (bug 667662)
Respect the order of paths defined in /etc/env.d/*, so that
packages like llvm can rely on ordering relative to paths
defined in /etc/env.d/50baselayout since baselayout-2.6.
See:
https://gitweb.gentoo.org/proj/baselayout.git/commit/?id=277e5b9e55717873b87eb541a95f4f2ae0c60a4d
Bug: https://bugs.gentoo.org/667662
Signed-off-by: Zac Medico
---
lib/portage/package/ebuild/doebuild.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/portage/package/ebuild/doebuild.py
b/lib/portage/package/ebuild/doebuild.py
index 941a597e2..621fe7360 100644
--- a/lib/portage/package/ebuild/doebuild.py
+++ b/lib/portage/package/ebuild/doebuild.py
@@ -212,6 +212,7 @@ def _doebuild_path(settings, eapi=None):
eprefix = portage.const.EPREFIX
prerootpath = [x for x in settings.get("PREROOTPATH", "").split(":") if
x]
rootpath = [x for x in settings.get("ROOTPATH", "").split(":") if x]
+ rootpath_set = frozenset(rootpath)
overrides = [x for x in settings.get(
"__PORTAGE_TEST_PATH_OVERRIDE", "").split(":") if x]
@@ -243,7 +244,10 @@ def _doebuild_path(settings, eapi=None):
for prefix in prefixes:
for x in ("usr/local/sbin", "usr/local/bin", "usr/sbin",
"usr/bin", "sbin", "bin"):
- path.append(os.path.join(prefix, x))
+ # Respect order defined in ROOTPATH
+ x_abs = os.path.join(prefix, x)
+ if x_abs not in rootpath_set:
+ path.append(x_abs)
path.extend(rootpath)
settings["PATH"] = ":".join(path)
--
2.16.4
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-10-07 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2018-10-07 23:59 UTC. Removals: Additions: dev-cpp/aixlog 20181005-10:14 whissi 82fe59d1206 dev-cpp/popl20181005-11:03 whissi e82f9d8b7a2 dev-python/diff-cover 20181001-17:55 zmedico39cf4109c3c dev-python/jinja2_pluralize 20181001-17:08 zmedicod2ea035a491 dev-python/pandas-datareader20180912-00:52 mgorny 7021a773c02 dev-python/sshtunnel20181004-17:34 titanofold 6129954809d dev-util/edi20180924-05:55 mgorny c4570290797 media-plugins/gst-plugins-cairo 20181006-19:00 leio 3c6583cd177 media-sound/lollypop20181002-13:23 johu 9411556f5c3 media-sound/snapcast20181005-14:02 whissi a29e535d11e media-sound/yarock 20181004-16:29 asturm 883d06b7e48 sci-libs/libxc 20181002-12:51 junghans 38875bd66cc sys-apps/superdiag 20180930-22:13 mgorny d723cdec156 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: Added Packages: media-sound/snapcast,added,whissi,20181005-14:02,a29e535d11e dev-cpp/popl,added,whissi,20181005-11:03,e82f9d8b7a2 dev-cpp/aixlog,added,whissi,20181005-10:14,82fe59d1206 dev-util/edi,added,mgorny,20180924-05:55,c4570290797 media-plugins/gst-plugins-cairo,added,leio,20181006-19:00,3c6583cd177 dev-python/sshtunnel,added,titanofold,20181004-17:34,6129954809d media-sound/yarock,added,asturm,20181004-16:29,883d06b7e48 media-sound/lollypop,added,johu,20181002-13:23,9411556f5c3 sci-libs/libxc,added,junghans,20181002-12:51,38875bd66cc dev-python/diff-cover,added,zmedico,20181001-17:55,39cf4109c3c dev-python/jinja2_pluralize,added,zmedico,20181001-17:08,d2ea035a491 dev-python/pandas-datareader,added,mgorny,20180912-00:52,7021a773c02 sys-apps/superdiag,added,mgorny,20180930-22:13,d723cdec156 Done.
Re: [gentoo-dev] [PATCH v2 0/1] profiles: unset USE=modules by default
Pushed.
[gentoo-dev] Last rites: app-office/openerp (and orphans)
# Virgil Dupras (07 Oct 2018) # Masked for removal, along with orphans, because it's unmaintained # and vulnerable. Bug #629270 app-office/openerp dev-python/pychart dev-python/pywebdav dev-python/vatnumber pgpLLrSXvkQdk.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass
Mykyta Holubakha schrieb am Sa., 6. Okt. 2018 um
13:18 Uhr:
> Signed-off-by: Mykyta Holubakha
>
> I'm proposing to add a new eclass: appimage.eclass, to facilitate
> extraction off AppImage bundles. The rationale is that some upstreams
> have migrated to distributing their proprietary software exclusively as
> AppImage bundles. (for instance dev-util/staruml-bin).
>
> An example ebuild can be seen at https://git.io/fx3Mg
>
>
I was also thinking of something, too. This direction of development
happens for a couple of years already, with more and more vendors /
upstream jumping on it. It was also highly recommended by Linus Torvalds as
a way of distributing packages easily along different linux flavors. I
don't think we should easily deny the direction where this is going.
Most appimages are distributed through central well-known servers. The
files have a sha1 BuildID attached to them (can be seen via file command),
which can possibly be used to verify them, so decreasing the possible
vulnerability to such packages somewhat. There might also be additional
ways to verify the integrity of them through the appimage API. They are
statically linked packages with no external dependencies, and contain a
squashfs filesystem in it.
>From a users point of view, I think it'd be a good idea, to give users the
possibility of installing appimages with the package manager, so they can
be handled accordingly, instead of just let them download the files and
move them into a separate folder in ${HOME} for execution. This would be
especially useful for propietary bin-packages, as well as for some big
packages, which are actually hard to maintain for proxy-maintainers, and
therefore get removed from the tree (freecad comes to my mind as an
example).
2. Are we OK with executing AppImage bundles downloaded from the
> Internet (an alternative would be to implement a proper extractor
> program, which would unpack the images without executing them, and add
> it to DEPENDs).
>
It think, this has mostly the same attack vectors which apply for
bin-packages. So there's not much new from my point of view.
> +# @FUNCTION: appimage_src_unpack
> +# @DESCRIPTION:
> +# Unpack all the AppImage bundles from ${A} (with .appimage extension).
> +# Other files are passed to regular unpack.
>
I'm not sure, if it makes sense to unpack them. Most of them are not built
on gentoo systems, so the extracted binaries and libraries might not easily
run without having the ebuild maintainer check every single one of them for
run-time dependencies.
For example, the freecad appimage contains a bin/mkdir program linked
against libselinux.so.1 which is not available on non-selinux profiles by
default, or its usr/lib/freecad/lib/DraftUtils.so, a freecad internal
library, links against libboost_system.so.1.55.0 while we have
libboost_system.so.1.65.0.
I would propose to keep them packed and install them in /opt/AppImages or
something like that, thus providing only a src_install function with the
eclass. Ebuild maintainers could then just add a .desktop file or extract
one from the image if it's present and add it to the files/ directory for
desktop integration.
Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass
On 06.10.2018 14:17, Mykyta Holubakha wrote: > Signed-off-by: Mykyta Holubakha > > I'm proposing to add a new eclass: appimage.eclass, to facilitate > extraction off AppImage bundles. The rationale is that some upstreams > have migrated to distributing their proprietary software exclusively as > AppImage bundles. Why making the separate eclass? Merge it with the unpacker one. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass
> On Sat, 06 Oct 2018, Mykyta Holubakha wrote:
> Signed-off-by: Mykyta Holubakha
> I'm proposing to add a new eclass: appimage.eclass, to facilitate
> extraction off AppImage bundles. The rationale is that some upstreams
> have migrated to distributing their proprietary software exclusively as
> AppImage bundles. (for instance dev-util/staruml-bin).
Ask upstream to use a friendlier package format?
> An example ebuild can be seen at https://git.io/fx3Mg
> I'd like to ask the following questions:
> 1. Can I put myself and proxy-maint under @MAINTAINER (or do I need to
> find a gentoo dev)?
You should contact proxy-maintainers in any case, because somebody needs
to commit it for you.
> 2. Are we OK with executing AppImage bundles downloaded from the
> Internet (an alternative would be to implement a proper extractor
> program, which would unpack the images without executing them, and add
> it to DEPENDs).
These are ELF binaries unpacking an included ISO 9660 image, right?
Not sure if it's a good idea to execute those in src_unpack. Won't they
require external dependencies to run?
I have also looked at staruml-bin-3.0.2.ebuild (your example above) and
I believe that it is highly problematic from a license point of view.
The distfile includes bundled LGPL libraries without including their
source, which means that it cannot be distributed.
> ---
> eclass/appimage.eclass | 69
> ++
> 1 file changed, 69 insertions(+)
> create mode 100644 eclass/appimage.eclass
> diff --git a/eclass/appimage.eclass b/eclass/appimage.eclass
> new file mode 100644
> index 000..454bdedc07b
> --- /dev/null
> +++ b/eclass/appimage.eclass
> @@ -0,0 +1,69 @@
> +# Copyright 2018 Gentoo Foundation
This should be "Gentoo Authors" by the new copyright policy.
> +# Distributed under the terms of the GNU General Public License v2
> +
> +# @ECLASS: appimage.eclass
> +# @MAINTAINER:
> +# maintainer-wan...@gentoo.org
> +# @AUTHOR:
> +# Mykyta Holubakha
> +# @BLURB: convenience eclass for extracting AppImage bundles
> +# @DESCRIPTION:
> +# This eclass provides a src_unpack function to extract AppImage bundles
> +
> +case "${EAPI:-0}" in
The quotes are not needed.
> + 6|7)
> + ;;
> + *)
> + die "EAPI ${EAPI:-0} is not supported"
> + ;;
> +esac
> +
> +EXPORT_FUNCTIONS src_unpack
> +
> +# @VARIABLE: APPIMAGE_EXTRACT_DIR
> +# @DEFAULT_UNSET: squashfs_root
@DEFAULT_UNSET doesn't take any parameters.
> +# @DESCRIPTION:
> +# This variable specifies the directory, in which the AppImage bundle
> +# is expected to be extracted.
> +
> +# @VARIABLE: APPIMAGE_EXTRACT_DEST
> +# @DEFAULT_UNSET: ${P}
> +# @DESCRIPTION:
> +# This variable specifies the directory, to which the extracted image
> +# will be moved.
> +
> +# @FUNCTION: appimage_src_unpack
> +# @DESCRIPTION:
> +# Unpack all the AppImage bundles from ${A} (with .appimage extension).
> +# Other files are passed to regular unpack.
> +appimage_src_unpack() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + local extract_dir="${APPIMAGE_EXTRACT_DIR:-squashfs-root}"
> + local extract_dest="${APPIMAGE_EXTRACT_DEST:-${P}}"
> +
> + local f
> + for f in ${A}
> + do
> + case "${f}" in
No quotes here.
> + *.appimage|*.AppImage)
> + cp "${DISTDIR}/${f}" "${WORKDIR}"
Add "|| die".
> + debug-print "${FUNCNAME}: unpacking bundle ${f}
> to ${extract_dest}"
> + chmod +x "${f}" \
> + || die "Failed to add execute
> permissions to bundle"
> + "${WORKDIR}/${f}" --appimage-help >/dev/null
> 2>/dev/null \
> + || die "Invalid AppImage bundle"
> + "${WORKDIR}/${f}" --appimage-extract >/dev/null
> 2>/dev/null \
> + || die "Failed to extract AppImage
> bundle"
See above, presumably it would be better to use an external tool for
extraction.
> + rm -f "${f}" || die "Failed to remove bundle
> copy"
> + mv "${extract_dir}" "${extract_dest}" \
> + || die "Failed to move AppImage bundle
> to destination"
> + ;;
> + *)
> + debug-print "${FUNCNAME}: falling back to
> unpack for ${f}"
> + unpack "${f}"
> + ;;
> + esac
> + done
> +}
> +
> --
> 2.15.1
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass
Hi! On Sat, 6 Oct 2018 14:17:50 +0300 Mykyta Holubakha wrote: > I'm proposing to add a new eclass: appimage.eclass, to facilitate > extraction off AppImage bundles. The rationale is that some upstreams > have migrated to distributing their proprietary software exclusively as > AppImage bundles. (for instance dev-util/staruml-bin). > > An example ebuild can be seen at https://git.io/fx3Mg > > I'd like to ask the following questions: > > 1. Can I put myself and proxy-maint under @MAINTAINER (or do I need to > find a gentoo dev)? Likely no. We have no such eclasses right now. Eclasses have more strict requirements than ebuilds, e.g. they should not be changed without a prior ML discussion except for project-specific eclasses. > 2. Are we OK with executing AppImage bundles downloaded from the > Internet (an alternative would be to implement a proper extractor > program, which would unpack the images without executing them, and add > it to DEPENDs). This would be a considerable security risk, so no. You should use some extractor. Looks like appimage carries filesystem inside with some offset. Best regards, Andrew Savchenko pgp8uIcWqqK7i.pgp Description: PGP signature
