50 replies to this topic

[christophecvr]

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.

 Normally the pkgconfig takes care off the install. It's not needed unless some none standard things are used .  But ... what is now standard ... That's the question.

[christophecvr]

To be honnest I slammed one keyboard into pieces due to this bloody foreign problem

[Beeker]

Yes i can imagine that..pfff..Well i have to leave,i try something later in the evening..I think we have to tell bitbake in the recipe how to install..But i could be wrong..

[MiLo]

Just look at how I 'fixed' the others, most have a "sed" script now to replace the AM_... invocation with something that works.

There's no quick way, you have to look at the first few lines of configure.ac and see what the patch must do to add "foreign" to the macro, and usually remove the old package+version arguments that were there.

I've never really understood why autotools insists on these useless files being present.

[athoik]

MAybe it's enough to add foreign to Makefile.am

AUTOMAKE_OPTIONS = foreign

Then most probably the only think required is to change AC_INIT

-AC_INIT
+AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)

Reference: http://mij.oltrelinu...oconf-automake/

[christophecvr]

MAybe it's enough to add foreign to Makefile.am

AUTOMAKE_OPTIONS = foreign

Then most probably the only think required is to change AC_INIT

-AC_INIT
+AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)

Reference: http://mij.oltrelinu...oconf-automake/

That's already tried by me , but really I never could not let it work. To at to automake in Makefile.am it is

 

AM_INIT_AUTOMAKE([foreign])

 

 

We do never reach the automake stage into bitbake , as it's already failed into autoreconf fase. And that's why the (foreign) patch was made in 2004 into oe-core . It is just removed now and there we go...problems are starting.

[MiLo]

We're the only ones still compiling projects that were already abandoned way before 2005 I guess

[christophecvr]

We're the only ones still compiling projects that were already abandoned way before 2005 I guess

Unfortunately no we are not . But  pli4 is well one of the only images which is using such modern oe-core.  The day when other images will start using the more modern oe-core they will have the same problems. Ok some packages are a lot older like tuxbox. But the gst-dvbmediasink  is pretty up to date. And others also.

[Beeker]

This is de working patch:

 

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

 

---------------------------------------------------------------------------------------------------------

 

IPK attachted.

Attached Files

•  gst-plugin-dreambox-dvbmediasink_0.10+git139+7671ff6-r10_mips32el.ipk   34.86KB   0 downloads

[Beeker]

For readymedia:

 

Make a empty file with the name ABOUT-NLS

 

And put minidlna.init.d.script (attached) in git/linux/ (in workdirectory  openpli-oe-core/build/tmp/work/mips32el-oe-linux/readymedia/1.1.0+gitAUTOINC+bb9d584a86-r0).

 

Not a real solution, but is better to do this then nothing.

Attached Files

•  minidlna.init.d.script.zip   852bytes   0 downloads

Edited by Beeker, 18 August 2014 - 23:28.

[Beeker]

For readymedia:

 

Make a empty file with the name ABOUT-NLS

Sorry , Put that file into the source dir.(openpli-oe-core/build/tmp/work/mips32el-oe-linux/readymedia/1.1.0+gitAUTOINC+bb9d584a86-r0/git).

[christophecvr]

I previousely spook about 2 solutions.

 

I just did a try with the first and this works fine. It's just an extra add to ...tuxcom.bb file :  pkgconfig to be added by inherit.

 

Complete build 100 % ok (with all feeds)

 

Here the patch. This is the most easy way

 

I copied the autoconf off oe-core to meta-openpli/recipes-devtools

 

readded the foreign patch and added it to the autoconf_2.69.bb

 

Build is just perfect.

 

Includded here the git patch against master-next

 

My build is made for vuduo2.

Attached Files

•  foreignaddedback.patch   30.62KB   3 downloads

[Beeker]

Yes there are more solutions.I also tried the sed script like @Milo said.

Tuxcom is now the only problem left.Before the master-next update last saterday tuxcom were OK.Now it complains about freetype again.

I follow the tread -Tuxcom is missing from feed-. So i have some information about it.I also take a look at your patch.

Edited by Beeker, 19 August 2014 - 11:19.

[Beeker]

Tuxcom is ok now.thanks.

[christophecvr]

Just look at how I 'fixed' the others, most have a "sed" script now to replace the AM_... invocation with something that works.

There's no quick way, you have to look at the first few lines of configure.ac and see what the patch must do to add "foreign" to the macro, and usually remove the old package+version arguments that were there.

I've never really understood why autotools insists on these useless files being present.

On that point a fully agree. Insisting one the presence of useless files is not understandable and does not make any sense.

 

I already told before , the guy who currently is doeing all those specific changes into oe-core , I can't understand him , i do not trust him , there is something not wright about him.

 

His changes improved nothing , no any valuable positiff effect is present. All his changes are leading to degraded build capacity.

 

It looks more like there is a hidden goal ?,diary? behind, It even smells bad ..... very bad.

Edited by christophecvr, 19 August 2014 - 14:42.

[pieterg]

You think the NSA might be behind it?

[MiLo]

Ask him.

[MiLo]

His changes improved nothing , no any valuable positiff effect is present. All his changes are leading to degraded build capacity.

There's the absense of bad effects, which is probably what he was after.

Because OE force-fed "--foreign" to all autotools invocations, even recipes created recently forgot to mention it in their makefile. As a result, you could only get those to compile using OE, but you couldn't build them on a normal PC. At least this puts a stop to the creation of more broken configure.ac files.

[christophecvr]

You think the NSA might be behind it?

No not really but some commercial onces ??   ... Once never now.

 

However this foreign problem, Yes normaly the source writers should pay attention to the gnu standards, and pay more attention to their configure.ac files. To have working autotools it's important. Just like MiLo said. ok it somehow underssandable.

 

What that Guy did with other things like a very good example is the Neon package is a very wrong and very questionable. It's clear that there he just did not test or even never thaught about severe consequences. And that since he's is in my opinion not stupid but just very smart and know his stuff very abnormal.

[christophecvr]

And here the solution 2 , actually it's not enterily like a proposed before , but took the better solution of MiLo

 

Tested now is full build off vuduo2 . Other boxes are not done. But I gues for dm it will just be to do extra by the gst-plugin...dreambox..dvbmediask.bb

 

This patch can be pushed to master next I think.

 

 

Attached Files

•  foreignextrasvuduo2.patch   3.69KB   0 downloads