From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id qBGoAoJmTWIpMQAAgWs5BA (envelope-from ) for ; Wed, 06 Apr 2022 12:08:02 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id aHcMAIJmTWKs3gAA9RJhRA (envelope-from ) for ; Wed, 06 Apr 2022 12:08:02 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9A5F1C2B0 for ; Wed, 6 Apr 2022 12:08:01 +0200 (CEST) Received: from localhost ([::1]:45520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nc2a0-0003Xf-I8 for larch@yhetil.org; Wed, 06 Apr 2022 06:08:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49748) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nc2Z4-000357-5O for guix-patches@gnu.org; Wed, 06 Apr 2022 06:07:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:34889) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nc2Z3-0006CL-Sn for guix-patches@gnu.org; Wed, 06 Apr 2022 06:07:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nc2Z3-0004G2-MQ for guix-patches@gnu.org; Wed, 06 Apr 2022 06:07:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#54744] [PATCH] Update gstreamer and its families to 1.20.1. Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Wed, 06 Apr 2022 10:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54744 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Zhu Zihao Cc: 54744@debbugs.gnu.org Received: via spool by 54744-submit@debbugs.gnu.org id=B54744.164923956316287 (code B ref 54744); Wed, 06 Apr 2022 10:07:01 +0000 Received: (at 54744) by debbugs.gnu.org; 6 Apr 2022 10:06:03 +0000 Received: from localhost ([127.0.0.1]:57019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc2Y6-0004Ec-M1 for submit@debbugs.gnu.org; Wed, 06 Apr 2022 06:06:03 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:26934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nc2Y4-0004E9-EP for 54744@debbugs.gnu.org; Wed, 06 Apr 2022 06:06:01 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4KYKsJ3tLmz3xNK; Wed, 6 Apr 2022 12:05:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1649239556; bh=p/z7o7mk6JOCzC83bjiGgocxOgogjZBuKLPk8Mrz09c=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=ic2xLSG0CBusftKMZDvlTexSaHbrNNPJINtBlg+LOUbedZySN6QtG9740tbURZ0NL FlmIr8kqT7K/YTPue14EUCa73ne9FVllc/85sX4MJ7m4gterNJPVwUWyUGxI/xav5T a8p5Ni0z6Z7u2cQY5S5/WfjnHvex5vgbE1NSEx4Y= Message-ID: <1b4e9351aef38bba2b0a7f6fd10d385dadf7d785.camel@ist.tugraz.at> From: Liliana Marie Prikler Date: Wed, 06 Apr 2022 12:05:55 +0200 In-Reply-To: <86czhud07t.fsf@163.com> References: <86bkxeop1g.fsf@163.com> <2a54af688cb50fc4bdaa96650be5718d12d420f0.camel@ist.tugraz.at> <86czhud07t.fsf@163.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1649239681; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=p/z7o7mk6JOCzC83bjiGgocxOgogjZBuKLPk8Mrz09c=; b=W0TOp5lfxBgR4ekYkpWRF/0b2SWZfOs8UAaKRzCTpqTM65XelwPZoJQm4n/SzcTD0SVE0D 98eMpsj8q1wx2yMYyiNdL5t4+tHUjBMXrRWZLyT1qSRpDePEH5NQN//4BoEfh6C2pBMoIK Ovk7SEWiOoWKr7YxTJkj2vETEzxagD879xkv22SZtvhqFZIfBY19+vICdhECp/ZAWlsCf+ /zDJX/St+YiQ3zeK9JMzC4bl0Wd/XNy8kZcwCT05Fm2YrSMKcHfwDExvqs96jEv9S7/pik A6Tguuim3Q1zmYpqC5zN7XOwQCTMO5mNIkFPkm1aKBSFWHLfcQkFOoCpPiCLyA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1649239681; a=rsa-sha256; cv=none; b=SCOdNZLR2gT5zsgdd1tz15NpWmF8kiBtQFwPVpwfgmufSH4pY2PGmxLK4TS8UK5ImspJUg h/TO54mp4bqStS/Iucyl9+N1xOTDL4fFqYL9zLycNI/882sYukITe09DMLl8LSNsuJYuWd nNLt/TPLUUtmn7SCnUxg0JkHuGwRbY2GOYTqyrqrBowY53FfEz66N2GL8c5fFavpQUC+Jw HV1Zvm0S/dmZ7C1oz52KfrAKQoT4i02VEFgpoBDMm0+zUW26OSapPHTMNwn/oPwDwpkzf3 RD+oI43EyD5yUuVdXiJgIvAB/lUZ+JBHVJy18HvPOlYsgolPDS5EP/PULLmnYQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=ic2xLSG0; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: 5.73 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=tugraz.at header.s=mailrelay header.b=ic2xLSG0; dmarc=fail reason="SPF not aligned (relaxed)" header.from=tugraz.at (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 9A5F1C2B0 X-Spam-Score: 5.73 X-Migadu-Scanner: scn0.migadu.com X-TUID: KwmujHA0GHxN Am Mittwoch, dem 06.04.2022 um 17:16 +0800 schrieb Zhu Zihao: > > Liliana Marie Prikler writes: > > > * gnu/packages/gstreamer.scm (%gstreamer-version): New variable. > > I don't think that's necessary or even beneficial.  Drop it. > > Ditto for all the packages referencing it. > > Good. From my view this can ensure packager to update every package > of gstreamer, not only a part of them. Gstreamer now use a monorepo > for all its components, they'll also have regular release cycle for > all components. Can't really say that the monorepo is a good idea nor condemn it without knowing the motivations behind, but let's hope that things still build in isolation. As for updating, the new variable does more harm than good. It forces every build to break when actually the build would have been sane. IMHO you should instead leave compatibility breaking changes to upstream. > > > * gnu/packages/gstreamer.scm (gst-plugins-good): Update to > > > 1.20.1. > > > [...] > > > [propagated-inputs]: Remove unnecessary propagation. > > Do gst-plugins-good really no longer depend on the base plugins? > > > > > * gnu/packages/gstreamer.scm (gst-plugins-ugly): Update to > > > 1.20.1. > > > [...] > > > [propagated-inputs]: Remove unnecessary propagation. > > Idem. > > > > > * gnu/packages/gstreamer.scm (gst-libav): Update to 1.20.1. > > > [...] > > > [propagated-inputs]: Remove unnecessary propagation. > > Ibidem. > > I checked the ugly and good and gst-libav, they do rely on > gst-plugins-base, but no propagation needed. I don't find a reason > that they really requires propagation, because their content just a > so file. > Gstreamer in Nixpkgs also don't have propagations for above packages. I personally found that missing these GstElements at runtime can screw you up. If that is no longer the case, then fair enough, but you need to prove that by launching a gst pipeline using a plugin from e.g. gst- plugins-good without having gst-plugins-base in your GST paths. > For necessary propgations like gst-plugins-bad(header or gi), I've > added some comments. That is always welcome. > > > > > (gst-plugins/selection): Remove because it's not useful in > > > packaging and requires extra maintenance. > > > * gnu/packages/video.scm (pitivi)[inputs]: Use gst-plugins-bad. > > Packages that only require some bad plugins and can exactly state > > which should not be forced to pull in all of them.  The bad plugins > > are explicitly named bad, because they're bad.  Enabling any of > > them beyond necessity should be an active choice of the user. > > > > > > > * gnu/packages/webkit.scm (webkitgtk): > > > [inputs]: Add gst-plugins-bad. It provides gstreamer-parsecodec. > > My, what a perfect use case for gst-plugins/selection that would > > be. Note, that gratuitous media codecs are an additional attack > > surface. > > > > Cheers > > I'll investigate into it. > > Currently I only see pitivi use gst-plugins/selection. Many packages > use gst-plugins-bad directly. Whether to use gst-plugins-bad or a selection of it is a per-package decision.  It depends on whether upstream communicates clearly which plugins they need or whether you'd have to pull hairs out of their noses to do so. In the latter case, it's likelier that they include it just because they can and will introduce more dependencies on it as time marches forward. For most packages not using it, there might however just be a historical reason – gst-plugins/selection has not existed for that long. If you feel it is underused, you might want to search for packages that (like Pitivi) provide a clear description of what they need. > BTW, how to maintain changes for a long patches series like this in > the review phase? It's quite annoying when I make some minor changes > but I have to re-sent all patches to the mail list. Ideally, you would send them one by one using `git send-email'. Then you can send a v2 for an individual patch. Note that excessive use of minor changes might however annoy both reviewers and infrastructure (I hear there's a patchwork instance somewhere actually building these packages). In my opinion it would be wiser to let it sit for a while, collect opinions, and then formulate a v2 with all of those in mind. Note that in your case, v2 should also be sent to staging, i.e. [PATCH staging v2]. Cheers