guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#54974] [PATCH] added btop


From: Wil deBeest
Subject: [bug#54974] [PATCH] added btop
Date: Sat, 28 May 2022 13:21:49 +0200

Maxime Devos <maximedevos@telenet.be> writes:

> [[PGP Signed Part:Undecided]]
> Wil deBeest schreef op vr 29-04-2022 om 01:17 [+0200]:
>> Hi Maxime,
>>> Long term, %outputs, %build-inputs, ... are being phased out, so I'd go
>>> with, so I'd go with
>>>    (arguments (list #:make-flags #~(string-append "PREFIX=" #$output)))
>>> here instead.
>> I haven't been able to integrate your snippet into the package.   Could you
>> show me how to do so or tell me which part of the handbook would be
>> relevant?
> 
> For a good example, see the 'stress-ng' package definition 'guix edit
> stress-ng'.  #:make-flags is documented in the manual (search for
> #:make-flags or go to (guix)Build Systems).  #$output is documented in
> ‘(guix)G-Expressions’.
> 
> Very concretely:
> 
>  (package
>    [...]
>    (arguments (list #:tests? #false ; some comment
>                     #:make-flags #~(...)
>                     #:phases
>                     ;; [Stuff for replacing the install phase and
>                     ;; removing the configure phase]
>                     #~(modify-phases %standard-phases ...))))
> 
> Greetings,
> Maxime.
> 
> [[End of PGP Signed Part]]


Thank you, I think I got it.

I've also added gcc-12 as a native input for efficiency reasons [1].

Since I'm not familiar with the process of deprecation, I've kept the thoughts 
I had written down regarding your question on whether bashtop & bpytop could be 
removed, even though there's probably nothing in there that hasn't at least 
been discussed before [2]


Cheers!




---
gnu/packages/admin.scm | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)

diff --git a/gnu/packages/admin.scm b/gnu/packages/admin.scm
index af75dee697..fccc0e8dd3 100644
--- a/gnu/packages/admin.scm
+++ b/gnu/packages/admin.scm
@@ -101,6 +101,7 @@ (define-module (gnu packages admin)
  #:use-module (gnu packages file)
  #:use-module (gnu packages flex)
  #:use-module (gnu packages gawk)
+  #:use-module (gnu packages gcc)
  #:use-module (gnu packages gettext)
  #:use-module (gnu packages gl)
  #:use-module (gnu packages glib)
@@ -752,6 +753,37 @@ (define-public bpytop
@command{bashtop}.")
    (license license:asl2.0)))

+(define-public btop
+  (package
+    (name "btop")
+    (version "1.2.6")
+    (source
+     (origin
+       (method git-fetch)
+       (uri (git-reference
+             (url "https://github.com/aristocratos/btop";)
+             (commit (string-append "v" version))))
+       (file-name (git-file-name name version))
+       (sha256
+        (base32
+         "03nd34q1w01visd2bg7mxrcjn0s6lnbm4s0vsfsj2mfv1rvyjl5b"))))
+    (native-inputs (list gcc-12))
+    (build-system gnu-build-system)
+    (arguments
+     (list #:make-flags
+       #~(list (string-append "PREFIX=" #$output))
+       #:phases
+       #~(modify-phases %standard-phases
+         (delete 'configure))
+        #:tests? #f))
+    (home-page "https://github.com/aristocratos/btop";)
+    (synopsis "Resource monitor")
+    (description "Resource monitor that shows usage and stats
+for processor, memory, disks, network and processes.
+
+C++ version and continuation of bashtop and bpytop.")
+    (license license:asl2.0)))
+
(define-public pies
  (package
    (name "pies")

base-commit: 6e9d99f97f15347f44df0518faa5e3b8b9d5184e
-- 
2.36.1









[1] "Needs GCC 10 or higher, (GCC 11 or above strongly recommended for
better CPU efficiency in the compiled binary)", sayeth the readme

[2] Is there a mechanism to flag these packages so a deprecation warning
would be shown when they are searched for?  (A first look seems to
suggest `gexp->derivation' could be used for that, but I'll have read
that more thoroughly)

If there is I think it would make sense to add a deprecation warning
including that reasons why they shouldn't be replaced can be directed to
e.g. 54974@debbugs.gnu.org and wait for feedback for some set amount of
time before either redefining the package names as aliases for btop or
removing them.  In both cases I think a message would make sense for
those who have installed them.  For others, adding something like
"replaces its predecessors bashtop and bpytop" to the description seems
to be enough.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]