1177 replies to this topic

[hemertje]

Is there an announcement?

[blzr]

@peti

I found this: https://github.com/o...b6503d0e3f72331 -

reportedly (upgraded) glibc 2.23 doesn't like bcm7405/7413 boxes for whatever reason (brodcom drivers fault?)

 

to check I built master-next image with only glibc rolled back to 2.22 and it boots and works fine...

 

not sure if we can expect any glibc fix/backport upstream, maybe older boxes simply will no longer be able to keep up with OE

 

I did a fresh fresh build from the master-next head with glibc 2.22, and compiled successfully and box is booting. Thanks for the hint. Hopefully someone can fix it, as this chip is not such ancient. 

 

ok, have some good news - today compiled master-next with yesterday's OE snapshot for my et9500, and, guess what - image boots and (at first glance) works fine

apparently glibc update to 2.24 solved our bcm7413 mysterious issue

root@et9x00:~# opkg list-installed *libc6*
libc6 - 2.24-r0

so, after next OE update in OpenPLi master-next our problematic boxes should be again in play

Attached Files

•  sys_info.jpg   53.89KB   14 downloads

Edited by blzr, 20 May 2016 - 16:38.

[MiLo]

Good to know - I was actually trying "krogoth" branch, but that's still on 2.23 so it wouldn't boot either.

[Erik Slagter]

Krogoth sounds like Klingon?

[MiLo]

The ultimate tech level 3 robot from Total Annihilation was called Krogoth.

[Erik Slagter]

Doesn't ring a bell.

[mrvica]

it does increase the size of the image, about 20MB more for OpenPLi 5, for boxes with just 64MB flash couldn´t even be installed on, could be a bit tight even for 128MB flash boxes

[christophecvr]

it does increase the size of the image, about 20MB more for OpenPLi 5, for boxes with just 64MB flash couldn´t even be installed on, could be a bit tight even for 128MB flash boxes

Yes I'm afk it does , But unfortunately evolutions off media and all other do the longer the more require more software and .... .  Gues that indeed the older boxes will slowly but surely need to be replaced in time. This is a bit normal the old flash for base software image was from the days all was sd now more then 50 % is already HD and sd support will drop down the longer the faster everywhere. 20 MB those days is peanuts but for old boxes ....

[MiLo]

On older boxes one could omit Samba. That package is responsible for most of the extra space.

[adri]

Will many users actually care about Samba?

I've never used a 'share' mapping between my linux receiver and my windows pc.

When I need to transfer files either way, I always use ftp.

 

Making Samba an option, to be installed though packages, shouldn't upset many people I think.

If you need it, you can install it after flashing.

If you don't need it, it'll keep your box tidy and leave more room for other things.

Edited by adri, 22 May 2016 - 20:31.

[peti]

 

ok, have some good news - today compiled master-next with yesterday's OE snapshot for my et9500, and, guess what - image boots and (at first glance) works fine

apparently glibc update to 2.24 solved our bcm7413 mysterious issue

 

thanks for the info, blzr, just started to build a new image for my VU+ Uno, will let you know 

[littlesat]

Making Samba an option, to be installed though packages, shouldn't upset many people I think.

-->

+1...

But i think we need to make a dummy sytemplugin than...

[peti]

enigma2 fails to compile with the current OE head - probably due to giflib update: http://git.openembed...1694c555633b921

 

Tpo -c -o service/service_libenigma_service_a-servicedvb.o `test -f 'service/servicedvb.cpp' || echo '../../git/lib/'`service/servicedvb.cpp
| ../../git/lib/gdi/picload.cpp: In function 'void gif_load(Cfilepara*, bool)':
| ../../git/lib/gdi/picload.cpp:481:39: error: too few arguments to function 'GifFileType* DGifOpenFileName(const char*, int*)'
|   gft = DGifOpenFileName(filepara->file);
|                                        ^
| In file included from ../../git/lib/gdi/picload.cpp:12:0:
| /home/peti/openpli5/openpli-oe-core/build/tmp/sysroots/vuuno/usr/include/gif_lib.h:179:14: note: declared here
|  GifFileType *DGifOpenFileName(const char *GifFileName, int *Error);
|               ^
| ../../git/lib/gdi/picload.cpp:571:19: error: too few arguments to function 'int DGifCloseFile(GifFileType*, int*)'
|   DGifCloseFile(gft);
|                    ^
| In file included from ../../git/lib/gdi/picload.cpp:12:0:
| /home/peti/openpli5/openpli-oe-core/build/tmp/sysroots/vuuno/usr/include/gif_lib.h:183:9: note: declared here
|      int DGifCloseFile(GifFileType * GifFile, int *ErrorCode);
|          ^
| ../../git/lib/gdi/picload.cpp:575:19: error: too few arguments to function 'int DGifCloseFile(GifFileType*, int*)'
|   DGifCloseFile(gft);
|                    ^
| In file included from ../../git/lib/gdi/picload.cpp:12:0:
| /home/peti/openpli5/openpli-oe-core/build/tmp/sysroots/vuuno/usr/include/gif_lib.h:183:9: note: declared here
|      int DGifCloseFile(GifFileType * GifFile, int *ErrorCode);
|          ^
| make[4]: *** [gdi/picload.o] Error 1

[Beeker]

As workaround.

diff --git a/lib/gdi/picload.cpp b/lib/gdi/picload.cpp
index 580826b..42bf46f 100644
--- a/lib/gdi/picload.cpp
+++ b/lib/gdi/picload.cpp
@@ -478,7 +478,7 @@ static void gif_load(Cfilepara* filepara, bool forceRGB = false)
 	int cmaps;
 	int extcode;
 
-	gft = DGifOpenFileName(filepara->file);
+	gft = DGifOpenFileName(filepara->file, 0);
 	if (gft == NULL)
 		return;
 	do
@@ -568,11 +568,11 @@ static void gif_load(Cfilepara* filepara, bool forceRGB = false)
 	}
 	while (rt != TERMINATE_RECORD_TYPE);
 
-	DGifCloseFile(gft);
+	DGifCloseFile(gft, 0);
 	return;
 ERROR_R:
 	eDebug("[ePicLoad] <Error gif>");
-	DGifCloseFile(gft);
+	DGifCloseFile(gft, 0);
 }
 
 //---------------------------------------------------------------------------------------------

Attached Files

•  01-workaround-compile-error-libgif.patch   758bytes   7 downloads

[peti]

Thanks Beeker, that worked, and I was able to build and boot an image for my VUUNO (with glibc 2.24). So far running fine. That strange issue with bcm7405/7413 seems to be gone. 

[christophecvr]

Hello to all and especially core members.

 

Now for further development about the upcoming pli5 still master next concerning gstreamer.

It will be gstreamer > = 1.0

 

Is it a good idea since now openpli-oe-core master-next and master-for-gcc5 is working with e2 next-master to remove all deprecated code related to gst < 1.0. ?

This would make it a lot easier to finally add mkv vob subtitle support and as far like possible based on gstreamer evolution also chapter support on m4v containers and so on ...

by gst >= 1.0 we are working with subtitle in sync (which was not possible by gst < 1.0)

 

Off course this for code by e2 next-master only.

[Beeker]

master-for-gcc5 is gstreamer 0.10.

 

It is openpli-4 with some updated devtools like ncurses, binutils,linux-utils..etc.

 

No need for that.

[christophecvr]

master-for-gcc5 is gstreamer 0.10.

 

It is openpli-4 with some updated devtools like ncurses, binutils,linux-utils..etc.

 

No need for that.

Oeps I thaught that master-for-gcc5 was the oe master-next but for build on machines who had gcc >= then 5.0 like ubuntu 16.04.

 

This means actually that last master-for-gcc5 is a kind off deprecated git recipe

Edited by christophecvr, 25 May 2016 - 21:05.

[Beeker]

Yes

 

It is just for building a openpli-4 image if your native compiler is gcc5.

 

Forget master-for-ggc5.

[Beeker]

BTW.

 

gcc6.1 is getting close in OE-core.Recipes are already present.

 

Keep my fingers crossed   Dreambox kernel... .