On Wed, Jul 6, 2022 at 10:54 AM Martin Jansa <martin.ja...@gmail.com> wrote:
>
> FWIW: I have noticed yesterday that some of our builds were able to fetch
> external dependencies in do_configure again and found that it was caused by
> this commit.
>
> I understand why this was needed to make icecc.bbclass working again.
>
> Our (LGE) use-case is a bit special, because we inherit icecc by default
> (through INHERIT_DISTRO) even when most builders might have it disabled with
> ICECC_DISABLED - it's set this way, so that jenkins builders with icecc
> enabled produce sstate-cache which can be re-used in local build machines
> where icecc might be disabled.
>
> So to support this I've changed icecc.bbclass to respect ICECC_DISABLED when
> setting network varFlag:
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/kirkstone&id=5bbb735c3285a16bf2ec9548a58b887f93f4900e
>
> but that requires expand to be True in bitbake-worker as in:
> https://git.openembedded.org/bitbake-contrib/commit/?h=jansa/2.0&id=4a6c8e61a545152776c0c76304c4225f79de94d2
>
> But that has parsing performance penalty as discussed with RP on #yocto, here
> is relevant part:
>
> 16:03 < JaMa> RP: do you remember if there was specific reason for using
> expand=False for network varFlag in
> https://git.openembedded.org/bitbake/commit/?id=0746b6a2a32fec4c18bf1a52b1454ca4c04bf543
> ? I wanted to change
>
> https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=25ea276a13a6ac2342c2b0945c8fafe878d56095
> to enable network only when ICECC_DISABLED isn't set
> 16:24 < RP> JaMa: it was efficiency
> 16:24 < RP> JaMa: saved any expansion call
> 16:24 < RP> and any processing to determine if the value was true or false
> 16:26 < JaMa> RP: and would it be acceptable to enable to support
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/kirkstone&id=5bbb735c3285a16bf2ec9548a58b887f93f4900e
> ?
> 16:28 < JaMa> I guess I can delVarFlag when ICECC_DISABLED is set, but then
> it would delete it even where it was explicitly enabled in the recipe
> 16:32 < RP> JaMa: well, I'd prefer not to as all these things mount up to
> increase parsing time but I'm starting to feel like I should just not care.
> I'm tired of saying no
> 16:33 < RP> JaMa: you could just equally set or delete those in anon python I
> guess. I really just don't know what to do for the best any more
> 16:34 < JaMa> RP: yes delVarFlag in anon python was my backup plan if the
> price for expand is too high, thanks
> 16:35 < RP> JaMa: it is sad in that "0" won't work in there are a value today
> either but I really don't know what price people want to pay on parsing speed
> vs usability and consistency
> 16:37 < JaMa> understood, thanks
> 16:39 < RP> JaMa: memories are paging back in, I think I did this to see
> whether anyone complained which they now have. It isn't unreasonable to
> properly check it :/
> 16:40 < RP> it is a bit like the cleandirs change for externalsrc. It will
> slow things down a lot :/
>
> Does anyone have some strong opinion either way or some other idea how to
> support this without parsing time penalty?
The only thing I can think of is maybe anonymous python? If that
works, it would at least limit the performance penalty to the case
where icecc.bbclass is inherited.
>
> Regards,
>
> On Mon, Feb 28, 2022 at 5:10 PM Jose Quaresma <quaresma.j...@gmail.com> wrote:
>>
>> This patch can't be the right fix but currently the icecc.bbclass doesn't
>> work on master.
>>
>> Jose
>>
>> Jose Quaresma via lists.openembedded.org
>> <quaresma.jose=gmail....@lists.openembedded.org> escreveu no dia quarta,
>> 16/02/2022 à(s) 23:27:
>>>
>>> The icecc.bbclass needs network access to work properly.
>>>
>>> Currently I build with icecc inside a container with network isolation and
>>> my icecc daemon runs outside of the build container in my host.
>>> The only thing I need to do for using the icecc inside my build container is
>>> mounting the unix socket /var/run/icecc/iceccd.socket inside the container.
>>>
>>> I think we need something like this mount functionality to have access to
>>> some sockets connections inside the tasks that runs on the new namespace
>>> created with unshare system call.
>>>
>>> This patch is not a the real solution for the problem and is more like
>>> an hack so we can use the icecc.bbclass again.
>>>
>>> Signed-off-by: Jose Quaresma <quaresma.j...@gmail.com>
>>> ---
>>> meta/classes/icecc.bbclass | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
>>> index 3bbd2645af..68415b04c7 100644
>>> --- a/meta/classes/icecc.bbclass
>>> +++ b/meta/classes/icecc.bbclass
>>> @@ -428,18 +428,22 @@ set_icecc_env() {
>>> bbnote "Using icecc tarball: $ICECC_VERSION"
>>> }
>>>
>>> +do_configure[network] = "1"
>>> do_configure:prepend() {
>>> set_icecc_env
>>> }
>>>
>>> +do_compile[network] = "1"
>>> do_compile:prepend() {
>>> set_icecc_env
>>> }
>>>
>>> +do_compile_kernelmodules[network] = "1"
>>> do_compile_kernelmodules:prepend() {
>>> set_icecc_env
>>> }
>>>
>>> +do_install[network] = "1"
>>> do_install:prepend() {
>>> set_icecc_env
>>> }
>>> --
>>> 2.35.1
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> José Quaresma
>>
>>
>>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#167732):
https://lists.openembedded.org/g/openembedded-core/message/167732
Mute This Topic: https://lists.openembedded.org/mt/89198407/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
