Am 27.12.21 um 15:54 schrieb Eero Aaltonen:
On Mon, 2021-12-27 at 14:38 +0100, Stefan Herbrechtsmeier via
lists.openembedded.org wrote:
Hi Alex,
Am 25.12.21 um 20:41 schrieb Alexander Kanavin:
On Sat, 25 Dec 2021 at 20:32, Stefan Herbrechtsmeier
mailto:ste...@herbrechtsmeier.net>>
wrote:
On Mon, 2021-12-27 at 14:38 +0100, Stefan Herbrechtsmeier via
lists.openembedded.org wrote:
> Hi Alex,
>
> Am 25.12.21 um 20:41 schrieb Alexander Kanavin:
> > On Sat, 25 Dec 2021 at 20:32, Stefan Herbrechtsmeier
> > mailto:ste...@herbrechtsmeier.net>>
> > wrote:
> >
> > > I'm not sure how
On Mon, 27 Dec 2021 at 14:38, Stefan Herbrechtsmeier <
ste...@herbrechtsmeier.net> wrote:
> > I tend to think that the best (and the hardest) option is to improve
> > these tools so that they're usable inside do_fetch (e.g. fulfil the
> > caching/reproducibility criteria for a bitbake fetcher),
Hi Alex,
Am 25.12.21 um 20:41 schrieb Alexander Kanavin:
On Sat, 25 Dec 2021 at 20:32, Stefan Herbrechtsmeier
mailto:ste...@herbrechtsmeier.net>> wrote:
> I'm not sure how to deal with that, so there aren't that many
options here.
This is a common problem for all language
On 27.12.21 13:54, Stefan Herbrechtsmeier wrote:
Hi Konrad,
Am 25.12.21 um 21:43 schrieb Konrad Weihmann:
What I so far don't really get is why increase in parsing time is such
a big deal.
I admit when we're talking about npm it's some kind of a drastic
increase in recipes one would have to
Am 25.12.21 um 21:58 schrieb Konrad Weihmann:
On 25.12.21 20:32, Stefan Herbrechtsmeier wrote:
Isn't the circular dependencies problem mainly a problem of the native
packages? In many cases the dependency only exists at compile time of
the main project and not at compile time of the
Hi Konrad,
Am 25.12.21 um 21:43 schrieb Konrad Weihmann:
What I so far don't really get is why increase in parsing time is such a
big deal.
I admit when we're talking about npm it's some kind of a drastic
increase in recipes one would have to maintain, just because some random
project decides
One more thing that came to my mind is that the project is missing demo
recipes/real life examples in core that actually would show that one can
achieve reproducibility in the sense of the project's definition for
both npm and go.
So far there is the fetcher code but real life users are living
On 25.12.21 20:32, Stefan Herbrechtsmeier wrote:
Isn't the circular dependencies problem mainly a problem of the native
packages? In many cases the dependency only exists at compile time of
the main project and not at compile time of the dependency itself. In
case of a native package all
What I so far don't really get is why increase in parsing time is such a
big deal.
I admit when we're talking about npm it's some kind of a drastic
increase in recipes one would have to maintain, just because some random
project decides to use a trillion dependencies instead of writing two or
On Sat, 25 Dec 2021 at 20:32, Stefan Herbrechtsmeier <
ste...@herbrechtsmeier.net> wrote:
> > I'm not sure how to deal with that, so there aren't that many options
> here.
>
> This is a common problem for all language specific package managers
> (python / pip, Node.js / npm, Rust / Carge, go) and
On Fri, Dec 24, 2021 at 2:36 AM Konrad Weihmann wrote:
>
> I had a look at the failures and most of them are fairly easy to fix -
> all but the go recipes like influxdb.
>
> I'm not sure how to deal with that, so there aren't that many options here.
>
> Either
> - inject all the needed with a
Hi Konrad,
Am 24.12.21 um 11:36 schrieb Konrad Weihmann:
I had a look at the failures and most of them are fairly easy to fix -
all but the go recipes like influxdb.
The go class doesn't work without network by default if the project
doesn't provide a vendor folder.
I'm not sure how to
Hi Richard,
Am 24.12.21 um 09:30 schrieb Richard Purdie:
On Thu, 2021-12-23 at 22:00 -0800, Khem Raj wrote:
is this list of failures due to this patch ?
https://errors.yoctoproject.org/Errors/Build/137579/
Looks likely, yes. Recipes shouldn't be attempting downloads in do_compile :(
In
I had a look at the failures and most of them are fairly easy to fix -
all but the go recipes like influxdb.
I'm not sure how to deal with that, so there aren't that many options here.
Either
- inject all the needed with a fixed revision, but that would prevent
devtool from catching updates
On Thu, 2021-12-23 at 22:00 -0800, Khem Raj wrote:
> is this list of failures due to this patch ?
> https://errors.yoctoproject.org/Errors/Build/137579/
Looks likely, yes. Recipes shouldn't be attempting downloads in do_compile :(
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all
is this list of failures due to this patch ?
https://errors.yoctoproject.org/Errors/Build/137579/
On Wed, Dec 22, 2021 at 3:20 PM Richard Purdie
wrote:
>
> Use the newly added nonetwork task flag to disable network access where
> possible in unpack/patch/configure/compile/install tasks.
>
> We
On Thu, 23 Dec 2021 at 14:11, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> > This is actually a brilliant idea, which would also make it easier to
> > control this behavior from a user's perspective
>
> Part of me wonders if we really do want to make this "easy" for the user :/
>
1
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH] base/patch: Disable network for
> unpack/patch/configure/compile/install
> >
> > Use the newly added nonetwork task flag to disable network access where
> > possible in unpack/patch/configur
-core@lists.openembedded.org
On Behalf Of Richard Purdie
Sent: den 23 december 2021 00:21
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] base/patch: Disable network for
unpack/patch/configure/compile/install
Use the newly added nonetwork task flag to disable network access
riginal Message-
> >>>> From: openembedded-core@lists.openembedded.org
> >>>> On Behalf Of Richard Purdie
> >>>> Sent: den 23 december 2021 00:21
> >>>> To: openembedded-core@lists.openembedded.org
> >>>> Subject: [OE-core] [PAT
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] base/patch: Disable network for
unpack/patch/configure/compile/install
Use the newly added nonetwork task flag to disable network access where
possible in unpack/patch/configure/compile/install tasks.
We can't disable networking
On Thu, 2021-12-23 at 08:28 +0300, Alexander Kanavin wrote:
> Should there be tests for this? Would be good to check that the network is
> indeed disabled in these tasks.
I think Ross was looking at that. The challenge will be the list needed to know
which distros this works on and which it does
ber 2021 00:21
> > > To: openembedded-core@lists.openembedded.org
> > > Subject: [OE-core] [PATCH] base/patch: Disable network for
> > > unpack/patch/configure/compile/install
> > >
> > > Use the newly added nonetwork task flag to disable network acces
On 23.12.21 11:49, Peter Kjellerstedt wrote:
-Original Message-
From: openembedded-core@lists.openembedded.org
On Behalf Of Richard Purdie
Sent: den 23 december 2021 00:21
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH] base/patch: Disable network for
unpack
> -Original Message-
> From: openembedded-core@lists.openembedded.org
> On Behalf Of Richard Purdie
> Sent: den 23 december 2021 00:21
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] base/patch: Disable network for
> unpack/patch/conf
Should there be tests for this? Would be good to check that the network is
indeed disabled in these tasks.
Alex
On Thu 23. Dec 2021 at 2.20, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> Use the newly added nonetwork task flag to disable network access where
> possible in
Use the newly added nonetwork task flag to disable network access where
possible in unpack/patch/configure/compile/install tasks.
We can't disable networking in sstate tasks due to sstate downloads and
also so we can report hash equivalence to the server.
Signed-off-by: Richard Purdie
---
28 matches
Mail list logo
