[gentoo-portage-dev] [PATCH] Add the has function to the ebuild(5) man page.

I WTF'ed on this for a long time before I noticed that the docs for has were sort-of contained in hasv. Might as well give has its own. From 423123cc2ea429c06914ef858a6fdb86c0c6d30b Mon Sep 17 00:00:00 2001 From: Michael Orlitzky m...@gentoo.org Date: Wed, 22 Jan 2014 16:18:23 -0500 Subject

Re: [gentoo-portage-dev] [RFC] Add 'emerge --sync-glsa' action and 'emaint sync-glsa' command

On 12/17/2014 05:32 PM, Brian Dolbec wrote: Only code changes I see to portage, pkgcore (I know nothing about paludis) are to look for the glsa's in the 2 possible locations. The standalone glsa repo, failing that, backup to the gentoo tree. Could we ship a GLSA overlay enabled by

Re: [gentoo-portage-dev] Re: [PATCHv3 1/2] MEDIUM: misc-functions: Be more quiet when removing non existing INSTALL_MASK

On 04/21/2015 01:28 PM, Zac Medico wrote: The docs for INSTALL_MASK (man 5 make.conf) don't mention that globs will work. It's expecting a space delimited list of file names. Does it really take a space-delimited list of globs instead? If so, how does that reconcile with the fact that * could

Re: [gentoo-portage-dev] Re: [PATCHv3 1/2] MEDIUM: misc-functions: Be more quiet when removing non existing INSTALL_MASK

On 04/21/2015 05:48 AM, Duncan wrote: Well, I don't use INSTALL_MASK myself, so I don't have a real-world use-case for you. However, it's clear that the code will expand shell globs, so I preserved that behavior for compatibility. I do, with shell globs, tho I didn't bother checking the

[gentoo-portage-dev] [PATCH 0/2] Document globbing for INSTALL_MASK.

This documents shell globs in INSTALL_MASK and warns about filenames containing spaces. I also added a few more comments to the code after I figured out what it was going. Michael Orlitzky (2): bin/misc-functions.sh: Elaborate on some comments in install_mask(). man/make.conf.5: Document

[gentoo-portage-dev] [PATCH 1/2] bin/misc-functions.sh: Elaborate on some comments in install_mask().

--- bin/misc-functions.sh | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh index 9b79351..c2ff70a 100755 --- a/bin/misc-functions.sh +++ b/bin/misc-functions.sh @@ -261,20 +261,30 @@ install_mask() { shift

[gentoo-portage-dev] [PATCH 0/1] Test PMS-compliant usage of the ROOT variable.

that are not so easy to fix will stand out once the trivial ones are. Perhaps in EAPI-$next, the warning can become an error. Michael Orlitzky (1): Add a test case for PMS-compliant usage of the ROOT variable. ebuild-test/root-var-usage/metadata.xml| 24 ++ ebuild-test/root-var

Re: [gentoo-portage-dev] [PATCH 1/1] Add a test case for PMS-compliant usage of the ROOT variable.

On 05/11/2016 12:33 PM, Brian Dolbec wrote: > > I'll work on adding this check to repoman after I finish getting some > in progress changes done so the new repoman code can be released. > I took a look at the new code and it was really easy to get something working. I added a new QA category,

Re: [gentoo-portage-dev] [PATCH] sys-apps/portage: add native-extensions USE flag (bug 571444)

On 02/01/2017 04:03 PM, Michał Górny wrote: >> SLOT="0" >> -IUSE="build doc epydoc +ipc linguas_ru selinux xattr" >> +IUSE="build doc epydoc +ipc linguas_ru native-extensions selinux >> xattr" > > Wouldn't it be better to enable it by default? > Please don't enshrine personal preferences into

Re: [gentoo-portage-dev] [PATCH v2] emerge: auto-enable --with-bdeps if --usepkg is not enabled (bug 598444)

On 03/05/2017 02:12 PM, Zac Medico wrote: > > Incorrect. > > ... > > Incorrect. > I see my mistakes, but maintain that this is confusing =) > > The --with-bdeps-auto option results in desirable behavior by default, > and it's also backward compatible with existing --with-bdeps and >

Re: [gentoo-portage-dev] [PATCH v2] emerge: auto-enable --with-bdeps if --usepkg is not enabled (bug 598444)

On 03/05/2017 03:40 AM, Zac Medico wrote: > > A new --with-bdeps-auto= option is provided, making it possible to > enable or disable the program logic that causes --with-bdeps to be > automatically enabled. Use --with-bdeps-auto=n to prevent --with-bdeps > from being automatically enabled

Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

On 01/10/2018 03:13 PM, Michał Górny wrote: > Remove empty directories in install-qa-check phase in order to prevent > Portage from installing them, and therefore from developers relying > on them being installed. This is going to break a lot of packages whose build systems create e.g.

Re: [gentoo-portage-dev] [PATCH v2] install-qa-check: Do not install empty directories

On 01/10/2018 03:55 PM, Zac Medico wrote: >> >> This is going to break a lot of packages whose build systems create e.g. >> /var/lib/foo and do nothing with it immediately. The ebuild should be >> calling keepdir on those paths, but how would anyone know that? > > If we consider that portage

[gentoo-portage-dev] [PATCH 1/2] man/ebuild.5: document that dodir is for nonempty directories.

--- man/ebuild.5 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index 42a0599fe..9dd969b03 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -1267,11 +1267,12 @@ that this expression does \fBNOT\fR use the offset prefix. runs sed on

[gentoo-portage-dev] [PATCH 0/2] man page updates to promote keepdir usage

The main barrier to proper keepdir usage is that nobody knows what it's for. These two commits update the ebuild (5) man page with an explanation, namely that empty directories are undefined by the PMS. Michael Orlitzky (2): man/ebuild.5: document that dodir is for nonempty directories. man

[gentoo-portage-dev] [PATCH 2/2] man/ebuild.5: document the rationale for using keepdir over dodir.

--- man/ebuild.5 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index 9dd969b03..5e2fdbcf5 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -1285,8 +1285,9 @@ Sets the root (\fIDESTTREE\fR) for other functions like \fBdobin\fR, The default

[gentoo-portage-dev] [PATCH v2 2/2] man/ebuild.5: document the rationale for using keepdir over dodir.

--- man/ebuild.5 | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index 28e9582d1..8784a14ee 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -1285,8 +1285,9 @@ Sets the root (\fIDESTTREE\fR) for other functions like \fBdobin\fR, The default

[gentoo-portage-dev] [PATCH v2 1/2] man/ebuild.5: document that dodir is for nonempty directories.

--- man/ebuild.5 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/man/ebuild.5 b/man/ebuild.5 index 42a0599fe..28e9582d1 100644 --- a/man/ebuild.5 +++ b/man/ebuild.5 @@ -1271,7 +1271,8 @@ Creates directories inside of ${ED}. .br .BR 'dodir\ /usr/lib/apache' creates

[gentoo-portage-dev] [PATCH v2 0/2] man page updates to promote keepdir usage

by "is (non)empty." Michael Orlitzky (2): man/ebuild.5: document that dodir is for nonempty directories. man/ebuild.5: document the rationale for using keepdir over dodir. man/ebuild.5 | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- 2.13.6

Re: [gentoo-portage-dev] [PATCH v3] install-qa-check: New QA check/cleanup for empty directories

On 01/30/2018 02:23 AM, Michał Górny wrote: > Warn about empty directories installed to /var Why only warn about /var, considering that FEATURES=strict-keepdir will delete the others? People will probably assume that if their package throws no warnings, it's strict-keepdir-safe.

Re: [gentoo-portage-dev] [PATCH] emerge: add --changed-deps-report option (bug 645780)

Since ::gentoo is the only repository governed by the PMS, can't we make repoman do this? The problem with requiring "repoman --force" for an in-place dependency change is that repoman generally won't have access to the unedited ebuild; but for ::gentoo, we can probably hack something together in

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

On 07/29/2018 03:43 PM, Ulrich Mueller wrote: > > Shouldn't this check for setuid binaries like /usr/bin/mandb (which is > owned by man:man)? I think these are legitimate usage case. > In general, yeah. I think we should be skeptical of setuid/gid executables, but this isn't the right place to

[gentoo-portage-dev] [PATCH 0/2] Two insecure ownership and group-writability QA checks.

Discussed and implemented in, https://bugs.gentoo.org/629398 Michael Orlitzky (2): bin/install-qa-check.d: add new 90bad-bin-owner QA check. bin/install-qa-check.d: add new 90bad-bin-group-write QA check. bin/install-qa-check.d/90bad-bin-group-write | 40 bin

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

System executables that are writable by a non-root user pose a security risk. Anyone who can write to an executable can change its behavior. If that executable is later run with elevated privileges (say, by root, when the machine starts), then the non-root user can escalate his own privileges to

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

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

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

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

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

System executables that are writable by a non-root user pose a security risk. Anyone who can write to an executable can change its behavior. If that executable is later run with elevated privileges (say, by root, when the machine starts), then the non-root user can escalate his own privileges to

[gentoo-portage-dev] [PATCH v2 0/2] Two insecure ownership and group-writability QA checks.

. Michael Orlitzky (2): bin/install-qa-check.d: add new 90bad-bin-owner QA check. bin/install-qa-check.d: add new 90bad-bin-group-write QA check. bin/install-qa-check.d/90bad-bin-group-write | 49 bin/install-qa-check.d/90bad-bin-owner | 47

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

On 07/29/2018 09:16 PM, Ulrich Mueller wrote: > > 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. One way would be to exploit a process that's running as the "man" user. Ostensibly such

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

On 07/29/2018 03:43 PM, Ulrich Mueller wrote: > >> 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"

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

On 08/07/2018 01:34 PM, Zac Medico wrote: > > Why not use ${ED%/} instead of ${D%/} here, so that the output is the > same regardless of ${EPREFIX}? > We want to show where the executable was actually installed, and generally that includes EPREFIX. For example, I'd want to see

[gentoo-portage-dev] [PATCH v3 2/2] bin/install-qa-check.d: add new 90bad-bin-group-write QA check.

System executables that are writable by a non-root user pose a security risk. Anyone who can write to an executable can change its behavior. If that executable is later run with elevated privileges (say, by root, when the machine starts), then the non-root user can escalate his own privileges to

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

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, the

[gentoo-portage-dev] [PATCH v3 0/2] Two insecure ownership and group-writability QA checks.​

Changes in v3: * Undo the setguid exception from v2, and add a comment explaining why. * Add line breaks for readability in two comments. * Try to put back the leading "/" in the output list. * Remove a superfluous comment mentioning the "prefix." Michael Orlitzky (

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

On 09/04/2018 01:53 PM, Michał Górny wrote: > + # TODO: do we need it? gconf installs empty dir there but that's > + # all > + root FWIW, we should not allow this.

Re: [gentoo-portage-dev] [PATCH] f{owners,perms}: Warn when using relative path

On 09/17/2018 02:52 AM, Michał Górny wrote: > > --- a/bin/ebuild-helpers/fowners > +++ b/bin/ebuild-helpers/fowners > ... > + eqawarn "This is unsupported. Please use 'chmod' when you need > to work on files" This one should be 'chown' instead of 'chmod'. (Calling chown on the live

Re: [gentoo-portage-dev] [RFC] Adding extra vars to md5-cache, for QA purposes

On 7/25/19 4:29 PM, Michał Górny wrote: >> >> * In the md5-cache entry, maybe use a common prefix like EXT_ for the >> extra keys in order to distinguish them from normal keys. > > Yeah, I was thinking of something like '__ext_foo', or '__ext[foo]'. > What are the pros/cons of this? The names

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

On 12/13/19 9:28 AM, Fabian Groffen wrote: > > We are providing those patches, maybe. In reality very often the > patches originate from somewhere else though. And you don't want to > have to respin all of those just because. At least that's what I feel. > Just because... the context

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

On 12/12/19 3:15 PM, Ulrich Mueller wrote: > > 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. It would only break the build for the maintainer, who would then

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

On 11/27/19 2:17 PM, Michał Górny wrote: > > To achieve that, attempt to apply each patch with -F0 --dry-run first. > If this succeeds, just silently apply the patch for real. If it > doesn't, output an explicit eqawarn that the patch does not apply > cleanly and retry with the default fuzz

Re: [gentoo-portage-dev] Constraint-Based Dependency Solver: initial results

On 8/30/19 10:34 AM, michael.lienha...@laposte.net wrote: > > All comments/suggestions are welcomed. > Since no one else has said it yet (?), I think this approach is really cool and I'm glad someone is working on it. Modeling difficult computations as abstract optimization problems is a

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

On 4/26/20 12:55 PM, Matt Turner wrote: > Bug: https://bugs.gentoo.org/715108 > Signed-off-by: Matt Turner > --- > Strawman patch. Bikeshed away. > Fuel for the fire: * https://www.nongnu.org/lzip/lzip_benchmark.html * https://www.nongnu.org/lzip/xz_inadequate.html

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

On 4/26/20 3:25 PM, Ulrich Mueller wrote: >>>>>> 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

[gentoo-portage-dev] [PATCH 1/1] Revert "repoman: deprecate netsurf.eclass."

-by: Michael Orlitzky --- repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 - 1 file changed, 1 deletion(-) diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py index 60410347b..5848a0c37 100644

[gentoo-portage-dev] [PATCH 1/1] repoman: deprecate netsurf.eclass.

can be put back into an eclass, and its consumers updated one-at-a-time. Bug: https://bugs.gentoo.org/489542 Bug: https://bugs.gentoo.org/637824 Signed-off-by: Michael Orlitzky --- repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

On Tue, 2021-10-05 at 17:13 +0200, Michał Górny wrote: > > > 2. What happens to the LTS branch when the next EAPI is released? > > > > I haven't really thought about it. Are you suggesting that we could > bump 'master' Portage to newer EAPI earlier or...? > I just mean that, a priori, the

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

On Tue, 2021-10-05 at 10:31 +0200, Michał Górny wrote: > Hi, everyone. > > I've been thinking about this for some time already, and the recent > FILESDIR mess seems to confirm it: I'd like to start a more stable LTS > branch of Portage. > I think this is healthy for most software projects, but

Re: [gentoo-portage-dev] [PATCH] portage.output: Replace darkblue colors with teal

On Sat, 2021-12-04 at 10:47 +0100, Fabian Groffen wrote: > > Now, if you would make a supported claim that all terminals we install > use a black background by default, your change becomes more valid. > > For one, when you're working through the handbook to install Gentoo, you're doing it on a