Unable to build non-devel quarterly 5.1.0 minimal for iMX7D

According to NONWORKING repo init examples here

I should repo init -b dunfell-5.x.y -m tdxref/default.xml then repo init -b refs/tags/5.1.0 -m tdxref/default.xml to switch to specific tag. Which is 5.1.0 in my case. Even starting in empty folder and missing -u https://git.toradex.com/toradex-manifest.git I still am getting -devel-

Build Configuration:
BB_VERSION           = "1.46.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-20.04"
TARGET_SYS           = "arm-tdx-linux-gnueabi"
MACHINE              = "colibri-imx7"
DISTRO               = "tdx-xwayland"
DISTRO_VERSION       = "5.1.0-devel-20210219112118+build.0"
TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard"
TARGET_FPU           = "hard"
meta-toradex-nxp     = "HEAD:8e762e3c8ec5c84f76254f442f37c70dfb7e1b68"
meta-freescale       = "HEAD:46f54fdc5ad854a22bf759aac7fd65db1d1bb574"
meta-freescale-3rdparty = "HEAD:05b1746a4adc240b690fe965ac5b8a043d9b9d03"
meta-toradex-tegra   = "HEAD:b214067b27204f471cf405a1e3997d3da233a8f9"
meta-toradex-bsp-common = "HEAD:cdbfe017be9096adbbfb4d3bbea0421e44f54cf3"

How to get rid of -devel- and build 5.1.0?

Just change DISTRO_VERSION to your liking. It gets automatically set to a non-devel value by our automated CI/CD infrastructure when we do official builds. By default, it has the -devel as you or me doing their “own” builds will obviously not be an “official” build. OK?

Thank you, @marcel.tx

That’s not very OK.

  1. I’ve got more than single question here why I’m using not official image or something. For me it doesn’t matter a lot how is it called, -devel- or not devel. But it takes time later to reply additional questions why it is not TDX build image. But that’s OK.
  2. It would be nice to have somehow visualized that hours taking build process is performed on the right version. As you may see here 5.1.0 release date is 2020-12-30. No signs of that in resulting images /etc/issue or in the Build configuration. How to determine I’m on the right track? How to determine later specific module was build around specific BSP. Quite big problem.

Regards,
Edward

That’s not very OK. 1) I’ve got more than single question here why I’m using not official image or something.

I do not understand what exactly you are after. With OpenEmbedded/Yocto Project you build your own images and it is ultimately your responsibility what exactly you build and do with it.

For me it doesn’t matter a lot how is it called, -devel- or not devel. But it takes time later to reply additional questions why it is not TDX build image. But that’s OK.

I guess if you are after a binary distribution then you should have a look at Torizon:

With OpenEmbedded/Yocto Project it is really your very own responsibility to customise/build images.

  1. It would be nice to have somehow visualized that hours taking build process is performed on the right version.

Well, those layer hashes tell you exactly that. What else are you looking for?

As you may see here 5.1.0 release date is 2020-12-30.

Yes, that is when we did our build thereof.

No signs of that in resulting images /etc/issue or in the Build configuration. How to determine I’m on the right track?

Sorry, but you really do have to check this using them hashes.

How to determine later specific module was build around specific BSP. Quite big problem.

Well, it is your very own custom image that is built so yes, you should better know what you built!

I do not understand what exactly you are after. With OpenEmbedded/Yocto Project you build your own images and it is ultimately your responsibility what exactly you build and do with it.

Yocto is very complicated thing. I want just some small indication I’m building exactly what I want. But there’s no clear feed back for it. Build instructions on toradex.com are not exact. We need to deduce missing command switches etc… After all missing parts are added I still am not sure I’m building the right thing.
Perhaps Torizon is right way to go, I’m too busy at the moment to learn it and to switch to it.

Well, those layer hashes tell you exactly that. What else are you looking for?

OK, hashes could be fine. But they aren’t listed for example here . Could you point me were to look for them? I don’t know either how to decipher right hashes from git.toradex.com.

Regards, Edward

Yocto is very complicated thing.

I somewhat agree, but there is not much we as Toradex can change about that. One basically has to go through the learning curve one way or another…

I want just some small indication I’m building exactly what I want. But there’s no clear feed back for it. Build instructions on toradex.com are not exact.

Such a claim would need to back with some more concrete facts. So far most customers, at least ones experienced with OpenEmbedded/Yocto Project, are quite happy with our documentation.

We need to deduce missing command switches etc… After all missing parts are added I still am not sure I’m building the right thing. Perhaps Torizon is right way to go, I’m too busy at the moment to learn it and to switch to it.

I would assume learning “Torizon” would be much simpler than learning OpenEmbedded/Yocto Project.

OK, hashes could be fine. But they aren’t listed for example here. Could you point me were to look for them? I don’t know either how to decipher right hashes from git.toradex.com.

Well, you would need to start with the manifest here:

https://git.toradex.com/cgit/toradex-manifest.git/tree/tdxref/default.xml?h=5.1.0

And then follow its include files:

https://git.toradex.com/cgit/toradex-manifest.git/tree/base/pinned.xml?h=5.1.0

https://git.toradex.com/cgit/toradex-manifest.git/tree/bsp/pinned-nxp.xml?h=5.1.0

https://git.toradex.com/cgit/toradex-manifest.git/tree/bsp/pinned-tdx.xml?h=5.1.0

It’s not that complicated, is it?

Good luck!

Hi @Edward

Is your issue solved?

Best regards,
Jaski

Hi @jaski.tx ,

yes, it is. I don’t see how I could mark it solved.

Regards,

Edward

Build instructions on toradex.com are not exact.
Such a claim would need to back with some more concrete facts. So far most customers, at least ones experienced with OpenEmbedded/Yocto Project, are quite happy with our documentation.

Usually I’m fine with your documentation and thank you very much for TDX efforts. But often it is hard to find something, even if I saw it once or twice. Regarding incomplete instructions see my first message above. Url and two incomplete repo init commands. They just aren’t working without -u switch. I’d love to see complete instruction how to rebuild 5.0.0, 5.1.0 etc… Could be a pattern 5.x.0, but working example please. And again, since it didn’t seem to work to produce non-devel 5.1.0, here we have whole thread about why it is so.

Regarding Torizon. Well, do you really think I won’t need to spent many days or weeks moving ready product from Yocto to Torizon? I really doubt it.

Thanks for pointing to right xml’s. I see now what to compare. It would be nice to see just meta-toradex-distro hash listed here next to BSP release version.

Thanks for the response. I closed the question.