Posted 1 August 2021 - 13:34
Not to mention the pile of BSP that fall over on each OE upgrade. If it's not immediately (during build), then it will happen during runtime (crashing...).
After the last time we upgraded (to Zeus), we still can't have fixed all issues, apparently this is an issue with libc that breaks our filepush code.
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Posted 1 August 2021 - 14:56
libc issues might be solved, some fixes have been backported by @rantanplan, builds with this fix are currently running (but will takes days, as a new libc means everything will be rebuild again).
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 2 August 2021 - 13:38
Since a few days the new operator syntax in master-next rises new parsing errors.
Expected...
As for the .bbappends I have done some tests with OE/Yocto releases starting from dunfell up to master-next of mid-July.
The list remains basically the same, only a few additions: this means that moving meta-openpli zeus->dunfell or zeus->hardknott will take the same efforts.
As for the BSP layers, well, this must be tested of course.
I don't expect breakages, mipsel was ok with gcc 10 and 11 and arm is surely more tested/maintained.
I'd say we could first go to dunfell LTS (or even hardknott/gcc10) for 8.2 and maybe target honister/gcc11/new override operator for 8.3.
There isn't any runtime change, I wouldn't say a 9.x is worth.
Cheers
A.A.
Posted 2 August 2021 - 16:02
We never change OE on minor releases.
What do you mean by "runtime change"? Every OE upgrade until now has given us unexpected suprises, so don't underestimate the work. Think for example about
Sometimes the changes are subtle and only found when testing, like Enigma parsing some command output, and the layout has changed causing the parsing to fail...
My gut feeling is:
I can setup a branch for it and give you access to it?
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 2 August 2021 - 17:02
We never change OE on minor releases.
What do you mean by "runtime change"? Every OE upgrade until now has given us unexpected suprises, so don't underestimate the work. Think for example about
Sometimes the changes are subtle and only found when testing, like Enigma parsing some command output, and the layout has changed causing the parsing to fail...
My gut feeling is:
- aim for Hardknott, not Dunfell
- create a "hardknott" branch from develop so the work doesn't impact the current develop branch
- when we feel the "hardknott" branch is ready, release 8.2 from develop
- merge the "hardknott" branch into develop to prepare for 9.0 (will probably need Enigma tweaks)
I can setup a branch for it and give you access to it?
I didn't express my self properly again 
For runtime changes I mean user-side necessaries changes (new protocols, new layout, etc.) and from the user POV runtime = enigma2.
I know there are underlying changes (samba, openssl, openssh, etc, etc) but this mostly is hidden for the user.
My point is that for future maintenance the OpenPLi project should adhere as much as possible to the actual Openembedded framework.
Having few developers means that the maintenance burden is really high, as is the risk of abandon/bitrot (same is for OpenEmbedded unfortunately but this would be another topic).
I have a bit of time in the next weeks so yes, I'll start to move the .bbappends to hardknott.
If you think please create a -next branch for us developers to fork.
We will fix separately the .bbappends and merge back with pull requests.
Thanks
A.A.
Posted 2 August 2021 - 17:12
Ok, clear. 
I'll call the branch "hardknott" if you don't mind, our "automated" build system doesn't like dashes or underscores in branch names...
You're sure you don't want push access on that branch? That would save me time pressing "merge" buttons...
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 2 August 2021 - 21:48
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 22 August 2021 - 13:15
I have a longstanding issue I want to discuss. We have these "image" recipes:
openpli-enigma2-feed.bb openpli-enigma2-image.bb openpli-image.bb
Why are there three? I'd suppose two is enough (everything that needs to be in the image and the rest in the feeds). Is this following good OE practise, I bet not?
Are there other things not following good OE practise? I often see OE examples where the directory structure is significantly different to ours.
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Posted 22 August 2021 - 14:23
I think most homebuilders only want to build the image, and not the feeds? Not sure about the history, long before "my time"...
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 23 August 2021 - 18:53
I can imagine that, but why would you need three bb files then? I guess two would suffice (which you'd anyway). Note that all of them are used for building our image, not just two of them.
* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.
Posted 23 August 2021 - 18:54
No idea, I haven't looked at it in detail, currently busy in trying to figure out why some shared feed packages are build multiple times.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
Posted 24 August 2021 - 15:02
I'll see if I can catch that with bitbake-diffsigs or with sstate-diff-machines.sh
Posted 24 August 2021 - 15:04
Back on topic we'll have to update bitbake to latest 1.50 to support both formats for the overrides.
https://git.openembe...ake/log/?h=1.50
atm we lack the two topmost commits
0 members, 1 guests, 0 anonymous users
