On 03/07/2018 11:06 AM, anote...@teknik.io wrote:
> Why should portage download some outdated second copy of the
> sources for 'bar', rebuild it, and scatter it around the file system
> where it cannot be used by other programs installed by cabal?
These other package managers don't solve any hard
On 03/07/2018 12:52 PM, Alec Warner wrote:
>
> I'm really not happy with the tone of this email, so I'm going to
> comment on it a bit.
>
Ok, it would have benefited from a do-I-sound-like-a-dick proofread. I
don't want to sound discouraging because this is an area with lots of
room for improve
On 03/08/2018 12:54 AM, Benda Xu wrote:
>
> This title itself is amusing enough
>
> Motherfuckers need package management
>
Which if it is not clear, is intended to be funny.
On 03/08/2018 10:40 AM, Michał Górny wrote:
>
> So, developers, please *stop adding USE=static-libs* to random libraries
> that have no reason whatever to be statically linked to. And by that I
> mean a good reason, not creeping featurism, not 'user asked for it', not
> 'this broken package hardco
On 03/12/2018 04:29 AM, Martin Vaeth wrote:
> Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> If I'm recalling correctly a warning posted on this list, repeated calls
>> to the github tarballing API for the same commit will result in delivery
>> of tarballs with differing checksums.
>
> This was so man
On 03/20/2018 07:50 AM, Herb Miller Jr. wrote:
> When I did my homework on creating nodejs ebuilds (not nodejs itself but
> packages written in node), it seems the topic has come up a few times in
> the past but the time commitment and general disorganization of upstream
> has scared off any seriou
On 03/20/2018 04:14 PM, Herb Miller Jr. wrote:
> That is scary. I hadn't noticed there are node_modules directories under
> many node modules and that npm list outputs different versions of the
> same dependency. To help me better understand the situation, when you
> see this happen does "bar-1.0"
On 03/28/2018 12:41 AM, Stephen Christie wrote:
>
> These are now the majority of the emails I've now received. The first
> reply was essentially "We've already talked about this, can we just
> move on?".
In our enthusiasm to defeat wltjr, we have let ourselves become wltjr.
On 03/29/2018 11:28 AM, Alec Warner wrote:
>
> Is there any particular reason we need to remove them?
>
The PMS says that empty directories are undefined, so the portage
behavior of installing them and leaving them alone leads to
incompatibilities. Ebuilds rely on the portage behavior, and if an
On 03/29/2018 11:57 AM, Alec Warner wrote:
>
> So we could simply change the PMS to keep the empty directories?
>
> Why is removing them *better* is my question.
I proposed this idea but basically everyone with a say in the process
was against it: https://bugs.gentoo.org/644366
My last comment:
On 03/29/2018 11:57 AM, William Hubbs wrote:
>>
>> The PMS says that empty directories are undefined, so the portage
>> behavior of installing them and leaving them alone leads to
>> incompatibilities. Ebuilds rely on the portage behavior, and if another
>> PM (within its rights) deletes them, then
On 04/07/2018 02:44 PM, William Hubbs wrote:
>
> I'm with floppym on this one. Is there a specific reason we enable them
> globally?
It's a relic from before we had IUSE defaults.
> Since there has been so little discussion on this thread, I will start
> looking at what I need to do to remove t
On 01/24/2016 07:43 PM, Ulrich Mueller wrote:
>>>>>> On Sun, 24 Jan 2016, Gokturk Yuksek wrote:
>
>> From: Michael Orlitzky
>
>> The ChangeLog section under misc-files is misleading now that our main
>> repository has been switched to git (and we no lon
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 appreciat
On 01/27/2016 04:22 AM, Dirkjan Ochtman wrote:
> On Tue, Jan 26, 2016 at 9:52 PM, Michael Orlitzky 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.
>> This used t
On 01/27/2016 09:49 AM, Dirkjan Ochtman wrote:
>
> Can I ask what your interest is?
>
An easy, automated way to make sure that I didn't screw up the file
before I commit it. For personal use, it can hit the network, but I was
also considering a pre-commit hook that would need to look locally (bu
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, a
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 n
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 as
On 02/05/2016 04:34 PM, Kent Fredric wrote:
> On 6 February 2016 at 10:10, Michael Orlitzky 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? Otherwise, lea
On 02/09/2016 02:53 PM, Ian Stakenvicius wrote:
>
> python-exec-cwrapper ?
>
Elmer Fudd goes to the bathroom? =)
python-exec-candy
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 II
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 tre
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 docume
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 l
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.
Wh
On 05/10/2016 02:28 PM, Mike Gilbert wrote:
> On Tue, May 10, 2016 at 11:08 AM, Michael Orlitzky 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"
>> do that?
&g
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 testing
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.
>
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLE
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.
>
Ok,
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 th
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
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 specificati
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 local
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
> +++ b/profiles/desc/p
imply
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
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 foun
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 vari
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
> [[
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
>> +>=sys-devel/libtool-1
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 d
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
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
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 b
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 sti
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 Patrick
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 won't.
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 con
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 t
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 on
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".
On 06/12/2016 09:12 PM, Benda Xu wrote:
> Michael Orlitzky writes:
>>
>> Every rm, cp, mv, mkdir, dodir, cd, etc. needs "|| die".
>
> Thanks, updated.
>
> ...
>
> # Don't forget to make directory for sysfs
> - [[ ! -d
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" "${PHP_EXT_NAME}
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]}" 2>/dev/
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.
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 cal
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 new
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 vary
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
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?
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.
>
> But,
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
> ###
Th
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, t
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 bro
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 time frame for lifting that
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 s
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 every
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 k
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 (n
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:
>
> -
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
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.
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
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
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
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:
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Pull_requests_f
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 just.
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 co
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
sys-libs/d
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 throu
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 separate
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 up
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 ma
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?
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 "stri
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}" ] && KV_DIR="${
On 11/30/2016 11:45 AM, Mike Gilbert wrote:
> On Wed, Nov 30, 2016 at 11:28 AM, Michael Orlitzky wrote:
>> On 11/26/2016 12:47 PM, Mike Gilbert wrote:
>>> The values get clobbered immediately afterward, so why bother?
>>> ...
>>> qeinfo "Determini
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
>
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 on/of
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 expo
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 desira
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...
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 tr
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 req
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
> de
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 addit
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
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.
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 s
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.
201 - 300 of 919 matches
Mail list logo
