Re: Packaging Jami progress

[Jan]

On Thu, 05 Dec 2019 15:32:23 +0100
Pierre Neidhardt <address@hidden> 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/<dependency-name> 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