Re: [yocto-infrastructure] [Openembedded-architecture] git.openembedded.org

2023-08-10 Thread Michael Halstead
This server is due to be migrated to the same servers as
git.yoctoproject.org which should resolve these issues.

In the meantime I've cleaned up this machine a bit and rebooted. There were
several open sockets and zombie processes. I expect to continue to use this
machine for a few more weeks. Please email if issues continue so we can
prioritize the move if needed.

On Wed, Aug 9, 2023 at 6:47 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Wed, 2023-08-09 at 08:21 -0500, Ryan Eatmon via
> lists.openembedded.org wrote:
> > We are seeing a lot failures with the git.openembedded.org server while
> > running our regular CICD builds.  Does the server need to be kicked or
> > something?  Also, is the right list to report/discuss issues like this?
>
> yocto-infrastruct...@lists.yoctoproject.org is perhaps the right place,
> and/or helpd...@yoctoproject.org.
>
> I've copied them on my reply.
>
> I know we have seen a couple of glitches on the autobuilder as well
> related to this and there is a server transition plan in progress for
> this service.
>
> Cheers,
>
> Richard
>
> > 08:11:29 Cloning into
> > '/scratch/jenkins_builds/arago-master-next/build/sources/oe-core'...
> > 08:11:48 error: Unable to get pack index
> >
> https://git.openembedded.org/openembedded-core/objects/pack/pack-c60b12d26c1fad6b8805af480670be31735e7f8f.idx
> > 08:11:48 error: Unable to get pack index
> >
> https://git.openembedded.org/openembedded-core/objects/pack/pack-fd33b8f607375a7c61da83b0cf00318d21726dae.idx
> > 08:11:49 error: Unable to get pack index
> >
> https://git.openembedded.org/openembedded-core/objects/pack/pack-95788bc2bc228ac1b0d1d505522830a98a3bb8e2.idx
> > 08:12:02 error: Unable to get pack index
> >
> https://git.openembedded.org/openembedded-core/objects/pack/pack-00d508e7dcfde948435d430584e129a938f70677.idx
> > 08:14:30 error: Unable to find 3e64884e615e76e97429b0aa38637254dd5a99d5
> > under https://git.openembedded.org/openembedded-core
> > 08:14:30 Cannot obtain needed tree
> 3e64884e615e76e97429b0aa38637254dd5a99d5
> > 08:14:30 while processing commit
> bff17171841fd15fb6084262e397c736005f7e3b.
> > 08:14:30 error: fetch failed.
> > 08:14:31 git failed... remaining attempts: 4sleeping 15 seconds
> > 08:14:46 Cloning into
> > '/scratch/jenkins_builds/arago-master-next/build/sources/oe-core'...
> > 08:15:01 error: Unable to get pack index
> >
> https://git.openembedded.org/openembedded-core/objects/pack/pack-4e27dc9c1f2589302f976de7fd3550aef1f9f4d5.idx
> > 08:18:40 error: Unable to find 7d148142fc7828abbc8c360e6890d841fd5b4b68
> > under https://git.openembedded.org/openembedded-core
> > 08:18:40 Cannot obtain needed blob
> 7d148142fc7828abbc8c360e6890d841fd5b4b68
> > 08:18:40 while processing commit
> f13fe33403f077802640e70a84596546d555c3b9.
> > 08:18:40 error: fetch failed.
> > 08:18:40 git failed... remaining attempts: 3sleeping 30 seconds
> >
> >
> >
> >
> >
>
>
> 
>
>

-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1732): 
https://lists.openembedded.org/g/openembedded-architecture/message/1732
Mute This Topic: https://lists.openembedded.org/mt/100667820/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: 
https://lists.openembedded.org/g/openembedded-architecture/leave/8022071/21656/27543430/xyzzy
 [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [Openembedded-architecture] Workflow improvements - incremental source updates?

2023-08-10 Thread Richard Purdie
On Tue, 2023-08-08 at 10:10 +0100, Richard Purdie via lists.openembedded.org 
wrote:
> There is a recent discussion about AUTOREV which has got me thinking a
> bit about the big picture and incremental development.
> 
> Currently AUTOREV injects into PV. The reasons for that are historical,
> when OE was not taskhash based we had to do that to trigger updates.
> There are now different ways it could be done with the revision just
> needing injection into PKGPV for packaging purposes.
> 
> I've also been looking at externalsrc bugs.
> 
> This got me thinking, if we did make AUTOREV work without messing with
> PV, we could probably go a step further and allow the fetcher to
> incrementally update an existing git checkout rather than remove and
> start again from scratch. Patches may or may not be an issue, we could
> mandate a clean single git:// srcuri to start with although the patch
> code can remove the patch stack already. This would need to hook in to
> disable some of the cleanup/removal code.
> 
> The usecase would be to allow the developer to pull updates from a
> remote repo, or even commit changes locally and then have the system
> "flow" the changes through from there. This would remove the annoying
> clean and re-checkout process which drives some developers crazy. It
> might also allow externalsrc to change to a new model with less
> deviation from the normal workflow.

I tried some experiments and this doesn't actually turn out to be so
difficult to do. I've included a patch below which basically drops the
SRCPV pieces into PKGV, the conditional can probably be simplified
further.

This patch isn't quite right in that we need to split get_srcrev into
two versions, one which returns the SRCREV_FORMAT string and one which
returns the full hashes for taskhash purposes.

The nice thing about this approach is that SRCPV can simply be removed
over time, it no longer does anything. That means compatibility is
retained with existing recipes.

I've not tested this extensively yet with AUTOREV but normal builds
appear to work ok with it and the WORKDIR directory naming
simplification is probably a win.

Cheers,

Richard

From: Richard Purdie 
Subject: fetch: Move SRCPV from PV to PKGV

Signed-off-by: Richard Purdie 
---
 bitbake/lib/bb/fetch2/__init__.py   |  5 -
 meta/classes-global/base.bbclass| 26 +-
 meta/classes-global/package.bbclass |  6 +-
 meta/conf/bitbake.conf  |  5 +
 4 files changed, 11 insertions(+), 31 deletions(-)

diff --git a/bitbake/lib/bb/fetch2/__init__.py 
b/bitbake/lib/bb/fetch2/__init__.py
index ad9d8a31a7e..ea51a009e1d 100644
--- a/bitbake/lib/bb/fetch2/__init__.py
+++ b/bitbake/lib/bb/fetch2/__init__.py
@@ -753,7 +753,7 @@ def get_autorev(d):
 d.setVar("__BBAUTOREV_SEEN", True)
 return "AUTOINC"
 
-def get_srcrev(d, method_name='sortable_revision'):
+def get_srcrev(d, method_name='sortable_revision', allow_none=False):
 """
 Return the revision string, usually for use in the version string (PV) of 
the current package
 Most packages usually only have one SCM so we just pass on the call.
@@ -781,6 +781,9 @@ def get_srcrev(d, method_name='sortable_revision'):
 scms.append(u)
 
 if not scms:
+if allow_none:
+d.delVar("__BBINSRCREV")
+return ""
 raise FetchError("SRCREV was used yet no valid SCM was found in 
SRC_URI")
 
 if len(scms) == 1 and len(urldata[scms[0]].names) == 1:
diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
index cbda8d12f09..2567b7d24be 100644
--- a/meta/classes-global/base.bbclass
+++ b/meta/classes-global/base.bbclass
@@ -130,7 +130,7 @@ addtask fetch
 do_fetch[dirs] = "${DL_DIR}"
 do_fetch[file-checksums] = "${@bb.fetch.get_checksum_file_list(d)}"
 do_fetch[file-checksums] += " ${@get_lic_checksum_file_list(d)}"
-do_fetch[vardeps] += "SRCREV"
+do_fetch[vardepvalue] += "${@bb.fetch.get_srcrev(d, allow_none=True)}"
 do_fetch[network] = "1"
 python base_do_fetch() {
 
@@ -606,7 +606,6 @@ python () {
 bb.debug(1, "Skipping recipe %s because of incompatible 
license(s): %s" % (pn, ' '.join(incompatible_lic)))
 raise bb.parse.SkipRecipe("it has incompatible license(s): 
%s" % ' '.join(incompatible_lic))
 
-needsrcrev = False
 srcuri = d.getVar('SRC_URI')
 for uri_string in srcuri.split():
 uri = bb.fetch.URI(uri_string)
@@ -619,24 +618,17 @@ python () {
 
 # Svn packages should DEPEND on subversion-native
 if uri.scheme == "svn":
-needsrcrev = True
 d.appendVarFlag('do_fetch', 'depends', ' 
subversion-native:do_populate_sysroot')
 
 # Git packages should DEPEND on git-native
 elif uri.scheme in ("git", "gitsm"):
-needsrcrev = True
 d.appendVarFlag('do_fetch', 'depends', ' 
git-native:do_populate_sysroot')
 
 # Mercurial packages should DEPEND on