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
Both sys-devel/binutils and sys-devel/gdb are built with system zlib by
default for some time now. This commit removes the mention of USE=zlib to avoid
confusion.
Signed-off-by: Thymo van Beers
---
man/make.conf.5 | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
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
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
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,
> 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
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
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
>
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
Signed-off-by: Ulrich Müller
---
eclass/l10n.eclass | 1 +
metadata/qa-policy.conf | 1 +
2 files changed, 2 insertions(+)
diff --git a/eclass/l10n.eclass b/eclass/l10n.eclass
index b1dff96ded12..f53cb3d0898b 100644
--- a/eclass/l10n.eclass
+++ b/eclass/l10n.eclass
@@ -8,6 +8,7 @@
# Ben
Ever since the L10N USE_EXPAND variable was introduced, the name of
this eclass was somewhat confusing, because it operates on LINGUAS and
is unrelated to L10N. Take the EAPI 8 bump as an opportunity to rename
the eclass.
Signed-off-by: Ulrich Müller
---
v2: Expanded eclass documentation
> On Mon, 28 Jun 2021, Martin Dummer wrote:
>>> --- a/eclass/vdr-plugin-2.eclass
>>> +++ b/eclass/vdr-plugin-2.eclass
>>> @@ -76,7 +76,7 @@
>>> inherit flag-o-matic toolchain-funcs unpacker
>> This should also inherit strip-linguas.eclass, because strip-linguas is
>> called in
23 matches
Mail list logo
