Re: [gentoo-dev] [PATCH 3/5] net-vpn/openvpn: Remove unnecessary option switch to path_exists

On 08/08/2018 05:34 PM, Michał Górny wrote: > > - if path_exists -o "${EROOT%/}"/etc/openvpn/*/local.conf ; then > + if path_exists "${EROOT%/}"/etc/openvpn/*/local.conf ; then > ewarn "WARNING: The openvpn init script has changed" > ewarn "" > fi Not

Re: [gentoo-dev] [PATCH] systemd.eclass: set BDEPEND for EAPI 7

On 08/06/2018 04:23 PM, Toralf Förster wrote: > On 08/06/2018 10:09 PM, Alec Warner wrote: >> >> They do not even do so by convention; there are numerous EAPIs in the >> wild that are non-numeric. > > Then this line > >if [[ ${EAPI} == [0123456] ]]; then > > is a short-term solution,

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

[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

[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

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

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/24/2018 12:37 PM, Rich Freeman wrote: >> harder to customize, because you can't turn it off. > > This was already addressed in a previous comment - PMS can be modified > to nullify flags Saying that hypothetically we could modify the PMS and wait for a new EAPI and wait for all package

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/24/2018 12:24 PM, Mike Gilbert wrote: > > For example, dhcpcd integrates with udevd via libudev to ensure that > udev has finished renaming your network interfaces before dhcpcd > attempts to configure them. I believe lvm2 uses libudev to prevent > various races in block device setup and

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/24/2018 12:14 PM, Rich Freeman wrote: > > I don't believe anybody suggested making Gentoo harder to customize. > This is just about setting reasonable defaults. For the (N+1)th time: enabling this flag by default does make Gentoo harder to customize, because you can't turn it off. And so

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/24/2018 11:39 AM, Mike Gilbert wrote: > > You can run any system without udev, but you need to be very careful > about what Linux features you utilize and how you have the system > configured. > > Most Linux servers out in the wild are running udev; your > configuration is an exception to

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/21/2018 12:59 PM, Matt Turner wrote: > > If it adds no additional dependencies, why do you care? > It adds complexity and attack surface for something I apparently don't need. You'll have to take it on faith that turning off shit I don't understand has made my job/life a lot easier over

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/21/2018 03:01 AM, Dennis Schridde wrote: > > What about adding a third operator, e.g. `^`, that resets a use flag to the > unset state? > The behavior of USE (in profiles) is documented in the PMS, so I don't think we can add a new operator so easily. But, this is what the PMS has to say

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/20/2018 03:37 AM, Matt Turner wrote: >> >> If I want to undo your new flag, I have to set USE="-udev" globally, and >> that clobbers any important per-package defaults that maintainers have set. > > I understand the concern at least in theory. But can you please give > me a concrete example

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/20/2018 07:55 AM, Rich Freeman wrote: > > While I agree that setting USE=-udev isn't the same as leaving it to > package defaults, you further claim that setting this globally causes > severe breakage in some cases. Can you provide an example of this? > https://bugs.gentoo.org/640226 Or

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/20/2018 02:12 AM, Mart Raudsepp wrote: > > Ok, I can see that point of view for make.conf. > I can't agree with changes in other profiles though, as other profile > will fall under the same category in USE_ORDER (in fact, it's the same > thing, as the end USE from "defaults" comes from your

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/20/2018 01:06 AM, Mart Raudsepp wrote: >> >> * They can't be undone. It's next to impossible for me to undo >> USE=udev when set in a profile that is inherited by all others. > > You set USE=-udev in your make.conf. That doesn't work, for reasons already stated. If I set USE="-udev"

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/19/2018 11:49 PM, Aaron Bauman wrote: > You are denying the majority default here. Granted, we don't have > statistics... Cuz Gentoo. No I'm not. I'm saying add them per-package, because it's a better design. We have package.use in profiles now, not just IUSE defaults. Global defaults have

Re: [gentoo-dev] Adding USE=udev to linux profiles

On 07/19/2018 05:51 PM, Ben Kohler wrote: > Hello, > > I'd like to propose adding USE=udev to our linux profiles (in > profiles/default/linux/make.defaults probably). This flag is already > enabled on desktop profiles but it also affects quite a few packages > used on non-desktop linux

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

On 04/07/2018 02:44 PM, William Hubbs wrote: > > I'm with floppym on this one. Is there a specific reason we enable them > globally? It's a relic from before we had IUSE defaults. > Since there has been so little discussion on this thread, I will start > looking at what I need to do to remove

Re: [gentoo-dev] rfc: empty directories in ${D}

On 03/29/2018 11:57 AM, William Hubbs wrote: >> >> The PMS says that empty directories are undefined, so the portage >> behavior of installing them and leaving them alone leads to >> incompatibilities. Ebuilds rely on the portage behavior, and if another >> PM (within its rights) deletes them,

Re: [gentoo-dev] rfc: empty directories in ${D}

On 03/29/2018 11:57 AM, Alec Warner wrote: > > So we could simply change the PMS to keep the empty directories? > > Why is removing them *better* is my question. I proposed this idea but basically everyone with a say in the process was against it: https://bugs.gentoo.org/644366 My last

Re: [gentoo-dev] rfc: empty directories in ${D}

On 03/29/2018 11:28 AM, Alec Warner wrote: > > Is there any particular reason we need to remove them? > The PMS says that empty directories are undefined, so the portage behavior of installing them and leaving them alone leads to incompatibilities. Ebuilds rely on the portage behavior, and if

Re: [gentoo-dev] Re: Mailing list moderation and community openness

On 03/28/2018 12:41 AM, Stephen Christie wrote: > > These are now the majority of the emails I've now received. The first > reply was essentially "We've already talked about this, can we just > move on?". In our enthusiasm to defeat wltjr, we have let ourselves become wltjr.

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

On 03/20/2018 04:14 PM, Herb Miller Jr. wrote: > That is scary. I hadn't noticed there are node_modules directories under > many node modules and that npm list outputs different versions of the > same dependency. To help me better understand the situation, when you > see this happen does "bar-1.0"

Re: [gentoo-dev] [RFC] Begin a dev-libs/nodejs category?

On 03/20/2018 07:50 AM, Herb Miller Jr. wrote: > When I did my homework on creating nodejs ebuilds (not nodejs itself but > packages written in node), it seems the topic has come up a few times in > the past but the time commitment and general disorganization of upstream > has scared off any

Re: [gentoo-dev] Re: How to deal with git sources?

On 03/12/2018 04:29 AM, Martin Vaeth wrote: > Duncan <1i5t5.dun...@cox.net> wrote: >> >> If I'm recalling correctly a warning posted on this list, repeated calls >> to the github tarballing API for the same commit will result in delivery >> of tarballs with differing checksums. > > This was so

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

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

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

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

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

On 03/07/2018 12:52 PM, Alec Warner wrote: > > I'm really not happy with the tone of this email, so I'm going to > comment on it a bit. >   Ok, it would have benefited from a do-I-sound-like-a-dick proofread. I don't want to sound discouraging because this is an area with lots of room for

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

On 03/07/2018 11:06 AM, anote...@teknik.io wrote: > Why should portage download some outdated second copy of the > sources for 'bar', rebuild it, and scatter it around the file system > where it cannot be used by other programs installed by cabal? These other package managers don't solve any hard

Re: [gentoo-dev] [PATCH 1/6] eapi7-ver.eclass: Explicitly indicate that EAPI 7+ includes it

On 03/06/2018 12:25 PM, Michał Górny wrote: > --- > eclass/eapi7-ver.eclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/eclass/eapi7-ver.eclass b/eclass/eapi7-ver.eclass > index 7eb070c68171..6117124a90a5 100644 > --- a/eclass/eapi7-ver.eclass > +++

Re: [gentoo-dev] RFC: eutils.eclass: More reliable return status for e*_clean.

On 02/16/2018 03:46 AM, Ulrich Mueller wrote: > > Should we take this as an opportunity to split off these three > functions into their own eclass, e.g. vcs-clean.eclass? I think this is a good direction to go in. Changing a popular eclass is always scary, and the more unrelated stuff it

Re: [gentoo-dev] Last Rites: Dead X11 packages

On 02/09/2018 05:47 PM, Matt Turner wrote: > > Wait, since it was just in DEPEND, I don't understand the problem. > > If it were in RDEPEND, I could understand. But in DEPEND, it'll get > depcleaned without any problem as far as I can tell. > After being subjected to a totally incomprehensible

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

On 02/08/2018 06:12 PM, William Hubbs wrote: > > There is no bug here. The problem, as I said before in this thread, is > that what goes in *sbin is arbitrary, and as Rich said, if you are > relying on the path to prevent a non-root user from running something > that only root should run, you are

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

On 02/08/2018 05:33 PM, Rich Freeman wrote: > > There are actually quite a few binaries in /sbin and /usr/sbin which > can be useful for non-root users. Sure, we could go through there > carefully and move stuff to /bin but honestly doing what everybody > else does and just sticking /sbin in the

Re: [gentoo-dev] newsitem: baselayout 2.5 changes

On 02/08/2018 05:13 PM, William Hubbs wrote: > > There are no reasons to remove the *sbin directories from PATH; I know > of no other distros that do this. The first reason that comes to mind is that when I type something like p to remind me of a command name, I don't need to see 50 programs

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-dev] [pre-GLEP] Split distfile mirror directory structure

On 01/27/2018 02:47 PM, Michał Górny wrote: >> * >> * Please download fileN from >> * wherever fileN can be found >> * and move it to $DISTDIR/subdirN > > Do you really believe this to be more friendly than a helper that places > all the files in correct directories? Well, it's no worse than

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On 01/27/2018 02:01 PM, Gordon Pettey wrote: > On Sat, Jan 27, 2018 at 10:48 AM, Michael Orlitzky <m...@gentoo.org> wrote: >> On 01/27/2018 11:42 AM, Gordon Pettey wrote: >>> Why not use a hash of the file name instead of its contents?... >> >> That's th

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On 01/27/2018 01:14 PM, Michał Górny wrote: >> >> If we have a tool like edistadd, then I see the problem. But if we were >> going to use file-data based hashes, then there would be no need for a >> tool in most cases. As a developer, "repoman manifest" would handle it. >> As a user, I'm going to

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On 01/27/2018 11:42 AM, Gordon Pettey wrote: > Why not use a hash of the file name instead of its contents? That > seems like it would be much simpler, and that's not going to reduce > the output space for balance... That's the proposal =P

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On 01/27/2018 03:30 AM, Michał Górny wrote: >> >> What are we worried about in using a temporary directory? Copying across >> filesystem boundaries? Except in rare cases, $DISTDIR itself will be >> usable a temporary location (on the same filesystem), won't it? > > Why add the extra complexity

Re: [gentoo-dev] Merge 7 Fedora wallpapers packages to single one with slots?

On 01/27/2018 11:09 AM, Sebastian Pipping wrote: > Hi! > > > I noticed that we have 7 packages on Fedora wallpapers with names that > only explain themselves to Fedora insiders: > > ... > > I was thinking that we could merge these packages into a new package > "x11-themes/fedora-backgrounds"

Re: [gentoo-dev] [pre-GLEP] Split distfile mirror directory structure

On 01/26/2018 06:24 PM, Michał Górny wrote: > > The alternate option of using file hash has the advantage of having > a more balanced split. Furthermore, since hashes are stored > in Manifests using them is zero-cost. However, this solution has two > significant disadvantages: > > 1. The hash

Re: [gentoo-dev] Re: News Item: Portage Dynamic Deps

On 01/23/2018 07:40 AM, Michael Palimaka wrote: >> >> Did you come up with a solution how to handle eclass-generated dependency >> changes then? > > No. > > Bug #641346 was filed for clarification about this, but it just got > closed without answering the question or consulting anyone. > >

Re: [gentoo-dev] version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass

On 01/22/2018 11:37 AM, Mike Gilbert wrote: >> >> If the dependencies are to remain in the eclasses, then the eclasses >> should get a new revision when those dependencies change. Afterwards, >> the consumers can be revbumped and stabilized normally to utilize the >> new eclass. > > While that

Re: [gentoo-dev] Re: version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass

On 01/22/2018 05:10 AM, Duncan wrote: >>> >>> If the dependencies are to remain in the eclasses, then the eclasses >>> should get a new revision when those dependencies change. Afterwards, >>> the consumers can be revbumped and stabilized normally to utilize the >>> new eclass. >> >> Sounds good!

Re: [gentoo-dev] version/slot locked dependencies in eclasses like autotools.eclass and vala.eclass

On 01/21/2018 11:24 PM, Zac Medico wrote: > > Some eclasses like autotools.eclass and vala.eclass generate > version/slot locked dependencies that cause the dependencies of > inheriting ebuilds to change when the versions in the eclasses are > updated. If possible, it would be nice to avoid this

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

On 01/19/2018 08:14 PM, William Hubbs wrote: >> >> Why not? Since /var/lib is root:root and mode 755, we can create >> /var/lib/foo while running --as=root (the default). Then afterwards, >> anything beneath /var/lib/foo would need to be created "--as" the owner >> of that directory. > > That

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

On 01/19/2018 07:16 PM, William Hubbs wrote: > > It looks like we can't use your --as suggestion if we want to be > able to create paths in /var/lib and /var/spool that are owned by > non-privileged users because of the permissions on those paths. It is > possible that service scripts are doing

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

On 01/17/2018 12:14 PM, William Hubbs wrote: >> >> 1. I could create /run/foo with owner "foo", and then create >>/run/foo/bar with owner "foo". That can be done without modifying >>existing permissions, but it's not safe, because you wind up working >>as root in the directory /run/foo

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

On 01/17/2018 10:21 AM, William Hubbs wrote: > > For both A and B above I think you mean owner/group/permissions right? Yep. >> 2. It should have a flag (say, --as=[:group]) to make it run as >> an unprivileged user. Basically a portable "su -c". > > I'm not following why I need this.

Re: [gentoo-dev] [PATCH] linux-mod.eclass: IUSE default support for MODULES_OPTIONAL_USE

On 01/14/2018 06:53 PM, Robin H. Johnson wrote: > +# @ECLASS-VARIABLE: MODULES_OPTIONAL_USE_IUSE_DEFAULT > +# @DESCRIPTION: > +# A boolean to control the IUSE default state for the MODULES_OPTIONAL_USE > USE > +# flag. Default value is unset (false). True represented by 1 or 'on', other > +#

[gentoo-dev] [PATCH 1/1] profiles: unset USE=modules by default.

The "modules" USE flag was originally enabled by default in the base profile so that any ebuild inheriting linux-mod.eclass would have its kernel modules built by default. However, the name of that USE flag is now controlled by the MODULES_OPTIONAL_USE variable, set in the ebuild itself. The best

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

On 01/10/2018 04:54 PM, William Hubbs wrote: > > What are we saying newpath should do differently than checkpath if I > go this route? I think this covers everything that we've talked about: 1. It should refuse to modify existing paths. 1.a. If newpath is called on an existing path, and

[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

[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 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 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

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

On 01/10/2018 01:17 PM, Kristian Fiskerstrand wrote: >> >> (I didn't realize at the time that the OpenRC fix still contained a race >> condition.) > > This was mentioned already in https://bugs.gentoo.org/540006#c15 > So it is =) I took the RESOLVED FIXED for granted when I reported the

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

On 01/10/2018 05:18 PM, James Le Cuirot wrote: > > The init script used to call chown/chmod -R, which is > obviously bad. I've compromised by only calling these on the > directories themselves (ignoring symlinks). I believe this is safe > because it's not possible to create hard linked

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

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-dev] Upcoming posting restrictions on the gentoo-dev mailing list

On 01/09/2018 07:37 PM, Philip Webb wrote: > > I'm very sorry that Council approved this proposal > & hope that it will soon see sense & rescind it. In an effort to reduce noise on the gentoo-dev mailing list, Gentoo will now require every user to send an email to the gentoo-dev mailing list

Re: [gentoo-dev] rfc: ideas for fixing OpenRC checkpath issue

On 01/09/2018 07:07 PM, William Hubbs wrote > > However, I'm not sure how to deal with the hard link issue in a way that > will not break service scripts. > Systemd mitigates this by enabling the fs.protected_hardlinks sysctl by default, but they have the liberty of requiring a relatively new

Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

On 12/30/2017 07:22 AM, Anthony G. Basile wrote: > use_if_iuse !nopie && return 0 Does this work? The "use" function supports negation (undocumented, but it's in the PMS), but I don't think use_if_iuse does.

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

We now have IUSE="+cracklib" in sys-apps/shadow, sys-auth/pambase, and sys-libs/pam (thanks robbat2). Does that address everyone's concerns? Enough so that I can revert the revert without anyone reverting the revert revert?

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

On 12/27/2017 10:42 AM, Mart Raudsepp wrote: > If you want to make such a base profile change, then I believe you > should contact the maintainers and see which one wants it default > disabled, and which default enabled; do the default enabled changes > and only afterwards you can touch a base

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

On 12/27/2017 05:49 AM, Jeroen Roovers wrote: > OK, let me explain again. > > In #gentoo we give a lot of attention and support to people who want to > set up full disk encryption, tor, VPNs, and other security mechanisms, > and this tells me that they actually want security. By saying that "some

[gentoo-dev] [PATCH 1/1] profiles: unset USE=session in default/linux/make.defaults.

The "session" USE flag has been enabled by default for all linux profiles in default/linux/make.defaults since 2010. According to the comment in that file, the flag was added for dev-lang/php where session support is near-critical. But, now that we have an IUSE default, the global setting is

Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

On 12/21/2017 02:27 PM, Jeroen Roovers wrote: > On Thu, 21 Dec 2017 10:10:30 -0500 > Michael Orlitzky <m...@gentoo.org> wrote: > >> The "cracklib" USE flag ... this commit removes it from base/make.defaults. >> >> Closes: https://bugs.gentoo.org/63569

[gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

The "cracklib" USE flag has long (since 2007ish) been enabled by default for all profiles. But, the features that it provides are not critical for any of the packages that use it: typically, the library is used to evaluate a candidate password and to prevent the user from choosing a weak one.

Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

On 12/20/2017 02:41 PM, Virgil Dupras wrote: > > Maybe some kind of official overlay for packages needing love? We > could send outdated packages there to die or to be born again if the > right person picks it up. > > The overlay could have more relaxed rules (not malicious and looking > good?

Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged

On 11/27/2017 10:16 AM, Mike Gilbert wrote: > On Mon, Nov 27, 2017 at 6:46 AM, Aaron W. Swenson > wrote: >> >> You should now be able to do compilation and tests without having the >> user/group created. For example, dev-db/postgresql doesn’t need the >> postgres system

[gentoo-dev] [PATCH 1/1] profiles: unset default USE=justify in hardened profiles.

The "justify" USE flag is local to only app-editors/nano, but it was enabled by default in two hardened profiles, * hardened/linux/amd64/make.defaults * features/hardened/amd64/make.defaults The reasoning for that is lost to time, but probably dates back to when nano was part of the @system

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

On 12/12/2017 01:24 PM, Rich Freeman wrote: > > As far as I'm aware the standing policy already exists that > maintainers can stabilize their own packages on amd64. https://bugs.gentoo.org/510198 is this thing on

Re: [gentoo-dev] amd64 17.1 profiles ready for testing

On 12/09/2017 04:00 PM, Michał Górny wrote: > > rm -r /lib.{old,new} /usr/lib.{old,new} > It probably won't hurt anything, but that should be run in BASH.

Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

On 12/02/2017 03:43 PM, Alon Bar-Lev wrote: > Hi, > Any reason we do not publish hardened/no-multilib? > I see we have[1] in place and is working if explicitly added. > Thanks, > Alon > > [1] profiles/features/hardened/amd64/no-multilib > I'm not sure if anything is using that particular

Re: [gentoo-dev] NEWS item for games destabling

On 11/27/2017 03:37 PM, Arve Barsnes wrote: > > Sounds kind of weird? If he has keyworded the game package, shouldn't it > just never install that version if it depends on an unstable package? That's right, but if there are two available ~arch versions, one of which has all stable dependencies

Re: [gentoo-dev] Re: cmake + ninja vs autotools

On 11/19/2017 01:00 PM, William L. Thomson Jr. wrote: >> >> This is broken: Static metadata like DEPEND must not depend >> on dynamic data like environment variables which are supposed >> to change at emerge time. > > I wondered about that. I guess adding to DEPEND via eclass is bad then. > So

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/12/2017 10:21 AM, Ulrich Mueller wrote: > >> * Change the PMS to remove "undefined behavior" and replace it with >> "empty directories must be tracked, and may only be removed once no >> installed package is using them," or something along those lines. >> That leaves the

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/12/2017 08:43 AM, Michał Górny wrote: > > I'm not convinced a QA warning is valid, given that not every empty > directory is meaningful. You're going to either cause people to create > unnecessary 'keepdir's, or to be swamped by false positives. The warning would essentially be saying,

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/11/2017 02:26 PM, Michał Górny wrote: >> >> As far as the actual implementation goes, I'm not sure that >> automatically-generated ".keep" files are better than having the package >> manager maintain its own database. The latter would be more complex, but >> would avoid littering everyone's

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/11/2017 02:58 AM, Michał Górny wrote: >> >> Certainly "keepdir" will make the directory non-empty, but with the >> additional (unwanted) side-effect that the directory won't be removed >> when the package is uninstalled. > > Wrong. It creates a dotfile inside it, and removes it along with

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/10/2017 04:36 PM, Damo Brisbane wrote: > > Re for...keepdir, I found removing it then the /var/log/fabio folders > were not getting created, so keeping it in there. You need to tell the ebuild to create that directory one way or another. The "dodir" function will create the directory, but

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

On 11/09/2017 11:08 PM, Damo Brisbane wrote: > I've run up a couple of golang based ebuilds - for the fabio load > balancer. My first run at it, not completely sure of any follow up > process, mentor? other posting, overlap with existing work? Anyway, > would appreciate the feedback. Your

Re: [gentoo-dev] [RFC] GLEP 65 v2: Post-install QA checks (now with post-merge checks)

On 10/25/2017 03:18 AM, Michał Górny wrote: >>> ... >>> The QA checks can inspect the installation image or live system >>> respectively, >> >> Respective to what? > > To the type of check, as explained later? If you want to help, then > please be specific instead of asking questions and

Re: [gentoo-dev] [RFC] GLEP 65 v2: Post-install QA checks (now with post-merge checks)

On 10/17/2017 02:12 PM, Michał Górny wrote: > > Abstract > > > ... > The QA checks can inspect the installation image or live system respectively, Respective to what? > output and store both user- and machine-oriented QA warning logs, manipulate > the files and abort the install, as

<    1   2   3   4   5   6   7   8   9   10   >