All of lore.kernel.org
 help / color / mirror / Atom feed
From: pmi183@gmail.com
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] buildhistory: Fix do_package race issues
Date: Thu, 23 May 2024 08:24:12 -0700	[thread overview]
Message-ID: <30216.1716477852755796076@lists.openembedded.org> (raw)
In-Reply-To: <CANNYZj-d-SSYPv-wZF8kfnSvt7i-cG3ec3wotSNETD6-OttyKQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

Hi Alex,

So problem starts at sstate.bbclass:406 (sstate_install(ss, d)), this should be running after the next for loop (for plain in ss['plaindirs']:).

Having this fixed, jumping to the buildhistory.bbclass:602, find should be out of the loop to give an hard error if it misses.
Then inside the for loop, while checking if output folder exists (buildhistory.bbclass:607), this doesnt make sense to me the way it is running:
- the comment refers "Make sure the output folder exists...", but we are not creating it if we need, just skipping if doesnt exists.
- this folder is being created on do_packagedata (buildhistory.bbclass:396) to write down latest file.

So before spending more time on this topic i have a few questions to understand a little bit of what should be the strategy to fix this:

- If we want to keep files-in-package.txt being created on do_package, shouldnt `buildhistory_list_pkg_files()` (buildhistory.bbclass:600) be responsible to create the folder on buildhistory side?
- If we keep `buildhistory_list_pkg_files` being triggered by do_package is there any case of do_package_setscene trigger this? I couldnt find any case to support this option (buildhistory.bbclass:101).
- If not we dont need in fact to create files-in-package.txt on do_package, should files-in-package.txt creation be moved to do_packagedata?

Thanks,

Pedro

[-- Attachment #2: Type: text/html, Size: 1464 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: pmi183@gmail.com
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] buildhistory: Fix do_package race issues
Date: Thu, 23 May 2024 08:24:48 -0700	[thread overview]
Message-ID: <30216.1716477852755796076@lists.openembedded.org> (raw)
Message-ID: <20240523152448.0FqOIhKPFeJiAsZrNh-DbxB7XnXyXr2eUQK9qKe1YqM@z> (raw)
In-Reply-To: <CANNYZj-d-SSYPv-wZF8kfnSvt7i-cG3ec3wotSNETD6-OttyKQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

Hi Alex,

So problem starts at sstate.bbclass:406 (sstate_install(ss, d)), this should be running after the next for loop (for plain in ss['plaindirs']:).

Having this fixed, jumping to the buildhistory.bbclass:602, find should be out of the loop to give a hard error if it misses.
Then inside the for loop, while checking if output folder exists (buildhistory.bbclass:607), this doesnt make sense to me the way it is running:
- the comment refers "Make sure the output folder exists...", but we are not creating it if we need, just skipping if doesnt exists.
- this folder is being created on do_packagedata (buildhistory.bbclass:396) to write down latest file.

So before spending more time on this topic i have a few questions to understand a little bit of what should be the strategy to fix this:

- If we want to keep files-in-package.txt being created on do_package, shouldnt `buildhistory_list_pkg_files()` (buildhistory.bbclass:600) be responsible to create the folder on buildhistory side?
- If we keep `buildhistory_list_pkg_files` being triggered by do_package is there any case of do_package_setscene trigger this? I couldnt find any case to support this option (buildhistory.bbclass:101).
- If not we dont need in fact to create files-in-package.txt on do_package, should files-in-package.txt creation be moved to do_packagedata?

Thanks,

Pedro

[-- Attachment #2: Type: text/html, Size: 1463 bytes --]

  reply	other threads:[~2024-05-23 15:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-23 13:59 [PATCH] buildhistory: Fix do_package race issues Richard Purdie
2021-11-23 14:19 ` [OE-core] " Alexander Kanavin
2024-05-13  9:47 ` pmi183
2024-05-13  9:51   ` [OE-core] " Alexander Kanavin
2024-05-13 10:05     ` pmi183
2024-05-13 11:01       ` [OE-core] " Alexander Kanavin
2024-05-15  9:36         ` pmi183
2024-05-15 10:07           ` [OE-core] " Alexander Kanavin
2024-05-20  8:10             ` pmi183
2024-05-20 11:12               ` [OE-core] " Jose Quaresma
2024-05-21 10:24               ` Alexander Kanavin
2024-05-23 15:24                 ` pmi183 [this message]
2024-05-23 15:24                   ` pmi183
     [not found]                   ` <Groupsio.1.30216.1716477852755796076@lists.openembedded.org>
2024-05-24  8:13                     ` [OE-core] " Alexander Kanavin
2024-05-29  8:56                       ` pmi183
2024-05-29  9:01                       ` pmi183
2024-05-29 10:22                         ` [OE-core] " Alexander Kanavin
2024-05-29 11:57                           ` pmi183
2024-05-29 12:17                             ` [OE-core] " Alexander Kanavin
2024-05-29 22:35                               ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=30216.1716477852755796076@lists.openembedded.org \
    --to=pmi183@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.