On Fri, Dec 20, 2019 at 8:41 AM Gerion Entrup wrote:
>
> Am Donnerstag, 19. Dezember 2019, 19:43:37 CET schrieb Sebastian Pipping:
> > 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
Am Donnerstag, 19. Dezember 2019, 19:43:37 CET schrieb Sebastian Pipping:
> 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?
Is it possible t
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 al
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 does
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 bu
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 t
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 with
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 oper
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&utf8=%E2%9C%93&state=closed&search=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 thin
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 GN
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 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 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
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
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
painle
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 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
20 matches
Mail list logo
