|
Re: devtool upgrade for go recipes with git "broken"
Thanks...
toggle quoted message
Show quoted text
-----Original Message----- From: yocto@... <yocto@...> On Behalf Of Alexander Kanavin Sent: Thursday, October 20, 2022 6:40 AM To: Roos, Thomas <throos@...> Cc: yocto@... Subject: Re: [yocto] devtool upgrade for go recipes with git "broken" External Email Alert This email has been sent from an account outside of the BAE Systems network. Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar. It may well be that no one remembers anymore why it's there, and in this case you can just drop it. Or you can dig into git history with 'git blame' and similar techniques. Alex On Thu, 20 Oct 2022 at 12:23, Roos, Thomas <throos@...> wrote:
sure, but may this src folder is necessary for something? Some go convention I don't know about...
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 12:09:47
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Can you propose a patch to core?
Alex
On Thu, 20 Oct 2022 at 12:05, Roos, Thomas <throos@...> wrote:
yes, I already did this - it's because that go.bbclass is spangly using a subdir called "src" and that will break the devtool check for upgrades mechanism because it's not looking into a src subdir. So git will fail checkout anything in the parent dir "reference is not a tree"
This simple change in the go.bbclass fix it - but I don't know if that additional src dir is somehow necessary:
# src folder will break devtool upgrade python go_do_unpack() {
src_uri = (d.getVar('SRC_URI') or "").split()
if len(src_uri) == 0:
return
fetcher = bb.fetch2.Fetch(src_uri, d)
for url in fetcher.urls:
if fetcher.ud[url].type == 'git':
if fetcher.ud[url].parm.get('destsuffix') is None:
s_dirname = os.path.basename(d.getVar('S'))
#cause problems fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, 'src', d.getVar('GO_IMPORT')) + '/'
#FIX
fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, '', d.getVar('GO_IMPORT')) + '/'
#FIX
fetcher.unpack(d.getVar('WORKDIR'))
}
# src folder will break devtool upgrade
go_do_configure() {
#cause problems ln -snf ${S}/src ${B}/
#FIX
ln -snf ${S} ${B}/
#FIX
}
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:56:48
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Thanks, I do not have a quick answer to this, but would appreciate
if you can dig deeper into the issue.
Alex
On Thu, 20 Oct 2022 at 11:50, Roos, Thomas <throos@...> wrote:
yes, easy
- set the go-helloworld bb srcrev to an older rev - e.g:
SRCREV = "ad95e7f791d8e1e7e7ec7f7cedfc2f6b29f6c9e2"
"devtool upgrade go-helloworld"
INFO: Extracting upgraded version source...
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 567, in upgrade
rev2, md5, sha256, srcbranch, srcsubdir2 = _extract_new_source(args.version, srctree, args.no_patch,
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 183, in _extract_new_source
__run('git checkout %s' % rev)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 170, in __run
return _run(cmd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 31, in _run
return bb.process.run('%s' % cmd, cwd=cwd)
File "/home/ubuntu/yocto/poky/bitbake/lib/bb/process.py", line 189, in run
raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
bb.process.ExecutionError: Execution of 'git checkout 2e68773dfca072cb81f219fc3b97ad34fe9d9f94' failed with exit code 128:
fatal: reference is not a tree:
2e68773dfca072cb81f219fc3b97ad34fe9d9f94
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/devtool", line 338, in <module>
ret = main()
File "/home/ubuntu/yocto/poky/scripts/devtool", line 325, in main
ret = args.func(args, config, basepath, workspace)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 575, in upgrade
_upgrade_error(e, recipedir, srctree, args.keep_failure)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 134, in _upgrade_error
_cleanup_on_error(rd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 126, in _cleanup_on_error
if not len(os.listdir(rdp)):
FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/yocto/build/workspace/recipes'
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:32:19
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
It helps if you show the exact error, and a way to reproduce this
using a minimal setup (ideally only poky).
Alex
On Thu, 20 Oct 2022 at 11:18, Thomas Roos via
lists.yoctoproject.org <throos=amazon.de@...> wrote:
Hi,
when doing a "devtool upgrade" for a recipe which inherits "go" and using a SRC_URI to a git repo this will fail. Complaining that the git revision is "out of tree" - I found that the additional "src" folder inside the checkout out sources is causing this problem and I wondering if this is necessary. I'm not a go programmer, but when changing this the recipe seems to produce the same result.
I did change our go recipe to don't use this additional src
folder by overwriting the go_do_upack and go_do_configure
method. Here:
https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a9
1b9703609d7658bd1649350acaf/recipes-support/amazon-ssm-agent/ama
zon-ssm-agent_3.1.1856.0.bb Is this a bug or do anybody know why
go use that additional src folder?
Cheers,
Thomas
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg Sitz der
Gesellschaft: L-1855 Luxemburg eingetragen im Luxemburgischen
Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen Sitz der
Zweigniederlassung: Muenchen eingetragen im Handelsregister des
Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg Sitz der
Gesellschaft: L-1855 Luxemburg eingetragen im Luxemburgischen
Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen Sitz der
Zweigniederlassung: Muenchen eingetragen im Handelsregister des
Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg Sitz der Gesellschaft:
L-1855 Luxemburg eingetragen im Luxemburgischen Handelsregister
unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen Sitz der Zweigniederlassung:
Muenchen eingetragen im Handelsregister des Amtsgerichts Muenchen
unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg Sitz der Gesellschaft:
L-1855 Luxemburg eingetragen im Luxemburgischen Handelsregister unter
R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen Sitz der Zweigniederlassung:
Muenchen eingetragen im Handelsregister des Amtsgerichts Muenchen
unter HRB 242240, USt-ID DE317013094
|
|
|
Re: devtool upgrade for go recipes with git "broken"
It may well be that no one remembers anymore why it's there, and in
this case you can just drop it. Or you can dig into git history with
'git blame' and similar techniques.
Alex
toggle quoted message
Show quoted text
On Thu, 20 Oct 2022 at 12:23, Roos, Thomas <throos@...> wrote:
sure, but may this src folder is necessary for something? Some go convention I don't know about...
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 12:09:47
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Can you propose a patch to core?
Alex
On Thu, 20 Oct 2022 at 12:05, Roos, Thomas <throos@...> wrote:
yes, I already did this - it's because that go.bbclass is spangly using a subdir called "src" and that will break the devtool check for upgrades mechanism because it's not looking into a src subdir. So git will fail checkout anything in the parent dir "reference is not a tree"
This simple change in the go.bbclass fix it - but I don't know if that additional src dir is somehow necessary:
# src folder will break devtool upgrade
python go_do_unpack() {
src_uri = (d.getVar('SRC_URI') or "").split()
if len(src_uri) == 0:
return
fetcher = bb.fetch2.Fetch(src_uri, d)
for url in fetcher.urls:
if fetcher.ud[url].type == 'git':
if fetcher.ud[url].parm.get('destsuffix') is None:
s_dirname = os.path.basename(d.getVar('S'))
#cause problems fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, 'src', d.getVar('GO_IMPORT')) + '/'
#FIX
fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, '', d.getVar('GO_IMPORT')) + '/'
#FIX
fetcher.unpack(d.getVar('WORKDIR'))
}
# src folder will break devtool upgrade
go_do_configure() {
#cause problems ln -snf ${S}/src ${B}/
#FIX
ln -snf ${S} ${B}/
#FIX
}
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:56:48
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Thanks, I do not have a quick answer to this, but would appreciate if
you can dig deeper into the issue.
Alex
On Thu, 20 Oct 2022 at 11:50, Roos, Thomas <throos@...> wrote:
yes, easy
- set the go-helloworld bb srcrev to an older rev - e.g:
SRCREV = "ad95e7f791d8e1e7e7ec7f7cedfc2f6b29f6c9e2"
"devtool upgrade go-helloworld"
INFO: Extracting upgraded version source...
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 567, in upgrade
rev2, md5, sha256, srcbranch, srcsubdir2 = _extract_new_source(args.version, srctree, args.no_patch,
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 183, in _extract_new_source
__run('git checkout %s' % rev)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 170, in __run
return _run(cmd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 31, in _run
return bb.process.run('%s' % cmd, cwd=cwd)
File "/home/ubuntu/yocto/poky/bitbake/lib/bb/process.py", line 189, in run
raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
bb.process.ExecutionError: Execution of 'git checkout 2e68773dfca072cb81f219fc3b97ad34fe9d9f94' failed with exit code 128:
fatal: reference is not a tree: 2e68773dfca072cb81f219fc3b97ad34fe9d9f94
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/devtool", line 338, in <module>
ret = main()
File "/home/ubuntu/yocto/poky/scripts/devtool", line 325, in main
ret = args.func(args, config, basepath, workspace)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 575, in upgrade
_upgrade_error(e, recipedir, srctree, args.keep_failure)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 134, in _upgrade_error
_cleanup_on_error(rd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 126, in _cleanup_on_error
if not len(os.listdir(rdp)):
FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/yocto/build/workspace/recipes'
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:32:19
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
It helps if you show the exact error, and a way to reproduce this
using a minimal setup (ideally only poky).
Alex
On Thu, 20 Oct 2022 at 11:18, Thomas Roos via lists.yoctoproject.org
<throos=amazon.de@...> wrote:
Hi,
when doing a "devtool upgrade" for a recipe which inherits "go" and using a SRC_URI to a git repo this will fail. Complaining that the git revision is "out of tree" - I found that the additional "src" folder inside the checkout out sources is causing this problem and I wondering if this is necessary. I'm not a go programmer, but when changing this the recipe seems to produce the same result.
I did change our go recipe to don't use this additional src folder by overwriting the go_do_upack and go_do_configure method. Here: https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a91b9703609d7658bd1649350acaf/recipes-support/amazon-ssm-agent/amazon-ssm-agent_3.1.1856.0.bb
Is this a bug or do anybody know why go use that additional src folder?
Cheers,
Thomas
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
Re: devtool upgrade for go recipes with git "broken"
sure, but may this src folder is necessary for something? Some go convention I don't know about...
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 12:09:47
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Can you propose a patch to core?
Alex
On Thu, 20 Oct 2022 at 12:05, Roos, Thomas <throos@...> wrote:
>
> yes, I already did this - it's because that go.bbclass is spangly using a subdir called "src" and that will break the devtool check for upgrades mechanism because it's not looking into a src subdir. So git will fail checkout anything in the parent dir "reference
is not a tree"
>
> This simple change in the go.bbclass fix it - but I don't know if that additional src dir is somehow necessary:
>
>
> # src folder will break devtool upgrade
> python go_do_unpack() {
> src_uri = (d.getVar('SRC_URI') or "").split()
> if len(src_uri) == 0:
> return
>
> fetcher = bb.fetch2.Fetch(src_uri, d)
> for url in fetcher.urls:
> if fetcher.ud[url].type == 'git':
> if fetcher.ud[url].parm.get('destsuffix') is None:
> s_dirname = os.path.basename(d.getVar('S'))
> #cause problems fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, 'src', d.getVar('GO_IMPORT')) + '/'
> #FIX
> fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, '', d.getVar('GO_IMPORT')) + '/'
> #FIX
> fetcher.unpack(d.getVar('WORKDIR'))
> }
>
> # src folder will break devtool upgrade
> go_do_configure() {
> #cause problems ln -snf ${S}/src ${B}/
> #FIX
> ln -snf ${S} ${B}/
> #FIX
> }
>
>
> ________________________________
> Von: Alexander Kanavin <alex.kanavin@...>
> Gesendet: Donnerstag, 20. Oktober 2022 11:56:48
> An: Roos, Thomas
> Cc: yocto@...
> Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> Thanks, I do not have a quick answer to this, but would appreciate if
> you can dig deeper into the issue.
>
> Alex
>
> On Thu, 20 Oct 2022 at 11:50, Roos, Thomas <throos@...> wrote:
> >
> > yes, easy
> > - set the go-helloworld bb srcrev to an older rev - e.g:
> > SRCREV = "ad95e7f791d8e1e7e7ec7f7cedfc2f6b29f6c9e2"
> >
> > "devtool upgrade go-helloworld"
> >
> > INFO: Extracting upgraded version source...
> > Traceback (most recent call last):
> > File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 567, in upgrade
> > rev2, md5, sha256, srcbranch, srcsubdir2 = _extract_new_source(args.version, srctree, args.no_patch,
> > File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 183, in _extract_new_source
> > __run('git checkout %s' % rev)
> > File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 170, in __run
> > return _run(cmd, srctree)
> > File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 31, in _run
> > return bb.process.run('%s' % cmd, cwd=cwd)
> > File "/home/ubuntu/yocto/poky/bitbake/lib/bb/process.py", line 189, in run
> > raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
> > bb.process.ExecutionError: Execution of 'git checkout 2e68773dfca072cb81f219fc3b97ad34fe9d9f94' failed with exit code 128:
> > fatal: reference is not a tree: 2e68773dfca072cb81f219fc3b97ad34fe9d9f94
> >
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File "/home/ubuntu/yocto/poky/scripts/devtool", line 338, in <module>
> > ret = main()
> > File "/home/ubuntu/yocto/poky/scripts/devtool", line 325, in main
> > ret = args.func(args, config, basepath, workspace)
> > File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 575, in upgrade
> > _upgrade_error(e, recipedir, srctree, args.keep_failure)
> > File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 134, in _upgrade_error
> > _cleanup_on_error(rd, srctree)
> > File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 126, in _cleanup_on_error
> > if not len(os.listdir(rdp)):
> > FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/yocto/build/workspace/recipes'
> >
> >
> >
> >
> >
> > ________________________________
> > Von: Alexander Kanavin <alex.kanavin@...>
> > Gesendet: Donnerstag, 20. Oktober 2022 11:32:19
> > An: Roos, Thomas
> > Cc: yocto@...
> > Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
> >
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > It helps if you show the exact error, and a way to reproduce this
> > using a minimal setup (ideally only poky).
> >
> > Alex
> >
> > On Thu, 20 Oct 2022 at 11:18, Thomas Roos via lists.yoctoproject.org
> > <throos=amazon.de@...> wrote:
> > >
> > > Hi,
> > > when doing a "devtool upgrade" for a recipe which inherits "go" and using a SRC_URI to a git repo this will fail. Complaining that the git revision is "out of tree" - I found that the additional "src" folder inside the checkout out sources is causing
this problem and I wondering if this is necessary. I'm not a go programmer, but when changing this the recipe seems to produce the same result.
> > > I did change our go recipe to don't use this additional src folder by overwriting the go_do_upack and go_do_configure method. Here:
https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a91b9703609d7658bd1649350acaf/recipes-support/amazon-ssm-agent/amazon-ssm-agent_3.1.1856.0.bb
> > > Is this a bug or do anybody know why go use that additional src folder?
> > >
> > >
> > > Cheers,
> > > Thomas
> > >
> > >
> > >
> > >
> > > Amazon Web Services EMEA SARL
> > > 38 avenue John F. Kennedy, L-1855 Luxembourg
> > > Sitz der Gesellschaft: L-1855 Luxemburg
> > > eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
> > >
> > > Amazon Web Services EMEA SARL, Niederlassung Deutschland
> > > Marcel-Breuer-Str. 12, D-80807 Muenchen
> > > Sitz der Zweigniederlassung: Muenchen
> > > eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > Amazon Web Services EMEA SARL
> > 38 avenue John F. Kennedy, L-1855 Luxembourg
> > Sitz der Gesellschaft: L-1855 Luxemburg
> > eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
> >
> > Amazon Web Services EMEA SARL, Niederlassung Deutschland
> > Marcel-Breuer-Str. 12, D-80807 Muenchen
> > Sitz der Zweigniederlassung: Muenchen
> > eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
> >
> >
>
>
>
> Amazon Web Services EMEA SARL
> 38 avenue John F. Kennedy, L-1855 Luxembourg
> Sitz der Gesellschaft: L-1855 Luxemburg
> eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
>
> Amazon Web Services EMEA SARL, Niederlassung Deutschland
> Marcel-Breuer-Str. 12, D-80807 Muenchen
> Sitz der Zweigniederlassung: Muenchen
> eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
>
>
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
Re: devtool upgrade for go recipes with git "broken"
Can you propose a patch to core?
Alex
toggle quoted message
Show quoted text
On Thu, 20 Oct 2022 at 12:05, Roos, Thomas <throos@...> wrote:
yes, I already did this - it's because that go.bbclass is spangly using a subdir called "src" and that will break the devtool check for upgrades mechanism because it's not looking into a src subdir. So git will fail checkout anything in the parent dir "reference is not a tree"
This simple change in the go.bbclass fix it - but I don't know if that additional src dir is somehow necessary:
# src folder will break devtool upgrade
python go_do_unpack() {
src_uri = (d.getVar('SRC_URI') or "").split()
if len(src_uri) == 0:
return
fetcher = bb.fetch2.Fetch(src_uri, d)
for url in fetcher.urls:
if fetcher.ud[url].type == 'git':
if fetcher.ud[url].parm.get('destsuffix') is None:
s_dirname = os.path.basename(d.getVar('S'))
#cause problems fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, 'src', d.getVar('GO_IMPORT')) + '/'
#FIX
fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, '', d.getVar('GO_IMPORT')) + '/'
#FIX
fetcher.unpack(d.getVar('WORKDIR'))
}
# src folder will break devtool upgrade
go_do_configure() {
#cause problems ln -snf ${S}/src ${B}/
#FIX
ln -snf ${S} ${B}/
#FIX
}
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:56:48
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Thanks, I do not have a quick answer to this, but would appreciate if
you can dig deeper into the issue.
Alex
On Thu, 20 Oct 2022 at 11:50, Roos, Thomas <throos@...> wrote:
yes, easy
- set the go-helloworld bb srcrev to an older rev - e.g:
SRCREV = "ad95e7f791d8e1e7e7ec7f7cedfc2f6b29f6c9e2"
"devtool upgrade go-helloworld"
INFO: Extracting upgraded version source...
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 567, in upgrade
rev2, md5, sha256, srcbranch, srcsubdir2 = _extract_new_source(args.version, srctree, args.no_patch,
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 183, in _extract_new_source
__run('git checkout %s' % rev)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 170, in __run
return _run(cmd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 31, in _run
return bb.process.run('%s' % cmd, cwd=cwd)
File "/home/ubuntu/yocto/poky/bitbake/lib/bb/process.py", line 189, in run
raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
bb.process.ExecutionError: Execution of 'git checkout 2e68773dfca072cb81f219fc3b97ad34fe9d9f94' failed with exit code 128:
fatal: reference is not a tree: 2e68773dfca072cb81f219fc3b97ad34fe9d9f94
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/devtool", line 338, in <module>
ret = main()
File "/home/ubuntu/yocto/poky/scripts/devtool", line 325, in main
ret = args.func(args, config, basepath, workspace)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 575, in upgrade
_upgrade_error(e, recipedir, srctree, args.keep_failure)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 134, in _upgrade_error
_cleanup_on_error(rd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 126, in _cleanup_on_error
if not len(os.listdir(rdp)):
FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/yocto/build/workspace/recipes'
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:32:19
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
It helps if you show the exact error, and a way to reproduce this
using a minimal setup (ideally only poky).
Alex
On Thu, 20 Oct 2022 at 11:18, Thomas Roos via lists.yoctoproject.org
<throos=amazon.de@...> wrote:
Hi,
when doing a "devtool upgrade" for a recipe which inherits "go" and using a SRC_URI to a git repo this will fail. Complaining that the git revision is "out of tree" - I found that the additional "src" folder inside the checkout out sources is causing this problem and I wondering if this is necessary. I'm not a go programmer, but when changing this the recipe seems to produce the same result.
I did change our go recipe to don't use this additional src folder by overwriting the go_do_upack and go_do_configure method. Here: https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a91b9703609d7658bd1649350acaf/recipes-support/amazon-ssm-agent/amazon-ssm-agent_3.1.1856.0.bb
Is this a bug or do anybody know why go use that additional src folder?
Cheers,
Thomas
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
Re: devtool upgrade for go recipes with git "broken"
yes, I already did this - it's because that go.bbclass is spangly using a subdir called "src" and that will break the devtool check for upgrades mechanism because it's not looking into a src subdir. So git will fail checkout anything in the parent dir "reference
is not a tree"
This simple change in the go.bbclass fix it - but I don't know if that additional src dir is somehow necessary:
# src folder will break devtool upgrade
python go_do_unpack() {
src_uri = (d.getVar('SRC_URI') or "").split()
if len(src_uri) == 0:
return
fetcher = bb.fetch2.Fetch(src_uri, d)
for url in fetcher.urls:
if fetcher.ud[url].type == 'git':
if fetcher.ud[url].parm.get('destsuffix') is None:
s_dirname = os.path.basename(d.getVar('S'))
#cause problems fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, 'src', d.getVar('GO_IMPORT')) + '/'
#FIX
fetcher.ud[url].parm['destsuffix'] = os.path.join(s_dirname, '', d.getVar('GO_IMPORT')) + '/'
#FIX
fetcher.unpack(d.getVar('WORKDIR'))
}
# src folder will break devtool upgrade
go_do_configure() {
#cause problems ln -snf ${S}/src ${B}/
#FIX
ln -snf ${S} ${B}/
#FIX
}
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:56:48
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Thanks, I do not have a quick answer to this, but would appreciate if
you can dig deeper into the issue.
Alex
On Thu, 20 Oct 2022 at 11:50, Roos, Thomas <throos@...> wrote:
>
> yes, easy
> - set the go-helloworld bb srcrev to an older rev - e.g:
> SRCREV = "ad95e7f791d8e1e7e7ec7f7cedfc2f6b29f6c9e2"
>
> "devtool upgrade go-helloworld"
>
> INFO: Extracting upgraded version source...
> Traceback (most recent call last):
> File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 567, in upgrade
> rev2, md5, sha256, srcbranch, srcsubdir2 = _extract_new_source(args.version, srctree, args.no_patch,
> File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 183, in _extract_new_source
> __run('git checkout %s' % rev)
> File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 170, in __run
> return _run(cmd, srctree)
> File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 31, in _run
> return bb.process.run('%s' % cmd, cwd=cwd)
> File "/home/ubuntu/yocto/poky/bitbake/lib/bb/process.py", line 189, in run
> raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
> bb.process.ExecutionError: Execution of 'git checkout 2e68773dfca072cb81f219fc3b97ad34fe9d9f94' failed with exit code 128:
> fatal: reference is not a tree: 2e68773dfca072cb81f219fc3b97ad34fe9d9f94
>
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/home/ubuntu/yocto/poky/scripts/devtool", line 338, in <module>
> ret = main()
> File "/home/ubuntu/yocto/poky/scripts/devtool", line 325, in main
> ret = args.func(args, config, basepath, workspace)
> File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 575, in upgrade
> _upgrade_error(e, recipedir, srctree, args.keep_failure)
> File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 134, in _upgrade_error
> _cleanup_on_error(rd, srctree)
> File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 126, in _cleanup_on_error
> if not len(os.listdir(rdp)):
> FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/yocto/build/workspace/recipes'
>
>
>
>
>
> ________________________________
> Von: Alexander Kanavin <alex.kanavin@...>
> Gesendet: Donnerstag, 20. Oktober 2022 11:32:19
> An: Roos, Thomas
> Cc: yocto@...
> Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> It helps if you show the exact error, and a way to reproduce this
> using a minimal setup (ideally only poky).
>
> Alex
>
> On Thu, 20 Oct 2022 at 11:18, Thomas Roos via lists.yoctoproject.org
> <throos=amazon.de@...> wrote:
> >
> > Hi,
> > when doing a "devtool upgrade" for a recipe which inherits "go" and using a SRC_URI to a git repo this will fail. Complaining that the git revision is "out of tree" - I found that the additional "src" folder inside the checkout out sources is causing this
problem and I wondering if this is necessary. I'm not a go programmer, but when changing this the recipe seems to produce the same result.
> > I did change our go recipe to don't use this additional src folder by overwriting the go_do_upack and go_do_configure method. Here:
https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a91b9703609d7658bd1649350acaf/recipes-support/amazon-ssm-agent/amazon-ssm-agent_3.1.1856.0.bb
> > Is this a bug or do anybody know why go use that additional src folder?
> >
> >
> > Cheers,
> > Thomas
> >
> >
> >
> >
> > Amazon Web Services EMEA SARL
> > 38 avenue John F. Kennedy, L-1855 Luxembourg
> > Sitz der Gesellschaft: L-1855 Luxemburg
> > eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
> >
> > Amazon Web Services EMEA SARL, Niederlassung Deutschland
> > Marcel-Breuer-Str. 12, D-80807 Muenchen
> > Sitz der Zweigniederlassung: Muenchen
> > eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
> >
> >
> >
> >
> >
>
>
>
> Amazon Web Services EMEA SARL
> 38 avenue John F. Kennedy, L-1855 Luxembourg
> Sitz der Gesellschaft: L-1855 Luxemburg
> eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
>
> Amazon Web Services EMEA SARL, Niederlassung Deutschland
> Marcel-Breuer-Str. 12, D-80807 Muenchen
> Sitz der Zweigniederlassung: Muenchen
> eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
>
>
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
Re: devtool upgrade for go recipes with git "broken"
Thanks, I do not have a quick answer to this, but would appreciate if
you can dig deeper into the issue.
Alex
toggle quoted message
Show quoted text
On Thu, 20 Oct 2022 at 11:50, Roos, Thomas <throos@...> wrote:
yes, easy
- set the go-helloworld bb srcrev to an older rev - e.g:
SRCREV = "ad95e7f791d8e1e7e7ec7f7cedfc2f6b29f6c9e2"
"devtool upgrade go-helloworld"
INFO: Extracting upgraded version source...
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 567, in upgrade
rev2, md5, sha256, srcbranch, srcsubdir2 = _extract_new_source(args.version, srctree, args.no_patch,
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 183, in _extract_new_source
__run('git checkout %s' % rev)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 170, in __run
return _run(cmd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 31, in _run
return bb.process.run('%s' % cmd, cwd=cwd)
File "/home/ubuntu/yocto/poky/bitbake/lib/bb/process.py", line 189, in run
raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
bb.process.ExecutionError: Execution of 'git checkout 2e68773dfca072cb81f219fc3b97ad34fe9d9f94' failed with exit code 128:
fatal: reference is not a tree: 2e68773dfca072cb81f219fc3b97ad34fe9d9f94
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/devtool", line 338, in <module>
ret = main()
File "/home/ubuntu/yocto/poky/scripts/devtool", line 325, in main
ret = args.func(args, config, basepath, workspace)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 575, in upgrade
_upgrade_error(e, recipedir, srctree, args.keep_failure)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 134, in _upgrade_error
_cleanup_on_error(rd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 126, in _cleanup_on_error
if not len(os.listdir(rdp)):
FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/yocto/build/workspace/recipes'
________________________________
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:32:19
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
It helps if you show the exact error, and a way to reproduce this
using a minimal setup (ideally only poky).
Alex
On Thu, 20 Oct 2022 at 11:18, Thomas Roos via lists.yoctoproject.org
<throos=amazon.de@...> wrote:
Hi,
when doing a "devtool upgrade" for a recipe which inherits "go" and using a SRC_URI to a git repo this will fail. Complaining that the git revision is "out of tree" - I found that the additional "src" folder inside the checkout out sources is causing this problem and I wondering if this is necessary. I'm not a go programmer, but when changing this the recipe seems to produce the same result.
I did change our go recipe to don't use this additional src folder by overwriting the go_do_upack and go_do_configure method. Here: https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a91b9703609d7658bd1649350acaf/recipes-support/amazon-ssm-agent/amazon-ssm-agent_3.1.1856.0.bb
Is this a bug or do anybody know why go use that additional src folder?
Cheers,
Thomas
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
Re: devtool upgrade for go recipes with git "broken"
yes, easy
- set the go-helloworld bb srcrev to an older rev - e.g:
SRCREV = "ad95e7f791d8e1e7e7ec7f7cedfc2f6b29f6c9e2"
"devtool upgrade go-helloworld"
INFO: Extracting upgraded version source...
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 567, in upgrade
rev2, md5, sha256, srcbranch, srcsubdir2 = _extract_new_source(args.version, srctree, args.no_patch,
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 183, in _extract_new_source
__run('git checkout %s' % rev)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 170, in __run
return _run(cmd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 31, in _run
return bb.process.run('%s' % cmd, cwd=cwd)
File "/home/ubuntu/yocto/poky/bitbake/lib/bb/process.py", line 189, in run
raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
bb.process.ExecutionError: Execution of 'git checkout 2e68773dfca072cb81f219fc3b97ad34fe9d9f94' failed with exit code 128:
fatal: reference is not a tree: 2e68773dfca072cb81f219fc3b97ad34fe9d9f94
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/ubuntu/yocto/poky/scripts/devtool", line 338, in <module>
ret = main()
File "/home/ubuntu/yocto/poky/scripts/devtool", line 325, in main
ret = args.func(args, config, basepath, workspace)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 575, in upgrade
_upgrade_error(e, recipedir, srctree, args.keep_failure)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 134, in _upgrade_error
_cleanup_on_error(rd, srctree)
File "/home/ubuntu/yocto/poky/scripts/lib/devtool/upgrade.py", line 126, in _cleanup_on_error
if not len(os.listdir(rdp)):
FileNotFoundError: [Errno 2] No such file or directory: '/home/ubuntu/yocto/build/workspace/recipes'
Von: Alexander Kanavin <alex.kanavin@...>
Gesendet: Donnerstag, 20. Oktober 2022 11:32:19
An: Roos, Thomas
Cc: yocto@...
Betreff: RE: [EXTERNAL][yocto] devtool upgrade for go recipes with git "broken"
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
It helps if you show the exact error, and a way to reproduce this
using a minimal setup (ideally only poky).
Alex
On Thu, 20 Oct 2022 at 11:18, Thomas Roos via lists.yoctoproject.org
<throos=amazon.de@...> wrote:
>
> Hi,
> when doing a "devtool upgrade" for a recipe which inherits "go" and using a SRC_URI to a git repo this will fail. Complaining that the git revision is "out of tree" - I found that the additional "src" folder inside the checkout out sources is causing this
problem and I wondering if this is necessary. I'm not a go programmer, but when changing this the recipe seems to produce the same result.
> I did change our go recipe to don't use this additional src folder by overwriting the go_do_upack and go_do_configure method. Here:
https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a91b9703609d7658bd1649350acaf/recipes-support/amazon-ssm-agent/amazon-ssm-agent_3.1.1856.0.bb
> Is this a bug or do anybody know why go use that additional src folder?
>
>
> Cheers,
> Thomas
>
>
>
>
> Amazon Web Services EMEA SARL
> 38 avenue John F. Kennedy, L-1855 Luxembourg
> Sitz der Gesellschaft: L-1855 Luxemburg
> eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
>
> Amazon Web Services EMEA SARL, Niederlassung Deutschland
> Marcel-Breuer-Str. 12, D-80807 Muenchen
> Sitz der Zweigniederlassung: Muenchen
> eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
>
>
>
>
>
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
Re: devtool upgrade for go recipes with git "broken"
It helps if you show the exact error, and a way to reproduce this using a minimal setup (ideally only poky). Alex On Thu, 20 Oct 2022 at 11:18, Thomas Roos via lists.yoctoproject.org <throos=amazon.de@...> wrote:
Hi,
when doing a "devtool upgrade" for a recipe which inherits "go" and using a SRC_URI to a git repo this will fail. Complaining that the git revision is "out of tree" - I found that the additional "src" folder inside the checkout out sources is causing this problem and I wondering if this is necessary. I'm not a go programmer, but when changing this the recipe seems to produce the same result.
I did change our go recipe to don't use this additional src folder by overwriting the go_do_upack and go_do_configure method. Here: https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a91b9703609d7658bd1649350acaf/recipes-support/amazon-ssm-agent/amazon-ssm-agent_3.1.1856.0.bb
Is this a bug or do anybody know why go use that additional src folder?
Cheers,
Thomas
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
devtool upgrade for go recipes with git "broken"
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
Re: devtool upgrade multiple architectures possible?
This would be a much welcome feature. I suspect however that devtool relies on the current target, and won't be easily convinced to update other targets. Alex On Thu, 20 Oct 2022 at 10:51, Thomas Roos via lists.yoctoproject.org <throos=amazon.de@...> wrote:
Hi,
wondering if it's possible when doing a "devtool upgrade" for a binary recipe to upgrade SRC rev for all architectures in that recipe. Or is this a missing feature?
E.g. here do an "aarch64.sha256sum" as well when running devtool upgrade and not only "x86-64.sha256sum"
SRC_URI[x86-64.sha256sum] = "aeec1a4fb34ffabbac931ba430601807133659a4bd02703c33044e80c925bed2"
SRC_URI[aarch64.sha256sum] = "69aa5a95b3f9030e1fef5b5886e4c97f75fffa7534dc2c98e59ef402a819a0aa"
Full file: https://github.com/aws4embeddedlinux/meta-aws/blob/942651026c7a91b9703609d7658bd1649350acaf/recipes-devtools/amazon-corretto/corretto-17-bin_17.0.5.8.1.bb
If this is not currently possible, I can create a bugzilla feature request, but wanted to ask first.
Cheers,
Thomas
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
devtool upgrade multiple architectures possible?
Hi,
wondering if it's possible when doing a "devtool upgrade" for a binary recipe to upgrade SRC rev for all architectures in that recipe. Or is this a missing feature?
E.g. here do an "aarch64.sha256sum" as well when running devtool upgrade and not only "x86-64.sha256sum"
Thomas
Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284
Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, USt-ID DE317013094
|
|
|
Re: Adding msktutil in yocto
#yocto
Poornesh G ( India - Bangalore )
Dear Khem Raj,
Thanks much , I could successfully able to add "msktutil" as per your response.
Thanks,
toggle quoted message
Show quoted text
On Thursday, October 20, 2022 11:26 IST, Khem Raj <raj.khem@...> wrote: Try something like
https://git.openembedded.org/meta-openembedded/commit/?h=master-next
On Wed, Oct 19, 2022 at 10:33 PM <poornesh.g@...> wrote:
>
> Greetings !
>
> Can any one help me out to include "msktutil" (used for fetching and managing kerberos keytabs in an Active Directory environment) in Yocto (Zeus).
>
> Thanks,
>
>
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
|
|
Re: Adding msktutil in yocto
#yocto
Khem Raj
toggle quoted message
Show quoted text
On Wed, Oct 19, 2022 at 10:33 PM <poornesh.g@...> wrote:
Greetings !
Can any one help me out to include "msktutil" (used for fetching and managing kerberos keytabs in an Active Directory environment) in Yocto (Zeus).
Thanks,
|
|
|
Adding msktutil in yocto
#yocto
Poornesh G ( India - Bangalore )
Greetings !
Can any one help me out to include "msktutil" (used for fetching and managing kerberos keytabs in an Active Directory environment) in Yocto (Zeus).
Thanks,
|
|
|
Re: [meta-rockchip][PATCH] add support for PX30 SoC
Khem Raj
On Wed, Oct 19, 2022 at 1:45 AM Quentin Schulz <foss@...> wrote:
From: Quentin Schulz <quentin.schulz@...>
Rockchip PX30 SoC is a quad-core ARM Cortex-A35 CPU fully implementing
the ARMv8-A instruction set with ARM Neon Advanced SIMD and Cryptography
Extensions.
This adds a base configuration file which can be included by PX30-based
boards and the required changes in U-Boot and TF-A for proper support.
lgtm Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
Note: this was developed and tested on kirkstone branch only
conf/machine/include/px30.inc | 21 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 5 +++++
recipes-bsp/u-boot/u-boot%.bbappend | 2 ++
3 files changed, 28 insertions(+)
create mode 100644 conf/machine/include/px30.inc
diff --git a/conf/machine/include/px30.inc b/conf/machine/include/px30.inc
new file mode 100644
index 0000000..a3727fb
--- /dev/null
+++ b/conf/machine/include/px30.inc
@@ -0,0 +1,21 @@
+# Copyright (C) 2022 Theobroma Systems Design und Consulting
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "px30"
+
+DEFAULTTUNE ?= "cortexa35-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/arm/armv8a/tune-cortexa35.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "px30"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 31024ce..814028b 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,6 +4,7 @@ DEPENDS:append:rk3399 = " virtual/arm-none-eabi-gcc-native"
COMPATIBLE_MACHINE:append:rk3399 = "|rk3399"
COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"
+COMPATIBLE_MACHINE:append:px30 = "|px30"
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
@@ -26,4 +27,8 @@ fixup_baudrate:rk3399() {
sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
}
+fixup_baudrate:px30() {
+ sed -i "s/#define PX30_BAUDRATE\s\+.*/#define PX30_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/px30/px30_def.h
+}
+
do_patch[postfuncs] += "fixup_baudrate"
diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend
index 9108a36..de1f2ca 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -11,6 +11,8 @@ EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
ATF_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
ATF_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy"
+EXTRA_OEMAKE:append:px30 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-px30.elf"
+ATF_DEPENDS:px30 = " trusted-firmware-a:do_deploy"
do_compile[depends] .= "${ATF_DEPENDS}"
--
2.37.3
|
|
|
[meta-rockchip][PATCH] add support for PX30 SoC
From: Quentin Schulz <quentin.schulz@...>
Rockchip PX30 SoC is a quad-core ARM Cortex-A35 CPU fully implementing
the ARMv8-A instruction set with ARM Neon Advanced SIMD and Cryptography
Extensions.
This adds a base configuration file which can be included by PX30-based
boards and the required changes in U-Boot and TF-A for proper support.
Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
Note: this was developed and tested on kirkstone branch only
conf/machine/include/px30.inc | 21 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 5 +++++
recipes-bsp/u-boot/u-boot%.bbappend | 2 ++
3 files changed, 28 insertions(+)
create mode 100644 conf/machine/include/px30.inc
diff --git a/conf/machine/include/px30.inc b/conf/machine/include/px30.inc
new file mode 100644
index 0000000..a3727fb
--- /dev/null
+++ b/conf/machine/include/px30.inc
@@ -0,0 +1,21 @@
+# Copyright (C) 2022 Theobroma Systems Design und Consulting
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "px30"
+
+DEFAULTTUNE ?= "cortexa35-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/arm/armv8a/tune-cortexa35.inc
+require conf/machine/include/rockchip-defaults.inc
+require conf/machine/include/rockchip-wic.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "px30"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 31024ce..814028b 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,6 +4,7 @@ DEPENDS:append:rk3399 = " virtual/arm-none-eabi-gcc-native"
COMPATIBLE_MACHINE:append:rk3399 = "|rk3399"
COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"
+COMPATIBLE_MACHINE:append:px30 = "|px30"
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
@@ -26,4 +27,8 @@ fixup_baudrate:rk3399() {
sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
}
+fixup_baudrate:px30() {
+ sed -i "s/#define PX30_BAUDRATE\s\+.*/#define PX30_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/px30/px30_def.h
+}
+
do_patch[postfuncs] += "fixup_baudrate"
diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend
index 9108a36..de1f2ca 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -11,6 +11,8 @@ EXTRA_OEMAKE:append:rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
ATF_DEPENDS:rk3399 = " trusted-firmware-a:do_deploy"
EXTRA_OEMAKE:append:rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
ATF_DEPENDS:rk3328 = " trusted-firmware-a:do_deploy"
+EXTRA_OEMAKE:append:px30 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-px30.elf"
+ATF_DEPENDS:px30 = " trusted-firmware-a:do_deploy"
do_compile[depends] .= "${ATF_DEPENDS}"
--
2.37.3
|
|
|
Re: Dealing with go dependencies in recipes - native docker-compose
On Tue, Oct 18, 2022 at 01:39:34PM -0400, Bruce Ashfield wrote: root@qemux86-64-c9:~# /usr/lib/docker/cli-plugins/docker-compose version
Docker Compose version v2.11.2 root@insidem2m:~/docker-nginx-demo# docker compose version Docker Compose version v2.11.2 I did a test run with a small docker-compose.yml for a nginx hello world demo. It worked flawlessly, downloading, installing and starting went really fine. Perfect, nice work! Kind Regards Konstantin -- INSIDE M2M GmbH Konstantin Kletschke Berenbosteler Straße 76 B 30823 Garbsen Telefon: +49 (0) 5137 90950136 Mobil: +49 (0) 151 15256238 Fax: +49 (0) 5137 9095010 konstantin.kletschke@... http://www.inside-m2m.de Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig HRB: 111204, AG Hannover
|
|
|
Re: do_kernel_configme - Could not generate configuration queue
Jeremy Puhlman
On 10/18/2022 3:31 PM, Bruce Ashfield
wrote:
On Tue, Oct 18, 2022 at 5:01
PM Jeremy Puhlman < jpuhlman@...>
wrote:
On 10/14/2022 6:52 PM, Bruce Ashfield wrote:
Yes indeed. This has
also passed my other regression testing, but I
was traveling today and couldn't send my pull
request.
I'll send it over the
weekend, so hopefully it'll be merged shortly!
Bruce
Did this end up getting sen to the list? I also validated
updating to the specific hash resolved my issue too.
Nope. I
got tied up with some other issues, I'll send it tonight
when I get a moment!
Bruce
Thanks!
Jose
I am
running into a bizarre problem with kernel
configuration.
I have an existing build environment that
builds for an i.MX6ul machine.
That works fine and the linux-fslc kernel
5.18 builds without any
problems. Now within the that build
environment I changed the machine to
imx6ullevk and then the kernel configuration
fails with this error message:
| DEBUG: Executing shell function
do_kernel_configme
| NOTE: do_kernel_metadata: for
summary/debug, set KCONF_AUDIT_LEVEL > 0
| [ERROR]: processing of file
/tmp/tmp.owmBptYrba failed
|
/develop/projects/altec/tcu/build/tmp/hosttools/dirname:
missing operand
| Try
'/develop/projects/altec/tcu/build/tmp/hosttools/dirname
--help'
for more information.
| ERROR: Could not generate configuration
queue for imx6ullevk.
| WARNING:
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395:209
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
| #1: bbfatal_log,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 209
| #2: do_kernel_metadata,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 382
| #3: do_kernel_configme,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 150
| #4: main,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 484
ERROR: Task
(/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc_5.18.bb:do_kernel_configme)
failed with exit code '1'
I tried to debug do_kernel_configme. The
issue seems in the scc script
more specifically, I think, in the kconf
command that is called by scc
when parsing the temporary configuration
queue file in /tmp: tmp.owmBptYrba
#
# spp v0.8
# processed: Fri Oct 14 09:49:02 PM UTC 2022
#
# This is a preprocessor output file, do not
edit
#
#
prefix
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
kconf non-hardware
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
# run time: 0 seconds
# processed files:
# _cfg
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
Apparently a call to dirname is missing the
argument. However, I do not
understand why.
I wiped out build/tmp directory entirely,
ran a cleanall on
virtual/kernel but to no avail. The problem
remains the same.
Has anybody seen this issue before?
Rudi
--
Best regards,
José Quaresma
--
- Thou shalt not follow the NULL
pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
Jeremy A. Puhlman
jpuhlman@...
--
- Thou shalt not follow
the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
Jeremy A. Puhlman
jpuhlman@...
|
|
|
Re: do_kernel_configme - Could not generate configuration queue
Rudolf J Streif
On 10/18/22 15:31, Bruce Ashfield
wrote:
On Tue, Oct 18, 2022 at 5:01
PM Jeremy Puhlman < jpuhlman@...>
wrote:
On 10/14/2022 6:52 PM, Bruce Ashfield wrote:
Yes indeed. This has
also passed my other regression testing, but I
was traveling today and couldn't send my pull
request.
I'll send it over the
weekend, so hopefully it'll be merged shortly!
Bruce
Did this end up getting sen to the list? I also validated
updating to the specific hash resolved my issue too.
Nope. I
got tied up with some other issues, I'll send it tonight
when I get a moment!
I can confirm that updating kern-tools-native to 6a4752eb resolved the issue for
me.
Jose
I am
running into a bizarre problem with kernel
configuration.
I have an existing build environment that
builds for an i.MX6ul machine.
That works fine and the linux-fslc kernel
5.18 builds without any
problems. Now within the that build
environment I changed the machine to
imx6ullevk and then the kernel configuration
fails with this error message:
| DEBUG: Executing shell function
do_kernel_configme
| NOTE: do_kernel_metadata: for
summary/debug, set KCONF_AUDIT_LEVEL > 0
| [ERROR]: processing of file
/tmp/tmp.owmBptYrba failed
|
/develop/projects/altec/tcu/build/tmp/hosttools/dirname:
missing operand
| Try
'/develop/projects/altec/tcu/build/tmp/hosttools/dirname
--help'
for more information.
| ERROR: Could not generate configuration
queue for imx6ullevk.
| WARNING:
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395:209
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
| #1: bbfatal_log,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 209
| #2: do_kernel_metadata,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 382
| #3: do_kernel_configme,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 150
| #4: main,
/develop/projects/altec/tcu/build/tmp/work/imx6ullevk-altec-linux-gnueabi/linux-fslc/5.18.5+gitAUTOINC+1d6b3055ae-r0/temp/run.do_kernel_configme.287395,
line 484
ERROR: Task
(/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc_5.18.bb:do_kernel_configme)
failed with exit code '1'
I tried to debug do_kernel_configme. The
issue seems in the scc script
more specifically, I think, in the kconf
command that is called by scc
when parsing the temporary configuration
queue file in /tmp: tmp.owmBptYrba
#
# spp v0.8
# processed: Fri Oct 14 09:49:02 PM UTC 2022
#
# This is a preprocessor output file, do not
edit
#
#
prefix
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
kconf non-hardware
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
# run time: 0 seconds
# processed files:
# _cfg
/develop/projects/altec/tcu/build/../meta-freescale/recipes-kernel/linux/linux-fslc/defconfig
Apparently a call to dirname is missing the
argument. However, I do not
understand why.
I wiped out build/tmp directory entirely,
ran a cleanall on
virtual/kernel but to no avail. The problem
remains the same.
Has anybody seen this issue before?
Rudi
--
Best regards,
José Quaresma
--
- Thou shalt not follow the NULL
pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
Jeremy A. Puhlman
jpuhlman@...
--
- Thou shalt not follow
the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
--
Rudolf J Streif
CEO/CTO
1.855.442.3386
|
|
|
Re: EXTRA_IMAGECMD:squashfs-xz support
Hello,
Just checking if EXTRA_IMAGECMD:squashfs-xz:append failing to apply is expected or if it should be fixed?
Thanks again,
-Jason
|
|
|
