Re: Possible error in the manual?
Nate Bargmann n...@n0nb.us skribis: Reading through the Guix manual I am in section 3.2 Invoking guix package and tried the --show=package option. I receive the following error from Guix: $ guix package --show=emacs guix package error: show=emacs: unrecognized option Running 'guix package --help' indeed shows no option named '--show'. Running 'guix --version' returns guix (GNU Guix) 0.7 ... Could it be that this is actually a pre-0.7 installation? Or perhaps ~/.config/guix/latest points to a pre-0.7 version? This option appeared in 0.7. Does the online Guix manual reflect unreleased features found only in the repository? Or is this a superseded option and the manual is lagging a bit? The on-line manual corresponds to the latest release, currently 0.7. HTH, Ludo’.
Re: problems with guix pull
Carlos Carleos carl...@uniovi.es skribis: Hi! On a Ubuntu system I've tried sudo guix pull --verbose and obtained this ([...] used to shorten the output; warnings and errors left): [...] compiling '/gnu/store/8s2y6886rl6z79axbskyh17xd18xw5cq-guix-latest/gnu/packages/abiword.scm'... [...] compiling '/gnu/store/8s2y6886rl6z79axbskyh17xd18xw5cq-guix-latest/gnu/services/xorg.scm'... compiling '/gnu/store/8s2y6886rl6z79axbskyh17xd18xw5cq-guix-latest/gnu/system.scm'... compiling '/gnu/store/8s2y6886rl6z79axbskyh17xd18xw5cq-guix-latest/gnu/system/file-systems.scm'... compiling '/gnu/store/8s2y6886rl6z79axbskyh17xd18xw5cq-guix-latest/gnu/system/grub.scm'... compiling '/gnu/store/8s2y6886rl6z79axbskyh17xd18xw5cq-guix-latest/gnu/system/install.scm'... ERROR: no code for module (gnu) [...] carleos@carleos:~$ guix --version guix (GNU Guix) 0.6 The old ‘guix pull’ didn’t now about the gnu.scm file, hence the error (this was fixed in June, in commit 9d0b8fbd.) That means you have to actually run ‘guix pull’ from 0.7, or from a recent checkout. The fact that ‘guix pull’ can potentially break for some future version is unfortunate. It would be ideal if instead of using its own build recipe, it would use one from the tarball. I’ll see how this can be fixed. (Cc: bug-guix so the bug is recorded.) Thanks, Ludo’.
Re: Possible error in the manual?
* On 2014 23 Sep 05:09 -0500, Ludovic Courtès wrote: Nate Bargmann n...@n0nb.us skribis: Running 'guix --version' returns guix (GNU Guix) 0.7 ... Could it be that this is actually a pre-0.7 installation? Or perhaps ~/.config/guix/latest points to a pre-0.7 version? This option appeared in 0.7. I double checked and Guix is reporting the version string I quoted above. I don't see pre- shown anywhere. I installed the GNU System from: ftp://alpha.gnu.org/gnu/guix/gnu-usb-install-0.7.i686.xz which is the link (more or less) provided in the online manual. The on-line manual corresponds to the latest release, currently 0.7. Thanks, Ludo. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us
[PATCH] gnu packages maxima: Update to 5.34.1 and fix dependencies
I would like to propose the attached patch for maxima. This updates it to version 5.34.1 which fixes an upstream bug in plot2d and friends. Also it fixes dependencies to gnuplot and tk. In preparing the patch I've observed the following: The build procedure (make) generates some temporary files. When I build the package with guix, guix extracts the program tar.gz archive in the temporary directory /tmp/nix-build-maxima-5.34.1.drv-0 However, maxima attempts to create temporary files in /tmp/nix-build-maxima-5.34.1 and fails. To correct for this I've explicitly passed TMPDIR=/tmp to make. Is this the expected behavior? Regards, Fede From 998303ea042361727837baf38193462148c07565 Mon Sep 17 00:00:00 2001 From: Federico Beffa be...@fbengineering.ch Date: Tue, 23 Sep 2014 16:20:02 +0200 Subject: [PATCH] gnu packages maxima: Update to 5.34.1 and fix dependencies * gnu/packages/maths.scm(maxima): Update to 5.34.1 which fixes a bug in the plotting capabilities (plot2d, ...) present in the previous version (5.33.0). Add the 'gnuplot' depencency which is required to generate plots. Add 'tcl' and 'tk' as dependencies: they are required by the 'xmaxima' command. --- gnu/packages/maths.scm | 33 - 1 file changed, 24 insertions(+), 9 deletions(-) diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm index af9feff..0321929 100644 --- a/gnu/packages/maths.scm +++ b/gnu/packages/maths.scm @@ -58,6 +58,7 @@ #:use-module (gnu packages python) #:use-module (gnu packages readline) #:use-module (gnu packages tcsh) + #:use-module (gnu packages tcl) #:use-module (gnu packages texinfo) #:use-module (gnu packages texlive) #:use-module (gnu packages xml)) @@ -836,7 +837,7 @@ to BMP, JPEG or PNG image formats.) (define-public maxima (package (name maxima) -(version 5.33.0) +(version 5.34.1) (source (origin (method url-fetch) @@ -844,19 +845,33 @@ to BMP, JPEG or PNG image formats.) version -source/ name - version .tar.gz)) (sha256 (base32 - 13axm11xw0f3frx5b0qdidi7igkn1524fzz77s9rbpl2yy2nrbz2 + 1dw9vfzldpj7lv303xbw0wpyn6ra6i2yzwlrjbcx7j0jm5n43ji0 (build-system gnu-build-system) -(arguments - `(#:phases (alist-cons-before - 'check 'pre-check - (lambda _ - (chmod src/maxima #o555)) - %standard-phases))) (inputs - `((gcl ,gcl))) + `((gcl ,gcl) + (gnuplot ,gnuplot) + (tcl ,tcl) + (tk ,tk))) (native-inputs `((texinfo ,texinfo) (perl ,perl))) +(arguments + `(#:configure-flags + (list --enable-gcl + (string-append --with-posix-shell= + (assoc-ref %build-inputs bash) + /bin/sh) + (string-append --with-wish= + (assoc-ref %build-inputs tk) + /bin/wish + (let ((v ,(package-version tk))) + (string-take v (string-index-right v #\.) + #:make-flags (list TMPDIR=/tmp) + #:phases (alist-cons-before + 'check 'pre-check + (lambda _ + (chmod src/maxima #o555)) + %standard-phases))) (home-page http://maxima.sourceforge.net;) (synopsis Numeric and symbolic expression manipulation) (description Maxima is a system for the manipulation of symbolic and -- 1.8.4
installing a modified package
Hi! I know I should be RTFM carefully, but... In Debian, I can follow these steps to customize a package (more or less): 1. # apt-get build-dep PACKAGE 2. $ apt-get source PACKAGE 3. $ cd PACKAGE-...; ...tweak...; dpkg-buildpackage... 4. # dpkg -i PACKAGE.deb What would be the similar sequence for GUIX? Thank you very much. -- CARLOS CARLEOSKAROLO EL KARLEOJ Secretario Sekretario Departamento de Estadística Departemento pri Statistiko e Investigación Operativakaj Operaciesploro y Didáctica de la Matemáticakaj Didaktiko de Matematiko Universidad Oviedo Universitato Oviedo Principado de Asturias Princlando Asturujo Reino de España Reĝlando Hispanujo Teléfono: 73353 SMS: +34 66 004 66 05 _ El cibercorreo no es SMS: dispone de |Retpoŝto malsamas ol SMS: - espacio suficiente| - sufiĉas spaco - comodidades adecuadas | - taŭgas komfortaĵoj para expresarse correctamente. |por ĝuste sin esprimi.
Re: installing a modified package
Carlos Carleos asked: What would be the similar sequence for GUIX? Edit the package definition as appropriate to accomplish what you need to do? Make a new package definition that uses the old one as an input with whatever changes are needed? If the changes you're making would be generally useful it might also be a good idea to share them so that they can be included. signature.asc Description: PGP signature
Re: installing a modified package
2014-09-23 12:51 GMT-04:00 Carlos Carleos carl...@uniovi.es: Hi! I know I should be RTFM carefully, but... In Debian, I can follow these steps to customize a package (more or less): 1. # apt-get build-dep PACKAGE 2. $ apt-get source PACKAGE 3. $ cd PACKAGE-...; ...tweak...; dpkg-buildpackage... 4. # dpkg -i PACKAGE.deb What would be the similar sequence for GUIX? Thank you very much. Since packages are Scheme expressions, you can simpley create a new package object that inherits from the package you want to modify. Untested code below: (use-modules (guix packages) (gnu packages emacs)) (package (inherit emacs) ...) To install, I believe you need to use something like: guix package -e '(load my-custom-emacs.scm)' Where my-custom-emacs.scm is a file that contains the code above. Having the 'package' form at the end of the file makes it the return value of 'load'. I'm writing this hastily, but I hope this helps. - Dave
Re: GSettings schemas
l...@gnu.org (Ludovic Courtès) writes: Federico Beffa be...@ieee.org skribis: I've found that setting the environment variable GSETTINGS_SCHEMA_DIR solves the problem. $ GSETTINGS_SCHEMA_DIR=/gnu/store/5shj344c9vrh4fx93r9lfjjrrr97fmjv-gtk+-3.10.1/share/glib-2.0/schemas emacs Can the schema location be fixed at configure/compile time? We could use ‘wrap-program’ to set that variable for Emacs, but we need to address that problem more generally. This 'wrap-program' strategy of setting environment variables before running a program has problems. In this case, it means that every program run within Emacs will inherit that GSETTINGS_SCHEMA_DIR value. Along the same lines, I've noticed that when running WindowMaker, all of the programs within my X session include a WindowMaker-specific directory at the front of PATH. It would be good to find another solution. Mark
Re: Possible error in the manual?
* On 2014 23 Sep 07:22 -0500, Ludovic Courtès wrote: Be aware that version X or Guix cannot contains a package of Guix version X. So Guix 0.7 actually comes with a pre-0.7 snapshot. This should be visible in the directory name in: readlink $(type -P guix) Embedded in the returned string is 'guix-0.6.0-'. I do recall seeing that reference during the installation and wondering why the previous version would be downloaded. Now I know. To get a newer Guix, it should be enough to run ‘guix pull’. That should give you the ‘--show’ options and lots of other bleeding-edge things. ;-) Thanks, I will try that. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us
Re: [PATCH] emacs: Rewrite scheme side in a functional manner.
Ludovic Courtès (2014-09-21 23:27 +0400) wrote: Alex Kost alez...@gmail.com skribis: Ludovic Courtès (2014-09-20 18:11 +0400) wrote: [...] Overall it looks OK. I’m concerned with code duplication between emacs/ and guix/, though, and there are also a few stylistic issues, and missing or terse docstrings. I don't understand what duplication you mean. I was thinking about things generic enough to be in (guix profiles), things that ‘guix package’ or guix-web could use. That said, it’s also fine do to things incrementally: write things specifically for guix.el’s need, and generalize them later when we have a clearer understanding of the situation. I just thought it’s worth keeping in mind. Thanks, I keep it in mind. Such incremental approach is the only way I can write code. I'm not able to construct a proper thing from the very beginning: I always make big changes when something new is added and I notice that a new wave of generalization is required. [...] We discussed using vhash, but I don't see how it can replace hash table. Here is the excerpt from the earlier message: Right, I remember that. My point was just that either this optimization is not strictly needed, or it could go in (guix profiles), whether it uses a vhash or a hash table actually. But I think we actually agree on that, so that can still be addressed at a later stage. Thanks. [...] To get information about packages/outputs, different “search-types” are used (like ‘name’, ‘all-available’, ‘installed’). These “search-types + search-vals” are transformed into a list of package/output patterns. Package patterns are: - package record; - list of name, version; - list of name, version, manifest entries; - list of name, version, manifest entries, packages. Oh, OK. Do remove any ambiguity, an option would be to call them “matches”, “search results”, “descriptors”, or “specifications”, perhaps. WDYT? (Maybe this is just bikeshedding, so your call.) I leave a “pattern” name for now. Output patterns are: - package record; - list of package record, output; - manifest entry record; - list of manifest entry record, packages; - list of name, version, output. Then these patterns are transformed into entries (alists with parameters/values) using “pattern-entries” functions created by ‘package-pattern-transformer’ and ‘output-pattern-transformer’. What about s/entries/sexps/? That would make it clearer that the intent is to serialize things, not to manipulate them internally. Yes, it is better, thanks. I settled to “sexp” for this thing. +(define (get-package/output-entries profile params entry-type +search-type search-vals) + Return list of package or output entries. Never ‘get’. Do you mean I need to remove get- from the procedures' names? Yes. Done. [...] The docstring is too terse. The concept of entry is too common for the code in “guix-main.scm” to write about it in every docstring. Yes, but still: there are 5 parameters. I can tell what ‘profile’ is, but I have no clear idea about the type and meaning of the others at first glance. Presumably ‘search-type’ and ‘entry-type’ are symbols, but then that still leaves a lot to be found out. I improved some docstrings. [...] Thanks for all your recommendations, I tried to follow them. I'm attaching the improved patch. Is it good enough now? From f93af8a3a0b4d119a0e7ff23ce81bc7b28a31b60 Mon Sep 17 00:00:00 2001 From: Alex Kost alez...@gmail.com Date: Thu, 18 Sep 2014 16:24:02 +0400 Subject: [PATCH 1/2] emacs: Rewrite scheme side in a functional manner. * emacs/guix-main.scm: Rewrite in a functional way. Add support for output entries. (%current-manifest, %current-manifest-entries-table, set-current-manifest-maybe!): Replace with... (manifest-entries-hash-table, manifest-hash-table): ... this. (manifest-entries-by-name+version): Replace with... (manifest-entries-by-name): ... this. (fold-manifest-entries): Rename to... (fold-manifest-by-name): ... this. (package-installed-param-alist): Rename to... (%manifest-entry-param-alist): ... this. (package-param-alist): Rename to... (%package-param-alist): this. (manifest-entry-installed-entry): Rename to... (manifest-entry-sexp): ... this. (manifest-entries-installed-entries): Rename to... (manifest-entries-sexps): ... this. (matching-generation-entries): Replace with... (matching-generations): ... this. (last-generation-entries): Replace with... (last-generations): ... this. (get-entries): Rename to... (entries): ... this. (installed-entries-by-name+version, installed-entries-by-package, matching-package-entries, fold-object, package-entries-by-name+version, package-entries-by-spec, package-entries-by-regexp, package-entries-by-ids, newest-available-package-entries, all-available-package-entries, manifest-package-entries, installed-package-entries,
Re: guix.el multiple outputs
Ludovic Courtès (2014-09-21 23:37 +0400) wrote: Alex Kost alez...@gmail.com skribis: Ludovic Courtès (2014-09-07 01:11 +0400) wrote: Taylan Ulrich Bayirli/Kammer taylanbayi...@gmail.com skribis: By the way, it might be nice to have an option to list the secondary outputs of a package explicitly alongside the normal, as if it were just another package. Currently *Guix Package List* shows, for instance: gcc-toolchain4.9.1 out, debugdebug, outComplete GCC tool chain for C/C++ development Are you suggesting that it should instead show it as two lines? gcc-toolchain4.9.1 out yes Complete GCC tool chain for C/C++ development gcc-toolchain4.9.1 debugyes Complete GCC tool chain for C/C++ development I think I would prefer it. (One advantage is that it would allow users to mark just one specific output, which is not currently possible.) [...] As for the changes visible to a user: now it is possible to get a list of outputs with “(setq guix-package-list-type 'output)”. Should it be default? The list of outputs means there’s one line for each output, as in the example above, right? Yes. I would make it the default, yes. OK, I made it the default option. Another UI question: RET in “*Guix Package List*” buffer describes current package(s) in “*Guix Package Info*” buffer. Analogously, RET in “*Guix Output List*” buffer describes current output(s) in “*Guix Output Info*” buffer. However I think it's not very useful: “output-info” buffer is very similar to “package-info” but it contains only one output per package info. So I think it would be better to display a usual “package-info” buffer (with all available outputs for a package) when a user press RET in a list of outputs. [not a clear description, isn't it :-)] WDYT? I would prefer having just *Guix Package List* and *Guix Package Info* (each listing all the outputs of packages), and not *Guix Output List* and *Guix Output Info*. Would it be possible? Absolutely. [...] I think this convinced me that it’s better to just have the ‘package-info’ and the ‘package-list’ buffer do the right thing. The added complexity above may be intimidating to users. Yes, you are right that defaults should be more user friendly :-) I've made appropriate changes, so now the only difference a user will see in the new version is that there are outputs (not packages) listed in *Guix Package List* buffer. And to return to the previous variant, one may use (it is documented): (setq guix-package-list-type 'package) A modified patch is attached. From 794096c19f2c702ad75c6c598c9c8312e66f0c84 Mon Sep 17 00:00:00 2001 From: Alex Kost alez...@gmail.com Date: Fri, 19 Sep 2014 09:57:36 +0400 Subject: [PATCH 2/2] emacs: Add support for displaying outputs. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Suggested by Taylan Ulrich Bayirli/Kammer and Ludovic Courtès. * emacs/guix-base.el (guix-param-titles): Add output titles. (guix-messages): Add output messages. (guix-get-package-id-and-output-by-output-id): New procedure. (guix-define-buffer-type): Add ':buffer-name' key. * emacs/guix-info.el: Add output-info buffer type. (guix-info-insert-methods): Add output methods. (guix-info-displayed-params): Add output params. (guix-output-info-insert-version, guix-output-info-insert-output): New procedures. * emacs/guix-list.el: Add output-list buffer type. (guix-list-column-format): Add output formats. (guix-list-column-value-methods): Add output methods. (guix-package-list-type): New variable. (guix-generation-list-show-packages): Use it. (guix-package-list-marking-check): Use 'guix-output-list-mode'. (guix-list-mark-package-upgrades): New procedure. (guix-package-list-mark-upgrades): Use it. (guix-list-execute-package-actions): New procedure. (guix-package-list-execute): Use it. (guix-list-describe-maybe): New procedure. (guix-list-describe): Use it. (guix-output-list-mark-install, guix-output-list-mark-delete, guix-output-list-mark-upgrade, guix-output-list-mark-upgrades, guix-output-list-execute, guix-output-list-make-action, guix-output-list-describe): New procedures. (guix-output-list-describe-type): New variable. * emacs/guix.el (guix-get-show-packages): Use 'guix-package-list-type'. * doc/emacs.texi (emacs Commands): Mention 'guix-package-list-type'. (emacs List buffer): Adjust accordingly. (emacs Info buffer): Likewise. (emacs Buffer Names): New node. (emacs Keymaps): Add keymaps for output buffers. --- doc/emacs.texi | 59 +++--- emacs/guix-base.el | 69 +++-- emacs/guix-info.el | 54 +++- emacs/guix-list.el | 176 ++--- emacs/guix.el | 12 ++-- 5 files changed, 329 insertions(+), 41 deletions(-) diff --git a/doc/emacs.texi b/doc/emacs.texi index
Re: Long-term Release Kernels
Jason Self ja...@bluehome.net writes: I was wondering what people though about whether or not there should also be a long-term release kernel package (see the longterm section at [0]) in addition to the current one which always tracks the latest version? Yes, I think we should have this. Mark
