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

On 01/29/2017 03:26 AM, Alan McKinnon wrote: >> >> Can anyone think of an upgrade path for fixed UIDs? That issue aside, I >> may have convinced myself that fixed UIDs are better. > > The general process I would recommend is that if the ebuild finds the user > already exists, leave it, it's UID

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

On 01/28/2017 10:23 PM, Gordon Pettey wrote: > > That's nonsense for reasons already mentioned by rich0. UIDs don't change > except in the case of an admin doing it manually. > It shouldn't be common, but it can and will happen once you put users in ebuilds. As an example, imagine an "echo"

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

On 01/28/2017 09:22 PM, Rich Freeman wrote: > > Honestly, I really will say "so what" here. :) > I forgot to mention a few of the advantages of having really-fixed UIDs. First, it makes the code simpler. Yup, cool. It also lets us play a nice trick and use the UID as a subslot, so that if

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

On 01/28/2017 09:22 PM, Rich Freeman wrote: >> >> Here's a problem I have no solution for. Suppose we tell everyone to >> pick a fixed UID for their user packages. I have a randomly assigned >> "tcpdump" user as UID 102 on my machine today. If we roll this out next >> week and the tcpdump

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

On 01/27/2017 11:21 PM, Rich Freeman wrote: > > It isn't like inconsistent UIDs are the end of the world. However, > IMO it still makes sense to at least try to standardize such things. > Really, if you have a package always installing the same user simply > sticking a default UID without any

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

On 01/27/2017 09:37 PM, Patrick McLean wrote: > > To make something to solve our problem (and I suspect everyone > else who cares about this), it would be sufficient to have a mechanism > to override the default random assignment with a fixed UID/GID. What I had in mind for this is that a

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

On 01/27/2017 04:15 PM, Michał Górny wrote: > >> * users-update: cleanup can be done with --depclean now. > > Err, cleanup is never easy. You shouldn't really remove a user if it > owns any files. I guess you could abuse pkg_prerm() for that but > depclean will be terribly slow then. > What

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

On 01/27/2017 02:53 PM, Rich Freeman wrote: > > I'm not saying we can't have random assignment for things where it > doesn't matter, or fall back to random assignment, but it seems rather > silly to go to all the trouble to have blockers when it would be just > as easy to not have a conflict in

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

On 01/27/2017 01:52 PM, Rich Freeman wrote: > > This doesn't really seem like a problem though. Just have a table > somewhere (wiki?) to track who is using what UID/GID and encode those > defaults into the ebuild that creates those users. > It should be possible to have two different users

[gentoo-dev] Requirements for UID/GID management

We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but never implemented it. I'm wondering what are the explicit requirements that we have for user and group management? What I'm really wondering is, instead of the proposal in GLEP27, if we couldn't simply handle users like any

[gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...

Forked from the gdbm/berkdb thread, wall of text ensues... On 01/27/2017 03:32 AM, Fabian Groffen wrote: > > You mention REQUIRED_USE should be used sparingly, I think I see your > reasoning, but if so, then why did we add it in the first place? There are a few conflicting interests at play.

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

On 01/26/2017 10:33 PM, Mike Gilbert wrote: > > Is there any reason to have these USE flags enabled globally? They are quite uncritical. > These USE seem pretty package-specific in scope. On my system, they > are used by around a dozen of 1000+ installed packages. I think it > might make sense

Re: [gentoo-dev] About ALLARCHES

On 01/24/2017 11:11 AM, Mart Raudsepp wrote: > > Currently this seems to be resulting in broken deptrees for arches that > don't have a stable profile. arm64 in particular. ALLARCHES should not include the unstable ones unless they are specifically in CC, and of course you should be running

Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles

On 01/23/2017 02:30 PM, Alexis Ballier wrote: > > repoman will test n out of 2^n (or n!) possibilities the way you > suggest, which is basically nothing when n is big > Corollary: big is basically nothing. I like it.

Re: [gentoo-dev] bzipped manpages

On 01/10/2017 06:54 AM, Jan Stary wrote: > > These are workarounds. Let me get back to the original question: > would you please consider having _uncompressed_ manpages as the default? > > On this particular system, the bzipped /usr/share/man/ is 67M. > The uncompressed man/ is 108M. That's 40M

[gentoo-dev] Drop global USE=frontbase

The "frontbase" USE flag has no consumers that I can find: gentoo.git $ grep -irl frontbase * profiles/arch/x86/use.mask profiles/use.desc profiles/base/use.mask If no one objects, I'll drop the flag and its masks.

Re: [gentoo-dev] The changes about the stabilization process

On 12/25/2016 02:55 PM, Andrew Savchenko wrote: > > What is a recommended way to describe how runtime testing should be > done? Some packages are quite complex and it is desired not only to > run them, but to run with some args or do some actions. > > Some ideas: > > ... The Emacs team came up

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-12-18 23:59 UTC

On 12/18/2016 08:19 PM, malc wrote: > I git'ified the original CVS scripts... it would be trivial to extract > the author-name (add %an in the format string for git-log), but we tried > to keep the generated e-mail to 80-char lines - and that would blow it. > One option would be to tag each

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-12-18 23:59 UTC

On 12/18/2016 07:05 PM, Robin H. Johnson wrote: > > Additions: > ... > dev-php/ca-bundle 20161124-07:43 mjo 7597666 > dev-php/cli-prompt20161124-07:21 mjo d3bd351 > dev-php/composer 20161124-08:09 mjo d273046 >

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add required @USAGE documentation to functions.

On 12/13/2016 06:11 AM, Mike Pagano wrote: > > You're absolutely right, Mike. It was the devmanual. > > I'm not a fan of having an empty usage. As the devmanual is written > today, it is not optional. > The devmanual is once again based on the awk script, which vaguely implies that USAGE is

Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish

On 12/10/2016 01:12 AM, A. Wilcox wrote: > > So for one example, at Adélie we are focusing hard on the musl libc. > At some point in the future, when we have things looking good, we can > contribute that back to the official Gentoo musl overlay. Ideally, > that would be the main Gentoo package

Re: [gentoo-dev] [PATCH] depend.apache.eclass: fix for EAPI=6

On 12/07/2016 03:59 PM, Andreas K. Huettel wrote: > > Hi Doug, > > I like it, actually more than my version- with one exception... if we do a > step with EAPI, we should be able to get this done without the -r1 mess. > > I'll try to whip up something reasonably elegant based on your patch...

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

On 12/04/2016 10:13 PM, A. Wilcox wrote: > > If there are no other objections to this proposal, would a PR that > implements this against the Gentoo tree be the best way forward? If > so, I can start work on that now while giving more people the chance > to read over it. (Would it be more

Re: [gentoo-dev] [PATCH] depend.apache.eclass EAPI=6 support

On 12/04/2016 06:18 PM, Andreas K. Huettel wrote: > Starting with EAPI=6, the variables APACHE_BASEDIR and APACHE_MODULESDIR > are not exported in global scope anymore. Currently, we emit a warning when using depend.apache with EAPI=6. How many packages are triggering that warning? If we stop

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

On 12/03/2016 09:25 AM, William L. Thomson Jr. wrote: >> >> This is generally considered infeasible: > > I would not think such, just need a wrapper to run around each package that > would get its USE flags and re-emerge it a few times. If a package has 10 USE flags, and if each can be set

Re: [gentoo-dev] Revision bumps vs git commits atomicity

On 12/02/2016 10:14 AM, Andrew Savchenko wrote: > > If both policies are to be followed, users will see something like: > foo-1.0 -> foo-1.1-r8 (assuming each sufficient change was made as > a separate commit with a revision bump). > > While such versioning change is technically correct, it is >

Re: [gentoo-dev] [PATCH] linux-info.eclass: get_version: remove useless readlink -f

On 11/30/2016 11:45 AM, Mike Gilbert wrote: > On Wed, Nov 30, 2016 at 11:28 AM, Michael Orlitzky <m...@gentoo.org> wrote: >> On 11/26/2016 12:47 PM, Mike Gilbert wrote: >>> The values get clobbered immediately afterward, so why bother? >>> ... >>&

Re: [gentoo-dev] [PATCH] linux-info.eclass: get_version: remove useless readlink -f

On 11/26/2016 12:47 PM, Mike Gilbert wrote: > The values get clobbered immediately afterward, so why bother? > ... > qeinfo "Determining the location of the kernel source code" > - [ -h "${KERNEL_DIR}" ] && KV_DIR="$(readlink -f ${KERNEL_DIR})" > [ -d "${KERNEL_DIR}" ] &&

Re: [gentoo-dev] Stabilisation procedure

On 11/17/2016 02:16 AM, Michael Palimaka wrote: > > # strict - have portage react strongly to conditions that have the > potential to be dangerous > ... > FEATURES="collision-protect ipc-sandbox network-sandbox sandbox > split-log split-elog strict test userfetch userpriv usersandbox" Maybe

Re: [gentoo-dev] Re: [RFC] New version constraints: variant one

On 11/10/2016 07:03 PM, Gordon Pettey wrote: > > Only if you're misusing revisions. A package depends on a another > package, not the ebuild revision of that package. > What if your package needs mine with SSL support, but mine was initially committed without SSL support and -r1 adds it?

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On 11/09/2016 02:42 AM, Michał Górny wrote: > >> apache2? ( www-servers/apache[apache2_modules_cgi] >= 2.4 ), > > In what order is that interpreted? Remember that you aren't allowed to > reference USE flags not in IUSE without (+) and (-). So if things are > parsed left-to-right, you

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On 11/08/2016 10:47 AM, Michał Górny wrote: > > Strictly speaking, we don't have to since the lexing should be > predictable enough. Of course, mistakes like missing version following > the operator would result in curious errors. > > The major problem with spaces I see is that it means we end

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On 11/08/2016 09:49 AM, Ulrich Mueller wrote: > > This wouldn't completely solve it, because we also have a := slot > operator. Oh, duh... > Brackets would help, or some new separator. Pick your poison: I would really like to have spaces around the infix operators, but then we need to

Re: [gentoo-dev] RFC: Future EAPI version operator changes

On 11/06/2016 05:52 AM, Michał Górny wrote: > > I've collected various ideas on operator changes on a wiki page [1]. > I've tried to stay open-minded and cover every possibility, even though > I doubt some of them would be even considered. > > ... > > So, what are your comments? > I read

Re: [gentoo-dev] [RFC] Problems and limitations of the current version dependency specs

On 10/31/2016 08:31 PM, Michał Górny wrote: > > 4. What are the common tasks that you find unnecessarily complex / > lengthy with the current version specifications? Slotted version ranges, for example: berkdb? ( || ( sys-libs/db:5.3 sys-libs/db:5.1

Re: [gentoo-dev] Commented packages in the @system set

On 10/26/2016 11:14 PM, Rich Freeman wrote: > > This is why I think "@system" oversimplifies all of this. IMO we > should just specify all dependencies for everything (and those could > include some virtuals for convenience, like the C toolchain), and then > have different sets or virtuals for

[gentoo-dev] Commented packages in the @system set

Looking at profiles/base/packages, I see a bunch of lines that are commented out. For example, *sys-apps/which #*sys-devel/autoconf #*sys-devel/automake *sys-devel/binutils #*sys-devel/bison #*sys-devel/flex *sys-devel/gcc Does anyone know why those are commented as opposed to

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

On 10/18/2016 08:03 PM, Benda Xu wrote: > > This will be an important reference. Please consider adding it into the > wiki after we reach a wider consensus on how to merge pull request on > github. It's been there for a long time:

Re: [gentoo-dev] Package file name requirement for binary ebuilds

On 10/17/2016 01:43 AM, Ian Stakenvicius wrote: > > There is also no particular policy that I am aware of for ensuring > packages are designed to be built from source first and foremost. If all you're looking for is something to cite, then binary packages run afoul of most of our existing QA and

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-check-openmp() function

On 10/13/2016 04:35 PM, David Seifert wrote: > + ewarn "Your current compiler does not support OpenMP" > + > + ... > + > + die "Active compiler does not have required support Hey, a message that isn't about comrel. Since you're going to die(), isn't eerror more

Re: [gentoo-dev] rfc: the demise of grub:0

On 10/03/2016 05:59 PM, William Hubbs wrote: > > - The only real problem with grub:2 has to do with pperception. Yes, > their documentation has a strong preference toward using their > configuration script (grub-mkconfig) to generate your grub.cfg, but > this is not required. > Migration

Re: [gentoo-dev] depend.apache.eclass and EAPI=6

On 09/30/2016 05:58 PM, Andreas K. Huettel wrote: > > app-eselect/eselect-php-0.9.1 Waiting on stabilization of the fixed version: https://bugs.gentoo.org/show_bug.cgi?id=592968 arm, hppa, ia64, ppc, ppc64, sparc, and x86.

Re: [gentoo-dev] questions about small fixes/cleanups

On 09/14/2016 09:50 AM, Alexis Ballier wrote: > > that might be better, but how do you map date / $PV to commit ? > Well, for that last one, I just looked down the list of commits and found the last one that happened before the date of the snapshot. But, if you're creating a new snapshot, it's

Re: [gentoo-dev] questions about small fixes/cleanups

On 09/14/2016 09:21 AM, Alexis Ballier wrote: > > Guess you never had to maintain packages whose releases are only > snapshots. They're trivial but it's a waste of time to re-assemble all > the bits every couple of months when you want to make a snapshot. > > Questions one needs to answer: > >

Re: [gentoo-dev] questions about small fixes/cleanups

On 09/14/2016 01:54 AM, Ulrich Mueller wrote: > > We had a review of such files before the git conversion: > https://bugs.gentoo.org/550434 > > Especially, there's a list of "maintainer scripts" in comment #13. > At the time, we didn't do anything about them. There are very few of > such files

Re: [gentoo-dev] questions about small fixes/cleanups

On 09/13/2016 02:57 PM, Michael Mair-Keimberger wrote: > > * Redirection: There are quite a few pages which aren't exactly offline, > but only forward the request to the current homepage. (like most > of the gentoo project pages). I haven't touch them yet, but i > would like to

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

On 08/24/2016 12:22 PM, Zac Medico wrote: > > Seems like something we could automate in pkg_posinst of the openrc > ebuild, but probably also deserves a news item. > Or in the systemd ebuild =P I'll drop this, I've made my peace: * adding another configuration file is inconsistent with

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

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 reconfigure when > migrating to/from openrc. > I

Re: [gentoo-dev] base-system needs developers who care

On 08/24/2016 11:32 AM, Mike Gilbert wrote: > On Wed, Aug 24, 2016 at 10:05 AM, Lars Wendler > wrote: >> Please keep in mind to *not* use EAPI-6 for base-system packages yet, so >> we can retain a somewhat stable upgrade path even for very old systems. > > What's the

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

On 08/24/2016 07:37 AM, Daniel Campbell wrote: > > I imagine _someone_ out there wants it, otherwise we wouldn't be > discussing it. The thread started out proposing it as a solution to a docker problem that, it turns out, isn't a problem. Why are we still trying to fixing something that isn't

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

On 08/24/2016 03:12 AM, Daniel Campbell wrote: >> > That seems like a fair compromise. Those who want /etc/hostname get to > use it, those who don't won't need to change anything. > Does anyone want it? This feels like a legacy backwards compatibility hack that we're adding after it's obsolete,

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

My mental model is wrong so I'm probably about to say something stupid. I'm not familiar with the way docker works so bear with me... On 08/23/2016 03:01 AM, Christian Kniep wrote: > > ### > $ docker service create --name nginx --mode=global -e > SERVICE_HOSTNAME=$(hostname -f) nginx > ###

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

On 08/22/2016 06:09 PM, William Hubbs wrote: > > Someone here at the office was wanting a cross-platform way to find out > the hostname of the host the container is running on inside the > container. We made another suggestion for that, so forget about the > docker angle on this for now. > >

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

On 08/22/2016 11:58 AM, William Hubbs wrote: > All, > > it looks like app-emulation/docker expects /etc/hostname to exist. > Isn't there some kind of portable operating system standard that says how to do these things?

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] 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] 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] [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] 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] 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 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] 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] 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] 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] [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] [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] [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] 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: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] 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: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 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] [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 >> +

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 >

[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

[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

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

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

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

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

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

<    2   3   4   5   6   7   8   9   10   >