Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Josselin Poiret]

Hi Andreas,

Andreas Enge  writes:

> Am Fri, Apr 07, 2023 at 05:24:41PM -0400 schrieb Maxim Cournoyer:
>> Reviewing the list of newly broken things, there was a flaky test spot
>> in python-pyopenssl (IIRC!) that led me to attempt to upgrade
>> python-cryptography, which is a bit more involved than I'd like.
>
> Okay, so I cherry-picked your staging commits for extra-cmake-modules
> and kcodecs to core-updates, which should bring us further in building KDE
> (once gtk+ is sorted out).

Is gtk+@3 not sorted out?  I have it built on my machine.  gtk@4 is also
available from bordeaux.

Best,
-- 
Josselin Poiret


signature.asc
Description: PGP signature

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Fri, Apr 07, 2023 at 05:24:41PM -0400 schrieb Maxim Cournoyer:
> Reviewing the list of newly broken things, there was a flaky test spot
> in python-pyopenssl (IIRC!) that led me to attempt to upgrade
> python-cryptography, which is a bit more involved than I'd like.

Okay, so I cherry-picked your staging commits for extra-cmake-modules
and kcodecs to core-updates, which should bring us further in building KDE
(once gtk+ is sorted out).

Andreas

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Maxim Cournoyer]

Hi Andreas,

Andreas Enge  writes:

> Hello Maxim,
>
> Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
>> It'd be useful if people tested it by reconfiguring their systems with
>> it or updating their profiles, and report any issues, as I'd like to
>> merge this branch into master in about a week time, if there are no
>> blockers.
>
> maybe you could proceed with the merge? Then we could also advance
> on core-updates.

Reviewing the list of newly broken things, there was a flaky test spot
in python-pyopenssl (IIRC!) that led me to attempt to upgrade
python-cryptography, which is a bit more involved than I'd like.

As a happy side effect though, I think it'll fix many of the rust
package failures seen on staging that are building on master.

To be continued...

-- 
Thanks,
Maxim

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Hello Maxim,

Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
> It'd be useful if people tested it by reconfiguring their systems with
> it or updating their profiles, and report any issues, as I'd like to
> merge this branch into master in about a week time, if there are no
> blockers.

maybe you could proceed with the merge? Then we could also advance
on core-updates.

Andreas

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Hello Maxim!

Am Wed, Mar 29, 2023 at 08:32:08AM -0400 schrieb Maxim Cournoyer:
> I'll
> gladly volunteer to do the tricky merge after staging is merged into
> master (and removed).

Great, thanks! It should be quite feasible when paying attention to this
special case, but I only did a merge once and do not feel confident about it.

Concerning kcodecs, attached is a patch that disables the test (but keeps
the class in that is supposed to work around the fixed Qt bug; so it is
quite possible that this class is wrong currently). However I did compile
a KDE program with it and launched it successfully, so I would be in favour
of applying the patch to staging (and thus later merge it to core-updates).
What do you think?

Apart from this, all of my profile is built (and available through CI),
so I would be happy with the merge.

Andreas

>From f8694bf4f32ea8f817fbc32abe28de52472b61f4 Mon Sep 17 00:00:00 2001
Message-Id: 

From: Andreas Enge 
Date: Wed, 29 Mar 2023 14:50:49 +0200
Subject: [PATCH] gnu: kcodecs: Disable obsolete test.

* gnu/packages/patches/kcodecs-5.98-drop-test.patch: New file.
* gnu/packages/kde-frameworks.scm (kcodecs): Add patch.
* gnu/local.mk (dist_patch_DATA): Register patch.
---
 gnu/local.mk  |  1 +
 gnu/packages/kde-frameworks.scm   |  3 ++-
 .../patches/kcodecs-5.98-drop-test.patch  | 20 +++
 3 files changed, 23 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/kcodecs-5.98-drop-test.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 65662f8667..45c786f136 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1397,6 +1397,7 @@ dist_patch_DATA = 
\
   %D%/packages/patches/lightdm-vncserver-check.patch   \
   %D%/packages/patches/lightdm-vnc-color-depth.patch   \
   %D%/packages/patches/localed-xorg-keyboard.patch \
+  %D%/packages/patches/kcodecs-5.98-drop-test.patch\
   %D%/packages/patches/kcontacts-incorrect-country-name.patch  \
   %D%/packages/patches/kde-cli-tools-delay-mime-db.patch   \
   %D%/packages/patches/kdiagram-Fix-missing-link-libraries.patch \
diff --git a/gnu/packages/kde-frameworks.scm b/gnu/packages/kde-frameworks.scm
index 10b8ac0134..65c4ccb4f4 100644
--- a/gnu/packages/kde-frameworks.scm
+++ b/gnu/packages/kde-frameworks.scm
@@ -532,7 +532,8 @@ (define-public kcodecs
 name "-" version ".tar.xz"))
   (sha256
(base32
-"0n10r7s9r25xp7vlym41qi421kld00niig73yark7yghj0r41jcz"
+"0n10r7s9r25xp7vlym41qi421kld00niig73yark7yghj0r41jcz"))
+  (patches (search-patches "kcodecs-5.98-drop-test.patch"
 (build-system cmake-build-system)
 (native-inputs
  (list extra-cmake-modules gperf qttools-5))
diff --git a/gnu/packages/patches/kcodecs-5.98-drop-test.patch 
b/gnu/packages/patches/kcodecs-5.98-drop-test.patch
new file mode 100644
index 00..fbb9bf42bc
--- /dev/null
+++ b/gnu/packages/patches/kcodecs-5.98-drop-test.patch
@@ -0,0 +1,20 @@
+diff -u -r kcodecs-5.98.0.alt/autotests/CMakeLists.txt 
kcodecs-5.98.0/autotests/CMakeLists.txt
+--- kcodecs-5.98.0.alt/autotests/CMakeLists.txt2023-03-29 
12:40:12.904883966 +0200
 kcodecs-5.98.0/autotests/CMakeLists.txt2023-03-29 12:40:28.952883548 
+0200
+@@ -25,16 +25,6 @@
+ LINK_LIBRARIES KF5::Codecs Qt${QT_MAJOR_VERSION}::Test ${_qt5_compat_libs}
+ )
+ 
+-ecm_add_test(
+-${CMAKE_SOURCE_DIR}/src/kusasciitextcodec.cpp
+-kusasciitextcodectest.cpp
+-TEST_NAME kusasciitextcodectest
+-LINK_LIBRARIES Qt${QT_MAJOR_VERSION}::Test ${_qt5_compat_libs}
+-)
+-target_include_directories(kusasciitextcodectest
+-PRIVATE "${CMAKE_SOURCE_DIR}/src"
+-)
+-
+ # Benchmark, compiled, but not run automatically with ctest
+ add_executable(base64benchmark base64benchmark.cpp)
+ target_link_libraries(base64benchmark KF5::Codecs Qt${QT_MAJOR_VERSION}::Test)
-- 
2.39.2

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Maxim Cournoyer]

Hi Andreas!

Andreas Enge  writes:

> Hello,
>
> Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
>> I've updated the following dependencies in a group (to try to make
>> things a bit more efficient) on the staging branch; the motivation
>> originally stemmed from the latest Jami now requiring FFmpeg 6.
>
> that sounds good if it means we will get rid of the branch for good soon :-)
> Otherwise I think it would have been better to work on merging staging and
> core-updates and then use a feature branch.

Yeah, I was thinking about removing the staging branch afterward, to
encourage the new teams workflow.

> However I am a bit afraid of repercussions on core-updates (originally I
> had planned to first merge back staging into master, but somehow we ended
> up working on core-updates first...). I have no idea what is the ordering
> between packages in master, staging and core-updates - it may well be
> possible that some packages are newer in staging, others in core-updates.
> Or that they are the same in both, but with different patches.
> For instance, I also updated qt to 5.15.8 on core-updates, but differently,
> using a global version variable for making sure to update everything at
> once. I think this is preferable. In any case, merging this will be a bit
> difficult to sort out without mixing bits from the two parts.
> So it would be nice if you could carefully merge master into core-updates
> after the staging merge.

Apologies for not noticing about the Qt update on core-updates; the
change was motivated by the open reports on our bug-guix tracker.  I'll
gladly volunteer to do the tricky merge after staging is merged into
master (and removed).  The reason I opted to keep the version
per-package instead of in a %qt5-version global variable was initially
for tooling; 'guix refresh --update' doesn't work otherwise; but then I
noticed that it doesn't work anyway with the 'qt-urls' scheme (it
doesn't find a newer release), so I guess I'll keep your approach here.

> A typo in the title confused me, but it is gstreamer@1.22.1 instead of
> @2.22, which is hopefully less of a change ;-)

Eh :-).  Yes, it's 1.22.1.

> Concerning ffmpeg, we now have 5 different versions of it; @2, @3 and @5
> have almost no dependents, @4 and @6 have many. It would be nice to sort
> this out later and hopefully drop most of them.

Agreed; the 5 to 6 transition is advertised as very uneventful (outside
of Mozilla stuff), with only a few deprecated bits that may cause
problems, such as:

1. 
https://github.com/FFmpeg/FFmpeg/commit/dd846bc4a9163f875cc2c4e99325c1a7b4ab8e7d
2. 
https://github.com/FFmpeg/FFmpeg/commit/8f72bb866e47bcb57586608086c77cf0a2e2f21a

Which easily fixed with a simple substitution, so hopefully we can get
rid of ffmpeg@5 soon.

-- 
Thanks,
Maxim

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Wed, Mar 29, 2023 at 11:53:22AM +0200 schrieb Andreas Enge:
> The file was removed in commit
> commit 2e7dc813c2b4672f34d135755e928c52c15a1c3a
> Author: Volker Krause 
> Date:   Sun Feb 19 20:15:29 2023 +0100
> Remove QTextCodec leftovers
> This is all unused internal API now.
> of kcodecs, together with lots of other changes (wc shows 944 lines).

> It is not part of the latest kcodecs release 5.104.0, made after the commit.

Sorry, this is not what I mean:
The *commit* is not part of the latest release,
so the *file* is still present in the latest release.
It is thus not enough to simply update kcodecs (and I do not know to which
extent this would even be feasible inside KDE, or whether we would need to
update everything at once; probably the latter).

Andreas

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Wed, Mar 29, 2023 at 11:35:24AM +0200 schrieb Andreas Enge:
> FAIL!  : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values 
> are not the same
>Actual   (failConverterState.invalidChars): 1
>Expected (0)  : 0
>Loc: 
> [/tmp/guix-build-kcodecs-5.98.0.drv-0/kcodecs-5.98.0/autotests/kusasciitextcodectest.cpp(56)]
> 86% tests passed, 1 tests failed out of 7

Looking at the file, it is a workaround for this Qt bug:
   https://bugreports.qt.io/browse/QTBUG-83081
which was fixed in 5.17.0.

The file was removed in commit
commit 2e7dc813c2b4672f34d135755e928c52c15a1c3a
Author: Volker Krause 
Date:   Sun Feb 19 20:15:29 2023 +0100
Remove QTextCodec leftovers
This is all unused internal API now.
of kcodecs, together with lots of other changes (wc shows 944 lines).

It is not part of the latest kcodecs release 5.104.0, made after the commit.

I do not know whether it would be safe to just disable the test for the
time being.

Andreas

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Wed, Mar 29, 2023 at 11:35:24AM +0200 schrieb Andreas Enge:
> FAIL!  : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values 
> are not the same

We are not the only ones:
   https://bugs.gentoo.org/885615
for version 5.99, but there is no patch.

Andreas

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
> It'd be useful if people tested it by reconfiguring their systems with
> it or updating their profiles, and report any issues

Supposedly the Qt update breaks kcodecs, which in turn breaks most of KDE.
This issue is also present on core-updates, so sorting it out would be
really helpful!

Apart from that all packages in my profile build.

Andreas

FAIL!  : KUsAsciiTextCodecTest::testBrokenBuiltinEncoding() Compared values are 
not the same
   Actual   (failConverterState.invalidChars): 1
   Expected (0)  : 0
   Loc: 
[/tmp/guix-build-kcodecs-5.98.0.drv-0/kcodecs-5.98.0/autotests/kusasciitextcodectest.cpp(56)]
86% tests passed, 1 tests failed out of 7

Total Test time (real) =   2.58 sec

The following tests FAILED:
  7 - kusasciitextcodectest (Failed)
Errors while running CTest
make: *** [Makefile:139: test] Error 8

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("test" "-j" "4") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 2.6 seconds
command "make" "test" "-j" "4" failed with status 2
builder for `/gnu/store/hj533y1br1gmm31lgrnj0jjaa9nq1qps-kcodecs-5.98.0.drv' 
failed with exit code 1
build of /gnu/store/hj533y1br1gmm31lgrnj0jjaa9nq1qps-kcodecs-5.98.0.drv failed
View build log at 
'/var/log/guix/drvs/hj/533y1br1gmm31lgrnj0jjaa9nq1qps-kcodecs-5.98.0.drv.gz'.

Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Andreas Enge]

Hello,

Am Tue, Mar 28, 2023 at 11:10:01PM -0400 schrieb Maxim Cournoyer:
> I've updated the following dependencies in a group (to try to make
> things a bit more efficient) on the staging branch; the motivation
> originally stemmed from the latest Jami now requiring FFmpeg 6.

that sounds good if it means we will get rid of the branch for good soon :-)
Otherwise I think it would have been better to work on merging staging and
core-updates and then use a feature branch.

However I am a bit afraid of repercussions on core-updates (originally I
had planned to first merge back staging into master, but somehow we ended
up working on core-updates first...). I have no idea what is the ordering
between packages in master, staging and core-updates - it may well be
possible that some packages are newer in staging, others in core-updates.
Or that they are the same in both, but with different patches.
For instance, I also updated qt to 5.15.8 on core-updates, but differently,
using a global version variable for making sure to update everything at
once. I think this is preferable. In any case, merging this will be a bit
difficult to sort out without mixing bits from the two parts.
So it would be nice if you could carefully merge master into core-updates
after the staging merge.

A typo in the title confused me, but it is gstreamer@1.22.1 instead of
@2.22, which is hopefully less of a change ;-)

Concerning ffmpeg, we now have 5 different versions of it; @2, @3 and @5
have almost no dependents, @4 and @6 have many. It would be nice to sort
this out later and hopefully drop most of them.

Andreas

gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging

[Maxim Cournoyer]

Hi,

I've updated the following dependencies in a group (to try to make
things a bit more efficient) on the staging branch; the motivation
originally stemmed from the latest Jami now requiring FFmpeg 6.

It'd be useful if people tested it by reconfiguring their systems with
it or updating their profiles, and report any issues, as I'd like to
merge this branch into master in about a week time, if there are no
blockers.

-- 
Thanks,
Maxim

Re: Browsers and Gstreamer plugins

[Maxim Cournoyer]

Hello Jack,

Thank you for posting this well written piece here.

Jack Hill  writes:

> Hi Guix,
>
> While we have made progress on #52375 [0], the way forward remains
> unclear. In summary, WebKitGTK expects certain GStreamer plugins to be 
> available. Depending on which plugins are missing and the web page
> content, the process corresponding to a browser tab may even crash. 
> Currently, we expect folks to manually install the necessary plugins
> into their profile/environment.

That sucks; but it really is webkitgtk/browsers' fault; they should have
better reporting so that users know what is missing instead of obtusely
crashing a tab.

> Complicating matters, it is not clear to me which plugins WebKitGTK
> needs or optionally makes use of. At least some of the needed plugins
> are from gst-plugins-bad, which upstream considers to be of lesser
> (code) quality [1]. gst-plugins-bad is also a large dependency. Adding
> it would increase the closure size of browsers by almost 1GiB!
>
> [0] https://issues.guix.gnu.org/52375
> [1]
> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/ca8068c6d793d7aaa6f2e2cc6324fdedfe2f33fa/README#L80

1 GiB for code deemed of even worst quality than even the 'ugly' plugins
(they're literally at the bottom of the chart, quality-wise) doesn't
sound too appealing :-) [0].

[0]  https://raw.githubusercontent.com/GStreamer/gstreamer/master/README

> I believe that what I have written above is more or less factual. Now
> for my opinion: I think that we should make browsers work out of the
> box on commonly-encountered web content.

How would you define "commonly-encountered" web content?  How will we
handle bug reports of "tab crashed on site X" because a plugin we
thought obscure is used by someone?  It's a bit of a slippery slope
where we may end up wrapping all/too many plugins, because of the issue
I raised in my preceding paragraph (bad reporting from webkitgtk
itself).

Plugins exist for the very reason to allow end users to extend
functionalities the way they see fit, so it seems a bit backward to me
to "wrap plugins in", which makes them non-optional onto users.  On
other systems, they are typically "recommended" but not wrapped in a way
that makes it difficult for users to opt out of them.

> To that end, I propose that
> we wrap WebKitGTK-powered browsers so that they can find the necessary
> plugins. I have attached a proof-of-concept patch that does just that
> for Vimb. I used the gst-plugins/selection procedure [2] to to add
> just one plugin from gst-plugins-bad that fixed the crash I was seeing
> in #52374.
>
> Size comparisons:
>
> Existing Vimb: 1397.5 MiB
> Vimb with my patch: 1409.9 MiB
> Vimb with all of gst-plugins-bad: 2298.6 MiB

This looks reasonable, space wise.

> Of course this is just the bare-minimum set of plugins. We may want to
> work with WebKitGTK upstream to determine any additional ones that we 
> should be including.
>
> [2] The patch depends on the fix for gst-plugins/selection that I
> submitted in https://issues.guix.gnu.org/52730
>
> A note on the approach of wrapping browsers rather than somehow
> including the plugins in WebKitGTK. It is much more obvious and
> straight forward (to me at least) to wrap the browser executable. Also
> WebKitGTK could in theory be used to render content that comes from a
> controlled environment, not the web, and therefore doesn't need the
> "web plugins". A downside to doing it this way is that each browser
> would need to be wrapped in the same set of plugins. Perhaps we can
> factor that out so that the plugin list only has to be maintained in
> one place.
>
>
> Questions and comments? How shall we move forward? Is it ok to wrap
> browsers in this way?

I sympathize with the goal of improving our users experience (by
shipping browsers that don't crash mysteriously left and right), but I'm
not satisfied with the solution of wrapping plugins.  Could we instead
try to fast-forward work that has happened in webkitgtk to produce
better diagnostics about missing plugins?  Such as [1], which has a
patch (with comments on).  It's not a panacea, but having errors about
missing plugins/functionality appear on stderr would be an improvement.
We should also create tickets upstream in webkitgtk-based browsers
requesting that they report missing plugins gracefully in their user
interfaces.

[1]  https://bugs.webkit.org/show_bug.cgi?id=233949

If all this is done and documented and in the waiting queue, then we
could proceed with wrap browsers with a minimal set of plugins as a
stopgap/temporary measure until the upstream issues get resolved.

What do you think?

Thanks,

Maxim

Browsers and Gstreamer plugins

[Jack Hill]

Hi Guix,

While we have made progress on #52375 [0], the way forward remains 
unclear. In summary, WebKitGTK expects certain GStreamer plugins to be 
available. Depending on which plugins are missing and the web page 
content, the process corresponding to a browser tab may even crash. 
Currently, we expect folks to manually install the necessary plugins into 
their profile/environment.


Complicating matters, it is not clear to me which plugins WebKitGTK needs 
or optionally makes use of. At least some of the needed plugins are from 
gst-plugins-bad, which upstream considers to be of lesser (code) quality 
[1]. gst-plugins-bad is also a large dependency. Adding it would increase 
the closure size of browsers by almost 1GiB!


[0] https://issues.guix.gnu.org/52375
[1] 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/blob/ca8068c6d793d7aaa6f2e2cc6324fdedfe2f33fa/README#L80

I believe that what I have written above is more or less factual. Now for 
my opinion: I think that we should make browsers work out of the box on 
commonly-encountered web content. To that end, I propose that we wrap 
WebKitGTK-powered browsers so that they can find the necessary plugins. I 
have attached a proof-of-concept patch that does just that for Vimb. I 
used the gst-plugins/selection procedure [2] to to add just one plugin 
from gst-plugins-bad that fixed the crash I was seeing in #52374.


Size comparisons:

Existing Vimb: 1397.5 MiB
Vimb with my patch: 1409.9 MiB
Vimb with all of gst-plugins-bad: 2298.6 MiB

Of course this is just the bare-minimum set of plugins. We may want to 
work with WebKitGTK upstream to determine any additional ones that we 
should be including.


[2] The patch depends on the fix for gst-plugins/selection that I 
submitted in https://issues.guix.gnu.org/52730


A note on the approach of wrapping browsers rather than somehow including 
the plugins in WebKitGTK. It is much more obvious and straight forward (to 
me at least) to wrap the browser executable. Also WebKitGTK could in 
theory be used to render content that comes from a controlled environment, 
not the web, and therefore doesn't need the "web plugins". A downside to 
doing it this way is that each browser would need to be wrapped in the 
same set of plugins. Perhaps we can factor that out so that the plugin 
list only has to be maintained in one place.


Questions and comments? How shall we move forward? Is it ok to wrap 
browsers in this way?


Best,
JackFrom 44971b5c5c2d355ed6b270810ee7fcb16b106edb Mon Sep 17 00:00:00 2001
From: Jack Hill 
Date: Wed, 22 Dec 2021 11:07:36 -0500
Subject: [PATCH] gnu: vimb: Wrap with required gstreamer plugins.

* gnu/package/web-browsers.scm (vimb)[make-flags]: Swith to using gexps.
[phases]: Add 'wrap-gst-plugins.
[inputs]: Remove input labels and add debugutils from gst-plugins-bad.
---
 gnu/packages/web-browsers.scm | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/gnu/packages/web-browsers.scm b/gnu/packages/web-browsers.scm
index 1a56d9a933..26151fb56f 100644
--- a/gnu/packages/web-browsers.scm
+++ b/gnu/packages/web-browsers.scm
@@ -44,6 +44,7 @@ (define-module (gnu packages web-browsers)
   #:use-module (guix build-system go)
   #:use-module (guix build-system python)
   #:use-module (guix download)
+  #:use-module (guix gexp)
   #:use-module (guix git-download)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
@@ -68,6 +69,7 @@ (define-module (gnu packages web-browsers)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages gnome-xyz)
   #:use-module (gnu packages gnupg)
+  #:use-module (gnu packages gstreamer)
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages image)
   #:use-module (gnu packages libevent)
@@ -551,17 +553,24 @@ (define-public vimb
(file-name (git-file-name name version
 (build-system glib-or-gtk-build-system)
 (arguments
- '(#:tests? #f  ; no tests
-   #:make-flags (list "CC=gcc"
-  "DESTDIR="
-  (string-append "PREFIX=" %output))
-   #:phases
-   (modify-phases %standard-phases
- (delete 'configure
+ (list #:tests? #f  ; no tests
+   #:make-flags #~(list "CC=gcc"
+"DESTDIR="
+(string-append "PREFIX=" #$output))
+   #:phases
+   #~(modify-phases %standard-phases
+   (delete 'configure)
+   (add-after 'glib-or-gtk-wrap 'wrap-gst-plugins
+ (lambda _
+   (wrap-program (string-append #$output "/bin/vimb")
+ `("GST_PLUGIN_SYSTEM_PATH" suffix
+   (,(getenv "GST_PLUGIN_SYSTEM_PATH")
 (inputs
- `(("glib-networking" ,gli

Re: 01/01: gnu: gstreamer: Skip failing test on 32-bit systems.

[Marius Bakke]

Mark H Weaver  writes:

> Marius Bakke  writes:
>
>> Mark H Weaver  writes:
>>
>>> Hi Marius,
>>>
>>> guix-comm...@gnu.org writes:
>>>
>>>> mbakke pushed a commit to branch staging
>>>> in repository guix.
>>>>
>>>> commit 2a9d89afb6fb869dd2bdf1e9f710f487786930fc
>>>> Author: Marius Bakke 
>>>> Date:   Thu Jun 13 14:08:32 2019 +0200
>>>>
>>>> gnu: gstreamer: Skip failing test on 32-bit systems.
>>>> 
>>>> * gnu/packages/gstreamer.scm (gstreamer)[arguments]: When building for 
>>>> a
>>>> 32-bit system, add #:phases.
>>> [...]
>>>> +   ,@(if (not (target-64bit?))
>>>> +   ;; Skip test that fails on 32-bit systems:
>>>> +   ;; 
>>>> <https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316>.
>>>> +   `(#:phases (modify-phases %standard-phases
>>>> +(add-before 'check 'disable-gstbufferpool-test
>>>> +  (lambda _
>>>> +(substitute* "tests/check/Makefile"
>>>> +  (("^[[:blank:]]+gst/gstbufferpool.*$")
>>>> +   ""))
>>>> +  #t
>>>> +   '(
>>>
>>> This might be sweeping a critical bug under the rug.  Does
>>>
>>>   Unexpected critical/warning: gst_buffer_resize_range:
>>> assertion 'bufmax >= bufoffs + offset + size' failed
>>>
>>> really sound like something we can safely ignore?
>>
>> I think you are right to be concerned.  I found the upstream commit that
>> introduced the problem.  See
>> <https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316#note_176773>.
>
> *ping*?

Sorry, I've been on holiday.  Will get it sorted this weekend.

Thanks!


signature.asc
Description: PGP signature

Re: 01/01: gnu: gstreamer: Skip failing test on 32-bit systems.

[Mark H Weaver]

Hi Marius,

Marius Bakke  writes:

> Mark H Weaver  writes:
>
>> guix-comm...@gnu.org writes:
>>
>>> mbakke pushed a commit to branch staging
>>> in repository guix.
>>>
>>> commit 2a9d89afb6fb869dd2bdf1e9f710f487786930fc
>>> Author: Marius Bakke 
>>> Date:   Thu Jun 13 14:08:32 2019 +0200
>>>
>>> gnu: gstreamer: Skip failing test on 32-bit systems.
>>> 
>>> * gnu/packages/gstreamer.scm (gstreamer)[arguments]: When building for a
>>> 32-bit system, add #:phases.
>> [...]
>>> +   ,@(if (not (target-64bit?))
>>> +   ;; Skip test that fails on 32-bit systems:
>>> +   ;; 
>>> <https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316>.
>>> +   `(#:phases (modify-phases %standard-phases
>>> +(add-before 'check 'disable-gstbufferpool-test
>>> +  (lambda _
>>> +(substitute* "tests/check/Makefile"
>>> +  (("^[[:blank:]]+gst/gstbufferpool.*$")
>>> +   ""))
>>> +  #t
>>> +   '(
>>
>> This might be sweeping a critical bug under the rug.  Does
>>
>>   Unexpected critical/warning: gst_buffer_resize_range:
>> assertion 'bufmax >= bufoffs + offset + size' failed
>>
>> really sound like something we can safely ignore?
>
> I think you are right to be concerned.  I found the upstream commit that
> introduced the problem.  See
> <https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316#note_176773>.

Thanks for checking.

> Do you have a preference for reverting the faulty commits, or going back
> to 1.14.5?

It depends on the nature of the faulty commit, whether other later
commits somehow depend on it, and whether other potential security holes
were fixed since 1.14.5.  Maybe use 1.14.5, possibly with cherry-picked
fixes applied as patches?  I'm not sure, and I don't have time to
investigate right now, but I trust your judgement to choose the best
available option.

   Thank you!
  Mark

Re: 01/01: gnu: gstreamer: Skip failing test on 32-bit systems.

[Marius Bakke]

Mark,

Mark H Weaver  writes:

> Hi Marius,
>
> guix-comm...@gnu.org writes:
>
>> mbakke pushed a commit to branch staging
>> in repository guix.
>>
>> commit 2a9d89afb6fb869dd2bdf1e9f710f487786930fc
>> Author: Marius Bakke 
>> Date:   Thu Jun 13 14:08:32 2019 +0200
>>
>> gnu: gstreamer: Skip failing test on 32-bit systems.
>> 
>> * gnu/packages/gstreamer.scm (gstreamer)[arguments]: When building for a
>> 32-bit system, add #:phases.
> [...]
>> +   ,@(if (not (target-64bit?))
>> +   ;; Skip test that fails on 32-bit systems:
>> +   ;; 
>> <https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316>.
>> +   `(#:phases (modify-phases %standard-phases
>> +(add-before 'check 'disable-gstbufferpool-test
>> +  (lambda _
>> +(substitute* "tests/check/Makefile"
>> +  (("^[[:blank:]]+gst/gstbufferpool.*$")
>> +   ""))
>> +  #t
>> +   '(
>
> This might be sweeping a critical bug under the rug.  Does
>
>   Unexpected critical/warning: gst_buffer_resize_range:
> assertion 'bufmax >= bufoffs + offset + size' failed
>
> really sound like something we can safely ignore?

I think you are right to be concerned.  I found the upstream commit that
introduced the problem.  See
<https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316#note_176773>.

Do you have a preference for reverting the faulty commits, or going back
to 1.14.5?

Thanks for noticing,
Marius


signature.asc
Description: PGP signature

Re: 01/01: gnu: gstreamer: Skip failing test on 32-bit systems.

[Mark H Weaver]

Hi Marius,

guix-comm...@gnu.org writes:

> mbakke pushed a commit to branch staging
> in repository guix.
>
> commit 2a9d89afb6fb869dd2bdf1e9f710f487786930fc
> Author: Marius Bakke 
> Date:   Thu Jun 13 14:08:32 2019 +0200
>
> gnu: gstreamer: Skip failing test on 32-bit systems.
> 
> * gnu/packages/gstreamer.scm (gstreamer)[arguments]: When building for a
> 32-bit system, add #:phases.
[...]
> +   ,@(if (not (target-64bit?))
> +   ;; Skip test that fails on 32-bit systems:
> +   ;; 
> <https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/316>.
> +   `(#:phases (modify-phases %standard-phases
> +(add-before 'check 'disable-gstbufferpool-test
> +  (lambda _
> +(substitute* "tests/check/Makefile"
> +  (("^[[:blank:]]+gst/gstbufferpool.*$")
> +   ""))
> +  #t
> +   '(

This might be sweeping a critical bug under the rug.  Does

  Unexpected critical/warning: gst_buffer_resize_range:
assertion 'bufmax >= bufoffs + offset + size' failed

really sound like something we can safely ignore?

  Mark

Re: 02/02: gnu: gstreamer: Update to 1.10.3.

[Leo Famulari]

On Thu, Feb 02, 2017 at 12:50:22AM -0500, Mark H Weaver wrote:
> Unfortunately, gst-plugins-base-1.10.3 has failed its test suite on i686
> three times in a row on Hydra, which leaves i686 users in a very bad
> spot, since modern web browsers, media players, and desktop environments
> become dependency failures.
> 
>   https://hydra.gnu.org/build/1824127
> 
> If we can't find a proper fix soon, we may need to revert this change.

Gstreamer 1.10.3 fixed a large number of bugs with potential security
implications:

http://seclists.org/oss-sec/2017/q1/258

So, hopefully we can find a fix for i686 platforms quickly so users can
get those changes.


signature.asc
Description: PGP signature

Re: 02/02: gnu: gstreamer: Update to 1.10.3.

[Marius Bakke]

Marius Bakke <mba...@fastmail.com> writes:

> Mark H Weaver <m...@netris.org> writes:
>
>> Hi,
>>
>> mba...@fastmail.com (Marius Bakke) writes:
>>
>>> mbakke pushed a commit to branch master
>>> in repository guix.
>>>
>>> commit 3e32eeb2478a9d3b46a2e858fdc416420bffe302
>>> Author: Marius Bakke <mba...@fastmail.com>
>>> Date:   Wed Feb 1 15:16:07 2017 +0100
>>>
>>> gnu: gstreamer: Update to 1.10.3.
>>> 
>>> * gnu/packages/gstreamer.scm (gstreamer): Update to 1.10.3.
>>> (gst-plugins-base): Likewise.
>>> (gst-plugins-good): Likewise.
>>> (gst-plugins-bad): Likewise.
>>> (gst-plugins-ugly): Likewise.
>>> (gst-libav): Likewise.
>>> (python-gst): Likewise.
>>
>> Unfortunately, gst-plugins-base-1.10.3 has failed its test suite on i686
>> three times in a row on Hydra, which leaves i686 users in a very bad
>> spot, since modern web browsers, media players, and desktop environments
>> become dependency failures.
>>
>>   https://hydra.gnu.org/build/1824127
>>
>> If we can't find a proper fix soon, we may need to revert this change.
>
> I can reproduce it with `guix build --system=i686-linux` on x86_64.

This was fixed upstream a few hours ago:

https://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=5e2e111627871c566ffc6607eda8f4ef4699d040

I pushed this patch as fe241868e39d102f074805b38d6621435f25.


signature.asc
Description: PGP signature

Re: 02/02: gnu: gstreamer: Update to 1.10.3.

[Marius Bakke]

Mark H Weaver <m...@netris.org> writes:

> Hi,
>
> mba...@fastmail.com (Marius Bakke) writes:
>
>> mbakke pushed a commit to branch master
>> in repository guix.
>>
>> commit 3e32eeb2478a9d3b46a2e858fdc416420bffe302
>> Author: Marius Bakke <mba...@fastmail.com>
>> Date:   Wed Feb 1 15:16:07 2017 +0100
>>
>> gnu: gstreamer: Update to 1.10.3.
>> 
>> * gnu/packages/gstreamer.scm (gstreamer): Update to 1.10.3.
>> (gst-plugins-base): Likewise.
>> (gst-plugins-good): Likewise.
>> (gst-plugins-bad): Likewise.
>> (gst-plugins-ugly): Likewise.
>> (gst-libav): Likewise.
>> (python-gst): Likewise.
>
> Unfortunately, gst-plugins-base-1.10.3 has failed its test suite on i686
> three times in a row on Hydra, which leaves i686 users in a very bad
> spot, since modern web browsers, media players, and desktop environments
> become dependency failures.
>
>   https://hydra.gnu.org/build/1824127
>
> If we can't find a proper fix soon, we may need to revert this change.

I can reproduce it with `guix build --system=i686-linux` on x86_64.

Reverting is not a good option due to:

http://seclists.org/oss-sec/2017/q1/284

Will try to figure out what's going on.


signature.asc
Description: PGP signature

Re: 02/02: gnu: gstreamer: Update to 1.10.3.

[Mark H Weaver]

Hi,

mba...@fastmail.com (Marius Bakke) writes:

> mbakke pushed a commit to branch master
> in repository guix.
>
> commit 3e32eeb2478a9d3b46a2e858fdc416420bffe302
> Author: Marius Bakke <mba...@fastmail.com>
> Date:   Wed Feb 1 15:16:07 2017 +0100
>
> gnu: gstreamer: Update to 1.10.3.
> 
> * gnu/packages/gstreamer.scm (gstreamer): Update to 1.10.3.
> (gst-plugins-base): Likewise.
> (gst-plugins-good): Likewise.
> (gst-plugins-bad): Likewise.
> (gst-plugins-ugly): Likewise.
> (gst-libav): Likewise.
> (python-gst): Likewise.

Unfortunately, gst-plugins-base-1.10.3 has failed its test suite on i686
three times in a row on Hydra, which leaves i686 users in a very bad
spot, since modern web browsers, media players, and desktop environments
become dependency failures.

  https://hydra.gnu.org/build/1824127

If we can't find a proper fix soon, we may need to revert this change.

Regards,
  Mark

Re: [PATCH 16/24] gnu: gstreamer: Add qt-gstreamer.

[David Craven]

I'll withhold this patch for now pending further investigation...

Thank you!

Re: [PATCH 16/24] gnu: gstreamer: Add qt-gstreamer.

[Eric Bavier]

On 2016-08-17 06:14, David Craven wrote:

Is boost propagated due to header references?


The include files reference these headers:

#include 
#include 
#include 
#include 


what is the reason for disabling runpath validation?


I'm getting a bunch of these errors. The problem seems to be that
/gnu/store/2g5xcc8hp16nfnf37449f3p492m8i03h-qt-gstreamer-1.2.0-1.fc159e5/lib64


Can you get qt-gstreamer to install its libraries into 
"/gnu/store/...-qt-gstreamer-1.2.0-=.fc159e5/lib"?  Things might Just 
Work™ then.


--
`~Eric

Re: [PATCH 16/24] gnu: gstreamer: Add qt-gstreamer.

[David Craven]

> Is boost propagated due to header references?

The include files reference these headers:

#include 
#include 
#include 
#include 

> what is the reason for disabling runpath validation?

I'm getting a bunch of these errors. The problem seems to be that
/gnu/store/2g5xcc8hp16nfnf37449f3p492m8i03h-qt-gstreamer-1.2.0-1.fc159e5/lib64
isn't in the RUNPATH. But isn't that folder implicitly in the RUNPATH
for libraries in the same directory? How can I get it in the RUNPATH,
is there a better way than using patchelf? what is the reason for
disabling runpath validation?

validating RUNPATH of 7 binaries in
"/gnu/store/2g5xcc8hp16nfnf37449f3p492m8i03h-qt-gstreamer-1.2.0-1.fc159e5/lib64"...
/gnu/store/2g5xcc8hp16nfnf37449f3p492m8i03h-qt-gstreamer-1.2.0-1.fc159e5/lib64/libQt5GStreamer-1.0.so:
error: depends on 'libQt5GLib-2.0.so.0', which cannot be found in
RUNPATH 
("/gnu/store/2g5xcc8hp16nfnf37449f3p492m8i03h-qt-gstreamer-1.2.0-1.fc159e5/lib"
"/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib"
"/gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib"
"/gnu/store/l1s4cw9g58hmcpd2qgbckfl228143qzx-glib-2.48.0/lib"
"/gnu/store/gspsx2v3zpfbl2s88xn7kb2ka9gv87bp-gstreamer-1.8.2/lib"
"/gnu/store/cc0192xs2lwcnkpjsv8msqv83d4s9zzv-gst-plugins-base-1.8.2/lib"
"/gnu/store/jz6wxyy2i279w92srv9p3qlabd7y0rjy-qtbase-5.7.0/lib"
"/gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../..")

Re: [PATCH 15/24] gnu: gstreamer: Symlink gstconfig.h into include directory.

[David Craven]

> In general, we should stick to upstream packaging unless it is clearly
> broken or there is a compelling reason to deviate.  In this case, if an
> application can't find , then it would seem to have a
> buggy build system, and we should fix the problem there.

The qt-gstreamer package doesn't build without this, but I agree that the
problem is with the qt-gstreamer package and not gstreamer and should
therefore be fixed there.

Re: [PATCH 15/24] gnu: gstreamer: Symlink gstconfig.h into include directory.

[Mark H Weaver]

David Craven <da...@craven.ch> writes:

>> What is the reason for this change?  Would it be appropriate to submit a
>> bug report upstream to add this to their "make install"?
>
> The reason is because applications may contain #include ,
> but gstconfig.h was moved to the lib directory because it contains "platform
> specific information".
>
> What do you suggest?

The pkgconfig file for gstreamer, $out/lib/pkgconfig/pkgconfig-1.0.pc,
includes this:

  Cflags: -I${includedir} -I${libdir}/gstreamer-1.0/include

Where ${libdir} is ${prefix}/lib.  So, the include path needed to find
 should automatically be included by non-broken build
systems.

What application(s) are you aware of that are unable to find
?

In general, we should stick to upstream packaging unless it is clearly
broken or there is a compelling reason to deviate.  In this case, if an
application can't find , then it would seem to have a
buggy build system, and we should fix the problem there.

What do you think?

Thanks,
  Mark

Re: [PATCH 15/24] gnu: gstreamer: Symlink gstconfig.h into include directory.

[David Craven]

> What is the reason for this change?  Would it be appropriate to submit a
> bug report upstream to add this to their "make install"?

The reason is because applications may contain #include ,
but gstconfig.h was moved to the lib directory because it contains "platform
specific information".

What do you suggest?

Re: [PATCH 15/24] gnu: gstreamer: Symlink gstconfig.h into include directory.

[Mark H Weaver]

David Craven <da...@craven.ch> writes:

> * gnu/packages/gstreamer.scm (gstreamer)[arguments]: Add symlink-gstconfig.h
>   phase.

What is the reason for this change?  Would it be appropriate to submit a
bug report upstream to add this to their "make install"?

  Mark
  

> ---
>  gnu/packages/gstreamer.scm | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
> index bd99880..54919cd 100644
> --- a/gnu/packages/gstreamer.scm
> +++ b/gnu/packages/gstreamer.scm
> @@ -113,7 +113,16 @@ arrays of data.")
>   `(#:configure-flags
> (list (string-append "--with-html-dir="
>  (assoc-ref %outputs "doc")
> -"/share/gtk-doc/html"
> +"/share/gtk-doc/html"))
> +   #:phases
> +(modify-phases %standard-phases
> +  (add-after 'install 'symlink-gstconfig.h
> +(lambda* (#:key outputs #:allow-other-keys)
> +  (symlink
> +(string-append (assoc-ref outputs "out")
> + "/lib/gstreamer-1.0/include/gst/gstconfig.h")
> +(string-append (assoc-ref outputs "out")
> + "/include/gstreamer-1.0/gst/gstconfig.h")))
>  (propagated-inputs `(("glib" ,glib))) ; required by gstreamer-1.0.pc.
>  (native-inputs
>   `(("bison" ,bison)

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[David Craven]

> That would be a massive refactoring - but can be done eventually.

I don't think it would be too hard, most work can be done through
applying a regex to the entire project and running the testsuite to
find the cases where it didn't work. I did this on the python.scm
file...

So then I'll leave the patch as it is?

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[Danny Milosavljevic]

On Wed, 17 Aug 2016 10:53:23 +0200
David Craven  wrote:

> Ah, I was thinking more about lgpl2.1+ and the sorts... So is it a
> good idea to prefix all licenses in guix licenses itself (as Eric
> mentioned), and be done with it?

That would be a massive refactoring - but can be done eventually.

I would just #:prefix license: whenever one touches something that caused these 
problems. No need to modify everything in one go.

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[David Craven]

> Expat causes a name collision.
>
> Also nmap, boost, cecill-c, freetype, imlib2, openldap2.0, openssl, ruby, 
> tcl/tk, vim, x11, zlib.
>
> Should there be new licenses it's a good guess it will be named like the 
> package it originated in.
>
> I would not advise removing the prefix. If anything, use it everywhere.

Ah, I was thinking more about lgpl2.1+ and the sorts... So is it a
good idea to prefix all licenses in guix licenses itself (as Eric
mentioned), and be done with it?

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[Danny Milosavljevic]

On Wed, 17 Aug 2016 10:02:26 +0200
David Craven  wrote:

> I wonder who started the #:prefix/#:select thing in the first place. I
> don't think that anything from guix licenses is likely to cause a name
> collision. Maybe it's best to remove the #:prefix entirely?

Expat causes a name collision. 

Also nmap, boost, cecill-c, freetype, imlib2, openldap2.0, openssl, ruby, 
tcl/tk, vim, x11, zlib.

Should there be new licenses it's a good guess it will be named like the 
package it originated in.

I would not advise removing the prefix. If anything, use it everywhere.

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[David Craven]

I wonder who started the #:prefix/#:select thing in the first place. I
don't think that anything from guix licenses is likely to cause a name
collision. Maybe it's best to remove the #:prefix entirely?

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[Eric Bavier]

On Tue, 16 Aug 2016 23:15:07 +0300
Alex Kost <alez...@gmail.com> wrote:

> David Craven (2016-08-16 21:39 +0300) wrote:
> 
> > * gnu/packages/gstreamer.scm (define-module): Import guix licenses with 
> > #:prefix
> >   license:.
> >   (orc): Likewise.
> >   (gstreamer): Likewise.
> >   (gst-plugins-base): Likewise.
> >   (gst-plugins-good): Likewise.
> >   (gst-plugins-bad): Likewise.
> >   (gst-plugins-ugly): Likewise.
> >   (gst-libav): Likewise.
> >   (python-gst): Likewise.  
>   ^^
> Please remove the leading spaces before "(...): Likewise."

In fact, I think this is a case where one could simple say something
like "Adjust license references".

> I like this patch.  However in general (a question for Guix people): is
> there a reason to use #:select for licenses?  Or would it be better to
> use #:prefix everywhere?  If the latter (my preference), I think it
> would be good to make this "#:select"→"#:prefix" change in a single
> patch instead of making separate patches for different modules.

I don't think it's something that needs to be mandated.  If we were to
use '#:prefix license:' everywhere, we might as well save the trouble
and just rename everything in (guix license) with the
prefix.  But I don't think this is necessary.  There are instances of
importing with '#:hide' even, which I think has its place.

`~Eric

Re: [PATCH 16/24] gnu: gstreamer: Add qt-gstreamer.

[Eric Bavier]

Hello David,

You can remove the "gstreamer: " bit from the commit subject.

On Tue, 16 Aug 2016 20:39:30 +0200
David Craven <da...@craven.ch> wrote:

> * gnu/packages/gstreamer.scm (qt-gstreamer): New variable.
> ---
>  gnu/packages/gstreamer.scm | 42 ++
>  1 file changed, 42 insertions(+)
> 
> diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
> index 54919cd..ee3c9e4 100644
> --- a/gnu/packages/gstreamer.scm
> +++ b/gnu/packages/gstreamer.scm
> @@ -24,11 +24,13 @@
>#:use-module ((guix licenses) #:prefix license:)
>#:use-module (guix packages)
>#:use-module (guix download)
> +  #:use-module (guix build-system cmake)
>#:use-module (guix build-system gnu)
>#:use-module (guix utils)
>#:use-module (gnu packages)
>#:use-module (gnu packages audio)
>#:use-module (gnu packages bison)
> +  #:use-module (gnu packages boost)
>#:use-module (gnu packages cdrom)
>#:use-module (gnu packages curl)
>#:use-module (gnu packages compression)
> @@ -467,3 +469,43 @@ be used by Python applications using GStreamer.")
>  (propagated-inputs
>   `(("gst-plugins-base" ,gst-plugins-base)
>     ("python-pygobject" ,python2-pygobject)
> +
> +(define-public qt-gstreamer
> +  (package
> +(name "qt-gstreamer")
> +(version "1.2.0")
> +    (source (origin
> +      (method url-fetch)
> +  (uri (string-append
> +"https://gstreamer.freedesktop.org/src/qt-gstreamer/;
> +"qt-gstreamer-" version ".tar.xz"))
> +  (sha256
> +   (base32
> +"1m4g5vcs8r4b8dzndr9a5w0rrawdyinvjkacis8vxnfafhmljfwz"
> +(build-system cmake-build-system)
> +(native-inputs
> + `(("glib:bin" ,glib "bin")
> +   ("pkg-config" ,pkg-config)))
> +(propagated-inputs
> + `(("boost" ,boost)))

Is boost propagated due to header references?

> +(inputs
> + `(("glib" ,glib)
> +   ("gstreamer" ,gstreamer)
> +   ("gst-libav" ,gst-libav)
> +   ("gst-plugins-base" ,gst-plugins-base)
> +   ("qtbase" ,qtbase)
> +   ("qtdeclarative" ,qtdeclarative)))
> +(arguments
> + `(#:configure-flags
> +'("-DQT_VERSION=5"
> +  "-DUSE_GST_PLUGIN_DIR=OFF"
> +  "-DUSE_QT_PLUGIN_DIR=OFF")
> +   #:validate-runpath? #f))

As Leo mentioned, what is the reason for disabling runpath validation?

> +(home-page "https://gstreamer.freedesktop.org/modules/qt-gstreamer.html;)
> +(synopsis "C++ bindings for GStreamer with a Qt-style API")
> +(description "QtGStreamer is a set of libraries providing C++ bindings 
> for
> +GStreamer with a Qt-style API, plus some helper classes and elements for
> +integrating GStreamer better in Qt applications.  The goal of this module is 
> to
> +allow easy use of GStreamer for applications targetting MeeGo Mobile or the 
> KDE
> +desktop.")
> +(license license:lgpl2.1+)))

Re: [PATCH 16/24] gnu: gstreamer: Add qt-gstreamer.

[Leo Famulari]

On Tue, Aug 16, 2016 at 08:39:30PM +0200, David Craven wrote:
> * gnu/packages/gstreamer.scm (qt-gstreamer): New variable.

> +   #:validate-runpath? #f))

My understanding is that if the runpath validator fails, then something is 
wrong with the
package. Why is it disabled here?

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[David Craven]

> I like this patch.  However in general (a question for Guix people): is
> there a reason to use #:select for licenses?  Or would it be better to
> use #:prefix everywhere?  If the latter (my preference), I think it
> would be good to make this "#:select"→"#:prefix" change in a single
> patch instead of making separate patches for different modules.

I think that #:select has it's purpose. It helps increase readability when
one or two things are selected for example in bootstrap.scm.

#:use-module ((guix store) #:select (add-to-store add-text-to-store))
#:use-module ((guix derivations) #:select (derivation))
#:use-module ((guix utils) #:select (gnu-triplet->nix-system))

However when it comes to licenses it's verbose and unnecessary. I'll
amend the commit tomorrow to cover all cases where #:select is used
for importing licenses.

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[Alex Kost]

David Craven (2016-08-16 21:39 +0300) wrote:

> * gnu/packages/gstreamer.scm (define-module): Import guix licenses with 
> #:prefix
>   license:.
>   (orc): Likewise.
>   (gstreamer): Likewise.
>   (gst-plugins-base): Likewise.
>   (gst-plugins-good): Likewise.
>   (gst-plugins-bad): Likewise.
>   (gst-plugins-ugly): Likewise.
>   (gst-libav): Likewise.
>   (python-gst): Likewise.
  ^^
Please remove the leading spaces before "(...): Likewise."

I like this patch.  However in general (a question for Guix people): is
there a reason to use #:select for licenses?  Or would it be better to
use #:prefix everywhere?  If the latter (my preference), I think it
would be good to make this "#:select"→"#:prefix" change in a single
patch instead of making separate patches for different modules.

-- 
Alex

Re: [PATCH 14/24] gnu: gstreamer: Use license: prefix.

[Danny Milosavljevic]

LGTM.

[PATCH 14/24] gnu: gstreamer: Use license: prefix.

[David Craven]

* gnu/packages/gstreamer.scm (define-module): Import guix licenses with #:prefix
  license:.
  (orc): Likewise.
  (gstreamer): Likewise.
  (gst-plugins-base): Likewise.
  (gst-plugins-good): Likewise.
  (gst-plugins-bad): Likewise.
  (gst-plugins-ugly): Likewise.
  (gst-libav): Likewise.
  (python-gst): Likewise.
---
 gnu/packages/gstreamer.scm | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
index a39a3b4..bd99880 100644
--- a/gnu/packages/gstreamer.scm
+++ b/gnu/packages/gstreamer.scm
@@ -21,7 +21,7 @@
 ;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
 
 (define-module (gnu packages gstreamer)
-  #:use-module ((guix licenses) #:select (lgpl2.0+ lgpl2.1+ bsd-2 bsd-3 gpl2+))
+  #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
   #:use-module (guix build-system gnu)
@@ -92,7 +92,7 @@ associated tools for compiling and executing simple programs 
that operate on
 arrays of data.")
 ;; The source code implementing the Marsenne Twister algorithm is licensed
 ;; under the 3-clause BSD license, the rest is under 2-clause BSD license.
-(license (list bsd-2 bsd-3
+(license (list license:bsd-2 license:bsd-3
 
 (define-public gstreamer
   (package
@@ -140,7 +140,7 @@ transparently.  Developers can add new codecs and filters 
by writing a
 simple plugin with a clean, generic interface.
 
 This package provides the core library and elements.")
-(license lgpl2.0+)))
+(license license:lgpl2.0+)))
 
 (define-public gst-plugins-base
   (package
@@ -192,7 +192,7 @@ This package provides the core library and elements.")
  "Plugins for the GStreamer multimedia library")
 (description "This package provides an essential exemplary set of plug-ins
 for the GStreamer multimedia library.")
-(license lgpl2.0+)))
+(license license:lgpl2.0+)))
 
 
 (define-public gst-plugins-good
@@ -258,7 +258,7 @@ for the GStreamer multimedia library.")
 (description "GStreamer Good Plug-ins is a set of plug-ins for the
 GStreamer multimedia library.  This set contains those plug-ins which the
 developers consider to have good quality code and correct functionality.")
-(license lgpl2.0+)))
+(license license:lgpl2.0+)))
 
 (define-public gst-plugins-bad
   (package
@@ -331,7 +331,7 @@ developers consider to have good quality code and correct 
functionality.")
 (description
  "GStreamer Bad Plug-ins is a set of plug-ins whose quality aren't up to
 par compared to the rest.")
-(license lgpl2.0+)))
+(license license:lgpl2.0+)))
 
 (define-public gst-plugins-ugly
   (package
@@ -369,7 +369,7 @@ par compared to the rest.")
 (description "GStreamer Ugly Plug-ins.  This set contains those plug-ins
 which the developers consider to have good quality code but that might pose
 distribution problems in some jurisdictions, e.g. due to patent threats.")
-(license lgpl2.0+)))
+(license license:lgpl2.0+)))
 
 (define-public gst-libav
   (package
@@ -406,7 +406,7 @@ distribution problems in some jurisdictions, e.g. due to 
patent threats.")
 (description
  "This GStreamer plugin supports a large number of audio and video
 compression formats through the use of the libav library.")
-(license gpl2+)))
+(license license:gpl2+)))
 
 (define-public python-gst
   (package
@@ -446,7 +446,7 @@ compression formats through the use of the libav library.")
 (description
  "This package contains GObject Introspection overrides for Python that can
 be used by Python applications using GStreamer.")
-(license lgpl2.1+)
+(license license:lgpl2.1+)
 (properties `((python2-variant . ,(delay python2-gst))
 
 (define-public python2-gst
-- 
2.9.0

[PATCH 16/24] gnu: gstreamer: Add qt-gstreamer.

[David Craven]

* gnu/packages/gstreamer.scm (qt-gstreamer): New variable.
---
 gnu/packages/gstreamer.scm | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
index 54919cd..ee3c9e4 100644
--- a/gnu/packages/gstreamer.scm
+++ b/gnu/packages/gstreamer.scm
@@ -24,11 +24,13 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix build-system cmake)
   #:use-module (guix build-system gnu)
   #:use-module (guix utils)
   #:use-module (gnu packages)
   #:use-module (gnu packages audio)
   #:use-module (gnu packages bison)
+  #:use-module (gnu packages boost)
   #:use-module (gnu packages cdrom)
   #:use-module (gnu packages curl)
   #:use-module (gnu packages compression)
@@ -467,3 +469,43 @@ be used by Python applications using GStreamer.")
 (propagated-inputs
  `(("gst-plugins-base" ,gst-plugins-base)
("python-pygobject" ,python2-pygobject)))))
+
+(define-public qt-gstreamer
+  (package
+(name "qt-gstreamer")
+(version "1.2.0")
+(source (origin
+  (method url-fetch)
+  (uri (string-append
+    "https://gstreamer.freedesktop.org/src/qt-gstreamer/;
+"qt-gstreamer-" version ".tar.xz"))
+  (sha256
+   (base32
+"1m4g5vcs8r4b8dzndr9a5w0rrawdyinvjkacis8vxnfafhmljfwz"
+(build-system cmake-build-system)
+(native-inputs
+ `(("glib:bin" ,glib "bin")
+   ("pkg-config" ,pkg-config)))
+(propagated-inputs
+ `(("boost" ,boost)))
+(inputs
+ `(("glib" ,glib)
+   ("gstreamer" ,gstreamer)
+   ("gst-libav" ,gst-libav)
+   ("gst-plugins-base" ,gst-plugins-base)
+   ("qtbase" ,qtbase)
+   ("qtdeclarative" ,qtdeclarative)))
+(arguments
+ `(#:configure-flags
+'("-DQT_VERSION=5"
+  "-DUSE_GST_PLUGIN_DIR=OFF"
+  "-DUSE_QT_PLUGIN_DIR=OFF")
+   #:validate-runpath? #f))
+(home-page "https://gstreamer.freedesktop.org/modules/qt-gstreamer.html;)
+(synopsis "C++ bindings for GStreamer with a Qt-style API")
+(description "QtGStreamer is a set of libraries providing C++ bindings for
+GStreamer with a Qt-style API, plus some helper classes and elements for
+integrating GStreamer better in Qt applications.  The goal of this module is to
+allow easy use of GStreamer for applications targetting MeeGo Mobile or the KDE
+desktop.")
+(license license:lgpl2.1+)))
-- 
2.9.0

[PATCH 15/24] gnu: gstreamer: Symlink gstconfig.h into include directory.

[David Craven]

* gnu/packages/gstreamer.scm (gstreamer)[arguments]: Add symlink-gstconfig.h
  phase.
---
 gnu/packages/gstreamer.scm | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
index bd99880..54919cd 100644
--- a/gnu/packages/gstreamer.scm
+++ b/gnu/packages/gstreamer.scm
@@ -113,7 +113,16 @@ arrays of data.")
  `(#:configure-flags
(list (string-append "--with-html-dir="
 (assoc-ref %outputs "doc")
-"/share/gtk-doc/html"
+"/share/gtk-doc/html"))
+   #:phases
+(modify-phases %standard-phases
+  (add-after 'install 'symlink-gstconfig.h
+(lambda* (#:key outputs #:allow-other-keys)
+  (symlink
+(string-append (assoc-ref outputs "out")
+ "/lib/gstreamer-1.0/include/gst/gstconfig.h")
+(string-append (assoc-ref outputs "out")
+ "/include/gstreamer-1.0/gst/gstconfig.h")))
 (propagated-inputs `(("glib" ,glib))) ; required by gstreamer-1.0.pc.
 (native-inputs
  `(("bison" ,bison)
-- 
2.9.0

Re: GStreamer, PulseAudio and libvpx update

[Andreas Enge]

Hello,

On Wed, Feb 03, 2016 at 12:23:24PM +0800, 宋文武 wrote:
> In the 'gstreamer-update' branch we have following updates:
>   libvpx -> 1.5.0
>   pulseaudio -> 8.0
>   ao -> 1.2.0
>   gstreamer (and plugins) -> 1.6.3

I noticed you merged master into the branch. My opinion is that merging
instead of rebasing messes up the history and makes it rather unclear
what the differences in this branch are. So I would suggest the following:
Delete the branch, create a branch "wip-gstreamer" from security-updates
(not master!), try to build a few packages; after security-updates has been
applied to master, rebase wip-gstreamer and have it built by hydra.

Right now, the priority clearly is to finish security-updates, and we
cannot afford to build a second branch in parallel.

Are these four updates independent? Should they all be built together,
or should we do them one by one? Only 19 packages depend on ao, only 29 on
libvpx, so these could be done separately. Could they even go to master,
or do they depend on gstreamer (or pulseaudio) being updated first? 
pulseaudio has 162 dependent packages, so even these could maybe be built
separately (where by "separately" I mean in a different evaluation).

What do you think?

Andreas

Re: GStreamer, PulseAudio and libvpx update

[Efraim Flashner]

On Wed, 3 Feb 2016 11:25:22 +0100
Andreas Enge <andr...@enge.fr> wrote:

> Hello,
> 
> On Wed, Feb 03, 2016 at 12:23:24PM +0800, 宋文武 wrote:
>  [...]  
> 
> I noticed you merged master into the branch. My opinion is that merging
> instead of rebasing messes up the history and makes it rather unclear
> what the differences in this branch are. So I would suggest the following:
> Delete the branch, create a branch "wip-gstreamer" from security-updates
> (not master!), try to build a few packages; after security-updates has been
> applied to master, rebase wip-gstreamer and have it built by hydra.
> 
> Right now, the priority clearly is to finish security-updates, and we
> cannot afford to build a second branch in parallel.
> 
> Are these four updates independent? Should they all be built together,
> or should we do them one by one? Only 19 packages depend on ao, only 29 on
> libvpx, so these could be done separately. Could they even go to master,
> or do they depend on gstreamer (or pulseaudio) being updated first? 
> pulseaudio has 162 dependent packages, so even these could maybe be built
> separately (where by "separately" I mean in a different evaluation).
> 
> What do you think?
> 
> Andreas
> 

They should all be independant, and AFAIK even the gstreamer updates can be
independant of each other. The problem I ran into before was that
gst-plugins-good didn't compile correctly after updating some of the others.

That said, I think it would be worth it to try to pick off some of the
updates and see if they can be applied without breakage, so I'll see about
again while security-updates get built.

-- 
Efraim Flashner   <efr...@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


pgp0fx0FFZfow.pgp
Description: OpenPGP digital signature

Re: GStreamer, PulseAudio and libvpx update

[宋文武]

Andreas Enge <andr...@enge.fr> writes:

> Hello,
>
> On Wed, Feb 03, 2016 at 12:23:24PM +0800, 宋文武 wrote:
>> In the 'gstreamer-update' branch we have following updates:
>>   libvpx -> 1.5.0
>>   pulseaudio -> 8.0
>>   ao -> 1.2.0
>>   gstreamer (and plugins) -> 1.6.3
>
> I noticed you merged master into the branch. My opinion is that merging
> instead of rebasing messes up the history and makes it rather unclear
> what the differences in this branch are. So I would suggest the following:
> Delete the branch, create a branch "wip-gstreamer" from security-updates
> (not master!), try to build a few packages; after security-updates has been
> applied to master, rebase wip-gstreamer and have it built by hydra.
Sure, merge does look weird.  Done as you said, thanks for the guide :)
>
> Right now, the priority clearly is to finish security-updates, and we
> cannot afford to build a second branch in parallel.
OK.
>
> Are these four updates independent? Should they all be built together,
> or should we do them one by one? Only 19 packages depend on ao, only 29 on
> libvpx, so these could be done separately. Could they even go to master,
> or do they depend on gstreamer (or pulseaudio) being updated first? 
> pulseaudio has 162 dependent packages, so even these could maybe be built
> separately (where by "separately" I mean in a different evaluation).
>
> What do you think?
Yes, they're independent.  I update gstreamer and add gst-plugins-bad,
the other are from Efraim Flashner's work.  Due to gst-plugins-good
failed to pass some tests with the update of libvpx and pulseaudio,
I think put them together may bring some luck.
well, it seem the test failure of gst-plugins-good is unreleated to
the update...

Re: GStreamer, PulseAudio and libvpx update

[Efraim Flashner]

On Wed, 03 Feb 2016 12:23:24 +0800
iyzs...@member.fsf.org (宋文武) wrote:

> In the 'gstreamer-update' branch we have following updates:
>   libvpx -> 1.5.0
>   pulseaudio -> 8.0
>   ao -> 1.2.0
>   gstreamer (and plugins) -> 1.6.3
> 
> This will lead to mess rebuilds.
> I have build gst-plugins-good, ffmpeg, mpv and pavucontrol,
> tested with pulseaudio-8.0, so I think it's safe to merge.
> Or should we start a job for the branch on hydra?
 
Depending on the number of packages to rebuild, giving hydra a head start of
a day or three is probably a good idea.
 
> Efraim Flashner <efr...@flashner.co.il> writes:
> 
>  [...]  
>  [...]  
>  [...]  
> With the gstreamer-update branch merged with current master, I don't
> meet any failure for my local x86_64 build of gst-plugins-good-1.6.3.
> 
> Do the failure still occur to you?

I just checked out origin/gstreamer-update again and gst-plugins-good failed
to build for me again.
FAIL: elements/splitmux
FAIL: elements/rtprtx

-- 
Efraim Flashner   <efr...@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


pgpWCwRlb3xpW.pgp
Description: OpenPGP digital signature

Re: GStreamer, PulseAudio and libvpx update

[Andreas Enge]

Hello,

On Wed, Feb 03, 2016 at 07:15:11PM +0800, 宋文武 wrote:
> Yes, they're independent.  I update gstreamer and add gst-plugins-bad,
> the other are from Efraim Flashner's work.  Due to gst-plugins-good
> failed to pass some tests with the update of libvpx and pulseaudio,
> I think put them together may bring some luck.
> well, it seem the test failure of gst-plugins-good is unreleated to
> the update...

thanks for getting back to this! I actually had forgotten to mention that
I would be willing to work on this, sorry.

So far, I tried the following: On x86_64, gst-plugins-good builds without
problem with the new version of ao that Efraim already pushed to master
and the new pulseaudio version. One test fails if I also apply the libvpx
update.

So it looks like we could also update pulseaudio in master; according to
"guix refresh -l" there are 168 dependent packages. Is this too much?

In any case, we should now wait for security-updates to be applied to
master, and probably keep the old version of libvpx until after the
gstreamer update.

Andreas

Re: GStreamer, PulseAudio and libvpx update

[Efraim Flashner]

On Wed, 3 Feb 2016 18:43:09 +0100
Andreas Enge <andr...@enge.fr> wrote:

> Hello,
> 
> On Wed, Feb 03, 2016 at 07:15:11PM +0800, 宋文武 wrote:
>  [...]  
> 
> thanks for getting back to this! I actually had forgotten to mention that
> I would be willing to work on this, sorry.
> 
> So far, I tried the following: On x86_64, gst-plugins-good builds without
> problem with the new version of ao that Efraim already pushed to master
> and the new pulseaudio version. One test fails if I also apply the libvpx
> update.
> 
> So it looks like we could also update pulseaudio in master; according to
> "guix refresh -l" there are 168 dependent packages. Is this too much?
> 
> In any case, we should now wait for security-updates to be applied to
> master, and probably keep the old version of libvpx until after the
> gstreamer update.
> 
> Andreas
> 

I tested the ao update which was obviously fine, but libvpx broke
gst-plugins-good. Its nice to know that pulseaudio doesn't break anything, I
assumed I was looking at a 2+ hour build session to really test it so I'm
glad I didn't have to be the one to do it in the end :) Debian managed to
upgrade libvpx to 1.5.0 with gstreamer at 1.6.3 so I'm a bit curious about
how they managed that.

-- 
Efraim Flashner   <efr...@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


pgpO91Zk73k9a.pgp
Description: OpenPGP digital signature

GStreamer, PulseAudio and libvpx update

[宋文武]

In the 'gstreamer-update' branch we have following updates:
  libvpx -> 1.5.0
  pulseaudio -> 8.0
  ao -> 1.2.0
  gstreamer (and plugins) -> 1.6.3

This will lead to mess rebuilds.
I have build gst-plugins-good, ffmpeg, mpv and pavucontrol,
tested with pulseaudio-8.0, so I think it's safe to merge.
Or should we start a job for the branch on hydra?


Efraim Flashner <efr...@flashner.co.il> writes:

> On Thu, 21 Jan 2016 09:54:25 +0800
> iyzs...@member.fsf.org (宋文武) wrote:
> [...]
>> 
>> Sorry I didn't follow the issue.  What break on master due to the update
>> of libvpx?  Since hydra is busy with core-updates, I think we can work
>> on a separate branch, and pick it later after core-updates merged.
>
> Against my local gstreamer- and gst-plugin-*-1.7.1 I updated libvpx to 1.5.0
> and pulseaudio to 8.0 and gst-plugins-good-1.7.1 built with no issues. When I
> compiled gst-plugins-good-1.6.3 against libvpx-1.5.0 and pulseaudio-8.0 I got
> the same failure as before (which I forgot to write down), so I'm thinking
> this will mostly resolve itself when the gstreamer-1.8 release comes
> out.
With the gstreamer-update branch merged with current master, I don't
meet any failure for my local x86_64 build of gst-plugins-good-1.6.3.

Do the failure still occur to you?

Re: Gstreamer

[iyzsong]

Andreas Enge <andr...@enge.fr> writes:

> Hello,
>
> gst-plugins-good currently fails its tests on armhf, which blocks quite
> a few packages.
Actually, it's the gst-plugins-base failing.

  http://hydra.gnu.org/build/723264/nixlog/1/tail-reload

> There are newer gstreamer versions: 1.5.1, 1.5.2 and
> 1.6.0. I tried to compile the latter some time ago, but somehow got
> tangled up. Do you think it would be safe to update?
Yes, I think it's safe to update to the stable release 1.6.x.
I looked into it, but it requires some compiler flags tricks like
in your patch, then I forget it :-

> Would there be a
> volunteer who is more knowledgeable about the package than me?
I may do it in the next week, but feel free to go ahead.
And Gstreamer is quite mature and standardize IMO, I don't have
special knowledge about it :-)

Re: Gstreamer

[Andreas Enge]

Actually I found the beginning of a patch on my git stash,
if someone wants to start from there:

diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm


index 0ac9783..a7f9539 100644   


--- a/gnu/packages/gstreamer.scm


+++ b/gnu/packages/gstreamer.scm


@@ -83,7 +83,7 @@ arrays of data.") 


 (define-public gstreamer
   (package
 (name "gstreamer")
-(version "1.4.5")
+(version "1.6.0")
 (source
  (origin
   (method url-fetch)
@@ -91,15 +91,24 @@ arrays of data.")
   version ".tar.xz"))
   (sha256
(base32
-"1bmhbhak6i5wmmb6w86jyyv8lax4gdq983la4lk4a0krz6kim020"
+"1k0glfw2m1qpfwp96jqwjzl0kah4zvz9lnk4nz413vxg8xb8ivsj"
 (build-system gnu-build-system)
 (outputs '("out" "doc"))
 (arguments
  `(#:make-flags '("CC=gcc") ; for g-ir-scanner.
#:configure-flags
-   (list (string-append "--with-html-dir="
+   (list "CFLAGS=-std=c99"
+ (string-append "--with-html-dir="
 (assoc-ref %outputs "doc")
-"/share/gtk-doc/html"
+"/share/gtk-doc/html"))
+   #:phases
+   (modify-phases %standard-phases
+ (add-after
+  'configure 'correct-config-h
+  (lambda _
+(substitute* "config.h"
+  (("HAVE_DECL_STRSIGNAL 0")
+   "HAVE_DECL_STRSIGNAL 1")))
 (propagated-inputs `(("glib" ,glib))) ; required by gstreamer-1.0.pc.
 (native-inputs
  `(("bison" ,bison)

Andreas

Re: [PATCH] gnu: gstreamer: Add search path specification for 'GST_PLUGIN_SYSTEM_PATH'.

[Ludovic Courtès]

宋文武 iyzs...@gmail.com skribis:

 Ludovic Courtès l...@gnu.org writes:

 宋文武 iyzs...@gmail.com skribis:

 This reverts commit e53fc0c8a, which add it wrongly to gst-plugins-base.

 * gnu/packages/gstreamer.scm (gstreamer)[native-search-paths]: New field.
   (gst-plugins-base)[native-search-paths]: Remove.

 LGTM!

 I wonder, why is there the word “SYSTEM” in this variable name?  Does
 that means there also exists GST_PLUGIN_PATH?
 Yes, you're right.  It has:

   GST_PLUGIN_SYSTEM_PATH, GST_PLUGIN_SYSTEM_PATH_1_0
   GST_PLUGIN_PATH, GST_PLUGIN_PATH_1_0

 I think any one is sufficent.

 http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html

OK, thanks.

Ludo’.

Re: [PATCH] gnu: gstreamer: Add search path specification for 'GST_PLUGIN_SYSTEM_PATH'.

[Ludovic Courtès]

宋文武 iyzs...@gmail.com skribis:

 This reverts commit e53fc0c8a, which add it wrongly to gst-plugins-base.

 * gnu/packages/gstreamer.scm (gstreamer)[native-search-paths]: New field.
   (gst-plugins-base)[native-search-paths]: Remove.

LGTM!

I wonder, why is there the word “SYSTEM” in this variable name?  Does
that means there also exists GST_PLUGIN_PATH?

Thanks,
Ludo’.

Re: [PATCH] gnu: gstreamer: Add search path specification for 'GST_PLUGIN_SYSTEM_PATH'.

[宋文武]

Ludovic Courtès l...@gnu.org writes:

 宋文武 iyzs...@gmail.com skribis:

 This reverts commit e53fc0c8a, which add it wrongly to gst-plugins-base.

 * gnu/packages/gstreamer.scm (gstreamer)[native-search-paths]: New field.
   (gst-plugins-base)[native-search-paths]: Remove.

 LGTM!

 I wonder, why is there the word “SYSTEM” in this variable name?  Does
 that means there also exists GST_PLUGIN_PATH?
Yes, you're right.  It has:

  GST_PLUGIN_SYSTEM_PATH, GST_PLUGIN_SYSTEM_PATH_1_0
  GST_PLUGIN_PATH, GST_PLUGIN_PATH_1_0

I think any one is sufficent.

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html

[PATCH] gnu: gstreamer: Add search path specification for 'GST_PLUGIN_SYSTEM_PATH'.

[宋文武]

This reverts commit e53fc0c8a, which add it wrongly to gst-plugins-base.

* gnu/packages/gstreamer.scm (gstreamer)[native-search-paths]: New field.
  (gst-plugins-base)[native-search-paths]: Remove.
---
 gnu/packages/gstreamer.scm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
index 24dc41b..1832909 100644
--- a/gnu/packages/gstreamer.scm
+++ b/gnu/packages/gstreamer.scm
@@ -109,6 +109,10 @@ arrays of data.)
(perl ,perl)
(pkg-config ,pkg-config)
(python-wrapper ,python-wrapper)))
+(native-search-paths
+ (list (search-path-specification
+(variable GST_PLUGIN_SYSTEM_PATH)
+(files '(lib/gstreamer-1.0)
 (home-page http://gstreamer.freedesktop.org/;)
 (synopsis Multimedia library)
 (description
@@ -171,10 +175,6 @@ This package provides the core library and elements.)
   ;; for g-ir-scanner.
   (setenv CC gcc))
 %standard-phases)))
-(native-search-paths
- (list (search-path-specification
-(variable GST_PLUGIN_SYSTEM_PATH)
-(files '(lib/gstreamer-1.0)
 (home-page http://gstreamer.freedesktop.org/;)
 (synopsis
  Plugins for the GStreamer multimedia library)
-- 
2.2.1

Re: [PATCH] gnu: Remove gstreamer-0.10 and gst-plugins-base-0.10.

[Ludovic Courtès]

宋文武 iyzs...@gmail.com skribis:

 It have been broken for 3 month, and no one seem to be interesting to
 fix it.  Since no packages use it actually (only wxwidgets have a
 comment), I'd like to remove them.

 What do you think?

Fine with me!

Ludo’.

Re: [PATCH] gnu: Remove gstreamer-0.10 and gst-plugins-base-0.10.

[宋文武]

Andreas Enge andr...@enge.fr writes:

 On Wed, Apr 29, 2015 at 04:24:56PM +0800, 宋文武 wrote:
 * gnu/packages/gstreamer.scm (gstreamer-0.10, gst-plugins-base-0.10):
   Remove variables.
 * gnu/packages/patches/gstreamer-0.10-bison3.patch,
   gnu/packages/patches/gstreamer-0.10-silly-test.patch: Remove files.
 * gnu-system.am (dist_patch_DATA): Remove them.

 It corresponds to a suggestion I have made before, so I am supporting it
 again. The packages do not compile currently. If they are needed at any time
 in the future as an input to some other package, the packager will have to
 repair them anyway, and getting them out of git would be a minor additional
 effort.
OK, pushed.

 Andreas

Re: [PATCH] gnu: Remove gstreamer-0.10 and gst-plugins-base-0.10.

[宋文武]

It have been broken for 3 month, and no one seem to be interesting to
fix it.  Since no packages use it actually (only wxwidgets have a
comment), I'd like to remove them.

What do you think?

http://hydra.gnu.org/job/gnu/master/gstreamer-0.10.36.i686-linux/all

Re: [PATCH] gnu: Remove gstreamer-0.10 and gst-plugins-base-0.10.

[Andreas Enge]

On Wed, Apr 29, 2015 at 04:24:56PM +0800, 宋文武 wrote:
 * gnu/packages/gstreamer.scm (gstreamer-0.10, gst-plugins-base-0.10):
   Remove variables.
 * gnu/packages/patches/gstreamer-0.10-bison3.patch,
   gnu/packages/patches/gstreamer-0.10-silly-test.patch: Remove files.
 * gnu-system.am (dist_patch_DATA): Remove them.

It corresponds to a suggestion I have made before, so I am supporting it
again. The packages do not compile currently. If they are needed at any time
in the future as an input to some other package, the packager will have to
repair them anyway, and getting them out of git would be a minor additional
effort.

Andreas

[PATCH] gnu: Remove gstreamer-0.10 and gst-plugins-base-0.10.

[宋文武]

* gnu/packages/gstreamer.scm (gstreamer-0.10, gst-plugins-base-0.10):
  Remove variables.
* gnu/packages/patches/gstreamer-0.10-bison3.patch,
  gnu/packages/patches/gstreamer-0.10-silly-test.patch: Remove files.
* gnu-system.am (dist_patch_DATA): Remove them.
---
 gnu-system.am  |  2 -
 gnu/packages/gstreamer.scm | 46 --
 gnu/packages/patches/gstreamer-0.10-bison3.patch   | 32 ---
 .../patches/gstreamer-0.10-silly-test.patch| 14 ---
 4 files changed, 94 deletions(-)
 delete mode 100644 gnu/packages/patches/gstreamer-0.10-bison3.patch
 delete mode 100644 gnu/packages/patches/gstreamer-0.10-silly-test.patch

diff --git a/gnu-system.am b/gnu-system.am
index 617e8bb..60901a6 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -440,8 +440,6 @@ dist_patch_DATA =   
\
   gnu/packages/patches/grep-CVE-2015-1345.patch\
   gnu/packages/patches/grub-gets-undeclared.patch  \
   gnu/packages/patches/grub-freetype.patch \
-  gnu/packages/patches/gstreamer-0.10-bison3.patch \
-  gnu/packages/patches/gstreamer-0.10-silly-test.patch \
   gnu/packages/patches/guile-1.8-cpp-4.5.patch \
   gnu/packages/patches/guile-arm-fixes.patch   \
   gnu/packages/patches/guile-default-utf8.patch\
diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
index b882208..03aecdf 100644
--- a/gnu/packages/gstreamer.scm
+++ b/gnu/packages/gstreamer.scm
@@ -124,32 +124,6 @@ simple plugin with a clean, generic interface.
 This package provides the core library and elements.)
 (license lgpl2.0+)))
 
-(define-public gstreamer-0.10
-  (package (inherit gstreamer)
-(version 0.10.36)
-(source
- (origin
-  (method url-fetch)
-  (uri (string-append 
http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-;
-  version .tar.xz))
-  (sha256
-   (base32
-1nkid1n2l3rrlmq5qrf5yy06grrkwjh3yxl5g0w58w0pih8allci))
-  (patches
-(list (search-patch gstreamer-0.10-bison3.patch)
-  (search-patch gstreamer-0.10-silly-test.patch)
-(propagated-inputs
- `((libxml2 ,libxml2)))
-(inputs `((glib ,glib)))
-(native-inputs
- `((bison ,bison)
-   (flex ,flex)
-   (perl ,perl)
-   (pkg-config ,pkg-config)
-   (glib ,glib bin)
-   (python ,python-2)
-
-
 (define-public gst-plugins-base
   (package
 (name gst-plugins-base)
@@ -288,23 +262,3 @@ developers consider to have good quality code and correct 
functionality.)
  This GStreamer plugin supports a large number of audio and video
 compression formats through the use of the libav library.)
 (license gpl2+)))
-
-(define-public gst-plugins-base-0.10
-  (package (inherit gst-plugins-base)
-(version 0.10.36)
-(source
- (origin
-  (method url-fetch)
-  (uri (string-append 
-
http://gstreamer.freedesktop.org/src/gst-plugins-base/gst-plugins-base-;
-version .tar.xz))
-  (sha256
-   (base32
-0jp6hjlra98cnkal4n6bdmr577q8mcyp3c08s3a02c4hjhw5rr0z
-(inputs
- `((glib ,glib)
-   (gstreamer ,gstreamer-0.10)))
-(native-inputs
-  `((pkg-config ,pkg-config)
-(glib ,glib bin)
-(python ,python-2)
diff --git a/gnu/packages/patches/gstreamer-0.10-bison3.patch 
b/gnu/packages/patches/gstreamer-0.10-bison3.patch
deleted file mode 100644
index f6eb90c..000
--- a/gnu/packages/patches/gstreamer-0.10-bison3.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-See https://bugzilla.gnome.org/show_bug.cgi?id=706462
-
-Subject: [PATCH] Make grammar.y work with Bison 3
-
-YYLEX_PARAM is no longer supported in Bison 3.

- gst/parse/grammar.y | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/gst/parse/grammar.y b/gst/parse/grammar.y
-index 8a9019c..f533389 100644
 a/gst/parse/grammar.y
-+++ b/gst/parse/grammar.y
-@@ -26,7 +26,6 @@
-  */
- 
- #define YYERROR_VERBOSE 1
--#define YYLEX_PARAM scanner
- 
- #define YYENABLE_NLS 0
- 
-@@ -659,6 +658,7 @@ static int yyerror (void *scanner, graph_t *graph, const 
char *s);
- %right '.'
- %left '!' '='
- 
-+%lex-param { void *scanner }
- %parse-param { void *scanner }
- %parse-param { graph_t *graph }
- %pure-parser
--- 
-1.8.3.4
-
diff --git a/gnu/packages/patches/gstreamer-0.10-silly-test.patch 
b/gnu/packages/patches/gstreamer-0.10-silly-test.patch
deleted file mode 100644
index 678dd7b..000
--- a/gnu/packages/patches/gstreamer-0.10-silly-test.patch
+++ /dev/null
@@ -1,14 +0,0 @@
-See 
http://lists.freedesktop.org/archives/gstreamer-bugs/2013-January/098461.html
-
-diff -ru gstreamer-0.10.36.orig/tests/check/Makefile.in 
gstreamer-0.10.36/tests/check/Makefile.in
 gstreamer-0.10.36.orig/tests/check/Makefile.in 2012-02-20 
23:48:29.0 +0100
-+++ gstreamer

Re: [PATCH] gnu: Add some more gstreamer plugins

[Ludovic Courtès]

John Darrington j...@gnu.org skribis:

 * gnu/packages/gstreamer.scm (gst-plugins-good): New variable.
 * gnu/packages/gstreamer.scm (gst-plugins-base): New inputs.

Please don’t repeat the file name, and list the newly-added dependencies.

 +(synopsis
 + Plugins for the gstreamer multimedia library)

s/gstreamer/GStreamer/

 +(description
 + GStreamer is a library for constructing graphs of media-handling
 +components.  The applications it supports range from simple Ogg/Vorbis
 +playback, audio/video streaming to complex audio (mixing) and video
 +(non-linear editing) processing.
 +
 +Applications can take advantage of advances in codec and filter technology
 +transparently.  Developers can add new codecs and filters by writing a
 +simple plugin with a clean, generic interface.
 +
 +GStreamer Good Plug-ins is a set of plug-ins that the developers consider to
 +have good quality code and correct functionality)
 +(license lgpl2.0+)))

Please remove the first two paragraphs, and add a sentence saying that
this package provides plug-ins.

OK to push with these changes, thank you!

Ludo’.

Re: [PATCH 1/2] gnu: gnunet: Remove Gstreamer dependency.

[Ludovic Courtès]

I’ve reported the bug at
https://bugzilla.gnome.org/show_bug.cgi?id=724073 and temporarily
disabled tests in the meantime.

Ludo’.