1177 replies to this topic

[christophecvr]

Hello all ,

 

To all Happy New-Year and a good 2016.

 

I did found it appropriate to install the pli5 on January 1 2016

 

Build and test report Off the coming pli-5. (currently still next-master).

 

Build off scratch on dm8000 and vuduo2. (For those who already worked with next master best remove all what You did fresh pull fresh build is advised).

 

Build vuduo2 almost 100 % ok for first try only a little issue with rytec sources. I temporarily solved this by reverting commit :

https://github.com/O...a9b0d92c8f9f4e9

That is not a permanent solution but the last rytec source is corrupt on the link. If Rytec team does re upload there source problem should be solved.

 

dm8000 (and I gues dm800se should be also) does build perfect after commit master next 5e4e998b5b5516e06f2bea358633e03b48308835.

 

I personally use already gstreamer 1.7.1  + head (so i'ts 1.7.1.1 master head).

 

Since 1.7.1 gstreamer again stabilizes and becomes slowly but surely stable again with great extra support.

By me 1.5.1 was ok. all gst version between 1.5.1 and up to included 1.7.0 where pretty unstable.

Think for pli its best to hook in on 1.7.2 once it's out. as a tagged version. Then we just need to remove the gstreamer1.0-plugins-bad-fragmented plugin out off e2-recommends and add gstreamer1.0-plugins-bad-hls.

 

Test reports vuduo2 and dm8000.

 

Flashing 100 % ok

Configuring 100 % ok

Loading channel lists 100 % ok

 

With other words looks all ok now.  Ok more extensive tests and use will maybe show some small issues to fix but in general all OK.

 

That's a nice new year start

[MastaG]

It's great to see master-next finishing up.

So many security CVE's are squashed by using the new snapshot from openembedded-core.

Soon I'll give it a spin for myself

[Beeker]

Bug in openpli-5

 

When there are only new packages for the feed(for example oscam or iptvplayer), it does build but the packagelist doesn't upgrade to the new revision(s).

 

So when you try to upgrade your box, there will be no updates.

 

When running the build once again, then your box will be updated.

 

When there are new packages for the image or, image and feed you have to run the build just once.Just as it should be.

 

But for new feed packages only, you have to run the build twice.

[Alexvrs]

Bug in openpli-5

 

Error when compiling the boxes with kernel (i testing et8500 and et4x00):

 

linux-etxx00-2g

 

linux-etxx00-3g

 

Has anyone been able to compile these boxes without errors?

 

TNX

[christophecvr]

I do not build for et8500 or et4x00 , But would be really surprised that it fails after that images for vuduo2 and dm8000 are building ok. Are You shure that you're build is not just failing on the rytec sources ?

[christophecvr]

As a last remark and this to all builders whatever machine.

 

(For those who already worked with next master best remove all what You did fresh pull fresh build is advised)

 

First MiLo very whell thanks off you're works , I know You're pretty act if with it since months.

 

For others really take my advice off :

For those who already worked with next master best remove all what You did fresh pull fresh build is advised

 

!!!! VERY VERY IMPORTANT.

 

As long You're do not that you're comments and remarks are useless, and You just will spill the time off MiLo.

[Erik Slagter]

Bug in openpli-5

 

Error when compiling the boxes with kernel (i testing et8500 and et4x00):

 

linux-etxx00-2g

 

linux-etxx00-3g

 

Has anyone been able to compile these boxes without errors?

 

TNX

No problems here building et8500.

[MiLo]

Apparently the et4x00 needs a kernel patch to atually work. Guess that's the same as for the other non-fpu boxes.

[Alexvrs]

I do not build for et8500 or et4x00 , But would be really surprised that it fails after that images for vuduo2 and dm8000 are building ok. Are You shure that you're build is not just failing on the rytec sources ?

 

with the rytec sources no problems

[peti]

I was also able to build for VUUNO.

I can confirm the bug described by Beeker

I had to add the 0001-fix-compile-error-261pay.patch for gstreamer1.0-plugins-good  and a different version of 0001-Fix-crash-with-gst-inspect.patch from MastaG for gstreamer1.0 (I'm using the 1.7.1 tagged one) 

[christophecvr]

I Would say be shure to have last git master -next  ( so noting else and certainly not the master-for-gcc5) the master-next is now gcc-5. If You did tried and or had already builds with master next. Clean all remove really the builds do a fresh pull.

Actually just erase the ..../openpli-oe-core  map and start new with a fresh clone.

 

About gstreamer yes the version going with the current master next is NOT OK . But we are still not on a off pli5 image .

I personally use now (as even the tagged 1.7.1 is lable) 1.7.1.1 git I'll set my recipes used whit patches and who do work supper and build with the current next-master.

 

 

Attached Files

•  Gstreamer-1.7.1.1-pli5-recipe.tar.gz   18.19KB   186 downloads

[peti]

any idea why are the master-next images so big? with same settings the zipped image for VUUNO jumped from 51MB to 68MB

[littlesat]

Samba....

[peti]

I do not think it will be just samba.. the usr/lib/samba is just 11MB uncompressed...

 

Here are the folder sizes for /usr... Later I can do a comparison with PLi4

root@vuuno:/# du /usr -d 2 -x -h
8.9M    /usr/bin
80.0K   /usr/lib/gio
152.0K  /usr/lib/ldb
12.0K   /usr/lib/ssl
340.0K  /usr/lib/dbus
232.0K  /usr/lib/krb5
928.0K  /usr/lib/opkg
17.5M   /usr/lib/gstreamer-1.0
11.7M   /usr/lib/enigma2
148.0K  /usr/lib/locale
68.0K   /usr/lib/gconv
11.0M   /usr/lib/samba
224.0K  /usr/lib/sasl2
24.0K   /usr/lib/gstreamer1.0
23.4M   /usr/lib/python2.7
20.0K   /usr/lib/libnfsidmap
101.8M  /usr/lib
0       /usr/src
0       /usr/keys
4.1M    /usr/sbin
0       /usr/games
40.0K   /usr/include/python2.7
40.0K   /usr/include
0       /usr/share/man
520.0K  /usr/share/alsa
0       /usr/share/dict
0       /usr/share/info
0       /usr/share/meta
0       /usr/share/misc
16.0K   /usr/share/opkg
4.0K    /usr/share/gstreamer-1.0
292.0K  /usr/share/zoneinfo
19.2M   /usr/share/enigma2
44.0K   /usr/share/gst-plugins-base
4.0K    /usr/share/locale
708.0K  /usr/share/ca-certificates
44.0K   /usr/share/keymaps
4.0K    /usr/share/glib-2.0
804.0K  /usr/share/transmission
12.0K   /usr/share/avahi
1.3M    /usr/share/fonts
320.0K  /usr/share/samba
80.0K   /usr/share/readline
4.0K    /usr/share/udhcpc
0       /usr/share/dbus-1
23.5M   /usr/share
138.4M  /usr

Edited by petike, 5 January 2016 - 16:25.

[MiLo]

Samba installs a LOT of other libraries. It's not just samba itself.

[theparasol]

Why not make it optional? I personally dont care for samba by default in my image!

[MiLo]

Trimming it down is on the TODO list.

I don't care either, but there should be a working alternative to share the disk first.

[athoik]

Maybe via OpenWebIf serve /media/ ?

[MiLo]

Not (just) for fetching files, but for recording onto another box and playing back from there (a.k.a. using one box as NAS). That CAN be done using the webif, technically the protocol can handle that just fine, but it'd require a bit of programming on both ends. Not to mention a bit of "vision" too.

Edited by MiLo, 5 January 2016 - 20:21.

[Taapat]

I see that in this moment in meta-openembedded has done some work to split samba into packages.

But of course it still does not reduce the dependency quantity which is compiled and installed together with the samba 4.

And as an alternative still exists possibility move back to the samba 3.