Re: [gentoo-dev] [PATCH] vdr-plugin-2.eclass: add EAPI 7 support

> On Sat, 14 Jul 2018, Joerg Bornkessel wrote: > Please review, > changes makes the vdr-plugin-2.eclass to be able handle EAPI 7 support. > Its just 1 line for this, > The rest is clean up, or better i should say, i removed the internal > vdr_dev_check function and replaced it by the eqawarn

Re: [gentoo-dev] rfc: moving default location of portage tree

> On Fri, 13 Jul 2018, konsolebox wrote: > I don't mind calling ::gentoo as Gentoo's official ebuild repository, > but it also has been "a portage tree", and "the portage tree" by > default context. If you imply that people should change convention to > something more PMS friendly, be

Re: [gentoo-dev] rfc: moving default location of portage tree

[Please fix your mailer. Your message has a broken "References" header.] > On Wed, 11 Jul 2018, Richard Yao wrote: > This does not answer my question. Is it really a FHS violation? The > contents of /usr changes when doing updates using the system package > manager. When not doing updates,

Re: [gentoo-dev] rfc: moving default location of portage tree

>>>>> On Tue, 10 Jul 2018, Ulrich Mueller wrote: >>>>> On Mon, 9 Jul 2018, William Hubbs wrote: >> Agreed, /var/db I guess is a Gentoo invention of some kind? > No, it exists in FreeBSD too. As was pointed out to me, it exists in all

Re: [gentoo-dev] rfc: moving default location of portage tree

> On Mon, 9 Jul 2018, William Hubbs wrote: > On Mon, Jul 09, 2018 at 04:53:43PM -0400, Rich Freeman wrote: >> Though I do prefer /var/lib or /var/cache over /var/db, simply >> because /var/lib is actually in FHS. > Agreed, /var/db I guess is a Gentoo invention of some kind? No, it exists in

Re: [gentoo-dev] rfc: moving default location of portage tree

> On Mon, 9 Jul 2018, Rich Freeman wrote: > I'd also consider /var/cache here as well. FHS specifically suggests > using it for web caches and the like (let's set aside the issue with > making that global), though for the most part it is more metadata > caching. A key principle is that it

Re: [gentoo-dev] rfc: moving default location of portage tree

> On Mon, 9 Jul 2018, William Hubbs wrote: > is there a tracker for when the portage tree can be moved out of > /usr/portage by default? > If not, what is the status of us being able to do this? Please remind me, what was the plan for the new location? Somewhere under /var/db or /var/lib,

Re: [gentoo-dev] [PATCH v4 00/14] GLEP 63 update

> On Sat, 07 Jul 2018, Michał Górny wrote: >> > 1. SHA2-series output digest (SHA1 digests internally permitted), >> >256bit or more:: >> >personal-digest-preferences SHA256 >> >> Is the config line still needed with current GnuPG versions? > I'll let others answer that. In any

Re: [gentoo-dev] [PATCH v4 13/14] glep-0063: Remove whitespace from LDAP field

> On Sat, 7 Jul 2018, Michał Górny wrote: > All Gentoo developers must list the complete fingerprint for their primary > keys in the "``gpgfingerprint``" LDAP field. It must be exactly 40 hex > digits, > -uppercase, with optional spaces every 8 hex digits. Regular expression for >

Re: [gentoo-dev] [PATCH v4 00/14] GLEP 63 update

> On Sat, 7 Jul 2018, Michał Górny wrote: [Section "Bare minimum requirements"] > 1. SHA2-series output digest (SHA1 digests internally permitted), >256bit or more:: >personal-digest-preferences SHA256 Is the config line still needed with current GnuPG versions? > 2. Signing

Re: [gentoo-dev] rfc: killing mediawiki

> On Fri, 6 Jul 2018, Kent Fredric wrote: > On Thu, 5 Jul 2018 12:32:20 -0500 > William Hubbs wrote: >> I looked at this first, and it is very hard on the server. >> Every pull or clone you do to update things works like an initial >> clone, so it takes pretty massive resources. > Surely,

Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory

> On Fri, 6 Jul 2018, Marc Schiffbauer wrote: > * Michał Górny schrieb am 06.07.18 um 11:33 Uhr: >> If you don't see it for 5 years, how can you be sure that it is >> even still there? > Are you serious? Who tells you that I do not check from time to > time? > I am sure there will always be

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

> On Fri, 06 Jul 2018, Michał Górny wrote: > Did you even read the text? It's 'at most 2 years'. If you renew it > every year, you can achieve the desired effect while keeping far > ahead of the required schedule. So effectively we're down from 5 years to 1 year also for the main key, as a

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

>>>>> On Fri, 6 Jul 2018, Robin H Johnson wrote: > On Fri, Jul 06, 2018 at 07:43:56AM +0200, Ulrich Mueller wrote: >> Still NACK. If expiration is exactly 2 years and renewal must happen >> 2 weeks before the expiry date, then it is not possible to keep the >>

Re: [gentoo-dev] [PATCH v3 08/12] glep-0063: Allow ECC curve 25519 keys

> On Thu, 5 Jul 2018, Jonas Stein wrote: >> b. RSA, >=2048 bits (OpenPGP v4 key format or later only) >> >> + c. ECC curve 25519 >> + >> 4. Key expiry: 5 years maximum >> 5. Upload your key to the SKS keyserver rotation before usage! > I think we should ensure first that everything works

Re: [gentoo-dev] [PATCH v3 10/12] glep-0063: Make 2-yearly expiration term mandatory

> On Thu, 5 Jul 2018, Michał Górny wrote: > Replace the disjoint 'minimum' and 'recommendation' for expiration > with a single requirement. Make it 2 years. Also, remove disjoint > expiration recommendation for the primary key and subkeys since many > developers fail at implementing that

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

> On Wed, 4 Jul 2018, Robin H Johnson wrote: >> >b. Signing subkey: 1 year maximum >> >> > 5. Key expiration date renewed at least 2 weeks before the >> >previous expiration date. > Only catch is that if I was doing it 2 weeks before, I'd want to > push it out another year or 6

Re: [gentoo-dev] [PATCH v2 00/11] Major GLEP 63 update; full text

> On Wed, 04 Jul 2018, Michał Górny wrote: >b. Signing subkey: 1 year maximum > 5. Key expiration date renewed at least 2 weeks before the previous >expiration date. This is crappy as a scheme, since it will make it impossible to keep the expiration date at a constant month and

Re: [gentoo-dev] [PATCH v2 09/11] glep-0063: Make recommended expiration terms mandatory

> On Wed, 4 Jul 2018, Michał Górny wrote: > -3. Key expiry: 5 years maximum > +3. Key expiration: > + > + a. Primary key: 3 years maximum > + > + b. Gentoo subkey: 1 year maximum What problem are you trying to solve here? Ulrich pgpfeO7ifif_W.pgp Description: PGP signature

Re: [gentoo-dev] Trustless Infrastructure

> On Mon, 2 Jul 2018, Jason A Donenfeld wrote: > Proposal: > - Sign every file in the portage tree so that it has a corresponding > .asc. Repoman will need support for this. Not possible, because there are some directories in profiles that must not contain any files other than those

Re: [gentoo-dev] [PATCH 05/10] xdg.eclass: make EAPI 7 ready

> On Tue, 26 Jun 2018, Marty E Plummer wrote: > Add dev-util/desktop-file-utils and x11-misc/shared-mime-info to BDEPEND > as a number of executables which will need to be executed on the build > host are included in them. > Package-Manager: Portage-2.3.40, Repoman-2.3.9 > --- >

Re: [gentoo-dev] Re: [PATCH 3/5] toolchain.eclass: avoid leading double slash

> On Thu, 21 Jun 2018, Marty E Plummer wrote: > On Thu, Jun 21, 2018 at 10:16:45AM +0200, Michael Haubenwallner wrote: >> Well, DATAPATH already has the leading slash, and I have to avoid >> double slash here. > -mkdir -p "${EROOT}"usr/{share/gcc-data,sbin,bin} > +

Re: [gentoo-dev] [PATCH 3/5] toolchain.eclass: avoid leading double slash

> On Wed, 20 Jun 2018, Michael Haubenwallner wrote: > Path starting with "//" is a Network path for Cygwin: > As DATAPATH starts with EPREFIX, we have to use it with ${ROOT%/}. > --- > eclass/toolchain.eclass | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > diff --git

Re: [gentoo-dev] [PATCH 1/2] gnome2-utils.eclass: make EAPI 7 ready

>>>>> On Mon, 18 Jun 2018, Mart Raudsepp wrote: > Ühel kenal päeval, E, 18.06.2018 kell 08:01, kirjutas Ulrich Mueller: >> > > > > > On Sun, 17 Jun 2018, Marty E Plummer wrote: >> > Signed-off-by: Marty E. Plummer >> >> Ple

Re: [gentoo-dev] [PATCH 1/2] gnome2-utils.eclass: make EAPI 7 ready

> On Sun, 17 Jun 2018, Marty E Plummer wrote: > Signed-off-by: Marty E. Plummer Please don't yet use Signed-off-by. Our policy on this (GLEP 76) is still a draft and subject to change. > -DEPEND=">=sys-apps/sed-4" > - > +# sed needs to be executable on the build system >

Re: [gentoo-dev] [PATCH 1/8] bash-completion-r1.eclass: Sanitize insopts

> On Fri, 8 Jun 2018, Michał Górny wrote: > ( > + insopts > insinto "$(_bash-completion-r1_get_bashcompdir)" > doins "${@}" > ) I wonder about these empty insopts commands. According to the spec: "When called with no arguments, resets the

[gentoo-dev] Re: [PATCH 2/2] readme.gentoo-r1.eclass: Support EAPI 7.

> On Sun, 3 Jun 2018, Ulrich Müller wrote: > No changes appear to be necessary, other than updating the case > statement. Pushed. pgpGNxZNvvmZ8.pgp Description: PGP signature

[gentoo-dev] Re: [PATCH] eclass: Remove remaining uses of epause and ebeep.

> On Sat, 26 May 2018, Ulrich Müller wrote: > These functions are long deprecated and only defined in EAPIs 0 to 2. > --- > eclass/gnatbuild-r1.eclass | 1 - > eclass/gnatbuild.eclass| 1 - > eclass/kernel-2.eclass | 2 -- > eclass/linux-info.eclass | 3 +-- > eclass/webapp.eclass

Re: [gentoo-dev] [PATCH] ant-tasks.eclass: use eapi7-ver

> On Wed, 30 May 2018, Marty E Plummer wrote: > Clean resend for monsierp, as the prior one got mangled a bit. Just a hint: If you write this after the separating line ("---"), then your patch can be applied with "git am" without this sentence being included in the commit message (unless you

Re: [gentoo-dev] Planning for disabling CVS services: migration of remaining active users

> On Sun, 20 May 2018, Robin H Johnson wrote: > It's been discussed before, but Infra would like to hear any concerns > about work towards not having CVS anymore. As an interim in this > process, it will be offered in a read-only mode. > gentoo/src/patchsets/ is the only part of CVS that

Re: [gentoo-dev] Re: [PATCH] ant-tasks.eclass: use eapi7-ver

> On Tue, 22 May 2018, Marty E Plummer wrote: > How's this? > --- > eclass/ant-tasks.eclass | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > diff --git a/eclass/ant-tasks.eclass b/eclass/ant-tasks.eclass > index e008e6eaea8..31683e68243 100644 > ---

Re: [gentoo-dev] Re: [PATCH] ant-tasks.eclass: use eapi7-ver

> On Mon, 21 May 2018, Marty E Plummer wrote: > On Tue, May 22, 2018 at 05:57:35AM +0200, Micha?? G??rny wrote: [Please check you mailer configuration. It's sending MIME, but charset=us-ascii cannot represent these chars.] >> Always check for old EAPIs, instead of expecting people to keep

[gentoo-dev] Re: [PATCH] bzr.eclass: Support EAPI 7.

> On Fri, 4 May 2018, Ulrich Müller wrote: > --- > eclass/bzr.eclass | 13 +++-- > 1 file changed, 7 insertions(+), 6 deletions(-) Merged. pgp1K63mNrLzg.pgp Description: PGP signature

Re: [gentoo-dev] [RFC] multiversion ebuilds

>>>>> On Wed, 16 May 2018, Ulrich Mueller wrote: >>>>> On Wed, 16 May 2018, Paweł Hajdan, wrote: >> I'm wondering: if the main goal would be more code sharing between >> ebuilds, would something like >> <https://exherbo.org/docs/eapi/exheres-fo

Re: [gentoo-dev] [RFC] multiversion ebuilds

> On Wed, 16 May 2018, Paweł Hajdan, wrote: > I'm wondering: if the main goal would be more code sharing between > ebuilds, would something like > > (essentially per-package eclasses) be an option? eblits! /me hides

[gentoo-dev] Re: [PATCH v3] eapi7-ver.eclass: Support EAPIs 0 to 6.

Pushed. pgpXWj3WGLB6c.pgp Description: PGP signature

Re: [gentoo-dev] [RFC] multiversion ebuilds

> On Sat, 12 May 2018, Gerion Entrup wrote: > just an idea for now. But what you think about multiversion ebuilds? > Technically this could be realized with the following line in the > ebuild itself: > ``` > VERSIONS=( 3.0.11 3.0.12 3.1 ) > ``` > [...] > The advantages of this idea I see

Re: [gentoo-dev] [PATCH] java-utils-2.eclass: port to EAPI 7

> On Tue, 8 May 2018, Marty E Plummer wrote: > --- > eclass/java-utils-2.eclass | 14 +++--- > 1 file changed, 11 insertions(+), 3 deletions(-) > diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass > index 25e35c33dd2..47bbb64ffd4 100644 > ---

[gentoo-dev] EAPI 7 can be used in the Gentoo repository

EAPI 7 has been approved by the Council one week ago [1]. The latest Portage version in ~arch (2.3.36) supports it, and the Infra team has upgraded the rsync master so that metadata cache generation will work correctly. Therefore, EAPI 7 ebuilds can be committed to the Gentoo repository from now

[gentoo-dev] Re: Old copyright assignments

>>>>> On Thu, 26 Apr 2018, Ulrich Mueller wrote: >> Reportedly, in the past at least some Gentoo developers signed >> copyright assignment forms [2] to Gentoo Technologies, Inc., and >> possibly later to the Gentoo Foundation. Bug 140286 [3] suggests >> that

Re: [gentoo-dev] rfc: virtual/init for init process

> On Thu, 26 Apr 2018, Jason Zaman wrote: >> IUSE="" > Dont you need: > IUSE="prefix selinux kernel_linux kernel_FreeBSD" prefix and KERNEL are injected from profiles/base/make.defaults, so no need to have them in IUSE. selinux might be needed indeed. Ulrich pgpowgaanGKEE.pgp

[gentoo-dev] Re: Old copyright assignments

>>>>> On Thu, 19 Apr 2018, Ulrich Mueller wrote: > Reportedly, in the past at least some Gentoo developers signed > copyright assignment forms [2] to Gentoo Technologies, Inc., and > possibly later to the Gentoo Foundation. Bug 140286 [3] suggests > that this no lon

Re: [gentoo-dev] [PATCH] freedict.eclass: rename dict.eclass, generalize

> On Wed, 25 Apr 2018, Marty E Plummer wrote: > Still, optimization or no, if app-text/dictd is looking at > /usr/lib/dict unconditionally and the app-dict/freedict-* dict files > are ending up in /usr/lib64/dict conditionally, something needs to > be fixed about that. So the dictionaries

Re: [gentoo-dev] [PATCH] freedict.eclass: rename dict.eclass, generalize

> On Wed, 25 Apr 2018, Marty E Plummer wrote: >> I don't see much code duplication there, so I think it would be >> cleaner to have a second eclass, rather than adding conditionals to >> the existing one. > I mean if you take into account app-dicts/dictd-* and freedict.eclass; > without the

Re: [gentoo-dev] [PATCH] freedict.eclass: rename dict.eclass, generalize

> On Tue, 24 Apr 2018, Marty E Plummer wrote: > Reworked to be usable with app-dicts/dictd-* ebuilds to avoid code > duplication I don't see much code duplication there, so I think it would be cleaner to have a second eclass, rather than adding conditionals to the existing one. > You can

[gentoo-dev] Old copyright assignments

Dear fellow (active and retired) developers, We (rich0, alicef, and myself) are currently working on a new Gentoo copyright policy, whose current draft version can be seen at [1]. One of its goals is to cover situations where Gentoo isn't the main copyright holder in a file. Connected to this is

Re: [gentoo-dev] Regarding the State of PaX in the tree

> On Mon, 16 Apr 2018, Michał Górny wrote: > W dniu nie, 15.04.2018 o godzinie 20∶04 -0400, użytkownik > Anthony G. Basile napisał: >> The question then is, do we remove all this code? As thing stands, >> its just lint that serves no current purpose, so removing it would >> clean things up.

Re: [gentoo-dev] [PATCH] eutils.eclass: split unique functions into eutils-r1

> On Sun, 8 Apr 2018, Marty E Plummer wrote: > Split all functions unique to eutils into eutils-r1, and inherit it > from eutils. Issue a QA warning on EAPI=6 ebuilds using eutils directly > and suggest migrating to direct use of the needed eclass, with a list of > functions unique to

Re: [gentoo-dev] [PATCH] eclass: freedict: require EAPI=6

> On Wed, 04 Apr 2018, Aaron Bauman wrote: > Marty, I will get this merged today. I apologize for the delay. Already done. :) One tiny change, namely I've added a trailing slash to the URL of the homepage. Thanks, Ulrich pgpM8BGhxc9yM.pgp Description: PGP signature

Re: [gentoo-dev] News item for Radicale upgrade

> On Fri, 30 Mar 2018, Christopher Head wrote: > Title: Radicale 2 requires pre-install migration > Author: Christopher Head > Posted: 2018-03-30 > Revision: 2 Please start with Revision 1 here. The revision should be increased only when an item is updated after publishing.

Re: [gentoo-dev] [PATCH] eclass: freedict: require EAPI=6

> On Wed, 28 Mar 2018, Marty E Plummer wrote: > How's this: Looks good to me. > --- > eclass/freedict.eclass | 18 ++ > 1 file changed, 10 insertions(+), 8 deletions(-) > diff --git a/eclass/freedict.eclass b/eclass/freedict.eclass > index 06419626d34..7c598aa6eaf 100644 >

Re: [gentoo-dev] [PATCH] eclass: freedict: require EAPI=6

> On Mon, 26 Mar 2018, Marty E Plummer wrote: > As a pretty simple eclass, which only inherited multilib in > order to get $(get_libdir) and eutils for who knows why, and > all its consumers bumped to EAPI=6, it makes sense to require > EAPI 6 for this eclass While at it: - Drop the IUSE=""

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

> On Fri, 23 Mar 2018, Roy Bamford wrote: > games-emulation/sdlmame is masked. I have a higher version in my > overlay than the one in the tree and it gets masked too. > Its not a problem to me as I know how to manage it. Its just untidy. You still don't need a repository specific mask

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

>>>>> On Fri, 23 Mar 2018, Francesco Riosa wrote: > Il 23/03/2018 10:48, Ulrich Mueller ha scritto: >> Conceptually that makes no sense. sys-devel/gcc is the name of an >> upstream package, so what does it even mean to mask it in one >> repository but not

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

> On Thu, 22 Mar 2018, Geaaru wrote: > for both portage and your fork I think that could be interesting add > an extension to PMS for define inside profiles or targets masking of > packages of a particular repslository. Currently PMS doesn't permit > this but have this feature could be help

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

>>>>> On Fri, 16 Mar 2018, Martin Vaeth wrote: > Ulrich Mueller <u...@gentoo.org> wrote: >> >> I think the conclusion is that github generates tarballs on the >> fly, and therefore we cannot rely on them being invariant over a >> l

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

>>>>> On Fri, 16 Mar 2018, Ulrich Mueller wrote: > I think the conclusion is that github generates tarballs on the fly, > and therefore we cannot rely on them being invariant over a long time. > They may be susceptible to changes in git, in tar, or in gzip. In fact, on

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

> On Thu, 15 Mar 2018, Martin Vaeth wrote: > Vadim A. Misbakh-Soloviov wrote: >> >> GH support answered me (in TL;DR version) "that's because we've >> upgraded git on *some* of our nodes" (means, some other using older >> git) > That would still require that the "git

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

> On Fri, 9 Mar 2018, Michał Górny wrote: > @@ -154,6 +165,12 @@ addread(){ __sb_append_var READ"$@" ; } > addwrite() { __sb_append_var WRITE "$@" ; } > adddeny(){ __sb_append_var DENY"$@" ; } > addpredict() { __sb_append_var PREDICT "$@" ; } > +if

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

> On Fri, 9 Mar 2018, Michał Górny wrote: > +if ! ___eapi_has_nonfatal_as_executable; then > + die "${0##*/} not supported as fallback helper in this EAPI" > +fi Nothing wrong with this, but this test isn't strictly necessary. PMS says in [1]: "Except where otherwise noted, they may be

Re: [gentoo-dev] [PATCH 3/6] epatch.eclass: Deprecate in EAPI 6

>>>>> On Tue, 06 Mar 2018, Michał Górny wrote: > W dniu wto, 06.03.2018 o godzinie 18∶41 +0100, użytkownik Ulrich Mueller > napisał: >> > > > > > On Tue, 6 Mar 2018, Michał Górny wrote: >> > + 6) >> > + # for eqawarn

Re: [gentoo-dev] [PATCH 3/6] epatch.eclass: Deprecate in EAPI 6

> On Tue, 6 Mar 2018, Michał Górny wrote: > + 6) > + # for eqawarn > + [[ -z ${_EUTILS_ECLASS} ]] && inherit eutils > ;; NACK. With this you defeat the whole purpose of splitting things off from eutils. In turn, eutils inherits a dozen of other

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

> On Sat, 3 Mar 2018, Michał Górny wrote: > Warn if the '=' package dependency operator is used along with pure > version with no revision specified. This means to catch a common mistake > of developers copying '=' from upstream dependency specification while > '~' operator would be more

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

> On Sat, 03 Mar 2018, Michał Górny wrote: > I don't really want to go into this. As far as I'm concerned, I can > leave defunct '-d' and just check dev profiles unconditionally. WFM. Or even better, leave defunct -d/--include-dev in place (in order not to break peoples' scripts) and add a

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

> On Sat, 03 Mar 2018, Michał Górny wrote: >> It seems counter-intuitive for a simple binary option to require an >> argument. What is wrong with specifying -d to enable the option, >> and simply not specifying it to disable? > What is wrong is that a number of developers have historically

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

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

[gentoo-dev] Last rites: app-emacs/{emacs-wiki,javascript,mcomplete}

# Ulrich Müller (21 Feb 2018) # Last release in 2006. Homepage is dead. Upstream says # that app-emacs/muse should be used as replacement. # Masked for removal in 30 days. Bug #619194. app-emacs/emacs-wiki # Ulrich Müller (21 Feb 2018) # Obsolete predecessor of

Re: [gentoo-dev] [PATCH] glep-0068: Add element to metadata.xml

> On Tue, 20 Feb 2018, Michał Górny wrote: > +- zero or more elements, possibly restricted > + to specific package versions (at most one for each version) whose presence Rather than versions, it might make more sense to allow restricting this to specific slots. I suggest to update the

Re: [gentoo-dev] EAPI 7 in Portage needs YOU!

> On Mon, 19 Feb 2018, Michael Lienhardt wrote: >> 2. ||= (binding any-of) dep groups. > I don't understand what this group means, and the PMS-7 is unclear as well: > "binding-any-of A binding-any-of group, which has the same format > as the any-of group, but begins with the string ||=

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

> On Fri, 16 Feb 2018, Michał Górny wrote: > Could you please use quotes instead of backslash escapes all the > way? They're generally less confusing since escapes trigger > different behavior in different contexts in bash. Done for the parentheses, and removed escaping of the plus sign

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

Currently the return status of e{cvs,svn,git}_clean is not at all reliable, because only the last command in the pipeline is tested. In addition, there are two pipelines in ecvs_clean, and the exit status of the first one is completely ignored. Another issue is that xargs -0 is an extension not

Re: [gentoo-dev] rfc: Remove inherit eutils from font.eclass for EAPI=6

> On Wed, 14 Feb 2018, Jonas Stein wrote: > I think we do not need > inherit eutils > https://github.com/gentoo/gentoo/blob/master/eclass/font.eclass#L9 > for the case that EAPI=6 What is eutils needed for in EAPIs 0 to 5? Ulrich pgpnMLnuhBQTB.pgp Description: PGP signature

[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

>>>>> On Tue, 13 Feb 2018, Ulrich Mueller wrote: > [about QA's role] Sorry, I didn't spend attention to the fact that the message I was replying to was in the wrong list. Please continue in gentoo-project where this thread belongs. pgp8a3bnmBxzU.pgp Description: PGP signature

[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

> On Tue, 13 Feb 2018, Chí-Thanh Christopher Nguyễn wrote: > Dean Stephens schrieb: >>> QA and Comrel are special in that they can take disciplinary >>> action against non-members, which there is no recourse against >>> except appeal to the Council. >>> >> At the very least: QA, Comrel, IRC

Re: [gentoo-dev] SAT-based dependency solver: request for test cases

> On Sat, 10 Feb 2018, Michał Górny wrote: > Example: many packages have impossible circular dependencies. > However, Portage conditionally pretends they don't exist, preferring > some random install-time breakage over fixing the packages in > question. Isn't that what the PMS allows,

Re: [gentoo-dev] rfc: handling the "uucp" group

> On Thu, 8 Feb 2018, R0b0t1 wrote: > It makes the most sense to me to give a uucp user dialout or tty > permission, instead of adding myself to the uucp group, a name which > references programs most people won't have installed and won't know > about. The tty group has an entirely

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

> On Thu, 8 Feb 2018, Mike Gilbert wrote: > Eliminating ROOTPATH seems like a significant change. Was this > officially discussed somewhere that I missed? > I actually support the change, but other people should be given the > chance to complain about it on the record. It contradicts the

Re: [gentoo-dev] rfc: handling the "uucp" group

> On Thu, 8 Feb 2018, William Hubbs wrote: > First, baselayout has had the "dialout" group since 2015, so the > longterm fix imo is to possibly use that instead of the uucp group. > What would it take to make that happen, or are we stuck with the > uucp group forever? There was an old

Re: [gentoo-dev] [PATCH] bzr.eclass: Drop bzr_bootstrap and bzr_src_prepare.

> On Wed, 07 Feb 2018, Michał Górny wrote: >> -# @FUNCTION: bzr_src_prepare >> -# @DESCRIPTION: >> -# Default src_prepare(), calls bzr_bootstrap. >> -bzr_src_prepare() { >> -bzr_bootstrap >> } > Hmm, unless I'm mistaken, this can cause another definition > of src_prepare to start

Re: [gentoo-dev] [PATCH] bzr.eclass: Add --overwrite-tags option to pull command.

> On Tue, 6 Feb 2018, Kristian Fiskerstrand wrote: >> Fixes: https://bugs.gentoo.org/446422 > Bug or Closes, Fixes would be referencing a commit-id c.f GLEP 66. Updated, thanks for catching this. > More generally though, should we start requiring more verbose commit > messages for eclasses

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

>>>>> On Sun, 04 Feb 2018, Michał Górny wrote: > W dniu sob, 03.02.2018 o godzinie 09∶58 +0100, użytkownik Ulrich Mueller > napisał: >> > Add a check for common mistakes in commit messages. For now, it >> > is pretty rough and exits immediately but it sh

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

> On Fri, 2 Feb 2018, Michał Górny wrote: > Add a check for common mistakes in commit messages. For now, it is > pretty rough and exits immediately but it should be integrated with > the editor in the future. Have you tested this against existing commits in the gentoo repo? Ulrich

Re: [gentoo-dev] [PATCH] use.desc: Correct/clarify SSL/TLS-related flags

>>>>> On Tue, 30 Jan 2018, Gordon Pettey wrote: > On Tue, Jan 30, 2018 at 5:22 PM, Ulrich Mueller <u...@gentoo.org> wrote: >> NACK. This seems to imply that USE="-ssl gnutls" is not a valid >> configuration? What if the user prefers gnutls and the

Re: [gentoo-dev] [PATCH] use.desc: Correct/clarify SSL/TLS-related flags

> On Tue, 30 Jan 2018, Michał Górny wrote: > Correct the description of SSL/TLS-related flags to match their modern > use. USE=ssl is a feature flag that enables support for SSL/TLS, > while USE=gnutls and USE=libressl are implementation toggling flags. > Unify the descriptions a bit. Make

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

> On Tue, 30 Jan 2018, Kent Fredric wrote: > Please download: > > src_url1/filename1.tar.gz > src_url2/filename2.tar.gz > src_url3/filename3.tar.gz > > And install them to your $DISTDIR with DISTDIR is not valid in pkg_nofetch(), though. > > edistadd ./filename1.tar.gz

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

> On Tue, 30 Jan 2018, Kent Fredric wrote: >> How about "consecutive non-negative integer keys"? > "Unsigned" ? Even better. pgp7Pa8YgSSFa.pgp Description: PGP signature

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

> On Sun, 28 Jan 2018, Michał Górny wrote: > How about this then: > | This specification currently defines one section: ``[structure]``. > | This section defines one or more repository structure definitions > | using non-negative sequential integer keys. The definition with > | the ``0``

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

> On Sun, 28 Jan 2018, Michał Górny wrote: >> > This specification currently defines one section: ``[structure]``. >> > This section defines one or more repository structure definitions >> > using sequential integer keys. The definition keyed as ``0`` >> > is the most preferred structure.

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

> On Sat, 27 Jan 2018, Michał Górny wrote: > This specification currently defines one section: ``[structure]``. > This section defines one or more repository structure definitions > using sequential integer keys. The definition keyed as ``0`` > is the most preferred structure. The package

[gentoo-dev] Re: Why are ebuilds licensed GPL v2 only (no later version)?

> On Fri, 26 Jan 2018, Duncan wrote: > The switch to GPLv2-only would have been made in the fight for its life > that was the Gentoo/Zynot fork, and almost certainly had to do with > trying to ensure that the gentoo/x86 tree could not be taken private > without community recourse, in an

[gentoo-dev] Why are ebuilds licensed GPL v2 only (no later version)?

Apparently licensing of the Gentoo repository was changed from GPL-2+ to GPL-2 (only) in 2002, see for example [1] and [2]. I cannot find any announcement or discussion about this. Who was around in 2002 and still remembers what was the rationale? Ulrich [1]

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

> On Thu, 25 Jan 2018, Zac Medico wrote: > It seems to be a common assumption that it's allowed, this command > currently shows 163 results in the gentoo repo: > git grep -l pkg_nofetch | xargs grep 'e\(log\|info\).*DISTDIR' | wc -l There will be little breakage if it is only used in elog

Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)

> On Thu, 25 Jan 2018, Michał Górny wrote: > Here's the updated version: > --- > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic > verification of the Gentoo rsync repository distributed over rsync > by default. Looks like there's one "rsync" too much in that sentence.

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

>>>>> On Wed, 24 Jan 2018, Martin Vaeth wrote: > Ulrich Mueller <u...@gentoo.org> wrote: >> "Runtime dependencies (RDEPEND). These must be installed and usable >> before the results of an ebuild merging are treated as usable." >> https://projec

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

> On Wed, 24 Jan 2018, Martin Vaeth wrote: > Rich Freeman wrote: >> >> It would already be broken on any PMS-compliant package manager > No, it is solely the interpretation of the package manager. > PMS does not specify what information is stored in /var/db > or how that

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

> On Tue, 23 Jan 2018, Michał Górny wrote: > Here's a short set of patches that reworks eshowkw keyword display > & ordering to match my Bugzilla proposal [1]. Also, it fixes the wrong > classification of *-fbsd as Prefix arch. > Example output: > -

Re: [gentoo-dev] RFC: Bugzilla arch list reordering

> On Tue, 23 Jan 2018, Michał Górny wrote: > I've updated the example to include the variant suggested by > Dirkjan. All arches are order according to the popularity (based on > the results from his mail), except Prefix which I left at the bottom > as a special case. Whether you will have

Re: [gentoo-dev] [Patch] review vdr-plugin-2.eclass changes

> On Sun, 21 Jan 2018, Joerg Bornkessel wrote: > as the LINGUAS Variable will be deprecated in the Future, i have the > vdr-plugin-2.eclass adapted to L10N handling. > Please review and comment... AFAICS this is about *.po files, therefore gettext related. The eclass should _not_ be changed

Re: [gentoo-dev] News Item: GnuCash 2.7+ Breaking Change (v4)

> On Thu, 11 Jan 2018, Aaron W Swenson wrote: > 2018-01-11-GnuCash-Breaking-Change.en.txt Since its last update, GLEP 42 strongly recommends using a very short name, with at most 20 characters for the short-name identifier [1] (whose main purpose is to keep the name unique if more than one

Re: [gentoo-dev] [PATCH 1/2] profiles.desc: Reduce the status of most exp profiles to dev

> On Thu, 11 Jan 2018, Michał Górny wrote: >> So you're *promoting* the ones considered to be broken from "exp" >> to "dev"? > Please point me to one bit of documentation that says that 'dev' is > better than 'exp' because I haven't been able to find any. Well, > except the fact that PMS

<    4   5   6   7   8   9   10   11   12   13   >