Re: Maintaining GNU Jami package for Guix
Hello Jan, Jan Wielkiewicz ezt írta (időpont: 2019. nov. 3., V, 22:20): > Dnia 2019-11-03, o godz. 11:15:56 > Pierre Neidhardt napisał(a): > > > Can you share the complete recipe? > > > > Yes. I guess you want a patch of my entire work so far, because > pjproject-jami is meaningless without changes in jami, so I'm attaching > the whole patch. Also the commit messages are messy, any advice how > should they look? > > Thanks for working on this. I can share some recommendations on the commit messages and structuring changes. While developing, feel free to do however it is convenient for you. Then before sumitting: If I see it correctly, then three packages are involved, so this should be three commits. When adding a new package make that a separate commit. Make it one commit, the final version. (You can squash commits together to make it one.) The commit message there should be in the form: gnu: Add . When updating a package, you can make that a single commit. Commit message should be: gnu: : Update to . If anything else is done besides updating the version, mention that in the commit message. You can find examples in the git log of guix, like for commit: af561664b8191e2a34570176422f4d500d5fd4fb One further thing: If you order the patches, then the earlier patches can make it to upstream before the rest of the series. For example libresample could be incorporated eariler, reducing the amount of code on the branch. Thanks so much for working on Jami, and happy hacking! > Jan Wielkiewicz > Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
Re: Maintaining GNU Jami package for Guix
Dnia 2019-11-03, o godz. 11:15:56 Pierre Neidhardt napisał(a): > Can you share the complete recipe? > Yes. I guess you want a patch of my entire work so far, because pjproject-jami is meaningless without changes in jami, so I'm attaching the whole patch. Also the commit messages are messy, any advice how should they look? Jan Wielkiewicz 0001-change-the-fetch-method-of-pjproject-to-git-fetch-th.patch 0002-add-libresample-needed-for-Jami.patch 0003-adding-resample-as-a-pjproject-dependency.patch 0004-bump-jami-version-to-20191025.1.074a237.patch 0005-bump-jami-to-20191029.2.32830e6.patch 0006-bump-gnutls-to-3.6.10-the-version-Jami-is-going-to-u.patch 0007-bump-Jami-to-20191031.3.40360d8.patch 0008-bump-jami-to-20191101.3.67671e7.patch 0009-make-files-in-pjproject-writeable-improve-formatting.patch
Re: Maintaining GNU Jami package for Guix
Jan writes: > On Sun, 03 Nov 2019 19:12:03 +0100 > Marius Bakke wrote: > >> You can safely ignore the 'read only' messages, they are actually just >> warnings. > > Good to know, so they get applied anyway, no matter if read-only? Correct, at least as long as you use the '--force' flag to the patch command. :-) signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
On Sun, 03 Nov 2019 19:12:03 +0100 Marius Bakke wrote: > You can safely ignore the 'read only' messages, they are actually just > warnings. Good to know, so they get applied anyway, no matter if read-only? > The problem is that 2/3 hunks in the patch for > pjnath/src/pjnath/ice_strans.c failed -- I would guess Jami needs a > different version of pjproject, or the patches are applied in the > wrong order? Already using the proper version of pjproject, so the order seems to be the problem, thanks a lot! I'll ask the developers about the order. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Jan Wielkiewicz writes: > I have good and bad news. > The good news is I fixed curl by using the most recent Jami source > tarball - 20191031.3.40360d8. > The bad news is that pjproject-jami didn't really build, because the > patches failed to get applied again - the curl problem had occured > *before* the problem with pjproject-jami, so I thought it had been > fixed. > > I don't know what's the problem - the versions of pjproject and gnutls > seem to be correct, I can check other dependencies of pjproject, but > it'll take some time. I'll also ask the devs if I'm using the right > versions now, but something seems to be broken for me, see this fail: > > patching file pjnath/src/pjnath/ice_strans.c > Hunk #1 succeeded at 366 (offset -25 lines). > Hunk #2 FAILED at 1655. > Hunk #3 FAILED at 1861. > 2 out of 3 hunks FAILED -- saving rejects to file > pjnath/src/pjnath/ice_strans.c.rej File > pjnath/src/pjnath/turn_session.c is read-only; trying to patch anyway > patching file pjnath/src/pjnath/turn_session.c Hunk #1 succeeded at 974 > (offset -1 lines). Hunk #2 succeeded at 1022 (offset -1 lines). > Hunk #3 succeeded at 1050 (offset -1 lines). > Hunk #4 succeeded at 1090 (offset -1 lines). > File pjnath/src/pjnath/turn_sock.c is read-only; trying to patch anyway > patching file pjnath/src/pjnath/turn_sock.c > command "patch" "--force" "-p1" "-i" "Savoir-faire Linux > patches/fix_ebusy_turn.patch" failed with status 1 You can safely ignore the 'read only' messages, they are actually just warnings. The problem is that 2/3 hunks in the patch for pjnath/src/pjnath/ice_strans.c failed -- I would guess Jami needs a different version of pjproject, or the patches are applied in the wrong order? signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Jan writes: > On Sun, 03 Nov 2019 17:37:10 +0100 > Marius Bakke wrote: > >> I did not find any cURL or GnuTLS patches there. Maybe I >> misunderstood something? > > Gnutls is a dependency of Jami, curl is probably a dependency of a > dependency of Jami, but that's all - what is important here is that > Jami uses a modified version of pjproject, which adds support for > gnutls - that's why patching fails. What happened with curl is a > mystery for me, the only thing I know is that building curl had failed > before building pjproject-jami, so I thought the patching process > succeeded. But since it works now, it doesn't matter (at least for me). OK, thanks for the explanation. >> There are many reasons not to include multiple versions of a package, >> but for cURL and GnuTLS in particular, the main reason is that there >> are security fixes in nearly every new version. Thus, we can only >> support the latest one. > > Okay, I'll try using the latest packages for Jami then. Excellent, good luck and don't hesitate to come back if you have other questions! :-) signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
On Sun, 03 Nov 2019 18:07:24 +0100 Marius Bakke wrote: > Git checkouts are read-only because they are copied to the store, > which strips write permissions. It could be mitigated by having > 'git-fetch' return a tarball instead of a directory, but in practice > read-only checkouts rarely causes problems (there is > 'make-file-writable' in case it does). I've tried it already, but it somehow doesn't work, check my previous mails. Seems I'm missing something important. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
On Sun, 03 Nov 2019 17:37:10 +0100 Marius Bakke wrote: > I did not find any cURL or GnuTLS patches there. Maybe I > misunderstood something? Gnutls is a dependency of Jami, curl is probably a dependency of a dependency of Jami, but that's all - what is important here is that Jami uses a modified version of pjproject, which adds support for gnutls - that's why patching fails. What happened with curl is a mystery for me, the only thing I know is that building curl had failed before building pjproject-jami, so I thought the patching process succeeded. But since it works now, it doesn't matter (at least for me). > Both GnuTLS and cURL have stable ABIs. That means, a package linked > against cURL 7.63 will almost certainly work with cURL 7.66 without > changes (even without recompilation). Don't know why, but Jami seems to use a specific version of gnutls, but if what you say is true, then it doesn't matter. I started looking for outdated dependencies, because I thought they could be the source of the problem. > There are many reasons not to include multiple versions of a package, > but for cURL and GnuTLS in particular, the main reason is that there > are security fixes in nearly every new version. Thus, we can only > support the latest one. Okay, I'll try using the latest packages for Jami then. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Jan Wielkiewicz writes: > Why "pjnath/src/pjnath/turn_session.c is read-only; trying to patch > anyway"? Why is it read-only. I don't get it, are we missing some > permissions? Somehow this wasn't a problem before - the previous > version of pjproject-jami didn't have this problem. Is it a bug in Guix? Git checkouts are read-only because they are copied to the store, which strips write permissions. It could be mitigated by having 'git-fetch' return a tarball instead of a directory, but in practice read-only checkouts rarely causes problems (there is 'make-file-writable' in case it does). signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Jan Wielkiewicz writes: > Dnia 2019-10-31, o godz. 23:26:39 > Marius Bakke napisał(a): > >> Do you have a link to the patches that Jami/pjproject needs? > You can find patches in the ring-project/daemon/contrib/src/pjproject > directory from the latest source tarball here: > https://dl.jami.net/ring-release/tarballs/ I did not find any cURL or GnuTLS patches there. Maybe I misunderstood something? >> It would be great if we could use system versions of GnuTLS and cURL, >> because otherwise Jami risks not getting security updates. > A bit unlikely, they update dependencies quickly, but they're slower > than upstream. Keeping a separate version and updating it paralelly > will prevent breaking the build process of the modified pjproject > version. > >> If they really need special patched versions of some libraries, you >> can do something along these lines to create a >> cusctm variant: >> >> (define-public gnutls/jami >> (hidden-package >>(package/inherit >> gnutls >> (source (origin >> (inherit (package-source gnutls)) >> (patches (append (origin-patches gnutls) >>(search-patches >> "gnutls-jami.patch" > Why can't we just keep paralell version for a package? Like > gnutls @ 3.6.7, gnutls @ 3.6.9 etc? Both GnuTLS and cURL have stable ABIs. That means, a package linked against cURL 7.63 will almost certainly work with cURL 7.66 without changes (even without recompilation). There are many reasons not to include multiple versions of a package, but for cURL and GnuTLS in particular, the main reason is that there are security fixes in nearly every new version. Thus, we can only support the latest one. signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Sorry, wrong command, sending the patch again...
Jan
>From 2f67e4c77ffb675bed3019b4289b3135db140015 Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sun, 27 Oct 2019 01:16:52 +0200
Subject: [PATCH 1/9] change the fetch method of pjproject to git; fetch the
exact commit needed for Jami; do not remove folders, which are not present in
the checkout
---
gnu/packages/telephony.scm | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index 127a856cc3cc65ccc29b99d4e5d83143400b741e..d17124ed4b22139f87a1efa3010153e97dfd5bb2 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -555,10 +555,10 @@ calls and messages")
(version "2.9")
(source
(origin
- (method url-fetch)
- (uri (string-append
- "http://www.pjsip.org/release/; ;
- version "/" name "-" version ".tar.bz2"))
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/pjsip/pjproject.git;)
+ (commit "5dfa75be7d69047387f9b0436dd9492bbbf03fe4")))
(modules '((guix build utils)))
(snippet
'(begin
@@ -566,9 +566,9 @@ calls and messages")
;; Things we don't need:
;; BaseClasses - contains libraries from Windows SDK
;; we don't need it, at least not now.
- (list "BaseClasses" "bin" "g7221" "ilbc" "milenage"
+ (list "BaseClasses" "g7221" "ilbc" "milenage"
"speex" "threademulation" "yuv" "bdsound"
- "gsm" "lib" "mp3" "resample" "srtp" "webrtc"
+ "gsm" "mp3" "resample" "srtp" "webrtc"
;; Keep only resample, build and README.txt.
"build/baseclasses" "build/g7221" "build/gsm"
"build/ilbc" "build/milenage" "build/resample"
@@ -591,7 +591,7 @@ calls and messages")
)
(sha256
(base32
- "0dm6l8fypkimmzvld35zyykbg957cm5zb4ny3lchgv68amwfz1fi"
+ "1ayj6n7zd5wvd1nzj2k9s57fb4ckc2fv92k5sjvhd87yg69k3393"
(build-system gnu-build-system)
(inputs
`(("portaudio" ,portaudio)))
--
2.23.0
>From a25f5ad984f01f41400a54a2dde07b6aee6e9e6c Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sun, 27 Oct 2019 14:26:08 +0100
Subject: [PATCH 2/9] add libresample needed for Jami
---
gnu/packages/audio.scm | 23 +++
1 file changed, 23 insertions(+)
diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index 110903e2fe6b094f8021e4fb29eff3720fcf6511..63dbb1fd0ef20853d5d13e5ae70c4b54b3879c8b 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -2299,6 +2299,29 @@ aimed at audio/musical applications.")
(base32
"04fajrass3ymr72flx5js5vxc601ccrmx8ny8scp0rw7j0igyjdr")))
+(define-public resample
+ (package
+ (name "resample")
+ (version "1.8.1")
+ (source (origin
+ (method url-fetch)
+ (uri (string-append "https://ccrma.stanford.edu/~jos/gz/resample-; version
+".tar.gz"))
+ (sha256 (base32
+ "074zj8ydp05yy1hjcglfv3hkvj4cm50f9nralka1992pm6yf8yvy"
+ (build-system gnu-build-system)
+ ;; (inputs)
+ ;; (propagated-inputs)
+ (native-inputs
+`(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("pkg-config" ,pkg-config)
+ ("libtool" ,libtool)))
+ (synopsis "")
+ (description "")
+ (license license:lgpl2.1+)
+ (home-page "https://ccrma.stanford.edu/~jos/resample/Free_Resampling_Software.html;)))
+
(define-public rubberband
(package
(name "rubberband")
--
2.23.0
>From bf8d0a15b289f7cb80f7f6d1b640163130a4fa27 Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sun, 27 Oct 2019 14:33:17 +0100
Subject: [PATCH 3/9] adding resample as a pjproject dependency
---
gnu/packages/telephony.scm | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index d17124ed4b22139f87a1efa3010153e97dfd5bb2..2dc3ccfe596dd0e66e5e0e02f1eb6bd3e991b472 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -601,6 +601,7 @@ calls and messages")
`(("speex" ,speex)
("libsrtp" ,libsrtp)
("gnutls" ,gnutls)
+ ("resample", resample)
("util-linux" ,util-linux)))
(native-inputs
`(("autoconf" ,autoconf)
--
2.23.0
>From c7e4ff2c7eec7671efd0886c229dde82358e38f1 Mon Sep 17 00:00:00 2001
From: Jan Wielkiewicz
Date: Sun, 27 Oct 2019 14:38:51 +0100
Subject: [PATCH 4/9] bump jami version to 20191025.1.074a237
---
gnu/packages/telephony.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index 2dc3ccfe596dd0e66e5e0e02f1eb6bd3e991b472..1bd508accc778f107244e37701189951906837e6 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -635,7 +635,7 @@ calls and messages")
Initiation Protocol (SIP) and a multimedia framework.")
(license license:gpl2+)))
-(define %jami-version
Re: Maintaining GNU Jami package for Guix
Dnia 2019-11-01, o godz. 20:01:26
Pierre Neidhardt napisał(a):
> Git preserves permissions, so if upstream made it read-only (probably
> a mistake), then it will be read-only in the checkout. No problem,
> you can make it writable with
> `make-file-writable'.
>
Don't know why, but it doesn't work...
It still tells me files are read-only.
I do something like this:
(modify-phases %standard-phases
(add-after 'unpack 'make-git-checkout-writable
(lambda _
(for-each make-file-writable (find-files "."))
#t))
(add-after 'unpack 'apply-patches
(lambda* (#:key inputs #:allow-other-keys)
(let ((savoir-faire-linux-patches-directory "Savoir-faire
Linux patches") ;; Comes from
;;
"ring-project/daemon/contrib/src/pjproject/rules.mak". ;; WARNING:
These amount for huge changes in pjproject. ;; Particularly, they add
support for GnuTLS. (savoir-faire-linux-patches
'("add_dtls_transport"
"android"
"disable_local_resolution"
Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-11-01, o godz. 20:02:22 Pierre Neidhardt napisał(a): > Because gnutls with Jami patches should not be called gnutls: it's a > non-vanilla version of GnuTLS. And I doubt it would be useful to > anyone but Jami. Actually gnutls is without patches, just an older version. What has patches is pjproject. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Jan Wielkiewicz writes: > Why "pjnath/src/pjnath/turn_session.c is read-only; trying to patch > anyway"? Why is it read-only. I don't get it, are we missing some > permissions? Somehow this wasn't a problem before - the previous > version of pjproject-jami didn't have this problem. Is it a bug in Guix? Git preserves permissions, so if upstream made it read-only (probably a mistake), then it will be read-only in the checkout. No problem, you can make it writable with `make-file-writable'. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Jan Wielkiewicz writes: > Why can't we just keep paralell version for a package? Like > gnutls @ 3.6.7, gnutls @ 3.6.9 etc? Because gnutls with Jami patches should not be called gnutls: it's a non-vanilla version of GnuTLS. And I doubt it would be useful to anyone but Jami. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-31, o godz. 23:26:39 Marius Bakke napisał(a): > Do you have a link to the patches that Jami/pjproject needs? You can find patches in the ring-project/daemon/contrib/src/pjproject directory from the latest source tarball here: https://dl.jami.net/ring-release/tarballs/ > It would be great if we could use system versions of GnuTLS and cURL, > because otherwise Jami risks not getting security updates. A bit unlikely, they update dependencies quickly, but they're slower than upstream. Keeping a separate version and updating it paralelly will prevent breaking the build process of the modified pjproject version. > If they really need special patched versions of some libraries, you > can do something along these lines to create a > cusctm variant: > > (define-public gnutls/jami > (hidden-package >(package/inherit > gnutls > (source (origin > (inherit (package-source gnutls)) > (patches (append (origin-patches gnutls) >(search-patches > "gnutls-jami.patch" Why can't we just keep paralell version for a package? Like gnutls @ 3.6.7, gnutls @ 3.6.9 etc? > I realize now that this won't do the right thing wrt grafts, but we > can deal with that later. :-) Don't really know what grafts are yet, so we can indeed skip this now :) Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Jan Wielkiewicz writes: > Also as for packaging Jami generally, I think we should keep a separate > versions of things like gnutls and pjproject (basically all > dependencies of pjproject), because version used by Jami are often not > up to date and considering patches getting applied, using an unproper > version can break compilation. Do you have a link to the patches that Jami/pjproject needs? It would be great if we could use system versions of GnuTLS and cURL, because otherwise Jami risks not getting security updates. If they really need special patched versions of some libraries, you can do something along these lines to create a custom variant: (define-public gnutls/jami (hidden-package (package/inherit gnutls (source (origin (inherit (package-source gnutls)) (patches (append (origin-patches gnutls) (search-patches "gnutls-jami.patch" I realize now that this won't do the right thing wrt grafts, but we can deal with that later. :-) signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Fantastic! I suggest you ask upstream which precise version of Curl they use. You can still try to skip the tests in the meantime, but the messages are not very reassuring... :p -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-27, o godz. 19:18:19 Pierre Neidhardt napisał(a): > Thanks for the update! :) > Which failing patch and what fails? Output? Sorry, I sent a mail explaining everything yesterday, but it seems it got lost somewhere - your or mine mail provider does something (blocks?) or the ML has a bug. Reposting it here, hope this time it'll work: Dnia 2019-10-26, o godz. 12:12:44 Pierre Neidhardt napisał(a): > Nice, thank you for getting in touch with the developers, this is > very informative. > > Have you tried using pjproject > 5dfa75be7d69047387f9b0436dd9492bbbf03fe4 ? > Does the patching still fail? I've tried this today and it still fails. Don't know if the fails with the exact commit are much different from 2.9 fetched from the tarball. If they're not different, then you can see what happens in one of my comments here https://git.ring.cx/savoirfairelinux/ring-project/issues/691 > Also it now depends on Restinio, I think we are missing this one, so > it would need to be packaged first. (But that's unrelated to the > patch issue.) I'm going to package it eventually, but for now I want to fix the current problems and then proceed with the rest. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-26, o godz. 12:12:44 Pierre Neidhardt napisał(a): > Nice, thank you for getting in touch with the developers, this is > very informative. > > Have you tried using pjproject > 5dfa75be7d69047387f9b0436dd9492bbbf03fe4 ? > Does the patching still fail? I've tried this today and it still fails. Don't know if the fails with the exact commit are much different from 2.9 fetched from the tarball. If they're not different, then you can see what happens in one of my comments here https://git.ring.cx/savoirfairelinux/ring-project/issues/691 > Also it now depends on Restinio, I think we are missing this one, so > it would need to be packaged first. (But that's unrelated to the > patch issue.) I'm going to package it eventually, but for now I want to fix the current problems and then proceed with the rest. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-27, o godz. 19:18:19 Pierre Neidhardt napisał(a): > Thanks for the update! :) > Which failing patch and what fails? Output? Sorry, I sent a mail explaining everything yesterday, but it seems it got lost somewhere - your or mine mail provider does something (blocks?) or the ML has a bug. Reposting it here, hope this time it'll work (it didn't work again - sending this the second time, don't know what's wrong - I use the "reply to all" option, it generally works, don't know why this case is different): Dnia 2019-10-26, o godz. 12:12:44 Pierre Neidhardt napisał(a): > Nice, thank you for getting in touch with the developers, this is > very informative. > > Have you tried using pjproject > 5dfa75be7d69047387f9b0436dd9492bbbf03fe4 ? > Does the patching still fail? I've tried this today and it still fails. Don't know if the fails with the exact commit are much different from 2.9 fetched from the tarball. If they're not different, then you can see what happens in one of my comments here https://git.ring.cx/savoirfairelinux/ring-project/issues/691 > Also it now depends on Restinio, I think we are missing this one, so > it would need to be packaged first. (But that's unrelated to the > patch issue.) I'm going to package it eventually, but for now I want to fix the current problems and then proceed with the rest. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Thanks for the update! :) Jan Wielkiewicz writes: > also gnutls needed for pjproject-jami has > the wrong version - 3.6.9, whereas the current version used by Jami is > 3.6.7 according to this commit > https://review.jami.net/c/ring-daemon/+/12108/1/contrib/src/gnutls/rules.mak > (but I'll ask developers to make sure) > > I tried downgrading gnutls (because I think it's the cause of failing > patches), Which failing patch and what fails? Output? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Dnia 2019-10-25, o godz. 17:03:01 Pierre Neidhardt napisał(a): > Hi Jan, > > any luck with Jami? Let me know if you need more specific help (my > previous message was maybe not too clear :p), I can dig into this > deeper in the coming days. > I had little time recently, but I've been trying different things in order to build pjproject. What I know is the current version of pjproject doesn't compile at all without Savoir-failre linux patches. I also talked with Jami developers about the current state of Jami and pjproject: https://git.ring.cx/savoirfairelinux/ring-project/issues/691 They're still applying patches for pjproject and the version they use is 2.9, tried updating jami-source and pjproject, but applying the patches failed. I suspect we're missing some dependencies of pjproject. I can post error messages, but have to sit down and build everything again. I'm going to try this weekend. Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Hi Jan, any luck with Jami? Let me know if you need more specific help (my previous message was maybe not too clear :p), I can dig into this deeper in the coming days. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: Maintaining GNU Jami package for Guix
Hi Jan, > On Sat, 19 Oct 2019 22:52:58 +0200 > Ricardo Wurmus wrote: > >> We always try to unbundle libraries, because that ensures that all >> packages benefit from security fixes. >> > > Great, so I have to package everything recursively :) > Just to make it clear, because I'm a bit unfamiliar with build systems > and the package API - will packing every library pjproject uses and > just adding it in the "inputs" field make building possible, or will I > have to do magic and copy built packages into "third_party" folder in > the pjproject source tree? This depends very much on how friendly the build system used by pjproject is. Some applications’ build systems resist any attempts to request the application to be linked with existing libraries, whereas others will only fall back to the bundled libraries if the libraries don’t already exist somewhere on LIBRARY_PATH. This is why it’s often a big headache to package software that uses custom build systems, as they often lack sane mechanisms for library discovery or overriding. > Also what if pjproject (or any package I want to update) depends on a > specific version of a library? Should I just update the package, or > should I add a separate version of the library? Let’s discuss this when the need actually arises. We have a few instances of packages that are named “…-for-some-other-package”, but let’s not add them when they aren’t absolutely necessary. -- Ricardo
Re: Maintaining GNU Jami package for Guix
On Sat, 19 Oct 2019 22:52:58 +0200 Ricardo Wurmus wrote: > We always try to unbundle libraries, because that ensures that all > packages benefit from security fixes. > Great, so I have to package everything recursively :) Just to make it clear, because I'm a bit unfamiliar with build systems and the package API - will packing every library pjproject uses and just adding it in the "inputs" field make building possible, or will I have to do magic and copy built packages into "third_party" folder in the pjproject source tree? Also what if pjproject (or any package I want to update) depends on a specific version of a library? Should I just update the package, or should I add a separate version of the library? Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Jan Wielkiewicz writes: > Why are third party directories removed if they're necessary to build > pjproject? Should I package contents of these folders as separate > package? We always try to unbundle libraries, because that ensures that all packages benefit from security fixes. -- Ricardo
Re: Maintaining GNU Jami package for Guix
Hello, Dnia 2019-10-19, o godz. 11:02:35 Pierre Neidhardt napisał(a): > Hi Jan, > > glad you are interested in picking this one up! :) > I'm the last packager of Jami, so I might be able to help. Yes, thank you, I definitely will need help. > After a quick glance, here is the situation it seems: > > Jami used to depend on their own fork of pjproject (as packaged in > Guix). > However it seems that recent versions have dropped the fork to use > upstream instead. _This needs to be confirmed._ It seems the latest version still has patches for pjproject in the source code, but I can ask the devs about it. > If this is the case, switching the pjproject input to use upstream > should work when updating Jami. I've tried updating Jami, but pjproject seems to be a problem - don't know what have changed, but now even the currently packaged version of pjproject won't compile. Here's the log: starting phase `autoconf' autoconf: error: invalid option `-vfi' Try `autoconf --help' for more information. command "autoconf" "-vfi" "-o" "aconfigure" "aconfigure.ac" failed with status 1 I've also tried updating pjproject to the current version Jami uses - 2.8, it throws the same error. I managed to skip that by removing the "-vfi" options by commenting it out like this: (add-before 'patch-source-shebangs 'autoconf (lambda _ (invoke "autoconf" "-o" ;"-vfi" "aconfigure" "aconfigure.ac"))) But then it fails later, while doing "make dep": make[2]: Entering directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make[2]: *** gsm: No such file or directory. Stop. make[2]: Leaving directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make[1]: *** [Makefile:7: dep] Error 1 make[1]: Leaving directory '/tmp/guix-build-pjproject-2.8.drv-0/pjproject-2.8/third_party/build' make: *** [Makefile:14: dep] Error 1 command "make" "dep" failed with status 2 Why are third party directories removed if they're necessary to build pjproject? Should I package contents of these folders as separate package? Also something is causing builds of Jami to be irreproducible - every time I run guix upgrade, Jami gets upgraded to the same version. Is there a way to check what exactly is unstable? > The rest should be mostly straightforward stuff. Don't hesitate to > come back to me if you need more help. Okay, thanks. > Cheers! > Jan Wielkiewicz
Re: Maintaining GNU Jami package for Guix
Hello Jan, Jan writes: > Hi all, > It seems Jami package is outdated and unmaintained, so I would like to > become a maintainer of the package. > I know the basics of Guile Scheme and Guix System, I'm more or > less familiar with how Jami works and what are its dependencies, but I > don't know much about development, git or build systems. > What are the things I need to learn to be able to start packaging? Thank you for your interest in maintaining Jami! You will need to learn the basics of git in order to make commits and send patches. You should also read this section of the manual: https://guix.gnu.org/manual/en/guix.html#Building-from-Git A typical workflow would go along these lines: First time setup: $ git clone https://git.savannah.gnu.org/git/guix.git $ cd guix $ guix environment guix [env] $ ./bootstrap [env] $ ./configure --localstatedir=/var [env] $ make -j4 # adjust for number of cores on your machine That will build the latest version of Guix locally. Now you can use the './pre-inst-env' script to run guix operations from this directory. You should repeat the 'make' step when you have pulled or made other changes, to pre-compile the Scheme modules. Making changes to the repository: $ ./pre-inst-env guix edit jami $ [...hacking away...] $ ./pre-inst-env guix build jami (investigate build failures, repeat until it works) Once you are happy with your changes, you should commit them and send a patch to guix-patc...@gnu.org: $ git add -p (press y on the hunks you wish to stage) $ git commit # commit the staged changes $ git send-email --to guix-patc...@gnu.org -1 HEAD Alternatively you can create a patch file with 'git format-patch -1 HEAD' and use your favourite mail user agent to send it. Please don't hesitate to ask for help here or on the #guix IRC channel if you get stuck on anything :-) Hope this helps, Marius signature.asc Description: PGP signature
