x86/64 : most gstreamer packages broken due to bump to 1.0

[Florent Thiery]

Due to the following packages still based on gstreamer-0.10, when enabling gstreamer together with e.g. gst-vaapi support building fails.

Packages depending on gstreamer 0.10:

• gst-vaapi
• gst-ducati
• gst-openmax
• gst-convenience
  
• gst-ffmpeg
• gst-bcmdec
• xbmc
• clutter-gst
• gst-auto-launch

Packages depending on gstreamer 1.0: 

• gst-plugins-base
  
• gst-plugins-good
  
• gst-plugins-bad
  
• gst-plugins-ugly
  
• gst-plugins-gl
• gst-libav (actually, replaces gst-ffmpeg)

Packages depending on unkown version of gstreamer (probably broken) :

• libnice
• gupnp-dnla
• qt
• libplayer
• baresip
• farsight
• wine

I tried checkouting the 0.10 gstreamer packages, but it doesn't build anymore with the upstream openbricks (i suspect, change of meta or toolchain that require updating the 0.10 packages meta/scripts).

The biggest issue here is that not every gstreamer package has been ported to 1.0, so bumping gstreamer to 1.0 breaks most hardware acceleration plugins. Ideally, i think that PKG_DEPENDS meta definitions should be able to include the version of the software it's depending on; the quick and dirty way to fix this would be to create 2 packages : gstreamer-0.10, gstreamer-1.0, gstreamer-plugins-good-0.10, gstreamer-plugins-good-1.0, etc... And update the meta information accordingly. 

However, this approach doesn't solve more complex cases, where a specific package would depend on an older dependancy version (e.g. let's say some gstreamer plugin package required gstreamer-0.10.29 instead of 0.10.34), but i would guess that would be overkill ...

The pandaboard faces this exact problem, and tom hacked the build script to force building an older version (i don't really understand how it works, notably because this is done after the make & make install), by echoing 0.10 to $ROOT/$TOOLCHAIN/gstversion, but it's not satisfactory IMO.

The good news is that gstreamer 1.0 has been designed to be parallelly installed to gstreamer-0.10, so i believe this is a good way to solve it. What do you think ?

Florent

[toml...@gmail.com]

Le 12/04/2013 15:55, Florent Thiery a écrit :
Hello,

Due to the following packages still based on gstreamer-0.10, when enabling gstreamer together with e.g. gst-vaapi support building fails.

:-(

Packages depending on gstreamer 0.10:

• gst-vaapi
• gst-ducati
• gst-openmax
• gst-convenience
  
• gst-ffmpeg
• gst-bcmdec
• xbmc

only for panda this one

• clutter-gst
• gst-auto-launch

Packages depending on gstreamer 1.0: 

• gst-plugins-base
  
• gst-plugins-good
  
• gst-plugins-bad
  
• gst-plugins-ugly
  
• gst-plugins-gl
• gst-libav (actually, replaces gst-ffmpeg)

Packages depending on unkown version of gstreamer (probably broken) :

• libnice
• gupnp-dnla
• qt
• libplayer
• baresip
• farsight
• wine

I tried checkouting the 0.10 gstreamer packages, but it doesn't build anymore with the upstream openbricks (i suspect, change of meta or toolchain that require updating the 0.10 packages meta/scripts).

The biggest issue here is that not every gstreamer package has been ported to 1.0, so bumping gstreamer to 1.0 breaks most hardware acceleration plugins. Ideally, i think that PKG_DEPENDS meta definitions should be able to include the version of the software it's depending on; the quick and dirty way to fix this would be to create 2 packages : gstreamer-0.10, gstreamer-1.0, gstreamer-plugins-good-0.10, gstreamer-plugins-good-1.0, etc... And update the meta information accordingly. 

We have something similar for xf86-video-nvidia, PKG_VERSION depends on target arch
we  can add this to meta files for gst* packages adapting it to our needs

However, this approach doesn't solve more complex cases, where a specific package would depend on an older dependancy version (e.g. let's say some gstreamer plugin package required gstreamer-0.10.29 instead of 0.10.34), but i would guess that would be overkill ...

I guess this can be achieved the same way but,
If build scripts need to be changed / modified changing PKG_VERSION of gstreamer, the best way is , I think, create new packages for 0.10 and 1.0 version of gstreamer

The pandaboard faces this exact problem, and tom hacked the build script to force building an older version (i don't really understand how it works, notably because this is done after the make & make install), by echoing 0.10 to $ROOT/$TOOLCHAIN/gstversion, but it's not satisfactory IMO.

We need it to install sub-package files into the right directory
But I'm agree that's an awful hack

The good news is that gstreamer 1.0 has been designed to be parallelly installed to gstreamer-0.10, so i believe this is a good way to solve it. What do you think ?

Florent

Regards,

Tom

--
You received this message because you are subscribed to the Google Groups "OpenBricks Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openbricks-dev...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Florent Thiery]

Hi,

 

We have something similar for xf86-video-nvidia, PKG_VERSION depends on target arch
we  can add this to meta files for gst* packages adapting it to our needs

However, this approach doesn't solve more complex cases, where a specific package would depend on an older dependancy version (e.g. let's say some gstreamer plugin package required gstreamer-0.10.29 instead of 0.10.34), but i would guess that would be overkill ...

I guess this can be achieved the same way but,
If build scripts need to be changed / modified changing PKG_VERSION of gstreamer, the best way is , I think, create new packages for 0.10 and 1.0 version of gstreamer

Yes, for the gstreamer-0.10 and 1.0, i also believe that's the best way to go; however, it doesn't solve the pandaboard case, where you actually patch the arch's package tree before building (from config/platforms/arm/omap4/packages, but then, what is the echoing 0.10 to $ROOT/$TOOLCHAIN/gstversion exactly for then ?), since the pandaboard requires a dedicated gstreamer-0.10 branch...

It's however good to see that you can "branch" the packages for a specific target, so this solves the specific pandaboard case; again, sorry for my limited understanding, but what is the $ROOT/$TOOLCHAIN/gstversion for ?

To sum up, what's to do:

1) create gstreamer-0.10 and gstreamer-1.0 packages instead of just gstreamer (and add -version to other gstreamer packages)

2) update meta files of 1.0 packages to depend on the corresponding one

3) re-create (/port) gstreamer-0.10 and -plugins meta information from last known commit and update of course meta

4) update the make menuconfig "system" to handle and allow to configure these new deps (i'm completely newbie on this) -- but in features/ what should be suggested ? gstreamer would be pointing to 1.0 ? to 0.10 ? arch dependent ?

Florent

[Thomas Genty]

Le 15/04/2013 10:02, Florent Thiery a écrit :

Hi,

 

We have something similar for xf86-video-nvidia, PKG_VERSION depends on target arch
we  can add this to meta files for gst* packages adapting it to our needs

However, this approach doesn't solve more complex cases, where a specific package would depend on an older dependancy version (e.g. let's say some gstreamer plugin package required gstreamer-0.10.29 instead of 0.10.34), but i would guess that would be overkill ...

I guess this can be achieved the same way but,
If build scripts need to be changed / modified changing PKG_VERSION of gstreamer, the best way is , I think, create new packages for 0.10 and 1.0 version of gstreamer

Yes, for the gstreamer-0.10 and 1.0, i also believe that's the best way to go; however, it doesn't solve the pandaboard case, where you actually patch the arch's package tree before building (from config/platforms/arm/omap4/packages, but then, what is the echoing 0.10 to $ROOT/$TOOLCHAIN/gstversion exactly for then ?), since the pandaboard requires a dedicated gstreamer-0.10 branch...

It's however good to see that you can "branch" the packages for a specific target, so this solves the specific pandaboard case; again, sorry for my limited understanding, but what is the $ROOT/$TOOLCHAIN/gstversion for ?

when you build gstreamer, you need to fix gstreamer-*.pc to point to correct directory (needed for other gst* packages)
see this commit : http://hg.openbricks.org/openbricks/rev/560470b22d33
before, it was hardcoded to 1.0 , so ...

Do you have a better idea ?

To sum up, what's to do:

1) create gstreamer-0.10 and gstreamer-1.0 packages instead of just gstreamer (and add -version to other gstreamer packages)

ok

2) update meta files of 1.0 packages to depend on the corresponding one

ok

3) re-create (/port) gstreamer-0.10 and -plugins meta information from last known commit and update of course meta

sure

4) update the make menuconfig "system" to handle and allow to configure these new deps (i'm completely newbie on this) -- but in features/ what should be suggested ? gstreamer would be pointing to 1.0 ? to 0.10 ? arch dependent ?

you said 0.10 is well supported so stay on 0.10 by default
if you have 2 sort of packages 0.10 and 1.0 we can add the possibility to select one, and auto select other gst* packages based on that

Florent

--

Tom

[Thomas Genty]

Le 15/04/2013 15:52, Thomas Genty a écrit :

Le 15/04/2013 10:02, Florent Thiery a écrit :

Hi,

 

We have something similar for xf86-video-nvidia, PKG_VERSION depends on target arch
we  can add this to meta files for gst* packages adapting it to our needs

However, this approach doesn't solve more complex cases, where a specific package would depend on an older dependancy version (e.g. let's say some gstreamer plugin package required gstreamer-0.10.29 instead of 0.10.34), but i would guess that would be overkill ...

I guess this can be achieved the same way but,
If build scripts need to be changed / modified changing PKG_VERSION of gstreamer, the best way is , I think, create new packages for 0.10 and 1.0 version of gstreamer

Yes, for the gstreamer-0.10 and 1.0, i also believe that's the best way to go; however, it doesn't solve the pandaboard case, where you actually patch the arch's package tree before building (from config/platforms/arm/omap4/packages, but then, what is the echoing 0.10 to $ROOT/$TOOLCHAIN/gstversion exactly for then ?), since the pandaboard requires a dedicated gstreamer-0.10 branch...

It's however good to see that you can "branch" the packages for a specific target, so this solves the specific pandaboard case; again, sorry for my limited understanding, but what is the $ROOT/$TOOLCHAIN/gstversion for ?

when you build gstreamer, you need to fix gstreamer-*.pc to point to correct directory (needed for other gst* packages)
see this commit : http://hg.openbricks.org/openbricks/rev/560470b22d33
before, it was hardcoded to 1.0 , so ...

Do you have a better idea ?

To sum up, what's to do:

1) create gstreamer-0.10 and gstreamer-1.0 packages instead of just gstreamer (and add -version to other gstreamer packages)

ok

done

2) update meta files of 1.0 packages to depend on the corresponding one

ok

done

3) re-create (/port) gstreamer-0.10 and -plugins meta information from last known commit and update of course meta

sure

partially done
Some packages are not ported ....

4) update the make menuconfig "system" to handle and allow to configure these new deps (i'm completely newbie on this) -- but in features/ what should be suggested ? gstreamer would be pointing to 1.0 ? to 0.10 ? arch dependent ?

you said 0.10 is well supported so stay on 0.10 by default
if you have 2 sort of packages 0.10 and 1.0 we can add the possibility to select one, and auto select other gst* packages based on that

done too

Note : you can even build version 1.0 and 0.10 in parallel.
(tested on panda)

Cheers

Tom