From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Subject: Re: Packaging Jami progress Date: Thu, 5 Dec 2019 17:00:16 +0100 Message-ID: <20191205170016.7530c813@kompiuter> References: <20191104214754.793ec2ff@interia.pl> <20191125221517.1140d0c9@kompiuter> <874kyrlzmn.fsf@ambrevar.xyz> <20191126203259.0f4141ea@kompiuter> <20191130192121.11e0c968@kompiuter> <87fti52or5.fsf@ambrevar.xyz> <20191201173411.042e68f2@kompiuter> <878snw2bpn.fsf@ambrevar.xyz> <20191203164402.77a8c728@interia.pl> <87tv6hieeg.fsf@ambrevar.xyz> <20191203190235.53765cba@kompiuter> <87fti1mf1u.fsf@ambrevar.xyz> <87d0d5mez0.fsf@ambrevar.xyz> <20191204153631.509b9afb@interia.pl> <87immwt8kh.fsf@ambrevar.xyz> <20191204165038.7a5403f2@interia.pl> <87fti0t6rr.fsf@ambrevar.xyz> <20191204175614.29f663cd@kompiuter> <87a788t47g.fsf@ambrevar.xyz> <20191204182249.38fd0700@interia.pl> <87wobac07c.fsf@ambrevar.xyz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:40378) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ictYM-0005NC-81 for guix-devel@gnu.org; Thu, 05 Dec 2019 11:00:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ictYK-0003O2-Fr for guix-devel@gnu.org; Thu, 05 Dec 2019 11:00:29 -0500 Received: from smtpo.poczta.interia.pl ([217.74.65.239]:36134) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ictYJ-00030i-It for guix-devel@gnu.org; Thu, 05 Dec 2019 11:00:28 -0500 In-Reply-To: <87wobac07c.fsf@ambrevar.xyz> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: Guix-devel On Thu, 05 Dec 2019 15:32:23 +0100 Pierre Neidhardt wrote: > Thanks! > > The first 5 commits look good overall. Good to know. > For the last one, I think there are a few confusions: > > - native-inputs takes packages or origins, it does not take a lambda. > > - To call a custom function from the builder, you need to include the > module that defines it for the build system, e.g. > > (arguments > `(#:modules ((gnu packages telephony) > ,@%gnu-build-system-modules) > ...) > > - In this particular case, you could even make a macro that is > expanded at definition time, so that you would not even need to > import the module. If you don't know how to write scheme macros, no > need to go down this road for now. I read about macros, but didn't write anything complicated myself. I would have to reread the manual again. > But before fixing this issue, what are you trying to do exactly? > Do you intend to reuse this `jami-apply-dependency-patches' procedure > somewhere else? Jami developers apply many patches for different projects - currently our package code only patches pjproject, but ffmpeg needs patches for instance for auto bitrate support and I don't really know what has to be patched next - I listed the output of "find -name "*.patch"" in the first mail. I think copying and pasting similar code from pjproject package definition to ffmpeg definition isn't a good practice, that's why I decided to create a procedure taking patches from ring-project/daemon/contrib/ and applying them. > > On a different topic, to avoid sending patch archives in the future, > you could use a public repository clone of Guix. > There are a couple of free services out there, like sr.ht, maybe > gogs.io, etc. > This would make it smoother to track your progress and help you in > the process. I'll check this out, thanks. Jan Wielkiewicz