| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
|
| |
Built into Java since 1.5. Ancient and doesn't build with
Java 8. Removal in 30 days. See bug #544038.
|
|
|
|
|
|
|
| |
This drops stable ppc64 support but nothing needs that and we need to
get rid of concurrent-util ASAP.
Package-Manager: portage-2.2.27
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
|
| |
Old, unused, broken on Java 7 and up. These are still alive upstream
but bumping is likely non-trivial. Removal in 30 days.
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
|
|
|
|
|
|
|
|
| |
This version bump was mostly straightforward, but the ebuild was
ported to EAPI=6 and its dependencies were cleaned up as well. A
simpler pattern was used to replace the existing "sed" invocation.
The LICENSE was also updated per the homepage.
Gentoo-Bug: 573242
Reported-By: Hanno Böck
Package-Manager: portage-2.2.26
|
|
|
|
|
|
|
|
|
|
|
| |
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 named explicitly in the case
statement. The default "*" case now dies with a warning that the EAPI
is unsupported.
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
|
|
| |
Gentoo-Bugs: 573046
Package-Manager: portage-2.2.27
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
|
| |
Gentoo-Bug: 572814
Package-Manager: portage-2.2.27
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
|
|
| |
Bug: 573646
Thanks: polynomial-c
Package-Manager: portage-2.2.26
|
|
|
|
| |
Package-Manager: portage-2.2.26
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --include-arches="arm"
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We've long been exporting the LS_COLORS variable to the default env,
but in practice, there's no reason to be doing this in the majority
of cases. The value we most often load is equivalent to the default
which means we're polluting the env and adding overhead for no gain.
Add a little more code (and one extra `dircolors` exec unfortunately)
to check to see if the LS_COLORS value we found is the default. If
so, don't bother exporting it anymore.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Starting with coreutils-8.24, the dircolors TERM entries are run through
fnmatch rather than being a plain text string. This means our parsing
logic no longer works because we assumed fixed strings. It isn't easy to
process a list of path globs in bash, so rework the code to always run
the dircolors tool. We were doing this anyways in the majority of cases,
so it's not like we're adding that much overhead. The only people who
are negatively impacted are interactive colorless terminals.
Reported-by: Bernd Feige <Bernd.Feige@gmx.net>
|
|
|
|
|
|
|
|
| |
The output of dircolors generally shouldn't be problematic even when it's
unquoted (as it tends to be a long dense string w/out whitespace), but add
quotes anyways just to be safe.
Reported-by: konsolebox@gmail.com
|
|
|
|
|
| |
A bunch of terms end in values like "-256color" and "-color" to indicate
the variant that supports color. Match all of those in the fallback case.
|
|
|
|
|
|
| |
We provide rudimentary TERM checking for BSD which doesn't have dircolors,
but this logic works just as well for all systems such as embedded. Make
this code run whenever dircolors does not exist.
|
|
|
|
|
| |
We've got two cases that check TERM with many common entries,
so make the leading parts look the same.
|
| |
|
| |
|
|
|
|
|
| |
Package-Manager: portage-2.2.27
RepoMan-Options: --force
|
| |
|
|
|
|
| |
Package-Manager: portage-2.2.27
|
|
|
|
| |
Package-Manager: portage-2.2.26
|
|
|
|
| |
Package-Manager: portage-2.2.26
|
|
|
|
| |
Package-Manager: portage-2.2.26
|