| Message ID | 20201209225553.28596-1-mail@davie.li |
|---|---|
| State | Accepted |
| Headers | show |
| Series | Add openfortivpn | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
On Thu, Dec 10, 2020 at 01:55:53AM +0300, David Dashyan wrote: > +(define-public openfortivpn Thanks! Overall, looks good to me. > + (native-inputs > + `(("openssl" ,openssl) > + ("autoconf" ,autoconf) > + ("autotools" ,automake) > + ("pkg-config" ,pkg-config))) In general, native-inputs are dependencies that are only used while building the package. Typically, OpenSSL is also used at run-time, so it probably should be a regular input. What do you think? > + (propagated-inputs > + `(("ppp" ,ppp))) Propagated-inputs are dependencies that will be installed along with your package when installing the package with e.g. `guix install openfortivpn`. This is for situations where the dependency is needed at run-time but for which the program lacks the ability to refer to dependencies directly. For example, a shell script that needs to invoke `ls` will need to find it on $PATH. It would not be easy to automatically substitute calls to `ls` to the full store path of `/gnu/store/...-coreutils-8.32/bin/ls`. However, most dependencies can be regular inputs, because the built package will refer to the full "/gnu/store/...-ppp-version/" path wherever it needs to invoke the dependency. So, does the package work if the openssl and ppp dependencies are just 'inputs' rather than native-inputs and propagated-inputs? You can use `guix gc --references $(guix build openfortinet)` to see what store references the built package has kept. These references are literally just strings that look like filenames in /gnu/store, found by scanning when the package build is completed. This tool can help one decide if an input should be propagated — if the built package refers to ppp, it likely can find it without propagation. Of course, practical testing is still the true measure. I hope that helps! > + (home-page "https://openvpn.net/") Is this the "home-page" of this program? Usually this field points to the site where the project is coordinated or marketed. It may even be the GitHub repo page. Can you send a revised patch based on this feedback? Please don't hesitate to ask any followup questions :)
Hello Leo! > I hope that helps! This does help. Thank you very much for detailed review and tips! I remember when I packaged it first it didn't run without ppp binary: ERROR: /usr/sbin/pppd: No such file or directory. Mistakenly I assumed that propagated inputs is THE way to include runtime dependencies such as commands. I greped the binary -- is does point to /gnu/store/xxx-ppp-2.4.8-1.yyy/sbin/pppd :) Didn't think of that. > So, does the package work if the openssl and ppp dependencies are just > 'inputs' rather than native-inputs and propagated-inputs? I've tested the package with suggested changes. It does work with ppp and openssl in inputs field. ldd points to libssl okay. $ guix environment --pure --ad-hoc openfortivpn [env]$ /run/setuid-programs/sudo --preserve-env \ openfortivpn -c ~/path/to/my/config > You can use `guix gc --references $(guix build openfortinet)` to see > what store references the built package has kept. These references are > literally just strings that look like filenames in /gnu/store, found > by scanning when the package build is completed. Great I will use it! > Is this the "home-page" of this program? Whoops I think i copypasted from definition below. This package doesn't have a home page it seems. BTW I'm what is the right way to send fixes patch? Sending the whole thing again is easier on your side then adding commit patch on top?
On Sat, Dec 12, 2020 at 10:58:26PM +0300, David Dashyan wrote: > BTW I'm what is the right way to send fixes patch? Sending the whole > thing again is easier on your side then adding commit patch on top? Yes, it's easier if you send a completely new patch rather than an incremental patch. Thanks again!
diff --git a/gnu/packages/vpn.scm b/gnu/packages/vpn.scm index 04c34c3d4d..8af9b89414 100644 --- a/gnu/packages/vpn.scm +++ b/gnu/packages/vpn.scm @@ -14,6 +14,7 @@ ;;; Copyright © 2020 Brice Waegeneire <brice@waegenei.re> ;;; Copyright © 2020 Ryan Prior <rprior@protonmail.com> ;;; Copyright © 2020 Ivan Kozlov <kanichos@yandex.ru> +;;; Copyright © 2020 David Dashyan <mail@davie.li> ;;; ;;; This file is part of GNU Guix. ;;; @@ -287,6 +288,35 @@ and probably others.") (license license:lgpl2.1) (home-page "https://www.infradead.org/openconnect/"))) +(define-public openfortivpn + (package + (name "openfortivpn") + (version "1.15.0") + (source (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/adrienverge/openfortivpn") + (commit (string-append "v" version)))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "1qsfgpxg553s8rc9cyrc4k96z0pislxsdxb9wyhp8fdprkak2mw2")))) + (build-system gnu-build-system) + (native-inputs + `(("openssl" ,openssl) + ("autoconf" ,autoconf) + ("autotools" ,automake) + ("pkg-config" ,pkg-config))) + (propagated-inputs + `(("ppp" ,ppp))) + (home-page "https://openvpn.net/") + (synopsis "Client for PPP+SSL VPN tunnel services") + (description + "Client for PPP+SSL VPN tunnel services. It spawns a pppd process and +operates the communication between the gateway and this process. It is +compatible with Fortinet VPNs.") + (license license:gpl3+))) + (define-public openvpn (package (name "openvpn")