Re: need help with debugging gopherd (geomyidae) service

[Maxim Cournoyer]

ng0  writes:

> When I start this via the arguments I pass (well, any arguments),
> without the service it starts and I can access the server.
>
> The service never starts (and due to its simplistic nature, no
> "BOOM CRASH THIS IS WHY I REFUSE TO START" is seen.
> In this version I added 'networking' to requirements, still no change.
>
> Anyone got an idea what could be missing from making this simple service
> functional?
>

[...]
> diff --git a/gnu/services/web.scm b/gnu/services/web.scm
> index f85b41215..2cfa835a7 100644
> --- a/gnu/services/web.scm
> +++ b/gnu/services/web.scm
> @@ -1,7 +1,7 @@
>  ;;; GNU Guix --- Functional package management for GNU
>  ;;; Copyright © 2015 David Thompson 
>  ;;; Copyright © 2015, 2016, 2017 Ludovic Courtès 
> -;;; Copyright © 2016 ng0 
> +;;; Copyright © 2016, 2017 ng0 
>  ;;; Copyright © 2016, 2017 Julien Lepiller 
>  ;;; Copyright © 2017 Christopher Baines 
>  ;;;
> @@ -41,7 +41,12 @@
>  nginx-named-location-configuration
>  nginx-named-location-configuration?
>  nginx-service
> -nginx-service-type))
> +nginx-service-type
> +
> +geomyidae-service
> +geomyidae-service-type
> +geomyidae-configuration
> +geomyidae-configuration?))
>  
>  ;;; Commentary:
>  ;;;
> @@ -305,3 +310,111 @@ files in LOG-DIRECTORY, and stores temporary runtime 
> files in RUN-DIRECTORY."
>  (server-blocks server-list)
>  (upstream-blocks upstream-list)
>  (file config-file
> +
> +;;;
> +;;; geomyidae
> +;;;
> +
> +(define-record-type* 
> +  geomyidae-configuration make-geomyidae-configuration
> +  geomyidae-configuration?
> +  (package  geomyidae-configuration-package ;package
> +(default geomyidae))
> +  (logfile  geomyidae-configuration-logfile ;string
> +(default "/var/log/geomyidae.log"))
> +  (loglevel geomyidae-configuration-loglevel ;number
> +(default 7))
> +  (htdocs   geomyidae-configuration-htdocs ;string
> +(default "/srv/gopher"))
> +  (port geomyidae-configuration-port ;number
> +(default 70))
> +  (sportgeomyidae-configuration-sport ;number
> +(default 70))
> +  (host geomyidae-configuration-host ;string
> +(default "localhost"))
> +  (ip   geomyidae-configuration-ip ;string
> +(default #f)))
> +
> +(define geomyidae-shepherd-service
> +  (match-lambda
> +(($ 
> +package logfile loglevel htdocs port
> +sport host ip);;user group
> + (let* ((geomyidae (file-append package "/bin/geomyidae"))
> +(cmd `(,geomyidae
> +   "-d"
> +   ,@(if logfile
> + `(,(string-append "-l " logfile))
> + '())
> +   ,@(if loglevel
> + `(,(string-append
> + "-v " (number->string loglevel)))
> + '())
> +   ,@(if htdocs
> + `(,(string-append "-b " htdocs))
> + '())
> +   ,@(if port
> + `(,(string-append
> + "-p " (number->string port)))
> + '())
> +   ,@(if sport
> + `(,(string-append
> + "-o " (number->string sport)))
> + '())
> +   ,@(if host
> + `(,(string-append "-h " host))
> + '())
> +   ,@(if ip
> + `(,(string-append "-i " ip))
> + '()
> +   (list (shepherd-service
> +  (documentation "Run the gopherd geomyidae")
> +  (provision '(geomyidae))
> +  (requirement '(user-processes loopback networking))
> +  (start #~(make-forkexec-constructor
> +'#$cmd

Why is there a single quote in front of #$cmd ?

I think Ludo once explained how to manually exercise the service script;
I'm not sure, but maybe you could gather more clues as to what might be
failing from there if you could manage to run the service manually at
the REPL.

Maxim


signature.asc
Description: PGP signature

WIP pgmodeler

[Catonano]

I have this patch for pgmodeler

https://www.pgmodeler.com.br/

It builds.

I would say that 20% of the work is done, now the remaining 80% is
integration work

It has some somewhat bizarre runtime requirements and procedures, it
probably needs some search paths to be set and probably a desktop file
should be written

I'm not keen to see after this stuff

So, I post it here, I'd be glad if anyone is willing to chip in some bits
and pieces

Thanks

P.S. I'm not sure if Potluck could cover this use case, but  I was thinking
that maybe a guix-wip mailing list like the guix-patches one could be
useful for half baked things like this
From 61d847dc95c0a28fbbbf5981deb1d637d9f6d9fd Mon Sep 17 00:00:00 2001
From: Adriano Peluso 
Date: Fri, 28 Apr 2017 09:50:07 +0200
Subject: [PATCH 1/1] gnu: Add pgmodeler.

* gnu/packages/databases.scm (pgmodeler) New variable.
---
 gnu/packages/databases.scm | 61 ++
 1 file changed, 61 insertions(+)

diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index 26706b827..4bd2f2f33 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -61,11 +61,13 @@
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages popt)
   #:use-module (gnu packages python)
+  #:use-module (gnu packages qt) ;; for pgmodeler
   #:use-module (gnu packages rdf)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages tcl)
   #:use-module (gnu packages tls)
   #:use-module (gnu packages xml)
+  #:use-module (gnu packages zip)
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
@@ -1530,3 +1532,62 @@ file format to other databases such as MySQL, Oracle, Sybase, PostgreSQL,
 etc., and an SQL engine for performing simple SQL queries.")
 (license (list license:lgpl2.0
license:gpl2+
+
+(define-public pgmodeler
+  (package ;(inherit qtbase)
+(name "pgmodeler")
+(version "0.8.2")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "https://github.com/pgmodeler/pgmodeler/archive/v";
+ version
+ ".zip"
+ ))
+ (file-name (string-append name "-" version ".zip"))
+ (sha256
+  (base32
+   "1qyh56dxh7jwnrqy61qcmay38ifs7s9n2b3y2p9ia92fk01gd78k"
+(native-inputs
+ `(
+   ;;("qtbase" ,qtbase)
+   ;;("zlib" ,zlib)
+   ("unzip" ,unzip)
+   ("pkg-config" ,pkg-config)   
+   ))
+(inputs
+ `(("qtbase" ,qtbase)
+   ("postgresql" ,postgresql)
+   ("libxlm" ,libxml2)
+   ("qtsvg" ,qtsvg)))
+(build-system gnu-build-system)
+(arguments
+ `(#:phases
+   (modify-phases %standard-phases
+ (replace 'configure
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out"))
+   (postgres (assoc-ref inputs "postgresql")))
+   (zero? (system* "qmake" "pgmodeler.pro"
+   (string-append "LIBS += -L" postgres "/lib" "-lpq")
+   (string-append "INCLUDEPATH  += " postgres "/include"))
+ (add-before 'configure 'fix-project-files
+ (lambda* (#:key inputs outputs #:allow-other-keys)
+   (let ((out(assoc-ref outputs "out"))
+ (qtbase (assoc-ref inputs "qtbase")))
+ (substitute* "pgmodeler.pri"
+   (("PREFIX = /usr/local")
+(string-append "PREFIX = "
+   out "/usr/local"))
+ (add-before 'check 'set-display
+ (lambda _
+   ;; make Qt render "offscreen", required for tests
+   (setenv "QT_QPA_PLATFORM" "offscreen")
+   #t)
+(synopsis "Graphical modeler for Postgresql")
+(description "Easily create and edit database models
+with simple and intuitive interface.
+The software's forms indicate which fields
+must be filled in order to provide
+the correct generation of SQL code.")
+(home-page "https://www.pgmodeler.com.br";)
+(license license:gpl3)))
-- 
2.13.0

Register for the GNU Hackers Meeting, August 25–27!

[Ludovic Courtès]

Hello Guix!

Now’s the time to register for the GNU Hackers Meeting:

  https://www.gnu.org/ghm/

  https://lists.gnu.org/archive/html/ghm-discuss/2017-05/msg0.html

A bunch of Guix hackers (myself included) are planning to be there, so
let’s take advantage of this event to meet in person, chat about all
things Guix and GNU, and have a good time!

It would be nice if you could propose a talk about how you use
Guix{,SD}, your experience, or new use cases that you envision: Web
service deployment, porting Guix{,SD} to new architectures,
cross-compilation to {MinGW,aarch64,GNU/Hurd,PowerPC,alpha,whatnot},
supporting multiple bootloaders, GuixSD service configuration & testing,
HPC & scientific software, the Guix Worflow Language, channels &
external package repos, the potluck, etc.

Hoping to see you there!

Ludo’.


signature.asc
Description: PGP signature

Re: Performance of the man page database generation

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> 18 man subdirectories contained newer manual pages.
> 3943 manual pages were added.
> find-files: 
> /gnu/store/5mk4lg1rdzq2p3148idjd4z0bvif0nf4-gimp-2.8.18/share/man/man1/gimp-console.1:
>  No such file or directory
> guix build: error: build failed: derivation 
> `/gnu/store/vk10zmd5nm8kppd0f655fraradr019fq-manual-database.drv' may not be 
> deterministic: output 
> `/gnu/store/lmf9rfzj565m31xzhhlam3lk91bjbqsm-manual-database' differs
>
> real0m39.890s
> user0m0.356s
> sys 0m0.040s

Not good!

> As you can see, mandb stumbled more than once with some of our packages'
> manpages. Those failures are probably attributable to bad packages
> manual pages. For example, the gcc manual pages are known to be broken
> for example. [0]
>
> By looking at the output as it was generated, it seemed as if those
> failures caused mandb to take more time.

That would be surprising no?

> Another reason could be that mandb is just inefficient. There's an old
> bug about mandb's use of processes being less than optimal ("strace
> indicates that mandb is forking on the order of four processes per
> page") [1]. It seems that Colin Watson had a good idea of how to improve
> things but didn't get around to implementing it yet.

Yeah, I noticed that it was forking a lot by looking at the process
graph in gkrellm.  That’s not good.

The database creation is probably not rocket science, so I wonder if we
could implement it more efficiently in Guile using the appropriate gdbm
or bdb bindings.  Certainly we could avoid the forks.

Alternately we optimize mandb itself directly and contribute it
upstream, which would be benefit everyone but might be trickier.

Thoughts?

Ludo’.

Re: We need a different downloader for KDE

[Ludovic Courtès]

Hello,

Hartmut Goebel  skribis:

> can anybody more skilled than me please implement some HTTP(s) updater,
> so we can "refresh" directly from downloads.kde.org. Please apologize,
> if there already is one, I did not spot one.
>
> Yesterday KDE released an security update, which was available at
> downloads.kde.org at 05:38 GMT. When I tried updating the packages
> ("guix refresh") at about 18:30 GMT, the packages have not been found.
>
> Reasons for this is: "guix refresh --type=kde" uses
> ftp://mirror.mit.edu, which obviously is lagging. This may cost us
> important time in case of an emergency update. Unfortunately KDE's main
> site (downloads.kd.org) is only accessible via https, not via FTP.

The updater currently browses FTP, and there’s no way to browse an HTTP
directory (because HTTP is not a file transfer protocol).

So we need a way to list the latest releases somehow.  If they publish
JSON, XML, or some other structured info format, that’s fine too.  But
HTTP alone is not good: we’d have to infer the information from HTML
pages, which sounds fragile.

Could you check what methods they offer to get updates?

Ludo’.

Re: GuixSD bootable ISO-9669 image

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> On Fri, 12 May 2017 17:33:21 +0200
> l...@gnu.org (Ludovic Courtès) wrote:
>> Then users should pick the right one, usually the macro, and get an
>> error when they pass an invalid UUID.
>
> Note that the directory /dev/disk/by-uuid doesn't contain any marker about 
> what kind of uuid it is. So it would make things complicated for the user.
>
> I wouldn't expect anyone that isn't a programmer to know that fat32 uuids are 
> different from btrfs uuids.
>
> If we have different uuid macros, we should have *-uuid macros for *every* 
> possible filesystem type, whether the uuids differ or not - at least then 
> there's a pattern for the user to learn.  Not like 3 macros and 14 filesystem 
> types so you'd have to have a mapping function in your head.
>
> But really, I myself use uuids only for file-system entries to be bus 
> independent so I can plug known disks on whatever slot I want and they'll be 
> mounted at the same place regardless.  I guess another use case is for the 
> Guix LiveCD to find itself - for the same reason.  Not sure what the 
> complication of bytevectors, multiple macros etcetc buys us.  The user is 
> probably copy&pasting the uuid from /dev/disk/by-uuid anyway.  It's not like 
> you type in uuids (ever).

The user interface (the ‘uuid’ macro for instance) and the internal
representation (bytevectors) are two different things.

The internal representation is fine, we don’t want to represent
something that’s literally a “byte vector” as a Unicode string, and have
parsing errors that could happen anywhere.

As for the user interface, I get your point.  We certainly don’t want to
make the user’s life unnecessarily difficult.

Honestly, I was under the assumptions that DCE UUIDs was all that
mattered: it works for ext2 and btrfs, right?  I would think that people
would rarely add FAT32 or ISO9660 UUIDs to the OS config.  That’s why I
though that having a separate macro for these two “special UUID types”
is okay.

What the macro buys us is expansion-time or system-instantiation-time
checks.  When someone uses /dev/disk/by-uuid/something-obviously-wrong
on another GNU/Linux system, they don’t get an error until they try to
boot the thing.  Here we have an opportunity to do that check before the
system is instantiated.

WDYT?

Ludo’.

shepherd -> guile 2.2?

[Ricardo Wurmus]

Hi Guix,

I have built shepherd with guile-2.2, but I noticed a couple of
warnings/errors during the build:

--8<---cut here---start->8---
starting phase `build'
/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin/mkdir -p 
"`dirname modules/shepherd/config.scm`"
/gnu/store/z763jk8lkragpz2qr2wbrz946lgalx2h-sed-4.4/bin/sed -e 
's,%PREFIX%,/gnu/store/7mlrfpazchpr9p2k9dx79ffzh0r5gxyw-shepherd-0.3.2,g' -e 
's,%modsrcdir%,/tmp/guix-build-shepherd-0.3.2.drv-0/shepherd-0.3.2/modules,g' 
-e 
's,%modbuilddir%,/tmp/guix-build-shepherd-0.3.2.drv-0/shepherd-0.3.2/modules,g' 
-e 's,%localstatedir%,/var,g' -e 
's,%sysconfdir%,/gnu/store/7mlrfpazchpr9p2k9dx79ffzh0r5gxyw-shepherd-0.3.2/etc,g'
 -e 's,%VERSION%,0.3.2,g' -e 's,%PACKAGE_BUGREPORT%,bug-g...@gnu.org,g' -e 
's,%PACKAGE_NAME%,GNU Shepherd,g' -e 
's,%PACKAGE_URL%,http://www.gnu.org/software/shepherd/,g' -e 
's,%GUILE%,/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guile,g' 
< modules/shepherd/config.scm.in >modules/shepherd/config.scm
make  all-am
make[1]: Entering directory 
'/tmp/guix-build-shepherd-0.3.2.drv-0/shepherd-0.3.2'
  GEN  shepherd
  GEN  herd
  GEN  reboot
  GEN  halt
  GUILEC   modules/shepherd/scripts/halt.go
  GUILEC   modules/shepherd.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild
;;; WARNING: compilation of 
/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild failed:
;;; ERROR: failed to create path for auto-compiled file 
"/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild"

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
  GUILEC   modules/shepherd/scripts/herd.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild
;;; WARNING: compilation of 
/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild failed:
;;; ERROR: failed to create path for auto-compiled file 
"/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild"

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
  GUILEC   modules/shepherd/scripts/reboot.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild
;;; WARNING: compilation of 
/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild failed:
;;; ERROR: failed to create path for auto-compiled file 
"/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild"

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
  GUILEC   modules/shepherd/config.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild
;;; WARNING: compilation of 
/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild failed:
;;; ERROR: failed to create path for auto-compiled file 
"/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild"

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
  GUILEC   modules/shepherd/system.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild
;;; WARNING: compilation of 
/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild failed:
;;; ERROR: failed to create path for auto-compiled file 
"/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild"
  GUILEC   modules/shepherd/args.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pass the --no-auto-compile argument to disable.
;;; compiling /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild
;;; WARNING: compilation of 
/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild failed:
;;; ERROR: failed to create path for auto-compiled file 
"/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild"
  GUILEC   modules/shepherd/service.go
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;   or pa

Customizing /etc

[Alex Kost]

This is almost the same message as:

  http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01570.html

I mean this is a reminder on the subject.

Ludovic, I think you suggested a good solution to a "Customizing
/etc/profile" problem.  Since I will no longer be a blocker of
 after this fix, would you like to commit
that change, or are there any issues with that?

-- 
Thanks,
Alex

Re: shepherd -> guile 2.2?

[Andy Wingo]

On Tue 16 May 2017 10:42, Ricardo Wurmus  writes:

> ;;; WARNING: compilation of 
> /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild failed:
> ;;; ERROR: failed to create path for auto-compiled file 
> "/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild"

This is because the build does not set XDG_CACHE_HOME.  See:

  https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00939.html

> Some deprecated features have been used.  Set the environment
> variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
> program to get more information.  Set it to "no" to suppress
> this message.

Here you will get more info if you set the
GUILE_WARN_DEPRECATED=detailed variable.

> shepherd/support.scm:209:2: warning: non-literal format string

Not a deal-breaker; worth having a look at though.

> shepherd/runlevel.scm:106:6: warning: possibly unbound variable 
> `next-services'

Something to look into.

> shepherd/service.scm:606:8: warning: possibly unbound variable `apply-to-args'

Replace with "apply".

> And lastly: should we keep a guile-2.0 variant of the shepherd, or is it
> fine to push this tiny change?

I would say don't bother keeping it.

Andy

How do I fix a messed-up Guix?

[Konrad Hinsen]

Hi everyone,

since ¨guix pull" failed (see a recent message), I tried various ideas 
for getting back to a useable guix installation:


 - Build from a git checkout. Unfortunately, I cannot do "guix 
environment guix" anymore (like "guix pull", it tries to download 
python-2.7.12 and fails due to a hash mismatch). Running "./bootstrap" 
in my standard environment fails with an obscure error message about 
"autopoint" missing.


 - "guix package --roll-back" in the hope of going back to a state in 
which I can do "guix environment guix".


I ended up rolling back until my profile no longer contained "guix" (I 
have no idea how I could ever produce such a profile), so now I am 
completely stuck. Any idea for getting out of this mess?


Thanks in advance,
  Konrad.

Re: How do I fix a messed-up Guix?

[Konrad Hinsen]

On 16/05/2017 15:02, Konrad Hinsen wrote:


I ended up rolling back until my profile no longer contained "guix" (I
have no idea how I could ever produce such a profile), so now I am
completely stuck. Any idea for getting out of this mess?


I forgot two details:

 - I tried building python-2.7.12 using --fallback. This fails because 
one of the tests (test_pty) fails.


 - Under another user account, I still have a working guix profile 
because I hardly ever update it. I'd like to avoid breaking it, and 
therefore avoid the brute-force approach of re-doing the binary install 
procedure.


Konrad.

Re: bug#26346: [PATCH] asdf-build-system improvements.

[Ricardo Wurmus]

Hi Andy,

> As promised a long time ago, I'm attaching patches to improve the state
> of the asdf-build-system.

I will push your patches with some very minor changes (e.g. fixed
typos, slightly adjusted commit summaries) after confirming that stumpwm
still works fine.

Thank you for your patches and your patience!

> As a result, there will be some changes that
> users should be aware of. Users of stumpwm should include sbcl-stumpwm
> as opposed to (list sbcl-stumpwm "bin") in their OS configurations, or
> sbcl-stumpwm instead of sbcl-stumpwm:bin in their profiles.

@guix-devel: please note this change and make adjustments to your
manifests or OS configurations if you’re using StumpWM.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: 150 € at Knüllwald venue

[Fox]

dude the math checks out

Re: How do I fix a messed-up Guix?

[julien lepiller]

Le 2017-05-16 15:11, Konrad Hinsen a écrit :

On 16/05/2017 15:02, Konrad Hinsen wrote:


I ended up rolling back until my profile no longer contained "guix" (I
have no idea how I could ever produce such a profile), so now I am
completely stuck. Any idea for getting out of this mess?


I forgot two details:

 - I tried building python-2.7.12 using --fallback. This fails because
one of the tests (test_pty) fails.

 - Under another user account, I still have a working guix profile
because I hardly ever update it. I'd like to avoid breaking it, and
therefore avoid the brute-force approach of re-doing the binary
install procedure.

Konrad.


Hi Konrad,

You could probably use the other user's guix version. Copy 
~otheruser/.config/guix/latest to your own user's .config/guix, and try 
to guix pull from that. That won't mess with the other user's profile.

Re: How do I fix a messed-up Guix?

[Pjotr Prins]

If you still have guix in the store you can use the store path to
reach and run it.

As I had something similar today that there was no recent guix... I
actually restored with a slightly older 'guix pack' from a different
machine.

  https://www.gnu.org/software/guix/news/creating-bundles-with-guix-pack.html

You have to use an older version that does not get overwritten by a
new Guix. Otherwise the update will fail dramatically. It happened to
me first time :)

Alternatively you can unpack the store part of the binary install and
use that. Again, make sure you are not reinstalling the exact same
version.

If you still have a working guix you should use 'guix archive'.

Many options.

Pj.

On Tue, May 16, 2017 at 04:03:19PM +0200, julien lepiller wrote:
> Le 2017-05-16 15:11, Konrad Hinsen a ??crit??:
> >On 16/05/2017 15:02, Konrad Hinsen wrote:
> >
> >>I ended up rolling back until my profile no longer contained "guix" (I
> >>have no idea how I could ever produce such a profile), so now I am
> >>completely stuck. Any idea for getting out of this mess?

Re: How do I fix a messed-up Guix?

[Konrad Hinsen]

Hi Julien,


You could probably use the other user's guix version. Copy
~otheruser/.config/guix/latest to your own user's .config/guix, and try
to guix pull from that. That won't mess with the other user's profile.


Thanks, that helped, though not directly: the other user didn't have 
~/.config/guix at all. But now I know where guix stores the pointer to 
its current version, and that helped me figure out how to revive an 
older version of guix-latest, which... works!


Unfortunately, compiling the current git checkout with that version fails:

  GUILEC   guix/tests/http.go
Backtrace:
In ice-9/boot-9.scm:
 160: 9 [catch #t # ...]
In unknown file:
   ?: 8 [apply-smob/1 #]
In ice-9/boot-9.scm:
  66: 7 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 6 [eval # #]
In ice-9/boot-9.scm:
2404: 5 [save-module-excursion #ice-9/boot-9.scm:4051:3 ()>]

4058: 4 [#]
1727: 3 [%start-stack load-stack ...]
1732: 2 [#]
In unknown file:
   ?: 1 [primitive-load 
"/home/hinsen/Development/guix/./build-aux/compile-all.scm"]

In ice-9/threads.scm:
  99: 0 [loop (("guix/base16.scm" "guix/base64.scm" "guix/records.scm" 
...))]


ice-9/threads.scm:99:22: In procedure loop:
ice-9/threads.scm:99:22: In procedure fport_write: Bad address


But I could run "guix pull" to get the latest release, which is good 
enough for my current needs.


Thanks again,
  Konrad.

Re: Planning for the next release

[sirgazil]

On 15/05/17 07:44, Ludovic Courtès wrote:
> Hi Leo!
>
> (sirgazil: this is about providing a ready-to-use VM image of GuixSD for
> download, in addition to the installation image.  See at the bottom.)

[...]

> sirgazil: do you think we should add a special icon or something for the
> VM image?

Yes. How about this:

https://bitbucket.org/sirgazil/dnd/downloads/qemu-img.tar.gz

You can drop both files in "website/static/base/img". The
"installer.svg" file is supposed to overwrite the existing one.

Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2]

[Ricardo Wurmus]

myglc2  writes:

> I believe there will be many guix "users" that want to run from git
> checkout. They just may not know it, yet. They will want it not just
> because they are trying to get around the limitations of git pull.  For
> example, even users that don't do development have occasion to...
>
> - select non-stock package config options
>
> - need/apply/use patches from guix developers
>
> - need/apply/use patches from package developers
>
> - need/apply/use some crazy stuff from a friend

For those things I believe it to be better to use the package rewriting
framework, i.e. *adding* package variants that have additional patches
or modified configuration options.

Using the git checkout directly comes with too many disadvantages for
users who are not developers.  Git’s UI is famously weird, and there
hardly is anyone who really loves it.

Using the git checkout also requires the use of “make clean-go” whenever
the ABI changes, and occasionally even necessitates re-bootstrapping, or
in the case of upgrading to Guile 2.2 re-configuration.

> Furthermore, ISTM that current guix packaging is a rather nasty tease:
> Our user installs guix/guixSD, does 'guix pull' & 'guix-edit', and what
> do they get?
>
> READ-ONLY source in an editor that BEEPS when they TRY TO CHANGE IT :-(
>
> Right out of the box this seem contrary to the Guix promise of _freedom_
> and _hackability_.

True, “guix edit” could do better, e.g. create a new package variant in
a user module that inherits from the given package and puts the cursor
in the right spot to make changes right there.  Upon saving, the package
could be used right away with GUIX_PACKAGE_PATH.

I think that a first step towards improving the experience with “guix
pull” is to build Guix continuously on Hydra and tell “guix pull” to
download that.  Users would no longer have to wait for compilation on
their local machines, removing a big incentive to go with a git
checkout.  Maybe we should do this first to stop the worst problems,
buying us a bit more time to implement channels.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

GNU Hackers Meeting, August 25–27 near Kassel in Hesse, Germany ("Knüllwald")

[ff]

"Knüllwald" sounds like a truely epic venue   ;-)

Re: Planning for the next release

[Alex Kost]

If it's not too late for the release, I think it would be good to make
guile-json an optional dependency (currently it is required).  A simple
fix is here:

  http://debbugs.gnu.org/26860

Although Ricardo suggested another solution there.

-- 
Alex

Re: Performance of the man page database generation

[Maxim Cournoyer]

Hi Ludovic,

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

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> 18 man subdirectories contained newer manual pages.
>> 3943 manual pages were added.
>> find-files: 
>> /gnu/store/5mk4lg1rdzq2p3148idjd4z0bvif0nf4-gimp-2.8.18/share/man/man1/gimp-console.1:
>>  No such file or directory
>> guix build: error: build failed: derivation
>> `/gnu/store/vk10zmd5nm8kppd0f655fraradr019fq-manual-database.drv'
>> may not be deterministic: output
>> `/gnu/store/lmf9rfzj565m31xzhhlam3lk91bjbqsm-manual-database'
>> differs
>>
>> real0m39.890s
>> user0m0.356s
>> sys 0m0.040s
>
> Not good!
>
>> As you can see, mandb stumbled more than once with some of our packages'
>> manpages. Those failures are probably attributable to bad packages
>> manual pages. For example, the gcc manual pages are known to be broken
>> for example. [0]
>>
>> By looking at the output as it was generated, it seemed as if those
>> failures caused mandb to take more time.
>
> That would be surprising no?
>

You're right. The output just tricked me into thinking that. But in the
end it's just the sheer numbers of manpages in my profile which takes
time to get indexed (I have almost 4000). The package which the biggest
collection that I know of is 'libx11', which comes with more than 2000
packages itself!

It can be used as a good test for the manual database profile hook:

--8<---cut here---start->8---
guix environment --ad-hoc libx11
substitute: updating list of substitutes from 'https://bayfront.guixsd.org'... 
100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivations will be built:
   /gnu/store/1ysz4v6nn4iwpwisgpzb3x92isympxrq-profile.drv
   /gnu/store/4laycbr82asv7k4li1y1fwfgfjfp0qxz-manual-database.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
Creating manual page database for 5 packages... done in 20.124 s
--8<---cut here---start->8---

>> Another reason could be that mandb is just inefficient. There's an old
>> bug about mandb's use of processes being less than optimal ("strace
>> indicates that mandb is forking on the order of four processes per
>> page") [1]. It seems that Colin Watson had a good idea of how to improve
>> things but didn't get around to implementing it yet.
>
> Yeah, I noticed that it was forking a lot by looking at the process
> graph in gkrellm.  That’s not good.
>
> The database creation is probably not rocket science, so I wonder if we
> could implement it more efficiently in Guile using the appropriate gdbm
> or bdb bindings.  Certainly we could avoid the forks.
>
> Alternately we optimize mandb itself directly and contribute it
> upstream, which would be benefit everyone but might be trickier.
>
> Thoughts?

It'd be nice as a first to check with Colin if he still thinks fixing it
in mandb would be easy. Colin pointed to improving the pipeline with
coroutines or generators [0], which would potentially go in
"libpipeline".

If this stuff is not easy to implement there, then yes, an
implementation in Guile with bindings to gdbm (which is what we are
using currently) would make sense since Guile already comes which
coroutines and generators, IIUC.

Maxim

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630799


signature.asc
Description: PGP signature

Re: Planning for the next release

[Leo Famulari]

On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote:
> On 15/05/17 07:44, Ludovic Courtès wrote:
> > Hi Leo!
> >
> > (sirgazil: this is about providing a ready-to-use VM image of GuixSD for
> > download, in addition to the installation image.  See at the bottom.)
> 
> [...]
> 
> > sirgazil: do you think we should add a special icon or something for the
> > VM image?
> 
> Yes. How about this:
> 
> https://bitbucket.org/sirgazil/dnd/downloads/qemu-img.tar.gz
> 
> You can drop both files in "website/static/base/img". The
> "installer.svg" file is supposed to overwrite the existing one.

I like this image; I'll push it to guix-artwork soon unless somebody
objects.


signature.asc
Description: PGP signature

Re: Planning for the next release

[Leo Famulari]

On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote:
> On 15/05/17 07:44, Ludovic Courtès wrote:
> > Hi Leo!
> >
> > (sirgazil: this is about providing a ready-to-use VM image of GuixSD for
> > download, in addition to the installation image.  See at the bottom.)
> 
> [...]
> 
> > sirgazil: do you think we should add a special icon or something for the
> > VM image?
> 
> Yes. How about this:
> 
> https://bitbucket.org/sirgazil/dnd/downloads/qemu-img.tar.gz
> 
> You can drop both files in "website/static/base/img". The
> "installer.svg" file is supposed to overwrite the existing one.

Although, I am wondering why 'installer.svg' seems specific to the VM
image now. The VM image is not an installer.

Re: shepherd -> guile 2.2?

[Fox]

I run shepherd in debian with guile 2.2.2

it cannot find my apache2, though

Re: guix pull timing out on low resource servers

[Leo Famulari]

On Mon, May 15, 2017 at 10:12:01AM +, ng0 wrote:
> Since the switch to Guile 2.2 and guix pull taking much more
> computing time and resources, all my virtual hosting servers
> time out when I run guix pull on them without using mosh
> and just openssh, because the process just takes much too
> long.

I have a super low-power server with 4 GB of RAM [0]. Building Guix with
Guile 2.2 takes about 100 minutes:


real100m6.133s
user0m18.804s
sys 0m2.724s

[0] This is basically an embedded router SOC, the AMD GX-412TC:
http://pcengines.ch/apu2b4.htm

Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2]

[Maxim Cournoyer]

On Tue, May 16, 2017 at 8:55 AM, Ricardo Wurmus  wrote:
>
> myglc2  writes:
>
>> I believe there will be many guix "users" that want to run from git
>> checkout. They just may not know it, yet. They will want it not just
>> because they are trying to get around the limitations of git pull.  For
>> example, even users that don't do development have occasion to...
>>
>> - select non-stock package config options
>>
>> - need/apply/use patches from guix developers
>>
>> - need/apply/use patches from package developers
>>
>> - need/apply/use some crazy stuff from a friend
>
> For those things I believe it to be better to use the package rewriting
> framework, i.e. *adding* package variants that have additional patches
> or modified configuration options.
>
> Using the git checkout directly comes with too many disadvantages for
> users who are not developers.  Git’s UI is famously weird, and there
> hardly is anyone who really loves it.
>
> Using the git checkout also requires the use of “make clean-go” whenever
> the ABI changes, and occasionally even necessitates re-bootstrapping, or
> in the case of upgrading to Guile 2.2 re-configuration.
>
>> Furthermore, ISTM that current guix packaging is a rather nasty tease:
>> Our user installs guix/guixSD, does 'guix pull' & 'guix-edit', and what
>> do they get?
>>
>> READ-ONLY source in an editor that BEEPS when they TRY TO CHANGE IT :-(
>>
>> Right out of the box this seem contrary to the Guix promise of _freedom_
>> and _hackability_.
>
> True, “guix edit” could do better, e.g. create a new package variant in
> a user module that inherits from the given package and puts the cursor
> in the right spot to make changes right there.  Upon saving, the package
> could be used right away with GUIX_PACKAGE_PATH.
>
> I think that a first step towards improving the experience with “guix
> pull” is to build Guix continuously on Hydra and tell “guix pull” to
> download that.  Users would no longer have to wait for compilation on
> their local machines, removing a big incentive to go with a git
> checkout.  Maybe we should do this first to stop the worst problems,
> buying us a bit more time to implement channels.

+1

Re: Planning for the next release

[Leo Famulari]

On Mon, May 15, 2017 at 02:44:51PM +0200, Ludovic Courtès wrote:
> Leo Famulari  skribis:
> > Subject: [PATCH 1/2] doc: Mention the pre-built VM image.
> > * doc/guix.texi (Running GuixSD in a VM): Mention the pre-built VM image.
>
> > Subject: [PATCH 2/2] maint: The 'release' target builds a VM image.
> > * Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
> > GUIXSD_VM_IMAGE_SIZE): New variables.
> > (release): Add logic to build a VM image.

I took your suggestions and added 'gnu/system/examples/vm-image.tmpl' in
the updated version of the patch (attached).

In 'vm-image.tmpl', I put some VPS-specific suggestions related to
partitioning and filesystems in the MOTD. The crux of the issue is that
we don't know how large the virtual disk will be, so we need to resize
the partition and filesystem after we boot.

Hopefully in the future we can offer something more sophisticated, which
will do this sort of task automatically.

> > Subject: [PATCH] website: downloads: Mention the VM image.
> >
> > * website/www/download.scm (%vm-image-description, %vm-image-manual,
> > %vm-image-image): New variables.
> > (guixsd-vm-image-files): New procedure.
> > (download-page): Use guixsd-vm-image-files.

> sirgazil: do you think we should add a special icon or something for the
> VM image?

I had a followup question for sirgazil so I'll wait for a response:

https://lists.gnu.org/archive/html/guix-devel/2017-05/msg00310.html
From 1c9ad17ea0b64b29117e49526ff07d2e7e7c6c13 Mon Sep 17 00:00:00 2001
From: Leo Famulari 
Date: Sat, 13 May 2017 20:44:36 -0400
Subject: [v2] maint: The 'release' target builds a VM image.

* Makefile.am (GUIXSD_VM_SYSTEMS, GUIXSD_VM_IMAGE_BASE,
GUIXSD_VM_IMAGE_SIZE): New variables.
(release): Add logic to build a VM image.
* gnu/system/examples/vm-image.tmpl: New file.
* doc/guix.texi (Running GuixSD in a VM, Installing GuixSD in a VM): Mention the
pre-built VM image.
---
 Makefile.am   | 24 ++
 doc/guix.texi | 29 +
 gnu/system/examples/vm-image.tmpl | 53 +++
 3 files changed, 95 insertions(+), 11 deletions(-)
 create mode 100644 gnu/system/examples/vm-image.tmpl

diff --git a/Makefile.am b/Makefile.am
index 5bfc9ca88..0b12c6484 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@
 # Copyright © 2016 Mathieu Lirzin 
 # Copyright © 2016, 2017 Mark H Weaver 
 # Copyright © 2017 Mathieu Othacehe 
+# Copyright © 2017 Leo Famulari 
 #
 # This file is part of GNU Guix.
 #
@@ -571,12 +572,21 @@ BINARY_TARBALLS = 
\
 # Systems supported by GuixSD.
 GUIXSD_SUPPORTED_SYSTEMS ?= x86_64-linux i686-linux
 
+# Systems for which we build GuixSD VMs.
+GUIXSD_VM_SYSTEMS ?= x86_64-linux
+
 # Prefix of the GuixSD installation image file name.
 GUIXSD_IMAGE_BASE = guixsd-usb-install-$(PACKAGE_VERSION)
 
+# Prefix of the GuixSD VM image file name.
+GUIXSD_VM_IMAGE_BASE = guixsd-vm-image-$(PACKAGE_VERSION)
+
 # Size of the installation image (for x86_64 typically).
 GUIXSD_INSTALLATION_IMAGE_SIZE ?= 950MiB
 
+# Size of the VM image (for x86_64 typically).
+GUIXSD_VM_IMAGE_SIZE ?= 2GiB
+
 # The release process works in several phases:
 #
 #   0. We assume the developer created a 'vX.Y' tag.
@@ -631,6 +641,20 @@ release: dist
  mv "$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz.tmp"   
\
 "$(releasedir)/$(GUIXSD_IMAGE_BASE).$$system.xz" ; 
\
done
+   for system in $(GUIXSD_VM_SYSTEMS) ; do 
\
+ image=`$(top_builddir)/pre-inst-env   
\
+   guix system vm-image
\
+   --system=$$system   
\
+   --image-size=$(GUIXSD_VM_IMAGE_SIZE)
\
+   gnu/system/examples/vm-image.tmpl` ;
\
+ if [ ! -f "$$image" ] ; then  
\
+   echo "failed to produced GuixSD VM image for $$system" >&2 ;
\
+   exit 1 ;
\
+ fi ;  
\
+ xz < "$$image" > 
"$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz.tmp" ;\
+ mv "$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz.tmp"
\
+"$(releasedir)/$(GUIXSD_VM_IMAGE_BASE).$$system.xz" ;  
\
+   done
@echo
@echo "Congratulations!  All the release files are now in 
$(releasedir)."
@echo
diff --git a/doc/guix.texi b/doc/guix.texi
index b272fcec8..e6a9706b9 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -7628,8 +7628,11 @@ good.
 @subsection I

Re: Planning for the next release

[sirgazil]

On 16/05/17 13:19, Leo Famulari wrote:
> On Tue, May 16, 2017 at 09:41:38AM -0500, sirgazil wrote:
>> On 15/05/17 07:44, Ludovic Courtès wrote:
>>> Hi Leo!
>>>
>>> (sirgazil: this is about providing a ready-to-use VM image of GuixSD for
>>> download, in addition to the installation image.  See at the bottom.)
>> [...]
>>
>>> sirgazil: do you think we should add a special icon or something for the
>>> VM image?
>> Yes. How about this:
>>
>> https://bitbucket.org/sirgazil/dnd/downloads/qemu-img.tar.gz
>>
>> You can drop both files in "website/static/base/img". The
>> "installer.svg" file is supposed to overwrite the existing one.
> Although, I am wondering why 'installer.svg' seems specific to the VM
> image now. The VM image is not an installer.
Hi Leo :)

I don't know if I understand correctly, but the "installed.svg" file
contains several download icons, but just one is on the "canvas" at a
time, so your file manager will display a preview with the last icon
that was left on the canvas, which should be the QEMU icon.

As for the name of the file, it may be confusing, so maybe it could be
renamed "download-icons.svg"?

-- 
https://sirgazil.bitbucket.io/

Re: Planning for the next release

[Leo Famulari]

On Tue, May 16, 2017 at 07:51:36PM -0500, sirgazil wrote:
> On 16/05/17 13:19, Leo Famulari wrote:
> > Although, I am wondering why 'installer.svg' seems specific to the VM
> > image now. The VM image is not an installer.
> Hi Leo :)
> 
> I don't know if I understand correctly, but the "installed.svg" file
> contains several download icons, but just one is on the "canvas" at a
> time, so your file manager will display a preview with the last icon
> that was left on the canvas, which should be the QEMU icon.

Oh, I see! I didn't realize it could contain multiple icons. Now, I
opened it with inkscape and see all the icons.

> As for the name of the file, it may be confusing, so maybe it could be
> renamed "download-icons.svg"?

Yeah, I think that's a good idea. I can do that locally before pushing.


signature.asc
Description: PGP signature