[gentoo-portage-dev] [PATCH eapi6-pt2 v2 3/6] Add sandbox directory removal functions for EAPI 7

Bug: https://bugs.gentoo.org/630422 --- bin/eapi.sh| 4 bin/ebuild.sh | 17 + bin/save-ebuild-env.sh | 1 + 3 files changed, 22 insertions(+) diff --git a/bin/eapi.sh b/bin/eapi.sh index 67563bed8..5d77c8daf 100644 --- a/bin/eapi.sh +++ b/bin/eapi.sh

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 4/6] Add EAPI 7 version comparison & manipulation functions

Bug: https://bugs.gentoo.org/482170 --- bin/eapi.sh | 4 + bin/eapi7-ver-funcs.sh| 191 bin/isolated-functions.sh | 4 + pym/portage/tests/bin/test_eapi7_ver_funcs.py | 240

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 6/6] Do not export PORTDIR & ECLASSDIR in EAPI 7

Bug: https://bugs.gentoo.org/373349 Bug: https://bugs.gentoo.org/373351 --- bin/eapi.sh| 4 bin/phase-functions.sh | 6 -- pym/portage/eapi.py| 11 +++ pym/portage/package/ebuild/doebuild.py | 14 ++ 4

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 5/6] Support ENV_UNSET for EAPI 7

Bug: https://bugs.gentoo.org/499288 --- bin/eapi.sh| 4 bin/ebuild.sh | 6 ++ pym/_emerge/actions.py | 4 ++-- pym/portage/const.py | 3 ++- 4 files changed, 14 insertions(+), 3 deletions(-) diff --git a/bin/eapi.sh b/bin/eapi.sh index cd2acad80..3e837f19d 100644

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 2/6] nonfatal: Implement fallback executable for EAPI 7

EAPI 7 specifies that nonfatal has to be implemented both as a bash function and a fallback executable, so that it can be used e.g. via find/xargs. Bug: https://bugs.gentoo.org/622894 --- bin/eapi.sh | 4 bin/ebuild-helpers/nonfatal | 14 ++ 2 files changed, 18

[gentoo-portage-dev] [PATCH eapi6-pt2 v2 1/6] Allow package.*, use.* directories in EAPI 7

Bug: https://bugs.gentoo.org/282296 --- pym/portage/eapi.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pym/portage/eapi.py b/pym/portage/eapi.py index 075f7a59c..092780ded 100644 --- a/pym/portage/eapi.py +++ b/pym/portage/eapi.py @@ -85,7 +85,7 @@ def

Re: [gentoo-dev] Functional portage with namespace (Was: Integrating Portage with other package managers)

On Thu, Mar 8, 2018 at 9:11 PM, R0b0t1 wrote: > > Sadly interest in the patches seems to have waned. The functionality > is not exactly duplicated in containers, but they do make it easier to > find changes. > Well, the idea with containers wouldn't be to monitor anything, but

Re: [gentoo-dev] Functional portage with namespace (Was: Integrating Portage with other package managers)

On Thu, Mar 8, 2018 at 7:06 PM, Rich Freeman wrote: > On Thu, Mar 8, 2018 at 7:46 PM, Benda Xu wrote: >> Rich Freeman writes: >> >>> If you have util-linux installed then try running (as any user - you >>> don't have to be root): unshare

[gentoo-dev] Feature="test" returns 0 tests

Hello, I am working on upgrading paho-mqtt to the latest release and I have an issue with enabling tests. I have FEATURE="test" in an lxc container and I am seeing it run the tests when I emerge dev-python/paho-mqtt. However, when I committed my changes, the reviewer is not having any test run

Re: [gentoo-dev] Functional portage with namespace (Was: Integrating Portage with other package managers)

On Thu, Mar 8, 2018 at 7:46 PM, Benda Xu wrote: > Rich Freeman writes: > >> If you have util-linux installed then try running (as any user - you >> don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U >> -r /bin/bash >> >> Congrats. You are

[gentoo-dev] Functional portage with namespace (Was: Integrating Portage with other package managers)

Rich Freeman writes: > If you have util-linux installed then try running (as any user - you > don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U > -r /bin/bash > > Congrats. You are now root in a container. You're in the same root > filesystem as always.

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

2018-03-08 16:40 GMT+01:00 Michał Górny : > Hello, developers. > > I would like to bring to your attention an alarming trend in Gentoo > ebuilds -- the proliferation of IUSE=static-libs, that is a flag > allowing our users to build static libraries. > > I should like to remind

Re: [gentoo-portage-dev] [PATCH] ebuild-helpers: Fix overriding 'insinto' directory

On 03/08/2018 11:51 AM, Michał Górny wrote: > Closes: https://bugs.gentoo.org/649946 > --- > bin/ebuild-helpers/doconfd | 9 +++-- > bin/ebuild-helpers/doenvd | 9 +++-- > bin/ebuild-helpers/doheader | 6 +- > 3 files changed, 19 insertions(+), 5 deletions(-) > > diff --git

Re: [gentoo-dev] Integrating Portage with other package managers

On Thu, Mar 8, 2018 at 4:00 PM, R0b0t1 wrote: > On Thu, Mar 8, 2018 at 11:50 AM, Rich Freeman wrote: >> If you have util-linux installed then try running (as any user - you >> don't have to be root): >> unshare -i -m -n -p -u -C -f --mount-proc -U -r

Re: [gentoo-dev] Integrating Portage with other package managers

On Thu, Mar 8, 2018 at 11:50 AM, Rich Freeman wrote: > If you have util-linux installed then try running (as any user - you > don't have to be root): > unshare -i -m -n -p -u -C -f --mount-proc -U -r /bin/bash > Interesting. I hadn't found a good interface to containers and

Re: [gentoo-dev] Integrating Portage with other package managers

On Wed, 7 Mar 2018 11:06:47 -0500 anote...@teknik.io wrote: > Having used Gentoo for a few years now, one thing that has been annoying > to me is the tremendous duplication of effort and uphill battle of > creating ebuilds (build recipes) for language-specific packages that > already have their

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

On Thu, 08 Mar 2018 16:40:44 +0100 Michał Górny wrote: > So, developers, please *stop adding USE=static-libs* to random libraries > that have no reason whatever to be statically linked to. Sorry, I like a lot of your ideas but I'm with the others on this one. I have, on the

[gentoo-portage-dev] [PATCH] doins: don't clobber _E_INSDESTTREE_

This might be set by another helper function (doconfd, doenvd, doheader). Bug: https://bugs.gentoo.org/649946 Fixes: a5d0111d0bdaa7ee9e5c68e22b4a97ce415e119b --- bin/ebuild-helpers/doins | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/ebuild-helpers/doins

Re: [gentoo-dev] Integrating Portage with other package managers

On Thu, Mar 8, 2018 at 11:44 AM, R0b0t1 wrote: > > I think I was equating containers to Docker as well. My point was > instead of trying to manage dependencies, containers allow people to > shove everything into an empty root with no conflicts. The > enthusiastic blog post seems

[gentoo-dev] [PATCH 8/8] linux-info.eclass: Skip linux_config_*_exists on non-Linux

The linux_config_src_exists and linux_config_bin_exists always return false on non-Linux systems by design. Short-circuit it via 'kernel_linux' check. --- eclass/linux-info.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/linux-info.eclass

[gentoo-dev] [PATCH 7/8] linux-info.eclass: Die in most of public-ish APIs on non-Linux

Add appropriate 'die' calls in most of the seemingly public APIs of the eclass that could be called by ebuilds and that are going to fail horribly when used on non-Linux systems. This means that e.g. 'kernel_is' calls need to be explicitly guarded in ebuilds, as we can't really reasonably return

[gentoo-dev] [PATCH 6/8] linux-info.eclass: Ignore check_extra_config on non-Linux

Make the check_extra_config and pkg_setup calls no-op on non-Linux systems. Those systems don't have a Linux kernel, so they obviously can't satisfy the requirements. This currently results in a lot of useless warnings about missing Linux kernel sources on FreeBSD. We could make it conditional

[gentoo-dev] [PATCH 5/8] linux-info.eclass: require_configured_kernel, improve error handling

Add error handling for failing get_version call in require_configured_kernel. Give just a simple 'die' message since the get_version function should verbosely explain the problem. --- eclass/linux-info.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[gentoo-dev] [PATCH 4/8] linux-info.eclass: Move get_version to require_configured_kernel

All require_configured_kernel calls in this eclass are followed by a get_version call. Since even calling it proactively wouldn't hurt, move it to require_configured_kernel. This saves us from having to manually implement error handling for it everywhere. --- eclass/linux-info.eclass | 4 +--- 1

[gentoo-dev] [PATCH 3/8] linux-info.eclass: linux-info_get_any_version, die on failure

Make linux-info_get_any_version die if it can't determine any version of the Linux kernel. This indicates a problem with the eclass code (as it should not happen on Linux) and the missing KV_* variables are going to cause random misbehavior and failures. --- eclass/linux-info.eclass | 4 +++- 1

[gentoo-dev] [PATCH 2/8] linux-info.eclass: Replace unnecessary $? checks

--- eclass/linux-info.eclass | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/eclass/linux-info.eclass b/eclass/linux-info.eclass index b8c1a524bae8..df6227220b79 100644 --- a/eclass/linux-info.eclass +++ b/eclass/linux-info.eclass @@ -628,8 +628,7 @@

[gentoo-dev] [PATCH 1/8] linux-info.eclass: get_localversion, do not call 'ls'

Use bash array to perform a safe filename glob instead of calling 'ls'. Also, use nullglob to cleanly handle no matches instead of silencing errors. --- eclass/linux-info.eclass | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/eclass/linux-info.eclass

[gentoo-dev] [PATCH 0/8] linux-info.eclass: cleanup & better non-Linux support

Hi, everyone. Here's a patch set for linux-info.eclass. Besides some minor cleanup, it improves error handling and adds explicit handling for non-Linux systems. Currently, the eclass pretty much wrongly assumes that every system is Linux. This causes e.g. a lot of spurious warnings or completely

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

On Thu, 08 Mar 2018 16:40:44 +0100 Michał Górny wrote: > As part of that we also shouldn't deliver static libraries OK, so you want to absolutely kill dead the only current sane way for developers who use Gentoo to ship static binaries to their users' target systems? Drive

Re: [gentoo-dev] Integrating Portage with other package managers

On Wed, Mar 7, 2018 at 3:06 PM, Rich Freeman wrote: > On Wed, Mar 7, 2018 at 3:55 PM, R0b0t1 wrote: >> On Wed, Mar 7, 2018 at 1:15 PM, Alec Warner wrote: >>> >>> Because containers are awesome and are way easier to use. >>> >> >> I think

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

On Thu, Mar 8, 2018 at 10:40 AM, Michał Górny wrote: > > So, developers, please *stop adding USE=static-libs* to random libraries > that have no reason whatever to be statically linked to. And by that I > mean a good reason, not creeping featurism, not 'user asked for it', not

Re: [gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

On Thu, Mar 8, 2018 at 10:40 AM, Michał Górny wrote: > Hello, developers. > > I would like to bring to your attention an alarming trend in Gentoo > ebuilds -- the proliferation of IUSE=static-libs, that is a flag > allowing our users to build static libraries. > > I should

[gentoo-dev] Proliferation of IUSE=static-libs in Gentoo

Hello, developers. I would like to bring to your attention an alarming trend in Gentoo ebuilds -- the proliferation of IUSE=static-libs, that is a flag allowing our users to build static libraries. I should like to remind you that static linking is almost always a bad idea. It has serious

Re: [gentoo-dev] Integrating Portage with other package managers

On 03/07/2018 11:06 AM, anote...@teknik.io wrote: > It seems reasonable to me to 'hook' portage into these > other package managers, so that running 'emerge bar' > would actually run 'cabal install bar' rather than > downloading sources and running 'ghc'. it gets tricky when there's no good way

Re: [gentoo-dev] Integrating Portage with other package managers

On 03/08/2018 07:25 AM, Michael Orlitzky wrote: > On 03/08/2018 12:54 AM, Benda Xu wrote: >> >> This title itself is amusing enough >> >> Motherfuckers need package management >> > > Which if it is not clear, is intended to be funny. > > the colorful language was proportional to the

Re: [gentoo-dev] Integrating Portage with other package managers

On 03/08/2018 12:54 AM, Benda Xu wrote: > > This title itself is amusing enough > > Motherfuckers need package management > Which if it is not clear, is intended to be funny.