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?
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
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
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
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 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
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
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
19 matches
Mail list logo
