On 12/18/19 6:28 PM, Michael Orlitzky wrote:
>
> This *does* happen if you mask virtual/emacs. It *could* happen if you
> delete it.
>
I tested this out.
Portage seems OK with the missing dependency, but for the overall plan
to work, you have to wait a long time before deleting virtual/emacs;
On 12/19/19 12:37 PM, Michał Górny wrote:
>
> Just because someone did something crappy, it doesn't mean it was
> considered 'good enough'. It was just a cheap hack that someone once
> did just to get it over with and stop caring. Not a good solution we
> should keep copying.
>
These should
Hello,
Here's another potential EAPI 8 feature I'd like to discuss. Please
note that this is about *new dependency type*, so please don't hijack it
into the big 'let's steal Exherbo syntax' debate.
Bug: https://bugs.gentoo.org/660306
The problem
===
Right now we don't really have a
On Thu, 2019-12-19 at 19:43 +0100, Sebastian Pipping wrote:
> On 19.12.19 18:37, Michał Górny wrote:
> > We have a better alternative that lets us limit the impact on the users.
> > Why not use it?
>
> Which one? The CMake bootstrap copy? The adding to stage3 one?
>
Bootstrap version. It
On 19.12.19 18:37, Michał Górny wrote:
> We have a better alternative that lets us limit the impact on the users.
> Why not use it?
Which one? The CMake bootstrap copy? The adding to stage3 one?
On Thu, 2019-12-19 at 18:28 +0100, Sebastian Pipping wrote:
> Hey!
>
>
> On 19.12.19 17:03, Michał Górny wrote:
> > > B) Introduce USE flag "system-expat" to CMake similar to existing
> > >flag "system-jsoncpp", have it off by default, keep reminding
> > >CMake upstream to update their
Hey!
On 19.12.19 17:03, Michał Górny wrote:
>> B) Introduce USE flag "system-expat" to CMake similar to existing
>>flag "system-jsoncpp", have it off by default, keep reminding
>>CMake upstream to update their bundle
>>
>> [..]
>
> It violates the policy on bundled libraries.
Same for
On Thu, 2019-12-19 at 15:39 +0100, Sebastian Pipping wrote:
> Hey!
>
>
> Thanks everyone for your thoughts so far!
>
> From what I heard, these two options seem realistic to me:
>
> A) Ask the KDE team for help with teaming up on a new package
>dev-util/cmake-bootstrap, keep it in sync
Hey!
Thanks everyone for your thoughts so far!
>From what I heard, these two options seem realistic to me:
A) Ask the KDE team for help with teaming up on a new package
dev-util/cmake-bootstrap, keep it in sync with dev-util/cmake,
make sure both packages co-exists with full disjoint
# Brian Evans (2019-12-19)
# PHP 7.1 is end of life and has security issues Bug 703326
# Associated packages are not ready for new versions tracked in bug 702110
# Removal in 30 days
dev-lang/php:7.1
dev-php/pecl-cassandra
signature.asc
Description: OpenPGP digital signature
On 19.12.19 14:32, Rolf Eike Beer wrote:
> These things _are_ updated regularly
To be fair they update because I keep opening update requests:
https://gitlab.kitware.com/cmake/cmake/issues?scope=all=%E2%9C%93=closed=expat+update
Am 2019-12-18 22:44, schrieb Francesco Riosa:
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
On Thu, 2019-12-19 at 14:54 +1300, Kent Fredric wrote:
> 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
On Wed, 2019-12-18 at 23:58 +, Sergei Trofimovich wrote:
> 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
14 matches
Mail list logo
