bug#26391: [PATCH 0/1] Patching getcap and which in torsocks

bug#26391: [PATCH 0/1] Patching getcap and which in torsocks

[Eric Bavier]

This patches references to the 'getcap' and 'which' programs in 'torsocks'
so that users that don't have either of those packages installed in their
profiles do not see confusing output about them missing.  Usually torsocks
will still function in that case, but it's probably better to have them
available.

I've so far done this sort of thing for several packages with shell scripts,
and each time I'm convinced that this method is better than declaring the
inputs in propagated-inputs.  But I think I'd feel more sure of myself if we
had a short "Packaging shell scripts" section in the manual that outlined
best-practices-of-the-moment.  Would that be useful?

Eric Bavier (1):
  gnu: torsocks: Patch references to 'getcap' and 'which'.

 gnu/packages/tor.scm | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

-- 
2.12.2

bug#26392: [PATCH 1/1] gnu: torsocks: Patch references to 'getcap' and 'which'.

[Eric Bavier]

* gnu/packages/tor.scm (torsocks)[inputs,arguments]: New fields.
---
 gnu/packages/tor.scm | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/gnu/packages/tor.scm b/gnu/packages/tor.scm
index e48017e64..06b6c4feb 100644
--- a/gnu/packages/tor.scm
+++ b/gnu/packages/tor.scm
@@ -4,6 +4,7 @@
 ;;; Copyright © 2016 Efraim Flashner <efraim@flashner.co.il>
 ;;; Copyright © 2016, 2017 ng0 <contact.ng0@cryptolab.net>
 ;;; Copyright © 2017 Tobias Geerinckx-Rice <me@tobias.gr>
+;;; Copyright © 2017 Eric Bavier <bavier@member.fsf.org>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -28,7 +29,9 @@
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system python)
   #:use-module (gnu packages)
+  #:use-module (gnu packages base)
   #:use-module (gnu packages libevent)
+  #:use-module (gnu packages linux)
   #:use-module (gnu packages compression)
   #:use-module (gnu packages pcre)
   #:use-module (gnu packages python)
@@ -88,6 +91,19 @@ the application layer) you need to install @code{torsocks}.")
                (base32
                 "0byr9ga9w79qz4vp0m11sbmspad7fsal9wm67r4znzb7zb7cis19"))))
     (build-system gnu-build-system)
+    (inputs
+     `(("which" ,which)
+       ("libcap" ,libcap)))
+    (arguments
+     `(#:phases (modify-phases %standard-phases
+                  (add-after 'build 'absolutize
+                    (lambda* (#:key inputs #:allow-other-keys)
+                      (substitute* "src/bin/torsocks"
+                        (("getcap=`.*`")
+                         (string-append "getcap=" (which "getcap")))
+                        (("`which")
+                         (string-append "`" (which "which"))))
+                      #t)))))
     (home-page "https://www.torproject.org/")
     (synopsis "Use socks-friendly applications with Tor")
     (description
--
2.12.2

bug#26391: [PATCH 0/1] Patching getcap and which in torsocks

[ng0]

Eric Bavier transcribed 0.8K bytes:
> This patches references to the 'getcap' and 'which' programs in 'torsocks'
> so that users that don't have either of those packages installed in their
> profiles do not see confusing output about them missing.  Usually torsocks
> will still function in that case, but it's probably better to have them
> available.
> 
> I've so far done this sort of thing for several packages with shell scripts,
> and each time I'm convinced that this method is better than declaring the
> inputs in propagated-inputs.  But I think I'd feel more sure of myself if we
> had a short "Packaging shell scripts" section in the manual that outlined
> best-practices-of-the-moment.  Would that be useful?
> 
> Eric Bavier (1):
>   gnu: torsocks: Patch references to 'getcap' and 'which'.
> 
>  gnu/packages/tor.scm | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> -- 
> 2.12.2
> 
> 

I have not run the patch, but the code looks good to me.
The "dependencies" are not obvious, so your proposed change is okay.

bug#26391: [PATCH 0/1] Patching getcap and which in torsocks

[Ludovic Courtès]

Hi Eric,

Eric Bavier <bavier@member.fsf.org> skribis:

> This patches references to the 'getcap' and 'which' programs in 'torsocks'
> so that users that don't have either of those packages installed in their
> profiles do not see confusing output about them missing.  Usually torsocks
> will still function in that case, but it's probably better to have them
> available.
>
> I've so far done this sort of thing for several packages with shell scripts,
> and each time I'm convinced that this method is better than declaring the
> inputs in propagated-inputs.  But I think I'd feel more sure of myself if we
> had a short "Packaging shell scripts" section in the manual that outlined
> best-practices-of-the-moment.  Would that be useful?

Yes, sure.

> * gnu/packages/tor.scm (torsocks)[inputs,arguments]: New fields.

LGTM, thanks!

Ludo’.

bug#26391: [PATCH 0/1] Patching getcap and which in torsocks

[Eric Bavier]

ludo@gnu.org (Ludovic Courtès) writes:

> Hi Eric,
>
> Eric Bavier <bavier@member.fsf.org> skribis:
>
>> This patches references to the 'getcap' and 'which' programs in 'torsocks'
>> so that users that don't have either of those packages installed in their
>> profiles do not see confusing output about them missing.  Usually torsocks
>> will still function in that case, but it's probably better to have them
>> available.
>
>> * gnu/packages/tor.scm (torsocks)[inputs,arguments]: New fields.
>
> LGTM, thanks!

Pushed in f3cf25c3c2aef91a47b790fe69b5008cdb6a6316

bug#26392: [PATCH 1/1] gnu: torsocks: Patch references to 'getcap' and 'which'.

[Ludovic Courtès]

Eric Bavier <bavier@member.fsf.org> skribis:

> * gnu/packages/tor.scm (torsocks)[inputs,arguments]: New fields.

LGTM, thanks!

Ludo'.

bug#26392: [PATCH 1/1] gnu: torsocks: Patch references to 'getcap' and 'which'.

[Eric Bavier]

On Mon, 10 Apr 2017 11:48:11 +0200
ludo@gnu.org (Ludovic Courtès) wrote:

> Eric Bavier <bavier@member.fsf.org> skribis:
> 
> > * gnu/packages/tor.scm (torsocks)[inputs,arguments]: New fields.  
> 
> LGTM, thanks!
> 
> Ludo'.

Didn't realize the cover-letter was sent to a separate bug.  Closing
this one too.

Pushed in f3cf25c3c2aef91a47b790fe69b5008cdb6a6316

`~Eric