Re: gstreamer 2.22, webkitgtk 2.40.0, qt 5.15.8 and ffmpeg 6 on staging
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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.
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.
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 <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.
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.
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.
I'll withhold this patch for now pending further investigation... Thank you!
Re: [PATCH 16/24] gnu: gstreamer: Add qt-gstreamer.
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.
> 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.
> 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.
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.
> 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.
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.
> 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.
On Wed, 17 Aug 2016 10:53:23 +0200 David Cravenwrote: > 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.
> 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.
On Wed, 17 Aug 2016 10:02:26 +0200 David Cravenwrote: > 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.
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.
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.
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.
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.
> 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.
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.
LGTM.
[PATCH 14/24] gnu: gstreamer: Use license: prefix.
* 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.
* 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.
* 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
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
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
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
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
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
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
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'.
宋文武 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'.
宋文武 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.
宋文武 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.
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
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.
I’ve reported the bug at https://bugzilla.gnome.org/show_bug.cgi?id=724073 and temporarily disabled tests in the meantime. Ludo’.