50 replies to this topic

[christophecvr]

@MiLo

 

This message is based on PLI4.0 does not build anymore due to broken svn fetcher

http://openpli.org/f...en-svn-fetcher/

 

At this moment  it actually has very few left related to that toppic.

 

I continued works and experiments on master-next.

 

I just produced 3 patches.

 

1) The first does contain the pkgconfig and gettext problems.

 

2) The second does contain the changed stuff out of master since last 7 days which where not merged into master-next yet.

 

3) The third does contain the needed python changes since meta-openembedded has and meta-python layer now.

     To do this I just used bbapend.  Removed the old 12.0.0 and replaced it by 13.2.0 . In this append I added python rdepends needed for pli4.0.

     Just one extra add by enigma2.bb  module numbers.

 

For persons who want't to try , Just clone the current master-next , then apply these 3 patches.

 

Would be nice if the first patch would is aplied to the current master. As it's an error there.

 

Then just merge the master to master-next (keeping the openembedded-core-rev off that one used in master-next now)

 

Then after merge users will only have to aplly patch 3. Or it may also be aplied to master next after merge with master.

 

Thank's

 

p.s. It is tested by me on vuduo2 and dm8000. It should be ok for all boxes.

 

 

 

Attached Files

•  Masternextpkgconfiggettext2.patch   5.49KB   3 downloads
•  Master-next-not-merged.patch   4.89KB   2 downloads
•  Master-next-Python.patch   12.94KB   5 downloads

[MiLo]

I'll look into it shortly, thanks for the good work.

[christophecvr]

I also find out something which could reduce maintenance in future , If the python-twisted into for example meta-openembedded/meta-python is upgraded. It should not give extra maintenance for pli team.

 

By replacing the package version into the bbappend from in this example :

 

python-twisted_13.2.0.bbappend

 

into :

 

python-twisted_%.bbappend

 

I do not know if there could come a not wanted site effect in future , but by me it works and does not issue any error.

 

her patch to apply only after the previous patches are applied.

Attached Files

•  Mater-next-bbappend-procent.patch   3.15KB   3 downloads

[christophecvr]

@All

 

The master-next is now ok . The latest patches are in and changes out off master are merged.

 

For those who are just like me and like to experiment .Clone latest master-next freshly. Make fresh build from scratch.

 

By me build vuduo2 and dm8000 OK flash ok working 100 % ok .

 

Not any problem encountered.

 

@MiLo Thanks.

[Beeker]

New OE-core update has problem with configure gst-plugin-subsink.bb (and more like bitrateviewer and gst-plugin-dvbmediasink).

autoreconf: running: automake --add-missing --copy --force-missing
| configure.ac:22: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.  For more info, see:
| configure.ac:22: http://www.gnu.org/s...MAKE-invocation
| Makefile.am: error: required file './NEWS' not found
| Makefile.am: error: required file './README' not found
| Makefile.am: error: required file './AUTHORS' not found
| Makefile.am: error: required file './ChangeLog' not found
| src/glib-gen.mak:8: warning: foreach h,$(glib_enum_headers: non-POSIX variable name
| src/glib-gen.mak:8: (probably a GNU make extension)
| src/Makefile.am:3:   'src/glib-gen.mak' included from here
| src/glib-gen.mak:11: warning: '%'-style pattern rules are a GNU make extension
| src/Makefile.am:3:   'src/glib-gen.mak' included from here
| src/glib-gen.mak:15: warning: '%'-style pattern rules are a GNU make extension
| src/Makefile.am:3:   'src/glib-gen.mak' included from here
| src/glib-gen.mak:20: warning: '%'-style pattern rules are a GNU make extension
| src/Makefile.am:3:   'src/glib-gen.mak' included from here
| src/glib-gen.mak:28: warning: '%'-style pattern rules are a GNU make extension
| src/Makefile.am:3:   'src/glib-gen.mak' included from here
| src/glib-gen.mak:40: warning: '%'-style pattern rules are a GNU make extension
| src/Makefile.am:3:   'src/glib-gen.mak' included from here
| src/glib-gen.mak:43: warning: '%'-style pattern rules are a GNU make extension
| src/Makefile.am:3:   'src/glib-gen.mak' included from here
| autoreconf: automake failed with exit status: 1
| ERROR: autoreconf execution failed.


It has probably what to do with commit 975b69e418ddfc8f05dbc2273eccfb150327931d ?

Fix for autotools incompatibility
    
    OE no longer supplies "foreign" to all autotools build, causing many old
    recipes to fail. Patch the configure.ac files to add "foreign" to the
    automake initialization using a simple sed script.
    Also remove "protocol=git" from git:// URIs.

To avoid conflicts and just to be sure everthing is up to date, i build from stratch with git clone -b master-next (today 22.20) but problem remain.

 

[MiLo]

Most of the "foreign" troubles should be solved now.

Upstream OE no longer supplies "foreign" to each autotools project, so projects that needed it but did not mention it now fail to build. Not really OE's fault, but the developer's who wrote the package.

[Beeker]

Most of the "foreign" troubles should be solved now.

Upstream OE no longer supplies "foreign" to each autotools project, so projects that needed it but did not mention it now fail to build. Not really OE's fault, but the developer's who wrote the package.

 

for your information:

With latest update to commit f3d0ceae01ffb6c0c4e968dd3e1566848d9ed9ff.

As workaround: i removed -inherit autotools- from these recipes:

meta-openpli/recipes-multimedia/readymedia/readymedia.bb, do_configure
meta-openpli/recipes-openpli/enigma2/gst-plugin-subsink.bb, do_configure
meta-openpli/recipes-openpli/enigma2-plugins/enigma2-plugin-extensions-tuxcom.bb, do_configure
meta-dream/recipes-bsp/drivers/gst-plugin-dtsdownmix.bb, do_configure
meta-dream/recipes-bsp/drivers/gst-plugin-dreambox-dvbmediasink_0.10.bb, do_configure
 
Then image and feed are build.Image boot after fresh flash and no problems.

Just add python-modules to openwebif.bb.Otherwise no webinterface and TV/radio channels(problem with Dreamboxedit).
 

[MiLo]

As workaround: i removed -inherit autotools- from these recipes:

That's the equivalent of "take 'em out to the barn and shoot 'em". They indeed won't give you any trouble after you do that.

[christophecvr]

Most of the "foreign" troubles should be solved now.

Upstream OE no longer supplies "foreign" to each autotools project, so projects that needed it but did not mention it now fail to build. Not really OE's fault, but the developer's who wrote the package.

Yes I already found this out, since I tried self with more updated oe-core then was in master next.

 

I spent many time to find a solution to implement the foreign to bb file for a specific package but couldn't find one. or to eventually adapt the specific source Makefile.am .

But none of them worked out.

 

What is well a solution.

 

1) Reimplement the foreign patch for the autoconf package like it was . can be done just simply by creating own pli automake_2.69.bb which is just a copy of that from oe-core but there just add the foreign patch back. 

   This solve the problems pli4 will use that to compile. Build back 100 % ok.

2) Adding the missing files for each package indivually. Like if README AUTHORS NEWS or a couple more if they are not present in the source. It's enough to just create an empty text file with those name's if they are not present in source. If done comipling back 100 % ok

 

The both options are a good possible solution. However the second whe eventually could make a script file to first scan the source if one of those files is missing creating a blank file with the name. This before running autoconf.

Some packages do contain multiple source files so it's must be done for each source.

[christophecvr]

But I gues that there are maybe even better solutions.

[Beeker]

gst-plugin-dtsdownmix and gst-plugin-subsink are OK now after adding NEW,README etc in de source.

gst-plugin-dreambox-dvbmediasink now configuring and compiling but fails to install.

build/tmp/work/mips32el-oe-linux/gst-plugin-dreambox-dvbmediasink/0.10+gitAUTOINC+7671ff6f07-r10/image is empty.

Readymedia and Tuxcom not important at the moment.So still shutdown by workaround.

I'm gonna try something.

[christophecvr]

gst-plugin-dtsdownmix and gst-plugin-subsink are OK now after adding NEW,README etc in de source.

gst-plugin-dreambox-dvbmediasink now configuring and compiling but fails to install.

build/tmp/work/mips32el-oe-linux/gst-plugin-dreambox-dvbmediasink/0.10+gitAUTOINC+7671ff6f07-r10/image is empty.

Readymedia and Tuxcom not important at the moment.So still shutdown by workaround.

I'm gonna try something.

Ter info after changes not all bust most packages like dvbmediasink needs first a full cleanall.

 

They only build ok when building the image again , they do not build using the bb file only.

[Beeker]

This is the patch i use for gst-plugin-dreambox-dvbmediasink. Maybe you know it is the right one?  I will build from stratch.

 

diff --git a/configure.ac b/configure.ac
index 7483e54..2eb9888 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,4 +1,4 @@
-AC_INIT
+AM_INIT_AUTOMAKE([foreign])
 AC_CONFIG_MACRO_DIR([m4])
 
 dnl versions of gstreamer and plugins-base

[christophecvr]

This is the patch i use for gst-plugin-dreambox-dvbmediasink. Maybe you know it is the right one?  I will build from stratch.

 

diff --git a/configure.ac b/configure.ac
index 7483e54..2eb9888 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,4 +1,4 @@
-AC_INIT
+AM_INIT_AUTOMAKE([foreign])
 AC_CONFIG_MACRO_DIR([m4])
 
 dnl versions of gstreamer and plugins-base

Perhaps it work's out by You , By me it never did .

 

That's also the reason why in 2004 they implemented this patch into autoconf. Just cause the AM_INIT_AUTOMAKE([foreign] never worked into oe-core , why ?? I don't.

 

If it work's by You let it know . I tried it all and it never worked with the oe-core.

[christophecvr]

As extra note as fare i could see,

 

It is the autoconf who fails . Just to the missing foreign , or eighter missing files AUTHORS NEW .... etc.

 

The automake will not fail if AM_INIT_AUTOMAKE([foreign]) . But we do never reach the automake stage into bitbake , as it's already failed into autoreconf fase. And that's why the patch was made.

[Beeker]

When patch applied, gst-plugins-dreambox-.dvbmediasink  configuring and compiling but fails on install..Maybe  -AC_INIT could be a problem ? Anyway i let you know..

Edited by Beeker, 18 August 2014 - 16:17.

[christophecvr]

When patch applied, gst-plugins-dreambox-.dvbmediasink  configuring and compiling but fails on install..Maybe  -AC_INIT could be a problem ? Anyway i let you know..

Don't forget note. What I say before.

 

Building the dvbmediasink with bitbake -b ..../gst-plugins-dreambox-.dvbmediasink.bb  will never work.

 

What You must do is first bitbake -b ..../gst-plugins-dreambox-.dvbmediasink.bb -f -c cleanall.

 

Then realy use bitbake openpli-enigma2-feed  (or you're own image). See that patches are applied out off bb file .

 

What also works is :

 

bitbake -b ..../gst-plugins-dreambox-.dvbmediasink.bb -f -c cleanall

 

Then

 

bitbake -b ..../gst-plugins-dreambox-.dvbmediasink.bb -c patch

 

Then make You're changes in the work repo.

 

Then continu with

 

bitbake openpli-enigma2-feed  (or you're own image).

Edited by christophecvr, 18 August 2014 - 17:08.

[Beeker]

I deleted the build directory..cause i have done a lot of experiments...but /gst-plugins-dreambox-.dvbmediasink still fail.

 

Log data follows:
| DEBUG: SITE files ['endian-little', 'bit-32', 'mips-common', 'common-linux', 'common-glibc', 'mipsel-linux', 'common']
| DEBUG: Executing shell function do_install
| NOTE: make -j 8 DESTDIR=/home/hains/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gst-plugin-dreambox-dvbmediasink/0.10+gitAUTOINC+7671ff6f07-r10/image install
| make: *** No rule to make target 'install'.  Stop.
| ERROR: oe_runmake failed
| WARNING: /home/hains/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gst-plugin-dreambox-dvbmediasink/0.10+gitAUTOINC+7671ff6f07-r10/temp/run.do_install.7315:1 exit 1 from
|   exit 1
| ERROR: Function failed: do_install (log file is located at /home/hains/openpli-oe-core/build/tmp/work/mips32el-oe-linux/gst-plugin-dreambox-dvbmediasink/0.10+gitAUTOINC+7671ff6f07-r10/temp/log.do_install.7315)
ERROR: Task 2873 (/home/hains/openpli-oe-core/meta-dream/recipes-bsp/drivers/gst-plugin-dreambox-dvbmediasink_0.10.bb, do_install) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3352 tasks of which 3344 didn't need to be rerun and 1 failed.
Waiting for 0 running tasks to finish:

[Beeker]

Ter info

 

I did a cleanall before and a git checkout on gts-plugin-dreabox-dvbmediasink.bb

 

Just added the patch to the recipe.

 

While building from stratch, just put NEW,README etc in the source code and continue with make image.

 

I see no do_install in the recipe.So maybe the problem could be solved to tell bitbake how.

[christophecvr]

Yes after to many experiments you end sometimes end up with unrecoverable issues. The last oe-core is much more sensible to such issues then the old ones.

 

Sometimes it helps by :

 

removing all the packages on which you experimented with the cleanall  (cleanall not clean !)

 

Then after they are all cleaned

 

run bitbake -b ..../image.bb (your image or the feeds) -f -c cleanall

 

on top off it

 

bitbake -c cleanall openpli-enigma2-feed  (or you're image.)

 

Restart the latest changes all over again. But never build one off those failed packages completely with the bitbake -b .../package.bb 

But build them maximum up to patch fase.

 

Finish the complete build always with

 

bitbake -k openpli-enigma2-feed (or you're image) (using the -k option does helps a lot)

 

If it still not works .... tjeeee back from scratch is needed.