Hi,
Many of you reported that various infra-owned services were not functioning
properly these past two days. We had some package upgrades roll out that
were bad, and a subset of services were non-functional while we worked
through the incident.
(a) The upgrades did not appear to cause any data l
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 vi
Signed-off-by: Matt Smith
---
Hi,
A very tiny patch, not sure if it warrants any discussion. Can submit
as a GitHub pull request if required.
Thanks,
Matthew.
eclass/optfeature.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/optfeature.eclass b/eclass/opt
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 virtu
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 compiler
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
> > we
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
> > ar
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 t
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 tree.
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 added
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, so
> On Mon, 28 Jun 2021, Michał Górny wrote:
> That said, it might be more consistent to change Portage behavior to use
> some visible distinction between output types (not just color), e.g.
> have it output:
> * [QA] ...
> * [WA] ...
> * [ER] ...
+1
Not sure if it's any standard that shou
Check for the mistake of calling distutils-r1_python_*_all() from
non-all python_*() subphase.
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass | 16
1 file changed, 16 insertions(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index a26130f7a1
On lunedì 28 giugno 2021 11:28:23 CEST Michał Górny wrote:
> That said, it might be more consistent to change Portage behavior to use
> some visible distinction between output types (not just color), e.g.
> have it output:
>
> * [QA] ...
> * [WA] ...
> * [ER] ...
+1
Agostino
On Mon, 2021-06-28 at 09:46 +0200, Agostino Sarubbo wrote:
> Hello,
>
> atm we have qa checks in:
> - ${PORTDIR}/metadata/install-qa-check.d
> - /usr/lib/portage/pythonX.Y/install-qa-check.d (installed via portage)
>
> Many of them do not begin as "Qa Notice" so it is very hard track them
> with
Hello,
atm we have qa checks in:
- ${PORTDIR}/metadata/install-qa-check.d
- /usr/lib/portage/pythonX.Y/install-qa-check.d (installed via portage)
Many of them do not begin as "Qa Notice" so it is very hard track them without
naked eye especially via tinderbox.
There is a bug where I reported pa
19 matches
Mail list logo
