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
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 L
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 t
-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
magic 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 --
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
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
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 changed?
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
presumabl
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 facto
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
"hobby
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
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
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.
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
/var/tmp/whatev
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 th
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 superus
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 (
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 a
all 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
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
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 th
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" sys
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 m
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 th
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
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
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.
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 g
---
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 ${ED}/us
y "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
---
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 roo
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/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 roo
---
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 ${ED}/usr/b
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 alrea
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.
/var/lib/fo
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
> --usepk
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 for inst
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 I
On 01/07/2017 06:08 AM, Wim Muskee wrote:
>
> URISCHEME_RE = re.compile(r'^[a-z\-]+://')
>
> ...
>
> URISCHEME_RE.match(ebuild.metadata.get("HOMEPAGE")) is None:
>
The PMS allows some weird stuff in HOMEPAGE:
https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-760008
Specifically,
In addit
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, "v
A recent thread on gentoo-dev proposed a change to the devmanual's
description of the ROOT variable:
https://archives.gentoo.org/gentoo-dev/message/8901669dd375ca0fdb610efef0ddfe6f
The proposed change would bring the devmanual's language in line with
the PMS. That discussion reveals that the use
cases 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/roo
The INSTALL_MASK variable has long supported shell glob patterns, but
these were not mentioned in the man page. In fact there are two
different behaviors -- one for globs that the shell can expand, and
one for "bare globs" like "*.pdf". Both of these are now documented in
the man page.
In addition
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
---
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
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 t
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 checkin
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 def
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
Date: Wed, 22 Jan 20
51 matches
Mail list logo