Re: [gentoo-portage-dev] [PATCH] Stop implicitly manipulating `NO_COLOR`/`NOCOLOR`

[Ulrich Mueller]

> On Sun, 26 Nov 2023, Michał Górny wrote:

> 3. Forcing `NO_COLOR=1` turns out to cause random test failures,
>and while fixing them is commendable, it is a pain for arch testing
>and it is currently blocking stabilization requests.

I'd argue that test suites that fail because of NO_COLOR are broken.
IIUC, these failures will show up for users who set NO_COLOR=1 in their
make.conf or in the environment?

> With the new approach, the color output in programs is consistent
> between using ``--jobs`` or ``--quiet-build``, and not.  Therefore,
> both cases generate uniform logs.  In order to obtain logs free of color
> codes, one can either filter them via `ansifilter(1)` (as the manpages
> already recommend) or explicitly set `NO_COLOR`.

Will this still guarantee that NO_COLOR=1 from the environment is always
passed on to the build system?

Otherwise, it would break ebuild-mode in some configurations.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] Fixing EAPI 8 --enable-static once and for all

[Ulrich Mueller]

> On Sat, 19 Nov 2022, David Seifert wrote:

> With this extensive analysis, I believe this patch to be safe.

Still looks like an incompatible change, so it will need an EAPI bump.

EAPI 9 feature bug is here: https://bugs.gentoo.org/815169


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] doins: fix D check, add EPREFIX check

[Ulrich Mueller]

> On Mon, 25 Jul 2022, Fabian Groffen wrote:

> @@ -50,6 +51,16 @@ if [[ ${_E_INSDESTTREE_#${ED}} != "${_E_INSDESTTREE_}" ]]; 
> then
>   __helpers_die "${helper} used with \${D} or \${ED}"
>   exit 1
>  fi
> +if [[ -n ${EPREFIX} && \
> + ${_E_INSDESTTREE_#${EPREFIX}} != "${_E_INSDESTTREE_}" ]];

The semicolon is redundant.

> +then
> + __vecho "---" 1>&2
> + __vecho "You should not use \${EPREFIX} with helpers." 1>&2
> + __vecho "  --> ${_E_INSDESTTREE_}" 1>&2
> + __vecho "---" 1>&2
> + __helpers_die "${helper} used with \${EPREFIX}"
> + exit 1
> +fi


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] eend: Output QA notice when called without argument

[Ulrich Mueller]

> On Sat, 04 Sep 2021, Ulrich Müller wrote:

> PMS says about eend: "Takes one fixed argument, which is a numeric
> return code, and an optional message in all subsequent arguments."

Pushed.


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v3] Copy files/* into the work tree instead of symlinking it

[Ulrich Mueller]

> On Sun, 26 Sep 2021, Michał Górny wrote:

> Symlinking FILESDIR into the work tree has the unintended consequence
> of preserving all original file metadata, including system-specific ACLs
> and so on.  When these files are installed, this could lead to
> unintentionally copying this metadata to the system and/or binary
> packages.

> Let's copy all files instead and drop metadata in the process.  Since
> FILESDIR is expected to be small by design, this shouldn't cause any
> major trouble.  It is also easier and less likely to cause regressions
> than making sure stuff is not preserved when installing.

> Unfortunately, a similar problem applies to DISTDIR.  However,
> installing files from DISTDIR is rarer than from FILESDIR, so I guess
> we'll cross that bridge when we get to it.

Sorry for the late reply, but this looks like the wrong solution to me.

Looking at the installation helpers (doins, doexe, etc.), they don't
preserve the normal permission bits, but reset them to a defined state.
So why would they preserve xattrs?

I don't see anything in PMS that would mandate that behaviour (on the
contrary, in section 13.3.1 there is "Other file attributes may be
discarded"). How do the other package managers handle this?

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 2/2] ebuild.sh: Update QA notice in inherit()

[Ulrich Mueller]

> On Sun, 29 Aug 2021, Michał Górny wrote:

> On Sun, 2021-08-29 at 22:06 +0200, Ulrich Müller wrote:
>> -eqawarn "For compatibility with <=portage-2.1.6.7, only 
>> call EXPORT_FUNCTIONS"
>> -eqawarn "after inherit(s)."
>> +eqawarn "For compatibility with PMS, only call 
>> EXPORT_FUNCTIONS after inherit(s)."

> Could you add a sentence that the current Portage behavior is going to
> change in the future?

Sure, but do we actually know that?


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] In what phase are file "merged"?

[Ulrich Mueller]

>>>>> On Fri, 06 Aug 2021, Joakim Tjernlund wrote:

> On Wed, 2021-06-23 at 13:33 +0200, Michał Górny wrote:
>> On Wed, 2021-06-23 at 12:40 +0200, Ulrich Mueller wrote:
>> > I don't think that the ebuild can rely on any particular status of
>> > the new package in pkg_*rm (of the old package), or the status of
>> > the old package in pkg_*inst (of the new package).
>> 
>> I would even say that it can't rely on the particular status of the
>> old package in any case, if it's meant to be removed.  In particular,
>> its dependencies can be unmerged before the package itself.

> Stubled ove this mail again and noticed "its dependencies can be
> unmerged before the package itself" stmt. That does not make sense to
> me. Deps should be unmerged after any pkg that depends on them?

A popular workflow is "emerge -c -p" followed by "emerge -C" on entries
of the list shown. IIUC emerge -C doesn't do any dependency resolution,
therefore ebuilds cannot rely on any removal order.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] In what phase are file "merged"?

[Ulrich Mueller]

>>>>> On Wed, 23 Jun 2021, Fabian Groffen wrote:

> On 23-06-2021 08:47:58 +0200, Ulrich Mueller wrote:
>> It's somewhat hidden, but it's there:
>> https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10
>> 
>> 9.1.10 pkg_preinst
>> ... immediately before merging the package to the live filesystem. ...
>> 
>> 9.1.11 pkg_postinst
>> ... immediately after merging the package to the live filesystem. ...

> Aha, so does this mean pkg_prerm and pkg_postrm are run with replacing
> package in place, e.g. if they refer to scripts installed by the
> replaced package they may no longer exist or be the same?

PMS has similar wording for pkg_prerm and pkg_postrm, so (at least
according to the spec) the old package will still be present in
pkg_prerm and will be gone in pkg_postrm.

I don't think that the ebuild can rely on any particular status of the
new package in pkg_*rm (of the old package), or the status of the old
package in pkg_*inst (of the new package).

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] In what phase are file "merged"?

[Ulrich Mueller]

> On Wed, 23 Jun 2021, Joakim Tjernlund wrote:

> In PMS 9.2 is says:
> The call order for upgrading, downgrading or reinstalling a package is:

> pkg_pretend (only for EAPIs listed in table 9.2), which is called outside 
> of the normal call order process.
> pkg_setup
> src_unpack
> src_prepare (only for EAPIs listed in table 9.3)
> src_configure (only for EAPIs listed in table 9.4)
> src_compile
> src_test (except if RESTRICT=test)
> src_install
> pkg_preinst
> pkg_prerm for the package being replaced
> pkg_postrm for the package being replaced
> pkg_postinst

> It does not say where in this list new files merged and old files
> unmerged, can anyone enlighten me?

It's somewhat hidden, but it's there:
https://projects.gentoo.org/pms/8/pms.html#x1-950009.1.10

   9.1.10 pkg_preinst
   ... immediately before merging the package to the live filesystem. ...

   9.1.11 pkg_postinst
   ... immediately after merging the package to the live filesystem. ...

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] env-update: create systemd env configuration if required

[Ulrich Mueller]

> On Thu, 03 Sep 2020, Florian Schmaus wrote:

> It's not really maintaining the information twice. The information is
> maintained at a single point: /etc/env.d
> And from there is is transformed by env-update already into two
> different formats:
> - /etc/profile.env
> - /etc/csh.env

> And with that change additionally into
> - /usr/lib/environment.d/gentoo-profile-env.conf

Sorry for another nitpick, but it's changing a file in /usr at runtime?
Also, does the file belong to any package, or is it an orphan?

Maybe it would be cleaner to generate the file in /etc like the others,
if necessary with a symlink in /usr/lib/environment.d? The symlink could
belong to some package, maybe even sys-apps/systemd itself.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] env-update: create systemd env configuration if required

[Ulrich Mueller]

> On Thu, 03 Sep 2020, Florian Schmaus wrote:

> This commit changes env-update so that, after profile.env has was
> generated, a systemd user session environment configuration file named

> /usr/lib/environment.d/gentoo-profile-env.conf

> is created, if the directory /usr/lib/environment.d exists.

Maybe a stupid question, but can't this file just source /etc/profile?
Maintaining the same information twice doesn't look like the right thing
to do.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] profile masking

[Ulrich Mueller]

> On Fri, 14 Aug 2020, Zac Medico wrote:

> On 8/14/20 8:42 AM, Joakim Tjernlund wrote:
>> Yes, I know I can add that in profile/package.mask but I am looking
>> for the bigger picture here. This has to stop somehow, there need to
>> be something that limits the mask scope to the repo/overlay it is
>> defined.

> The scope is already limited, but this overlay inherits the mask because
> it has the gentoo repo as its master (either implicitly or via a masters
> setting in metadata/layout.conf).

> I suppose we could add an option to prevent this inheritance.

Like an option in repos.conf or layout.conf?

The problem I see with this is that preventing inheritance would disable
files like license_groups or thirdpartymirrors. So overlays would have
to maintain their own versions.

>> I think a good start would be to consider /etc/portage the top
>> profile and other subprofiles should be able to use the same features
>> as /etc/portage.
>> 
>> Portage could start supporting that now, but there would be a while
>> until one can use them in Gentoo profile.

> We've got this bug open for the ::repo atom support:

> https://bugs.gentoo.org/651208

I still believe that adding ::gentoo to every line in package.mask would
be the wrong approach to the problem.

Ulrich

Re: [gentoo-portage-dev] profile masking

[Ulrich Mueller]

> On Fri, 14 Aug 2020, Joakim Tjernlund wrote:

> When pkgs are masked in the profile, it affects all variants of that
> pkgs, even the ones that are in other overlays.
> Example:
> !!! The following installed packages are masked:
> - sys-auth/sssd-::transmode (masked by: package.mask)
> /usr/portage/profiles/package.mask:
> # Matt Turner  (2020-08-13)
> # Masked for testing

> My sssd- is now masked.

> Could the profile syntax be extended to include syntax allowed in
> /etc/portage ? Then one could use the ::gentoo syntax (or so I hope)

The :: syntax is Portage specific and doesn't exist in EAPI 7.
So there's no chance to get it into the profile dir anytime soon
(because that would imply :: to be added to a future EAPI and the
top-level profile dir to be bumped to that EAPI).

You could override the mask in your overlay's profile/package.mask
instead, using an entry with the "-" operator.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 01/26] lib/portage/util/_desktop_entry.py: fix unused-import

[Ulrich Mueller]

> On Mon, 03 Aug 2020, Aaron Bauman wrote:

> --- a/lib/portage/util/_desktop_entry.py
> +++ b/lib/portage/util/_desktop_entry.py
> @@ -1,16 +1,13 @@
> -# Copyright 2012-2013 Gentoo Foundation
> +# Copyright 2020 Gentoo Authors

Please don't drop existing years from the range.


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 2/3] Remove support code for Python < 3.3

[Ulrich Mueller]

> On Fri, 17 Jul 2020, Michał Górny wrote:

> --- a/lib/portage/util/_dyn_libs/PreservedLibsRegistry.py
> +++ b/lib/portage/util/_dyn_libs/PreservedLibsRegistry.py
> @@ -34,12 +34,9 @@ class PreservedLibsRegistry(object):
>  
>   _json_write_opts = {
>   "ensure_ascii": False,
> - "indent": "\t",
> - "sort_keys": True
> + "indent": 4,

This is assigning 4 now unconditionally, while it was "\t" before for
modern Python versions. Is this intentional?

> + "sort_keys": True,

Why the added comma?

>   }
> - if sys.hexversion < 0x30200F0:
> - # indent only supports int number of spaces
> - _json_write_opts["indent"] = 4
>  
>   def __init__(self, root, filename):
>   """


> --- a/lib/portage/util/mtimedb.py
> +++ b/lib/portage/util/mtimedb.py
> @@ -29,12 +29,9 @@ class MtimeDB(dict):
>  
>   _json_write_opts = {
>   "ensure_ascii": False,
> - "indent": "\t",
> + "indent": 4,

Same here.

>   "sort_keys": True
>   }
> - if sys.hexversion < 0x30200F0:
> - # indent only supports int number of spaces
> - _json_write_opts["indent"] = 4
>  
>   def __init__(self, filename):
>   dict.__init__(self)

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Add caching to use_reduce, vercmp, and catpkgsplit

[Ulrich Mueller]

> On Mon, 13 Jul 2020, Chun-Yu Shei wrote:

> Ah, I wasn't aware that I should have added that... I'm happy to say
> "Signed-off-by: Chun-Yu Shei " somewhere if
> necessary.

Should be enough to say it here, because this mailing list is archived.
We could of course add an empty commit with "Fixes" and "Signed-off-by",
so we'd have the paper trail in the repo.

> The patch has gone through Google's open source patching approval
> process and I'm able to agree to any CLA required.

We don't require a CLA. As long as you can signoff the copyright, things
are fine. See https://www.gentoo.org/glep/glep-0076.html for all the
details.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Add caching to use_reduce, vercmp, and catpkgsplit

[Ulrich Mueller]

> On Mon, 13 Jul 2020, Zac Medico wrote:

> Merged:

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

Looks like the author's copyright signoff is missing?


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] erroneous behavior in 2-style USE dependencies?

[Ulrich Mueller]

> On Wed, 17 Jun 2020, Michael Lienhardt wrote:

> But maybe, "error" here in the PMS mean "the cpvs without the use flag
> does not match that dependency and a warning should be raised to
> improve compatibility in the future". In that case, it would be
> clearer for me to change 'error' in the PMS into something like
> "results in a no match,

IMHO we cannot assume that. If the flag is not in the dependency's
IUSE_EFFECTIVE then behaviour is undefined.

> but should be avoided". That way, it is explicitly stated that missing
> use flags for a 2-style USE dependency is accepted (which is the
> current behavior of emerge) but frown upon, without forcing any
> specific error handling, like Michał accurately pointed out.

The real problem is that we don't have a good procedure for removing
flags from ebuilds with reverse (2-style) use dependencies. (And even
with 4-style use dependencies the problem remains that one cannot know
in advance whether removal of the flag implies that the feature is now
unconditionally enabled, or that it is disabled.)

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Use env to find python

[Ulrich Mueller]

> On Tue, 16 Jun 2020, Michał Górny wrote:

> '/usr/bin/env python' (with no extra options) is the portable shebang.

I still think this is a gross hack. You want your script to use the
correct interpreter (which is in /usr/bin, or the path substituted for
it at install time), not some random binary which happens to be found
in the user's ${PATH}.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Use env to find python

[Ulrich Mueller]

But we know that it is in /usr/bin, so why add yet another indirection?


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Improve handling of percent-signs in SRC_URI

[Ulrich Mueller]

> On Sun, 31 May 2020, Zac Medico wrote:

> We've also got these other basename calls in fetch.py:

>> diff --git a/lib/portage/package/ebuild/fetch.py 
>> b/lib/portage/package/ebuild/fetch.py
>> index 28e7caf53..56b375d58 100644
>> --- a/lib/portage/package/ebuild/fetch.py
>> +++ b/lib/portage/package/ebuild/fetch.py
>> @@ -730,9 +730,9 @@ def fetch(myuris, mysettings, listonly=0, fetchonly=0,
>> else:
>> for myuri in myuris:
>> if urlparse(myuri).scheme:
>> -   
>> file_uri_tuples.append((os.path.basename(myuri), myuri))
>> +   
>> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), myuri))
>> else:
>> -   
>> file_uri_tuples.append((os.path.basename(myuri), None))
>> +   
>> file_uri_tuples.append((urlunquote(os.path.basename(myuri)), None))

> The case with no scheme is not a URI, so we need to decide whether
> or not to unquote, and we should make _parse_uri_map behavior
> consistent for this case.

I think that this follows from PMS, section 8.2 [1]:

| The following elements are recognised in at least one class of
| specification. All elements must be surrounded on both sides by
| whitespace, except at the start and end of the string.
| 
| [...]
| - A URI, in the form proto://host/path. Permitted in SRC_URI and
| HOMEPAGE. In EAPIs listed in table 8.4 as supporting SRC_URI arrows,
| may optionally be followed by whitespace, then ->, then whitespace,
| then a simple filename when in SRC_URI. For SRC_URI behaviour, see
| section 8.2.10.
| - A flat filename. Permitted in SRC_URI.

So if it isn't an URI then it is a "flat filename" which IMHO is to be
interpreted literally without any unquoting.

Ulrich

[1] https://projects.gentoo.org/pms/7/pms.html#x1-690008.2


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Escape percent-signs in filename when fetching from mirrors

[Ulrich Mueller]

> On Sun, 31 May 2020, Zac Medico wrote:

> In order to ensure that the filename will not have an extra level of quoting
> in the mirror path, we'll have to do something like this wherever we
> translate a uri in SRC_URI to a filename:

> diff --git a/lib/portage/dbapi/porttree.py b/lib/portage/dbapi/porttree.py
> index 08af17bcd..99d8ab720 100644
> --- a/lib/portage/dbapi/porttree.py
> +++ b/lib/portage/dbapi/porttree.py
> @@ -1547,7 +1547,7 @@ def _parse_uri_map(cpv, metadata, use=None):
> myuris.pop()
> distfile = myuris.pop()
> else:
> -   distfile = os.path.basename(uri)
> +   distfile = unquote(os.path.basename(uri))
> if not distfile:
> raise portage.exception.InvalidDependString(
> ("getFetchMap(): '%s' SRC_URI has no 
> file " + \

I think that unescaping is correct, but you'll need a subsequent sanity
check to make sure that the resulting filename doesn't contain any
characters that aren't allowed in the Manifest.

Namely, "excluding the backwards slash (\) and characters classified as
control characters or as whitespace" (GLEP 74).

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] config.environ: delay export of A and AA (bug 720180)

[Ulrich Mueller]

> On Tue, 26 May 2020, Zac Medico wrote:

> On 5/26/20 12:48 AM, Michał Górny wrote:
>> On Mon, 2020-05-25 at 21:31 -0700, Zac Medico wrote:
>>> Since variables like A and AA can contain extremely large values which
>>> may trigger E2BIG errors during attempts to execute subprocesses, delay
>>> export until the last moment, and unexport when appropriate.
>> 
>> Please don't.  This will only hide the problem from developers who will
>> unknowingly commit broken ebuilds and cause users of alternative package
>> managers to suffer.

> We've seen in https://bugs.gentoo.org/719202 that developers can already
> do that with existing versions of portage, since the failure can be
> dependent on USE configuration.

We have seen in bug 719202 that A has exceeded _SC_ARG_MAX which is
128 KiB.

However, your commit message mentions E2BIG which will trigger at a much
larger value, namely 2 MiB. We are far away from reaching that limit in
any ebuild.

These are separate issues (although related), so I think we should make
it very clear about which one we're talking.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Change BINPKG_COMPRESS default from bzip2 to xz

[Ulrich Mueller]

> On Sun, 26 Apr 2020, Michael Orlitzky wrote:

> Fuel for the fire:

>  * https://www.nongnu.org/lzip/lzip_benchmark.html
>  * https://www.nongnu.org/lzip/xz_inadequate.html

Yep. That's why lzip is the dominant compression format now, and nobody
is using xz any more.

SCNR,
Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] einstalldocs: Fix test for DOCS being unset.

[Ulrich Mueller]

> On Thu, 20 Feb 2020, Zac Medico wrote:

> Looks good. Even though earlier EAPIs are deprecated, would there be a
> problem with updating __eapi4_src_install for consistency?

I'd rather not, because for EAPIs 4 and 5 PMS specifies that the return
status of declare -p should be tested [1].

Presumably it wouldn't make much of a difference, because we don't
account for the "assigned, but empty" case in these EAPIs.
src_install format 4 will just fail for DOCS="" or DOCS=().

[1] https://projects.gentoo.org/pms/7/pms.html#x1-94001r7


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] dosym: revert deprecated prefix compat (bug 615594)

[Ulrich Mueller]

> On Sun, 19 Jan 2020, Zac Medico wrote:

> --- a/bin/ebuild-helpers/dosym
> +++ b/bin/ebuild-helpers/dosym
> @@ -21,14 +21,6 @@ fi
>  destdir=${2%/*}
>  [[ ! -d ${ED%/}/${destdir#/} ]] && dodir "${destdir}"
>  target="${1}"
> -# DEPRECATED HACK: when absolute, prefix with offset for Gentoo Prefix
> -# (but only if ${EPREFIX} is not there already)
> -# this will eventually be removed, #615594
> -if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then
> - eqawarn "dosym: prepending EPREFIX to path implicitly. If this is 
> desired,"
> - eqawarn "   please fix the ebuild to use \${EPREFIX} explicitly."
> - target="${EPREFIX}${target}"
> -fi
>  ln -snf "${target}" "${ED%/}/${2#/}"

The intermediate "target" variable is no longer needed, you can simply
say "$1" here.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0

[Ulrich Mueller]

> On Sat, 14 Dec 2019, Michał Górny wrote:

> Actually, I added that because of your comment that people should be
> rebasing patches rather than removing context.

Isn't rebasing easier than removing context, anyway? I'd trust the
maintainer to do the right thing there.

The main argument is that the warning is apparently seen by some users,
who will then file unwanted bug reports. (Also, as I said before, we
don't even have a policy that patches must apply without fuzz.)

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0

[Ulrich Mueller]

> On Fri, 13 Dec 2019, Mike Gilbert wrote:

>> > It also triggers pointless bug reports. Please remove this.
>>
>> I don't like that eqawarn either (see above).
>>
>> OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES,
>> so they won't see the warning?

> Here's a bug report filed by a user, which is what prompted me to
> reply on this thread in the first place.

> https://bugs.gentoo.org/702608

Well then, trivial patch included below.


From 81000b32d330a1cc41a4541f7e4264918eb7e6c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Fri, 13 Dec 2019 23:41:23 +0100
Subject: [PATCH] eapply: Drop QA warning for fuzz factor.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This didn't add any information beyond what is already present in the
output of patch. Developers will know how to interpret its output, and
users won't see the warning anyway with the standard configuration.

Signed-off-by: Ulrich Müller 
---
 bin/phase-helpers.sh | 2 --
 1 file changed, 2 deletions(-)

diff --git a/bin/phase-helpers.sh b/bin/phase-helpers.sh
index b5691bd70..020862ba0 100644
--- a/bin/phase-helpers.sh
+++ b/bin/phase-helpers.sh
@@ -1004,8 +1004,6 @@ if ___eapi_has_eapply; then
if ${patch_cmd} "${all_opts[@]}" --dry-run -s -F0 \
< "${f}" &>/dev/null; then
all_opts+=( -s -F0 )
-   else
-   eqawarn "${f}: patch failed to apply 
without a fuzz factor, please rebase"
fi
 
${patch_cmd} "${all_opts[@]}" < "${f}"
-- 
2.24.0


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0

[Ulrich Mueller]

>>>>> On Thu, 12 Dec 2019, Mike Gilbert wrote:

> On Wed, Nov 27, 2019 at 11:14 PM Michał Górny  wrote:
>> On Wed, 2019-11-27 at 23:49 +0100, Ulrich Mueller wrote:

>> > The difference is that there is now a QA warning for something that
>> > is perfectly within the spec. Maybe the extra verboseness would be
>> > enough, but the eqawarn line should be omitted? It doesn't provide
>> > any info that isn't already present in the output of patch itself.
>>
>> It helps people understand why some patches throw a wall of text
>> while others don't.

> It also triggers pointless bug reports. Please remove this.

I don't like that eqawarn either (see above).

OTOH, users shouldn't normally have "qa" in PORTAGE_ELOG_CLASSES,
so they won't see the warning?

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

[Ulrich Mueller]

> On Thu, 12 Dec 2019, Mike Gilbert wrote:

> I think this should be reverted. It causes too much noise, and
> "solves" a problem only very rarely.

Now, how many lines of output does this typically produce, compared
to the total size of a typical build log? Especially with mgorny's
subsequent modification, which suppresses the output unless the patch
doesn't apply cleanly.

It was also suggested that we add -F0 in EAPI 8, but that would break
the build in those cases that are producing extra output now. I don't
think that would be preferable.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0

[Ulrich Mueller]

> On Thu, 28 Nov 2019, Michał Górny wrote:

>> The difference is that there is now a QA warning for something that
>> is perfectly within the spec. Maybe the extra verboseness would be
>> enough, but the eqawarn line should be omitted? It doesn't provide
>> any info that isn't already present in the output of patch itself.

> It helps people understand why some patches throw a wall of text while
> others don't.

WFM, but then omit the "please rebase" at least.

(Also, with the filename added, the line tends to be very long.
Maybe omit that leading whitespace to at least partially compensate?)

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH v2] eapply: Output verbosely only if patch fails to apply with -F0

[Ulrich Mueller]

> On Wed, 27 Nov 2019, Michael Orlitzky wrote:

> This now disagrees with the PMS algorithm, doesn't it?

The difference is that there is now a QA warning for something that is
perfectly within the spec. Maybe the extra verboseness would be enough,
but the eqawarn line should be omitted? It doesn't provide any info that
isn't already present in the output of patch itself.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] SLOT move of sys-libs/ncurses-5.9-r5(0/5) to sys-libs/ncurses-compat-5.9-r5(5/5) ?

[Ulrich Mueller]

> On Thu, 14 Nov 2019, Joakim Tjernlund wrote:

> And pkg move will move all pkgs within sys-libs/ncurses ?

Yes, "move" only accepts (qualified) package names without versions.

> Or could portage move only sys-libs/ncurses-5.9-r5 to
> sys-libs/ncurses-compat-5.9-r5 ?

No.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] make.globals: Change FETCHCOMMAND_RSYNC to --copy-links

[Ulrich Mueller]

> On Mon, 21 Oct 2019, Michał Górny wrote:

> This also removes most of the other options that are irrelevant or even
> undesirable to distfile fetching, that is:

> - '-r' since we always fetch a single file, so recursive operation is
>   unnecessary
> - '-p', '-o', '-g' since we want to apply our permissions and ownership
>   for distfiles rather than copying the one from mirrors,
> - '-D' since we do not expect any devices or specials in distfiles.

That certainly makes sense, but I don't see it in the actual patch?


signature.asc
Description: PGP signature

[gentoo-portage-dev] [PATCH v2] doebuild.py: Override network-sandbox in unpack only for live ebuilds (was: Re: [PATCH] Support PROPERTIES="live")

[Ulrich Mueller]

> On Mon, 29 Jul 2019, Zac Medico wrote:

> This will enable network-sandbox for all of _networked_phases, but
> Michał only suggested to do it for src_unpack.

Right. Patch v2 below.


From 6e929fac0a3f5f0bcfe85152c0931cb20d579881 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Mon, 29 Jul 2019 14:22:57 +0200
Subject: [PATCH] doebuild.py: Override network-sandbox in unpack only for live
 ebuilds.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested-by: Michał Górny 
Signed-off-by: Ulrich Müller 
---
 lib/portage/package/ebuild/doebuild.py | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/lib/portage/package/ebuild/doebuild.py 
b/lib/portage/package/ebuild/doebuild.py
index 67867d33e..6f980f87d 100644
--- a/lib/portage/package/ebuild/doebuild.py
+++ b/lib/portage/package/ebuild/doebuild.py
@@ -115,13 +115,6 @@ _ipc_phases = frozenset([
 _global_pid_phases = frozenset([
'config', 'depend', 'preinst', 'prerm', 'postinst', 'postrm'])
 
-# phases in which networking access is allowed
-_networked_phases = frozenset([
-   # for VCS fetching
-   "unpack",
-   # + for network-bound IPC
-] + list(_ipc_phases))
-
 _phase_func_map = {
"config": "pkg_config",
"setup": "pkg_setup",
@@ -156,7 +149,9 @@ def _doebuild_spawn(phase, settings, actionmap=None, 
**kwargs):
phase in _ipc_phases
kwargs['mountns'] = 'mount-sandbox' in settings.features
kwargs['networked'] = 'network-sandbox' not in settings.features or \
-   phase in _networked_phases or \
+   (phase == 'unpack' and \
+   'live' in settings.configdict['pkg'].get('PROPERTIES', 
'').split()) or \
+   phase in _ipc_phases or \
'network-sandbox' in settings['PORTAGE_RESTRICT'].split()
kwargs['pidns'] = ('pid-sandbox' in settings.features and
phase not in _global_pid_phases)
-- 
2.22.0


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Support PROPERTIES="live".

[Ulrich Mueller]

> On Sat, 27 Jul 2019, Michał Górny wrote:

> While at it, could you look into making src_unpack() network-sandbox
> override apply only to ebuilds with PROPERTIES=live?

I believe the patch included below would do that.

Ulrich


From f4ebd25a04d5eb64504724b711b41141723afcd4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ulrich=20M=C3=BCller?= 
Date: Mon, 29 Jul 2019 14:22:57 +0200
Subject: [PATCH] doebuild.py: Override network-sandbox only for live ebuilds.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Suggested-by: Michał Górny 
Signed-off-by: Ulrich Müller 
---
 lib/portage/package/ebuild/doebuild.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/portage/package/ebuild/doebuild.py 
b/lib/portage/package/ebuild/doebuild.py
index 67867d33e..cab838ead 100644
--- a/lib/portage/package/ebuild/doebuild.py
+++ b/lib/portage/package/ebuild/doebuild.py
@@ -156,7 +156,8 @@ def _doebuild_spawn(phase, settings, actionmap=None, 
**kwargs):
phase in _ipc_phases
kwargs['mountns'] = 'mount-sandbox' in settings.features
kwargs['networked'] = 'network-sandbox' not in settings.features or \
-   phase in _networked_phases or \
+   (phase in _networked_phases and \
+   'live' in settings.configdict['pkg'].get('PROPERTIES', 
'').split()) or \
'network-sandbox' in settings['PORTAGE_RESTRICT'].split()
kwargs['pidns'] = ('pid-sandbox' in settings.features and
phase not in _global_pid_phases)
-- 
2.22.0



signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Support PROPERTIES="live".

[Ulrich Mueller]

> On Mon, 29 Jul 2019, Michał Górny wrote:

> On Sun, 2019-07-28 at 17:21 -0700, Zac Medico wrote:
>> There could be another subset of packages that aren't quite "live" but
>> they need to fetch something that's immutable which can't be fetched via
>> a protocol supported by SRC_URI. Maybe call it
>> PROPERTIES="src-fetch-immutable" or something.

> Could you name one of those packages, and explain how are they not
> 'live' if they skip checksum verification?  I'm really against adding
> hundreds of weird-named items for the sake of potential use cases
> without a real benefit to it.

+1


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Support PROPERTIES="live".

[Ulrich Mueller]

> On Fri, 26 Jul 2019, Zac Medico wrote:

> Looks good. Please merge.

Will do, as soon as the live eclasses set PROPERTIES="live".

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] repoman: add 'user.eclass' to deprecated eclasses

[Ulrich Mueller]

> On Tue, 23 Jul 2019, Michał Górny wrote:

> Make repoman report user.eclass as deprecated by GLEP 81.

I don't understand. user.eclass is inherited by both acct-user.eclass
and acct-group.eclass, therefore in active use.

Or are you planning to inline its code in the inheriting eclasses?

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] repos.conf: default sync-webrsync-verify-signature

[Ulrich Mueller]

> On Tue, 09 Jul 2019, Zac Medico wrote:
 
> --- a/man/make.conf.5
> +++ b/man/make.conf.5
> @@ -1,4 +1,4 @@
> -.TH "MAKE.CONF" "5" "Jun 2019" "Portage VERSION" "Portage"
> +.TH "MAKE.CONF" "5" "Ju. 2019" "Portage VERSION" "Portage"

Typo.


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 2/2 v3] Update /usr/portage references (bug 378603)

[Ulrich Mueller]

> On Thu, 18 Apr 2019, Zac Medico wrote:

> --- a/man/ebuild.5
> +++ b/man/ebuild.5
> [...]
> @@ -553,8 +554,8 @@ usage.
>  .B LICENSE
>  This should be a space delimited list of licenses that the package falls
>  under.  This \fB_must_\fR be set to a matching license in
> -/usr/portage/licenses/. If the license does not exist in portage yet, you
> -must add it first.
> +/var/db/repos/gentoo/licenses/. If the license does not exist in portage
> +yet, you must add it first.

s/in portage/in the repository/

> --- a/man/portage.5
> +++ b/man/portage.5
> @@ -13,7 +13,7 @@ https://wiki.gentoo.org/wiki/Profile_(Portage)
>  .IP Note:
>  If you are looking for information on how to emerge something, please see
>  .BR emerge (1).
> -.SH "SYNOPSIS"
> +.SH "SYNOPSIS"/var/db/repos/gentoo

This change looks strange.

> [...]
> @@ -251,7 +251,7 @@ explaining how they can upgrade.
>  default-linux/x86/2005.0
>  # emerge -n '>=sys-apps/portage-2.0.51'
>  # rm -f /etc/portage/make.profile
> -# ln -s /usr/portage/profiles/default-linux/alpha/2005.0 \
> +# ln -s /var/db/repos/gentoo/profiles/default-linux/alpha/2005.0 \
>  /etc/portage/make.profile

Update the example?

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] collision_protect: use dynamic report interval

[Ulrich Mueller]

> On Tue, 08 Jan 2019, Fabian Groffen wrote:

> Output before this patch:

>  * checking 6111 files for package collisions
>  [...]

> After:

>  * checking 6158 files for package collisions
>  [...]

Why does the total number of files change?

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] ecompress-file: Support decompressing .lz

[Ulrich Mueller]

> On Sat, 17 Nov 2018, Michał Górny wrote:

> Signed-off-by: Michał Górny 
> ---
>  bin/ecompress-file | 3 +++
>  1 file changed, 3 insertions(+)

> diff --git a/bin/ecompress-file b/bin/ecompress-file
> index bc8fe5451..ccc2701c3 100755
> --- a/bin/ecompress-file
> +++ b/bin/ecompress-file
> @@ -29,6 +29,9 @@ compress_file() {
>   *.lzma|*.xz)
>   unxz -f "${x}" || __helpers_die "unxz failed"
>   x=${x%.*};;
> + *.lz)
> + lzip -df "${x}" || __helpers_die "lzip -d 
> failed"
> + x=${x%.lz};;
>   esac
 
>   filtered_args+=( "$x" )
> -- 
> 2.19.1

Does that mean that portage will gain a dependency on lzip now?

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] Re: [RFC] gpkg format proposal v2

[Ulrich Mueller]

> On Mon, 12 Nov 2018, Michał Górny wrote:

> Once tar is used for inner archive format, it is also a natural choice
> for the outer format.  If you believe we should use another format, that
> is introduce a second distinct archive format and depend on a second
> tool, you need to have a good justification for it.

Right, that's a better reason. :)

> So yes, ar is an option, as well as cpio.  In both cases the format is
> simpler (yet obscure), and the files are smaller.  But does that justify
> using a second tool that serves the same purpose as tar, given that tar
> works and we need to use it anyway?  Even if we skip the fact that ar is
> bundled as part of binutils rather than as stand-alone archiver, we're
> introducing unnecessarily complexity of learning a second tool.
> And both ar(1) and cpio(1) have weird CLI, compared to tar(1).

cpio is not feasible because of file size limitations (4 GiB IIRC).

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] Re: [RFC] gpkg format proposal v2

[Ulrich Mueller]

> On Mon, 12 Nov 2018, Michał Górny wrote:

>> Also, what would be wrong with ar? It's a standard POSIX tool, and
>> should be available everywhere.

> The original post says what's wrong with ar.  Please be more specific
> if you disagree with it.

AFAICS, the arguments are that ar would be obscure, and that the LSB
considers it deprecated. I don't find either of them convincing.
Since when do we care about the LSB?

Ulrich


signature.asc
Description: PGP signature

[gentoo-portage-dev] Re: [RFC] gpkg format proposal v2

[Ulrich Mueller]

> On Mon, 12 Nov 2018, Michał Górny wrote:

> On Mon, 2018-11-12 at 17:51 +0100, Fabian Groffen wrote:
>> I'm wondering here, how much sense does it make to compress 2., 3.
>> and/or 4. if you compress the whole gpkg?  I have the impression
>> compression on compression isn't beneficial here.  Shouldn't just
>> compressing of the gpkg tar be sufficient?

> Please read the spec again.  It explicitly says it's not compressed.

Isn't that the wrong way around? The tar format contains a lot of
padding, so using uncompressed tar for the outer archive would be
somewhat wasteful. Why not leave the inner tar files uncompressed, but
compress the whole binpkg instead?

Also, what would be wrong with ar? It's a standard POSIX tool, and
should be available everywhere.

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] install-qa-checks.d: Add a check for Gentoo path policies (FHS-y)

[Ulrich Mueller]

> On Tue, 04 Sep 2018, Michał Górny wrote:

> + # toplevel directories which can be installed to by ebuilds
> + # /home is not included as no ebuilds should install files there
> + local allowed_paths_toplevel=(
> + "${allowed_common_dirs[@]}"
> + boot dev etc opt srv usr var
> + # TODO: do we need it? gconf installs empty dir there but that's
> + # all
> + root
> + )

Does any package actually install files in /srv? (GLEP 20 suggested
that, but it wasn't accepted.)

> + # directories in /usr which can be installed to by ebuilds
> + local allowed_paths_usr=(
> + "${allowed_common_dirs[@]}"
> + include libexec share src
> + # toolchain stuff
> + "${CHOST}" "${CTARGET}"
> + )

Maybe add a comment that you've deliberately omitted games?

Ulrich


signature.asc
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] install-qa-check.d/60pngfix: parallel support (bug 630292)

[Ulrich Mueller]

> On Thu, 09 Aug 2018, Michał Górny wrote:

>> +if xargs --help | grep -q -- --max-procs=; then

> '--help' is not a valid argument on FreeBSD, so this spews errors
> to stderr:

IIRC, GNU findutils is required by PMS?

Ulrich

Re: [gentoo-portage-dev] [PATCH 2/2] Update /usr/portage references (bug 378603)

[Ulrich Mueller]

> On Mon, 6 Aug 2018, Brian Dolbec wrote:

> But that too can be changed along with all the user install
> documentation which will need to be updated as well.  The new
> recomended location should be /var/db/repos/local.  I will be updating
> layman for /var/db/repos/... as well.  That is the intention of the
> "repos/" subdir.

What is the exact plan for layman? IIUC, only the storage dir should
be changed to /var/db/repos, but the rest (cache, installed,
make_conf) would stay under /var/lib/layman?

> All these changes as well as the catlayst changes need to be
> co-ordinated so that snapshots and portage and stages don't precede
> the docs changes.

+1

Ulrich

Re: [gentoo-portage-dev] [PATCH 2/2] Update /usr/portage references (bug 378603)

[Ulrich Mueller]

> On Sun, 5 Aug 2018, Zac Medico wrote:

> --- a/cnf/make.conf.example
> +++ b/cnf/make.conf.example
> [...]

> @@ -119,16 +119,16 @@
>  # fetched on demand for a given build. If you would like to
>  # selectively prune obsolete files from this directory, see
>  # eclean from the gentoolkit package. Note that locations under
> -# /usr/portage are not necessarily safe for data storage. See the
> +# /var/db/repos/gentoo are not necessarily safe for data storage. See the
>  # PORTDIR documentation for more information.
> -#DISTDIR=/usr/portage/distfiles
> +#DISTDIR=/var/db/repos/gentoo/distfiles

Shouldn't this be /var/cache/distfiles ...

>  #
>  # PKGDIR is the location of binary packages that you can have created
>  # with '--buildpkg' or '-b' while emerging a package. This can get
>  # up to several hundred megs, or even a few gigs. Note that
> -# locations under /usr/portage are not necessarily safe for data
> +# locations under /var/db/repos/gentoo are not necessarily safe for data
>  # storage. See the PORTDIR documentation for more information.
> -#PKGDIR=/usr/portage/packages
> +#PKGDIR=/var/db/repos/gentoo/packages

... and /var/cache/binpkgs?

> --- a/lib/portage/cache/flat_hash.py
> +++ b/lib/portage/cache/flat_hash.py
> @@ -144,7 +144,7 @@ class database(fs_template.FsBased):
>   # Only recurse 1 deep, in order to 
> avoid iteration over
>   # entries from another nested cache 
> instance. This can
>   # happen if the user nests an overlay 
> inside
> - # /usr/portage/local as in bug #302764.
> + # /var/db/repos/gentoo/local as in bug 
> #302764.

Shouldn't a local overlay be in /var/db/repos/local, but never inside
of the gentoo repo?

> --- a/man/make.conf.5
> +++ b/man/make.conf.5
> @@ -219,10 +219,10 @@ Use the \fBPORTAGE_RO_DISTDIRS\fR variable to specify 
> one or
>  more read-only directories containing distfiles.
>  
>  Note
> -that locations under /usr/portage are not necessarily safe for data storage.
> +that locations under /var/db/repos/gentoo are not necessarily safe for data 
> storage.

IMHO this statement should be made much stronger.

>  See the \fBPORTDIR\fR documentation for more information.
>  .br
> -Defaults to /usr/portage/distfiles.
> +Defaults to /var/db/repos/gentoo/distfiles.

/var/cache/distfiles

> @@ -800,10 +800,10 @@ to it's category. However, for backward compatibility 
> with the layout
>  used by older versions of portage, if the \fI${PKGDIR}/All\fR directory
>  exists then all packages will be stored inside of it and symlinks to
>  the packages will be created in the category subdirectories. Note
> -that locations under /usr/portage are not necessarily safe for data storage.
> +that locations under /var/db/repos/gentoo are not necessarily safe for data 
> storage.

See above.

>  See the \fBPORTDIR\fR documentation for more information.
>  .br
> -Defaults to /usr/portage/packages.
> +Defaults to /var/db/repos/gentoo/packages.

/var/cache/binpkgs

> --- a/man/quickpkg.1
> +++ b/man/quickpkg.1
> @@ -17,7 +17,7 @@ modified since they were first installed.
>  .br
>  The packages, after being created, will be placed in \fBPKGDIR\fR.
>  This variable is defined in \fBmake.conf\fR(5) and defaults to
> -/usr/portage/packages.
> +/var/db/repos/gentoo/packages.

See above.

Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

[Ulrich Mueller]

> On Sun, 29 Jul 2018, Michael Orlitzky wrote:

> After thinking about this for a while, I think we should ignore setgid
> but not setuid executables. The problem with setuid and a non-root owner
> is that the owner can always exploit the situation:

> Suppose /bin/foo is owned by "foo" and setuid. If root (or any other
> privileged user) is about to run /bin/foo, then the "foo" user can
> simply strip away the setuid bit and fill /bin/foo with malicious code.

Staying with the man:man example, how would anybody become the "man"
user, in the first place? That user has /bin/false as a shell and no
valid password.

> The same situation with setgid is safe because (as far as I know)
> members of the group can't strip off the setgid bit.

Setgid executables shouldn't be group writable, so I believe that part
of the test is fine as-is in v1 of your patch.

Ulrich


pgppMBCz_RDB1.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.

[Ulrich Mueller]

> On Sun, 29 Jul 2018, Michael Orlitzky wrote:

> System executables that are not owned by root pose a security
> risk. The owner of the executable is free to modify it at any time;
> so, for example, he can change a daemon's behavior to make it
> malicious before the next time the service is started (usually by
> root).

> On a "normal" system, there is no good reason why the superuser should
> not own every system executable. This commit adds a new install-time
> check that reports any such binaries with a QA warning. To avoid false
> positives, non-"normal" systems (like prefix) are skipped at the moment.

Shouldn't this check for setuid binaries like /usr/bin/mandb (which is
owned by man:man)? I think these are legitimate usage case.

Ulrich


pgptqtrJo8E1U.pgp
Description: PGP signature

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

[Ulrich Mueller]

> On Fri, 9 Mar 2018, Michał Górny wrote:

> @@ -154,6 +165,12 @@ addread(){ __sb_append_var READ"$@" ; }
>  addwrite()   { __sb_append_var WRITE   "$@" ; }
>  adddeny(){ __sb_append_var DENY"$@" ; }
>  addpredict() { __sb_append_var PREDICT "$@" ; }
> +if ___eapi_has_sandbox_rm_functions; then
> + rmread() { __sb_remove_var READ"$@" ; }
> + rmwrite(){ __sb_remove_var WRITE   "$@" ; }
> + rmdeny() { __sb_remove_var DENY"$@" ; }
> + rmpredict()  { __sb_remove_var PREDICT "$@" ; }
> +fi

See my message to gentoo-pms [1], where I suggest to omit this feature
from EAPI 7. We should rather rethink if this is the best possible
interface.

Ulrich

[1] 
https://archives.gentoo.org/gentoo-pms/message/cf4bd0266f09245c02470e4fa3810947


pgpnhbMUIm3Z5.pgp
Description: PGP signature

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

[Ulrich Mueller]

> On Fri, 9 Mar 2018, Michał Górny wrote:

> +if ! ___eapi_has_nonfatal_as_executable; then
> + die "${0##*/} not supported as fallback helper in this EAPI"
> +fi

Nothing wrong with this, but this test isn't strictly necessary.
PMS says in [1]: "Except where otherwise noted, they may be internal
(shell functions or aliases) or external commands available in PATH;
where this is not specified, ebuilds may not rely upon either
behaviour."

So in EAPIs 0 to 6, Portage is free to implement it as shell function,
or external command, or both.

Ulrich

[1] https://projects.gentoo.org/pms/6/pms.html#x1-13100011.3.3


pgpQj9Jrmn1pd.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] repoman: Warn on = dependencies without * or revision

[Ulrich Mueller]

> On Sat, 3 Mar 2018, Michał Górny wrote:

> Warn if the '=' package dependency operator is used along with pure
> version with no revision specified. This means to catch a common mistake
> of developers copying '=' from upstream dependency specification while
> '~' operator would be more appropriate. This causes unintended depgraph
> breakage when the dependencies are revbumped e.g. due to dependency
> changes, or prevents people from upgrading.

> The developers are given two suggestions: either to use '~' if any
> revision is acceptable, or to explicitly specify '-r0' when they really
> do accept -r0 only.

I won't be opposed against this, but there doesn't seem to be any
policy that would require explicit -r0 in dependency specifications.
So this is a policy change which should be discussed in gentoo-dev
before it can be added to repoman.

Also according to PMS, no revision and -r0 (and even -r00) are
completely equivalent. so IMHO we should think twice before
introducing behaviour that would treat them differently in some
places.

Ulrich


pgpkTWCqrICrD.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

[Ulrich Mueller]

> On Sat, 03 Mar 2018, Michał Górny wrote:

> I don't really want to go into this. As far as I'm concerned, I can
> leave defunct '-d' and just check dev profiles unconditionally.

WFM. Or even better, leave defunct -d/--include-dev in place (in order
not to break peoples' scripts) and add a long --no-include-dev option.

Ulrich


pgppFpmvLee_2.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

[Ulrich Mueller]

> On Sat, 03 Mar 2018, Michał Górny wrote:

>> It seems counter-intuitive for a simple binary option to require an
>> argument. What is wrong with specifying -d to enable the option,
>> and simply not specifying it to disable?

> What is wrong is that a number of developers have historically not
> specified the option and broke stuff. Plus, it's infinitely silly to
> require people to explicitly specify the option to enable required
> behavior.

My remark was about syntax, not about semantics. "-d y" and "-d n"
instead of "-d" and "(nothing)" is a crappy user interface.

Maybe unify things into "--include-profiles=" (with a
comma separated list of "stable", "dev", and "exp") or
"--include-profile-level=" with n=0 for stable, n=1 for stable+dev,
etc.?

Ulrich


pgpRefoLzQiiY.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 3/3] repoman: Enable testing dev profiles by default

[Ulrich Mueller]

> On Sat, 3 Mar 2018, Michał Górny wrote:
 
>   parser.add_argument(
>   '-d', '--include-dev-profiles', choices=('y', 'n'), 
> metavar='',
> - default='n',
> + default='y',
>   help='include dev profiles in dependency checks')

It seems counter-intuitive for a simple binary option to require an
argument. What is wrong with specifying -d to enable the option, and
simply not specifying it to disable?

Ulrich


pgpXXL5a128zO.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] repoman: Add commit message verification

[Ulrich Mueller]

>>>>> On Sun, 04 Feb 2018, Michał Górny wrote:

> W dniu sob, 03.02.2018 o godzinie 09∶58 +0100, użytkownik Ulrich Mueller
> napisał:
>> > Add a check for common mistakes in commit messages. For now, it
>> > is pretty rough and exits immediately but it should be integrated
>> > with the editor in the future.
>> 
>> Have you tested this against existing commits in the gentoo repo?

> After checking the 1 most recent commits, I have the following
> stats on invalid commit messages:

> [...]

> Most of the violations are uses of Gentoo-Bug and very long
> single-line commit messages; most likely people using '-m "very long
> message because I am lazy and can't use editor properly"'.

> Full list of violations in the sample:
> https://gist.github.com/mgorny/fa81ffe07ca9565198e4e44fb040bb19

IMHO this shows that some of the tests are too rigid. Especially,
"body lines should be wrapped at 72 characters" often triggers in
cases where rewrapping wouldn't improve readability.

Since GLEP 66 says that "the body *should* be wrapped at 72
characters" (my emphasis), I would suggest to relax this test a bit
and only flag body lines longer than 80 characters. Also, any lines
containing long URIs should be excluded from the test.

Ulrich


pgpfHhBhi2Jyg.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] repoman: Add commit message verification

[Ulrich Mueller]

> On Fri, 2 Feb 2018, Michał Górny wrote:

> Add a check for common mistakes in commit messages. For now, it is
> pretty rough and exits immediately but it should be integrated with
> the editor in the future.

Have you tested this against existing commits in the gentoo repo?

Ulrich


pgp9WrL5Q8VBT.pgp
Description: PGP signature

Re: [gentoo-portage-dev] Re: [PATCH v2 3/3] _emerge.Ebuild*: delay creating DISTDIR shadow until src_unpack

[Ulrich Mueller]

> On Thu, 25 Jan 2018, Zac Medico wrote:

> It seems to be a common assumption that it's allowed, this command
> currently shows 163 results in the gentoo repo:

> git grep -l pkg_nofetch | xargs grep 'e\(log\|info\).*DISTDIR' | wc -l

There will be little breakage if it is only used in elog messages.

> We should double check with the PMS maintainers to see if they think
> it's worthy of an exception. Otherwise, we need to announce the
> issue on the gentoo-dev mailing list.

PMS had never defined DISTDIR in pkg_* phases. You can see this e.g.
in the PMS version from 2010 [1].

In addition to this, the following clarification of variables' scope
was approved by the council in 2017 [2]:

| 6. Scope and consistency of FILESDIR and DISTDIR
| 
| Old: src_* (not consistent across ebuild phases)
| New: src_*, global scope (consistent). No access to the dir in
| global scope.
|
| Rationale: These variables must be defined in global scope for
| assignment of the PATCHES variable in EAPI 6. However, the actual
| directories are not necessarily present in global scope (e.g., when
| installing from a binary package) and therefore must not be accessed
| there.

Ulrich


[1] https://projects.gentoo.org/pms/3/pms.html#x1-117002
[2] https://bugs.gentoo.org/616206


pgpudLoADGanK.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [gentoolkit] eshowkw: Improve & reorder keywords for my Bugzie proposal

[Ulrich Mueller]

> On Tue, 23 Jan 2018, Michał Górny wrote:

> Here's a short set of patches that reworks eshowkw keyword display
> & ordering to match my Bugzilla proposal [1]. Also, it fixes the wrong
> classification of *-fbsd as Prefix arch.

> Example output:
> - https://dev.gentoo.org/~mgorny/tmp/short.png (without -P)
> - https://dev.gentoo.org/~mgorny/tmp/long.png (with -P)

Two points:
1. For prefix, can you use the same ordering as in KEYWORDS? That
   is, sort by the part after the hyphen first (i.e. aix, cygwin, ...,
   winnt), then by the part before it.
2. sparc-fbsd is grouped with prefix. Is that intentional?

Ulrich


pgpOPUifhTrOS.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Completely ban external commands in global scope

[Ulrich Mueller]

> On Fri, 8 Sep 2017, Robin H Johnson wrote:

> On Thu, Aug 31, 2017 at 10:45:42PM +0200, Michał Górny wrote:
>> +export PATH=/dev/null
> Minor nitpick: The Single UNIX spec says that PATH is a set of
> prefixes, and that they're treated as directories.
> http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html

> I think it might be good to use either a non-existing path, or a
> known empty directory (/var/empty), rather than /dev/null which DOES
> exist.

Is /var/empty standard? On my system here, it belongs to
net-misc/openssh.

Also any /dev/null/foo is guaranteed not to exist, so I don't see how
pathname resolution could possibly succeed when PATH is /dev/null.

Ulrich


pgpVY9QRev455.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] ebuild.sh: Explicitly ban get_libdir in global scope

[Ulrich Mueller]

> On Wed, 30 Aug 2017, Zac Medico wrote:

> It's possible that there are working ebuilds that call get_libdir in
> global scope.

How could that be possible when get_libdir() is defined in
phase-helpers.sh?

> Have we done an analysis of the ebuilds in the gentoo repository?
> Obviously, it would be safer to call eqawarn.

Ulrich


pgpY_GOdKdi2j.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX

[Ulrich Mueller]

>>>>> On Wed, 19 Apr 2017, Ulrich Mueller wrote:

>> +if [[ ${target:0:1} == "/" && ${target} != "${EPREFIX}"* ]]; then

> I think you want an additional slash in the second condition, in order
> to prevent /foo/barbaz from matching if EPREFIX is equal to /foo/bar:

> if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then

>> +target="${EPREFIX}${target}"

One more point, maybe output a QA warning here?

>> +fi
>> ln -snf "${target}" "${ED}${2}"
>> 
>> ret=$?

Ulrich


pgpnbu32eKtEv.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] dosym: protect Prefix hack from double EPREFIX

[Ulrich Mueller]

> On Wed, 19 Apr 2017, Michał Górny wrote:

> Add an additional conditional to the dosym Prefix hack to ensure that
> the symlink is not using double Prefix when the ebuild uses ${EPREFIX}
> explicitly. This ensures that Portage on Prefix systems is both
> compatible with the ebuilds relying on the hack, and using dosym
> in the PMS-defined manner.
 
 
>  destdir=${2%/*}
>  [[ ! -d ${ED}${destdir} ]] && dodir "${destdir}"
> -# when absolute, prefix with offset for Gentoo Prefix
>  target="${1}"
> -[[ ${target:0:1} == "/" ]] && target="${EPREFIX}${target}"
> +# DEPRECATED HACK: when absolute, prefix with offset for Gentoo Prefix
> +# (but only if ${EPREFIX} is not there already)

Maybe add a date (like 2018-04-30) to the comment after which the code
can be removed?

> +if [[ ${target:0:1} == "/" && ${target} != "${EPREFIX}"* ]]; then

I think you want an additional slash in the second condition, in order
to prevent /foo/barbaz from matching if EPREFIX is equal to /foo/bar:

if [[ ${target:0:1} == "/" && ${target}/ != "${EPREFIX}"/* ]]; then

> + target="${EPREFIX}${target}"
> +fi
>  ln -snf "${target}" "${ED}${2}"
>  
>  ret=$?

Ulrich


pgpkQoluwZQnU.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [RFC] eslurp helper

[Ulrich Mueller]

> On Sun, 26 Mar 2017, Michał Górny wrote:

> I'm thinking of creating a new helper in Portage. The draft name is
> eslurp. It would be used like:

>   eslurp [--dist|--binpkg] ...

+1

The name will need some bikeshedding, though. :)
I suggest "edrop" or "einsert".

> i.e. it would have two modes:

> 1. --dist would place all listed files in DISTDIR (respecting any
> possible future DISTDIR split),

> 2. --binpkg would place all listed packages in PKGDIR (respecting
> subdirectories, updating index).

> If neither of the options were specified, it would guess the
> directory type by the filename suffix.

I wonder how that could possibly work. Distfiles have no specific
suffix, and binpkgs have a .tbz2 suffix which however can occur for
distfiles too.

Ulrich


pgpxAExMXnxXE.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] phase-helpers.sh: Loop over A rather than SRC_URI in __eapi0_pkg_nofetch.

[Ulrich Mueller]

>>>>> On Thu, 23 Mar 2017, Ulrich Mueller wrote:

>>>>> On Thu, 23 Mar 2017, Zac Medico wrote:
>> On Thu, Mar 23, 2017 at 2:55 AM, Ulrich Müller <u...@gentoo.org> wrote:
>>> Looping over SRC_URI also outputs non-filename elements (e.g, use
>>> conditionals) which is avoided when looping over A.
>>> 
>>> Gentoo-Bug: 613132
>>> ---
>>> bin/phase-helpers.sh | 8 
>>> 1 file changed, 4 insertions(+), 4 deletions(-)

>> Looks good.

> Presumably we should wait for the ack (or rather the usual consensus
> timeout) of the corresponding PMS patch:
> https://archives.gentoo.org/gentoo-pms/message/6044537cd2cd36bc23307918a9afced9

Pushed.


pgpy3h8Z_85CP.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] phase-helpers.sh: Loop over A rather than SRC_URI in __eapi0_pkg_nofetch.

[Ulrich Mueller]

> On Thu, 23 Mar 2017, Zac Medico wrote:

> On Thu, Mar 23, 2017 at 2:55 AM, Ulrich Müller  wrote:
>> Looping over SRC_URI also outputs non-filename elements (e.g, use
>> conditionals) which is avoided when looping over A.
>> 
>> Gentoo-Bug: 613132
>> ---
>> bin/phase-helpers.sh | 8 
>> 1 file changed, 4 insertions(+), 4 deletions(-)

> Looks good.

Presumably we should wait for the ack (or rather the usual consensus
timeout) of the corresponding PMS patch:
https://archives.gentoo.org/gentoo-pms/message/6044537cd2cd36bc23307918a9afced9

Ulrich


pgp1eMEcTz3O8.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] portage.package.ebuild: Use a fake FILESDIR to catch invalid accesses

[Ulrich Mueller]

> On Thu, 16 Mar 2017, Michał Górny wrote:

> + mysettings["FILESDIR"] = os.path.join(settings["PORTAGE_BUILDDIR"], 
> "files")

I believe that this contradicts current PMS 11.1, which defines
FILESDIR as follows: "The full path to the package's files directory,
used for small support files or patches. See section 4.3."

So maybe you should first propose a clarification of the PMS wording?

Ulrich


pgpmZkYwR2dxH.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] news: Support News-Item-Format 2.0

[Ulrich Mueller]

> On Sat, 3 Sep 2016, Zac Medico wrote:

> If we wanted to be more strict about the input that we accept, we
> could limit the profile wildcard match to so that it only works if
> the format is 2.* and only supports a terminal /* since that's all
> that the spec says is supported.

Please do.

GLEP 42 says:
"In news item format 2.0, a terminal asterisk immediately following a
slash acts as a wildcard for any further path components, for example
default/linux/*."

Ulrich


pgpmyroVujnKk.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] Print WORKDIR & D sizes in build logs

[Ulrich Mueller]

> On Sun, 27 Dec 2015, Michał Górny wrote:

> ---
>  bin/phase-functions.sh | 9 +
>  1 file changed, 9 insertions(+)

> diff --git a/bin/phase-functions.sh b/bin/phase-functions.sh
> index 0b853bf..6a47fed 100644
> --- a/bin/phase-functions.sh
> +++ b/bin/phase-functions.sh
> @@ -593,6 +593,15 @@ __dyn_install() {
>   __vecho
>   __ebuild_phase post_src_install
 
> + # record build & installed size in build log
> + if type -P du &>/dev/null; then
> + local sz=( $(du -ks "${WORKDIR}") )
> + einfo "Final size of build directory: ${sz[0]} KiB"
> + sz=( $(du -ks "${D}") )
> + einfo "Final size of installed tree: ${sz[0]} KiB"
> + __vecho
> + fi
> +
>   cd "${PORTAGE_BUILDDIR}"/build-info
>   set -f
>   local f x
> -- 
> 2.6.4

Will this be called before or after prepcompress?

Ulrich


pgpcKy53y1gSh.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] EAPI 6: Fail if eapply_user is not called in src_prepare()

[Ulrich Mueller]

> On Tue, 17 Nov 2015, Zac Medico wrote:

>> What happens if an ebuild calls eapply_user in src_unpack but not
>> in src_prepare?

> It will succeed in that case.

It should die if it isn't called in src_prepare.

> If necessary, we can make eapply_user die if it's called during the
> wrong phase.

That's not really mandated by the spec, but I think such extra
strictness would be a good idea.

Ulrich


pgprOjJy0HKZs.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] EAPI 6: Fail if eapply_user is not called in src_prepare()

[Ulrich Mueller]

> On Tue, 17 Nov 2015, Michał Górny wrote:

>   __ebuild_phase src_prepare
> +
> + # keep path in eapply_user in sync!
> + if [[ ! -f ${T}/.portage_user_patches_applied ]]; then
> + die "eapply_user (or default) must be called in src_prepare()!"
> + fi
> +

What happens if an ebuild calls eapply_user in src_unpack but not
in src_prepare?

Ulrich


pgp82vwaobi1U.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels

[Ulrich Mueller]

> On Fri, 13 Nov 2015, Michał Górny wrote:

> Ok, I recalled the issue I was particularly concerned about.

>   PV="1_beta2"
>   MY_PV="${PV/_/~}"

> This triggers different behavior between bash<=4.2 and bash>=4.3,
> with the latter requiring:

>   PV="1_beta2"
>   MY_PV="${PV/_/\~}"

> (which in turns breaks older). Now, if someone put a conditional on
> BASH_VERSINFO that worked around this discrepancy, introducing
> BASH_COMPAT suddenly breaks it by forcing the old behavior when
> BASH_VERSINFO indicates the new behavior is expected.

> Not saying this is very likely to happen.

Highly unlikely, IMHO. There are several workarounds that are simpler
than making the code conditional on the bash version. For example:

   tilde="~"; MY_PV="${PV/_/${tilde}}"

or:

   MY_PV="${PV/_/$'\x7e'}"

> However, we are clearly violating the idea behind PMS by allowing it
> to happen retroactively.

Not sure. PMS is (and always was) quite clear about which bash version
belongs to which EAPI, so ebuilds have no business of circumventing
this by doing their own version checks.

> However, enabling BASH_COMPAT in EAPI 6 is a good thing. For
> example, because people in EAPI 6 no longer need to be concerned
> about this discrepancy.

Enabling it for EAPI 6 only will lead to the paradoxical situation
that bash will be compatible to 4.2 in EAPI 6, as it should be.
Whereas earlier EAPIs (which should use 3.2 really) will get the
behaviour of bash 4.3 or later instead.

Ulrich


pgpXfica1utMs.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 1/2] Warn if LC_CTYPE does not transform ASCII chars like POSIX

[Ulrich Mueller]

> On Sat, 14 Nov 2015, Michał Górny wrote:

> Output a warning if LC_CTYPE is set to a value that causes libc
> toupper() and/or tolower() conversions not apply correctly to
> printable ASCII characters.

The wording of the spec is "The package manager must ensure [...]",
therefore I think a warning is not enough here.

Maybe add a fallback to en_US.UTF-8, then to POSIX?

Ulrich


pgpyUmCseVJxI.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels

[Ulrich Mueller]

> On Thu, 12 Nov 2015, Zac Medico wrote:

> On 11/12/2015 04:06 PM, Mike Frysinger wrote:
>> from ebuilds/eclasses that have already stopped using __:
>> __do_sed_fix ()
>> ___ECLASS_RECUR_MULTILIB=yes
>> ___ECLASS_RECUR_TOOLCHAIN_FUNCS=yes
>> __versionator_shopt_toggle ()
>> __versionator__test_version_compare ()
>> __versionator__test_version_is_at_least ()
>> 
>> grepping the tree, i see like two packages and one eclass still using __.
>> both of which are trivial to convert.

> Sure, but do we really want to confuse people who might be ignorant of
> this rule? Having functions disappear from the environment without
> warning is very likely to cause confusion...

Maybe repoman should make people aware of this rule then?

Ulrich


pgpzQwU1HBa1r.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels

[Ulrich Mueller]

> On Wed, 11 Nov 2015, Michał Górny wrote:

> I'm not convinced we ought to do this for EAPI < 6. It is a breaking
> change after all, and as such changes the behavior of EAPI < 6
> ebuilds.

Which according to PMS should assume bash version 3.2. Also, AFAICS
the only feature where the compat settings could have any impact is
this setting from compat42:

   If set, bash does not process the replacement string in the pattern
   substitution word expansion using quote removal.

All other compat changes affect either only POSIX mode, or interactive
mode, or string comparison (where the compat32 setting disables locale
specific behaviour and uses strcmp instead, so effectively the compat
setting should be saner).

> There are some ebuilds/eclasses that have bash version checks,
> and execute bash-4 code when bash-4 is available. As far as I
> understand, this will effectively prohibit bash-4 code even though
> BASH_VERSINFO will still indicate bash-4 is being used. 

The compat settings don't disable any new features. They only restore
previous behaviour where there was an incompatible change.

Ulrich


pgpUvQguzzIMa.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH] ebuild: set up bash compat levels

[Ulrich Mueller]

> On Tue, 10 Nov 2015, Mike Frysinger wrote:

> + # Set the compat level in case things change with newer ones.  We must 
> not
> + # export this into the env otherwise we might break  other shell 
> scripts we
> + # execute (e.g. ones in /usr/bin).
> + BASH_COMPAT="${maj}.${min}"
> +
> + # The variable above is new to bash-4.3.  For older versions, we have 
> to use
> + # a compat knob.  Further, the compat knob only exists with older 
> versions
> + # (e.g. bash-4.3 has compat42 but not compat43).  This means we only 
> need to
> + # turn the knob with older EAPIs, and only when running newer bash 
> versions:
> + # there is no bash-3.3 (it went 3.2 to 4.0), and when requiring 
> bash-4.2, the
> + # var works with bash-4.3+, and you don't need to set compat to 4.2 
> when you
> + # are already running 4.2.
> + if __eapi_bash_3_2 && [[ ${BASH_VERSINFO[0]} -gt 3 ]] ; then
> + shopt -s compat32
> + fi

Wouldn't this profit from an additional test for 

[gentoo-portage-dev] Re: [gentoo-dev] [PATCH] pym/portage/news.py: let slackers copy+paste the news read command

[Ulrich Mueller]

 On Thu, 29 Jan 2015, Zac Medico wrote:

 -print(Use  + colorize(GOOD, eselect news) +  to read 
 news items.)
 +print(Use  + colorize(GOOD, eselect news read new) +  to 
 read new items.)

 I guess that's fine, but I have to wonder how many people are really
 that lazy. To me, it actually seems like more effort to highlight the
 span of characters with the mouse than it does to type them out.

 Also, when the work read appears twice on a short line like that, it
 gives a wordy/redundant feeling.

Also new is the default for eselect's read action, therefore
eselect news read would be enough.

Ulrich


pgpjeToyup0vH.pgp
Description: PGP signature

Re: [gentoo-alt] Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types

[Ulrich Mueller]

 On Sun, 07 Dec 2014, Zac Medico wrote:

 On 12/07/2014 07:06 PM, Christoph Junghans wrote:
 I know, I am late to the party, I just wanted to say that in
 unpacker.eclass I implemented a variant which uses neither deb2tags
 nor ar on prefix, but just bash's read and head.

The code uses head -c which is a GNU extension:

   $ man 1p head
   HEAD(1P)POSIX Programmer's ManualHEAD(1P)
   [...]
   SYNOPSIS
  head [−n number] [file...]
   [...]

For example, on OpenBSD and HPUX there is no -c option, or it is used
differently. Also Busybox doesn't have it.

Are we better off by requiring GNU head instead of GNU ar?

 Very nice. We should borrow that code and use it to eliminate the
 need for deb2targz in portage.

In PMS, this would have to go into EAPI 6, I suppose?

Ulrich


pgpfesq0ME4CD.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types

[Ulrich Mueller]

 On Sat, 06 Dec 2014, Zac Medico wrote:

 The PMS people should be *very* interested in any changes to unpack
 behavior like this. It supports behavior that will lead to failures for
 older versions of portage and other package managers.

Some remarks:

- The upstream deb2targz program supports only data.tar.gz. Only the
  Gentoo version has been patched up to support other file types.

- There is only a single package in the tree with a dependency on
  app-arch/deb2targz, and this only on AIX [1]. So on most users'
  systems deb2targz will not be installed, and ar x will be used for
  unpacking.

- Paludis and Pkgcore unconditionally use ar x for unpacking.

- PMS says [2]:

 deb packages (*.deb). Ebuilds must ensure that the deb2targz
 program is installed on those platforms where the GNU binutils
 ar program is not available and the installed ar program is
 incompatible with GNU archives. Otherwise, ebuilds must ensure
 that GNU binutils is installed.

  One could conclude that GNU binutils ar should be used on platforms
  where it is available. deb2targz should be used only where ar is
  incompatible with the GNU version.

So in any case, this is a problem of Portage only. I'd suggest to
change the logic in unpack() as follows:

if ar is GNU; then
ar x ...
elif deb2targz installed; then
deb2targz ...
else
ar x ...
fi

And then the deb2targz case could be patched as proposed. After all,
it is only a fallback that should be compatible with ar x
extraction.

Ulrich

[1] http://qa-reports.gentoo.org/output/genrdeps/dindex/app-arch/deb2targz
[2] http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-14100011.3.3.13


pgph26utPMmUN.pgp
Description: PGP signature

Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types

[Ulrich Mueller]

 On Sun, 07 Dec 2014, Zac Medico wrote:

 Anyway, Brian's patch for xz support with debt2targz appears to be
 compatible with other package managers as well as AIX, so that seems
 like a good way to go.

I still think that ar should always be used on platforms where GNU
binutils is installed. Currently unpack uses deb2targz when it finds
the program, which is not a well defined behaviour.

Ulrich


pgppXonqP1VjG.pgp
Description: PGP signature

Re: [gentoo-alt] Re: [gentoo-portage-dev] [PATCH 1/2] bin/phase-helpers.shL Fix unpack() for deb2targz .xz types

[Ulrich Mueller]

 On Sun, 07 Dec 2014, Zac Medico wrote:

 On 12/07/2014 11:23 AM, Fabian Groffen wrote:
 FYI:
 
 % portageq envvar CHOST
 x86_64-apple-darwin13
 % ar --version
 ar: illegal option -- -
 usage:  ar -d [-TLsv] archive file ...
 [...]

 It's hard to whitelist it if doesn't support --version, so it seems
 reasonable to require deb2targz whenever ar is not GNU ar.

unpack will still use ar if deb2targz is not installed. So on Darwin,
behaviour should be the same as before.

Ulrich


pgpPQEfcOLwSJ.pgp
Description: PGP signature