[ET8500] librist issues compiling tsduck - OpenVIX feeds since after Jul 21

[waistcoat]

What type of support thread are you creating?

Possible bug

What OpenViX Image build number are you using?

6.8.010 / 6.9.001

Have you tried re-flashing WITHOUT settings restore?

NO

Have you tried re-flashing WITH a settings restore?

NO

As my reciever is no longer getting pre-built releases, I've been compiling my own since 6.8 was released.

Since after 21-July-26 I haven't been able to cleanly compile OpenVIX feeds as tsduck complains about missing librist headers. In fact this is the last package of tsduck I've managed to cleanly compile without hacks:
Jun 19 00:22 tsduck_3.41-4299-git4367+b1848920+b18489209c-r0_mips32el.ipk

Since I got stuck on 6.8.010 I see we've moved on to 6.9 release with oe branch 6.0, I've managed to get feeds to now compile by manually adding NORIST=1 to meta-oe-alliance/meta-oe/recipes-support/tsduck/tsduck_git.bb.

Anyone else experiencing this buidling for other platforma? Any suggestions? Am I doing something wrong?
As I don't actually use tsduck I'm guessing I could use BBMASK once I figure it out to somehow to not build it at all.

-Steve

ERROR: tsduck-git-r0 do_compile: Execution of '/home/smg/openvix/build-enviroment.x/builds/openvix/release/et8500/tmp/work/mips32el-oe-linux/tsduck/git/temp/run.do_compile.1821075' failed with exit code 1

...

| In file included from /home/smg/openvix/build-enviroment.x/builds/openvix/release/et8500/tmp/work/mips32el-oe-linux/tsduck/git/sources/tsduck-git/src/libtsduck/plugins/private/tsRISTPluginData.h:16,
|                  from plugins/plugins/tsRISTInputPlugin.cpp:10:
| /home/smg/openvix/build-enviroment.x/builds/openvix/release/et8500/tmp/work/mips32el-oe-linux/tsduck/git/sources/tsduck-git/src/libtsduck/network/private/tsLibRIST.h:43:55: error: missing binary operator before token '('
|    43 |     #if LIBRIST_API_VERSION < LIBRIST_MAKE_API_VERSION(4, 2, 0)

...

| In file included from network/tsRIST.cpp:10:
| /home/smg/openvix/build-enviroment.x/builds/openvix/release/et8500/tmp/work/mips32el-oe-linux/tsduck/git/sources/tsduck-git/src/libtsduck/network/private/tsLibRIST.h:39:14: fatal error: librist/librist.h: No such file or directory
|    39 |     #include <librist/librist.h>
|       |              ^~~~~~~~~~~~~~~~~~~
| compilation terminated.
| make[2]: *** [../../Makefile.inc:66: /home/smg/openvix/build-enviroment.x/builds/openvix/release/et8500/tmp/work/mips32el-oe-linux/tsduck/git/sources/tsduck-git/bin/release-mips32el-vpro/objs-libtsduck/tsRIST.o] Error 1

 

[twol]

So amongst other boxes, I build the ET7500 which although simpler than the ET8500 uses similar Mips build, and I have no issues either on OEA 5.6 or 6.0.
So I would suggest you delete the current build directory but keep the sources file and then refresh the OEA 6.0 build —-> open the OEA 6.0 git in terminal and enter “make update“
I have no idea when you last updated your OEA 6.0 build but there have been many updates recently.

 

[birdman]

My build of tsduck for an et8000 on 6.9.002.025 just happens to have got to tsduck, and it's proceeding OK.

Looking at the *.bb file (meta-oe-alliance/meta-oe/recipes-support/tsduck/tsduck_git.bb) it contains:

EXTRA_OEMAKE = "CXXFLAGS_EXTRA=-Wno-maybe-uninitialized \
MAIN_ARCH=${TUNE_PKGARCH} SYSROOT=${D} STRIP=/bin/true \
NOTEST=1 NOPCSC=1 NODTAPI=1 NOSRT=1 NODOC=1 NOVATEK=1 NOPCSTD=1"

 

[waistcoat]

I think the issue occurred after a clean build - just done another one - see what happens in the next several compile hours..

 

[waistcoat]

My build of tsduck for an et8000 on 6.9.002.025 just happens to have got to tsduck, and it's proceeding OK.

Looking at the *.bb file (meta-oe-alliance/meta-oe/recipes-support/tsduck/tsduck_git.bb) it contains:

Yip that's what a clean fetch of the sources contains. Adding NORIST=1 was the only way I could get it to compile. I'm trying again just in case - my laptop is melting as I type .

 

[el bandido]

Deleting the build folder like Twol mentioned in post#2 would probably fix it outright, but is a drastic solution. Deleting the build folder is almost starting over, but you get to retain the sources and a few other things. There would be several ways of solving your problem, with all of them being either right or wrong depending on who was looking at it.

Enigma2 image building can be very rewarding. I have some OpenVix image builds set by cron to automatically run by cron everyday while I am asleep. Usually if there is an image build error, it is sorted in at least a few days. The main thing really is to keep the build updated, so the build script runs make update each time before any building starts.

You may also get the feeds traffic light to work by making a few edits. Keeping all of the customization edits such as outright deleting tsduck or anything else in meta-local will allow you to keep your customization after running make update.

In the eight month of 2026, there exists AI's that can be installed onto your computer, and will build, run, manage, or maintain enigma2 image builds. While this does cost a small amount of money, it solves many image build problems we encounter, plus it gives the potential for a level of customization and support that cannot be found or matched on any FTA forum.

Attached is a guide that could be fed directly into the Claude Code AI or probably Codex, and the expected result would be some questions followed by a complete image build that would be debugged if the build stopped. Might have to play with it a bit, but the thing will build an image and debug any failures, plus customize it. --All for a price.

The attached guide if carefully read shows you how to properly delete tsduck from the build, and the general steps to do that would apply for other things you want to get rid of. The less you build, the faster you build, and the less heat on the laptop or desktop!

There are many different ways to do this image build stuff, with all of them being either right or wrong, depending on who you talk to. Good to see someone putting effort into it!

 

[waistcoat]

Deleting the build folder like Twol mentioned in post#2 would probably fix it outright, but is a drastic solution. Deleting the build folder is almost starting over, but you get to retain the sources and a few other things. There would be several ways of solving your problem, with all of them being either right or wrong depending on who was looking at it.

Enigma2 image building can be very rewarding. I have some OpenVix image builds set by cron to automatically run by cron everyday while I am asleep. Usually if there is an image build error, it is sorted in at least a few days. The main thing really is to keep the build updated, so the build script runs make update each time before any building starts.

You may also get the feeds traffic light to work by making a few edits. Keeping all of the customization edits such as outright deleting tsduck or anything else in meta-local will allow you to keep your customization after running make update.

In the eight month of 2026, there exists AI's that can be installed onto your computer, and will build, run, manage, or maintain enigma2 image builds. While this does cost a small amount of money, it solves many image build problems we encounter, plus it gives the potential for a level of customization and support that cannot be found or matched on any FTA forum.

Attached is a guide that could be fed directly into the Claude Code AI or probably Codex, and the expected result would be some questions followed by a complete image build that would be debugged if the build stopped. Might have to play with it a bit, but the thing will build an image and debug any failures, plus customize it. --All for a price.

The attached guide if carefully read shows you how to properly delete tsduck from the build, and the general steps to do that would apply for other things you want to get rid of. The less you build, the faster you build, and the less heat on the laptop or desktop!

There are many different ways to do this image build stuff, with all of them being either right or wrong, depending on who you talk to. Good to see someone putting effort into it!

This is SO useful.
Looks like tsduck was indeed detecting that I had librist-dev installed on the host build machine and assuming it existed in the cross-compiled systsem resulting in the error. Purging the package means it build correctly again.
I'll see about creating an issue for adding NORIST=1 to the

 

[waistcoat]

Bit rusty, but created a PR and it's been gratefully accepted and merged into oe-alliance-core 6.0. Soon it won'r matter if the host build system has librist-dev installed or not. Thank you everyone.

 

[el bandido]

Excellent!
I would encourage you to continue on beyond "MACHINE=blah blah blah make image" and get some real customization out of it. Enigma2 image customization gets easier everyday, with tools you pay for and tools you do not. For years I wanted an enigma2 Signal finder with Audio feedback so you can "hear" the signal and now I have it. Reward yourself with automation or something nice!

 

[el bandido]

Probably the most delicate part of an enigma2 image build is running make update. Edits done outside of meta-local can turn into a ticking time bomb that causes make update to fail midway and break something else in the process. This is something I never understood for some years and just assumed that after a period of months, the build needed to be abandoned when in fact my on stupidity caused the breakage.

Now when my make update is ran, it has customized checks to ensure all is well and if it breaks everything stops until the problem can be fixed. I found it easier to build an image about everyday instead of waiting for updates to pile up and then sort through the mess. Hence the automated build.

Today I noticed the build did not complete due to an apparent OpenVix enigma2 error. In years past, I would sort through the crash log and spend time figuring out what happened, then fix it. Or simply rebuild everyday until the problem was resolved.

Now I just let the Claude Code AI handle it which gives me time to do other things. Claude Code will find the error, fix it, check the fix for syntax and other errors, build what ever broke and verify it is fixed, write a local commit for a record, then provide a summary. I prefer this method to manually hunting the error.

Today's error was thrown compiling enigma2 and the error source seems to be line 24 of lib/python/python_pmt.i on the Release branch. An edit to meta-local was made and the build for the 3 images completed. Modern tools makes this easy. Now I can move on to something else and not worry about broken image build.

Claude Code Summary
- Root cause: osmini4k (openvix release) failed do_compile on enigma2 6.9+git because upstream OpenViX/enigma2 (Release, commit 2b0a0637) still has one
leftover Python 2 call, PyInt_FromLong, at lib/python/python_pmt.i:24 that was missed when the rest of that file was ported to Python 3.
- Fix: added meta-local/recipes-oe-alliance/enigma2/enigma2/0001-fix-PyInt_FromLong-python3.patch and wired it via SRC_URI:append: openvix in the
existing enigma2.bbappend, scoped to openvix only.
- Verified: ran a real bitbake -c cleansstate enigma2 + bitbake -c compile enigma2 for MACHINE=osmini4k DISTRO=openvix DISTRO_TYPE=release — do_patch
and do_compile both succeeded, and the generated python_pmt.i now shows PyLong_FromLong at line 24.
- Committed locally to build-enviroment (6.0 branch) — not pushed, since our push access is limited to enigma2-tnap.

 

[waistcoat]

Probably the most delicate part of an enigma2 image build is running make update. Edits done outside of meta-local can turn into a ticking time bomb that causes make update to fail midway and break something else in the process. This is something I never understood for some years and just assumed that after a period of months, the build needed to be abandoned when in fact my on stupidity caused the breakage.

Now when my make update is ran, it has customized checks to ensure all is well and if it breaks everything stops until the problem can be fixed. I found it easier to build an image about everyday instead of waiting for updates to pile up and then sort through the mess. Hence the automated build.

Today I noticed the build did not complete due to an apparent OpenVix enigma2 error. In years past, I would sort through the crash log and spend time figuring out what happened, then fix it. Or simply rebuild everyday until the problem was resolved.

Now I just let the Claude Code AI handle it which gives me time to do other things. Claude Code will find the error, fix it, check the fix for syntax and other errors, build what ever broke and verify it is fixed, write a local commit for a record, then provide a summary. I prefer this method to manually hunting the error.

Today's error was thrown compiling enigma2 and the error source seems to be line 24 of lib/python/python_pmt.i on the Release branch. An edit to meta-local was made and the build for the 3 images completed. Modern tools makes this easy. Now I can move on to something else and not worry about broken image build.

Claude Code Summary
- Root cause: osmini4k (openvix release) failed do_compile on enigma2 6.9+git because upstream OpenViX/enigma2 (Release, commit 2b0a0637) still has one
leftover Python 2 call, PyInt_FromLong, at lib/python/python_pmt.i:24 that was missed when the rest of that file was ported to Python 3.
- Fix: added meta-local/recipes-oe-alliance/enigma2/enigma2/0001-fix-PyInt_FromLong-python3.patch and wired it via SRC_URI:append: openvix in the
existing enigma2.bbappend, scoped to openvix only.
- Verified: ran a real bitbake -c cleansstate enigma2 + bitbake -c compile enigma2 for MACHINE=osmini4k DISTRO=openvix DISTRO_TYPE=release — do_patch
and do_compile both succeeded, and the generated python_pmt.i now shows PyLong_FromLong at line 24.
- Committed locally to build-enviroment (6.0 branch) — not pushed, since our push access is limited to enigma2-tnap.

Yes I noticed the breakage in the build yesterday. After a few hours of looking today, I'd worked out that a python2 statement in lib/python/python_pmt.i - PyInt_FromLong is deprecated and replaced by PyLong_FromLong. What change caused this break is beyond me or why it wasn't spotted by the repo/build owners. I suspect an overzealous change 'we don't need the python2 compatability headers anymore' or something like that caused it but I couldn't find it, and that's as far as I'd got before heading to the pub tonight.
I've just tested and the official repos are still borked so will take a look at your fix in a bit - maybe tomorrow as it's passed midnight here atm.
If I get a clean build, I'll see if i can get a PR created for the official repo.
Many thanks,
-Steve

 

[el bandido]

I think you could make a temporary fix by unzipping the attached file and putting it in meta local (meta-local/recipes-oe-alliance). As to why it was not found, there are thousands of files so it is hard if not impossible to catch everything.

 

[waistcoat]

I think you could make a temporary fix by unzipping the attached file and putting it in meta local (meta-local/recipes-oe-alliance). As to why it was not found, there are thousands of files so it is hard if not impossible to catch everything.

I should have gone to bed - just hacked up virtually the same files:

$ find meta-local/recipes-oe-alliance/ -print -type f -exec cat \{\} \;
meta-local/recipes-oe-alliance/
meta-local/recipes-oe-alliance/enigma2
meta-local/recipes-oe-alliance/enigma2/0001-fix-PyInt_FromLong-python3.patch
--- a/lib/python/python_pmt.i    2026-08-19 03:05:12.674451016 +0100
+++ b/lib/python/python_pmt.i    2026-08-19 03:09:11.340093675 +0100
@@ -24 +24 @@ PyObject *eDVBServicePMTHandler::getCaId
-            PyList_SET_ITEM(ret, i, PyInt_FromLong(caids[i]));
+            PyList_SET_ITEM(ret, i, PyLong_FromLong(caids[i]));
meta-local/recipes-oe-alliance/enigma2/enigma2.bbappend
FILESEXTRAPATHS:prepend := "${THISDIR}:"
SRC_URI += "file://0001-fix-PyInt_FromLong-python3.patch"

Thank you - my laptop is trying to do a build - I'll leave it going - time to sleep for now.
-Steve

 

[twol]

@el bandido - thanks
I made all these changes many years ago now (whilst in hospital!), but not sure why I missed this change.
Also I built all day yesterday across architectures without problem, so surprised it caused an issue as its also mapped PyInt_FromLong to PyLong_FromLong in another python module.
Commit done.