> 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:
> 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
> 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
Any specific reason for 553?
I had previously suggested that we stay below 500 as long as there is
space. On the one hand it would match the LSB better, on the other hand
we might at some point want to do dynamic allocation counting from 999
downwards, and keeping the fixed IDs below 500 would
> On Sat, 27 Jul 2019, James Le Cuirot wrote:
> Ack, although shouldn't this variable be made to do that? Or perhaps
> that's a PMS change?
Yes, it would need a new EAPI, but I have some doubts if the benefits
would outweigh the increased complexity of EAPI dependent behaviour.
Ulrich
> On Fri, 26 Jul 2019, Zac Medico wrote:
> Technically, they should do PROPERTIES+=" live" because PROPERTIES and
> RESTRICT actually do not append automatically.
Good catch. I'll amend the patch before pushing.
Ulrich
signature.asc
Description: PGP signature
> 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
> On Thu, 25 Jul 2019, Michał Górny wrote:
> - local defgroup=${egroups_arr[0]}
> + local g groups=( "${egroups_arr[0]}" )
> # sort supplementary groups to make comparison possible
> - readarray -t exgroups_arr < <(printf '%s\n' "${egroups_arr[@]:1}" |
> sort)
> - local
>>>>> On Thu, 25 Jul 2019, Ulrich Mueller wrote:
>> +readarray -t topdirs \
> Not legal in EAPIs 0 to 5 which use bash-3.2.
In fact, not legal in EAPIs 6 and 7 either, because the -t option
doesn't exist in bash-4.2.
signature.asc
Description: PGP signature
> On Thu, 25 Jul 2019, Michał Górny wrote:
> + readarray -t topdirs \
Not legal in EAPIs 0 to 5 which use bash-3.2.
Ulrich
signature.asc
Description: PGP signature
> 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?
> On Mon, 15 Jul 2019, Mike Gilbert wrote:
> + [[ -z ${ED+set} ]] && local ED=${D%/}${EPREFIX}/
Wouldn't this be a good time to drop such historical baggage, and
instead only support EAPIs where ED is defined? (I see the occasional
EAPI=4 in your list of ebuilds, but nothing older.)
> 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
> On Mon, 08 Jul 2019, Michał Górny wrote:
> Correct the enewuser call not to enforce specified UID unless
> ACCT_USER_ENFORCE_ID is set.
Patch series looks good.
signature.asc
Description: PGP signature
# Ulrich Müller (2019-07-05)
# Fetch restricted, SRC_URI is gone, last release in 2008.
# Binary-only 32 bit package. Program fails with SIGSEGV.
# Masked for removal in 30 days, bug #689158.
media-sound/ventrilo-server-bin
signature.asc
Description: PGP signature
> On Tue, 02 Jul 2019, Jonas Stein wrote:
>> Could you also look into converting other profile files? They were
>> known to have even less consistency than top-level package.mask.
> Good point. I will have a look at it.
> It will take some time, because the date formats there are mixed a
> On Wed, 26 Jun 2019, Marek Szuba wrote:
> Here is the RFC for acct-* packages corresponding to users and groups
> created by packages I currently maintain. This is also a request to
> reserve the respective UIDs/GIDs, namely:
> Groups:
> - burp - 501
> - rtkit - 133
> Users:
> - burp -
# Ulrich Müller (24 Jun 2019)
# Byte-compilation with recent Emacs versions fails.
# SRC_URI is gone. Last visible upstream activity in 2008.
# Use app-emacs/flim as replacement.
# Masked for removal in 30 days, bug #688596.
app-emacs/limit
virtual/emacs-flim
signature.asc
Description: PGP
> On Thu, 20 Jun 2019, Michał Górny wrote:
> --- /dev/null
> +++ b/acct-group/mail/mail-0.ebuild
> @@ -0,0 +1,9 @@
> +# Copyright 2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit acct-group
> +
> +DESCRIPTION="Mail program
> On Thu, 20 Jun 2019, Michał Górny wrote:
> Here's the RFC for first acct-* packages I'd like to commit. This is
> also a request to reserve the respective UIDs/GIDs. Namely:
> Groups:
> ftp - 21
> mail - 12 (on Linux, FreeBSD has it in baselayout)
> Users:
> ftp - 21
> mail - 8
"gamestat" group with gid 36, as defined by QA policy:
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies#Games
Not attaching the ebuild, because it's standard boilerplate, defining
only two variables:
DESCRIPTION="Group for shared game state files"
ACCT_GROUP_ID=36
Its first
> On Wed, 12 Jun 2019, Marek Szuba wrote:
>>> +dv - Dhivehi
>>
>> IANA registry says:
>>
>> | Subtag: dv
>> | Description: Dhivehi
>> | Description: Divehi
>> | Description: Maldivian
>>
>> So maybe make it 'Dhivehi (Maldivian)'?
> Originally I had all three names here but then I noticed
> On Thu, 06 Jun 2019, Michał Górny wrote:
> On Wed, 2019-06-05 at 21:10 +0200, Pacho Ramos wrote:
>> > +# Then you add appropriate dependency to your package. The dependency
>> > +# type(s) should be:
>> > +# - DEPEND (+ RDEPEND) if the group is already needed at build time,
>> > +# -
> On Wed, 05 Jun 2019, Michael Orlitzky wrote:
> Should we require a mailing list review for new user/group packages?
> It's difficult to modify a user once you've settled on a UID, home
> directory, and shell; so it pays to get things right the first time.
> The need is more apparent with
> On Wed, 05 Jun 2019, Michał Górny wrote:
> +# @FUNCTION: acct-group_pkg_pretend
> +# @DESCRIPTION:
> +# Performs sanity checks for correct eclass usage, and early-checks
> +# whether requested GID can be enforced.
> +acct-group_pkg_pretend() {
> + debug-print-function ${FUNCNAME} "${@}"
>>>>> On Tue, 14 May 2019, Ulrich Mueller wrote:
> There are quite a few news items that appear to be no longer relevant.
> The following ones are from 2013 or earlier:
> 2007-05-04-paludis-0_24
> 2009-01-04-sparc-multilib
> 2009-04-06-x_server-1_5
> On Wed, 29 May 2019, David Seifert wrote:
> On Wed, 2019-05-29 at 11:00 +0200, Michael Haubenwallner wrote:
>> +case ${EAPI:-0} in
>> +[0-6]*)
> Why the *? Do we really care about EAPI="5-HDEPEND" and others?
Worse, this will match EAPI 10. :)
signature.asc
Description: PGP
> On Fri, 24 May 2019, Mike Gilbert wrote:
> On Thu, May 23, 2019 at 7:16 PM David Seifert wrote:
>> Given that there are no ebuilds in the tree using this eclass and being
>> in EAPI 0, 1 or 2 (
>> https://qa-reports.gentoo.org/output/eapi-per-eclass/savedconfig.eclass/
>> ), wouldn't it
As you certainly have noticed, the ACCEPT_LICENSE change was reverted
because of concerns about user experience. In the meantime, Whissi has
written a migration tool app-portage/elicense.
We have updated the news item to reflect this, see the paragraph
inserted after the package.license examples.
> On Sun, 19 May 2019, Michał Górny wrote:
> Migration from both 13.0 and 17.0 profiles is supported. In case
> of the former, please read the news item for 17.0 upgrade first
> and enable gcc 6.4.0 or newer first as explained there.
The 17.0 news item is from 2017 and somewhat hard to
Another iteration, due to an upcoming restructuring of the
linux-firmware package. Only change in v3 is the second line in the
package.license file which now contains the @BINARY-REDISTRIBUTABLE
group instead of individual licenses.
Current plan is that this will go live on next Sunday,
There are quite a few news items that appear to be no longer relevant.
The following ones are from 2013 or earlier:
2007-05-04-paludis-0_24
2009-01-04-sparc-multilib
2009-04-06-x_server-1_5
2009-07-12-xorg-74-alpha
2009-10-02-xorg-server-1-6-libxcb-1_4
2009-10-08-gnome-226
Thanks for the feedback on IRC and mailing list. Find v2 below.
Ulrich
Title: Change of ACCEPT_LICENSE default
Author: Ulrich Müller
Posted: 2019-04-XX
Revision: 1
News-Item-Format: 2.0
The default set of accepted licenses has been changed [1,2] to:
ACCEPT_LICENSE="-* @FREE"
This means
Hello,
As the Council has decided in its 20190210 meeting, we are about to
change the ACCEPT_LICENSE default in the base profile (pending final
acknowledgement from RelEng).
Please review the corresponding news item included below.
Title: Change of ACCEPT_LICENSE default
Author: 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
>
>>>>> On Sat, 13 Apr 2019, Michał Górny wrote:
> On Sat, 2019-04-13 at 21:52 +0200, Ulrich Mueller wrote:
>> > > > > > On Sat, 13 Apr 2019, Michał Górny wrote:
>> > # Michał Górny (13 Apr 2019)
>> > # Unmaintained. Contains vulnerable cod
> On Sat, 13 Apr 2019, Michał Górny wrote:
> # Michał Górny (13 Apr 2019)
> # Unmaintained. Contains vulnerable code and a large number of unsolved
> # (upstream) issues, including licensing issues that prevented Debian
> # from including it.
I suppose that is referring to Debian bug
# Ulrich Müller (13 Apr 2019)
# Last release in 2001, HOMEPAGE and SRC_URI are gone.
# Byte-compilation with recent Emacs versions fails.
# Masked for removal in 30 days, bug #683248.
app-emacs/prom-wl
signature.asc
Description: PGP signature
src_test still falls back to WORKDIR, if S does not point to an existing
directory. For other phase functions this is no longer the case since
EAPI 4.
Does anyone rely on that behaviour (e.g., define src_test in a virtual)?
If not, I would clarify the wording in PMS, which arguably contradicts
> On Sat, 02 Mar 2019, Michał Górny wrote:
> On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
>> Perhaps we should un-ban the ltprune eclass for EAPI 7?
>>
>> It seems like it would still be useful to have a way of detecting
>> libtool-archives instead of removing any file that ends
> On Sun, 24 Feb 2019, Aaron Bauman wrote:
> Following the feedback so far, here is v2 of the news item. [...]
Sorry, looks like I replied to v1 when v2 was already out.
The following still applies, though:
> Migration from both 13.0 and 17.0 profiles are supported. In case
s/are/is/
> On Sun, 24 Feb 2019, Aaron Bauman wrote:
> Following up on Michał's work with the amd64 17.1 profiles, I have
> revised the original news item for review with the intent of moving the
> profiles to stable.
> These profiles were initially published by Michał in December 2017 as
> exp and
>>>>> On Wed, 20 Feb 2019, Michał Górny wrote:
> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>> > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
>>
>>
>> ># Don't install libtool archives (even for modules)
>&
>>>>> On Wed, 20 Feb 2019, Michał Górny wrote:
> On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
>> > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
>>
>>
>> ># Don't install libtool archives (even for modules)
>&
> On Wed, 20 Feb 2019, Matt Turner wrote:
> Nearly all the work is just removing uses of autotools-multilib and
> autotools-utils. The new code should work in EAPI 4 and 5. Don't add
> support for EAPI 6; that ship has already sailed.
AFAICS, adding EAPI 6 support wouldn't require any
> On Wed, 20 Feb 2019, Matt Turner wrote:
> # Don't install libtool archives (even for modules)
> - prune_libtool_files --all
> + find "${D}" -name '*.la' -delete || die
Maybe restrict removal to regular files, i.e. add "-type f"?
signature.asc
Description: PGP signature
# Ulrich Müller (19 Jan 2019)
# Last release in 1999, last visible upstream activity in 2011.
# Byte-compilation fails. Masked for removal in 30 days, bug #675814.
app-emacs/tdtd
signature.asc
Description: PGP signature
> On Fri, 18 Jan 2019, Michał Górny wrote:
> My suggestion is to move binary compatibility slots into separate
> packages. For example, dev-libs/openssl would be split into:
> dev-libs/openssl -- containing the actual package
> dev-libs/openssl-bin-compat -- containing binary
> 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
> On Mon, 07 Jan 2019, Georgy Yakovlev wrote:
> cargo_src_compile() {
> debug-print-function ${FUNCNAME} "$@"
>
> export CARGO_HOME="${ECARGO_HOME}"
>
> - cargo build -j $(makeopts_jobs) $(usex debug "" --release) \
> + cargo build -j $(makeopts_jobs) $(usex debug ""
> On Mon, 03 Dec 2018, grozin wrote:
> On Sun, 2 Dec 2018, Michał Górny wrote:
>> I think that if there's one package that doesn't work with profiles
>> (compared to the very large number of packages which just work fine),
>> it's not the profiles but the package being broken (read: doing
> On Fri, 30 Nov 2018, Michał Górny wrote:
> Here's hopefully the last update for some time (that is, before I get to
> working on implementation). There are two small changes:
> - clarified the text on top archive directory: mentioned it shouldn't
> have an explicit member in the archive
> On Tue, 27 Nov 2018, Andrey Utkin wrote:
> It seems to me this will grow huge, and be the source of annoyance for
> users.
IIUC the file has a specific purpose, namely to solve the copyright
attribution problem. So only those entities who would otherwise add
themselves to ebuild headers
> On Tue, 27 Nov 2018, Gerion Entrup wrote:
> It seems that sobby was deprecated by the Gobby team (also last commit
> from 2012). Libinifity also provides an obby server (infinoted). Does
> app-emacs/rudel run with infinoted as well?
According to https://www.emacswiki.org/emacs/Rudel:
> On Mon, 26 Nov 2018, Tiziano Müller wrote:
> the following packages are up for grabs since I have no use for them
> anymore:
> net-misc/sobby
> net-libs/obby
> net-libs/libinfinity
> net-libs/net6
> They are unfortunately not up-to-date, and 3 minor bugs are open for
>
> On Mon, 26 Nov 2018, Michał Górny wrote:
> Specification
> =
> The container format
>
> The gpkg package container is an uncompressed .tar achive whose filename
> should use ``.gpkg.tar`` suffix. This archive contains the following
> members, all placed
> On Sun, 25 Nov 2018, Michał Górny wrote:
> Due to long-time inactivity, the following packages are now up for
> grabs. Given the length of the list, please forgive me for any
> mistakes.
> app-editors/jupp
Emacs team will take this one.
Ulrich
signature.asc
Description: PGP signature
> 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
>
> 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
> 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
> 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.
> On Thu, 01 Nov 2018, Andrew Savchenko wrote:
> -inherit eutils toolchain-funcs
> +inherit toolchain-funcs
> +case ${EAPI:-0} in
> + # not used in the eclass, but left for backward compatibility with
> legacy users
> + 4|5|6) inherit eutils ;;
> + 7) ;;
> + *) die
# Ulrich Müller (23 Oct 2018)
# Depends on
signature.asc
Description: PGP signature
> On Mon, 15 Oct 2018, Michael Haubenwallner wrote:
> in pkg_nofetch, beyond to "direct the user to download relevant
> source files", I've found it useful to tell the user which
> filesystem directory to put the files into once downloaded.
> Beyond that, I've also found it useful to tell
> On Sat, 06 Oct 2018, Mykyta Holubakha wrote:
> Signed-off-by: Mykyta Holubakha
> I'm proposing to add a new eclass: appimage.eclass, to facilitate
> extraction off AppImage bundles. The rationale is that some upstreams
> have migrated to distributing their proprietary software exclusively
> On Mon, 01 Oct 2018, Mike Gilbert wrote:
> @@ -15,7 +15,7 @@
> inherit xdg-utils
> case "${EAPI:-0}" in
This was there before your change, but the ":-0" isn't needed here ...
> - 4|5|6)
> + 4|5|6|7)
> EXPORT_FUNCTIONS src_prepare pkg_preinst pkg_postinst
By GLEP 76, two forms of copyright notices are allowed for copyrightable
files in Gentoo projects:
A "long form":
Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]
or a "simplified form":
Copyright YEARS Gentoo Authors
The latter was introduced because keeping track
> On Tue, 18 Sep 2018, Michał Górny wrote:
> Reported-by: Michael Orlitzky
> ---
> glep-0066.rst | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
There's another paragraph in the "Commit messages" section that should
be updated:
| The only tag defined by git
> On Sun, 16 Sep 2018, Michał Górny wrote:
> Just FYI: the Trustees have approved GLEP 76 aka our new copyright
> policy [1]. While the exact implementation details are to be determined
> yet, please note that *Signed-off-by* line will mean you are certifying
> our GCO [2].
> Since some
> On Thu, 13 Sep 2018, Mike wrote:
> On 9/13/18 9:35 AM, Rich Freeman wrote:
>> What regulation? No action was taken.
>>
>> We can't exactly stop people from asking governance bodies to do
>> things. At most we can say no when they ask.
>>
>> Unless we want to make people ask if they can
> On Wed, 12 Sep 2018, Mike wrote:
> Picking random email.
> I would like to say I'm glad we can discuss our technical differences
> like this with both sides expressing their opinion and reasoning.
> I would hope in the future we start with this path and not with
> disciplinary action or
> On Sun, 09 Sep 2018, Andrew Savchenko wrote:
> What I'm trying to do is to allow maintainers to keep -Werror if
> they really want to do this, understand what they are doing and
> have enough manpower to support this.
Bug 665464 has just proven that this doesn't work. That bug would not
> 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
> On Mon, 27 Aug 2018, Matija Šuklje wrote:
> The GNU family was a special case and it was a very difficult and long
> discussion/negotiation about it before the consensus was made. It was
> caused by FSF’s very strong stance on this and the trade-off is that FSF
> now recommends SPDX as
> On Mon, 27 Aug 2018, Robin H Johnson wrote:
> I've been wondering if we can switch outright to using SPDX-based
> expressions inside our USE-flag conditionals.
> For the entries we have in licenses/ that are not presently covered by
> SPDX licenses or exceptions, we'll need additions*,
> On Sun, 26 Aug 2018, Matija Šuklje wrote:
> It is worth noting that the SPDX standard (since 3.0) has indeed changed
> for the *GPL family of licenses
> from
> • GPL-2.0, and
> • GPL-2.0+
> to
> • GPL-2.0-only, and
> • GPL-2.0-or-later
> This was done by request and in coordination
> On Sun, 26 Aug 2018, Michał Górny wrote:
> 1. introducing additional *-only licenses that explicitly indicate
> that a newer version is not allowed, e.g. GPL-2-only, LGPL-3-only etc.
I don't like this at all, because LICENSE="GPL-2" means exactly the
above, namely GPL version 2, no later
> 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
> On Wed, 8 Aug 2018, Michał Górny wrote:
> Alternatively, we could remove the function entirely and inline its
> use in the three packages that need it.
Sounds like a better plan. Removing the options is an incompatible
change anyway, so maybe removing the function would be a cleaner
# Ulrich Müller (07 Aug 2018)
# Fails to build with emacs-26.1. Last release in 2003, last commit
# to upstream CVS in 2010. Masked for removal in 30 days. Bug #663030.
app-emacs/cmail
> On Mon, 06 Aug 2018, Vadim A Misbakh-Soloviov wrote:
> Anyway, I think, it is possible to add something like
> "EAPI=${EAPI:-0}" somewhere at the top of eclass, to don't call
> "${EAPI:-0}" each time when EAPI variable is needed.
No, that is not possible. Changing EAPI in an eclass would
> On Mon, 6 Aug 2018, Mike Gilbert wrote:
> -DEPEND="virtual/pkgconfig"
> +if [[ ${EAPI} == [0123456] ]]; then
This should use ${EAPI:-0} because for EAPI 0 the variable can be
empty.
> + DEPEND="virtual/pkgconfig"
> +else
> + BDEPEND="virtual/pkgconfig"
> +fi
> 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
> 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
> On Sat, 4 Aug 2018, Michał Górny wrote:
> GLEP 63 originally did not include a rationale. Given the importance
> of this document, I think it would be reasonable to include one and
> use the opportunity to explain the policies in detail.
The council just approved the updated GLEP 63 in its
> On Fri, 03 Aug 2018, Michał Górny wrote:
> Firstly, there is a result mismatch for council-201206 election.
> More specifically, the countify results are:
> [["dberkholz"], ["grobian"], ["chainsaw"], ["scarabeus"], ["ulm"],
> ["betelgeuse"], ...]
> While devotee considers ulm and
> 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
>>>>> On Fri, 27 Jul 2018, Brian Dolbec wrote:
> On Fri, 27 Jul 2018 16:31:15 +0200
> Ulrich Mueller wrote:
>> >>>>> On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote:
>>
>> > From the same source
>> > "No other
kg ?
Best,
/Anders
On Fri, Jul 27, 2018 at 4:31 PM, Ulrich Mueller wrote:
>>>>> On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote:
> July 27, 2018 4:07 PM, "William Hubbs" wrote:
>> Section 5.5.2 describes the directory structure of /var/c
> 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
> On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote:
> July 27, 2018 4:07 PM, "William Hubbs" wrote:
>> Section 5.5.2 describes the directory structure of /var/cache.
>> These paths are all optional [1].
>>
>> /var/cache/fonts
>> /var/cache/man
>> /var/cache/www
>> /var/cache/
>>
>>
;
> One small note, while it is never needed to modify, skel.ebuild
> would then be a file that is meant to be accessed by users in
> /var/lib if your proposal is realized.
That's one of the reasons why the proposal prefers /var/db. The other
reason is existing usage in eselect-repository.
> On Thu, 26 Jul 2018, Virgil Dupras wrote:
> The only adjustment made here is setting BDEPEND instead of DEPEND
> when under EAPI 7.
There's a third DEPEND assignment which you've missed, at the end of
the optional|tests case.
Ulrich
pgpog9TsT6GuR.pgp
Description: PGP signature
> On Wed, 25 Jul 2018, Aaron Bauman wrote:
> The whole, "I am not doing one year..." and then the "anvil doesn't
> count" seems uncooperative and contradictory.
> Is there some obstacle stopping you from updating your key
> expiration once a year? It takes at most 20 minutes.
It is *not*
> On Thu, 19 Jul 2018, Johannes Huber wrote:
>> app-doc/devmanual
> I took those by myself.
I have added the devmanual project as well, as a backup maintainer.
Ulrich
pgpB8U3Eu2VqK.pgp
Description: PGP signature
>>>>> On Wed, 18 Jul 2018, Christopher Head wrote:
> On July 18, 2018 2:55:55 AM PDT, Ulrich Mueller wrote:
>> It was mentioned that all three directories (ebuild repository,
>> binary packages, distfiles) have some characteristics of a cache.
>> How
>>>>> On Wed, 18 Jul 2018, Rich Freeman wrote:
> On Wed, Jul 18, 2018 at 5:55 AM Ulrich Mueller wrote:
>> Also, there is that strange requirement that the
>> file hierarchy must not be exposed to users. At least for the
>> make.profile link we rely on a w
[Moving the thread back from -project to -dev.]
>>>>> On Fri, 13 Jul 2018, Ulrich Mueller wrote:
>>>>> On Fri, 13 Jul 2018, Rich Freeman wrote:
>> Well, /var/lib/ is 3 right there. If 5 is no good then you
>> only have one left. We could just make it /
> On Wed, 18 Jul 2018, Matthew Thode wrote:
> On 18-07-18 09:16:07, Johannes Huber wrote:
>> english is not my mother language, so please clarify what bup means, just
>> seen here:
>>
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397
>>
>> Just
> On Fri, 13 Jul 2018, Marty E Plummer wrote:
> In EAPI 7, D, ED, ROOT, EROOT no longer have a trailing slash[1]. This
> makes finding /usr/src/linux not work properly as it currently stands.
> Use the form "${ROOT%/}/" where apropos in order to unify behavior across
> EAPIs.
> 1:
701 - 800 of 2165 matches
Mail list logo
