On Mon, Jun 28, 2021 at 11:58 AM Agostino Sarubbo wrote:
>
> On lunedì 28 giugno 2021 17:07:57 CEST Michael Orlitzky wrote:
> > If the package declares a dependency on e.g. virtual/c-compiler, ago
> > would want to re-test it whenever a new version of any compiler is
> > released that satisfies
On lunedì 28 giugno 2021 17:07:57 CEST Michael Orlitzky wrote:
> If the package declares a dependency on e.g. virtual/c-compiler, ago
> would want to re-test it whenever a new version of any compiler is
> released that satisfies virtual/c-compiler. Conversely, if the package
> doesn't require
Am Montag, 28. Juni 2021, 15:03:59 CEST schrieb Michał Górny:
> On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
> > Hello all,
> >
> > long story short:
> >
> > when there is a major change (new gcc, new libc, and so on), tinderbox
> > takes a lot of time to test the entire tree.
> >
On Mon, 2021-06-28 at 16:52 +0200, Michał Górny wrote:
> >
> > This is long overdue, for many reasons, but in particular it would
> > force us to declare a dependency on a C compiler if one is needed and
> > allow you to re-test only those packages that use a C compiler.
> >
>
> Which C
On Mon, 2021-06-28 at 16:31 +0200, Gerion Entrup wrote:
>
> This should only build, if _all_ build dependencies are present
> (including every compiler and base system tool). Of course, it needs a
> bigger rework of the portage build process.
We had a GSoC project that aimed to do something like
On Mon, 2021-06-28 at 09:46 -0400, Michael Orlitzky wrote:
> On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
> >
> > Instead, imagine that each ebuild declares a variable called SOURCETYPE (
> > or
> > similar, or in metadata.xml if you prefer ) and with a tool like equery/eix
> >
Am Montag, 28. Juni 2021, 16:13:41 CEST schrieb Rich Freeman:
> On Mon, Jun 28, 2021 at 9:46 AM Michael Orlitzky wrote:
> >
> > On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
> > >
> > > Instead, imagine that each ebuild declares a variable called SOURCETYPE (
> > > or
> > > similar,
On Mon, Jun 28, 2021 at 9:46 AM Michael Orlitzky wrote:
>
> On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
> >
> > Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or
> > similar, or in metadata.xml if you prefer ) and with a tool like equery/eix
> > we
> >
On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
>
> Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or
> similar, or in metadata.xml if you prefer ) and with a tool like equery/eix
> we
> are able to get the list of all packages that compiles C code.
>
I
Hi
28.06.2021 14:00, Agostino Sarubbo пишет:
> Hello all,
>
> long story short:
>
> when there is a major change (new gcc, new libc, and so on), tinderbox takes
> a
> lot of time to test the entire tree.
>
> Let's do a practical example:
> A new version of sys-devel/gcc is added to the
On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
> Hello all,
>
> long story short:
>
> when there is a major change (new gcc, new libc, and so on), tinderbox takes
> a
> lot of time to test the entire tree.
>
> Let's do a practical example:
> A new version of sys-devel/gcc is
Hello all,
long story short:
when there is a major change (new gcc, new libc, and so on), tinderbox takes a
lot of time to test the entire tree.
Let's do a practical example:
A new version of sys-devel/gcc is added to the tree.
There is no way to know how much packages compiles C/C++ code,
12 matches
Mail list logo
