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
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
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"
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
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 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
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-
>
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]
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:
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,
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.
>
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
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
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
On 18/12/19 17:36, Joakim Tjernlund wrote:
> On Wed, 2019-12-18 at 11:22 -0500, Mike Gilbert wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you recognize the sender and know the
>> content is safe.
>>
>>
>> On Thu, Dec
On Wed, 2019-12-18 at 11:22 -0500, Mike Gilbert wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> On Thu, Dec 12, 2019 at 10:18 AM Joakim Tjernlund
> wrote:
>
> 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
# 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:
> 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
On Thu, Dec 12, 2019 at 10:18 AM Joakim Tjernlund
wrote:
>
> When build in a qemu-user chroot I get odd build paths:
> /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc
>
> This path is missing the abi_ppc_32 like so:
>
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
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 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
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
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
+++
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
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
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
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
29 matches
Mail list logo
