| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Package-Manager: Portage-2.3.3, Repoman-2.3.1
|
|
|
|
| |
stable #600174
|
|
|
|
|
|
| |
Package-Manager: portage-2.3.0
RepoMan-Options: --include-arches="x86"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
|
| |
Package-Manager: portage-2.3.0
RepoMan-Options: --include-arches="amd64"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
| |
Gentoo-Bug: 600174
|
|
|
|
| |
Package-Manager: portage-2.3.2
|
|
|
|
| |
Package-Manager: portage-2.3.2
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The patch applies against the readline source which we delete in the
bash ebuild, so it doesn't do anything useful here.
|
|
|
|
|
|
| |
Bug: 595142
Package-Manager: portage-2.3.0
|
|
|
|
|
| |
Package-Manager: portage-2.3.1
RepoMan-Options: --include-arches="arm"
|
|
|
|
|
| |
Package-Manager: portage-2.3.2
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.2
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
| |
Gentoo-Bug: 595268
|
|
|
|
|
| |
Package-Manager: portage-2.3.1
RepoMan-Options: --ignore-arches
|
|
|
|
|
|
| |
Package-Manager: portage-2.2.28
RepoMan-Options: --include-arches="x86"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
|
| |
Package-Manager: portage-2.2.28
RepoMan-Options: --include-arches="amd64"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.1
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.1
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.1
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
|
|
| |
Package-Manager: portage-2.2.28
RepoMan-Options: --include-arches="ia64"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
|
| |
Package-Manager: portage-2.2.28
RepoMan-Options: --include-arches="arm"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
|
| |
Package-Manager: portage-2.2.28
RepoMan-Options: --include-arches="ppc"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
|
| |
Package-Manager: portage-2.2.28
RepoMan-Options: --include-arches="sparc"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
|
| |
Package-Manager: portage-2.2.28
RepoMan-Options: --include-arches="x86"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.1
RepoMan-Options: --ignore-arches
|
|
|
|
|
|
| |
Package-Manager: portage-2.2.28
RepoMan-Options: --include-arches="amd64"
Signed-off-by: Agostino Sarubbo <ago@gentoo.org>
|
|
|
|
| |
Gentoo-Bug: 594496
|
|
|
|
|
| |
Package-Manager: portage-2.3.1
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.0
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.0
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.0
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
|
|
|
|
| |
Package-Manager: portage-2.3.0
Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
|
| |
|
|
|
|
|
|
| |
Closes: https://github.com/gentoo/gentoo/pull/1887
Signed-off-by: Patrice Clement <monsieurp@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
The behavior of ls in the default case (when LS_COLORS isn't set) isn't
documented well. The manual leads you to believe the defaults will be
used when in reality they are not. A scan of the source shows this. So
back out some the attempts to optimize the env and go back to exporting
LS_COLORS all the time. We'll just have to live with incompat warnings
when coreutils upgrades & changes behavior.
|
| |
|
| |
|
|
|
|
|
|
| |
Bug: 585764
Package-Manager: portage-2.2.28
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|