Hi,
As someone with a Radeon / Intel hybrid/dual graphics chip.
I can only emphasise what Matt says below. It's a PITA currently.
Having said that ... I don't see how this can be made simpler, unless we
have a tool of sorts that when run on *any* hardware gives you what this
needs to be set to,
The package split between app-editors/emacs for regular ebuilds and
app-editors/emacs-vcs for live ebuilds has outlived its usefulness, and
it entails additional maintenance effort to keep the two packages (e.g.,
the list of their use flags in metadata.xml) synchronised.
Therefore, consolidate all
To this end, replace the simple numeric comparison of the first
component by a call to ver_test.
Signed-off-by: Ulrich Müller
---
eclass/elisp-common.eclass | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
After the package split between emacs and emacs-vcs is gone, packages
can depend on app-editors/emacs directly.
Signed-off-by: Ulrich Müller
---
eclass/elisp-common.eclass | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/eclass/elisp-common.eclass b/ecl
This replaces the indirect dependency on virtual/emacs.
Signed-off-by: Ulrich Müller
---
eclass/elisp.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/elisp.eclass b/eclass/elisp.eclass
index df160ea01e2..8f907bbb5d6 100644
--- a/eclass/elisp.eclass
+++ b/ecl
Dnia December 18, 2019 11:08:16 AM UTC, "Ulrich Müller"
napisał(a):
>The package split between app-editors/emacs for regular ebuilds and
>app-editors/emacs-vcs for live ebuilds has outlived its usefulness, and
>it entails additional maintenance effort to keep the two packages
>(e.g.,
>the list of
> On Wed, 18 Dec 2019, Michał Górny wrote:
>> - Package mask app-editors/emacs-vcs (but not the virtual) for removal.
> Maybe package.deprecated the virtual?
Good idea. I have to get used to this. :-)
signature.asc
Description: PGP signature
On 12/18/19 6:08 AM, Ulrich Müller wrote:
> No revbumps will be done for this (and virtual/emacs will be simply
> removed without prior masking).
I guess it's nice that we know ahead of time, but is there any reason to
suspect that this won't cause havoc?
On Sat, Dec 14, 2019 at 08:16:03AM +0100, Ulrich Mueller wrote:
> Some ebuilds output SGR control sequences (formerly known as ANSI escape
> sequences) to the terminal, i.e., they do things like:
>
> echo -e "\033[1m${@}\033[0m"
> einfo "Fetching \e[1m${r}\e[22m ..."
> ewarn "\033[1;33m*
> On Wed, 18 Dec 2019, Michael Orlitzky wrote:
>> No revbumps will be done for this (and virtual/emacs will be simply
>> removed without prior masking).
> I guess it's nice that we know ahead of time, but is there any reason
> to suspect that this won't cause havoc?
Removal of the virtual/em
# Ulrich Müller (2019-12-18)
# Live ebuilds for Emacs from Git have been consolidated
# into separate slots of the app-editors/emacs package.
# Please update your package.keywords file accordingly.
# Masked for removal in 30 days. Bug #291296.
app-editors/emacs-vcs
signature.asc
Description: PGP
> On Wed, 18 Dec 2019, Ulrich Mueller wrote:
> # Ulrich Müller (2019-12-18)
> # Live ebuilds for Emacs from Git have been consolidated
> # into separate slots of the app-editors/emacs package.
> # Please update your package.keywords file accordingly.
Sorry, this should have read "package.acc
Hi all,
I noticed that dev-util/cmake depends on dev-libs/expat and that
libexpat upstream (where I'm involved) is in the process of
dropping GNU Autotools altogether in favor of CMake in the near future,
potentially the next release (without any known target release date).
CMake bundles a (prev
On Wed, 2019-12-18 at 22:02 +0100, Sebastian Pipping wrote:
> Hi all,
>
>
> I noticed that dev-util/cmake depends on dev-libs/expat and that
> libexpat upstream (where I'm involved) is in the process of
> dropping GNU Autotools altogether in favor of CMake in the near future,
> potentially the ne
Hi,
On 18/12/2019 22.08, Michał Górny wrote:
> I know that's an unhappy idea but maybe it's time to include CMake
> in stage3. Then it would be just a matter of temporarily enabling
> bundled libs for stage builds, I guess.
Not sure what's unhappy about it, but I like the idea, it will be
painle
On Wed, 2019-12-18 at 22:10 +0100, Piotr Karbowski wrote:
> Hi,
>
> On 18/12/2019 22.08, Michał Górny wrote:
> > I know that's an unhappy idea but maybe it's time to include CMake
> > in stage3. Then it would be just a matter of temporarily enabling
> > bundled libs for stage builds, I guess.
>
Il giorno mer 18 dic 2019 alle ore 22:03 Sebastian Pipping
ha scritto:
>
> CMake bundles a (previously outdated and vulnerable) copy of expat so
> I'm not sure if re-activating that bundle — say with a new use flag
> "system-expat" — would be a good thing to resort to for breaking the
> cycle, wi
I would like to reserve UID/GID 139 for shellinabox
(www-misc/shellinabox)
Debian, Fedora, and Red Hat do not have UID/GIDs reserved for
shellinabox. FreeBSD [1] uses 139 so that's what I'm requesting.
Gentoo API [2] shows these numbers are currently unused.
Here's a PR for this change:
http
Hi,
Due to slis retiring, the following packages are now in need of a new
maintainer:
[ v] app-arch/wimlib
[ v] dev-embedded/lpc21isp
[b?] dev-libs/libflatarray
[ ] dev-libs/libpfm
[bv] dev-libs/papi
[ v] dev-python/aldryn-
boilerplates
[ v] dev-python/aldryn-common
[ v] dev-python/click-plugins
On 18/12/19 22:33, Michał Górny wrote:
> Hi,
>
> Due to slis retiring, the following packages are now in need of a new
> maintainer:
>
> [ v] app-arch/wimlib
> [ v] dev-embedded/lpc21isp
> [b?] dev-libs/libflatarray
> [ ] dev-libs/libpfm
> [bv] dev-libs/papi
> [ v] dev-python/aldryn-
> boilerplate
On 12/18/19 11:34 AM, Ulrich Mueller wrote:
>
> Removal of the virtual/emacs ebuilds won't remove the installed package
> from users' systems. It will eventually disappear, when all its reverse
> dependencies have been updated. Why would its continued presence as an
> installed package (for anothe
On Wed, 18 Dec 2019 22:02:47 +0100
Sebastian Pipping wrote:
> Hi all,
>
>
> I noticed that dev-util/cmake depends on dev-libs/expat and that
> libexpat upstream (where I'm involved) is in the process of
> dropping GNU Autotools altogether in favor of CMake in the near future,
> potentially the
On 12/18/19 4:02 PM, Sebastian Pipping wrote:
> Hi all,
>
>
> I noticed that dev-util/cmake depends on dev-libs/expat and that
> libexpat upstream (where I'm involved) is in the process of
> dropping GNU Autotools altogether in favor of CMake in the near future,
> potentially the next release (wi
On Wed, 18 Dec 2019 23:58:22 +
Sergei Trofimovich wrote:
> [c] would be nice to be solved at portage level if portage could schedule
> multiple merges for the same package with different USE flags.
Related bugs:
- Portage should be able to auto-flip USE="test" & FEATURES="test"
https://b
On Wed, 18 Dec 2019 22:35:40 +
Michael 'veremitz' Everitt wrote:
> There is some very strange wrapping/formatting in this message, was that
> intentional?
If I had to guess, I'd say the word-wrap length was accidentally set to
"8" instead of "80".
pgpHbspqNJkzy.pgp
Description: OpenPGP di
Hello,
I'll be removing myself from (proxy-)maintainer of www-plugins/passff
and www-plugins/passff-host as firefox as been more and more of a pain
to deal with.
For example today I ended up discovering that firefox-68.3.0 bundles
Python 2.7.9 at ${S}/obj-x86_64-pc-linux-gnu/_virtualenvs/init/b
26 matches
Mail list logo
