Re: couple of crashes while guix package -u for (libreoffice, kodi, rust, blender)

[Tobias Geerinckx-Rice]

ng0,

Nils Gillmann wrote:
[...]
Furthermore it seems like the tor service got somehow broken? I 
get errors of it not being able to write
to its service directory and then crashing. Anyone else 
experiencing that?


Nope. I reconfigured & rebooted my main Tor relay just earlier 
today, and it's relaying just fine...


Kind regards,

T G-R

Re: couple of crashes while guix package -u for (libreoffice, kodi, rust, blender)

[Nils Gillmann]

Ricardo Wurmus transcribed 1.3K bytes:
> 
> Hi Nils,
> 
> > * rust is failing a (tiny?) part of its testsuite:
> > […]
> > note: Run with `RUST_BACKTRACE=1` for a backtrace.
> 
> Have you tried that to see the backtrace?
> 
> > * blender, because of imageio:
> 
> Here you seem to have elided the actual error message of openimageio.
> 
> > * kodi (once again, as usual), because of mysql:
> 
> Can kodi use mariadb instead?  (That’s no fix, of course, because mysql
> should not fail to build.)  Unfortunately, we don’t see the error
> message in what you included here.

Probably, as masriadb and mysql are mostly compatible. Only edge-cases do
not work I think.

> > * libreoffice, because of liborcus:
> >
> > checking for MDDS... yes
> > checking for LIBIXION... no
> > configure: error: Package requirements (libixion-0.13 >= 0.12.0) were not 
> > met:
> >
> > No package 'libixion-0.13' found
> […]
> > cannot build derivation 
> > `/gnu/store/4dlhqln57hbb31a519404a7v563yd35c-libreoffice-5.4.6.2.drv': 1 
> > dependencies couldn't be built
> > guix package: error: build failed: build of 
> > `/gnu/store/4dlhqln57hbb31a519404a7v563yd35c-libreoffice-5.4.6.2.drv' failed
> 
> I don’t think this is right.  I’ve upgraded libreoffice a few days ago
> to version 6.0.x and this included an upgrade of libixion.
> 
> Are you sure you’re using the latest version of Guix?  If so, do you
> have GUIX_PACKAGE_PATH set?

Yes, the GPP is set, but my pick for this update of it does not
include any conflicting package definitions.

I will double check in the next days.

My guix version comes from the normal guix pull,
version b19950a184a9b7506f9be4ecaa043e5a7e460b52

> 
> --
> Ricardo
> 

Re: couple of crashes while guix package -u for (libreoffice, kodi, rust, blender)

[Ricardo Wurmus]

Hi Nils,

> * rust is failing a (tiny?) part of its testsuite:
> […]
> note: Run with `RUST_BACKTRACE=1` for a backtrace.

Have you tried that to see the backtrace?

> * blender, because of imageio:

Here you seem to have elided the actual error message of openimageio.

> * kodi (once again, as usual), because of mysql:

Can kodi use mariadb instead?  (That’s no fix, of course, because mysql
should not fail to build.)  Unfortunately, we don’t see the error
message in what you included here.

> * libreoffice, because of liborcus:
>
> checking for MDDS... yes
> checking for LIBIXION... no
> configure: error: Package requirements (libixion-0.13 >= 0.12.0) were not met:
>
> No package 'libixion-0.13' found
[…]
> cannot build derivation 
> `/gnu/store/4dlhqln57hbb31a519404a7v563yd35c-libreoffice-5.4.6.2.drv': 1 
> dependencies couldn't be built
> guix package: error: build failed: build of 
> `/gnu/store/4dlhqln57hbb31a519404a7v563yd35c-libreoffice-5.4.6.2.drv' failed

I don’t think this is right.  I’ve upgraded libreoffice a few days ago
to version 6.0.x and this included an upgrade of libixion.

Are you sure you’re using the latest version of Guix?  If so, do you
have GUIX_PACKAGE_PATH set?

--
Ricardo

couple of crashes while guix package -u for (libreoffice, kodi, rust, blender)

[Nils Gillmann]

since HEAD of today (and also 2 days, since I started updating):

* rust is failing a (tiny?) part of its testsuite:

failures:

 [run-pass] run-pass/out-of-stack.rs stdout 

error: test run failed!
status: exit code: 101
command: 
"/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack.stage2-x86_64-unknown-linux-gnu"
stdout:
--
testing: silent-thread

--
stderr:
--
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `Some(11)`,
 right: `Some(6)`', 
/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/src/test/run-pass/out-of-stack.rs:50:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

--

thread '[run-pass] run-pass/out-of-stack.rs' panicked at 'explicit panic', 
src/tools/compiletest/src/runtest.rs:2531:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.


failures:
[run-pass] run-pass/out-of-stack.rs

test result: FAILED. 2827 passed; 1 failed; 14 ignored; 0 measured; 0 filtered 
out

thread 'main' panicked at 'Some tests failed', 
src/tools/compiletest/src/main.rs:331:21


command did not execute successfully: 
"/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest"
 "--compile-lib-path" 
"/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/stage2/lib"
 "--run-lib-path" 
"/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib"
 "--rustc-path" 
"/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc"
 "--src-base" 
"/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/src/test/run-pass" 
"--build-base" 
"/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/test/run-pass"
 "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-pass" "--target" 
"x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" 
"--llvm-filecheck" 
"/gnu/store/fbvin47yrijwsyhbm5rb0pmzahqn3k44-llvm-3.9.1/bin/FileCheck" 
"--host-rustcflags" "-Crpath -O" "--target-rustcflags" "-Crpath -O 
-Lnative=/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
 "--docck-python" 
"/gnu/store/axfhalb1syyhayn6j873z4l8s5d68i3v-python2-2.7.14/bin/python2" 
"--lldb-python" 
"/gnu/store/axfhalb1syyhayn6j873z4l8s5d68i3v-python2-2.7.14/bin/python2" 
"--gdb" "/gnu/store/9k6g3inhgfjnm65rk3m002jg87s03r5q-gdb-8.1/bin/gdb" 
"--llvm-version" "3.9.1\n" "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" 
"--llvm-components" "" "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" 
"/data/tmp/work" "--android-cross-path" ""
expected success, got: exit code: 101


failed to run: 
/tmp/guix-build-rust-1.23.0.drv-0/rustc-1.23.0-src/build/bootstrap/debug/bootstrap
 -j1 test
Build completed unsuccessfully in 0:29:01
Backtrace:
   5 (primitive-load "/gnu/store/sz91irj9qx1bmv9l6qg4zga6ix3?")
In ice-9/eval.scm:
   191:35  4 (_ _)
In srfi/srfi-1.scm:
640:9  3 (for-each # ?)
In 
/gnu/store/44nwmjdb1zwkmvk96rf6i18rc16kqxxk-module-import/guix/build/gnu-build-system.scm:
   799:31  2 (_ _)
In ice-9/eval.scm:
619:8  1 (_ #(#(#) (#:source # ?)))
In 
/gnu/store/44nwmjdb1zwkmvk96rf6i18rc16kqxxk-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/44nwmjdb1zwkmvk96rf6i18rc16kqxxk-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
builder for `/gnu/store/pn5a9q6z91f183pg41vbpw6b9bw38wkv-rust-1.23.0.drv' 
failed with exit code 1
derivation '/gnu/store/pn5a9q6z91f183pg41vbpw6b9bw38wkv-rust-1.23.0.drv' 
offloaded to 'cult.of.n0.is' failed: build of 
`/gnu/store/pn5a9q6z91f183pg41vbpw6b9bw38wkv-rust-1.23.0.drv' failed
cannot build derivation 
`/gnu/store/5xm9c91349i99svh73yfc2nhijxwzr63-rust-1.24.1.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/mpqyjddivj9zv1li45vqqr4f6b8fdm01-rust-1.25.0.drv': 1 dependencies 
couldn't be built
guix package: error: build failed: build of 
`/gnu/store/mpqyjddivj9zv1li45vqqr4f6b8fdm01-rust-1.25.0.drv' failed






* blender, because of imageio:


[ 94%] Building CXX object src/oiiotool/CMakeFiles/oiiotool.dir/diff.cpp.o
cd /tmp/guix-build-openimageio-1.6.15.drv-0/build/src/oiiotool && 
/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/c++  -DNDEBUG 
-DUSE_OPENEXR_VERSION2=1 -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS 
-I/gnu/store/6sr9czac53dbhiy8p2qr82zxf88c1648-openexr-2.2.1/include 
-I/gnu/store/rpbmvxkyx4nnxscv81pxa9d2h7bnzaz6-ilmbase-2.2.1/include 
-I/gnu/store/rpbmvxkyx4nnxscv81pxa9d2h7bnzaz6-ilmbase-2.2.1/include/OpenEXR 
-isystem /gnu/store/l6hqfwr1hcbn9rg56bwn2d41g2ai36h2-boost-1.66.0/include 
-I/tmp/guix-build-openimageio-1.6.15.drv-0/oiio-Release-1.6.15/src/include 

Re: 04/05: gnu: swig: Patch for Octave 4.4.

[Kei Kebreau]

Kei Kebreau  writes:

> Kei Kebreau  writes:
>
>> Other than Shogun's Python/SWIG-related build failure (attached), this
>> patch seems to work fairly well. There appears to be an upstream issue
>> related to the invalid conversion mentioned in the build failure. I'm
>> keeping an eye on it for any new developments.
>
> FYI, this is an updated patch that bypasses the Python interface issue
> and runs into an issue with R.

I haven't been able to crack the issue with Shogun and R.  The attached
patch explicitly disables the R interface which allows shogun to build
properly while the R problem is resolved.

From a364bc3122ac9d3903a0d84a579d477334a59ac8 Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Wed, 30 May 2018 08:34:42 -0400
Subject: [PATCH] gnu: shogun: Use a patched swig for Octave 4.4.

* gnu/packages/swig.scm (swig-git): New variable
* gnu/packages/machine-learning.scm (shogun)[arguments]: Add
'fix-python-compiler-flags' phase.  Disable R interface.
[inputs]: Replace swig with swig-git.  Remove r-minimal.
---
 gnu/packages/machine-learning.scm | 13 +---
 gnu/packages/swig.scm | 34 +++
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/machine-learning.scm 
b/gnu/packages/machine-learning.scm
index 15e4d4574..65dd9d31b 100644
--- a/gnu/packages/machine-learning.scm
+++ b/gnu/packages/machine-learning.scm
@@ -469,6 +469,13 @@ sample proximities between pairs of cases.")
(mkdir-p rxcpp-dir)
(install-file (assoc-ref inputs "rxcpp") rxcpp-dir)
#t)))
+ (add-after 'unpack 'fix-python-compiler-flags
+   (lambda _
+ ;; This prevents a set of function conversions from stopping the
+ ;; build with an error.
+ (substitute* "src/interfaces/python/CMakeLists.txt"
+   (("Wno-c\\+\\+11-narrowing") "fpermissive"))
+ #t))
  (add-before 'build 'set-HOME
;; $HOME needs to be set at some point during the build phase
(lambda _ (setenv "HOME" "/tmp") #t)))
@@ -482,13 +489,13 @@ sample proximities between pairs of cases.")
  ;;"-DINTERFACE_LUA=ON"  ;fails because lua doesn't build 
pkgconfig file
  "-DINTERFACE_OCTAVE=ON"
  "-DINTERFACE_PYTHON=ON"
- "-DINTERFACE_R=ON")))
+ "-DINTERFACE_R=OFF")))  ;temporarily off due to unknown issues.
 (inputs
  `(("python" ,python)
("numpy" ,python-numpy)
-   ("r-minimal" ,r-minimal)
+   ;;("r-minimal" ,r-minimal) ;re-enable when interface issues are resolved
("octave" ,octave)
-   ("swig" ,swig)
+   ("swig" ,swig-git)
("eigen" ,eigen)
("hdf5" ,hdf5)
("atlas" ,atlas)
diff --git a/gnu/packages/swig.scm b/gnu/packages/swig.scm
index b931db412..3a1139dbb 100644
--- a/gnu/packages/swig.scm
+++ b/gnu/packages/swig.scm
@@ -20,8 +20,12 @@
 (define-module (gnu packages swig)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix licenses)
+  #:use-module (guix utils)
   #:use-module (guix build-system gnu)
+  #:use-module (gnu packages autotools)
+  #:use-module (gnu packages bison)
   #:use-module (gnu packages pcre)
   #:use-module (gnu packages guile)
   #:use-module (gnu packages boost)
@@ -74,3 +78,33 @@ you tailor the wrapping process to suit your application.")
 
 ;; See http://www.swig.org/Release/LICENSE for details.
 (license gpl3+)))
+
+;; This package contains upstream fixes that haven't been released as part of a
+;; stable version of SWIG.  This is necessary for software that uses SWIG to
+;; compile the correct and up-to-date programming language interfaces.
+(define-public swig-git
+  (let ((commit "12c66f9b7d884020e896ce92b9783bc3bac95d2d")
+(revision "1"))
+(package/inherit swig
+  (name "swig-git")
+  (version (git-version "4.0.0" revision commit))
+  (source
+   (origin
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://github.com/swig/swig.git;)
+   (commit commit)))
+ (sha256 (base32 
"1367y47kdkly9cwyp4d60cm5d660am83g4p52k1hmzvimghwgvlp"))
+ (file-name (git-file-name name version
+  (arguments
+   (substitute-keyword-arguments (package-arguments swig)
+ ((#:phases phases)
+  `(modify-phases ,phases
+ (add-after 'unpack 'autogen
+   (lambda _
+ (invoke "sh" "autogen.sh")))
+  (native-inputs
+   `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("bison" ,bison)
+ ,@(package-native-inputs swig))
-- 
2.17.1



signature.asc
Description: PGP signature

Re: Fwd: Re: Patch file for colorize module

[Sahitihi]

Hi Ricardo,

Text file is attached with all changes I added including colorize module.

The changes added to build.scm is (/(parameterize
((current-build-output-port  colorful-build-output-port)) /)

> Please send me the complete changes as a text file, so that I can apply
> it to my copy of the Guix repository.
>
---
Thanks!!
Sahithi.
(define color-table
  `((CLEAR   .   "0")
(RESET   .   "0")
(BOLD.   "1")
(DARK.   "2")
(UNDERLINE   .   "4")
(UNDERSCORE  .   "4")
(BLINK   .   "5")
(REVERSE .   "6")
(CONCEALED   .   "8")
(BLACK   .  "30")
(RED .  "31")
(GREEN   .  "32")
(YELLOW  .  "33")
(BLUE.  "34")
(MAGENTA .  "35")
(CYAN.  "36")
(WHITE   .  "37")
(ON-BLACK.  "40")
(ON-RED  .  "41")
(ON-GREEN.  "42")
(ON-YELLOW   .  "43")
(ON-BLUE .  "44")
(ON-MAGENTA  .  "45")
(ON-CYAN .  "46")
(ON-WHITE.  "47")))

(define (color . lst)
  "Return a string containing the ANSI escape sequence for producing the
requested set of attributes in LST.  Unknown attributes are ignored."
  (let ((color-list
 (remove not
 (map (lambda (color) (assq-ref color-table color))
  lst
(if (null? color-list)
""
(string-append
 (string #\esc #\[)
 (string-join color-list ";" 'infix)
 "m"

(define (colorize-string str . color-list)
  "Return a copy of STR colorized using ANSI escape sequences according to the
attributes STR.  At the end of the returned string, the color attributes will
be reset such that subsequent output will not have any colors in effect."
  (string-append
   (apply color color-list)
   str
   (color 'RESET)))

 
(define (handle-string str)
(let ((message  (or (and=> (string-match "^(starting phase)(.*)" str)
   (lambda (m)
 (string-append
   (colorize-string (match:substring m 1) 'BLUE)
   (colorize-string (match:substring m 2) 'GREEN

   (and=> (string-match "^(phase) (.*) (succeeded after) (.*) (seconds)" 
str)
  (lambda (m)
(string-append
  (colorize-string (match:substring m 1) 'BLUE)
  (colorize-string (match:substring m 2) 'GREEN)
  (colorize-string (match:substring m 3) 'BLUE)
  (colorize-string (match:substring m 4) 'GREEN)
  (colorize-string (match:substring m 5) 'BLUE

   (and=> (string-match "^(phase)(.*) (failed after) (.*) (seconds)" str)
  (lambda (m)
(string-append
  (colorize-string (match:substring m 1) 'RED)
  (colorize-string (match:substring m 2) 'GREEN)
  (colorize-string (match:substring m 3) 'RED)
  (colorize-string (match:substring m 4) 'GREEN)
  (colorize-string (match:substring m 5) 'RED

;; Didn’t match, so return unmodified string.
   str)))
(display message (current-error-port

(define colorful-build-output-port
  (make-soft-port
   (vector
(lambda (c) (write c (current-error-port)))
handle-string
(lambda () (display "." (current-error-port)))
(lambda () (char-upcase (read-char)))
(lambda () (display "@" (current-error-port
   "rw"))

;;; ui.scm ends here

Re: Fwd: Re: Patch file for colorize module

[Sahitihi]

Hi Gábor,

Updated patch is attached.

> Could you send an updated patch?

---
Thanks!!
Sahithi.
>From 765035232a43f09a5c3dbecf77c90499dd1473d4 Mon Sep 17 00:00:00 2001
From: Sahithi Yarlagadda 
Date: Tue, 5 Jun 2018 00:08:32 +0530
Subject: [PATCH] guix: Add coloring soft port.

* guix/ui.scm (handle-string): New procedures.
(colorful-build-output-port): New variable.

guix: Added colorful-build-output-port to build.scm instead of default
---
 guix/scripts/build.scm |  5 +
 guix/ui.scm| 42 +-
 2 files changed, 42 insertions(+), 5 deletions(-)
 mode change 100644 => 100755 guix/scripts/build.scm
 mode change 100644 => 100755 guix/ui.scm

diff --git a/guix/scripts/build.scm b/guix/scripts/build.scm
old mode 100644
new mode 100755
index 4dd4fbccd..be457443b
--- a/guix/scripts/build.scm
+++ b/guix/scripts/build.scm
@@ -732,10 +732,7 @@ needed."
   (with-store store
 ;; Set the build options before we do anything else.
 (set-build-options-from-command-line store opts)
-
-(parameterize ((current-build-output-port (if quiet?
-  (%make-void-port "w")
-  (current-error-port
+(parameterize ((current-build-output-port  colorful-build-output-port))
   (let* ((mode  (assoc-ref opts 'build-mode))
  (drv   (options->derivations store opts))
  (urls  (map (cut string-append <> "/log")
diff --git a/guix/ui.scm b/guix/ui.scm
old mode 100644
new mode 100755
index 80f1a4d77..83302ce30
--- a/guix/ui.scm
+++ b/guix/ui.scm
@@ -109,7 +109,7 @@
 warning
 info
 guix-main
-colorize-string))
+colorful-build-output-port))
 
 ;;; Commentary:
 ;;;
@@ -1631,4 +1631,44 @@ be reset such that subsequent output will not have any colors in effect."
str
(color 'RESET)))
 
+ 
+(define (handle-string str)
+(let ((message  (or (and=> (string-match "^(starting phase)(.*)" str)
+   (lambda (m)
+ (string-append
+   (colorize-string (match:substring m 1) 'BLUE)
+   (colorize-string (match:substring m 2) 'GREEN
+
+   (and=> (string-match "^(phase) (.*) (succeeded after) (.*) (seconds)" str)
+  (lambda (m)
+(string-append
+  (colorize-string (match:substring m 1) 'BLUE)
+  (colorize-string (match:substring m 2) 'GREEN)
+  (colorize-string (match:substring m 3) 'BLUE)
+  (colorize-string (match:substring m 4) 'GREEN)
+  (colorize-string (match:substring m 5) 'BLUE
+
+   (and=> (string-match "^(phase)(.*) (failed after) (.*) (seconds)" str)
+  (lambda (m)
+(string-append
+  (colorize-string (match:substring m 1) 'RED)
+  (colorize-string (match:substring m 2) 'GREEN)
+  (colorize-string (match:substring m 3) 'RED)
+  (colorize-string (match:substring m 4) 'GREEN)
+  (colorize-string (match:substring m 5) 'RED
+
+;; Didn’t match, so return unmodified string.
+   str)))
+(display message (current-error-port
+
+(define colorful-build-output-port
+  (make-soft-port
+   (vector
+(lambda (c) (write c (current-error-port)))
+handle-string
+(lambda () (display "." (current-error-port)))
+(lambda () (char-upcase (read-char)))
+(lambda () (display "@" (current-error-port
+   "rw"))
+
 ;;; ui.scm ends here
-- 
2.11.0

Re: GSoC - "Continuing re-write of daemon in Guile Scheme" update

[Joshua Branson]

Don't give up!  I'm sorry that life has thrown you a curse ball, and I
respect your need to help your family.  You have still got a lot of
potential.  And with a little bit of effort, you certainly can
contribute to Guix in a meaningful way!

Re: Fwd: Re: Patch file for colorize module

[Ricardo Wurmus]

Hi Sahithi,

>> You should see the same as I did.
> This worked for me too.

That’s good.

>> To see what’s going on with your modifications to “(guix ui)” it would
>> help if you could go through your changes once more (use “git diff” to
>> be sure to inspect all the lines you have changed) and send your changes
>> to this list.
>>
> Image is attached. Though I made these changes to ui.scm still I
> couldn't see the reflections in output.

Please send me the complete changes as a text file, so that I can apply
it to my copy of the Guix repository.

-- 
Ricardo

Re: Fwd: Re: Patch file for colorize module

[Gábor Boskovits]

2018-06-11 14:14 GMT+02:00 Sahitihi :

> Hi Ricardo,
>
> > You should see the same as I did.
> This worked for me too.
> > To see what’s going on with your modifications to “(guix ui)” it would
> > help if you could go through your changes once more (use “git diff” to
> > be sure to inspect all the lines you have changed) and send your changes
> > to this list.
> >
> Image is attached. Though I made these changes to ui.scm still I
> couldn't see the reflections in output.
>
> ---
> Thanks!!
> Sahithi.
>

Could you send an updated patch?
Thanks,
g_bor

Re: Fwd: Re: Patch file for colorize module

[Sahitihi]

Hi Ricardo,

> You should see the same as I did.
This worked for me too.
> To see what’s going on with your modifications to “(guix ui)” it would
> help if you could go through your changes once more (use “git diff” to
> be sure to inspect all the lines you have changed) and send your changes
> to this list.
>
Image is attached. Though I made these changes to ui.scm still I
couldn't see the reflections in output.

---
Thanks!!
Sahithi.

Re: GSoC 2018 Syntax and semantics of systemd units in the Shepherd - 1st update

[Ioannis Panagiotis Koutsidis]

Thank you a lot for your comments! I will make sure to make the changes that you
suggested.

As for match and things like car/cdr, I had issues with match and signal 
handling
in the service file, which was why I changed it with a cond. As for the unit 
parser
I also take the rest of the list via cdar because match in something like
(x y rest ...) does not bind rest - I will probably have to use (x . (y . 
rest)) in
the replacement.

On 06/11/18 14:47, Ludovic Courtès wrote:

Hello Ioannis!

Thanks for the update!

Ioannis Panagiotis Koutsidis  skribis:


As the 1st phase is coming to an end I decided to post my progress. I have
implemented the unit file parsing as well as some of the basic entries supported
by it, such as ExecStart, User, Group, Restart, etc. In addition, support for
the systemd Restart values (on-success, on-failure, on-abnormal, and on-abort)
was added to the Shepherd via the restart-systemd field in the  class,
letting services written in guile to also use that feature.


Very nice!


During the next phases I will focus on other common .service entries, .socket
support, as well as thoroughly testing the code.


Cool.  Adding unit tests like those currently under tests/ is definitely
something you should do—you probably already run tests manually anyway,
so it’s mostly a matter of putting them in a file.

For things like the unit file parser, you may find it more convenient to
write the test in Scheme (currently all the tests are shell scripts.)
That can easily be done by using the .scm file name extension for your
test and then defining ‘SCM_LOG_COMPILER’ in Makefile.am.  If unsure,
you can look at how Guix itself does it, or just stop by on #guix or ask
on the list for details.

Some comments about the code:


 From a0a46ead5e43cd2672a08adb4c16919c377514c2 Mon Sep 17 00:00:00 2001
From: Ioannis Panagiotis Koutsidis 
Date: Sat, 9 Jun 2018 16:17:27 +0300
Subject: [PATCH] Initial systemd unit support


Could you try to split it in several patches, where each patch
represents a single “logical” change?

By that I mean that you could have a first patch that modifies ‘restart’
and all in (shepherd service), possibly with extended tests to exercise
the new functionality if appropriate.

A second patch would add the unit file parser in (shepherd systemd)
along with its unit test.

For commit logs, please try to follow the ChangeLog convention:
.  You
can look at ‘git log’ and basically try to mimic what’s been done
before.  Don’t lose your hair over commit logs though; it’s good to try
to follow the conventions, but if you’re unsure or if you make mistakes,
it’s not the end of the world.


@@ -165,6 +166,11 @@ respawned, shows that it has been respawned more than TIMES in 
SECONDS."
(respawn? #:init-keyword #:respawn?
#:init-value #f
#:getter respawn?)
+  ;; For the systemd restart values.  Can be 'no (when respawn? is #f),
+  ;; 'on-success, 'on-failure, 'on-abnormal, 'on-watchdog, 'on-abort, or 
'always
+  (respawn-systemd #:init-keyword #:respawn-systemd
+   #:init-value 'always
+   #:getter respawn-systemd)


As briefly discussed on IRC, I think we should keep a single field for
this.  So perhaps ‘respawn?’ must simply be renamed to ‘respawn’ (no
question mark), with a comment like above explaining what the possible
values are.


+  (let* ([e (status:exit-val status)]
+ [t (status:term-sig status)]
+ [r (respawn-systemd serv)]


Please avoid square brackets to remain consistent with the rest of the
code.  :-)


+ [clean (or (zero?  e)
+(equal? t SIGHUP)
+(equal? t SIGINT)
+(equal? t SIGTERM)
+(equal? t SIGPIPE))])


Use ‘=’ rather than ‘equal?’ when we know we’re dealing with numbers.


+(if (or (equal? r 'always)
+(equal? r 'on-watchdog) ;; not implemented yet
+(and (equal? r 'on-success) clean)
+(and (equal? r 'on-abnormal) (not clean) (equal? e #f))
+(and (equal? r 'on-failure)  (not clean))
+(and (equal? r 'on-abort)(equal? t SIGABRT)))


Likewise, use ‘eq?’ for symbols.


+++ b/modules/shepherd/systemd.scm
@@ -0,0 +1,143 @@
+;; systemd.scm -- Systemd support
+;; Copyright (C) 2018 Ioannis Panagiotis Koutsidis 
+;;
+;; This file is part of the GNU Shepherd.
+;;
+;; The GNU Shepherd is free software; you can redistribute it and/or modify it
+;; under the terms of the GNU General Public License as published by
+;; the Free Software Foundation; either version 3 of the License, or (at
+;; your option) any later version.
+;;
+;; The GNU Shepherd is distributed in the hope that it will be useful, but
+;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;; GNU General 

Re: GSoC 2018 Syntax and semantics of systemd units in the Shepherd - 1st update

[Ludovic Courtès]

Hello Ioannis!

Thanks for the update!

Ioannis Panagiotis Koutsidis  skribis:

> As the 1st phase is coming to an end I decided to post my progress. I have
> implemented the unit file parsing as well as some of the basic entries 
> supported
> by it, such as ExecStart, User, Group, Restart, etc. In addition, support for
> the systemd Restart values (on-success, on-failure, on-abnormal, and on-abort)
> was added to the Shepherd via the restart-systemd field in the  
> class,
> letting services written in guile to also use that feature.

Very nice!  

> During the next phases I will focus on other common .service entries, .socket
> support, as well as thoroughly testing the code.

Cool.  Adding unit tests like those currently under tests/ is definitely
something you should do—you probably already run tests manually anyway,
so it’s mostly a matter of putting them in a file.

For things like the unit file parser, you may find it more convenient to
write the test in Scheme (currently all the tests are shell scripts.)
That can easily be done by using the .scm file name extension for your
test and then defining ‘SCM_LOG_COMPILER’ in Makefile.am.  If unsure,
you can look at how Guix itself does it, or just stop by on #guix or ask
on the list for details.

Some comments about the code:

> From a0a46ead5e43cd2672a08adb4c16919c377514c2 Mon Sep 17 00:00:00 2001
> From: Ioannis Panagiotis Koutsidis 
> Date: Sat, 9 Jun 2018 16:17:27 +0300
> Subject: [PATCH] Initial systemd unit support

Could you try to split it in several patches, where each patch
represents a single “logical” change?

By that I mean that you could have a first patch that modifies ‘restart’
and all in (shepherd service), possibly with extended tests to exercise
the new functionality if appropriate.

A second patch would add the unit file parser in (shepherd systemd)
along with its unit test.

For commit logs, please try to follow the ChangeLog convention:
.  You
can look at ‘git log’ and basically try to mimic what’s been done
before.  Don’t lose your hair over commit logs though; it’s good to try
to follow the conventions, but if you’re unsure or if you make mistakes,
it’s not the end of the world.

> @@ -165,6 +166,11 @@ respawned, shows that it has been respawned more than 
> TIMES in SECONDS."
>(respawn? #:init-keyword #:respawn?
>   #:init-value #f
>   #:getter respawn?)
> +  ;; For the systemd restart values.  Can be 'no (when respawn? is #f),
> +  ;; 'on-success, 'on-failure, 'on-abnormal, 'on-watchdog, 'on-abort, or 
> 'always
> +  (respawn-systemd #:init-keyword #:respawn-systemd
> +   #:init-value 'always
> +   #:getter respawn-systemd)

As briefly discussed on IRC, I think we should keep a single field for
this.  So perhaps ‘respawn?’ must simply be renamed to ‘respawn’ (no
question mark), with a comment like above explaining what the possible
values are.

> +  (let* ([e (status:exit-val status)]
> + [t (status:term-sig status)]
> + [r (respawn-systemd serv)]

Please avoid square brackets to remain consistent with the rest of the
code.  :-)

> + [clean (or (zero?  e)
> +(equal? t SIGHUP)
> +(equal? t SIGINT)
> +(equal? t SIGTERM)
> +(equal? t SIGPIPE))])

Use ‘=’ rather than ‘equal?’ when we know we’re dealing with numbers.

> +(if (or (equal? r 'always)
> +(equal? r 'on-watchdog) ;; not implemented yet
> +(and (equal? r 'on-success) clean)
> +(and (equal? r 'on-abnormal) (not clean) (equal? e #f))
> +(and (equal? r 'on-failure)  (not clean))
> +(and (equal? r 'on-abort)(equal? t SIGABRT)))

Likewise, use ‘eq?’ for symbols.

> +++ b/modules/shepherd/systemd.scm
> @@ -0,0 +1,143 @@
> +;; systemd.scm -- Systemd support
> +;; Copyright (C) 2018 Ioannis Panagiotis Koutsidis 
> +;;
> +;; This file is part of the GNU Shepherd.
> +;;
> +;; The GNU Shepherd is free software; you can redistribute it and/or modify 
> it
> +;; under the terms of the GNU General Public License as published by
> +;; the Free Software Foundation; either version 3 of the License, or (at
> +;; your option) any later version.
> +;;
> +;; The GNU Shepherd is distributed in the hope that it will be useful, but
> +;; WITHOUT ANY WARRANTY; without even the implied warranty of
> +;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +;; GNU General Public License for more details.
> +;;
> +;; You should have received a copy of the GNU General Public License
> +;; along with the GNU Shepherd.  If not, see .
> +
> +(define-module (shepherd systemd)
> +  #:use-module (ice-9 match)
> +  #:use-module (ice-9 textual-ports)
> +  #:use-module (oop goops)
> +  #:use-module (shepherd service)
> +  #:export 

Re: New ‘guix pull’ dosen’t update the guix manual in GuixSD

[宋文武]

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

>> The last there are from the ‘export’ statement of ‘/etc/profile’, the
>> first two are added by ‘source’ the profiles.  Since there is a guix in
>> the system profile contains the old info manual, the current one won’t
>> be picked.
>
> Ooh!  I think the change below should be enough to ensure
> ~/.config/guix/current comes first:
>
> --- a/gnu/system.scm
> +++ b/gnu/system.scm
> @@ -602,7 +602,7 @@ directory."
>  # because they would require combining both profiles.
>  # FIXME: See .
>  export 
> MANPATH=$HOME/.guix-profile/share/man:/run/current-system/profile/share/man
> -export 
> INFOPATH=$HOME/.config/guix/current/share/info:$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
> +export 
> INFOPATH=$HOME/.guix-profile/share/info:/run/current-system/profile/share/info
>  export 
> XDG_DATA_DIRS=$HOME/.guix-profile/share:/run/current-system/profile/share
>  export 
> XDG_CONFIG_DIRS=$HOME/.guix-profile/etc/xdg:/run/current-system/profile/etc/xdg
>  
> @@ -630,7 +630,7 @@ then
>export `cat /etc/environment | cut -d= -f1`
>  fi
>  
> -for profile in \"$HOME/.config/guix/current\" \"$HOME/.guix-profile\"
> +for profile in \"$HOME/.guix-profile\" \"$HOME/.config/guix/current\"
>  do
>if [ -f \"$profile/etc/profile\" ]
>then
> @@ -644,6 +644,8 @@ do
>fi
>  done
>  
> +export INFOPATH=\"$HOME/.config/guix/current/share/info:$INFOPATH\"
> +
>  # Set the umask, notably for users logging in via 'lsh'.
>  # See .
>  umask 022
>
>
> How does that sound?

Yeah, that's fine.  Maybe add comments about why source ‘current’ after
user profile (prefer current guix) and why ‘export INFOPATH’ at the end
(prefer the current guix manual).  Thank you!

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Ludovic Courtès]

Hello Tatiana & Ricardo!

Ricardo Wurmus  skribis:

> I wasn’t sure about this, so I asked on the #guix IRC channel.  Ludovic
> replied there that the Cuirass repository contains a “random”
> specification in “examples/random.scm”.  It uses
> “examples/random-jobs.scm” to generate … random jobs :)

Specifically, here’s how I would launch Cuirass for testing purposes:

--8<---cut here---start->8---
$ ./pre-inst-env cuirass -D cuirass.db -I 10 -S examples/random.scm
2018-06-11T13:20:58 running Fibers on 4 kernel threads
2018-06-11T13:20:58 marking stale builds as "scheduled"...
2018-06-11T13:20:58 listening on 127.0.0.1:8080
2018-06-11T13:20:58 retrieving list of pending builds...
2018-06-11T13:20:58 heap: 11.82 MiB; threads: 10; file descriptors: 55
2018-06-11T13:20:58 considering spec 'random', URL 'file:///data/src/cuirass'
2018-06-11T13:20:58 canceling 3 stale builds
2018-06-11T13:20:58 restarting 0 pending builds
2018-06-11T13:20:58 building 0 derivations in batches of 200
2018-06-11T13:20:58 done with 0 derivations
2018-06-11T13:20:58 done with restarted builds
2018-06-11T13:20:58 spec 'random': fetched commit 
"238f856e48ee333ed3e19fa32ce5e1742c650c67" (stamp was 
"43be95c40a433d21f65c9e6bfb04ccc9fa8e2db4")
2018-06-11T13:20:58 next evaluation in 10 seconds
2018-06-11T13:20:58 evaluating 'random' with commit 
"238f856e48ee333ed3e19fa32ce5e1742c650c67"
evaluating random jobs from directory 
"/gnu/store/bb7x9wgc91h9jndyd9k36dysqnamjmyl-cuirass-238f856", commit 
"238f856e48ee333ed3e19fa32ce5e1742c650c67"
2018-06-11T13:20:59 created evaluation 5 for random, commit 
238f856e48ee333ed3e19fa32ce5e1742c650c67
2018-06-11T13:20:59 building 11 jobs for 'random'
2018-06-11T13:20:59 building 11 derivations in batches of 200
2018-06-11T13:20:59 building batch of 200 derivations (0/11)
2018-06-11T13:21:00 build started: 
'/gnu/store/npkk2v9n3lrs99j6hfm2sa7z839q00lz-random0.drv'
2018-06-11T13:21:00 build started: 
'/gnu/store/xbsa9sk4aipcvkqpxai73pzad523mwnc-random1.drv'
2018-06-11T13:21:08 considering spec 'random', URL 'file:///data/src/cuirass'
2018-06-11T13:21:08 spec 'random': fetched commit 
"238f856e48ee333ed3e19fa32ce5e1742c650c67" (stamp was 
"238f856e48ee333ed3e19fa32ce5e1742c650c67")
2018-06-11T13:21:08 next evaluation in 10 seconds
--8<---cut here---end--->8---

This example instructs Cuirass to populate the ‘cuirass.db’ file from
the current directory, to check the repo in the current directory every
10 seconds, and to use the job specification from ‘examples/random.scm’.
The HTTP server of Cuirass is listening on ‘localhost’, port 8080.

Let me know if you have any questions!  (I’m civodul on #guile.)

HTH,
Ludo’.

Re: GSoC: Adding a web interface similar to the Hydra web interface

[Ricardo Wurmus]

Hi Tatiana,

> I've just committed a new version of the interface. I've implemented the
> first feature and create a more friendly interface based on bootstrap.

I’ve looked at the screenshots and have to say that this is really
looking good already.  Exciting!

> I had to add new database requests: db-get-evaluations-count,
> db-get-evaluations-info for the feature. I have added new endpoints:
> ("jobset" name), ("eval" id) and changed "status" endpoint to "/".

Okay.

> Now, when you launch Cuirass you can see all specifications on the
> main page (localhost:PORT/); when you click on the specification name
> you can see a list of all evaluations of a specification displaying
> numbers of successful, failed and pending builds for each evaluation;
> when you click on the evaluation ID you can see a list of builds with
> their statuses.

Excellent.

> The evaluation list is broken down into a set of pages with 20
> evaluations on each page. I have implemented a page navigation tool
> which may be used for other pages of this kind that we will implement
> later.

Sounds good.

> Could you please take a look at the commit and new functions?

I will take a look today and reply with some comments on your commits.

> I am still facing the local testing issue. When I tried to launch Cuirass
> with the large database you sent before it crashed with some git
> error.

Could you share the error message with us?

> Maybe you could recommend me some
> specifications to add to my local database?

I wasn’t sure about this, so I asked on the #guix IRC channel.  Ludovic
replied there that the Cuirass repository contains a “random”
specification in “examples/random.scm”.  It uses
“examples/random-jobs.scm” to generate … random jobs :)

Note that you’ll need to have Guix installed to use this, and you need
to start Cuirass from your source checkout.

> Now I am going to implement separate pages for builds with different
> statuses and implementation of the first feature will be finished. Also, I
> think It will be useful if I add some more navigation buttons to the
> header. Now it has only one link to the main page with Guix logo.

These sound like good next steps.  Thank you, Tatiana!

--
Ricardo

Re: 2 ideas

[Nils Gillmann]

Chris Marusich transcribed 2.2K bytes:
> Ricardo Wurmus  writes:
> 
> > It could be useful to have application-specific setup notes in a
> > well-known location that is gathered when the profile is built.
> 
> Maybe we could begin by adding a simple, optional field
> ("post-install-notes", maybe?) to the  record type?  We could
> maybe print the notes in the output of invocations like "guix package
> --show=foo".  We could also add a profile hook to generate a simple
> summary of such documentation for a given profile, in a specific
> location (not sure where - depends on the format, maybe, but somewhere
> in $GUIX_PROFILE/share?).

I still think $out/guix/doc/ would be a good idea (so the summary in
$GUIX_PROFILE/guix/doc), but other than that it seems like a good idea.

> > I would not like these notes to be printed automatically upon
> > installation, but generating a file with important notes seems like a
> > good idea in general.
> 
> I also think it's a good idea.  It seems potentially more useful than
> maintaining separate documentation in the manual or in a wiki, too
> (although that is certainly useful, as well).  There is something to be
> said for "self-documenting" package definitions.  It would have helped
> me to learn, for example, that to play additional media types in
> Rhythmbox (from the rhythmbox package), I needed to install additional
> GStreamer plugins (from the gst-libav package, I think).

Wouldn't this be a case for optional-inputs (list)? This is what I want
to provide. The output of it should tell you for which feature you need
which independent runtime dependency.

It's an entirely new subject, but you seem to be getting in that direction,
right?

Not everyone is aware of info, and we can not write and adjust man pages
for every application. With our continued diverging from Unix traditions,
self-documented package modules seem like the right choice - for both
users as well as developers and "middle-ware users".
> 
> -- 
> Chris

Re: my latest blog post [everyone, please take a cooldown break]

[swedebugia]

Hi

On June 10, 2018 4:37:17 PM GMT+02:00, Kei Kebreau  wrote:
>Gábor Boskovits  writes:
>
>> +1
>>
>> 2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber
>:
>>
>>  Nils Gillmann writes:
>>
>>  > Hi,
>>  >
>>  > I think it would be best if everyone involved would cool down for
>a couple of
>>  > days, restructure their thoughts and reflect on this thread. Look
>at what
>>  > they are doing, and at how they are reacting to other peoples
>reaction.
>>  > This topic is getting quiet heated, and other than the maintainers
>we
>>  > do not have established some kind of mderation. It can be hard to
>discuss
>>  > some topics online.
>>  > Text can sometimes fail to transport what we attampt to express,
>and
>>  > I have seen people step away from projects because of this.
>>
>>  +1000
>
>+1

+1
I would also like to point to resources that help me when I sometimes get into 
a heated discussion IRL and how to focus inward first to understand what is 
going on in me (with stimulus from the surrounding):
http://thework.com/en/do-work
https://www.youtube.com/watch?v=l7TONauJGfc
-- 
Cheers Swedebugia