Re: installing a modified package
Carlos Carleos writes: > 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. IMO, the best approach is to clone the Guix git repo, create your own private branch with your preferred modifications, and periodically merge or rebase with Guix upstream. When running Guix directly from the git repo, there's no need to run "make install", instead prefix commands with /path/to/guix-git-working-dir/pre-inst-env. I also put a shell script in ~/bin/guix that does: /path/to/guix/pre-inst-env guix "$@" Since Guix aims to create reproducable builds, we do not support a mode where you first unpack a source tree, tweak things by hand, and then build it right there. Instead, as Jason said, you need to edit the package definition in gnu/packages/*.scm (guix package -A tells you where). In some cases, you might simply change the configure flags or build inputs. Other times you might need to add a patch to gnu/packages/patches/* and add it to 'patches' in the 'origin' of the package (search for 'search-patch' in gnu/packages/*.scm for examples). For patching, I usually start by unpacking the source plus existing Guix patches using "tar xf $(guix build -S )". To test your modified package, run "make" in the top-level source directory, then "./pre-inst-env guix build -K ", and if it succeeds, you can install it in your profile with "./pre-inst-env guix package -i ". Does this work for you? Mark
Re: Long-term Release Kernels
"Jason Self" 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
Re: guix.el & multiple outputs
Ludovic Courtès (2014-09-21 23:37 +0400) wrote: > Alex Kost skribis: > >> Ludovic Courtès (2014-09-07 01:11 +0400) wrote: >> >>> Taylan Ulrich Bayirli/Kammer 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 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
Re: [PATCH] emacs: Rewrite scheme side in a functional manner.
Ludovic Courtès (2014-09-21 23:27 +0400) wrote: > Alex Kost 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 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-
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: GSettings schemas
l...@gnu.org (Ludovic Courtès) writes: > Federico Beffa 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: installing a modified package
2014-09-23 12:51 GMT-04:00 Carlos Carleos : > > 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: 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
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.
[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 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
Re: Possible error in the manual?
Nate Bargmann skribis: > * On 2014 23 Sep 05:09 -0500, Ludovic Courtès wrote: >> Nate Bargmann 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. Actually it always shows the future version number, so it cannot really be relied on. > I installed the GNU System from: > > ftp://alpha.gnu.org/gnu/guix/gnu-usb-install-0.7.i686.xz 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) 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. ;-) Ludo’.
Re: Possible error in the manual?
* On 2014 23 Sep 05:09 -0500, Ludovic Courtès wrote: > Nate Bargmann 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
Re: problems with "guix pull"
Carlos Carleos 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?
Nate Bargmann 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’.