bug#41063: emacs-guix: unrecognized keyword error

[Michael Rohleder]

Ludovic Courtès  writes:
>> emacs-guix/actions.scm:118:8: In procedure process-package-actions:
>> Unrecognized keyword: #:use-substitutes?
>
> This probably has to do with this API change:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=65ffb9388c1c3d870cb07e4cb3ef12c9ac06a161
>
> I see it’s already reported upstream:
>
>   https://gitlab.com/emacs-guix/emacs-guix/-/issues/18

This is fixed with the latest (gitlab) version:

From 1c58fd7f2de4623bb051e7f8472e703290663e64 Mon Sep 17 00:00:00 2001
From: Michael Rohleder 
Date: Fri, 31 Jul 2020 08:33:43 +0200
Subject: [PATCH] gnu: emacs-guix: Update to latest gitlab version.

* gnu/packages/emacs-xyz.scm (emacs-guix): Update to a 0.5.2 snapshot.
fix https://issues.guix.gnu.org/41063
[source] changes to git-getch.
[snippet] removed.
[native-inputs] added tools to build.
---
 gnu/packages/emacs-xyz.scm | 73 +++---
 1 file changed, 36 insertions(+), 37 deletions(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 04bb534ce7..ba16c84402 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -2566,46 +2566,45 @@ type, for example: packages, buffers, files, etc.")
 (license license:gpl3+)))
 
 (define-public emacs-guix
-  (package
-(name "emacs-guix")
-(version "0.5.2")
-(source (origin
-  (method url-fetch)
-  (uri (string-append "https://emacs-guix.gitlab.io/website/";
-  "releases/emacs-guix-" version ".tar.gz"))
-  (sha256
-   (base32
-"0yz64c0z4ygi2k4af18k4r1ncgys18jb8icywkp2g5pgmpn5l7ps"))
-  (modules '((guix build utils)))
-  (snippet
-   '(begin
-  ;; Add support for Guile 3.0.  Remove for versions > 0.5.2.
-  (substitute* "configure"
-(("\"2\\.2 2\\.0\"")
- "\"3.0 2.2 2.0\""))
-  #t
-(build-system gnu-build-system)
-(native-inputs
- `(("pkg-config" ,pkg-config)
-   ("emacs" ,emacs-minimal)))
-(inputs
- `(("guile" ,@(assoc-ref (package-native-inputs guix) "guile"))
-   ("guix" ,guix)))
-(propagated-inputs
- `(("geiser" ,emacs-geiser)
-   ("guile-gcrypt" ,guile-gcrypt)
-   ("dash" ,emacs-dash)
-   ("bui" ,emacs-bui)
-   ("edit-indirect" ,emacs-edit-indirect)
-   ("magit-popup" ,emacs-magit-popup)))
-(home-page "https://emacs-guix.gitlab.io/website/";)
-(synopsis "Emacs interface for GNU Guix")
-(description
- "Emacs-Guix provides a visual interface, tools and features for the GNU
+  (let ((commit "df1fc5d8885959fd2bb83a443137d21c6850dd74")
+(revision "1"))
+(package
+  (name "emacs-guix")
+  (version (git-version "0.5.2" revision commit))
+  (source (origin
+(method git-fetch)
+(uri (git-reference
+  (url "https://gitlab.com/emacs-guix/emacs-guix";)
+  (commit commit)))
+(file-name (git-file-name name version))
+(sha256
+ (base32
+  "14rn02ay1b8zl0pg54pkqpyzh948c4qiqlvl35627shx7zw5acqh"
+  (build-system gnu-build-system)
+  (native-inputs
+   `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("pkg-config" ,pkg-config)
+ ("texinfo" ,texinfo)
+ ("emacs" ,emacs-minimal)))
+  (inputs
+   `(("guile" ,@(assoc-ref (package-native-inputs guix) "guile"))
+ ("guix" ,guix)))
+  (propagated-inputs
+   `(("geiser" ,emacs-geiser)
+ ("guile-gcrypt" ,guile-gcrypt)
+ ("dash" ,emacs-dash)
+ ("bui" ,emacs-bui)
+ ("edit-indirect" ,emacs-edit-indirect)
+ ("magit-popup" ,emacs-magit-popup)))
+  (home-page "https://emacs-guix.gitlab.io/website/";)
+  (synopsis "Emacs interface for GNU Guix")
+  (description
+   "Emacs-Guix provides a visual interface, tools and features for the GNU
 Guix package manager.  Particularly, it allows you to do various package
 management tasks from Emacs.  To begin with, run @code{M-x guix-about} or
 @code{M-x guix-help} command.")
-(license license:gpl3+)))
+  (license license:gpl3+
 
 (define-public emacs-build-farm
   (package
-- 
2.28.0



signature.asc
Description: PGP signature

bug#42601: Guix install bug: error: Unbound variable: ~S

[Bengt Richter]

Hi,

On +2020-07-30 00:15:56 +0200, Ricardo Wurmus wrote:
> 
> Jan Wielkiewicz  writes:
> 
> > Dnia 2020-07-29, o godz. 22:17:01
> > Ricardo Wurmus  napisał(a):
> >
> >> 
> >> “avr-toolchain” is a procedure, not a package.  Use
> >> “avr-toolchain-4.9” or “avr-toolchain-5”.
> >> 
> >
> > Success!
> >
> > What about the strange message though?
> > "incorrect package definition" would be better.
> 
> “Unbound variable: ~S” looks like a format string with a placeholder
> that didn’t get replaced with an actual value.  It would be marginally
> better if it said “Unbound variable: avr-toolchain”.

I suspect there are also bugs lurking in the exception-reporting chain between
a (throw 'exception args ...) and the ultimate format statement that produces
a message with "~S" in it. Perhaps one got fixed or avoided in the upgrade?

It seems like something must receive a malformed (key . args) pair
where the args don't match the standard(?) tuple expected for the key.

I'd look for dynamic format string generation splitting arg strings
and mistakenly recomposing a format string and args for it, such that
"~S" got placed in the arg list instead of string-appended into the
proper final format.

Just a hunch. IIRC I've seen mangling the final format string and its args
wind up with a mismatch in number of args and interpolation "~s" elements
and if not papered over, that gets reported as a formatting error (which it is,
but which hides the real error).

> 
> We should, I think, take advantage of the fact that the type of inputs
> is known: it can only be an origin or a package value.  Perhaps we can
> catch unbound variables in inputs and print a more valuable error
> message.

I think you are right.
And all implicit meta-data should be seen as potential security vulnerabilities 
IMO :)
Who do you trust to do a reinterpret-cast for you?

> 
> -- 
> Ricardo
> 
> 
> 

-- 
Regards,
Bengt Richter

bug#42423: icedtea: JAVA_HOME

[Michael Rohleder]

Hi Christopher,

Christopher Howard  writes:
> Hi, I'm not going to pretend to be a Java expert, but I was trying to
> build and run a Java application, and had to set JAVA_HOME manually. It
> is my understanding from my research[1] that applications often will
> want JAVA_HOME set to the path to the java install directory. It would
> seem like it would be useful if Guix set that as well for the icedtea
> and icedtea:jdk package.
>
> If there are good reasons for that not to be, perhaps more
> knowledgeable individuals will explain it.
>
> One part I'm not quite sure about is what JAVA_HOME would be set to if
> both icedtea and icedtea:jdk were installed.

I dont think this is a good idea (or even possible?):

From a Developer POV I think its pretty common to have many jdk's installed
(8,11,14 sometimes even 7). To what should JAVA_HOME be set/defaults in this
case?

I dont know a distribution which sets JAVA_HOME (per default) and I
think its much better to let the user or sysadmin decide which one is
best...


signature.asc
Description: PGP signature

bug#41397: xfce4-terminal not reproducible

[Michael Rohleder]

Hi Danny,

I just tried to reproduce this (10 times) but failed (all builds are the
same)
Is this still the case?


signature.asc
Description: PGP signature

bug#42342: Wine64 segfaults (5.12/staging)

[pelzflorian (Florian Pelz)]

On Thu, Jul 30, 2020 at 04:54:45PM +0200, Jakub Kądziołka wrote:
> $ guix environment --ad-hoc wine64 -- wine64 regedit
> 
> fired up the registry editor just fine.


Indeed, when running pure 64-bit applications (like VLC’s 64-bit
Windows build), using wine64 instead of wine works fine.  I did not
even know this command existed.

It seems the issue is only with WoW64, i.e. supporting both 32-bit and
64-bit programs.  The synopsis of wine64 claims it’s a WoW64 version.

For example, the installer of VLC’s 32-bit or 64-bit Windows version
fails to run.  The installer is claimed by binutils’ objdump program
to be a 32-bit i386 executable instead of i386:x86-64.

Regards,
Florian

bug#40834: system-config-printer fails while starting

[Michael Rohleder]

this seems to fix it:

>From 83e8f11687b284bbda73c482434fac0bc0f8f9bf Mon Sep 17 00:00:00 2001
From: Michael Rohleder 
Date: Fri, 31 Jul 2020 15:06:11 +0200
Subject: [PATCH] gnu: system-config-printer: fix for 40834.

* gnu/packages/gnome.scm (system-config-printer): fix 40834.
---
 gnu/packages/gnome.scm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 8f0153f6bf..017fa3647c 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -54,6 +54,7 @@
 ;;; Copyright © 2020 Vinicius Monego 
 ;;; Copyright © 2020 Brice Waegeneire 
 ;;; Copyright © 2020 Arun Isaac 
+;;; Copyright © 2020 Michael Rohleder 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -1988,6 +1989,7 @@ database is translated at Transifex.")
("gobject-introspection" ,gobject-introspection)
("python" ,python)
("cups" ,cups)
+   ("gtk+" ,gtk+)   ; fix http://issues.guix.gnu.org/40834
("python-dbus" ,python-dbus)
("python-pygobject" ,python-pygobject)
("python-pycups" ,python-pycups)
-- 
2.28.0

bug#42632: nextpnr-ice40 fails to compile

[Malte Frank Gerdes]

Hi,

nextpnr-ice40 fails to compile; the error is already resolved upstream
here https://github.com/YosysHQ/nextpnr/issues/373. I built the current
master and it *seems* to be working. I tried:

commit: "b39a2a502065ec1407417ffacdac2154385bf80f"
hash:   "0sgvwmwp9hx62zkdajinif4r3fzc5z71yy1k1fjz3pp8iy290iqg"

Malte

bug#42423: icedtea: JAVA_HOME

[Christopher Howard]

Hi, I am open to learning more and to guix developer wisdom. I don't
quite understand your argument, though — I wouldn't think this would be
any more difficult a question than deciding what version of the java
binary would show up in your profile: you would only select one version
in a profile. If you need to work with multiple versions (not talking
about dependencies) you would create multiple profiles, or multiple
manifest files to use with guix environment.

I would assume if we are talking about guix package dependencies, you
are relying on the direct paths. But practical case here is if you just
download some Java code and run "ant build" or "ant run": that won't
work unless "JAVA_HOME" is defined, which is a bother to figure out
yourself every time you want to update your profile. This is what I
have to do to get arduino-ide running (as well as running patchelf on
the generated binaries, but that is another story...)

-- 
Christopher Howard
p: +1 (907) 374-0257
w: https://librehacker.com
social: https://gnusocial.club/librehacker
gpg: ADDEAADE5D607C8D (keys.gnupg.net)

On Fri, 2020-07-31 at 13:49 +0200, Michael Rohleder wrote:
> Hi Christopher,
> 
> Christopher Howard  writes:
> > Hi, I'm not going to pretend to be a Java expert, but I was trying
> > to
> > build and run a Java application, and had to set JAVA_HOME
> > manually. It
> > is my understanding from my research[1] that applications often
> > will
> > want JAVA_HOME set to the path to the java install directory. It
> > would
> > seem like it would be useful if Guix set that as well for the
> > icedtea
> > and icedtea:jdk package.
> > 
> > If there are good reasons for that not to be, perhaps more
> > knowledgeable individuals will explain it.
> > 
> > One part I'm not quite sure about is what JAVA_HOME would be set to
> > if
> > both icedtea and icedtea:jdk were installed.
> 
> I dont think this is a good idea (or even possible?):
> 
> From a Developer POV I think its pretty common to have many jdk's
> installed
> (8,11,14 sometimes even 7). To what should JAVA_HOME be set/defaults
> in this
> case?
> 
> I dont know a distribution which sets JAVA_HOME (per default) and I
> think its much better to let the user or sysadmin decide which one is
> best...

bug#42162: Recovering source tarballs

[Ludovic Courtès]

Hi Timothy!

Timothy Sample  skribis:

> This jumped out at me because I have been working with compression and
> tarballs for the bootstrapping effort.  I started pulling some threads
> and doing some research, and ended up prototyping an end-to-end solution
> for decomposing a Gzip’d tarball into Gzip metadata, tarball metadata,
> and an SWH directory ID.  It can even put them back together!  :)  There
> are a bunch of problems still, but I think this project is doable in the
> short-term.  I’ve tested 100 arbitrary Gzip’d tarballs from Guix, and
> found and fixed a bunch of little gaffes.  There’s a ton of work to do,
> of course, but here’s another small step.
>
> I call the thing “Disarchive” as in “disassemble a source code archive”.
> You can find it at .  It has a simple
> command-line interface so you can do
>
> $ disarchive save software-1.0.tar.gz
>
> which serializes a disassembled version of “software-1.0.tar.gz” to the
> database (which is just a directory) specified by the “DISARCHIVE_DB”
> environment variable.  Next, you can run
>
> $ disarchive load hash-of-something-in-the-db
>
> which will recover an original file from its metadata (stored in the
> database) and data retrieved from the SWH archive or taken from a cache
> (again, just a directory) specified by “DISARCHIVE_DIRCACHE”.

Wooohoo!  Is it that time of the year when people give presents to one
another?  I can’t believe it.  :-)

> Now some implementation details.  The way I’ve set it up is that all of
> the assembly happens through Guix.  Each step in recreating a compressed
> tarball is a fixed-output derivation: the download from SWH, the
> creation of the tarball, and the compression.  I wanted an easy way to
> build and verify things according to a dependency graph without writing
> any code.  Hi Guix Daemon!  I’m not sure if this is a good long-term
> approach, though.  It could work well for reproducibility, but it might
> be easier to let some external service drive my code as a Guix package.
> Either way, it was an easy way to get started.
>
> For disassembly, it takes a Gzip file (containing a single member) and
> breaks it down like this:
>
> (gzip-member
>   (version 0)
>   (name "hungrycat-0.4.1.tar.gz")
>   (input (sha256
>"1ifzck1b97kjm567qb0prnqag2d01x0v8lghx98w1h2gzwsmxgi1"))
>   (header
> (mtime 0)
> (extra-flags 2)
> (os 3))
>   (footer
> (crc 3863610951)
> (isize 194560))
>   (compressor gnu-best)
>   (digest
> (sha256
>   "03fc1zsrf99lvxa7b4ps6pbi43304wbxh1f6ci4q0vkal370yfwh")))

Awesome.

> The header and footer are read directly from the file.  Finding the
> compressor is harder.  I followed the approach taken by the pristine-tar
> project.  That is, try a bunch of compressors and hope for a match.
> Currently, I have:
>
> • gnu-best
> • gnu-best-rsync
> • gnu
> • gnu-rsync
> • gnu-fast
> • gnu-fast-rsync
> • zlib-best
> • zlib
> • zlib-fast
> • zlib-best-perl
> • zlib-perl
> • zlib-fast-perl
> • gnu-best-rsync-1.4
> • gnu-rsync-1.4
> • gnu-fast-rsync-1.4

I would have used the integers that zlib supports, but I guess that
doesn’t capture this whole gamut of compression setups.  And yeah, it’s
not great that we actually have to try and find the right compression
levels, but there’s no way around it it seems, and as you write, we can
expect a couple of variants to be the most commonly used ones.

> The “input” field likely points to a tarball, which looks like this:
>
> (tarball
>   (version 0)
>   (name "hungrycat-0.4.1.tar")
>   (input (sha256
>"02qg3z5cvq6dkdc0mxz4sami1ys668lddggf7bjhszk23xpfjm5r"))
>   (default-header)
>   (headers
> ((name "hungrycat-0.4.1/")
>  (mode 493)
>  (mtime 1513360022)
>  (chksum 5058)
>  (typeflag 53))
> ((name "hungrycat-0.4.1/configure")
>  (mode 493)
>  (size 130263)
>  (mtime 1513360022)
>  (chksum 6043))
> ...)
>   (padding 3584)
>   (digest
> (sha256
>   "1ifzck1b97kjm567qb0prnqag2d01x0v8lghx98w1h2gzwsmxgi1")))
>
> Originally, I used your code, but I ran into some problems.  Namely,
> real tarballs are not well-behaved.  I wrote new code to keep track of
> subtle things like the formatting of the octal values.

Yeah I guess I was too optimistic.  :-)  I wanted to have the
serialization/deserialization code automatically generated by that
macro, but yeah, it doesn’t capture enough details for real-world
tarballs.

Do you know how frequently you get “weird” tarballs?  I was thinking
about having something that works for plain GNU tar, but it’s even
better to have something that works with “unusual” tarballs!

(BTW the code I posted or the one in Disarchive could perhaps replace
the one in Gash-Utils.  I was frustrated t

bug#26302: Multilingual web site is on-line!

[Ludovic Courtès]

Hi!

"pelzflorian (Florian Pelz)"  skribis:

> On Tue, Jul 28, 2020 at 11:50:13PM +0200, Ludovic Courtès wrote:
>> "pelzflorian (Florian Pelz)"  skribis:
>> > Guix’ website is written in
>> > [SHTML](https://www.nongnu.org/guile-lib/doc/ref/htmlprag/), which is
>> > a variant of HTML (in which web pages are usually written) that
>> 
>> I think it’s technically SXHTML, no?
>> https://www.gnu.org/software/guile/manual/html_node/SXML.html
>
> The result is not valid XHTML.  I will just call it SXML now, which is
> what the Haunt info manual calls it.

OK.

>> I wonder if we should link to more practical step-by-step instructions
>> on how to get started translating, to lower the barrier for those who
>> want to get started without engaging in possibly open-ended discussions
>> with the fabulous Guix team.  :-)
>
> I don’t know how best to integrate step-by-step instructions.  While
> the TP has instructions
> , they seem more
> intimidating to me than, as a first step, talking to the helpful
> people at the TP.  A few steps also describe how to disclaim
> copyright, which Guix does not ask for anyway.

Yeah, dunno.  In the post you could duplicate/filter those steps just so
it’s more directly understandable what it takes to translate pages.
Your call!

> I propose the attached blog post draft if noone objects, taking into
> account Ludo’s helpful suggestions.  Is it missing anything
> interesting about the i18n system?
>
> Should I add it to the website as a draft?  I suppose no, I suppose I
> should just publish it as-is once guix-website.pot is at the TP.

Yes.

> title: Adding translations to Guix’ website
> date: 2020-07-29 15:00
> author: Florian Pelz
> tags: Community

LGTM!  :-)

Ludo’.

bug#42423: icedtea: JAVA_HOME

[Ricardo Wurmus]

Christopher Howard  writes:

> […] This is what I
> have to do to get arduino-ide running (as well as running patchelf on
> the generated binaries, but that is another story...)

Recently, I also built the Arduino IDE to upload the software onto my
Open Theremin.  Instead of using patchelf I opted to make the loader
available globally:

   ln -s $(guix build glibc)/lib/ld-linux-x86-64.so.2 /lib64/

On Guix System we can also use “extra-special-file”:

  (extra-special-file "/lib64/ld-linux-x86-64.so.2"
  (file-append glibc "/lib/ld-linux-x86-64.so.2"))

-- 
Ricardo

bug#41929: Missing root file system in OS leads to backtrace

[Robin Green via web]

test comment

bug#42544: [PATCH]: gnu: services: Make some openvpn options optional to include in the openvpn config file.

[david larsson]

From 5014aa2f455b127deaa013f327dc1cc42d0e1772 Mon Sep 17 00:00:00 2001
From: David Larsson 
Date: Sat, 1 Aug 2020 00:16:02 +0200
Subject: [bug#42544] [PATCH]: gnu: services: Make some openvpn options
 optional to include in the openvpn config file.

* gnu/services/vpn.scm (openvpn-client-configuration) 
(openvpn-server-configuration): Change cert and key options to type 
maybe-string.

---
 gnu/services/vpn.scm | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gnu/services/vpn.scm b/gnu/services/vpn.scm
index 658d5c3e88..6155fd7938 100644
--- a/gnu/services/vpn.scm
+++ b/gnu/services/vpn.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2017 Julien Lepiller 
 ;;; Copyright © 2017 Clément Lassieur 
 ;;; Copyright © 2017 Mathieu Othacehe 
+;;; Copyright © 2020 David Larsson 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -277,12 +278,12 @@ servers.")
 "The certificate authority to check connections against.")

(cert
-(string "/etc/openvpn/client.crt")
+(maybe-string 'disabled)
 "The certificate of the machine the daemon is running on. It should 
be signed

 by the authority given in @code{ca}.")

(key
-(string "/etc/openvpn/client.key")
+(maybe-string 'disabled)
 "The key of the machine the daemon is running on. It must be the 
key whose

 certificate is @code{cert}.")

--
2.18.0