Re: [gentoo-dev] pre-GLEP review: Maintainership structure

On 11/03/2015 05:15 PM, Michał Górny wrote: > > Please review, comment and answer the questions in TODOs ;-). > > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_structure > Much more sane than what we have now, thank you. My only question is about the name of the

Re: [gentoo-dev] Depending on a range of slots

On 11/02/2015 02:48 PM, Ciaran McCreesh wrote: > On Mon, 2 Nov 2015 14:33:57 -0500 > Michael Orlitzky <m...@gentoo.org> wrote: >> Followup question, which of these is less dumb? >> >> Option 1: berkdb? ( >=sys-libs/db-4:* > This doesn't mean what you think it

[gentoo-dev] Revision diffs

These days, if I'm careful to revbump when necessary AND limit my commits to one logical change, can I wind up going from (say) -r1 all the way to -r4 before pushing my changes. That looks a little weird to users, but whatever, I can explain it. The real annoyance is that I don't get decent diffs

Re: [gentoo-dev] Revision diffs

On 11/06/2015 08:34 AM, Kent Fredric wrote: > On 7 November 2015 at 02:16, Michael Orlitzky <m...@gentoo.org> wrote: >> These days, if I'm careful to revbump when necessary AND limit my >> commits to one logical change, can I wind up going from (say) -r1 all >> the w

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

On 10/14/2015 11:39 PM, Mike Frysinger wrote: > iputils is currently in @system for everyone. by default, it only > installs `ping`. do we feel strongly enough about this to require > all systems include it ? or should this wait for the long idea of > releasing stage4's instead of stage3's ? >

Re: [gentoo-dev] EAPI 6 portage is out!

On 11/17/2015 05:09 PM, Michał Górny wrote: > Fellow Developers! > > I have the pleasure to announce that portage-2.2.25 has just been > committed and it comes with complete EAPI 6 support. This effectively > means that from this moment forward Gentoo developers are permitted to > commit EAPI 6

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

On 11/18/2015 12:55 PM, Michael Orlitzky wrote: > > That's taking about half a second if I run it from the command-line. > ...and this takes even longer: cinfo = self.grab(['git', self._work_tree, 'diff-tree', '--name-status', '--n

Re: [gentoo-dev] ChangeLog - Infra Response; update 2015/11/11, potential impact to 30min rsync cycle

On 11/18/2015 09:48 AM, Peter Stuge wrote: > Peter Stuge wrote: >> Robin H. Johnson wrote: >>> However, the largest sticking point, even with parallel threads, is that >>> it seems the base ChangeLog generation is incredibly slow. It averages >>> above 350ms per package right now (at 19k packages

Re: [gentoo-dev] EAPI 6 portage is out!

On 11/17/2015 08:04 PM, Ian Stakenvicius wrote: > > If your PM doesn't support EAPI6, then those ebuilds will be ignored > just as if they do not exist. It is plenty safe. There can be > issues if EAPI5 or older ~arch packages start -needing- EAPI6-only > ~arch dependencies, but so long as

[gentoo-dev] [PATCH 1/2] php-ext-pecl-r2.eclass: fix eclass/function name comments.

While investigating bug #371985, I took a look at the php-ext-pecl-r2 eclass. There's nothing to be done there for prefix support, but there are a few places where the old revision -r1 shows up in some comments. This commit fixes them to -r2. Bug: 371985 Bug: 558612 ---

[gentoo-dev] [PATCH 2/2] php-ext-source-r2.eclass: add prefix support.

The php-ext-source-r2 eclass sets a bunch of environment variables of the form, PHPIZE=/usr/${libdir}/${1}/bin/phpize and also tests for the existence of an INI file using absolute paths. To accomodate a prefix environment, all of these paths need to be prefixed with $EPREFIX. This commit adds

[gentoo-dev] [PATCH 0/2] Add prefix support to php-ext-source-r2.eclass.

Add prefix support to php-ext-source-r2.eclass by prepending $EPREFIX in a few places. The second patch does that, and the first patch fixes some typos in php-ext-pecl-r2.eclass that were found in the process. Michael Orlitzky (2): php-ext-pecl-r2.eclass: fix eclass/function name comments

Re: [gentoo-dev] Summary line

On 08/31/2015 01:33 PM, Rich Freeman wrote: > On Mon, Aug 31, 2015 at 10:53 AM, Alec Warner wrote: >>> >>> Mostly, because when I see "A version is bumped" I immediately expect >>> to know which version the bump is to, but have to dig out the diff to >>> find out. >>> >> >> So

Re: [gentoo-dev] www-client/chromium gtk3 support

On 09/10/2015 08:33 AM, hasufell wrote: > > So you are saying for the unlikely case that someone runs gentoo on a > desktop system where he cannot even compile gcc, llvm and others without > waiting for 2 weeks or setting up his on binhost, we have to provide a > backup-path for him, so that gtk3

Re: [gentoo-dev] Inconsistent and messy layout of team maintainership in Gentoo

Replying somewhere randomly with an idea. Since projects are now on the wiki, why don't we use that as the canonical source of project members? It's machine readable, although not so nice to have it located outside the repo/ldap. The email alias would then be auto-generated from the project

Re: [gentoo-dev] Dynamic dependencies

On 10/01/2015 02:34 PM, Rich Freeman wrote: > > RDEPEND changes directly in ebuilds > Proposal 1: Anytime an RDEPEND in a non-virtual ebuild is changed, the > ebuild must be revisioned. This includes adding/removing inherited > eclasses which set RDEPENDs. > This gets conflated with dynamic

Re: [gentoo-dev] RFI: A better workflow for github pull requests

On 09/19/2015 05:16 PM, Daniel Campbell wrote: > > We'd just need a developer who's experienced in maintaining and > setting them up. > Has anyone ever set up Gitlab or Gerrit, managed by a package manager, in a way that a small bug won't grant anonymous write access to every single repository?

Re: [gentoo-dev] RFI: A better workflow for github pull requests

On 09/23/2015 04:40 AM, Todd Goodman wrote: > > We haven't had too many problems with it. Most of our problems seem to > be with people having issues with git itself (it was new to almost > everyone on the team) and not embracing a good workflow with it (or > trying to only use git via Eclipse.)

[gentoo-dev] last rites: dev-php/smarty-docs

# Michael Orlitzky <m...@gentoo.org> (21 Sep 2015) # Mask for removal in 30 days. Obsolete. Bug #561040. dev-php/smarty-docs

Re: [gentoo-dev] unnecessary revbump

On 10/06/2015 09:33 AM, William Hubbs wrote: > I don't think the revbump of net-misc/openconnect-7.06-r1 to -r2 was > necessary. When the change purely affects use flags, that is picked up > by the pm and there is no need to force everyone to rebuild the package. > -r1 is stable.

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

On 12/06/2015 11:49 AM, Michał Górny wrote: >> >> Is the testing performed per-push rather than per-commit? Either way, I >> would like to get a notification that something broke, even if it wasn't >> my commit at fault. Just change the word "blame" to "alert" so no one >> feels slandered. > > It

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

On 12/06/2015 09:36 AM, Michał Górny wrote: > > So what do you think? Would it be fine to mail the package maintainers > whenever their packages break? Would it be a problem if I just CC-ed > all the maintainers on the gentoo-automated-testing mails? Of course. Add the commit author, too: I

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

On 12/06/2015 11:00 AM, Michał Górny wrote: >> >> Of course. Add the commit author, too: I want to know if I break someone >> else's package. > > So far, can't do that since we don't know which commit exactly broke. I > don't want to do any heuristics that could blame the wrong person. > Is the

Re: [gentoo-dev] rfc: OpenRC public API definition

On 12/03/2015 12:36 PM, William Hubbs wrote: > All, > > I would like opinions on what is considered the public api of librc. > > 1) All definitions in rc.h, even though they are not formally documented > in man pages. > > 2) the definitions in rc.h which are documented in section 3 man pages. >

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-emulation/runc/

On 12/07/2015 01:26 PM, Matt Turner wrote: >> >> I fixed it now. > > This is happening with some frequency. Could we install a server-side > git hook that prevents pushes if an ebuild is added without a Manifest > change? It wouldn't have to verify anything more than that to catch > nearly all of

Re: [gentoo-dev] Re: rfc: openrc c api (librc) usage

On 12/16/2015 01:44 AM, Duncan wrote: >> >> look at the RDEPEND in ebuilds. if a package uses the libs, it should >> be listed there. > > Even with openrc still in @system? Doesn't look like that bug has been > fixed yet.[1] > No one agrees on which @system packages can be omitted from

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 12:49 PM, Rich Freeman wrote: > > My understanding (which could be wrong) is that this update will break > things even if the user never runs eselect php afterwards. I can't > tell you the last time I touched the php eselect module, because major > updates to php are rare. > I

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 08:40 AM, Michał Górny wrote: > > Therefore, I think you should really work on some kind of backwards > compatibility for people using '-D PHP5' that would prevent those kind > of issues at least for some migration period. With big fat warnings for > people who run it. > I wasn't

Re: [gentoo-dev] Re: [PATCH 01/15] scons-utils.eclass: Modernize the example not to rely on myescons...

On 01/01/2016 12:42 PM, Michael Palimaka wrote: > I don't see the absurdity. Two formally independent statements that are actually dependent because of some implicit shared state: >> >> src_configure() { >> local mycmakeargs=( >> ... >> ) >> cmake-utils_src_configure >> }

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 02:27 PM, Michael Orlitzky wrote: > > I may be able to fix that by simply including the old 70_mod_php5.conf > for backwards compatibility. > I just pushed a new revision with this fix. In eselect-php-0.8.2-r1, we ship both the new 70_mod_php.conf and the old 70_m

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/07/2016 07:52 PM, Marc Schiffbauer wrote: >> >> 3. I could try to hack some magic into eselect-php to detect whether or >>not you have -DPHP5 set. Something simple, like grepping /etc/conf.d >>/apache2 for "PHP5". In that case we could omit a notice. >>This one simultaneously

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 11:11 AM, Peter Stuge wrote: > > So pkg_postinst for >=eselect-php-0.8.1 should say something, but > ideally also the invocation - but I don't know if eselect-php is also > code or only data managed by eselect? The pkg_postinst is already there. The eselect-php routines are bash

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/04/2016 12:11 AM, Jeroen Roovers wrote: > >> Without updating APACHE2_OPTS, websites could end up serving >> PHP code (include configuration files with passwords) >> unprocessed to website visitors! > > That would mean there is an additional (local) security problem. > All PHP

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

On 01/06/2016 02:36 PM, Sebastian Pipping wrote: > On 05.01.2016 20:35, Michael Orlitzky wrote: >> I just pushed a new revision with this fix. In eselect-php-0.8.2-r1, >> we ship both the new 70_mod_php.conf and the old 70_mod_php5.conf. The >> latter comes with a b

Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: python_export_utf8_locale(), ensure sane locale

On 12/17/2015 08:23 PM, Tyler Pohl wrote: > Please reomove tylerap...@gmail.com from > the mailing list. Or please let me know how to get this done. > You are doing too much work, Michał. To unsubscribe, send a message to the address contained in the

[gentoo-dev] (e)changelog pages in the devmanual

Do we need to keep these around? 1. https://devmanual.gentoo.org/tools-reference/echangelog/ 2. https://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/ If not, I'll get rid of them and close bug #485314.

Re: [gentoo-dev] rfc: adding sbin directories to PATH for all users

On 11/25/2015 12:10 PM, William Hubbs wrote: > All, > > I would like for us to discuss adding the sbin directories to PATH for > all users. > > The only thing that procps installs in /sbin is sysctl. Why? It works when run as a normal user, as long as you don't try to change something sacred.

Re: [gentoo-dev] [RFC] New global USE flag: webp

On 06/04/2016 04:03 PM, M. J. Everitt wrote: >> > LOL - that still happens?! > Yeah, at least in the U.S. There was a "PHP 6", but everything went so wrong that they decided to just pretend that the number 6 doesn't exist. > I still see php5 installed as stable everywhere .. so perhaps php7

Re: [gentoo-dev] [RFC] New global USE flag: webp

On 06/04/2016 03:30 PM, M. J. Everitt wrote: > The existing use description might be considered slightly confusing, > potentially .. > I changed them to, Enable webp support for GD in php-5.x Enable webp support for GD in php-7.x

Re: [gentoo-dev] [RFC] New global USE flag: webp

On 06/04/2016 03:45 PM, Kristian Fiskerstrand wrote: > > would a REQUIRED_USE in newer versions make sense to force the new use > flag for people upgrading as a deprecation period? > You mean like requiring USE=webp (new) if the user has USE=vpx (old)? Sounds like a good idea. It's been totally

Re: [gentoo-dev] [RFC] New global USE flag: webp

On 06/04/2016 03:50 PM, M. J. Everitt wrote: > What's the migration path/timeline look like .. I'da thought it would be > months/years to move everything that's centred on php5 up to php7 if > that's the way things are going. What happened to php6 ?!? v5 and v7 are mostly compatible, and the few

Re: [gentoo-dev] [RFC] Global USE=gui

On 06/07/2016 02:57 PM, Michał Górny wrote: > > The point is that: > > 1. REQUIRED_USE is semi-machine-understandable while pkg_pretend() is > some random function crap. Why do users care about that? Why do I even care about that? The whole ebuild is random function crap. The only benefit is

Re: [gentoo-dev] app-text/htmltidy: Maintainer Request

On 06/06/2016 10:55 AM, Yury German wrote: > Well a few things need to happen: > > 1. app-text/tidy-html5 - Need to go Stabl > 2. dep and rdep need to be migrated to tidy-html5 and tested. > Please also make sure that tidy-html5 has the same KEYWORDS as htmltidy. We support a lot of the weird

Re: [gentoo-dev] [RFC] Global USE=gui

On 06/07/2016 04:59 PM, Michał Górny wrote: >> >> I'll believe this when I see it =P > > You won't because the Gentoo way is to create a shitload of hacks > instead of fixing the root issue. > I'm not arguing for anything here, I'm just toying around with an idea for fun. What we want is a way

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

On 06/12/2016 05:21 AM, Benda Xu wrote: > # let other packages install some of these headers > - rm -rf "${D}"/${ddir}/scsi #glibc/uclibc/etc... > + rm -rf "${ED}"${ddir}/scsi #glibc/uclibc/etc... Every rm, cp, mv, mkdir, dodir, cd, etc. needs "|| die".

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

On 06/12/2016 09:12 PM, Benda Xu wrote: > Michael Orlitzky <m...@gentoo.org> writes: >> >> Every rm, cp, mv, mkdir, dodir, cd, etc. needs "|| die". > > Thanks, updated. > > ... > > # Don't forget to make directory for sysfs > - [[

Re: [gentoo-dev] [RFC] New global USE flag: webp

On 06/04/2016 12:29 PM, waltd...@waltdnes.org wrote: > > dev-lang/php:vpx - Enable webp suppoprt for GD > > ?!?!?!?! Is that a typo? > Half and half. The "suppoprt" is obviously a typo, but unfortunately, PHP uses a bundled copy of GD, so that isn't. ...and there's more. In php-7.x, they've

Re: [gentoo-dev] [RFC] Global USE=gui

On 06/07/2016 12:20 PM, Michał Górny wrote: > > So many weird ideas... while the simplest one is a proper REQUIRED_USE > with gui being the control flag, and IUSE defaults to select > the preferred toolkit. > This is what came to my mind. The underlying problem that we are hitting (a la

Re: [gentoo-dev] [RFC] Global USE=gui

On 06/07/2016 12:20 PM, Michał Górny wrote: >> >> A pkg_pretend() message would certainly make sense and IMO be a good >> idea, but again this isn't any different than the situation as it >> stands now WITHOUT a USE=gui. Regardless I don't see this as a >> blocker to the idea. > > Nope, it

Re: [gentoo-dev] [PATCH 12/17] profiles: Remove unused php5-2 target

On 05/26/2016 02:43 PM, Michał Górny wrote: > --- > profiles/desc/php_targets.desc | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/profiles/desc/php_targets.desc b/profiles/desc/php_targets.desc > index 6108b0b..75d09ce 100644 > --- a/profiles/desc/php_targets.desc > +++

Re: [gentoo-dev] [PATCH 1/2] php-ext-source-r3.eclass: new revision supporting EAPI=6.

Thanks for the detailed review. I followed every suggestion except the doexe thing for *.so files (only because I don't understand the reasoning yet). The new version is attached. On 06/01/2016 01:47 PM, Michał Górny wrote: >> +DEPEND=">=sys-devel/m4-1.4.3 >> +

[gentoo-dev] [PATCH 0/2] New revisions of PHP extension eclasses

inherits that one. A migration guide for users can be found at, https://wiki.gentoo.org/wiki/Project:PHP/Php-ext-source-r3_migration_guide Michael Orlitzky (2): php-ext-source-r3.eclass: new revision supporting EAPI=6. php-ext-pecl-r3.eclass: new revision supporting EAPI=6. eclass/php-ext-pecl

[gentoo-dev] [PATCH 2/2] php-ext-pecl-r3.eclass: new revision supporting EAPI=6.

The php-ext-pecl eclasses are based mainly on the php-ext-source eclasses. Now that we have a new revision php-ext-source-r3.eclass, this new revision of php-ext-pecl inherits that. As a result, all of the changes affecting that revision also affect this one. A migration guide for users can be

[gentoo-dev] [PATCH 1/2] php-ext-source-r3.eclass: new revision supporting EAPI=6.

This is a new revision of the php-ext-source eclass that supports EAPI=6 (only) and cleans up some of the existing code. The list of user-facing changes is, * Support only EAPI=6. * PATCHES array/variable support. * DOCS array support (bug 512184). * Renamed my_conf and PHPSAPILIST

Re: [gentoo-dev] [PATCH 2/2] php-ext-pecl-r3.eclass: new revision supporting EAPI=6.

I'll start with the easy one first. A new version is attached. On 06/01/2016 01:53 PM, Michał Górny wrote: >> + >> +[[ -z ${MY_PV} ]] && MY_PV=${PV} > > Is MY_PV part of the API? If yes, document it, and preferably rename > into something more collision-proof. If not, you shouldn't be doing >

Re: [gentoo-dev] [PATCH] git-r3.eclass: Make EGIT_LIVE_* associative arrays

On 06/22/2016 08:34 PM, Dan Douglas wrote: > On 06/22/2016 07:12 PM, Ulrich Mueller wrote: >>> On Wed, 22 Jun 2016, Dan Douglas wrote: >> >>> + [[ >>> + ( BASH_VERSINFO[0] -ge 4 || EAPI -ge 6 ) && >>> + $(declare -p "EGIT_${livevars[idx+1]}"

Re: [gentoo-dev] [PATCH 00/16] devmanual: update the docs for post git-migration #558642

On 01/17/2016 02:55 AM, Gokturk Yuksek wrote: > Hi, > > The following patch series attempt to update devmanual to replace the > instances > of CVS with their git equivalents. Thank you! > - I am not sure about what to do with the subsection > Ebuild Functions/Miscellaneous Files/ChangeLog.

Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!

On 02/09/2016 02:53 PM, Ian Stakenvicius wrote: > > python-exec-cwrapper ? > Elmer Fudd goes to the bathroom? =) python-exec-candy

Re: [gentoo-dev] Automatic Bug Assignment

On 02/05/2016 04:34 PM, Kent Fredric wrote: > On 6 February 2016 at 10:10, Michael Orlitzky <m...@gentoo.org> wrote: >> How about, if there's (exactly) one portage-compatible atom >> in the summary and that package has (exactly) one maintainer, we >> auto-assign it? Oth

Re: [gentoo-dev] Automatic Bug Assignment

On 02/05/2016 03:47 PM, Rich Freeman wrote: > The main problem I see with auto-assignment is that some asignees end > up being black holes for bugs. If two active devs get their bugs > crossed it isn't a big deal since they'll just reassign them to each > other. If an active dev gets their bug

Re: [gentoo-dev] New schema language for metadata validation?

On 01/27/2016 10:28 AM, Dirkjan Ochtman wrote: > >> Therefore, I'd suggest we just ship properly hand-written XML Schema, >> with some nice comments. I don't see a reason to ship any RELAX-NG >> files unless we actually have tools that support only that. > > I'd be curious what Michael, Ulrich,

[gentoo-dev] [PATCH 1/1] php-pear-r1.eclass: add support for EAPI=6 and clean up the EAPI check.

The dev-lang/php dependency in php-pear-r1.eclass is calculated based on the EAPI. In newer EAPIs, we specify the "any slot" operator to avoid repoman warnings. Previously, the "any slot" operator was added only for EAPI=5; this commit adds it for EAPI=6. In addition, EAPIs 0, 1, 2, 3, and 4 are

Re: [gentoo-dev] [Proposal] Eclass for nodejs modules

On 02/29/2016 06:24 PM, Andrew Udvare wrote: > On 29/02/16 03:23, Geaaru wrote: >> >> In conclusion, it seems that is not accepted use of nodejs modules >> ebuild inside portage. It is right? >> >> > There used to be a CoffeeScript ebuild if you search back. I do not > remember how it worked but

Re: [gentoo-dev] [RFD] Adopt-a-package, proxy-maintenance, and other musings

On 01/21/2016 05:41 PM, waltd...@waltdnes.org wrote: > > Maybe we should start a "gentoo-ebuilds" mailing list to help regular > users learn the ins and outs of making ebuilds. Try gentoo-devhelp@lists.g.o, or the associated #gentoo-dev-help on IRC. We should be trying to get these things

Re: [gentoo-dev] New USE_EXPAND: POSTGRES

On 01/23/2016 07:26 AM, Aaron W. Swenson wrote: > In regards to: > https://archives.gentoo.org/gentoo-dev/message/877bee2af740e50e88f65cfe76126c0f > > I'm planning on introducing a new eclass to the tree and am also > considering adding a new USE_EXPAND as well that would control the > specific

Re: [gentoo-dev] Re: [PATCH v2 17/19] ebuild-writing/misc-files: remove ChangeLog section #485314

On 01/24/2016 07:43 PM, Ulrich Mueller wrote: >>>>>> On Sun, 24 Jan 2016, Gokturk Yuksek wrote: > >> From: Michael Orlitzky <m...@gentoo.org> > >> The ChangeLog section under misc-files is misleading now that our main >> repository has been swit

Re: [gentoo-dev] New schema language for metadata validation?

On 01/26/2016 02:52 PM, Dirkjan Ochtman wrote: > All, > > TL;DR: I think we should switch from DTD to RELAX NG (compact syntax, > ideally) for our XML validation needs. It is more expressive and more > readable. > A great idea. > What other stuff would need to be updated? > I would

Re: [gentoo-dev] New schema language for metadata validation?

On 01/27/2016 04:22 AM, Dirkjan Ochtman wrote: > On Tue, Jan 26, 2016 at 9:52 PM, Michael Orlitzky <m...@gentoo.org> wrote: >> I would appreciate examples of some common tasks like validating >> projects.xml, but since we don't have those now, it's not critical. >

Re: [gentoo-dev] CVS headers in ebuilds

On 04/10/2016 05:36 PM, Gordon Pettey wrote: > Or you could just use a branching workflow like Git has great support > for, and create your overlay as a branch of the main tree you're copying > ebuilds from. With recent versions, you can even have checkouts of > different branches from the same

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

On 05/20/2016 12:48 PM, Michał Górny wrote: > > That's not a case since GLEP doesn't define how it is configured. > And it's invalid to reference other groups in path=s of a defined > group. > I'm just playing language lawyer. The spec does say, A Package Manager implementing this

Re: [gentoo-dev] [RFC] How to deal with LINGUAS mess?

On 05/21/2016 03:41 AM, Michał Górny wrote: > > I see the following possibilities: > #2 is ugly and requires a special case due to a bad choice of variable name; #4 will never work. > 3. We remove LINGUAS from USE_EXPAND and stop using it. If ebuilds have > a good reason to use flags for

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

On 05/20/2016 10:01 AM, Michał Górny wrote: > > Please review the specification provided. The basic goal is to provide > an ability to use INSTALL_MASK alike USE flags -- with path groups that > are well-defined and described in the repository. > >

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

On 05/20/2016 11:34 AM, Daniel Campbell wrote: > > ...and the user has this in their install.mask file: > > [bash-completion] > path=/some/other/path > desc=some other description > I don't think that's allowed; the groups are specified by each repository's metadata/install-mask.conf, not by

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

On 05/20/2016 11:21 AM, Michał Górny wrote: > > ... > > Getting into implementation details, I'd probably go for: > > INSTALL_MASK="@bash-completion" > > but the exact syntax is left for various package managers. Paludis > and pkgcore would probably prefer a proper configuration file. >

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

On 05/20/2016 11:44 AM, Michał Górny wrote: > > I'd make '@' signify group names, like we do for sets. This would have > the side limitation that it would make it impossible to filter > filenames starting with '@' with the currently supported > path-or-filename syntax. > That may be the best we

Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT

On 05/10/2016 02:28 PM, Mike Gilbert wrote: > On Tue, May 10, 2016 at 11:08 AM, Michael Orlitzky <m...@gentoo.org> wrote: >> We have maybe 150 ebuilds in the tree using $ROOT in src_* functions. >> Some are bugs, but many look OK to me. Do we really want to say "never&q

[gentoo-portage-dev] [PATCH 0/1] Test PMS-compliant usage of the ROOT variable.

that are not so easy to fix will stand out once the trivial ones are. Perhaps in EAPI-$next, the warning can become an error. Michael Orlitzky (1): Add a test case for PMS-compliant usage of the ROOT variable. ebuild-test/root-var-usage/metadata.xml| 24 ++ ebuild-test/root-var

Re: [gentoo-portage-dev] [PATCH 1/1] Add a test case for PMS-compliant usage of the ROOT variable.

On 05/11/2016 12:33 PM, Brian Dolbec wrote: > > I'll work on adding this check to repoman after I finish getting some > in progress changes done so the new repoman code can be released. > I took a look at the new code and it was really easy to get something working. I added a new QA category,

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 05/17/2016 06:01 AM, Pallav Agarwal wrote: > Hi, > You are right, of course. > The target is to standardize something that would encourage maintainers > to actually provide non-upstream scripts to test packages. At the same > time, it should be possible to use those scripts for automated

Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT

On 05/08/2016 01:42 PM, Mike Gilbert wrote: > The current description of ROOT makes no sense and just confuses people. > The new description is paraphrased from PMS. The current version is bad, but the PMS version isn't great either. We really need examples for D, ROOT, ED, EROOT, and EPREFIX.

Re: [gentoo-dev] Migrate to Phabricator

On 04/18/2016 09:44 AM, Kent Fredric wrote: > > Two trends struck out at me, and assuming everything mentioned ( or > linked in the related GHC entry[0] ) is still true: > They are. Most of the Haskell standard library is still undocumented. If anyone thinks Phabricator is a good idea, go

Re: [gentoo-dev] [PATCH] l10n.eclass: Sort and normalize PLOCALES in l10n_find_plocales_change

On 05/07/2016 04:13 PM, James Le Cuirot wrote: > > + if [[ $(tr -s "[:space:]" "\n" <<< "${PLOCALES}" | sort | xargs echo) > != ${current%[[:space:]]} ]] ; then The stuff on the left-hand side just sorts a space-separated list, right? It might be time to split that into another function. It

Re: [gentoo-dev] [PATCH] depend.apache.eclass - fix for EAPI6

On 07/14/2016 04:24 PM, Ian Stakenvicius wrote: > Hey all -- depend.apache.eclass currently calls get_libdir() in global > scope due to _init_apache2 being called by need_apache*() functions. > This patch drops _init_apache2 from these need_apache*() functions on > all EAPIS other than 0-5, and

Re: [gentoo-dev] News Item: OpenAFS no longer needs kernel option DEBUG_RODATA

On 07/20/2016 01:13 PM, NP-Hardass wrote: > Display-If-Installed: <=net-fs/openafs-kernel-1.6.18.2 > > ... > > Starting with net-fs/openafs-kernel-1.6.18.2, this condition is no longer > forced in the ebuild. Might not that version bound might backfire if someone upgrades before reading the

Re: [gentoo-dev] man pages: build or copy?

On 07/09/2016 09:54 AM, Neil Bothwick wrote: > I've created an ebuild for net-misc/zerotier [1]. This has a BDEP on > app-text/ronn, the build system uses it to create the man pages. The > trouble is that ronn is a Ruby program and pulls in a shedload of > dependencies, just to install man pages.

Re: [gentoo-dev] [PATCH 1/2] php-ext-source-r3.eclass: new revision supporting EAPI=6.

On 06/08/2016 03:34 PM, Michał Górny wrote: > > Next time, please inline and don't attach. It's awfully hard to reply > to both the reply and the attachment. Sorry, I was trying to hide the fact that I can't work Thunderbird. + newins "modules/${PHP_EXT_NAME}.so"

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

On 08/14/2016 05:35 PM, Kristian Fiskerstrand wrote: > > Some initial items it was suggested the WG look into is > * The b.g.o workflow, bugs should not be considered fixed until the >fix has reached the stable tree. Today the InVCS keyword exists for >this purpose, but it is used to

Re: [gentoo-dev] New Working Group established to evaluate the stable tree

On 08/15/2016 03:18 PM, Andreas K. Hüttel wrote: > Am Sonntag, 14. August 2016, 23:57:31 schrieb Ciaran McCreesh: >> >> I'm not sure what a group is. Is it anything like a herd? > > It's a set with a binary operator, with following fulfilled: > * closed with respect to the operation THIS IS PART

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/03/2017 10:30 AM, Ian Stakenvicius wrote: > > ok you lost me. Could you provide an explicit example of what you > would want to see enabled in the profile (while everything else is > disabled) that you don't get when USE="-*" is set? USE="hardened pax_kernel ..." > > It's sounding more

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/03/2017 01:33 PM, Patrick McLean wrote: > > We might as well go back to before IUSE defaults then. Part of the > advantage of IUSE defaults is maintainers don't all have to fiddle with > the profiles, everything can be self-contained in the ebuild. This > drastically complicates

Re: [gentoo-dev] Re: Requirements for UID/GID management

On 02/03/2017 09:51 AM, Martin Vaeth wrote: > Michael Orlitzky <m...@gentoo.org> wrote: >> >> The fact that all permission and ownership information is shared is >> precisely the problem. When you change ownership of the hardlink (which >> you'll never know is

Re: [gentoo-portage-dev] [PATCH] sys-apps/portage: add native-extensions USE flag (bug 571444)

On 02/01/2017 04:03 PM, Michał Górny wrote: >> SLOT="0" >> -IUSE="build doc epydoc +ipc linguas_ru selinux xattr" >> +IUSE="build doc epydoc +ipc linguas_ru native-extensions selinux >> xattr" > > Wouldn't it be better to enable it by default? > Please don't enshrine personal preferences into

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 06:41 PM, Ian Stakenvicius wrote: > Responding here instead of the first time it was posted, just 'cause. > > On 02/02/17 06:35 PM, james wrote: >> " >> I'm not saying that we should have a minimal experience out-of-the-box, >> only that the base profile should result in an

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 01:01 PM, Rich Freeman wrote: > On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky <m...@gentoo.org> wrote: >> >> If (base == minimal), then all of the upstream defaults need to be added >> to package.use for the upstream-defaults profile. That's bad, &

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/07/2017 02:52 AM, Ulrich Mueller wrote: > > I see no point in discouraging IUSE defaults, given that they are > purely advisory for the package manager: > > "[...] any use flag name in IUSE may be prefixed by at most one of a > plus or a minus sign. If such a prefix is present, the package

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 09:22 PM, Sam Jorna wrote: > > Also, how would this work with local USE flags as opposed to global > flags? Would they be acceptable to have IUSE defaults? > Exactly the same way as global flags: drop an entry in the desktop profile's package.use.

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 09:31 PM, Rich Freeman wrote: > > The desktop profile is going to do things like enable X11 support by > default. It isn't going to do things like enable bzip support in > ffmpeg (but not the new experimental codec that causes it to crash 25% > of the time, but which apparently

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 10:16 PM, Patrick McLean wrote: > > There are people who run servers on Gentoo, and don't particularly want > minimalism, then want a normal Linux system level of functionality (ie > upstream and/or sane defaults) without having to add dozens of USE > flags to random packages

Re: [gentoo-dev] Guidelines for IUSE defaults

On 02/02/2017 09:00 PM, Sam Jorna wrote: > > Consider: a new user, coming from Ubuntu or Fedora or Windows, starts > building their system. They start installing packages they want, only to > find that half of the package isn't there because no USE flags were > enabled. They have to enable

[gentoo-dev] Guidelines for IUSE defaults

IUSE defaults are used in a few different ways: 1 To ensure that critical functionality is enabled. * Example: force the "unix" module for apache. 2 To avoid an unsatisfied REQUIRED_USE by default. * Example: having a non-empty RUBY_TARGETS by default. 3 To make Gentoo defaults

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