Timezone problems
Hello all, I'm running into issues whereby the 'date' command that is part of the coreutils package (installed through guix) returns non-timezone corrected values (i.e. it returns UTC even for local time). I suspect this was to do with the locale complications of the earlier gcc version that was part of guix, and that locale issue seems to be resolved now: Guile 2.0.9 compiled with the new gcc does not complain about locale settings anymore. Would guix normally have recompiled coreutils following the gcc upgrade too? If so then the problem must be something else — but the date program invoked through /bin/date returns the correct local time (installed through aptitude), so it seems guix specific. If not — is there a way to force re-installation from scratch for just coreutils? Best wishes, Alex
Re: 'python-build-system'
Nikita Karetnikov nik...@karetnikov.org skribis: With these changes in place, OK to commit. I've just pushed both patches. Please have a look. To answer your previous question, this ‘wrap’ phase serves a different (but related) purpose than the ‘native-search-paths’ thing: it ensures that the ‘bzr’ program, when run by the user, finds all its Python modules. I know. But why do we need to use 'native-search-paths' to set PYTHONPATH if we wrap all executables anyway? What is the purpose of 'native-search-paths' in this case? Not all Python packages have binaries, and when they do, they can often be used either as stand-alone binaries or as Python modules. Does that clarify? Ludo’.
Re: Timezone problems
Alex Sassmannshausen alex.sassmannshau...@gmail.com skribis: I'm running into issues whereby the 'date' command that is part of the coreutils package (installed through guix) returns non-timezone corrected values (i.e. it returns UTC even for local time). Actually you first need to install the ‘tzdata’ package (which I just added yesterday!). Then you must set the TZDIR environment variable to point to it, like this: export TZDIR=$HOME/.guix-profile/share/zoneinfo The C library (the one from Guix) will then get timezone info from there. I suspect this was to do with the locale complications of the earlier gcc version that was part of guix, and that locale issue seems to be resolved now: Guile 2.0.9 compiled with the new gcc does not complain about locale settings anymore. This is actually unrelated but yes, this one’s fixed too. Would guix normally have recompiled coreutils following the gcc upgrade too? If so then the problem must be something else — but the date program invoked through /bin/date returns the correct local time (installed through aptitude), so it seems guix specific. If not — is there a way to force re-installation from scratch for just coreutils? What matters most is what’s in your profile. I just run ‘guix package --upgrade’, which atomically upgrades everything that’s installed in your profile (so you get the new Coreutils, and everything linked against the new libc.) HTH! Ludo’.
Re: Literate programming
I wouldn’t want to automatically extract command-line doc. First,
because --help needs to be concise, whereas the manual can give
additional details (compare ‘guix package --help’ and “Invoking guix
packages”.) Second, because the manual should include cross-references
and examples to make things more understandable.
Here is how I see the process: one creates a command-line tool and uses
Commentary to document it. Then the person should manually @include the
output of extracted and converted Commentary (e.g., 'filename.texi'),
which isn't created at this point. After that it's only necessary to
run 'make' to compile 'filename.texi' and 'guix.texi'. (Note that it's
possible to use cross-references.)
I've created a rough example. 'doc/hash-texi.scm' shows how to extract
and convert Commentary. The same thing should be done for all scripts.
So each 'file.scm' should have a corresponding 'file.texi'. Other files
in 'guix' will need a different extraction scheme because it's necessary
to get docstrings as well. I'd like to write a couple of procedures and
put them into a makefile. Still, it'll be necessary to @include files
manually.
I guess this sounds like a lot of work, but the same approach is also
used with LaTeX [1]. You have a main file, a style file, and other files
which will be included into the main file.
I'd also like to find a way to automatically create a table of contents.
[1] https://en.wikibooks.org/wiki/LaTeX/Modular_Documents
diff --git a/doc/guix.texi b/doc/guix.texi
index 9147f43..17f7e14 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1214,36 +1214,7 @@ the @code{package-derivation} procedure of the @code{(guix packages)}
module, and to the @code{build-derivations} procedure of the @code{(guix
store)} module.
-@node Invoking guix hash
-@section Invoking @command{guix hash}
-
-The @command{guix hash} command allows to check the integrity of a file.
-It is primarily a convenience tool for anyone contributing to the
-distribution: it computes the cryptographic hash of a file, which can be
-used in the definition of a package (@pxref{Defining Packages}).
-
-The general syntax is:
-
-@example
-guix hash @var{option} @var{file}
-@end example
-
-@command{guix hash} has the following option:
-
-@table @code
-
-@item --format=@var{fmt}
-@itemx -f @var{fmt}
-Write the hash in the given format.
-
-Supported formats: @code{nix-base32}, @code{base32}, @code{base16}
-(@code{hex} and @code{hexadecimal} can be used as well).
-
-If the @option{--format} option is not specified, @command{guix hash}
-will output the hash in @code{nix-base32}. This representation is used
-in the definitions of packages.
-
-@end table
+@include hash.texi
@node Invoking guix refresh
@section Invoking @command{guix refresh}
diff --git a/doc/hash-texi.scm b/doc/hash-texi.scm
new file mode 100644
index 000..801f92f
--- /dev/null
+++ b/doc/hash-texi.scm
@@ -0,0 +1,29 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2013 Nikita Karetnikov nik...@karetnikov.org
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix 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.
+;;;
+;;; GNU Guix 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 GNU Guix. If not, see http://www.gnu.org/licenses/.
+
+(use-modules (texinfo serialize)
+ (ice-9 session))
+
+;; 'string-stexi' and 'module-commentary' are used instead of
+;; 'module-stexi-documentation' because we do not want to mention 'guix-hash'
+;; and the names of sections.
+(call-with-output-file doc/hash.texi
+ (lambda (out)
+(format out ~a~%
+(stexi-texi ((@@ (texinfo reflection) string-stexi)
+ (module-commentary '(guix scripts hash)))
\ No newline at end of file
diff --git a/doc/hash.texi b/doc/hash.texi
new file mode 100644
index 000..a6469da
--- /dev/null
+++ b/doc/hash.texi
@@ -0,0 +1,35 @@
+
+@c %start of fragment
+
+@node Invoking guix hash
+@section Invoking @command{guix hash}
+The @command{guix hash} command allows to check the integrity of a file.
+It is primarily a convenience tool for anyone contributing to the
+distribution: it computes the cryptographic hash of a file, which can be
+used in the definition of a package (@pxref{Defining Packages}).
+
+The general syntax is:
+
+@example
+ guix hash @var{option} @var{file}
+@end example
+
+@command{guix hash} has the following option:
+
+@table @code
+@item --format=@var{fmt}
+@itemx -f @var{fmt}
+Write the hash in the given format.
+
Re: New “guix refresh” command
Objects aren’t malicious. Perhaps you’re talking about situations where a mirror provides a tarball along with a valid signature, but said signature is made with a random key, and the tarball is actually not genuine, right? Yep. Second, this is the same model as used by the OpenSSH client. When the client is first introduced to a host, it presents you its key fingerprint, you type ‘y’, and that key gets added to your known hosts file. From there on, person-in-the-middle attacks are trivially detected as a key mismatch. AFAICT, 'guix refresh' doesn't allow to check fingerprints. If so, we must change it. Am I mistaken? I'm not sure because it fails on my machine: # ./pre-inst-env guix refresh -u [...] In execlp of gpg2: No such file or directory guix refresh: warning: signature verification failed for `guile-2.0.9.tar.gz' guix refresh: warning: (could be because the public key is not in your keyring) gnu/packages/guile.scm:48:12: guile: updating from version 1.8.8 to version 2.0.9... Backtrace: In ice-9/boot-9.scm: 157: 12 [catch #t #catch-closure 954b170 ...] In unknown file: ?: 11 [apply-smob/1 #catch-closure 954b170] In ice-9/boot-9.scm: 63: 10 [call-with-prompt prompt0 ...] In ice-9/eval.scm: 432: 9 [eval # #] In ice-9/boot-9.scm: 2320: 8 [save-module-excursion #procedure 93f9e80 at ice-9/boot-9.scm:3961:3 ()] 3966: 7 [#procedure 93f9e80 at ice-9/boot-9.scm:3961:3 ()] In unknown file: ?: 6 [load-compiled/vm /root/.cache/guile/ccache/2.0-LE-4-2.0/home/guix-test2/scripts/guix.go] In guix/ui.scm: 417: 5 [guix-main /home/guix-test2/scripts/guix refresh -u] In ice-9/boot-9.scm: 157: 4 [catch srfi-34 #procedure 9858520 at guix/ui.scm:138:2 () ...] In srfi/srfi-1.scm: 619: 3 [for-each #procedure 98580e0 at guix/scripts/refresh.scm:151:22 (package) ...] In guix/scripts/refresh.scm: 167: 2 [#procedure 98580e0 at guix/scripts/refresh.scm:151:22 (package) #] In ice-9/boot-9.scm: 788: 1 [call-with-input-file #f ...] In unknown file: ?: 0 [open-file #f r #:encoding #f #:guess-encoding #f] ERROR: In procedure open-file: ERROR: Wrong type (expecting string): #f It’s exactly what I would do manually. What about you? It depends. I usually use a similar page [1] to compare fingerprints and also check via keys.gnupg.net. Sometimes I try to get more information elsewhere. Again, the sad truth is that it's easier not to sign an ingenuine tarball at all. Is it possible to use three mirrors to check keys and tarballs? Check against what? What do you want to address? Check them against each other. But it's not the case because 'guix refresh' uses one server per package. I’ve made this suggestion to one of the FSF sysadmins, but it seems to need further discussion, and probably input from crypto-savvy people. OK. [1] http://gcc.gnu.org/mirrors.html pgpcwwBzmDSzj.pgp Description: PGP signature
