search

siemens / meta-iot2050

SIMATIC IOT2050 Isar/Debian Board Support Package
MIT License
130 stars 77 forks source link

Chao/bump version #269

Closed AsuraZeng closed 2 years ago

jan-kiszka commented 2 years ago

I do have a kernel update to latest stable (101 for non-rt) here as well, but we need to merge my watchdog fixes first (it uses them).

jan-kiszka commented 2 years ago

And U-Boot is also more complex, but I have a queue. Blocker here is a new release for SE Boot.

AsuraZeng commented 2 years ago

I do have a kernel update to latest stable (101 for non-rt) here as well, but we need to merge my watchdog fixes first (it uses them).

I suggest we unify none-rt and rt kernel version based on 100. cause for 101 do not have a formal rt patch currently. unify the kernel version I think could reduce the test work.

jan-kiszka commented 2 years ago

We didn't unify the past release as well, so I see no benefits, rather risks to miss relevant fixes for the majority of users (those of the example image).

jan-kiszka commented 2 years ago

FWIW, latest U-Boot 2022.01 queue now at https://github.com/siemens/u-boot/commits/jan/iot2050-v2022.01. But, as I said, it depends on a new SE Boot release.

jan-kiszka commented 2 years ago

In order to move forward, I would suggest to drop kernel and u-boot from this PR. Those can be updates later once their preconditions are fulfilled.

AsuraZeng commented 2 years ago

I agree with you. But we'd like to start our OSS clearing, it's better to finally determine the u-boot and kernel version when we do next release.

currently, I proposal to unify the none-rt and rt kernel based on 5.10.100. firstly,it would reduce our testing work, another it would reduce oss clearing time. only do one kernel version OSS. Although there are benefits to separating the kernel versions. consider it comprehensively, maybe it is better unify kernel version for the current

Another, for u-boot, we would bump up to latest U-Boot 2022.01.

jan-kiszka commented 2 years ago

Testing efforts will not be different between 5.10.100 and 5.10.102 because the RT kernel is a different thing, so you unfortunately gain almost nothing by using the same base version /wrt testing. And OSS license report for both stable versions will be identical. I'm all for moving forward with updating recipes, therefore: Please review/ack #266 ASAP.

I think we agree that U-Boot mainline version is set. You can help with moving forward there by looking at the additional patch queue likely needed (see what I shared).

AsuraZeng commented 2 years ago

I have dropped the u-boot and kernel and rebase with master.

AsuraZeng commented 2 years ago

@jan-kiszka upgrade TF-A and optee to the latest version. do you have any comments on this upgrade.

AsuraZeng commented 2 years ago

Oops，CI is down. the repo in the meta-coral git://salsa.debian.org/python-team/packages/python-gast.git has some problem. has reported to meta-coral

jan-kiszka commented 2 years ago

I've done these updates locally as well. TF-A seems fine, OP-TEE now gives us

I/TC: OP-TEE version: 3.16.0 (gcc version 10.2.1 20210110 (Debian 10.2.1-6)) #1 Thu Jan  1 00:00:42 UTC 1970 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html

which still needs clarification. I was already in contact with TI.

BaochengSu commented 2 years ago

Oops，CI is down. the repo in the meta-coral git://salsa.debian.org/python-team/packages/python-gast.git has some problem. has reported to meta-coral

Seems the entire https://salsa.debian.org/ is down. We could either 1) wait for Debian fix it or 2) remove meta-coral out of the ci temporary.

I think Debian will fix the website soon, so I stick with opt 1.

BaochengSu commented 2 years ago

I've done these updates locally as well. TF-A seems fine, OP-TEE now gives us

I/TC: OP-TEE version: 3.16.0 (gcc version 10.2.1 20210110 (Debian 10.2.1-6)) #1 Thu Jan  1 00:00:42 UTC 1970 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html

which still needs clarification. I was already in contact with TI.

@AsuraZeng , Since atf, optee and u-boot are within the bootloader scope, we can leave them together in future PR.

So for this one I think we can go w/o them.

jan-kiszka commented 2 years ago

Regarding salsa: https://micronews.debian.org/2022/1645992519.html - they are aware, but it seems to take some effort.

BaochengSu commented 2 years ago

@jan-kiszka could the verisons for OPTEE & ATF & u-boot be freezed for oss clearing at this moment?

jan-kiszka commented 2 years ago

I think the base versions can be froze, yes, but patches will possibly come on top. I'm still waiting for an SE Boot release to move forward with an update, though.

AsuraZeng commented 2 years ago

I think the base versions can be froze, yes, but patches will possibly come on top. I'm still waiting for an SE Boot release to move forward with an update, though. so for the optee would upgrade to 3.16.0 and tf-a would upgrade to 2.6. OK, for this PR, I would drop the optee and tf-a. and we would start to do oss based on the version.

jan-kiszka commented 2 years ago

@AsuraZeng did you check back then whether Node RED still works? I'm currently getting

Mar 17 11:18:36 iot2050-debian node-red[488]: internal/modules/cjs/loader.js:818
Mar 17 11:18:36 iot2050-debian node-red[488]:   throw err;
Mar 17 11:18:36 iot2050-debian node-red[488]:   ^
Mar 17 11:18:36 iot2050-debian node-red[488]: Error: Cannot find module 'express'
Mar 17 11:18:36 iot2050-debian node-red[488]: Require stack:
Mar 17 11:18:36 iot2050-debian node-red[488]: - /usr/lib/node_modules/node-red/red.js
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Function.Module._resolveFilename (internal/modules/cjs/loader.js:815:15)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Function.Module._load (internal/modules/cjs/loader.js:667:27)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Module.require (internal/modules/cjs/loader.js:887:19)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at require (internal/modules/cjs/helpers.js:74:18)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Object.<anonymous> (/usr/lib/node_modules/node-red/red.js:32:15)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Module._compile (internal/modules/cjs/loader.js:999:30)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Module.load (internal/modules/cjs/loader.js:863:32)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Function.Module._load (internal/modules/cjs/loader.js:708:14)
Mar 17 11:18:36 iot2050-debian node-red[488]:     at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:60:12) {
Mar 17 11:18:36 iot2050-debian node-red[488]:   code: 'MODULE_NOT_FOUND',
Mar 17 11:18:36 iot2050-debian node-red[488]:   requireStack: [ '/usr/lib/node_modules/node-red/red.js' ]
Mar 17 11:18:36 iot2050-debian node-red[488]: }
jan-kiszka commented 2 years ago

Found the issue: the nmp-shrinkwarp.json files were wrongly created (missing --global-style) - or you used an npm version that had problems with this way.

Will regenerate everything, but that may mean we will get some newer packages now.

AsuraZeng commented 2 years ago

Found the issue: the nmp-shrinkwarp.json files were wrongly created (missing --global-style) - or you used an npm version that had problems with this way.

Will regenerate everything, but that may mean we will get some newer packages now.

Haven't fully tested.

the method I use is refer :https://github.com/siemens/meta-iot2050/blob/master/classes/npm.bbclass#L6 I think this is a right way, it contains the option --global-style.

But I run a debian image using docker on the x86 machine to create these files.

jan-kiszka commented 2 years ago

I'll check that under Debian 11 as. Currently using nodejs12 under OpenSUSE.

AsuraZeng commented 2 years ago

hi jan

I have reproduced this problem.

lack of some sub module .like express body_parser and so on But they are in the node-red shrink dependencies list

and I have installed the node-red on the latest debian system, it would work and no lack of anything.

I would look into it.

jan-kiszka commented 2 years ago

No need to, I've a working version here again. Will send a PR soon.

AsuraZeng commented 2 years ago

That's very kind．

The problem should be the shrink.json file as express: new shrinkwrap.json node_modules/node-red/node_modules/express old shrinkwrap node_modules/express

the express path seems not correct.

jan-kiszka commented 2 years ago

It's likely npm version related: I can reproduce the issue when using npm 7.5.2 from debian 11. Seems that version is ignoring --global-style. I have 6.14.16 here, and that works. This mode has to be selected via the config file now: npm config set global-style=true.

I'll redo things under Debian with that and check if it changes the setup.