Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

On 09/18/2012 03:35 AM, Ulrich Mueller wrote: >> On Tue, 18 Sep 2012, vivo75@gmail com wrote: > >> Il 18/09/2012 11:38, Ulrich Mueller ha scritto: >>> Which is longer than the original.;-) > >> RDEPEND=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 app-arch/xz-utils" >> DEPEND="${RDEPEND} vir

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

On 09/18/2012 12:29 PM, Ciaran McCreesh wrote: > On Tue, 18 Sep 2012 12:25:57 -0700 > Zac Medico wrote: >> Also, if we change the meaning of RDEPEND in the next EAPI, so that >> it's a hard build-time dep like DEPEND, then DEPEND="${RDEPEND} >> virtual/pkgconfig&

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

On 09/18/2012 12:44 PM, Ciaran McCreesh wrote: > On Tue, 18 Sep 2012 12:40:51 -0700 > Zac Medico wrote: >> On 09/18/2012 12:29 PM, Ciaran McCreesh wrote: >>> On Tue, 18 Sep 2012 12:25:57 -0700 >>> Zac Medico wrote: >>>> Also, if we change the me

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

On 09/18/2012 01:10 PM, Ciaran McCreesh wrote: > On Tue, 18 Sep 2012 12:58:30 -0700 > Zac Medico wrote: >> On 09/18/2012 12:44 PM, Ciaran McCreesh wrote: >>> On Tue, 18 Sep 2012 12:40:51 -0700 >>> Zac Medico wrote: >>>> On 09/18/2012 12:29 PM, Ciaran Mc

Re: [gentoo-dev] RFC: method of checking for cross compilation from ebuild functions

On 09/20/2012 10:34 AM, Ambroz Bizjak wrote: > The question now is, how should this method for checking > --crosscompile be implemented? In particular, we have two options: > > - Environment variable. If so, how to call it? Possible names are > CROSSCOMPILE, GENTOO_CROSSCOMPILE, PORTAGE_CROSSCOMPI

Re: [gentoo-dev] RFC: method of checking for cross compilation from ebuild functions

On 09/22/2012 09:08 AM, Ambroz Bizjak wrote: > Yes, I think this is a good idea, it would allow the dependencies to > be expressed nicely as conditions. > > But I'm not sure how this would be a USE flag. It should behave like > one during the build, but it would be best if it was not written into

Re: [gentoo-dev] RFC: method of checking for cross compilation from ebuild functions

On 09/22/2012 09:48 AM, Ambroz Bizjak wrote: > Zac, I think you misunderstood me here. Crosscompile-only HDEPEND is > definitely necessary, I've seen many packages need this. But what I'm > suggesting is that we also, and maybe only, need "ROOT != /" - only > HDEPEND dependencies. This means that t

Re: [gentoo-dev] RFC: method of checking for cross compilation from ebuild functions

On 09/22/2012 10:14 AM, Ambroz Bizjak wrote: > Yes, sysroot is much better, thanks :) > > So, does anyone have any objections to just having a sysroot condition > and no --crosscompile or FEATURES=crosscompile? > > Essentially, there's still tc-is-cross-compiler, if you want the real > cross-comp

Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.

On 09/23/2012 03:02 AM, hasufell wrote: > On 09/23/2012 11:56 AM, Michał Górny wrote: >>> So i would prefer some help/support with multilib-portage to get >>> it accepted sooner, instead of this additional workaround for a >>> subset of packages. > >> I prefer the simpler solution. > > > I prefe

Re: [gentoo-dev] patch eutils.eclass for EAPI 5

On 09/27/2012 09:49 AM, Ulrich Mueller wrote: > As far as I can see, only the definition of the usex function must be > disabled. Please review the patch included below. > > Ulrich > > --- eutils.eclass 15 Sep 2012 16:16:53 - 1.403 > +++ eutils.eclass 27 Sep 2012 16:45:14 - >

Re: [gentoo-dev] patch eutils.eclass for EAPI 5

On 09/27/2012 10:07 AM, Zac Medico wrote: > On 09/27/2012 09:49 AM, Ulrich Mueller wrote: >> As far as I can see, only the definition of the usex function must be >> disabled. Please review the patch included below. >> >> Ulrich >> >> --- eutils.eclass

Re: [gentoo-dev] patch eutils.eclass for EAPI 5

On 09/27/2012 10:16 AM, Ian Stakenvicius wrote: > On 27/09/12 01:07 PM, Zac Medico wrote: >> On 09/27/2012 09:49 AM, Ulrich Mueller wrote: >>> As far as I can see, only the definition of the usex function >>> must be disabled. Please review the patch inc

Re: [gentoo-dev] Let's populate IUSE_IMPLICIT in the base profile

On 09/27/2012 10:45 AM, Ian Stakenvicius wrote: > On 27/09/12 12:02 PM, Ian Stakenvicius wrote: >> On 27/09/12 11:57 AM, Mike Gilbert wrote: >>> On Thu, Sep 13, 2012 at 1:40 AM, Zac Medico >>> wrote: >>>> Hi, >>>> >>>> The council ha

Re: [gentoo-dev] Addressing GLEP-62 itself

On 09/27/2012 12:53 PM, Brian Harring wrote: > Bullshit. This is optional in the sense of embrace/extend 'optional'; > if one PM takes up the new functionality, all have to switch to > writing unfinalized deps to the VDB, and all have to switch to > transfering that IUSE_RUNTIME crap to the VDB

Re: [gentoo-dev] Addressing GLEP-62 itself

On 09/27/2012 01:30 PM, Ian Stakenvicius wrote: > On 27/09/12 04:13 PM, Zac Medico wrote: >> On 09/27/2012 12:53 PM, Brian Harring wrote: >>> Bullshit. This is optional in the sense of embrace/extend >>> 'optional'; if one PM takes up the new functionali

Re: [gentoo-dev] GLEP-0062: updated version for review

On 09/29/2012 02:42 AM, Michał Górny wrote: > Hello, > > Following the late discussion, I have updated GLEP-62. It no longer is > designed to be 'backwards compatible' and instead it was suited for > addition in a new EAPI. > > Thus, IUSE_RUNTIME is now independent of IUSE, and runtime dependenci

Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass

On 09/30/2012 07:12 AM, Fabian Groffen wrote: > Back then, we found it hurt us (Bad marshalling data) when using > binpkgs. Not sure if it still does today with Python 2.7. Somehow we > reached a consensus with the Python maintainer at that time that cache > stuff shouldn't be in VDB, also becaus

Re: [gentoo-dev] Proposal: removing "server" profile variants from profiles.desc

On 10/14/2012 09:22 PM, Mike Frysinger wrote: > sounds like we should extend the profiles.desc file or profile structure to > include a description so that people know the intention of each one. the > only > marker we had before was implicitly in the name (".../server" and > ".../desktop"). M

Re: [gentoo-dev] Re: [gentoo-dev-announce] PORTAGE_GPG_KEY strictness

On 10/17/2012 12:16 AM, Michał Górny wrote: > On Tue, 16 Oct 2012 22:54:04 + > "Robin H. Johnson" wrote: >> As such, we've decided to make the PORTAGE_GPG_KEY strictly enforce what >> was originally intended. >> >> - You must specify a key or subkey exactly. >> - The leading "0x" is optional.

Re: [gentoo-dev] Re: [RFC] Drop EAPI=0 requirement for system packages.

On 10/18/2012 09:09 PM, Ryan Hill wrote: > Anyways, we're seriously getting off topic here. I don't think anyone > objected to removing the EAPI 0 requirement for system packages (and in > reality no one follows it anyways. An EAPI 0 requirement for system packages is just silly these days. > E

Re: [gentoo-dev] eclass error-handling post-EAPI4

On 10/19/2012 07:23 AM, Gregory M. Turner wrote: > I'm cooking up some eclass functions and it occurred to me that perhaps > I had some responsibility regarding EAPI4's new error handling > semantics. After looking into it, it seems that, superficially, the > answer to my question is "no, the EAPI

Re: [gentoo-dev] eclass error-handling post-EAPI4

On 10/20/2012 03:52 AM, Gregory M. Turner wrote: > If I indeed understand the facts correctly, I'm still a bit > uncomfortable with your advice to just use "helper || die" in eclass > code. It seems to me that if I follow this recipe, >=EAPI4 kinda works > OK, but EAPI[0-3] doesn't. > > Specifica

Re: [gentoo-dev] eclass error-handling post-EAPI4

On 10/20/2012 02:24 PM, Gregory M. Turner wrote: > On 10/20/2012 4:05 AM, Ciaran McCreesh wrote: >> On Sat, 20 Oct 2012 03:52:49 -0700 >> "Gregory M. Turner" wrote: >>> Took me a while, but I think I see why this is correct, now (mostly >>> -- see below). The source of my confusion was a mistaken

Re: [gentoo-dev] eclass error-handling post-EAPI4

On 10/20/2012 03:51 PM, Gregory M. Turner wrote: > On 10/20/2012 11:16 AM, Zac Medico wrote: >> On 10/20/2012 03:52 AM, Gregory M. Turner wrote: >>> EAPI[0-3] conventions encourage the habit of writing ebuild code like >>> >>>invoke_fn || ... # handle error

Re: [gentoo-dev] [warning] the bug queue has 100 bugs

On 11/03/2012 09:29 PM, Ben de Groot wrote: > On 4 November 2012 08:28, Ian Stakenvicius wrote: >>> 03.11.12 09:04, Ben de Groot написав(ла): I think we need to come up with a better policy regarding elog messages, which would improve the signal to noise ratio. >> As of EAPI=4 (i th

Re: [gentoo-dev] net-irc/xchat

On 11/25/2012 12:27 PM, Lars Wendler wrote: > I also planned to release a news through the portage news system as soon as I > lastrite xchat so people know how to move over to hexchat. As I never did > this > before I'd like to have some help concerning this matter. Is there some > documentatio

Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook

On 11/28/2012 09:50 AM, Michał Górny wrote: > On Wed, 28 Nov 2012 10:05:55 -0500 > Richard Yao wrote: > >> On 11/28/2012 09:17 AM, Maxim Kammerer wrote: >>> On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao wrote: We could slightly simplify the handbook installation procedure if we told peo

Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook

ed a mirror://snapshots/index.html containing the string "portage-2012". -- Thanks, Zac >From a4126418bf102f70249092cab9fa294be5b27635 Mon Sep 17 00:00:00 2001 From: Zac Medico Date: Fri, 30 Nov 2012 23:28:30 -0800 Subject: [PATCH] Add mirrorselect --list-only option --- mirrorselect/main.py | 9

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/02/2017 06:47 AM, Michael Orlitzky wrote: > On 03/02/2017 09:24 AM, Mike Gilbert wrote: >>> >>> In other words, the ":=" only does something special in RDEPEND. That >>> makes sense when you think of it as meaning "the thing will break" >>> rather than "I want to do a rebuild." The only reaso

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On 03/02/2017 11:24 AM, Michael Orlitzky wrote: > On 03/02/2017 02:05 PM, Zac Medico wrote: >>> >>> This is why we can't have nice things. >> >> For those that are interested, I'm planning to to make --with-bdeps >> automatically enabled when pos

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On Tue, Mar 7, 2017 at 4:38 PM, William Hubbs wrote: > On Tue, Mar 07, 2017 at 07:13:38PM -0500, Michael Orlitzky wrote: >> If all dev-go libraries wind up in RDEPEND solely to force rebuilds on >> upgrades, why not do the same with the standard library (dev-lang/go)? > > They should not end up in

Re: [gentoo-dev] new virtual -- virtual/go to fix go build time dependencies

On Wed, Mar 8, 2017 at 11:20 AM, William Hubbs wrote: > On Wed, Mar 08, 2017 at 07:44:01AM -0500, Michael Orlitzky wrote: >> On 03/08/2017 01:27 AM, Zac Medico wrote: >> > On Tue, Mar 7, 2017 at 4:38 PM, William Hubbs wrote: >> >> On Tue, Mar 07, 2017 at 07:13:38PM

[gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat

Add forward compatibility up to python3.9. It's helpful to allow some flexibility in ebuild PYTHON_COMPAT settings, for third-party repositories that may be used with multiple snapshots of the gentoo repository. --- eclass/python-utils-r1.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat

On Tue, May 2, 2017 at 12:01 PM, Michał Górny wrote: > On wto, 2017-05-02 at 11:49 -0700, Zac Medico wrote: > > Add forward compatibility up to python3.9. It's helpful to allow some > > flexibility in ebuild PYTHON_COMPAT settings, for third-party > > repositories that

[gentoo-dev] [PATCH] python-utils-r1.eclass: support PYTHON_IMPLS_NO_STRICT variable

This is intended to be set by the user when using ebuilds that may have unknown implementations in PYTHON_COMPAT. The assumption is that the ebuilds are intended to be used within multiple contexts which can involve revisions of this eclass that support different python implementations. --- eclass

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat

On Tue, May 2, 2017 at 1:08 PM, Michał Górny wrote: > On wto, 2017-05-02 at 12:11 -0700, Zac Medico wrote: > > On Tue, May 2, 2017 at 12:01 PM, Michał Górny wrote: > > > > > On wto, 2017-05-02 at 11:49 -0700, Zac Medico wrote: > > > > Add forward compatibil

[gentoo-dev] Re: [PATCH] python-utils-r1.eclass: support PYTHON_IMPLS_NO_STRICT variable

On Tue, May 2, 2017 at 2:48 PM, Zac Medico wrote: > This is intended to be set by the user when using ebuilds that may > have unknown implementations in PYTHON_COMPAT. The assumption is > that the ebuilds are intended to be used within multiple contexts > which can involve revis

Re: [gentoo-dev] Re: [PATCH] python-utils-r1.eclass: support PYTHON_IMPLS_NO_STRICT variable

On Thu, May 4, 2017 at 10:29 PM, Michał Górny wrote: > Dnia 4 maja 2017 22:34:56 CEST, Zac Medico > napisał(a): > >On Tue, May 2, 2017 at 2:48 PM, Zac Medico wrote: > > > >> This is intended to be set by the user when using ebuilds that may > >> have unkn

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: support PYTHON_IMPLS_NO_STRICT variable

On Tue, May 16, 2017 at 10:19 AM, Michał Górny wrote: > On wto, 2017-05-02 at 14:48 -0700, Zac Medico wrote: > > This is intended to be set by the user when using ebuilds that may > > have unknown implementations in PYTHON_COMPAT. The assumption is > > that the ebuilds ar

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

On Sat, Jul 8, 2017 at 4:09 PM, William L. Thomson Jr. wrote: > Sets are also used for package rebuilds, like x11-module-rebuild, > live-rebuild, and others. Usually there are better ways to trigger rebuilds. For example, slot operator dependencies for rebuilds due to subslot changes, and --newus

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

On Sat, Jul 8, 2017 at 4:46 PM, William L. Thomson Jr. wrote: > On Sat, 8 Jul 2017 16:35:34 -0700 > Zac Medico wrote: > >> For live-rebuild, it would be >> much nicer to have a framework that automatically triggers rebuilds >> when upstream changes are detect

Re: [gentoo-dev] Re: Sets vs Meta ebuilds

On Sat, Jul 8, 2017 at 6:39 PM, William L. Thomson Jr. wrote: > On Sat, 8 Jul 2017 18:30:10 -0700 > Zac Medico wrote: > >> On Sat, Jul 8, 2017 at 4:46 PM, William L. Thomson Jr. >> wrote: >> > On Sat, 8 Jul 2017 16:35:34 -0700 >> > Zac Medico wrote: &

[gentoo-dev] Re: [gentoo-portage-dev] FEATURES=splitdebug and debugedit

On 10/12/2017 02:24 PM, Francesco Riosa wrote: > hi, > >     FEATURES=splitdebug at the moment require package dev-util/debugedit > which is a lagging behind upstream. > However package app-arch/rpm (from which debugedit is forked) always > install the same binary in ${ROOT}/usr/libexec/rpm/debuge

Re: [gentoo-dev] Packages up for grabs

On 11/29/2017 04:03 PM, Alex Brandt wrote: > Hey, > > These packages are up for grabs, and many of them I'm sure can be added > to the python project as deemed appropriate. > > * dev-python/aiohttp > * dev-python/multidict I'll be happy to take these two. -- Thanks, Zac

Re: [gentoo-dev] Managing updates on many identical Gentoo systems

On 01/18/2018 08:13 AM, Alec Warner wrote: > On Thu, Jan 18, 2018 at 6:46 AM, Anthony G. Basile > wrote: > > Hi everyone, > > I'm trying to design an update system for many identical Gentoo systems. >  Using a binhost is obvious, but there are still proble

Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems

On 01/19/2018 07:03 AM, Anthony G. Basile wrote: > On 1/19/18 9:45 AM, Alec Warner wrote: >> On Thu, Jan 18, 2018 at 5:13 PM, Bill Kenworthy wrote: >> >>> On 18/01/18 23:36, Duncan wrote: Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excerpted: > I'm trying to design

Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems

On 01/20/2018 07:34 AM, Anthony G. Basile wrote: > On 1/19/18 10:03 AM, Anthony G. Basile wrote: >> >> Zac pretty much nailed the requirements in bug #644990. You should not >> need the portage tree at all, neither locally nor via any network >> filesystem. He mentions there that it is currently

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

Hi, In sys-app/portage-2.3.20, emerge now defaults to --dynamic-deps=n. This means that unless people explicitly set EMERGE_DEFAULT_OPTS="--dynamic-deps=y" they're going to have to rebuild packages any time that the runtime dependencies of those packages need to be updated. It's possible to trigge

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

On 01/21/2018 08:57 PM, Michael Orlitzky wrote: > 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 v

[gentoo-dev] News Item: Portage Dynamic Deps

Please review. Title: Portage Dynamic Deps Author: Zac Medico Posted: 2018-01-28 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: Title: Portage Dynamic Deps Author: Zac Medico Posted: 2018-01-28 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: signature.asc Description: OpenPGP

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

On 01/22/2018 05:14 AM, Mart Raudsepp wrote: > On Sun, 2018-01-21 at 20:24 -0800, Zac Medico wrote: >> Hi, >> >> In sys-app/portage-2.3.20, emerge now defaults to --dynamic-deps=n. >> This >> means that unless people explicitly set >> EMERGE_DEFAULT_OPTS=&quo

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

On 01/23/2018 01:06 AM, Mart Raudsepp wrote: > On Mon, 2018-01-22 at 12:07 -0800, Zac Medico wrote: >> On 01/22/2018 05:14 AM, Mart Raudsepp wrote: >>> On Sun, 2018-01-21 at 20:24 -0800, Zac Medico wrote: >>>> Hi, >>>> >>>> In sys-app/portage

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

On 01/22/2018 12:24 AM, Alexis Ballier wrote: > On Sun, 21 Jan 2018 23:01:08 -0800 > Zac Medico wrote: > >> Please review. >> >> Title: Portage Dynamic Deps >> Author: Zac Medico >> Posted: 2018-01-28 >> Revision: 1 >> News-Item-Format: 2.0 &

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

On 01/22/2018 01:38 AM, Dirkjan Ochtman wrote: > On Mon, Jan 22, 2018 at 8:01 AM, Zac Medico <mailto:zmed...@gentoo.org>> wrote: > > According to Gentoo policy, future ebuild dependency changes need to be > accompanied by a revision bump in order to trigg

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

On 01/22/2018 02:28 AM, Andreas K. Huettel wrote: > Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico: >> >> According to Gentoo policy, future ebuild dependency changes need to be >> accompanied by a revision bump in order to trigger rebuilds for users. >>

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

On 01/28/2018 02:00 PM, Andrew Barchuk wrote: >> To the contrary, that would not remain balanced, because your >> boundaries are entirely dependent on exactly what is in the tree at >> the moment you run your script. Now the package manager has to perform >> directory listing, sort and find the fil

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

On 02/19/2018 11:38 AM, Michał Górny wrote: > W dniu pon, 19.02.2018 o godzinie 21∶32 +0200, użytkownik Mart Raudsepp > napisał: >> On Mon, 2018-02-19 at 18:34 +0100, Ulrich Mueller wrote: On Mon, 19 Feb 2018, Michael Lienhardt wrote: > > 2. ||= (binding any-of) dep groups. >>

[gentoo-dev] News Item: Portage rsync tree verification unstable

Please review. This is needed in order to resolve https://bugs.gentoo.org/650072. Title: Portage rsync tree verification unstable Author: Zac Medico Posted: 2018-03-13 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: sys-apps/portage Starting with sys-apps/portage-2.3.24, Portage will no

Re: [gentoo-dev] News Item: Portage rsync tree verification unstable

On 03/10/2018 01:42 PM, Michał Górny wrote: > W dniu sob, 10.03.2018 o godzinie 13∶22 -0800, użytkownik Zac Medico > napisał: >> Please review. This is needed in order to resolve >> https://bugs.gentoo.org/650072. >> >> Title: Portage rsync tree verification

[gentoo-dev] News Item v2: Portage rsync tree verification unstable

Changes: * First paragraph rewritten by Robin Johnson * Fixes spelling of 'following' reported by Michael Everitt Title: Portage rsync tree verification unstable Author: Zac Medico Posted: 2018-03-13 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: sys-apps/portage Por

Re: [gentoo-dev] News Item v2: Portage rsync tree verification unstable

On 03/11/2018 12:39 AM, Michał Górny wrote: > W dniu sob, 10.03.2018 o godzinie 15∶16 -0800, użytkownik Zac Medico > napisał: >> Changes: >> * First paragraph rewritten by Robin Johnson >> * Fixes spelling of 'following' reported by Michael Everitt

Re: [gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

On 03/10/2018 05:38 PM, Duncan wrote: > Zac Medico posted on Sat, 10 Mar 2018 15:16:29 -0800 as excerpted: > >> Changes: >> * First paragraph rewritten by Robin Johnson >> * Fixes spelling of 'following' reported by Michael Everitt >> >> >

Re: [gentoo-dev] Re: News Item v2: Portage rsync tree verification unstable

On 03/11/2018 09:58 PM, M. J. Everitt wrote: > On 12/03/18 04:53, Duncan wrote: >> Zac Medico posted on Sun, 11 Mar 2018 19:57:31 -0700 as excerpted: >> >>> I really don't want to spend a lot of time making revisions, and I think >>> "unstable" com

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

On 03/22/2018 01:17 PM, James Le Cuirot wrote: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górny wrote: > >> After 2+ years of repeating disagreements with Portage maintainer(s) >> I have finally decided to fork Portage. My little fork uses technical >> name of 'portage[mgorny]' [1] (to disting

Re: [gentoo-dev] [PATCH 2/2] java-utils-2.eclass: Drop sys-apps/portage build dependency

On 03/22/2018 02:22 PM, James Le Cuirot wrote: > It originates from 2006 and should arguably have never been added. > --- > eclass/java-utils-2.eclass | 12 ++-- > 1 file changed, 2 insertions(+), 10 deletions(-) These dependencies seem were only to pull in a version of portage supporting

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

On 03/22/2018 03:52 PM, Geaaru wrote: > Hi, > > a bit out of topic (sorry in advance) but connect to eventually new > portage feature... > > 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

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

On 03/24/2018 02:01 AM, Kent Fredric wrote: > On Sat, 24 Mar 2018 09:02:20 +0100 > Michał Górny wrote: > >> ...except that it is also used to say 'this is experimental version, >> unmask at will' and Portage wants to unmask stuff for you anyway. Well, >> I mean the default configuration of Portag

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

On 03/24/2018 01:33 PM, Kent Fredric wrote: > On Sat, 24 Mar 2018 11:27:20 -0700 > Zac Medico wrote: > >> The defaults certainly do not work perfectly in all situations. However, >> there are a vast number of situations where using --autounmask-continue >> will ma

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

On 03/24/2018 07:26 PM, Kent Fredric wrote: > On Sat, 24 Mar 2018 13:44:49 -0700 > Zac Medico wrote: > >> That only happens when dependency satisfaction fails by normal means. > > And when that happens, it is better to bail and go "Uh oh, something bad", > not

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

On 03/25/2018 02:02 AM, Kent Fredric wrote: > On Sat, 24 Mar 2018 21:43:41 -0700 > Zac Medico wrote: > >> But if the majority demographic is as you describe, then they shouldn't >> be using anything having dependencies that require package.unmask or ** >> keywords

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

On 03/26/2018 09:48 AM, Thomas Deutschmann wrote: > On 2018-03-23 18:44, Patrick McLean wrote: >> At my (and zmedico's) employer we use Gentoo heavily (all of our servers >> run it), and have a few large internal overlays and hundreds of internal >> profiles. There are packages in upstream Gentoo t

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

On 03/29/2018 10:20 PM, Michał Górny wrote: > Dnia 30 marca 2018 06:30:14 CEST, Zac Medico napisał(a): >> commit: 3f04d4d93d00afa5242a0c9459487c9eea7e9a6f >> Author: Zac Medico gentoo org> >> AuthorDate: Fri Mar 30 04:18:05 2018 + >> Commi

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

On 03/30/2018 01:42 AM, Michał Górny wrote: > Dnia 30 marca 2018 09:07:03 CEST, Zac Medico napisał(a): >> On 03/29/2018 10:20 PM, Michał Górny wrote: >>> Dnia 30 marca 2018 06:30:14 CEST, Zac Medico >> napisał(a): >>>> commit: 3f04d4d93d00afa5242a0c945

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

On 03/30/2018 08:16 AM, William Hubbs wrote: > On Fri, Mar 30, 2018 at 12:42:09PM +0200, Michał Górny wrote: >> Dnia 30 marca 2018 11:01:33 CEST, Zac Medico napisał(a): >>> On 03/30/2018 01:42 AM, Michał Górny wrote: >>>> Dnia 30 marca 2018 09:07:03 CEST, Zac Medic

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

On 04/26/2018 01:08 PM, William Hubbs wrote: > After some discussion on IRC, I need to drop busybox from this virtual > because it is in packages already. OpenRC needs to be dropped because > for now we do not have a way to make sure both openrc and sysvinit get > installed in stage 3 if openrc is

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

On 04/26/2018 11:34 PM, Kent Fredric wrote: > On Thu, 26 Apr 2018 13:35:15 -0700 > Zac Medico wrote: > >> emerge --depclean, resulting in an unbootable system. Just say-in. > > And depclean being very verbose doesn't do many favours here either. > > ( I regular

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

On 04/27/2018 08:45 AM, William Hubbs wrote: > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >>> On Thu, 26 Apr 2018 13:35:15 -0700 >>> Zac Medico wrote: >>> >>>> emerge --depclean

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

On 04/27/2018 08:43 AM, Pacho Ramos wrote: > El vie, 27-04-2018 a las 00:48 -0700, Zac Medico escribió: >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >>> On Thu, 26 Apr 2018 13:35:15 -0700 >>> Zac Medico wrote: >>> >>>> emerge --depclean

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

On 04/27/2018 08:45 AM, William Hubbs wrote: > On Fri, Apr 27, 2018 at 12:48:09AM -0700, Zac Medico wrote: >> On 04/26/2018 11:34 PM, Kent Fredric wrote: >>> On Thu, 26 Apr 2018 13:35:15 -0700 >>> Zac Medico wrote: >>> >>>> emerge --depclean

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

On 04/27/2018 11:43 AM, Rich Freeman wrote: > On Fri, Apr 27, 2018 at 2:18 PM Zac Medico wrote: > >> Actually, if things like sys-apps/s6 or sys-process/runit remain as >> choices for virtual/init, this isn't going to solve the problem of >> sys-apps/sysvinit being

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

On 05/06/2018 11:43 AM, Geaaru wrote: > Hi, > > I read documentation about new features for configure profiles, thanks. > > In the past I open a discussion about permit use of annotation > :: under profiles package.mask to mask from overlay for > example gentoo/upstream packages. > Is now support

Re: [gentoo-dev] EAPI 7, BDEPEND and pkg_*inst

On 05/30/2018 04:49 AM, Michael Haubenwallner wrote: > Hi, > > HOORAY, seems like EAPI 7 might be able to obsolete the "prefix-chaining" > portage patch I've carried in prefix-overlay all the time, thank you for that! > > However, a first thing being unclear already came up when bumping EAPI 6 to

Re: [gentoo-dev] Re: EAPI 7, BDEPEND and pkg_*inst

On 06/05/2018 01:26 AM, Michael Haubenwallner wrote: > On 06/04/2018 01:40 PM, Michał Górny wrote: >> I think the 'closest' thing to right would be to use BDEPEND+RDEPEND. >> It won't cover cross+binpkg but I guess it's as good as you can get. >> > > Having BDEPEND in RDEPEND will fix binpkg, but

[gentoo-dev] RFC: making ebuilds that provide mkfs.* programs include kernel config checks for fcaps (or other xattrs)

Hi, As suggested by Wojciech Myrda in bug 659486 [1], it would be helpful if sys-fs/e2fsprogs would use the linux-info eclass to warn if the kernel configuration doesn't include CONFIG_EXT4_FS_SECURITY=y when the user has expressed a desire to use file capabilities. This idea can be extended to an

[gentoo-dev] Re: [PATCH] eapply_user: allow empty directories

On 03/06/2016 03:01 PM, Jason A. Donenfeld wrote: > Without this, an empty directory in > /etc/portage/patches/$cat/$pkg will result in an fatal error. > > Fixes: 573920 > Signed-off-by: Jason A. Donenfeld > --- > bin/phase-helpers.sh | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-

Re: [gentoo-dev] Google API Go Client packages; slotting?

On 03/20/2016 11:45 PM, Andrew Udvare wrote: > https://github.com/google/google-api-go-client/ > > Looking at these to generate ebuilds for (with a script and GitHub API). > There might be an issue with assuming versions supersede (otherwise why > would they keep multiple versions up?). Can you c

Re: [gentoo-dev] Google API Go Client packages; slotting?

On 03/21/2016 12:44 AM, Andrew Udvare wrote: > On 21/03/16 00:05, Zac Medico wrote: >> On 03/20/2016 11:45 PM, Andrew Udvare wrote: >>> Currently I'm re-wrapping https://github.com/odeke-em/drive (I had done >>> this before when there were no Go helper eclasses). &

Re: [gentoo-dev] Google API Go Client packages; slotting?

On 03/22/2016 12:33 AM, Andrew Udvare wrote: > On 21/03/16 02:27, Zac Medico wrote: >> Yeah, I know. Anyway, I went ahead and packaged it. Please try it out >> and file bugs if there's anything wrong: >> >> https://gitweb.gento

[gentoo-dev] Re: [PATCH] nvme-cli: Fix cross compilation issue.

On 05/23/2016 04:08 PM, Gwendal Grignou wrote: > When not setting CC, the compilation fails on option: -clang-syntax > "gcc.real: error: unrecognized command line option '-clang-syntax'" > > Addressed the issue by properly setting the CC variable. > > Signed-off-by: Gwendal Grignou > --- > sys-

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

On 06/08/2016 06:16 AM, Alexander Berntsen wrote: > In the end, Gentoo might make a gigantic leap into the future with a > truly modular distribution. If anyone wants to look at distros that > get this more right than Gentoo, have a look at e.g. NixOS and Exherbo. > > What are your thoughts? The

Re: [gentoo-dev] RFC: kernel-2.eclass Prefix support

On 06/11/2016 08:02 AM, Benda Xu wrote: > Hi Fellows, > > This is a trivial patch for kernel-2.eclass to support Prefix. Does it > look good to be commited? The EPREFIX and EROOT variables are undefined prior to EAPI 3, so the eclass should die if the EAPI is 0, 1, or 2. -- Thanks, Zac

Re: [gentoo-dev] Re: RFC: kernel-2.eclass Prefix support

On 06/12/2016 02:02 AM, Benda Xu wrote: > Hi Ulrich, > > Ulrich Mueller writes: > >>> I have added EPREFIX logics for EAPI<3 and improved the trailing >>> slashes and quotes. >> >>> - [[ -f ${ROOT}/usr/include/linux/autoconf.h ]] \ >>> + [[ -f "${EROOT}"usr/include/linux/auto

Re: [gentoo-dev] JavaScript packages?

On Mon, Jul 4, 2016 at 1:20 AM, Nicolas Bock wrote: > On 07/04/2016 10:15 AM, Daniel Campbell wrote: >> On 07/04/2016 12:57 AM, Nicolas Bock wrote: >>> Hi, >>> >>> I would like to package a code that depends on JavaScript packages. The >>> suggested installation procedure from upstream involves ru

Re: [gentoo-dev] [RFC] new eselect module: compiler

On 08/08/2016 10:58 PM, Fabian Groffen wrote: > On 08-08-2016 13:45:07 -0500, R0b0t1 wrote: >> On Mon, Aug 8, 2016 at 11:23 AM, Lei Zhang wrote: >>> "cc" is the standard C compiler name defined in POSIX, so ideally any >>> gcc-agnostic programs should use "cc" instead of "gcc". Practically, >>> bu

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

On 08/24/2016 09:06 AM, Michael Orlitzky wrote: > On 08/24/2016 11:49 AM, Mike Gilbert wrote: >> >> You're right that the orignal purpose of the change has been debunked. >> >> So, starting over: one real benefit would be cross-compatibility with >> systemd. It's one less thing people would need to

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

On 08/24/2016 09:33 AM, Michael Orlitzky wrote: > * no benefit put forth so far, other than that it's the same file that > systemd uses, which is true but not beneficial as far as I can tell It's a de facto standard. Being different for the sake of being different is not a virtue in cases li

Re: [gentoo-dev] rfc: /etc/hostname on gentoo

On 08/27/2016 11:30 PM, Daniel Campbell wrote: > On 08/24/2016 09:42 AM, Zac Medico wrote: >> On 08/24/2016 09:33 AM, Michael Orlitzky wrote: >>> * no benefit put forth so far, other than that it's the same file that >>> systemd uses, which is true but not

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

On 09/16/2016 08:20 AM, Ulrich Mueller wrote: >> On Sat, 17 Sep 2016, Kent Fredric wrote: >> 4. Due to referential integrity, it should be trivial to identify which >> files are needed by a given ebuild, and which files are now redundant, >> assisting with keeping the tree pruned. > > How does

Re: [gentoo-dev] OpenPGP verification for gentoo-mirror repos

On 10/30/2016 01:44 PM, Michał Górny wrote: > Hi, everyone. > > Just a quick note: I've prepared a simple tool [1] to verify clones of > gentoo-mirror repositories. It's still early WiP but can be easily used > to verify a clone: > > $ ./verify-repo gentoo > [/var/db/repos/gentoo] > Untrust

Re: [gentoo-dev] OpenPGP verification for gentoo-mirror repos

I'm merging in Michał's reply from the related "[gentoo-portage-dev] [PATCH] [sync] Increase the default git sync-depth to 10" thread. On 10/30/2016 02:58 PM, Zac Medico wrote: > On 10/30/2016 01:44 PM, Michał Górny wrote: >> Hi, everyone. >> >> Just a q

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