OpenViX build for Beyonwiz

[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.

[Huevos]

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

It means that someone who doesn't own one of the supported receivers can still be involved in shared development.

The Beyonwiz is not a supported receiver, so there will be receiver specific stuff missing from the image. For example OpenViX doesn't know what sockets or resolutions the Beyonwiz has available.

There is nothing to stop people building OpenViX for themselves but they will get no support from our forum. This is the same for all non-supported receivers. But redistribution of compiled images is not something we would be happy about.

[peteru]

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.

The top level directory should have a copy of the Yocto Project Reference Manual in PDF format. I actually prefer to use the online mega manual. Not only is it more up to date, but the formatting is more usable. Not everything in the manual applies to the OE-A build environment.

Basically, you want to source the environment file from your distro build directory, then use bitbake to get a devshell in the enigma2 working directory. There are a few ways of managing your source. You could use the external source method, you could change ENIGMA2_URI to point at your git repo, or you could work directly in the workdir git repo. Be aware that by default the build process will use rm_work, which will blow away your changes in the workdir if you kick of the normal bitbake process. You probably don't have enough disk space to work without rm_work, so you need to learn how to work with OpenEmbedded. The section on development models and workflow will probably help. A relatively recent addition is devtool, which may be helpful. Mind you I never used devtool for enigma2 work, so can't give you step-by-step instructions.

[Huevos]

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

Hopefully this will help.

Just build the enigma2 binary

For testing CPP code, just build enigma2, to save time.

enigma2 git location = /home/username/3.3/builds/developer/vusolo4k/tmp/work/vusolo4k-oe-linux-gnueabi/enigma2/enigma2-5.2+gitAUTOINC+f3fe89ab92-r0/git

enigma2 binary location = /home/username/3.3/builds/developer/vusolo4k/tmp/work/vusolo4k-oe-linux-gnueabi/enigma2/enigma2-5.2+gitAUTOINC+f3fe89ab92-r0/package/usr/bin/enigma2

cd /home/username/3.3/builds/openvix/developer/vusolo4k
MACHINE=vusolo4k
MACHINEBUILD=vusolo4k
. env.source
bitbake -f -c clean enigma2
bitbake -f -c unpack enigma2

(transfer modified C++ files to "enigma2 git")

bitbake -c package enigma2

(retrieve enigma2 binary from "enigma2 binary location")...

But an update build only takes a few minutes so normally I just do an update build from my enigma2 fork.

[prl]

Thanks, Huevos. I tried that earlier today and I think I've got it sorted now for a real test build.

When I posted asking how to do it, I couldn't quite match what was in the HTML of instructions with what I had, but it's good now.

[BigbobOz]

Thanks guys. A lot of work being done behind the scenes!

[prl]

Does anyone know whether I should be building the current OpenViX Dev branch on the Oe-Alliance 4.0 or 4.1 build-environment?

[IanSav]

Hi Prl,

Does anyone know whether I should be building the current OpenViX Dev branch on the Oe-Alliance 4.0 or 4.1 build-environment?

Is there a file, flag or setting within the build I can check to tell you the current build environment used in the new firmware I applied today? If not I can ask the other developers for you.

Regards,
Ian.

[prl]

Hi Prl,

Does anyone know whether I should be building the current OpenViX Dev branch on the Oe-Alliance 4.0 or 4.1 build-environment?

Is there a file, flag or setting within the build I can check to tell you the current build environment used in the new firmware I applied today? If not I can ask the other developers for you.
...

Thanks, Ian.

I think that if the OpenViX image name starts with 5.0 it was built on the Oe-Alliance 4.0 build-environment and so if the image name starts with 5.1 it may have been built on Oe-Alliance 4.1. But that's a guess, and I don't know of any other potential indicators.

The problem I'm having is that
MACHINE=beyonwizt3 DISTRO=openvix DISTRO_TYPE=developer make image

runs for a while and then the bitbake processes hang.

[IanSav]

Hi Prl,

Today's update was to 5.0.21.005 (Developer).

It is the middle of the night over there so I will ask for you when they are awake.

Regards,
Ian.

[prl]

OK, thanks Ian. That would be good.

[prl]

The problem I'm having is that there are three bitbake processes "running", but they're running very little, in the past nearly 4 hours, less than 2 min runtime each:

Code: Select all

  PID TTY      STAT   TIME COMMAND
...
 7597 pts/17   S+     0:00 make image
 7619 pts/17   S+     0:00 /bin/sh -c . /home/prl/openvix/builds/openvix/developer/inihdx/env.source && cd /home/prl/openvix/builds/openvix/developer/inihdx && bitbake openvix-image
 7621 pts/17   S+     1:44 python3 /home/prl/openvix/bitbake/bin/bitbake openvix-image
 7624 pts/17   Sl+    1:41 python3 /home/prl/openvix/bitbake/bin/bitbake openvix-image
 7626 pts/17   Sl+    0:51 python3 /home/prl/openvix/bitbake/bin/bitbake openvix-image
 7627 pts/17   Z+    11:05 [Parser-1:2] <defunct>

And I'm not sure why Parser-1:2 has gone zombie.

I haven't been able to find any detailed logs beyond the setout/stderr of the make, which isn't saying anything about the problem.

[IanSav]

Hi Prl,

Build environment 4.0 is still the one to use.

Regards,
Ian.

[Huevos]

4.0 is the current branch we are using for 5.0 images.

You should also be able to build from 4.1 if there is something you want to test in that branch that does not exist in the current branch.

Image numbering is not pegged to the core branch numbering although it has been in the past.

And enigma2 just comes from whatever git is mentioned in openvix.conf. So, for example, I test most of my stuff in my own fork of OpenViX and build from that.

Same with feeds. Just edit the feeds URI in openvix.conf to reflect where your feeds are located.

[IanB]

...

Code: Select all

  PID TTY      STAT   TIME COMMAND
...
 7627 pts/17   Z+    11:05 [Parser-1:2] <defunct>

And I'm not sure why Parser-1:2 has gone zombie.

Zombie's are finished processes whose parent process has not yet completed a waitpid() call to collect the child's exit() status.

[prl]

...

Code: Select all

  PID TTY      STAT   TIME COMMAND
...
 7627 pts/17   Z+    11:05 [Parser-1:2] <defunct>

And I'm not sure why Parser-1:2 has gone zombie.

Zombie's are finished processes whose parent process has not yet completed a waitpid() call to collect the child's exit() status.

I know what a zombie process is. I was wondering why Parser-1:2 had exited when it wasn't expected to.

[prl]

Thanks, IanSav & Huevos. I've been building using the 4.0 build-environment and on the Dev branch of the main OpenViX repository.

[IanB]

..... I was wondering why Parser-1:2 had exited when it wasn't expected to.

Alternatively Parser-1:2 may have finished successfully and it's the parent that constipated.

[prl]

4.0 is the current branch we are using for 5.0 images.

You should also be able to build from 4.1 if there is something you want to test in that branch that does not exist in the current branch.

Image numbering is not pegged to the core branch numbering although it has been in the past.

And enigma2 just comes from whatever git is mentioned in openvix.conf. So, for example, I test most of my stuff in my own fork of OpenViX and build from that.

Same with feeds. Just edit the feeds URI in openvix.conf to reflect where your feeds are located.

I've just been doing this:

Code: Select all

git clone https://github.com/oe-alliance/build-enviroment.git -b 4.0 openvix
cd openvix
make init
make update
MACHINE=beyonwizt3 DISTRO=openvix DISTRO_TYPE=developer make image

I.e. everything straight from the standard repositories.

However, there does seem to be some sort of feed problem, since I'm getting all these failures to locate packages:

Code: Select all

WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-odroid/recipes-bsp/odroid-shutdown.bb: Unable to get checksum for odroid-shutdown SRC_URI entry inihdx-shutdown.sh: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-odin/recipes-bsp/odin-backup.bb: Unable to get checksum for odin-backup SRC_URI entry odin-backup.sh: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-gigablue/recipes-gb/gigablue-ethwol.bb: Unable to get checksum for gigablue-ethwol SRC_URI entry ethwol.sh: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-gfutures/recipes-graphics/libgles/hd-qteglfs-platform.bb: Unable to get checksum for hd-qteglfs-platform SRC_URI entry libqeglfs-nxpl-integration.so: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-fulan/recipes-drivers/fulan-dvb-modules-spark.bb: Unable to get checksum for fulan-dvb-modules-spark SRC_URI entry modules.conf: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-fulan/recipes-drivers/fulan-dvb-modules-spark.bb: Unable to get checksum for fulan-dvb-modules-spark SRC_URI entry modules-conf.conf: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-dream/recipes-enigma2/dreambox-enigma2-config.bb: Unable to get checksum for dreambox-enigma2-config SRC_URI entry skin_box.xml: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-dream/recipes-drivers/dreambox-dvb-modules-dm800sev2_3.2-20151201.bb: Unable to get checksum for dreambox-dvb-modules-dm800sev2 SRC_URI entry modules: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-dream/recipes-drivers/dreambox-dvb-modules-dm800se_3.2-20151201.bb: Unable to get checksum for dreambox-dvb-modules-dm800se SRC_URI entry modules: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-dream/recipes-drivers/dreambox-dvb-modules-dm800_2.6.18-7.4-20131228a.bb: Unable to get checksum for dreambox-dvb-modules-dm800 SRC_URI entry modules: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-dream/recipes-drivers/dreambox-dvb-modules-dm7020hdv2_3.2-20160701.bb: Unable to get checksum for dreambox-dvb-modules-dm7020hdv2 SRC_URI entry modules: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-dream/recipes-drivers/dreambox-dvb-modules-dm7020hd_3.2-20160701.bb: Unable to get checksum for dreambox-dvb-modules-dm7020hd SRC_URI entry modules: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-dream/recipes-drivers/dreambox-dvb-modules-dm500hdv2_3.2-20140616.bb: Unable to get checksum for dreambox-dvb-modules-dm500hdv2 SRC_URI entry modules: file could not be found
WARNING: /home/prl/openvix/meta-oe-alliance/meta-brands/meta-dream/recipes-drivers/dreambox-dvb-modules-dm500hd_3.2-20140616.bb: Unable to get checksum for dreambox-dvb-modules-dm500hd SRC_URI entry modules: file could not be found
WARNING: /home/prl/openvix/meta-openembedded/meta-oe/recipes-support/libtinyxml/libtinyxml_2.6.2.bb: Unable to get checksum for libtinyxml-native SRC_URI entry tinyxml.pc: file could not be found

There's no further log output at all after the warning about tinyxml.pc. Parser runs for a few minutes, then exits and the bitbake processes seem to lock up. It wouldn't surprise me if these failures caused the lockup, but I can't find any logging that would help work out which ones or what to do to fix them. They're not the only log messages, but they seem to me to be the ones most likely to be causing a problem.

[peteru]

All those messages are nothing to worry about. It's caused by the bitbake recipes referencing files that are not part of your build configuration.

The parser needs network access to parse any recipes that build from git repositories, I would probably start looking at that aspect.

[prl]

All those messages are nothing to worry about. It's caused by the bitbake recipes referencing files that are not part of your build configuration.

The parser needs network access to parse any recipes that build from git repositories, I would probably start looking at that aspect.

I have network access in the VM running Ubuntu on my Mac, and the Parser is exiting without any error message being logged. I tend to agree that a network issue may be the cause, but why have the bitbake processes hung, and why did the Parser exit without any logged error message?