OpenViX build for Beyonwiz

[IanSav]

Hi Prl,

It may be useful to have a devel copy of OpenViX. In fact I have already had an offer of becoming an OpenViX developer (from RobvanderDoes IIRC). I don't really want to become an OpenViX developer, but sometimes it would be useful to offer changes upstream.

Unfortunately Rob is no longer an active OpenViX developer. I can supply you with an OpenViX 5.0 T3 development image if you like.

Regards,
Ian.

[prl]

Thanks, Ian.

Does the image include a build toolchain for enigma2? Or is that what it means?

[IanSav]

Hi Prl,

Does the image include a build toolchain for enigma2? Or is that what it means?

This image is just a standard firmware image, ready to install and run on a Beyonwiz T3. (I will need Internet access to update itself to the latest development version.)

I also have access to the build instruction notes on the OpenViX developers forum created to help a Beyonwiz user, more knowledgeable than myself, to build their own images. I have extracted those notes and tools for your reference.

EDIT: I just realised that the notes were created for OpenViX 4.2 but I think they should transfer to OpenViX 5.0.

Regards,
Ian.

[prl]

Hi Prl,

Does the image include a build toolchain for enigma2? Or is that what it means?

This image is just a standard firmware image, ready to install and run on a Beyonwiz T3. (I will need Internet access to update itself to the latest development version.)

OK, that image That would be good. My devel machines have Internet access. Hard to do much without it.

I also have access to the build instruction notes on the OpenViX developers forum created to help a Beyonwiz user, more knowledgeable than myself, to build their own images. I have extracted those notes and tools for your reference.

EDIT: I just realised that the notes were created for OpenViX 4.2 but I think they should transfer to OpenViX 5.0.
...

Thanks, that would be very useful. I'd have never been able to work out the configure incantation for the Beyonwiz enigma2 build without peteru's help.

[IanSav]

Hi Prl,

I have a 75MB care package ready for you. What is the best way to get it to you?

Regards,
Ian.

[prl]

...
I have a 75MB care package ready for you. What is the best way to get it to you?
...

Thanks.

Do you have a file hosting service account I can download it from? I can PM you my email address for you to send me a download link if you have.

[IanSav]

Hi Prl,

Do you have a file hosting service account I can download it from? I can PM you my email address for you to send me a download link if you have.

Can you read 256 bit AES ZIP files?

Confirm your ability to read an encrypted ZIP file and send me your E-Mail details and I will send you a link to the file via one method and the password via another.

Regards,
Ian.

[prl]

Hi Prl,

Do you have a file hosting service account I can download it from? I can PM you my email address for you to send me a download link if you have.

Can you read 256 bit AES ZIP files?

I have no idea, but I rather doubt it. We could try initially with a small file thet you could just email me as an attachment.

[IanSav]

Hi Prl,

I have attached a file for you to test. The password is "Password".

Regards,
Ian.

[prl]

I'll give it a go in the morning.

[prl]

Hi, IanSav.

I've at last got around to try to build OpenVix using the Care Package instructions. I get to the step:

MACHINE=vusolo2 DISTRO=openvix DISTRO_TYPE=developer make image

which I re-write as:

MACHINE=beyonwizt3 DISTRO=openvix DISTRO_TYPE=developer make image

That grinds away for a while, then dies with:

Code: Select all

ERROR: ExpansionError during parsing /home/prl/3.4/meta-oe-alliance/meta-brands/meta-vuplus/recipes-bsp/vuplus-opera-dumpait.bb: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command export PATH="/home/prl/3.4/openembedded-core/scripts:/home/prl/3.4/builds/openvix/developer/inihdx/tmp/sysroots/x86_64-linux/usr/bin/mipsel-oe-linux:/home/prl/3.4/builds/openvix/developer/inihdx/tmp/sysroots/inihdx/usr/bin/crossscripts:/home/prl/3.4/builds/openvix/developer/inihdx/tmp/sysroots/x86_64-linux/usr/sbin:/home/prl/3.4/builds/openvix/developer/inihdx/tmp/sysroots/x86_64-linux/usr/bin:/home/prl/3.4/builds/openvix/developer/inihdx/tmp/sysroots/x86_64-linux/sbin:/home/prl/3.4/builds/openvix/developer/inihdx/tmp/sysroots/x86_64-linux/bin:/home/prl/3.4/openembedded-core/scripts:/home/prl/3.4/bitbake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin"; export HOME="/home/prl"; git -c core.fsyncobjectfiles=0 ls-remote http://code.vuplus.com/git/dumpait.git  could not be run:
[Errno 12] Cannot allocate memory
WARNING: Unable to get checksum for odin-backup SRC_URI entry odin-backup.sh: file could not be found

Summary: There were 24 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
Makefile:753: recipe for target 'image' failed
make: *** [image] Error 1

Could you ask the OpenViX folk for suggestions? I tried doubling my VM's memory space from 1GB to 2GB (I only have 4GB altogether), but that didn't help. It looks like the git command is dying.

[peteru]

I don't think 2GB RAM will work for builds with more than one concurrent job. Even then, it may be a tight squeeze. If you recall a couple of years ago I was building on my laptop with 4GB RAM + 8GB swap and it was struggling with only two concurrent jobs. Also, make sure that you are running in 64-bit mode. It's conceivable that you are getting that error because you are running out of address space.

[prl]

I don't think 2GB RAM will work for builds with more than one concurrent job. Even then, it may be a tight squeeze. If you recall a couple of years ago I was building on my laptop with 4GB RAM + 8GB swap and it was struggling with only two concurrent jobs.

I've cut the make down to a single job and I've cut BB_THREADS to 4 and started a new run. I'll see how that goes.

The site.conf file is now:

Code: Select all

SCONF_VERSION = "1"
#BB_NUMBER_THREADS = "8"
#PARALLEL_MAKE = "-j 2"
BB_NUMBER_THREADS = "4"
PARALLEL_MAKE = "-j 1"
BUILD_OPTIMIZATION = "-march=native -O2 -pipe"
DL_DIR = "/home/prl/3.4/sources"
INHERIT += "rm_work"

Also, make sure that you are running in 64-bit mode. It's conceivable that you are getting that error because you are running out of address space.

How do I tell? The VirtualBox control panel says I'm running Ubuntu (64-bit).

/proc/cpuinfo says:
address sizes : 36 bits physical, 48 bits virtual

I can't find anything that looks definitive in /proc/meminfo.

[prl]

Thanks, that seems to have fixed the problem. It's now getting on and seems to be compiling stuff.

[peteru]

BB_NUMBER_THREADS = "4" is quite optimistic. It'll probably work for a big chunk of the build, but unless you have 4 cores (not just 4 threads), it won't make things any faster, just create more RAM stress. There are a few instances where the GCC optimiser can gobble up huge amounts of memory to deal with some code and it's likely that when you hit those bumps, your build could derail.

It sounds like you are running in 64-bit mode so that's good. How many cores have you allocated to the VM?

BB_NUMBER_THREADS * PARALLEL_MAKE should not really be any larger than the number of threads available. Given the age of your CPU, I'd probably recommend that you actually keep that number to the number of cores, rather than threads.

[prl]

... How many cores have you allocated to the VM?

The VirtualBox control settings only allow me to allocate CPUs (but I expect its simply not distinguishing between cores and full CPUs). I have allocated 1 CPU. My (rather aged) MacBook Pro has an Intel Core 2 Duo (Penryn P8700) which Wikipedia lists as 2 cores.

BB_NUMBER_THREADS * PARALLEL_MAKE should not really be any larger than the number of threads available. Given the age of your CPU, I'd probably recommend that you actually keep that number to the number of cores, rather than threads.

The run's still trundling along, and it'll be a while (currently "Running task 200 of 10726"). I'll adjust the parameters when it finishes.

[prl]

It got about a third of the way through, then died with a bunch of failed fetches (grepped from the log):

Code: Select all

ERROR: util-macros-native-1_1.19.0-r0 do_fetch: Fetcher failure: Fetch command failed with exit code 4, output:
ERROR: util-macros-native-1_1.19.0-r0 do_fetch: Function failed: Fetcher failure for URL: 'http://xorg.freedesktop.org/releases/individual/util/util-macros-1.19.0.tar.gz'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/prl/3.4/builds/openvix/developer/inihdx/tmp/work/x86_64-linux/util-macros-native/util-macros-native-1_1.19.0-r0/temp/log.do_fetch.22519
ERROR: Task 3920 (virtual:native:/home/prl/3.4/openembedded-core/meta/recipes-graphics/xorg-util/util-macros_1.19.0.bb, do_fetch) failed with exit code '1'
ERROR: xproto-native-1_7.0.28-r0 do_fetch: Fetcher failure: Fetch command failed with exit code 4, output:
ERROR: xproto-native-1_7.0.28-r0 do_fetch: Function failed: Fetcher failure for URL: 'http://xorg.freedesktop.org/releases/individual/proto/xproto-7.0.28.tar.bz2'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/prl/3.4/builds/openvix/developer/inihdx/tmp/work/x86_64-linux/xproto-native/xproto-native-1_7.0.28-r0/temp/log.do_fetch.25481
ERROR: Task 3910 (virtual:native:/home/prl/3.4/openembedded-core/meta/recipes-graphics/xorg-proto/xproto_7.0.28.bb, do_fetch) failed with exit code '1'
Summary: There were 4 ERROR messages shown, returning a non-zero exit code.

[peteru]

Welcome to the joy of building firmware distributions! It's a lot of work and it requires quite a bit of infrastructure.

Try restarting the build in case this was a temporary glitch. If that doesn't fix it, look at the origin URL to determine if the package is still available. You'll have to keep your build environment up to date by doing frequent pulls on the top level build environment repo and any submodules. If you are trying to build from a snapshot that is older than about a week or two, you are not going to get very far.

[prl]

... snapshot ....

Jargon query: What's a snapshot?

[prl]

... Try restarting the build in case this was a temporary glitch. ...

Looks like it might be temporary. I was just able to fetch the two files manually using curl on both my OS X host and on the Ubuntu guest where the build is actually being done.

Just been reminded that using the word curl gets you put in LiteSpeed's naughty corner...

[MrQuade]

Now with its own thread, and a slightly off topic comment. I wonder if this Vix package will build under Windows as well . I image that it is a good deal more involved than a simple T series binary build.
Anyway, that's probably a side project for IanSav given the Vix code was only intended for limited distribution from what I gather .

[IanSav]

Hi MrQuade,

Now with its own thread, and a slightly off topic comment. I wonder if this Vix package will build under Windows as well . I image that it is a good deal more involved than a simple T series binary build.

It isn't meant to be any more complicated.

Anyway, that's probably a side project for IanSav given the Vix code was only intended for limited distribution from what I gather .

At the moment it is on restricted release. If discussions between Jai and the OpenViX backers go well this might change.

I am waiting for my new main development PCs to get the Creators Update. So far only my notebook running the Home edition has been allowed to update. I want to run the development on my beefier Windows 10 Pro system.

Regards,
Ian.

[prl]

OK, I got a bit further, to where it looks like it's checking that all the required packages have been created:

| configure: error: Package requirements (freetype2 fribidi gstreamer-1.0 gstreamer-pbutils-1.0 libdvbsi++ libpng libxml-2.0 sigc++-2.0 libssl libcrypto) were not met:
|
| No package 'sigc++-2.0' found
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
| Alternatively, you may set the environment variables BASE_CFLAGS
| and BASE_LIBS to avoid the need to call pkg-config.
| See the pkg-config man page for more details.
| NOTE: The following config.log files may provide further information.
| WARNING: /home/prl/3.4/builds/openvix/developer/inihdx/tmp/work/beyonwizt3-oe-linux/enigma2/enigma2-5.3+gitAUTOINC+06771cebc6-r4/temp/run.do_configure.1796:1
exit 1 from 'exit 1'
| NOTE: /home/prl/3.4/builds/openvix/developer/inihdx/tmp/work/beyonwizt3-oe-linux/enigma2/enigma2-5.3+gitAUTOINC+06771cebc6-r4/git/config.log
| ERROR: configure failed

The .../config.log file above doesn't seem to contain any additional useful information, but here it is:

configure:18776: $PKG_CONFIG --exists --print-errors "freetype2 fribidi gstreamer-$GST_MAJORMINOR gstreamer-pbutils-$GST_MAJORMINOR libdvbsi++ libpng libxml-2.0 sigc++-2.0 libssl libcrypto"
Package sigc++-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `sigc++-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sigc++-2.0' found
configure:18779: $? = 1
configure:18793: $PKG_CONFIG --exists --print-errors "freetype2 fribidi gstreamer-$GST_MAJORMINOR gstreamer-pbutils-$GST_MAJORMINOR libdvbsi++ libpng libxml-2.0 sigc++-2.0 libssl libcrypto"
Package sigc++-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `sigc++-2.0.pc' to the PKG_CONFIG_PATH environment variable
No package 'sigc++-2.0' found
configure:18796: $? = 1
configure:18810: result: no
No package 'sigc++-2.0' found
configure:18826: error: Package requirements (freetype2 fribidi gstreamer-1.0 gstreamer-pbutils-1.0 libdvbsi++ libpng libxml-2.0 sigc++-2.0 libssl libcrypto) were not met:
No package 'sigc++-2.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables BASE_CFLAGS
and BASE_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

Earlier, it looks like libsigc++-2.0 was created:

NOTE: Running task 1871 of 10726 (ID: 10639, /home/prl/3.4/meta-openembedded/meta-oe/recipes-core/libsigc++-2.0/libsigc++-2.0_2.2.11.bb, do_fetch)
NOTE: recipe libsigc++-2.0-2.2.11-r0: task do_fetch: Started
NOTE: recipe libsigc++-2.0-2.2.11-r0: task do_fetch: Succeeded
NOTE: Running task 1872 of 10726 (ID: 10635, /home/prl/3.4/meta-openembedded/meta-oe/recipes-core/libsigc++-2.0/libsigc++-2.0_2.2.11.bb, do_unpack)
NOTE: recipe libsigc++-2.0-2.2.11-r0: task do_unpack: Started
NOTE: recipe libsigc++-2.0-2.2.11-r0: task do_unpack: Succeeded
NOTE: Running task 1873 of 10726 (ID: 10636, /home/prl/3.4/meta-openembedded/meta-oe/recipes-core/libsigc++-2.0/libsigc++-2.0_2.2.11.bb, do_patch)
NOTE: recipe libsigc++-2.0-2.2.11-r0: task do_patch: Started
NOTE: recipe libsigc++-2.0-2.2.11-r0: task do_patch: Succeeded
NOTE: Running task 1874 of 10726 (ID: 10642, /home/prl/3.4/meta-openembedded/meta-oe/recipes-core/libsigc++-2.0/libsigc++-2.0_2.2.11.bb, do_populate_lic)
NOTE: recipe libsigc++-2.0-2.2.11-r0: task do_populate_lic: Started
NOTE: recipe libsigc++-2.0-2.2.11-r0: task do_populate_lic: Succeeded

But what's package sigc++-2.0?

Quotes used instead of code blocks because code blocks are now broken

[IanSav]

Hi Prl,

The switch to libsigc++ 2.0 appears to have created some issues for some in OpenViX. Please see
https://github.com/OpenViX/enigma2/comm ... 1b083fff2c.

Regards,
Ian.

[prl]

...
The switch to libsigc++ 2.0 appears to have created some issues for some in OpenViX. Please see
https://github.com/OpenViX/enigma2/comm ... 1b083fff2c.
...

Thanks, I'll have a look at it tomorrow.

[peteru]

I don't know what IanSav made available for you, but it seems it's an old snapshot (i.e. a working copy of someone's working tree)

You'd be better off just cloning the oe-a "build-enviroment" (sic) repo and building your own current distro.

There's nothing special about OpenViX if you are going to follow the public development branch.

[prl]

...
There's nothing special about OpenViX if you are going to follow the public development branch.

OK, I'll give that a go.

[prl]

OK, I started a build using the oe-alliance build-enviroment, and when I start "make image", I get:

Code: Select all

prl@Cambyses-Ubuntu:~/openvix/build-enviroment$ ./do_make 2>&1 | tee make.log.2
check internet connection: Online      
Please use a locale setting which supports utf-8.
Python can't change the filesystem locale after loading so we need a utf-8 when python starts or things won't work.
Makefile:787: recipe for target 'image' failed
make: *** [image] Error 1
prl@Cambyses-Ubuntu:~/openvix/build-enviroment$

Code: Select all

prl@Cambyses-Ubuntu:~/openvix/build-enviroment$ locale
LANG=en_AU.UTF-8
LANGUAGE=en_AU:en
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_PAPER="C"
LC_NAME="C"
LC_ADDRESS="C"
LC_TELEPHONE="C"
LC_MEASUREMENT="C"
LC_IDENTIFICATION="C"
LC_ALL=C
prl@Cambyses-Ubuntu:~/openvix/build-enviroment$

It looks like the LANG setting should be one that supports UTF-8.

I have similar locale issues when I try to run Gnome Terminal, and I haven't been able to resolve them, either. Syslog:

Code: Select all

May  2 12:45:00 Cambyses-Ubuntu org.gnome.Terminal[1625]: Non UTF-8 locale (ANSI_X3.4-1968) is not supported!

[IanSav]

Hi,

It appears that the Creators Edition update for Windows 10 is broken and has been withdrawn from the auto updates. That explains why the rest of my new PCs aren't seeing the update even though it can manually be downloaded.

I intend to wait until the update is fixed before attempting an install. BASH for Windows can't be updated from version 14 to version 16 without the Creators Edition. I will try an update and Enigma2 build when things settle.

Regards,
Ian.

[MrQuade]

It appears that the Creators Edition update for Windows 10 is broken and has been withdrawn from the auto updates. That explains why the rest of my new PCs aren't seeing the update even though it can manually be downloaded.

It may come to you yet. From what I understand, Microsoft is witholding the update from PCs that it has detected may be vulnerable to some known issues/limitations. They recommend not downloading the manual updater and instead waiting until the auto-updater decides all is clear. I think most of the issues centre around WiFi/Bluetooth connectivity issues.

My PC received the update somewhat early in the piece, but my wife's PC (of a similar spec) only received the update on Sunday evening. (I did manually initiate the update on my HTPC, but only because I wanted to control the process and didn't want any surprises when I wanted to watch a movie).

You may find that your PC is just at the end of a long rollout queue.

[peteru]

Working 4.4 and 16.1 build system:

Code: Select all

$ locale
LANG=en_AU
LC_CTYPE="en_AU"
LC_NUMERIC=en_AU.UTF-8
LC_TIME=C
LC_COLLATE=en_AU.UTF-8
LC_MONETARY=en_AU.UTF-8
LC_MESSAGES="en_AU"
LC_PAPER="en_AU"
LC_NAME="en_AU"
LC_ADDRESS="en_AU"
LC_TELEPHONE="en_AU"
LC_MEASUREMENT=en_AU.UTF-8
LC_IDENTIFICATION="en_AU"
LC_ALL=

Working 17.1 build system:

Code: Select all

$ locale
LANG=en_AU.utf8
LC_CTYPE="en_AU.utf8"
LC_NUMERIC=en_AU.UTF-8
LC_TIME=C
LC_COLLATE=en_AU.UTF-8
LC_MONETARY=en_AU.UTF-8
LC_MESSAGES="en_AU.utf8"
LC_PAPER="en_AU.utf8"
LC_NAME="en_AU.utf8"
LC_ADDRESS="en_AU.utf8"
LC_TELEPHONE="en_AU.utf8"
LC_MEASUREMENT=en_AU.UTF-8
LC_IDENTIFICATION="en_AU.utf8"
LC_ALL=

Yes, it's all over the place. I blame the braindead user interface that KDE Plasma 5 has adopted. However, it works.

[prl]

OK, thanks. I'll give it a go. What are 4.4, 16.1 and 17.1 the version numbers of, exactly?

[peteru]

What are 4.4, 16.1 and 17.1 the version numbers of, exactly?

Those are the version numbers that I assigned to particular release lines of the firmware. It's effectively an attempt at reducing the number of moving targets in the build system and separating the feeds from each other.

If you like, you can think of these as feed versions.

[peteru]

Oh, it just occurred to me that you may need to play with locale.gen(5) to get the right locales generated. Here's a copy of my /etc/locale.gen

Code: Select all

en_AU ISO-8859-1
en_AU.UTF-8 UTF-8
en_US ISO-8859-1
en_US.UTF-8 UTF-8

[prl]

Thanks.

[prl]

I have a build running now using peteru's suggestion of using the OE-Alliance build environment. It hasn't got all that far yet, but I'll see how it goes.

[prl]

Two days later and the build has finished and I'm running the build of the OpenViX devel branch on a test T3.

So why the secrecy about building OpenViX when it can be done from publicly available sources by someone with only a fairly rudimentary understanding of the build process?

[prl]

OK, so now I've got this far, how do I use build-enviroment to let me modify the C++ source and compile enigma2?

I've found sources/git2_github.com.OpenViX.enigma2.git.tar.gz, but I don't know what to do with it.

[IanSav]

Hi Prl,

So why the secrecy about building OpenViX when it can be done from publicly available sources by someone with only a fairly rudimentary understanding of the build process?

The secrecy about the Beyonwiz build only applies to the work by OpenViX devs and forums of OpenViX which are run by a company with financial stakes in the boxes that are allowed to be discussed on those forums.

Anything made from the open source should be fine. If you didn't use any of the private data provided by the OpenViX team then the build should be fine. Discussion about your effort here on the Beyonwiz forums should also be fine.

Regards,
Ian.

[Huevos]

Could you ask the OpenViX folk for suggestions? I tried doubling my VM's memory space from 1GB to 2GB (I only have 4GB altogether), but that didn't help. It looks like the git command is dying.

You are building from the wrong core branch. Currently we are using branch 4.0...

git clone https://github.com/oe-alliance/build-enviroment.git -b 4.0 5.0
cd 5.0
make init

If you move your sources folder to /prl and edit site.conf you won't have to download them all over again.

[prl]

Could you ask the OpenViX folk for suggestions? I tried doubling my VM's memory space from 1GB to 2GB (I only have 4GB altogether), but that didn't help. It looks like the git command is dying.

You are building from the wrong core branch. Currently we are using branch 4.0...

git clone https://github.com/oe-alliance/build-enviroment.git -b 4.0 5.0
cd 5.0
make init

If you move your sources folder to /prl and edit site.conf you won't have to download them all over again.

Thanks, Huevos, but that seems to be a fix to a different problem.

When I run "build image" for OpenViX in either of the 3.4 and 4.0 build environments, I get the "out of memory" error on the first run. If I re-run "build image" on either, the build proceeds provided I only use one bitbake thread and one make job (I'm doing the build on an oldish and rather under-powered MacBook Pro). The error looks like a name expansion in a bitbake recipe that perhaps goes into infinite recursion. It seems that some part of the build state is affected by the failed task, and that change allows the substitution to work in subsequent runs. But I haven't really investigated the cause in any detail.

However, moving from the 3.4 to the 4.0 build environment does fix the problem of the build exiting because of an apparently incorrect test of whether libsigc++-2.0 has been built. That prevents a build using 3.4 from proceeding, but a build using 4.0 runs to completion on my setup.

[prl]

...
Anything made from the open source should be fine. If you didn't use any of the private data provided by the OpenViX team then the build should be fine. Discussion about your effort here on the Beyonwiz forums should also be fine.
...

My successful build using the OE build environment didn't use any data from the OpenViX "Care Package", but it's questionable whether the data in it is of all that much use:

• Both the "Care Package" and the OE build environments have a memory issue on their first run on my setup. That problem seems to go away if I limit the number of make jobs and number of bitbake threads to 1 each and re-run the "make image". The default OE build environment sets those to the correct values; the "Care Package" defaults them to values that are too large for my setup.
• The "Care Package" contains a build environment that's too old to build the current OpenViX devel branch. The current OE build environment builds OpenViX correctly. That difference may be why some people are reporting in the OpenViX repository being able to build the devel branch after it was switched to use libsigc++-2.0 and some are not.
• The "Care Package" contains three additional packages that should be moved to the sources directory early in the build. I didn't use those packages in my build using the OE build environment. The consequences were:
  • There were 2 related packages in the "Care Package" that were required for the "Care Package" build. Their absence in the "sources" directory in the OE Alliance build meant that the build fetched binary versions of the packages. That generated a warning saying that one of the binaries had had its debug information stripped from its symbol table, but otherwise the build proceeded unaffected
  • The other package in the "Care Package" implements an OpenViX function, probably as a plugin. Its absence in the sources directory during the OE Alliance build didn't affect the build. The package name was not mentioned in the build log. It would be pretty obvious what function was missing when the build is run, and presumably it would not be hard to find the missing package and add it to the build. I don't have any need to do that for what I currently want to do, so I probably won't bother.
• The "Care Package" contains instructions about how to do a build of just the enigma2 binary, which would be very useful to me (I haven't tried it yet), but it isn't really pertinent to the question of whether there's much difficulty in building an OpenViX image from purely public data.

So, all, up I think I can stick by my statement that OpenViX can be built entirely from public sources by someone with only a fairly rudimentary knowledge of the build environment, which still makes the secrecy surrounding both much of the "Care Package" and the Beyonwiz devel version of OpenViX puzzling.

[IanSav]

Hi Prl,

So, all, up I think I can stick by my statement that OpenViX can be built entirely from public sources by someone with only a fairly rudimentary knowledge of the build environment, which still makes the secrecy surrounding both much of the "Care Package" and the Beyonwiz devel version of OpenViX puzzling.

Given your success in using the open and publicly available sources I believe the only issue, which is really a non-issue, is the discussion of Beyonwiz on the OpenViX forum. This appears to be a purely commercial limitation of that service provider. I would assume that discussion of your efforts here would be perfectly acceptable.

Regards,
Ian.

[BigbobOz]

Out of interest, what's the advantage of getting OpenViX on the Beyonwiz?

[prl]

Out of interest, what's the advantage of getting OpenViX on the Beyonwiz?

For myself, so that I can test firmware changes on it and make the same changes on both it and the Beyonwiz firmware. That makes merges later from OpenViX easier for peteru.

[MrQuade]

Out of interest, what's the advantage of getting OpenViX on the Beyonwiz?

More for a developer than a consumer.

However, there may be some plugins that work better on Vix than they do on the Wiz firmware. You'd be compromising your Live TV experience somewhat by using Vix though I imagine (not sure, haven't tried it), as all the Aussie enhancements would be missing.

[prl]

... as all the Aussie enhancements would be missing [in OpenViX].

In particular, but not exclusively, lots of bug fixes, being able to use UP/DOWN for skips, enhancements to the HELP screen system and having the Terrestrial TV LCN bouquet (though IMO that's of rather limited use).

[prl]

But in any case, even though I still think I could build OpenViX entirely from public sources, I still would respect the preference of the OpenViX developers community to not distribute OpenViX for PVR models that are outside the normal OpenViX distribution.

[IanSav]

Hi BigbobOz,

Out of interest, what's the advantage of getting OpenViX on the Beyonwiz?

In my case I am both a Beyonwiz and OpenViX developer. I only have access to Beyonwiz hardware so need to be able to run both versions.

From an end user point of view about the only reason to run other firmware would be to try out plugins, skins, and other things that don't work on the Beyonwiz firmware. The reality is that the Beyonwiz firmware is a lot more stable and much more user friendly than any of the other builds.

Regards,
Ian.