Re: Synchronizing descriptions with GSRC?
Nikita Karetnikov nik...@karetnikov.org skribis: That sounds fine then. I was probably being overly cautious. I share your concerns. Could you ask the FSF? Could you be more specific about what your concerns are? AFAIK most GNU web pages where we/I took summaries from at copyright FSF, to start with. Of course I’m all in favor of clarifying any issues that could exist, and I’m all ears for advice on that. Now, saying that this might “spoil years of work” is clearly an overstatement. When I asked Karl about this some time ago, he wasn’t concerned, even wondering whether a descriptive paragraph like these could be subject to copyright. Thanks, Ludo’.
'substitute*' fails with string contains #\nul character (was: 'patchelf' doesn't change shared libraries)
'substitute*' fails to patch a binary and returns the following error [...] starting phase `pre-configure' Backtrace: In ice-9/boot-9.scm: 2320: 19 [save-module-excursion #procedure 8e81de0 at ice-9/boot-9.scm:3961:3 ()] 3966: 18 [#procedure 8e81de0 at ice-9/boot-9.scm:3961:3 ()] 1645: 17 [%start-stack load-stack ...] 1650: 16 [#procedure 8e84df8 ()] In unknown file: ?: 15 [primitive-load /nix/store/rcjkvdqp28dnp7igksnf3lzgwzxqvadb-ghc-bin-7.0.1-guile-builder] In ice-9/eval.scm: 387: 14 [eval # ()] In srfi/srfi-1.scm: 830: 13 [every1 #procedure 9090f10 at /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/gnu-build-system.scm:364:9 (expr) ...] In /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/gnu-build-system.scm: 368: 12 [#procedure 9090f10 at /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/gnu-build-system.scm:364:9 (expr) #] In ice-9/eval.scm: 432: 11 [eval # #] In srfi/srfi-1.scm: 616: 10 [for-each #procedure 9097a98 at ice-9/eval.scm:416:20 (a) #] In ice-9/boot-9.scm: 171: 9 [with-throw-handler #t ...] 793: 8 [call-with-input-file inplace/bin/ghc-cabal ...] In /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/utils.scm: 336: 7 [#procedure 908b4e0 at /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/utils.scm:335:10 (in) #input: inplace/bin/ghc-cabal 11] 361: 6 [#procedure 9320fc0 at /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/utils.scm:357:6 (in out) #input: inplace/bin/ghc-cabal 11 ...] In srfi/srfi-1.scm: 465: 5 [fold #procedure 9026f40 at /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/utils.scm:361:32 (r+p line) ...] In /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/utils.scm: 364: 4 [#procedure 9026f40 at /nix/store/04z6assixr4ms2fmvm2m42aw1a8k07x5-module-import/guix/build/utils.scm:361:32 (r+p line) # ...] In ice-9/regex.scm: 189: 3 [list-matches # ...] 176: 2 [fold-matches # ...] In unknown file: ?: 1 [regexp-exec # ...] In ice-9/boot-9.scm: 106: 0 [#procedure 908b500 at ice-9/boot-9.scm:97:6 (thrown-k . args) misc-error ...] ice-9/boot-9.scm:106:20: In procedure #procedure 908b500 at ice-9/boot-9.scm:97:6 (thrown-k . args): ice-9/boot-9.scm:106:20: string contains #\nul character: [...] diff --git a/gnu/packages/ghc.scm b/gnu/packages/ghc.scm new file mode 100644 index 000..1a3d308 --- /dev/null +++ b/gnu/packages/ghc.scm @@ -0,0 +1,114 @@ +;;; 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/. + +(define-module (gnu packages ghc) + #:use-module ((guix licenses) #:select (bsd-style)) + #:use-module (guix packages) + #:use-module (guix download) + #:use-module (guix build-system gnu) + #:use-module (gnu packages base) + #:use-module (gnu packages bootstrap) + #:use-module (gnu packages libffi) + #:use-module (gnu packages multiprecision) + #:use-module (gnu packages ncurses) + #:use-module (gnu packages patchelf) + #:use-module (gnu packages perl)) + +(define-public ghc-7.0.1-bin + (package +(name ghc-bin) +;; 7.0.2--7.6.3 +(version 7.0.1) +(source + (origin + (method url-fetch) + ;; XXX: Support other platforms. + (uri (string-append http://www.haskell.org/ghc/dist/; + version /ghc- version + -i386-unknown-linux.tar.bz2)) + (sha256 + (base32 +1cc9ih3h804gj53vf1xabg4155m6bz5r468mjsv54kckmabgsmav +(build-system gnu-build-system) +(arguments + `(#:modules ((guix build gnu-build-system) + (guix build utils) + (srfi srfi-1)) + #:phases (alist-cons-before + 'configure 'pre-configure + (lambda _ + (let ((gmp (string-append (assoc-ref %build-inputs gmp) + /lib)) + (linker (string-append + (assoc-ref %build-inputs libc) + ,(glibc-dynamic-linker))) + (libffi (string-append + (assoc-ref %build-inputs libffi) +
GNU Guix 0.3 released
We are pleased to announce GNU Guix version 0.3, the third alpha release, representing 254 commits by 6 people over 2 months. • About GNU Guix is a functional package manager and distribution of the GNU system. In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. Guix uses low-level mechanisms from the Nix package manager, with Guile Scheme programming interfaces. At this stage Guix can be used on top of an i686 or x86_64 GNU/Linux system. Future versions will stand alone. http://www.gnu.org/software/guix/ • Download Here are the compressed sources and a GPG detached signature[*]: ftp://alpha.gnu.org/gnu/guix/guix-0.3.tar.gz ftp://alpha.gnu.org/gnu/guix/guix-0.3.tar.gz.sig Use a mirror for higher download bandwidth: http://www.gnu.org/order/ftp.html Here are the MD5 and SHA1 checksums: 1112e55273ce47cb89ccbdedb2d431f6 guix-0.3.tar.gz 6a3f3c469a8a6bb5316f632a54ffb5df97d3911a guix-0.3.tar.gz [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify guix-0.3.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys EA52ECF4 and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.14 Makeinfo 5.1 Guix users can upgrade by running “guix pull”. • Changes since version 0.2 (excerpt from the NEWS file) ** Package management *** Cross-compilation support Guix can now cross-build packages. On the command-line, this is achieved with the new ‘--target’ command-line option of ‘guix build’. At the Scheme level, the guts of this is the ‘package-cross-derivation’ procedure. Core packages of the distribution can already be cross-compiled. See the manual for details. *** New ‘--max-silent-time’ option for “guix build” and “guix package” See the manual for details. *** New ‘--fallback’ option for “guix build” and “guix package” This option instructs to fall back to local builds when the substituter fails to download a substitute. *** New ‘--requisites’ option for “guix gc” See the manual for details. *** New ‘--key-download’ option for “guix refresh” See the manual for details. ** Programming interfaces *** New ‘package-cross-derivation’ procedure in (guix derivations) See the manual for details. *** New ‘%current-target-system’ SRFI-39 parameter This parameter is like ‘%current-system’, but for cross-compilation. It allows code in package definitions (such as in the ‘arguments’ field) to know whether it is being cross-compiled, and what the target system is. *** New (guix hash) module; new ‘open-sha256-port’ and ‘sha256-port’ procedures This improves performance of SHA256 computations. ** GNU distribution *** 33 new packages alsa-lib, babel, cairo, cvs, gcal, gcc-cross-mips64el-linux-gnuabi64, gd, gdk-pixbuf, graphviz, grue-hunter, gtk+, gts, harfbuzz, imagemagick, iproute2, iptables, libspectre, mpg321, noweb, pango, plotutils, privoxy, pytz, racket, rubber, rush, strace, tk, torsocks, unrtf, vc-dwim, wordnet, xlockmore *** 25 package updates automake 1.14, ed 1.9, freeipmi 1.2.8, gawk 4.1.0, gcc 4.8.1, gettext 0.18.3, glib 2.37.1, gmp 5.1.2, gnutls 3.2.1, gzip 1.6, help2man 1.43.3, libapr 1.4.8, libaprutil 1.5.2, libassuan 2.1.1, libffi 3.0.13, libgc 7.2d, libgpg-error 1.12, libidn 1.28, libpng 1.5.17, lout 3.40, lsh 2.1, nettle 2.7.1, qemu 1.5.1, tzdata 2013d, xorriso 1.3.0 *** Binary packages now available for i686-linux The build farm at http://hydra.gnu.org now provides 32-bit GNU/Linux binaries (i686-linux), in addition to the x86_64-linux binaries. Both can be transparently used as substitutes for local builds on these platforms. *** Debug info packages Some packages now have a “debug” output containing debugging information. The “debug” output can be used by GDB, and can be installed separately from the other outputs of the package. See “Installing Debugging Files” in the manual. *** Bootstrap binaries can be cross-compiled The distribution can now be ported to new architectures (currently GNU/Linux-only) by cross-compiling the “bootstrap binaries”. See “Porting” in the manual. *** Bootstrapping documented See “Bootstrapping” in the manual, for information on how the GNU distribution builds “from scratch”. ** Internationalization New translations: eo, pt_BR. ** Bugs fixed *** “guix --help” now works when using Guile 2.0.5 *** Binary substituter multi-threading and pipe issues fixed These could lead to random
Talk for the GHM
Hello, Time has come to send a title and summary for GHM talks. Presumably, Andreas and I will give a talk, or two talks, or two sub-talks, perhaps with Andreas talking about more specific technical topics. Here’s what I have in mind. GNU Guix, the computing freedom deployment tool Guix is GNU’s package manager and distribution. It seeks to empower users in several ways: by being a dependable system foundation, by providing the tools to formally correlate a binary package and the “recipes” and source code that led to it—furthering the spirit of the GNU GPL—, by allowing users to customize the distribution, and by lowering the barrier to entry in distribution development. This talk will reflect on a year of development, showing how far we’ve got toward this mission, and showing off with a demo. We will discuss challenges ahead in building a stand-alone GNU system, as well as opportunities for the larger GNU community. This may not be clear from the summary, but the message would be primarily philosophical social, and practical rather than about the internals. WDYT? (I’d like to send it tomorrow or early on Friday.) Thanks, Ludo’.
Re: Talk for the GHM
So here is my suggestion for the GHM: GNU Guix: Package without a scheme! One of the seducing features of the GNU Guix distribution is that the package management system as well as the package descriptions themselves are written in Guile, the GNU implementation of the Scheme language. But what if you do not know Scheme? Then you can still contribute by packaging your favourite GNU and other free software, and maybe learn a bit of beautiful functional programming en passant. This talk gives an overview of what is already packaged in GNU Guix, demonstrates the creation of a new package and asks the audience to come up with schemes of what to package for the next releases. I could give a talk of my own (two talks will give more weight to Guix!), but will probably not need 45 minutes; rather 30. Then I think we should have a tutorial session, where every GHM participant packages their favourite piece of software ;-) Andreas
Re: [PATCH 2/4] Add libaprutil.
Am Freitag, 25. Januar 2013 schrieb Cyril Roelandt: * gnu/packages/libapr: new variable. gnu/packages/libapr.scm | 33 + +(define-public libaprutil While trying to update subversion, I come across libapr.scm. Unlike Debian, we normally do not add lib in front of the name for a library package. For instance, we use cairo instead of libcairo. So I would suggest to rename the file to apr.scm, and the package libapr to apr. I am not sure for libaprutil, however, for which the official name is APR- util. Shall we use apr-util or aprutil to avoid the dash? Andreas
Re: Talk for the GHM
Andreas Enge andr...@enge.fr skribis: Sounds good to me, with the first paragraph maybe a bit heavy on buzzwords. Heh. :-) I wanted it to be high-level and concise, and ended up reusing that ELS intro. I think I’ll go with this one, because holiday time has come. ;-) Am Mittwoch, 17. Juli 2013 schrieb Ludovic Courtès: This talk will reflect on a year of development, showing how far we’ve got toward this mission, come instead of got, I think; I would also continue with infinitives: show instead of showing. Agreed. and showing off with a demo. give instead of show off with, or finish with? I really meant that we’ll be showing off. :-) Thanks for your input, Ludo’.
Re: HTML package list
l...@gnu.org (Ludovic Courtès) skribis: I just committed a script, build-aux/list-packages.scm, that produces an HTML page with a list of the available package, suitable for use on gnu.org. The result is at http://www.gnu.org/software/guix/package-list.html. [...] I’ll add a crontab entry somewhere to update the list periodically. I did that on hydra.gnu.org, so normally it will update it once per day. Happy summer! :-) Ludo’.
Re: Talk for the GHM
Hello, Sounds like a great plan. I must confess I started packaging nmap, and managed to build the derivation locally, but then got distracted with other stuff. This talk would probably give me the final push to start packaging for Guix. Best wishes, Alex On Thu, Jul 18, 2013 at 8:17 PM, Andreas Enge andr...@enge.fr wrote: So here is my suggestion for the GHM: GNU Guix: Package without a scheme! One of the seducing features of the GNU Guix distribution is that the package management system as well as the package descriptions themselves are written in Guile, the GNU implementation of the Scheme language. But what if you do not know Scheme? Then you can still contribute by packaging your favourite GNU and other free software, and maybe learn a bit of beautiful functional programming en passant. This talk gives an overview of what is already packaged in GNU Guix, demonstrates the creation of a new package and asks the audience to come up with schemes of what to package for the next releases. I could give a talk of my own (two talks will give more weight to Guix!), but will probably not need 45 minutes; rather 30. Then I think we should have a tutorial session, where every GHM participant packages their favourite piece of software ;-) Andreas
manual - bug report
It seems that the figure in section 6.4 of the documentation ( http://www.gnu.org/software/guix/manual/guix.html#GNU-Distribution) is missing: http://www.gnu.org/software/guix/manual/images/bootstrap-graph.png
Re: patch for list-packages
Btw, I can't see the patches as attachements, only inlined. Is it a problem with my mail client or does everybody witness the same behaviour ? I see the same. They also appear inline in the archives [1]. [1] https://lists.gnu.org/archive/html/guix-devel/2013-08/msg4.html pgp1UW2mnTqu6.pgp Description: PGP signature
[PATCH 1/2] list-packages: remove deprecated height attribute on td element.
See http://www.w3.org/TR/html5-diff/#obsolete-attributes for more information.
* build-aux/list-packages.html(package-sxml)[description-id]: remove height
attribute for td elements.
---
build-aux/list-packages.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/build-aux/list-packages.scm b/build-aux/list-packages.scm
index d060787..5ca2323 100755
--- a/build-aux/list-packages.scm
+++ b/build-aux/list-packages.scm
@@ -103,7 +103,7 @@ exec guile -l $0 \
(title Link to the Guix package source code))
,(package-name package)
,(package-version package)))
-(td (@ (colspan 2) (height 0))
+(td (@ (colspan 2))
(a (@ (href javascript:void(0))
(title show/hide package description)
(onClick ,(format #f javascript:show_hide('~a')
--
1.8.3.1
[PATCH 2/2] list-packages: remove useless language attribute of script element
See http://www.w3.org/TR/html5-diff/#changed-attributes for more information.
* build-aux/list-packages.html (insert-js): remove language attribute,
useless for the
* script element.
---
build-aux/list-packages.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/build-aux/list-packages.scm b/build-aux/list-packages.scm
index 5ca2323..a1bea69 100755
--- a/build-aux/list-packages.scm
+++ b/build-aux/list-packages.scm
@@ -206,7 +206,7 @@ color:#fff;
(define (insert-js)
Return the JavaScript for the list-packages page.
(format #t
-script language=\javascript\ type=\text/javascript\
+script type=\text/javascript\
// license: CC0
function show_hide(idThing)
{
--
1.8.3.1
Re: patch for list-packages
Cyril Roelandt tipec...@gmail.com skribis: Also, after applying those 3 patches, we go from 627 errors/warnings to 955 in the W3C validator (http://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.atheia.org%2Fguix%2Foutput.html). Oops. I'll try and send some patches. Ludo, where is the repository for gnu.org ? I'd like to get the images and the other html files. What do you mean? See http://savannah.gnu.org/cvs/?group=guix for the web page CVS repo. Ludo’.
Re: Gtk+
l...@gnu.org (Ludovic Courtès) skribis: Andreas Enge andr...@enge.fr skribis: thanks to Ludovic's help, who noticed that the pango input harfbuzz should be propagated, and after disabling the X server related tests, I managed to compile gtk+. I just pushed the new package, but so far, I did not test it with any application, so it might not even work... Neat, in time for 0.3, thank you! :-) I just added it to Emacs: [...] Now, the widgets that use Pango for font rendering (I suppose), like menus, display squares instead of actual characters, and the console is filled with things like: Fontconfig error: line 139: invalid attribute 'xml:space' Fontconfig error: line 140: invalid attribute 'xml:space' Fontconfig error: line 146: invalid attribute 'xml:space' Fontconfig warning: /nix/store/i7gz1hrlrpvaz0dr3qj8hhnqx3rg60rn-fontconfig-2.8.0/etc/fonts/conf.d/30-metric-aliases.conf, line 84: Having multiple family in alias isn't supported and may not work as expected Fontconfig warning: /nix/store/i7gz1hrlrpvaz0dr3qj8hhnqx3rg60rn-fontconfig-2.8.0/etc/fonts/conf.d/30-metric-aliases.conf, line 84: Having multiple family in alias isn't supported and may not work as expected Fontconfig warning: /nix/store/i7gz1hrlrpvaz0dr3qj8hhnqx3rg60rn-fontconfig-2.8.0/etc/fonts/conf.d/30-metric-aliases.conf, line 93: Having multiple family in alias isn't supported and may not work as expected I still get these. However, once gs-fonts is installed in the profile, everything displays correctly (thanks to commit 0ceea4f3edb6fd158613f2c46d18e037bc183f1a). My .emacs does this: (set-frame-font Bitstream Vera Sans Mono-12 nil) So I packaged that font. Once it’s installed, it’s loaded and used as expected, and everything works beautifully! We should probably add a section “Installing and Using Fonts” under “GNU Distribution”, to explain that fonts are searched for in the user’s default profile. Any volunteer? :-) Thanks, Ludo’.
Re: [PATCH 1/2] gnu: Add datefudge.
On 08/16/2013 07:45 PM, Ludovic Courtès wrote: Cyril Roelandt tipec...@gmail.com skribis: +(alist-replace + 'configure + (lambda* (#:key version outputs #:allow-other-keys #:rest args) + (pk version outputs) Leftover debugging statements, and ‘version’ doesn’t exist. What you can do is use: (arguments `( ... ,version ... )) to paste the ‘version’ field of the package being defined in the quasiquote expression. What kind of whitchcraft is this ? This works but I have no idea why. I don't think that Duckduckgoing GNU Guile , will give me any interesting results, so would you care to explain how this works, or redirect me to the appropriate documentation ? + (substitute* Makefile + ((^VERSION.*$) (string-append VERSION= version))) + ;; We do not need to pass these flags to install. + (substitute* Makefile No need to repeat ‘substitute*’: there can be several substitutations in a substitute* form. + (substitute* Makefile + ((^prefix.*$) (string-append prefix= out \n) Ditto. OK. +(inputs `((perl ,perl))) ; Needed for the tests. ‘native-inputs’, probably (if it were being cross-compiled, you’d want to run the native Perl, right?). Not sure about the difference between inputs and native-inputs. I think we may want to improve the documentation: $ git grep native-inputs doc/ $ Cyril.
Re: [PATCH] list-packages: Add an alt attribute for the logos.
Beat me to it, with a virtually identical change. :-) alex On Sat Aug 17 21:56:44 2013 Cyril Roelandt tipec...@gmail.com wrote: * build-aux/list-packages.scm (package-sxml): add an alternative text for the logos of the packages. --- build-aux/list-packages.scm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/build-aux/list-packages.scm b/build-aux/list-packages.scm index a1bea69..3f17b87 100755 --- a/build-aux/list-packages.scm +++ b/build-aux/list-packages.scm @@ -115,7 +115,8 @@ exec guile -l $0 \ ((? string? url) `(img (@ (src ,url) (height 35em) - (class package-logo + (class package-logo) + (alt (Logo of ,(package-name package)) (_ #f)) (p ,(package-description package)) ,(license package) -- 1.8.3.1
Re: 'substitute*' fails with string contains #\nul character
I can’t find anything relevant there. I suppose that Nix people don’t have to touch those binaries since they have ‘/bin/sh’ in a chroot. What string exactly are you trying to patch? Just /bin/sh? In which binary? For now, at least ‘/bin/sh’ in ‘inplace/bin/ghc-cabal’. I’m not sure about the details. I would have expected tools like BFD or libelf to provide the necessary support to make this kind of operation easier, but I’ve never tried myself. OK, I’ll try and report back. pgpm6Omq9mVe7.pgp Description: PGP signature
Re: 'substitute*' fails with string contains #\nul character
Another possible solution is to ship our own bootstrap binary (like we do with Guile and Bash). But first, I’ll try to patch it. Are you OK with that? With shipping a binary of GHC? Well, if that’s the only reasonable way to do it, then yes. GNU/MIT Scheme does that for instance, but that’s “their responsibility”, not ours. Does the GHC project distribute binaries for bootstrapping purposes? Yes. Actually, I’m trying to package a binary version of GHC [1], but I was talking about shipping ‘ghc-cabal’. Again, I think that patching is a better solution. [1] http://www.haskell.org/ghc/dist/7.0.1/ghc-7.0.1-i386-unknown-linux.tar.bz2 pgpGsDsG_xUXg.pgp Description: PGP signature
Re: Guile 2.0.5, HTTP downloads, and progress reports
Am Mittwoch, 21. August 2013 schrieb Ludovic Courtès: Commit db90b40 partially addresses this by removing the fake progress report on Guile 2.0.5, and by printing “please wait” (and “please upgrade”). Feedback from 2.0.5 users is welcome! As far as I can tell, nothing changed, I still get the progress report. Andreas
Re: Cross bootstrap!
l...@gnu.org (Ludovic Courtès) skribis: l...@gnu.org (Ludovic Courtès) skribis: So commit beda99e adds the N64 cross tool chain. I was able to build the static binaries tarball (Coreutils, gawk, etc.), and it seems to work as expected (tested on gcc49 of the GCC Compile Farm): I’ve uploaded two of the tarballs, for those who can’t use the substituter and don’t want to rebuild everything: http://www.fdn.fr/~lcourtes/tmp/static-binaries-0-mips64el-linux-gnuabi64.tar.xz http://www.fdn.fr/~lcourtes/tmp/guile-static-stripped-2.0.9-mips64el-linux-gnuabi64.tar.xz In fact, I’m interested in getting help with the Guile binary. Basically the binaries in the first tarball (Coreutils, gawk, etc.) work fine, but Guile (second tarball) aborts early. Commit 682cb00 may have fixed this bug, so I just uploaded a new tarball (SHA1: ba235690711b3856c053032af045c0819e534e91) obtained by running: guix build guile-static-stripped-tarball --target=mips64el-linux-gnuabi64 Unfortunately I can’t test (gcc49 is down). Can someone with a MIPS box test the Guile binary above? Thanks, Ludo’. pgpIvBImtucYs.pgp Description: PGP signature
Re: Guile 2.0.5, HTTP downloads, and progress reports
Am Mittwoch, 21. August 2013 schrieb Ludovic Courtès:
What do the following print?
guile -c '(pk (version))'
My guess is that (version) return 2.0.5-foobar-deb, which defeats the
test above.
Indeed, this prints
;;; (2.0.5-deb+1-3)
My report may have been wrong, as it appears that I did not correctly
install the newest guix version. Anyway, with
git-911b1b9cb693b59c4001899f144d77c3437c12fe I now cannot download any
more:
$ git build intltool
The following file will be downloaded:
/nix/store/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-intltool-0.50.2
@ substituter-started /nix/store/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 /usr/local/guix-git/libexec/guix/substitute-binary
downloading `/nix/store/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-intltool-0.50.2'
from `http://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2'...
http://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-intltool-0.50.2
4.0 KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 8.0 KiB transferredBacktrace:
In ice-9/boot-9.scm:
http://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-intltool-0.50.2
12.0 KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 16.0
KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 20.0
KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 24.0
KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 28.0
KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 32.0
KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 34.4
KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 34.4
KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 34.4
KiBhttp://hydra.gnu.org/nar/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 34.4 KiB transferred 149: 12 [catch #t #catch-
closure 92d1a0 ...]
157: 11 Exception thrown while printing backtrace:
ERROR: In procedure set-current-output-port: Wrong type argument in
position 1 (expecting open output port): #closed: file 0
ERROR: In procedure execl:
ERROR: In procedure execl: Datei oder Verzeichnis nicht gefunden
Backtrace:
In ice-9/boot-9.scm:
149: 14 [catch #t #catch-closure 92d1a0 ...]
157: 13 [#procedure 8cb0f0 ()]
In unknown file:
?: 12 [catch-closure]
In ice-9/boot-9.scm:
63: 11 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
407: 10 [eval # #]
In ice-9/boot-9.scm:
2111: 9 [save-module-excursion #procedure 8d0100 at
ice-9/boot-9.scm:3646:3 ()]
3651: 8 [#procedure 8d0100 at ice-9/boot-9.scm:3646:3 ()]
In unknown file:
?: 7 [load-compiled/vm /root/.cache/guile/ccache/2.0-
LE-8-2.0/usr/local/guix-git/bin/guix.go]
In guix/ui.scm:
475: 6 [run-guix-command substitute-binary --substitute ...]
In ice-9/boot-9.scm:
149: 5 [catch getaddrinfo-error ...]
157: 4 [#procedure c62370 ()]
In guix/scripts/substitute-binary.scm:
532: 3 [#procedure d81400 at guix/scripts/substitute-binary.scm:457:2
()]
In guix/nar.scm:
177: 2 [restore-file #input: #{read pipe}# 10 ...]
In guix/serialization.scm:
77: 1 [read-string #input: #{read pipe}# 10]
49: 0 [read-int #input: #{read pipe}# 10]
guix/serialization.scm:49:4: In procedure read-int:
guix/serialization.scm:49:4: In procedure bv-u32-ref: Wrong type argument
in position 1 (expecting bytevector): #eof
@ substituter-failed /nix/store/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-
intltool-0.50.2 256 fetching path
`/nix/store/khmpbvi9ivsfhhxz3a7k7cy7vkadczdp-intltool-0.50.2' failed with
exit code 1
guix build: error: build failed: some substitutes for the outputs of
derivation `/nix/store/ag99pv3rjk6bjf3fblnx2jrvmg6q7a96-
intltool-0.50.2.drv' failed; try `--fallback'
The file itself can be downloaded without problem with wget.
After applying your patch, the progress report is indeed suppressed, but
the download problem persists.
Andreas
Re: LWN article on Guix
Am Dienstag, 20. August 2013 schrieb Ludovic Courtès: If you’ve missed it, the Aug. 1st edition of Linux Weekly News (LWN) had an article about Guix: https://lwn.net/Articles/560760/ . Thanks for the link! It’s well written and conveys the important ideas, though there are a couple of misunderstandings Rather annoying is the misunderstanding in: For example, Guix's package store model works by linking a single directory in the system-wide store to a directory in the user's profile. This assumes that a package only installs files to one location, which is often not the case. Packages that install content in multiple output directories (e.g., /usr/bin and /usr/share/doc) are split up into separate pieces for Guix, so the GNU Distribution's glib package contains the Glibc binaries, while glib:doc contains its corresponding documentation. Each file is symlinked separately, and splitting into several packages is just an option (like in this case to avoid that a user needs to install heavy documentation). Andreas
Patches: Progressive Enhancement
Hello,
As discussed at the GHM, please find attached revised patches for
list-packages.
The first patch tidies the CSS in (insert-css).
The second patch uses fold-values from (sxml fold) to achieve what my
previous patch did without the use of set! (essentially change the page
so that it does not assume JavaScript to display all content elegantly).
Output is visible at www.atheia.org/guix/list-packages.html again, and
it validates correctly.
Let me know if you spot any problems. I will have another go at
externalising the CSS and JS after these patches have been approved and
merged.
Best wishes,
Alex
From 361b7aa0eff3681a8b0a47b7139fb7e84d7c8f71 Mon Sep 17 00:00:00 2001
From: Alex Sassmannshausen alex.sassmannshau...@gmail.com
Date: Mon, 26 Aug 2013 15:53:38 +0200
Subject: [PATCH 1/2] list-packages: Tidy CSS in preparation for split into
external file.
* build-aux/list-packages.scm (insert-css): Tidy CSS alignment etc.
---
build-aux/list-packages.scm | 97 ---
1 file changed, 63 insertions(+), 34 deletions(-)
diff --git a/build-aux/list-packages.scm b/build-aux/list-packages.scm
index 9cb07c1..3e798fc 100755
--- a/build-aux/list-packages.scm
+++ b/build-aux/list-packages.scm
@@ -156,50 +156,79 @@ exec guile -l $0 \
Return the CSS for the list-packages page.
(format #t
style
-a {transition: all 0.3s}
-div#intro {margin-bottom: 5em}
-div#intro div, div#intro p {padding:0.5em}
-div#intro div {float:left}
-table#packages, table#packages tr, table#packages tbody, table#packages td,
-table#packages th {border: 0px solid black}
-div.package-description {position: relative}
-table#packages tr:nth-child(even) {background-color: #FFF}
-table#packages tr:nth-child(odd) {background-color: #EEE}
-table#packages tr:hover, table#packages tr:focus, table#packages tr:active {background-color: #DDD}
+/* license: CC0 */
+a {
+transition: all 0.3s;
+}
+div#intro {
+margin-bottom: 2em;
+}
+div#intro div, div#intro p {
+padding:0.5em;
+}
+div#intro div {
+float:left;
+}
+div#intro img {
+float:left;
+padding:0.75em;
+}
+table#packages, table#packages tr, table#packages tbody, table#packages td, table#packages th {
+border: 0px solid black;
+clear: both;
+}
+table#packages tr:nth-child(even) {
+background-color: #FFF;
+}
+table#packages tr:nth-child(odd) {
+background-color: #EEE;
+}
+table#packages tr:hover, table#packages tr:focus, table#packages tr:active {
+background-color: #DDD;
+}
table#packages tr:first-child, table#packages tr:first-child:hover, table#packages tr:first-child:focus, table#packages tr:first-child:active {
-background-color: #333;
-color: #fff;
+background-color: #333;
+color: #fff;
}
-table#packages td
-{
-margin:0px;
-padding:0.2em 0.5em;
+table#packages td {
+margin:0px;
+padding:0.2em 0.5em;
}
table#packages td:first-child {
-width:10%;
-text-align:center;
+width:10%;
+text-align:center;
+}
+table#packages td:nth-child(2) {
+width:30%;
+}
+table#packages td:last-child {
+width:60%;
}
-table#packages td:nth-child(2){width:30%;}
-table#packages td:last-child {width:60%}
img.package-logo {
-float: left;
-padding-right: 1em;
+float: left;
+padding: 0.75em;
+}
+table#packages span {
+font-weight: 700;
+}
+table#packages span a {
+float: right;
+font-weight: 500;
}
-table#packages span a {float: right}
a#top {
-position:fixed;
-right:2%;
-bottom:2%;
-font-size:150%;
-background-color:#EEE;
-padding:1.125% 0.75% 0% 0.75%;
-text-decoration:none;
-color:#000;
-border-radius:5px;
+position:fixed;
+right:10px;
+bottom:10px;
+font-size:150%;
+background-color:#EEE;
+padding:10px 7.5px 0 7.5px;
+text-decoration:none;
+color:#000;
+border-radius:5px;
}
a#top:hover, a#top:focus {
-background-color:#333;
-color:#fff;
+background-color:#333;
+color:#fff;
}
/style))
--
1.7.10.4
From ed5771c1d5a18c31634ef075d6fe1eee70b32d6b Mon Sep 17 00:00:00 2001
From: Alex Sassmannshausen alex.sassmannshau...@gmail.com
Date: Mon, 26 Aug 2013 15:55:28 +0200
Subject: [PATCH 2/2] list-packages: Progressive Enhancement approach to JS.
* build-aux/list-packages.scm (package-sxml): Modify formal params,
docstring. Introduce logic for fold-values process.
(insert-tr): Moved sxml package table-row generation to new function; remove
a elements and JS function calls. These are created through JS
(prep_pkg_descs). Add insert-js-call for every 15th package, and the last.
(insert-js-call): New function.
(packages-sxml): Change map to fold values; add init params.
(insert-js): show_hide: add compatibility check, introduce, use thingLink
prep: new JS function.
bulk_show_hide: new JS function.
---
build-aux/list-packages.scm | 133 ---
1 file changed, 101 insertions(+), 32 deletions(-)
diff --git a/build-aux/list-packages.scm
Re: Patches: Progressive Enhancement
…and the link should of course have been http://www.atheia.org/guix/package-list.html Thanks to Amirouche for spotting that. Alex Alex == Alex Sassmannshausen alex.sassmannshau...@gmail.com writes: Alex Hello, As discussed at the GHM, please find attached revised Alex patches for list-packages. Alex The first patch tidies the CSS in (insert-css). Alex The second patch uses fold-values from (sxml fold) to achieve Alex what my previous patch did without the use of set! Alex (essentially change the page so that it does not assume Alex JavaScript to display all content elegantly). Alex Output is visible at www.atheia.org/guix/list-packages.html Alex again, and it validates correctly. Alex Let me know if you spot any problems. I will have another go Alex at externalising the CSS and JS after these patches have been Alex approved and merged. Alex Best wishes, Alex Alex
Re: Agreeing on some rules for packaging.
Am Dienstag, 27. August 2013 schrieb Cyril Roelandt: At the GHM, a Fedora hacker (whose name I forgot) suggested that it might be time for us to write down some rules as to how packaging should be done. It was Patrice Dumas. I agree and volunteer to propose such a document with good packaging practices. I would also like to include a page on python with a naming scheme suggestion. Would you mind holding back on python3 for so long? At least the python part should be ready by tomorrow evening. Andreas
Re: Recursive makefiles
On Thu, Aug 29, 2013 at 12:21:47AM +0200, Ludovic Courtès wrote: Hmm, there was no Makefile in doc/, so how could “cd doc; make pdf” work? Sorry, indeed, it did not work of course. make doc/guix.pdf. With that, “make pdf” at the top level creates doc/guix.pdf, and leaves no intermediate files at all at the top level. Is it an acceptable solution for you (provided the bug above is fixed nicely)? If so, I’ll prepare a patch. That sounds very good, thanks! Andreas
Goals for 0.4
Hello! So, what do we put in 0.4, and when do we release it? First, I’d like to release 0.4 by (or on) GNU’s 30th birthday, which is on Sep. 28th [0]. On the 28th, I’d also like to have a bootable QEMU image built with Guix, featuring at least the init system (dmd), a console login, and bare utilities. What I would really like to see in 0.4: • Guix must be usable with the old Guile 2.0.5, since that’s what some distros provide. At the GHM I realized that some people had weird bugs with that Guile, notably in the substituter. I fixed a couple of bugs, but there may be others around. So, to 2.0.5 users: please run ‘make check’, use Guix and in particular the substituter, and report bugs! • Packages: as already discussed, more packages, anything that makes the distro more useful (having Git is a must.) A package a day keeps the competition away. ;-) • Core updates: in particular libc 2.18. Possibly switch to GCC 4.8 as the default compiler. • APIs: new or extended APIs for building stand-alone images. I’ve been looking into that recently, notably with the initrd stuff. • New ‘--list-generations’ and ‘--delete-generations’ options for ‘guix package’. • Manual: improve as we see fit; notably add a section on font usage for X applications. Optional goals: • MIPS64/N64 support: the bootstrap tarballs are now all available through cross-compilation from x86_64, so it’s “just” a matter of feeding them in bootstrap.scm and trying out. • Rebuilt bootstrap binaries (aka. the “Fixed Point Project”, more on that later.) • Python 3, and related packaging changes. Anything else? What do people think? Ludo’. [0] https://www.gnu.org/gnu30/ pgpp4y_ewp4ro.pgp Description: PGP signature
Re: Online hackathon ?
On Wed, Aug 28, 2013 at 10:53:53PM +0200, Ludovic Courtès wrote: The second thing is GNU packages. Some of the trickier but more interesting include TeXmacs, Octave, and R, for instance. Octave requires gfortran. How can this be activated in our gcc used for building packages? Andreas
Re: Recursive makefiles
Andreas Enge andr...@enge.fr skribis: On Thu, Aug 29, 2013 at 12:21:47AM +0200, Ludovic Courtès wrote: Hmm, there was no Makefile in doc/, so how could “cd doc; make pdf” work? Sorry, indeed, it did not work of course. make doc/guix.pdf. With that, “make pdf” at the top level creates doc/guix.pdf, and leaves no intermediate files at all at the top level. Is it an acceptable solution for you (provided the bug above is fixed nicely)? If so, I’ll prepare a patch. That sounds very good, thanks! I just did that in commit a9424c0 (already pushed). I think it does the right thing, but if it doesn’t, let’s discuss it. :-) Ludo’.
Re: Compiling guix 0.3 on a fedora 8 planetlab node
On Thu, Aug 29, 2013 at 10:02:46PM +0200, Ludovic Courtès wrote: If the answer is “no”, then you may just as well comment out CLONE_NEWIPC in nix/libstore/build.cc. Apart from that, you also need guile version at least 2.0.5, released in January 2012. It would definitely be easier to use a distribution containing this version already. Andreas
Re: Recursive makefiles
On Thu, Aug 29, 2013 at 10:04:10PM +0200, Ludovic Courtès wrote: I just did that in commit a9424c0 (already pushed). I think it does the right thing, but if it doesn’t, let’s discuss it. :-) It works well for me, and the patch fixing the size of the graph is also a nice addition. Thanks! Andreas
Re: Compiling guix 0.3 on a fedora 8 planetlab node
Andreas Enge andr...@enge.fr skribis: PS: For work on gnunet, it would be preferable to clone the git repository, which contains a few dependencies not yet available in 0.3. ... or you can install 0.3 and run “guix pull” to get them. Ludo’.
Re: Goals for 0.4
Andreas Enge andr...@enge.fr skribis: On Thu, Aug 29, 2013 at 02:34:27PM +0200, Ludovic Courtès wrote: • Manual: improve as we see fit; notably add a section on font usage for X applications. I would volunteer for this one. • Python 3, and related packaging changes. And for some work on this one. Thanks! Ludo’.
Re: Overlays
2013/8/30 Ludovic Courtès l...@gnu.org Nikita Karetnikov nik...@karetnikov.org skribis: So I think Guix nearly supports overlays, no? :-) What do NixOS people mean by “overlay”? Well, I don’t think that wiki page has much authority. ;-) “Overlay” is not a term that is used in NixOS circles. My guess is that the Ruby and Haskell overlays mentioned at http://nixos.org/wiki/Nix(OS)_related_repositories_and_work are used by a single person, and I’m not sure what they do. I don't recall how I heard about those overlay. Is it a remote collection of recipes? Does NixOS allow to use them without copying to the local storage (like ‘gnu/packages’)? I believe that the question was about these issues. I’m not sure what the issues are. The issue I see is that some one wants to distribute recipes but doesn't want to contribute them in the guix repository. One way to do that is to fork the guix repository and merge once in a while and then ask the users to install packages using the command used during development from the forked repository. Otherwise, if overlays were supported users would just have to install overlays somewhat like apt sources and use the same command as with guix distribution recipes. I see they are quite useful in Gentoo for forked distributions. In Guix, third parties could distribute their own Guile modules that define packages. Guix would need a way to nicely deal with them at the command line, but otherwise it’s just Guile modules. IIRC in nixos one just has to use the command «nix-env -i path/to/nix/package» to install a recipe out of nixpkg tree, I'm not sure it's supported by guix. Anyway, the reason I raised now this feature is because: - I find it a useful feature, but the features you proposed for 0.4 are way more interesting for the time being - One user complained on IRC that overlays could *streamline* recipes contributions that said contributing packages is not difficult using the guix repository So what I propose is to put this feature request in a TODO to avoid future loosly backed request like mine (except if someone wants to work on this) and focus on the 0.4 roadmap :)
Python 3 native-search-paths
I just noticed that there is a variable native-search-paths in python-2, which looks like it should be updated for python 3. However, when I modify the package accordingly, it is not recompiled. How come? Is this variable really needed? Andreas
Re: [PATCH 0/2] Add tools for sysadmins: htop and dfc.
Cyril Roelandt tipec...@gmail.com skribis: This patch series adds htop and dfc, which are 'modern' versions of top and df. [...] gnu/packages/sysutils.scm | 70 + It just occurred to me that there’s already (gnu packages system), which contains sysadmin tools. Could you put the contents of sysutils.scm in there? Thanks, Ludo’.
Re: Python 3 binaries
Cyril Roelandt tipec...@gmail.com skribis: On 08/31/2013 05:30 PM, Andreas Enge wrote: Hello, python 3 does not ship a python binary any more, just a binary called python3. That could be useful, since it would allow to install python 2 and 3 side by side. However, all packages relying on a shebang substitution with a python binary now fail. I see two general possibilities to solve the problem: - The simplest one, add a symlink python-python3 in the python 3 package. But then we lose the possibility of installing python 2 and 3 at the same time. Which maybe does not matter? It would only be a problem for a user wanting to install both in the user profile, while all other packages would internally have rewritten their calls to either of the two python versions I think lots of users would want that. On Debian, I really like having multiple versions of Python, since some of my scripts are not Python3 compatible. It's also useful to run test suites against many versions of Python. I think users must be able to install both. Yes, and that’s visibly what upstream wants. So I would just leave things as is, without the symlink. Then again I know nothing about Python. :-) Ludo’.
Re: Goals for 0.4
jema...@gnu.org (Jose E. Marchesi) skribis: I just realized that we can do even better: have --list-generations output recutils-formatted data (using ‘object-fields’). Then, if we do it right, the output can just be piped to ‘recsel’ to select entries of a certain age, to display specific fields, etc. Like: generation-number: 1 date: 2013-05-07 However, I don’t know exactly how to represent both the generations and the list of packages in each generation in a single recutils stream. José, how can the relations between “generation” records and “package” records be expressed? You can have two record sets: one for generations, one for packages. A foreign key can relate them. Something like this: Perfect, thanks! Ludo’.
Re: Python 3 native-search-paths
On Sat, Aug 31, 2013 at 08:06:34PM +0200, Ludovic Courtès wrote: It has no effect in the build of Python itself; its effect is only when building Python code that uses Python and one or more Python libs. I still think something is wrong here and that this variable should be included into the computation of the hash. When I now recompile a package depending on python, it gets the same hash, but it is different. Or more easily: The python package with the new native-search-paths behaves differently from the previous one, so it should have a different hash. Andreas
Re: Online hackathon ?
Jason Self ja...@bluehome.net skribis: There will also be a hackathon going on at the GNU Project's 30th anniversary [0] in Boston if anyone's interested in meeting in person there. It could probably be coordinated with an online hackathon too. Based on Libby's message [1] it might be possible to coordinate something for Guix too. Would be nice, though I think most people here are on the other side of the ocean. On the positive side: it would be an opportunity to conquer the US. ;-) There’s a birthday party in Paris on the 21st too. I won’t be physically there, but that could be a good date too. Cyril? Ludo’.
Re: [PATCH] gnu: Add Python 3.
The impact of the switch from Python 2 to 3 can be seen here: http://hydra.gnu.org/eval/10856 That is: minus 48 packages. :-) Many are due to the fact that the ‘python’ executable is unavailable, like http://hydra.gnu.org/build/16789. Ludo’.
Re: Git.
On Thu, Aug 29, 2013 at 10:16:37PM +0200, Cyril Roelandt wrote: So, I've just tried to make git work. The attached patch allows me to build Git on my x86 machine, but the build fails on my x86-64 machine. Any idea ? For me, everything works on x86_64 and with --system=i686-linux. The tests fail, but a few simple operations (stash, diff, pull) on the guix tree work. Shall I push the attached patch despite the test failures? Andreas diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm index 5059dcd..4b0d331 100644 --- a/gnu/packages/version-control.scm +++ b/gnu/packages/version-control.scm @@ -2,6 +2,7 @@ ;;; Copyright © 2013 Nikita Karetnikov nik...@karetnikov.org ;;; Copyright © 2013 Cyril Roelandt tipec...@gmail.com ;;; Copyright © 2013 Ludovic Courtès l...@gnu.org +;;; Copyright © 2013 Andreas Enge andr...@enge.fr ;;; ;;; This file is part of GNU Guix. ;;; @@ -19,7 +20,7 @@ ;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. (define-module (gnu packages version-control) - #:use-module ((guix licenses) #:select (asl2.0 gpl1+ gpl2+ gpl3+)) + #:use-module ((guix licenses) #:select (asl2.0 gpl1+ gpl2 gpl2+ gpl3+)) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix build-system gnu) @@ -28,11 +29,14 @@ #:use-module ((gnu packages gettext) #:renamer (symbol-prefix-proc 'guix:)) #:use-module (gnu packages apr) + #:use-module (gnu packages curl) #:use-module (gnu packages nano) + #:use-module (gnu packages openssl) #:use-module (gnu packages perl) #:use-module (gnu packages python) #:use-module (gnu packages sqlite) #:use-module (gnu packages system) + #:use-module (gnu packages xml) #:use-module (gnu packages emacs) #:use-module (gnu packages compression)) @@ -64,6 +68,48 @@ organize their workspace in whichever way they want. It is possible to work from a command line or use a GUI application.) (license gpl2+))) +(define-public git + (package + (name git) + (version 1.8.4) + (source (origin +(method url-fetch) +(uri (string-append http://git-core.googlecode.com/files/git-; +version .tar.gz)) +(sha256 + (base32 + 156bwqqgaw65rsvbb4wih5jfg94bxyf6p16mdwf0ky3f4ln55s2i + (build-system gnu-build-system) + (inputs +`((curl ,curl) + (expat ,expat) + (gettext ,guix:gettext) + (openssl ,openssl) + (perl ,perl) + (python ,python-2) ; incompatible with python-3 according to INSTALL + (zlib ,zlib))) + (arguments +`(#:make-flags `(V=1) ; more verbose compilation + #:test-target test + #:tests? #f ; FIXME: Many tests are failing + #:phases + (alist-replace +'configure +(lambda* (#:key #:allow-other-keys #:rest args) + (let ((configure (assoc-ref %standard-phases 'configure))) + (apply configure args) + (substitute* Makefile +((/bin/sh) (which sh)) +((/usr/bin/perl) (which perl)) +((/usr/bin/python) (which python) + %standard-phases))) + (synopsis distributed version control system) + (description +Git is a free distributed version control system designed to handle +everything from small to very large projects with speed and efficiency.) + (license gpl2) + (home-page http://git-scm.com/;))) + (define-public subversion (package (name subversion)
Re: Python 3 binaries
On Sun, Sep 01, 2013 at 07:34:03PM +0200, Ludovic Courtès wrote: However, my understanding from what Cyril and Brandon said is that users may prefer to have it called ‘python3’ by default, so they can install both Python 2 and Python 3 in parallel. Furthermore, they can choose to have (say) an alias python=python3 if that’s what they want. Based on that, I thought the wrapper would be mostly for internal consumption. Did I get it right? My understanding was that users (really: Python developers) would expect to get a ‘python3’ binary when they install the latest, and a ‘python’ binary otherwise. My impression was that most people would like to install the latest and greatest (python 3), but with the binary still called python. These people could install python-default (the wrapper, which I would then expect to be the package that the average user would install). Developers who want both versions can install python-2 and python-3. The Debian python policy stipulates the following: Python scripts depending on the default Python version (...) or not depending on a specific Python version should use python (without a version) as the interpreter name. Python scripts that only work with a specific Python version must explicitly use the versioned interpreter name (pythonX.Y). Following this policy (which we may or may not do), if we declare Python 3 to be the default python version, then our python-3 package should contain a binary named python, and we would have to delete the python binary from the version 2 package and keep only those named python2 and python2.7. And we should, for internal use, create a wrapper package python-default-2... But indeed, it would be nice to get our python specialists' opinion. Andreas
[PATCH 1/2 v3] gnu: Add htop.
* gnu/packages/sysutils.scm (htop): New variable. --- gnu/packages/system.scm | 22 ++ 1 file changed, 22 insertions(+) diff --git a/gnu/packages/system.scm b/gnu/packages/system.scm index e326e49..fb364f1 100644 --- a/gnu/packages/system.scm +++ b/gnu/packages/system.scm @@ -1,5 +1,6 @@ ;;; GNU Guix --- Functional package management for GNU ;;; Copyright © 2012, 2013 Ludovic Courtès l...@gnu.org +;;; Copyright © 2013 Cyril Roelandt tipec...@gmail.com ;;; ;;; This file is part of GNU Guix. ;;; @@ -25,6 +26,27 @@ #:use-module (gnu packages ncurses) #:use-module (gnu packages linux)) +(define-public htop + (package + (name htop) + (version 1.0.2) + (source (origin +(method url-fetch) +(uri (string-append mirror://sourceforge/htop/ + version /htop- version .tar.gz)) +(sha256 + (base32 + 18fqrhvnm7h4c3939av8lpiwrwxbyw6hcly0jvq0vkjf0ixnaq7f + (build-system gnu-build-system) + (inputs +`((ncurses ,ncurses))) + (home-page http://htop.sourceforge.net/;) + (synopsis Interactive process viewer) + (description +This is htop, an interactive process viewer. It is a text-mode +application (for console or X terminals) and requires ncurses.) + (license gpl2))) + (define-public pies (package (name pies) -- 1.7.10.4
[PATCH 2/2 v3] gnu: Add dfc.
* gnu/packages/system.scm (dfc): New variable. --- gnu/packages/system.scm | 23 +++ 1 file changed, 23 insertions(+) diff --git a/gnu/packages/system.scm b/gnu/packages/system.scm index fb364f1..1f8a7d5 100644 --- a/gnu/packages/system.scm +++ b/gnu/packages/system.scm @@ -21,11 +21,34 @@ #:use-module (guix licenses) #:use-module (guix packages) #:use-module (guix download) + #:use-module (guix build-system cmake) #:use-module (guix build-system gnu) #:use-module (gnu packages) #:use-module (gnu packages ncurses) #:use-module (gnu packages linux)) +(define-public dfc + (package + (name dfc) + (version 3.0.3) + (source +(origin + (method url-fetch) + (uri (string-append +http://projects.gw-computing.net/attachments/download/78/dfc-; +version .tar.gz)) + (sha256 + (base32 +1b4hfqv23l87cb37fxwzfk2sgspkyxpr3ig2hsd23hr6mm982j7z + (build-system cmake-build-system) + (arguments '(#:tests? #f)) ; There are no tests. + (home-page http://projects.gw-computing.net/projects/dfc;) + (synopsis Display file system space usage using graphs and colors.) + (description +dfc (df color) is a modern version of df. It uses colors, draws pretty +graphs and can export its output to different formats.) + (license bsd-3))) + (define-public htop (package (name htop) -- 1.7.10.4
Re: Python 3 binaries
On Sun, Sep 01, 2013 at 07:40:18PM +0200, Cyril Roelandt wrote: Packages usually exist in two different versions: python-foo and python3-foo. I think this is quite a good way of packaging both Python 2 and 3. One day, maybe nobody will use Python 2.x any more, and we'll just use python instead of python3, but until then, I'm really happy to have python and python3. I think it is not compatible with our policy of defaulting to always the latest version, if possible, while debian usually defaults to something old and very stable. (I notice that python-3.0 dates from 2008). So do I understand correctly that you would suggest two packages, python (containing version 2.x) and python3 (containing version 3.x), and the same for all modules? Otherwise, having python-2 and python-3, upgrading and installing without giving a version number would automatically switch to python-3, and then we would lose the python binary. With a package python (version 2) and a package python3, without a wrapper package, all our packages containing some #!/usr/bin/python would have to use Python version 2. Is that what we want? I think the suggestions with a wrapper package make it easier to switch to Python 3 wherever possible, while your suggestion, if I understand it correctly, seems to force us to stay with Python 2 until the last minute. Worse, if there are packages requiring Python 3 but containing #!/usr/bin/python (do such programs exist?), we would need to treat them on a case-by-case basis. Andreas
Re: [PATCH] gnu: Add Python 3.
On Sun, Sep 01, 2013 at 09:40:27PM +0200, Ludovic Courtès wrote: Speaking of which: in the future, we should use topic branches for such things, to avoid disrupting the main branch. For instance, I’ve locally switched back to Python 2 as the default since I was otherwise unable to use the QEMU-related things. Actually it’s not too late: we could create a new branch off ‘master’, and just switch back to Python 2 as the default on ‘master’. Hydra can be told to build the new branch in addition to ‘master’. Actually, 77c7f8f41b558bab13690c843068af8ba996e5bf switches back (while keeping the definition of Python 3 in the variable python-3; but all packages using python as input will get Python 2). We could create branches; very often (like here, with changes to the python build system pending), we might as well use core-updates directly. Andreas
Re: Git.
Andreas Enge andr...@enge.fr skribis: On Thu, Aug 29, 2013 at 10:16:37PM +0200, Cyril Roelandt wrote: So, I've just tried to make git work. The attached patch allows me to build Git on my x86 machine, but the build fails on my x86-64 machine. Any idea ? For me, everything works on x86_64 and with --system=i686-linux. The tests fail, but a few simple operations (stash, diff, pull) on the guix tree work. Shall I push the attached patch despite the test failures? Yes, please (I’ll try to look at the test failures, though I’m happy to share that with someone else.) +(lambda* (#:key #:allow-other-keys #:rest args) + (let ((configure (assoc-ref %standard-phases 'configure))) + (apply configure args) + (substitute* Makefile +((/bin/sh) (which sh)) +((/usr/bin/perl) (which perl)) +((/usr/bin/python) (which python) Please indent according to scoping, and check the return value of CONFIGURE: (let ((configure (...))) (and (apply configure args) (substitute* ...))) Thanks! Ludo’.
Re: Git.
On Sun, Sep 01, 2013 at 09:48:47PM +0200, Ludovic Courtès wrote: Please indent according to scoping, and check the return value of CONFIGURE: (let ((configure (...))) (and (apply configure args) (substitute* ...))) Thanks, I updated the recipe, and am going to push. Andreas
Re: Git.
On 09/01/2013 05:27 PM, Andreas Enge wrote: For me, everything works on x86_64 and with --system=i686-linux. What's the difference between your patch and mine ? The tests fail, but a few simple operations (stash, diff, pull) on the guix tree work. Shall I push the attached patch despite the test failures? I think we should do that, since git is a very important package to have. Cyril.
GHM videos
The GHM videos are now available from audio-video.gnu.org. My talk is linked from http://gnu.org/s/guix/ with a fancy HTML5 video tag. :-) Thanks, Ludo’. PS: Thanks to Sylvestre Ledru and others for recording, to Luca Saiu for polishing, and to Mark H. Weaver and Luca for uploading to gnu.org!
Re: Python 3 binaries
l...@gnu.org (Ludovic Courtès) writes: My understanding was that users (really: Python developers) would expect to get a ‘python3’ binary when they install the latest, and a ‘python’ binary otherwise. It depends. I've grown used to having python(-python3) and python2 binaries in Parabola/Arch, where it is the policy to always have the latest version as the default. Then that means we don’t really have to worry, and just document that the python-3.x package is an unmodified upstream package, with its binary is called ‘python3’. I think that is a fine way to do it. The most important part is internal consistency. It seems that the unmodified upstream strategy is the path of least resistance, and it will fit with the expectations of all of the Debian-based users out there. As for the shebangs, you may well still have to do some patching for some packages, if they were written in python3 but the shebang is for /usr/bin/python. -brandon -- Brandon Invergo http://brandon.invergo.net pgpReWjPHwLzn.pgp Description: PGP signature
Re: New ‘--list-generations’ and ‘--delete-generations’ options
Nikita Karetnikov nik...@karetnikov.org skribis: I’m trying to handle the “last-month” and the “first-month” cases. I’d like to use ‘profile-numbers’* to construct an alist of generations and their creation dates. What can I use to get the creation date of a file? I can’t find anything in the manual. Something like (and= (stat foo) stat:ctime). * We should rename it to ‘generation-numbers’ or something like that. Probably, yes. Ludo’.
Re: Goals for 0.4
On 09/02/2013 09:38 PM, Ludovic Courtès wrote: That is, try to install something that’s available on hydra.gnu.org, and check that it downloads correctly, and prints “Please consider upgrading Guile to get proper progress report”. It does exactly that. Cyril.
Optimizing profile creation
At the GHM, Andreas rightfully noted that building a profile with many files, as is the case when TeX Live is installed, can take quite a bit of time; and every time a package is installed/removed/upgraded, you pay that price again since the profile is built from scratch. Creating a profile builds a symlink forest that is the union of all the package directories that make up the profile. But with a package like TeX Live, until now, this would end up traversing all of its ‘texmf’ sub-directory, just to create a symlink forest that copies the ‘texmf’ directory structure. So, commit 43dd920 does the (now obvious) optimization: if a sub-directory, like ‘texmf’, is only in one package, then it symlinks that directory without traversing it. This happens to be a quite frequent situation. For instance, with Emacs in my profile, I would before have this: --8---cut here---start-8--- $ ls -l /nix/var/nix/profiles/per-user/ludo/guix-profile-104-link/share/emacs/ total 16 dr-xr-xr-x 6 root nixbld 4096 Jan 1 1970 24.3/ dr-xr-xr-x 3 root nixbld 12288 Jan 1 1970 site-lisp/ $ ls -l /nix/var/nix/profiles/per-user/ludo/guix-profile-104-link/share/emacs/24.3/lisp/ total 2096 lrwxrwxrwx 1 nixbld1 nixbld87 Jan 1 1970 abbrev.elc - /nix/store/f3pxa96mg8ws4kfldzarayd8i58ddz5j-emacs-24.3/share/emacs/24.3/lisp/abbrev.elc lrwxrwxrwx 1 nixbld1 nixbld89 Jan 1 1970 abbrev.el.gz - /nix/store/f3pxa96mg8ws4kfldzarayd8i58ddz5j-emacs-24.3/share/emacs/24.3/lisp/abbrev.el.gz lrwxrwxrwx 1 nixbld1 nixbld86 Jan 1 1970 align.elc - /nix/store/f3pxa96mg8ws4kfldzarayd8i58ddz5j-emacs-24.3/share/emacs/24.3/lisp/align.elc lrwxrwxrwx 1 nixbld1 nixbld88 Jan 1 1970 align.el.gz - /nix/store/f3pxa96mg8ws4kfldzarayd8i58ddz5j-emacs-24.3/share/emacs/24.3/lisp/align.el.gz [...] --8---cut here---end---8--- With this optimization, I have directly this: --8---cut here---start-8--- $ ls -l /nix/var/nix/profiles/per-user/ludo/guix-profile-105-link/share/emacs/ total 16 lrwxrwxrwx 1 nixbld1 nixbld71 Jan 1 1970 24.3 - /nix/store/f3pxa96mg8ws4kfldzarayd8i58ddz5j-emacs-24.3/share/emacs/24.3/ dr-xr-xr-x 2 rootnixbld 12288 Jan 1 1970 site-lisp/ --8---cut here---end---8--- No need to traverse the crowded ‘24.3’ directory since there’s only one package in my profile that provides it. Please report any speedups or bugs you may have. :-) Ludo’.
Re: Optimizing profile creation
On Mon, Sep 02, 2013 at 11:14:27PM +0200, Ludovic Courtès wrote: Please report any speedups or bugs you may have. :-) Nothing to report so far, but this is a very neat optimisation! Andreas
MIPS64/N64 support (was: Goals for 0.4)
• MIPS64/N64 support: the bootstrap tarballs are now all available through cross-compilation from x86_64, so it’s “just” a matter of feeding them in bootstrap.scm and trying out. I’m also interested in this one. Oh, I forgot that I’ll need five tarballs, not two [1]. Can I get the other three somewhere? Otherwise, I’ll probably try to cross-compile them myself. [1] http://www.fdn.fr/~lcourtes/tmp/ pgpmTclcc3YOy.pgp Description: PGP signature
Re: MIPS64/N64 support
Nikita Karetnikov nik...@karetnikov.org skribis: • MIPS64/N64 support: the bootstrap tarballs are now all available through cross-compilation from x86_64, so it’s “just” a matter of feeding them in bootstrap.scm and trying out. I’m also interested in this one. Oh, I forgot that I’ll need five tarballs, not two [1]. Can I get the other three somewhere? Otherwise, I’ll probably try to cross-compile them myself. If you can cross-compile (really: substitute) them from x86_64, the better (you can even log in to hydra.gnu.org and get them from there.) Otherwise let me know and we’ll arrange something. Ludo’.
Re: Naming scheme for Python packages
On Wed, Sep 04, 2013 at 10:52:08PM +0200, Cyril Roelandt wrote: (define pytz (package (name python-pytz) ...)) This is quite Debianish. I like it. But the alternative (as I suggested in the packaging guidelines) is as debianish: (define python-pytz (package (name python-pytz) ...)) We agree on the outer experience, the question is now how to name variables internally (which is, admittedly, less important). Andreas
Re: Naming scheme for Python packages
On 09/04/2013 10:51 PM, Ludovic Courtès wrote: Thus I would do: (define pytz (package (name python-pytz) ...)) And what should we call python2-pytz ? Cyril.
Re: Naming scheme for Python packages
On Wed, Sep 04, 2013 at 10:51:17PM +0200, Ludovic Courtès wrote: However, I don’t think that scheme should be followed for variable names: it’s tedious to type, and Guile offers mechanisms to select/rename bindings imported from other bindings. Thus I would do: (define pytz (package (name python-pytz) ...)) Well, we also have the policy so far that variable name = name field. I find it consistent, and do not mind typing a few python- more or less. It is not what makes packaging quite a bit of work... But if others agree, this can still be changed quite easily. You may wish to suggest a patch to the packaging guidelines in the documen- tation; the ease or lack of ease to formulate a coherent guideline could be an indication on what we should do... Andreas
Git\Github
Are you using git repositories or other kind of distributed version control? Thanks, Filipe Machado
Re: New ‘--list-generations’ and ‘--delete-generations’ options
Nikita Karetnikov nik...@karetnikov.org skribis: The attached procedure will be invoked when either option is called with an argument. Nice. BTW, what did you think of the idea of using recutils format as the output? (Either as the sole output format, or otherwise as a secondary format.) Do you see any problems? Please check everything (especially the ‘first-month’ and ‘last-month’ functions). Better yet: write test cases. :-) ;; XXX: (avail-generations ) returns () (because of (csi)). This case ;; should be handled by a different procedure. Basically, it means that no ;; arguments were passed to '--list-generations' or '--delete-generations'. (define* (avail-generations str #:optional (profile %current-profile)) Please, never use abbreviations in public identifiers, and avoid them in private identifiers too (‘valid-generation?’, ‘maybe-integer’ instead of ‘int’, etc.) Return a list of generations matching the pattern in STR. What about splitting it in two functions: ‘string-time-range’ → return two SRFI-19 time objects representing a time interval, or #f and #f on failure ‘generation-within-time-range?’ Writing tests for the former will be easy. The code otherwise looks OK, but disentangling parsing from validation will make it even more pleasant IMO. Thanks, Ludo’.
Re: New ‘--list-generations’ and ‘--delete-generations’ options
BTW, what did you think of the idea of using recutils format as the output? (Either as the sole output format, or otherwise as a secondary format.) I like the idea. It’s always better to use a documented format, especially when it comes with a mode for Emacs. And don’t forget that ‘--search’ already uses recutils. I didn’t say anything before because I haven’t tried to implement this part yet. Do you see any problems? Please check everything (especially the ‘first-month’ and ‘last-month’ functions). Better yet: write test cases. :-) I have some tests, but you have to modify ‘int’ and the other related procedures to use them. So it’s not an option. I’m also not sure what’s the best way to test the ‘first-month’ and ‘last-month’ functions (the validation part). Any ideas? The code otherwise looks OK, but disentangling parsing from validation will make it even more pleasant IMO. I agree. I just haven’t found a way that avoids unnecessary repetition. (I’ll comment on other issues later.) Could you share your thoughts on other things that are marked with “XXX”? pgpfnOS0ga2uS.pgp Description: PGP signature
Re: MIPS64/N64 support
Oh indeed, using ‘-s’ was a good idea. Note that ‘guix build bootstrap-tarballs’ is even faster to type. Thanks. Which Guile do I need? The stripped one, right? The one that’s in the output of ‘guix build bootstrap-tarballs’ (I forgot the name.) Yep, the stripped one. Can I download the bootstrap tarballs from the web interface of Hydra? (Otherwise, I’ll have to configure a web server myself. I’d like to avoid that.) Also, I’ve noticed that your tarballs (the ones in /tmp) are different From the ones I use. Does it raise a flag? Was there a change in the inputs? pgpmWnN_Vpfbk.pgp Description: PGP signature
‘--no-substitutes’ is ignored on i686 (was: Goals for 0.4)
• Guix must be usable with the old Guile 2.0.5, since that’s what some distros provide. At the GHM I realized that some people had weird bugs with that Guile, notably in the substituter. I fixed a couple of bugs, but there may be others around. So, to 2.0.5 users: please run ‘make check’, use Guix and in particular the substituter, and report bugs! I’m using the latest version of Guile. And I’ve already mentioned this (though, it might be a new issue): ‘--no-substitutes’ doesn’t work on my system at all. It’s completely ignored. (I haven’t tested on a different machine.) I’ll try to look into it when I finish with generations and MIPS. pgpYkEJn0gHUH.pgp Description: PGP signature
Re: MIPS64/N64 support
Nikita Karetnikov nik...@karetnikov.org skribis: Oh indeed, using ‘-s’ was a good idea. Note that ‘guix build bootstrap-tarballs’ is even faster to type. Thanks. Which Guile do I need? The stripped one, right? The one that’s in the output of ‘guix build bootstrap-tarballs’ (I forgot the name.) Yep, the stripped one. Can I download the bootstrap tarballs from the web interface of Hydra? Why not do ‘guix build bootstrap-tarballs -s x86_64-linux --target=...’? Also, I’ve noticed that your tarballs (the ones in /tmp) are different From the ones I use. Does it raise a flag? Was there a change in the inputs? It’s likely that something changed in the inputs in the meantime. Ludo’.
Re: ‘--no-substitutes’ is ignored on i686
Nikita Karetnikov nik...@karetnikov.org skribis: • Guix must be usable with the old Guile 2.0.5, since that’s what some distros provide. At the GHM I realized that some people had weird bugs with that Guile, notably in the substituter. I fixed a couple of bugs, but there may be others around. So, to 2.0.5 users: please run ‘make check’, use Guix and in particular the substituter, and report bugs! I’m using the latest version of Guile. And I’ve already mentioned this (though, it might be a new issue): ‘--no-substitutes’ doesn’t work on my system at all. It’s completely ignored. (I haven’t tested on a different machine.) In which command? guix build, guix package, guix-daemon? Ludo’.
Add Mercurial to version-control.scm
Hi, Here’s a patch to add Mercurial as package: --- /usr/local/share/guile/site/2.0/gnu/packages/version-control.scm 2013-09-04 16:27:21.495618474 +0200 +++ /home/arne/version-control.scm 2013-09-06 11:13:57.080871243 +0200 @@ -64,6 +64,26 @@ from a command line or use a GUI application.) (license gpl2+))) +(define-public mercurial + (package +(name mercurial) +(version 2.7.1) +(source + (origin + (method url-fetch) + (uri (string-append http://mercurial.selenic.com/release/mercurial-; version .tar.gz)) + (sha256 + (base32 +121m8f7vmipmdg00cnzdz2rjkgydh28mwfirqkrbs5fv089vywl4 +(build-system python-build-system) +(home-page http://mercurial.selenic.com;) +(synopsis Decentralized version control system) +(description + Mercurial is a free, distributed source control management tool. +It efficiently handles projects of any size and offers an easy and intuitive interface.) +(license gpl2+))) + + (define-public subversion (package (name subversion) I put Mercurial between bazaar and subversion to keep alphabetic ordering. Later items might not be ordered alphabetically, but that’s out of my responsibility :) Best wishes, Arne
Re: Naming scheme for Python packages
On Thu, Sep 05, 2013 at 03:00:27PM +0200, Ludovic Courtès wrote: BTW, I haven’t check whether this is the case already, but we need something like (define (package-with-explicit-python p python) ;; Return a version of P built for PYTHON. (package (inherit p) ...)) so we can just write: (define python2-pytz (package-with-explicit-python python-pytz python-2)) The attached patch does almost this, following our offline discussion on how to create packages recursively on the fly: - It adds an argument pair #:python ,python-2, or replaces an already present argument #:python something-else, and this recursively for all inputs and native-inputs that use the python build system. - It rewrites the corresponding names from python-... to python2-..., or adds a prefix python2-. So one can write (define python2-pytz (package-with-explicit-python python-pytz)) As the second argument would always be python-2, I decided to drop it. When trying this with python2-babel, the previous code in python.scm (commented out in the attached patch) and the new one create almost the same derivations, that differ only in /nix/store/4rrnwqsj8c086zzviyypr4fikb7pz49v-python2-babel-0.9.6-guile-builder vs. /nix/store/5prbhg600qa9k8p0bgjs12p4dm682gn8-python2-babel-0.9.6-guile-builder so that the final hash is also different. Comments are welcome. Andreas diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm index ce89281..aa2d15c 100644 --- a/gnu/packages/python.scm +++ b/gnu/packages/python.scm @@ -28,6 +28,7 @@ #:use-module (gnu packages patchelf) #:use-module (guix packages) #:use-module (guix download) + #:use-module (guix utils) #:use-module (guix build-system gnu) #:use-module (guix build-system python) #:use-module (guix build-system trivial)) @@ -215,9 +216,7 @@ using Python 2.4 or higher and provides access to the Olson timezone database.) (license x11))) (define-public python2-pytz - (package (inherit python-pytz) -(name python2-pytz) -(arguments (append (package-arguments python-pytz) `(#:python ,python-2) + (package-with-python2 python-pytz)) (define-public python-babel (package @@ -233,7 +232,8 @@ using Python 2.4 or higher and provides access to the Olson timezone database.) 03vmr54jq5vf3qw6kpdv7cdk7x7i2jhzyf1mawv2gk8zrxg0hfja (build-system python-build-system) (inputs - `((python-pytz ,python-pytz))) + `((python-pytz ,python-pytz) + (openssl ,openssl))) (arguments `(#:tests? #f)) ; no test target (home-page http://babel.edgewall.org/;) (synopsis @@ -246,9 +246,12 @@ access to various locale display names, localized number and date formatting, etc. ) (license bsd-3))) +;; (define-public python2-babel +;; (package (inherit python-babel) +;; (name python2-babel) +;; (inputs +;; `((python2-pytz ,python2-pytz))) +;; (arguments (append (package-arguments python-babel) `(#:python ,python-2) + (define-public python2-babel - (package (inherit python-babel) -(name python2-babel) -(inputs - `((python2-pytz ,python2-pytz))) -(arguments (append (package-arguments python-babel) `(#:python ,python-2) + (package-with-python2 python-babel)) diff --git a/guix/build-system/python.scm b/guix/build-system/python.scm index 7ac93b2..a704d35 100644 --- a/guix/build-system/python.scm +++ b/guix/build-system/python.scm @@ -41,6 +41,56 @@ (let ((python (resolve-interface '(gnu packages python (module-ref python 'python-wrapper))) +(define (default-python2) + Return the default Python 2 package. + (let ((python (resolve-interface '(gnu packages python +(module-ref python 'python-2))) + +(define-public (package-with-python2 p) + Create a package with the same fields as P, which is assumed to use +PYTHON-BUILD-SYSTEM and to be compiled with the default python, such that +it is compiled with python 2 instead. The name of P is prefixed with +\python2-\; a potential existing prefix \python-\ is dropped. + (let ((rewrite (lambda (x) + ;; procedure taking a two-element list (name package) + ;; and returning a two element list + ;; (name (package-with-python2 package)) + (let ((name (car x)) + (content (car (cdr x + (list name + (if (package? content) + (package-with-python2 content) + content) +(build-system (package-build-system p))) +(package (inherit p) + (name +(let ((name (package-name p))) + (if (eq? build-system python-build-system) +(string-append python2- + (if (string-prefix? python- name) + (substring name 7) + name)) +name))) + (arguments +(let ((arguments
Should ‘./configure’ fail when makeinfo is missing?
Should ‘./configure’ check for makeinfo? ‘make’ will fail when makeinfo isn’t installed. pgp6b8ytEaZGE.pgp Description: PGP signature
Re: Agreeing on some rules for packaging.
I’ve just fixed a small bug [1]. Maybe we should agree to run make distclean ./boostrap ./configure make make check before pushing, or will it be too tedious? Also, I don’t like the ‘license:’ prefix. What about something like ‘l:’? It’ll probably be even better to use ‘#:select’ when it’s possible. [1] http://git.savannah.gnu.org/cgit/guix.git/commit/?id=a129e0d877f125693f58457d55973d184468b461 pgppVhZC5MCZi.pgp Description: PGP signature
Re: ‘--no-substitutes’ is ignored on i686
In which command? guix build, guix package, guix-daemon? ‘guix build’ and ‘guix package’ when ‘guix-daemon’ runs without ‘--no-substitutes’. (I was able to reproduce this on a different i686 machine.) When the daemon uses the mentioned option, ‘guix build’ and ‘guix package’ work as expected. pgpSipfBxF28i.pgp Description: PGP signature
Re: Online hackathon ?
On 09/07/2013 02:35 PM, Ludovic Courtès wrote: Jason Self ja...@bluehome.net skribis: There will also be a hackathon going on at the GNU Project's 30th anniversary [0] in Boston if anyone's interested in meeting in person there. It could probably be coordinated with an online hackathon too. Based on Libby's message [1] it might be possible to coordinate something for Guix too. We haven’t heard from our Hackaton Manager, but I think ey (Cyril) mentioned liking the idea of having the hackaton on that occasion. Oh right, forgot to write an email about that, but as discussed on IRC (iirc), I think it'd be best to have our online Hackathon at this date. Cyril.
Re: New ‘--list-generations’ and ‘--delete-generations’ options
I’m asking because if we do that, ‘--list-generations’ may just as well print out *all* the generation records. Users who want to select only less than one-month old generations can do that with ‘recsel’, and we don’t have anything more to do. WDYT? I see recutils as an advanced option (for those who need it), not a replacement for the basic functionality. OTOH, for ‘--delete-generations’ it will still be more convenient to support ‘--delete-generations’. Could you rephrase? I don’t understand the above. I believe we should think from a user’s perspective. One should be able to select the needed generations without relying on a different program. I think you find it difficult to test because the parsing and generation enumeration are intermingled. Right, I agree. What about splitting it in two functions: ‘string-time-range’ → return two SRFI-19 time objects representing a time interval, or #f and #f on failure ‘generation-within-time-range?’ Writing tests for the former will be easy. What do you think of the separation I proposed? We have the following cases: ‘1’, ‘1,2,3’, ‘1..9’, ‘1..’, ‘..9’, ‘first-month’, and ‘last-month’. It’s easy to parse the first three and output a list of generations without checking them. However, you’ll have to check the profile in the other cases. That’s the problem. It’s also possible to write something like this (untested): (define (available-generations str) (define (integer?*) (integer? (string-number str))) (define (comma-separated-integers?) (every integer? (delete-duplicates (map string-number (delete (string-split str #\,)) (define (safe-match:substring-number match n) (false-if-exception (string-number (match:substring match n (define (maybe-whole-range-lst) (let* ((rx (make-regexp ^([0-9]+)\\.\\.([0-9]+)$)) (res (regexp-exec rx str)) (x (safe-match:substring-number res 1)) (y (safe-match:substring-number res 2))) (list x y))) (define (whole-range?) (let ((x (first maybe-whole-range-lst)) (y (last maybe-whole-range-lst))) (and (every integer? (maybe-whole-range-lst)) (= x y (define (maybe-start-range) (let* ((rx (make-regexp ^([0-9]+)\\.\\.$)) (res (regexp-exec rx str))) (safe-match:substring-number res 1))) (define (start-range?) (integer? (maybe-start-range))) ;; ... ) First, this is quite wordy. Moreover, we’ll have to move every definition to the global namespace if we want to test only syntax. I doubt that the above is the way to go. I don’t understand how the ‘string-time-range’ function will help to solve the above problem. There are only two time-related cases: ‘first-month’ and ‘last-month’. Why do you want to return a time range for every case? Could you show an example? pgpPfOC9czbab.pgp Description: PGP signature
Re: ‘--no-substitutes’ is ignored on i686
I can confirm this bug on i686. The same happens with guix package --no-substitutes -i gnupg. On x86-64, everything works as expected. Does it mean that the daemon is the cause of the problem since the error is platform-specific? Also, note this line: The following derivations will be built: … pgp4ffMtyQdIf.pgp Description: PGP signature
Re: Python 3 binaries
Hello, time to give a quick update! What I implemented in the python branch, following the discussions on the list, is the following: On Mon, Sep 02, 2013 at 08:24:48AM +0200, Brandon Invergo wrote: Then that means we don’t really have to worry, and just document that the python-3.x package is an unmodified upstream package, with its binary is called ‘python3’. I think that is a fine way to do it. The most important part is internal consistency. It seems that the unmodified upstream strategy is the path of least resistance, and it will fit with the expectations of all of the Debian-based users out there. There are unmodified binaries for Python 2.7.5 and Python 3.3.2 (which should probably be updated to 3.4.0). As for the shebangs, you may well still have to do some patching for some packages, if they were written in python3 but the shebang is for /usr/bin/python. Then there is a package called python-wrapper, which simply adds the following symlinks into the Python 3 bin/ directory: idle - idle3 pydoc - pydoc3 python - python3 It is used internally as an input, so that shebangs need not be rewritten; but users may also install it if they wish Python 3 binaries known under the name of python etc., without also installing Python 2. Simple packages compile, and once a few problems with the build system are solved, I should be able to add setuptools, which will pave the way for more modules. Andreas
Re: MIPS64/N64 support
Nikita Karetnikov nik...@karetnikov.org skribis: 3. Created ‘mips64el-linux-gnuabi64’ in ‘gnu/packages/bootstrap/’. Hmm, I think we should just call it ‘mips64el-linux’ since the ABI is really something orthogonal. I’ve already tried that: $ ./pre-inst-env guix build -K -s mips64el-linux-gnuabi64 hello […] ERROR: bootstrap binary not found tar mips64el-linux-gnuabi64 How would you change ‘bootstrap.scm’ to handle this? As I wrote, call it ‘mips64el-linux’, and put the binaries under the directory of that name. * It’s 2.0.9. I decided not to touch ‘%bootstrap-guile’ for now to avoid errors. What do you mean? ‘%bootstrap-guile’ needs to refer to that new tarball, right? Yes, ‘%bootstrap-guile’ expects a binary called ‘guile-2.0.7.tar.xz’: (guile (-store guile-2.0.7.tar.xz)) Aah, right. Well, either call it this way, or do something like: (-store (if (string=? (%current-system) mips64el-linux) guile-2.0.9.tar.xz guile-2.0.7.tar.xz)) HTH, Ludo’.
Re: Naming scheme for Python packages
Andreas Enge andr...@enge.fr skribis: On Sun, Sep 08, 2013 at 04:03:23PM +0200, Ludovic Courtès wrote: Andreas Enge andr...@enge.fr skribis: separate ‘package-with-name-prefix’ procedure, such that we would do: (define package-with-python-2 (compose (cut package-with-name-prefix python2-) (cut package-with-explicit-python python-2))) WDYT? I think one function is enough; there is not much benefit in striving for maximal generality here, since these two operations should always be linked in our context. Yeah, right. (I would use an internal ‘define’ like this, rather than ‘let’, to introduce the ‘rewrite’ procedure; that doesn’t change the semantics, but I find it easier to read.) Ah, but that is less functional, no? ;-) No; internal ‘define’ is just syntactic sugar equivalent to ‘letrec*’. Thanks for the other suggestions, which look quite interesting. The current solution looks easier to a Scheme neophyte like me, and as there is no major objection, I am going to push the patch as it is. This will allow us to go forward with the other problems in the python build system, and hopefully package a few more modules! Excellent, thanks! Ludo’.
Re: Online hackathon ?
Andreas Enge andr...@enge.fr skribis: On Sat, Sep 07, 2013 at 02:35:01PM +0200, Ludovic Courtès wrote: Jason Self ja...@bluehome.net skribis: There will also be a hackathon going on at the GNU Project's 30th anniversary [0] in Boston if anyone's interested in meeting in person there. It could probably be coordinated with an online hackathon too. Based on Libby's message [1] it might be possible to coordinate something for Guix too. We haven’t heard from our Hackaton Manager, but I think ey (Cyril) mentioned liking the idea of having the hackaton on that occasion. Another option would be to have it coincide with the 30th anniversary celebrations in Paris in two weeks: http://www.april.org/celebrer-les-30-ans-de-gnu-le-21-septembre-2013-paris-8 I will probably go there, is anyone else going to attend? I won’t. In the meantime I had emailed Libby of the FSF mentioning Sep. 28th. So you’ll have the 21st to chat in Paris, and the 28th to hack. ;-) Ludo’.
Re: New ‘--list-generations’ and ‘--delete-generations’ options
Nikita Karetnikov nik...@karetnikov.org skribis: I’m asking because if we do that, ‘--list-generations’ may just as well print out *all* the generation records. Users who want to select only less than one-month old generations can do that with ‘recsel’, and we don’t have anything more to do. WDYT? I see recutils as an advanced option (for those who need it), not a replacement for the basic functionality. Yeah, possibly. In that case, would you suggest --list-generations=rec to specify the recutils output format (with no filtering)? OTOH, for ‘--delete-generations’ it will still be more convenient to support ‘--delete-generations’. Could you rephrase? Oops, sorry; this should read: OTOH for ‘--delete-generations’ it will be more convenient to support date-range specifications such as ‘last-month’, etc. I don’t understand the above. I believe we should think from a user’s perspective. One should be able to select the needed generations without relying on a different program. Yes. What about splitting it in two functions: ‘string-time-range’ → return two SRFI-19 time objects representing a time interval, or #f and #f on failure ‘generation-within-time-range?’ Writing tests for the former will be easy. What do you think of the separation I proposed? We have the following cases: ‘1’, ‘1,2,3’, ‘1..9’, ‘1..’, ‘..9’, ‘first-month’, and ‘last-month’. It’s easy to parse the first three and output a list of generations without checking them. However, you’ll have to check the profile in the other cases. That’s the problem. [...] I don’t understand how the ‘string-time-range’ function will help to solve the above problem. There are only two time-related cases: ‘first-month’ and ‘last-month’. Why do you want to return a time range for every case? Could you show an example? Sorry I think I have been sloppy. So we want to support generation enumerations like ‘1,2,3’, ranges (incl. open-ended ranges) like ‘1..9’, and age specifications. For the first one, I would do a ‘string-generations’ procedure: 1,2,3 ⇒ (1 2 3) 1..9 ⇒ (1 2 3 4 5 6 7 8 9) ..9⇒ (= 9) ; with the ‘=’ symbol 1..⇒ (= 1) foo⇒ #f Age specifications would only be of the kind “at least X days/months old”. A non-ambiguous syntax is needed, and something more flexible than just ‘last-month’. Let’s assume ‘string-duration’: +22⇒ #time time-duration ... ; 22 days +2w⇒ #time time-duration ... ; 14 days +1m⇒ #time time-duration ... ; 30 days Then one just needs to ‘filter’ all the generations that match the specification. This way, there are two parsing procedures, and one or two filtering procedures. These are just suggestions, but that seems to make more sense now. WDYT? Apologies for the confusion! Thanks, Ludo’.
Re: MIPS64/N64 support
I’ve already tried that: $ ./pre-inst-env guix build -K -s mips64el-linux-gnuabi64 hello […] ERROR: bootstrap binary not found tar mips64el-linux-gnuabi64 As I wrote, call it ‘mips64el-linux’, and put the binaries under the directory of that name. I did that but forgot to adjust ‘-s mips64el-linux-gnuabi64’. So I’ve just tried this command: $ ./pre-inst-env guix build -K -s mips64el-linux hello The bootstrap Guile binary that I fetched from Hydra [1] aborts when ‘./guile --version’ is called. But this one works [2]. What has happened? I’ve also tested ‘./tar --version’ (the one from Hydra), and it works. Could you run the following command and paste the hashsums? $ ./pre-inst-env guix build bootstrap-tarballs -s x86_64-linux --target=mips64el-linux-gnuabi64 [1] https://lists.gnu.org/archive/html/guix-devel/2013-09/msg00046.html [2] http://www.fdn.fr/~lcourtes/tmp/guile-static-stripped-2.0.9-mips64el-linux-gnuabi64.tar.xz pgpOFX8m34qoq.pgp Description: PGP signature
Re: Python-build-system does not honour phases
On Tue, Sep 10, 2013 at 10:26:55AM +0200, Andreas Enge wrote: Maybe we should try to use a variable name %python-standard-phases instead. The attached patch to guix/build/python-build-system.scm does just this and works. Would it make sense to push it? The part of the patch adding python-setuptools is not finished yet. Installation ends with the contradictory error message running install Checking .pth file support in /nix/store/dwfvjk9rii9xyshfd6snny590a82bbfq-python-setuptools-1.1.4/lib/python3.3/site-packages/ /nix/store/fqg4h8afvnh7c0l2pqrid0wsjldp03sh-python-wrapper-3.3.2/bin/python -E -c pass TEST FAILED: /nix/store/dwfvjk9rii9xyshfd6snny590a82bbfq-python-setuptools-1.1.4/lib/python3.3/site-packages/ does NOT support .pth files error: bad install directory or PYTHONPATH You are attempting to install a package to a directory that is not on PYTHONPATH and which Python does not read .pth files from. The installation directory you specified (via --install-dir, --prefix, or the distutils default setting) was: /nix/store/dwfvjk9rii9xyshfd6snny590a82bbfq-python-setuptools-1.1.4/lib/python3.3/site-packages/ and your PYTHONPATH environment variable currently contains: '/nix/store/dwfvjk9rii9xyshfd6snny590a82bbfq-python-setuptools-1.1.4/lib/python3.3/site/packages/' Here are some of your options for correcting the problem: * You can choose a different installation directory, i.e., one that is on PYTHONPATH or supports .pth files * You can add the installation directory to the PYTHONPATH environment variable. (It must then also be on PYTHONPATH whenever you run Python and want to use the package(s) you are installing.) * You can set up the installation directory to support .pth files by using one of the approaches described here: https://pythonhosted.org/setuptools/easy_install.html#custom-installation-locations Please make the appropriate changes for your system and try again. From what I can tell, I followed exactly the second approach. Does any of the python specialists understand what is happening? Andreas diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm index 3ff4da2..a8f8c9d 100644 --- a/gnu/packages/python.scm +++ b/gnu/packages/python.scm @@ -247,3 +247,44 @@ etc. ) (define-public python2-babel (package-with-python2 python-babel)) + +(define-public python-setuptools + (package +(name python-setuptools) +(version 1.1.4) +(source + (origin + (method url-fetch) + (uri (string-append https://pypi.python.org/packages/source/s/setuptools/setuptools-; + version .tar.gz)) + (sha256 + (base32 +0hl9sa5xr9bi2ifq51wy1bawsjv5nzvpbac7m9z1ciz778874csf +(build-system python-build-system) +(arguments + `(#:tests? #f ; FIXME: try to run tests + #:phases + (alist-replace + 'install + (lambda* (#:key outputs #:allow-other-keys #:rest args) +(let* ((install (assoc-ref %python-standard-phases 'install)) + (out (assoc-ref outputs out)) + (path (string-append out /lib/python3.3/site/packages/))) + (mkdir-p path) + (setenv PYTHONPATH path) + (format #t XXX ~a XXX~% (getenv PYTHONPATH)) + (apply install args))) + %python-standard-phases))) +(home-page https://pypi.python.org/pypi/setuptools;) +(synopsis + Library designed to facilitate packaging Python projects) +(description + Setuptools is a fully-featured, stable library designed to facilitate +packaging Python projects, where packaging includes: +Python package and module definitions, +distribution package metadata, +test hooks, +project installation, +platform-specific details, +Python 3 support.) +(license psfl))) diff --git a/guix/build/python-build-system.scm b/guix/build/python-build-system.scm index f213a97..14cd086 100644 --- a/guix/build/python-build-system.scm +++ b/guix/build/python-build-system.scm @@ -19,14 +19,13 @@ ;;; along with GNU Guix. If not, see http://www.gnu.org/licenses/. (define-module (guix build python-build-system) - #:use-module ((guix build gnu-build-system) -#:renamer (symbol-prefix-proc 'gnu:)) + #:use-module (guix build gnu-build-system) #:use-module (guix build utils) #:use-module (ice-9 match) #:use-module (ice-9 ftw) #:use-module (srfi srfi-1) #:use-module (srfi srfi-26) - #:export (%standard-phases + #:export (%python-standard-phases python-build)) ;; Commentary: @@ -91,7 +90,7 @@ files))) bindirs))) -(define %standard-phases +(define %python-standard-phases ;; 'configure' and 'build' phases are not needed. Everything is done during ;; 'install'. (alist-cons-after @@ -103,11 +102,11 @@ 'check check (alist-replace 'install install (alist-delete 'configure -
Re: Python-build-system does not honour phases
On Tue, Sep 10, 2013 at 07:48:30PM +0200, Ludovic Courtès wrote: You’re mixing different things: the line above is on the host side, whereas the patch I proposed changes the modules imported on the build side. Okay, I get it! Can you try this patch to check the value of ‘phases’? Without your previous patch, I get the following: ;;; (the-python-phases ((set-paths . #procedure set-paths (#:key target inputs native-inputs search-paths native-search-paths)) (unpack . #procedure unpack (#:key source)) (patch . #procedure patch (#:key patches patch-flags)) (patch-source-shebangs . #procedure patch-source-shebangs (#:key source)) (configure . #procedure configure (#:key target native-inputs inputs outputs configure-flags out-of-source?)) (patch-generated-file-shebangs . #procedure patch-generated-file-shebangs rest) (build . #procedure build (#:key make-flags parallel-build?)) (check . #procedure check (#:key target make-flags tests? test-target parallel-tests?)) (install . #procedure 1c90070 at ice-9/eval.scm:264:7 %args) (patch-shebangs . #procedure patch-shebangs (#:key outputs patch-shebangs?)) (strip . #procedure strip (#:key target outputs strip-binaries? strip-command objcopy-command strip-flags strip-directories WARNING: (guile-user): `%standard-phases' imported from both (guix build python-build-system) and (guix build gnu-build-system) After applying your previous patch, I get this: ;;; (the-python-phases ((set-paths . #procedure set-paths (#:key target inputs native-inputs search-paths native-search-paths)) (unpack . #procedure unpack (#:key source)) (patch . #procedure patch (#:key patches patch-flags)) (patch-source-shebangs . #procedure patch-source-shebangs (#:key source)) (patch-generated-file-shebangs . #procedure patch-generated-file-shebangs rest) (build . #procedure build empty) (check . #procedure check (#:key tests? test-target)) (install . #procedure b92230 at ice-9/eval.scm:264:7 %args) (wrap . #procedure wrap (#:key inputs outputs)) (patch-shebangs . #procedure patch-shebangs (#:key outputs patch-shebangs?)) (strip . #procedure strip (#:key target outputs strip-binaries? strip-command objcopy-command strip-flags strip-directories So indeed, your patch solves the confusion! Thanks, I will push it then. Andreas
Re: Compiling guix 0.3 on a fedora 8 planetlab node
Matthias Wachs wa...@net.in.tum.de skribis: On Thu, 2013-08-29 at 23:31 +0200, Ludovic Courtès wrote: Andreas Enge andr...@enge.fr skribis: PS: For work on gnunet, it would be preferable to clone the git repository, which contains a few dependencies not yet available in 0.3. ... or you can install 0.3 and run “guix pull” to get them. Ludo’. Thx for your help ... I would prefer the guix pull approach, but pull fails on my local machine as well as on the planetlab nodes... Any idea about that? It could indicate that something’s broken in the distro, or that something’s broken in how ‘pull’ compiles things. Could you apply the patch at http://git.sv.gnu.org/cgit/guix.git/commit/?id=bda44eed939ae251a21ad3cd1337c58e8d349581, and try again? TIA, Ludo’.
Re: Python-build-system does not honour phases
So the next module python-dateutil works. But again, python setup.py install complains that the path it wishes to install to, /nix/store/q637nhgrixha1f8cfl32l6gvviha737g-python2-dateutil-1.5/lib/python2.7/site-packages does not exist and is not in PYTHONPATH. So I added the following: `(#:phases (alist-replace 'install (lambda* (#:key outputs #:allow-other-keys #:rest args) (let* ((install (assoc-ref %standard-phases 'install)) (out (assoc-ref outputs out)) (python (assoc-ref %build-inputs python)) (python-version (string-take (string-take-right python 5) 3)) (path (string-append out /lib/python python-version /site-packages/))) (mkdir-p path) (setenv PYTHONPATH (string-append (getenv PYTHONPATH) : path)) (apply install args))) %standard-phases))) which is (a refined version of) the expression for python-setuptools. We need to factor this out. I suggest to do the following: In the install phase, before running setup.py, we create the directory and add it to the python path. But this would only be needed for programs creating modules, and I suppose not for programs that only create executables. I see two solutions: - We create the directory anyway, and try to remove it after installation with rmdir -p. - Or more cleanly, we can add a variable #:module? (default: #f) and create the directory only if this variable is set to #t. What do you think? Andreas
Re: Python-build-system does not honour phases
Andreas Enge andr...@enge.fr skribis: We need to factor this out. I suggest to do the following: In the install phase, before running setup.py, we create the directory and add it to the python path. But this would only be needed for programs creating modules, and I suppose not for programs that only create executables. I see two solutions: - We create the directory anyway, and try to remove it after installation with rmdir -p. - Or more cleanly, we can add a variable #:module? (default: #f) and create the directory only if this variable is set to #t. What do you think? It think it’s OK to create it anyway, and not even try to remove it, because packages that use ‘python-build-system’ surely have Python modules to install, no? Ludo’.
Re: Python-build-system does not honour phases
Andreas Enge andr...@enge.fr skribis: So indeed, your patch solves the confusion! Excellent, thanks! Ludo’.
Re: Python-build-system does not honour phases
Andreas Enge andr...@enge.fr skribis: On Tue, Sep 10, 2013 at 10:26:55AM +0200, Andreas Enge wrote: Maybe we should try to use a variable name %python-standard-phases instead. The attached patch to guix/build/python-build-system.scm does just this and works. Would it make sense to push it? No, I prefer to understand what’s going on and DTRT. The part of the patch adding python-setuptools is not finished yet. Installation ends with the contradictory error message [...] You are attempting to install a package to a directory that is not on PYTHONPATH and which Python does not read .pth files from. The installation directory you specified (via --install-dir, --prefix, or the distutils default setting) was: /nix/store/dwfvjk9rii9xyshfd6snny590a82bbfq-python-setuptools-1.1.4/lib/python3.3/site-packages/ and your PYTHONPATH environment variable currently contains: '/nix/store/dwfvjk9rii9xyshfd6snny590a82bbfq-python-setuptools-1.1.4/lib/python3.3/site/packages/' The error seems to be that we use ‘site-packages’ when it expects ‘site/packages’. The latter is clearly wrong, but I couldn’t find where it comes from (perhaps you fixed it in the meantime?). Ludo’.
Re: Python-build-system does not honour phases
Andreas Enge andr...@enge.fr skribis: On Mon, Sep 09, 2013 at 11:35:55PM +0200, Ludovic Courtès wrote: The problem is that both the gnu-build-system and the python-build-system were getting imported, and both export a ‘%standard-phases’. That is what I thought. I tried to add a #:use-module ((guix build-system gnu) #:select (gnu-build-system)) but that was not enough. You’re mixing different things: the line above is on the host side, whereas the patch I proposed changes the modules imported on the build side. The fix is to use only python-build-system: That also does not seem to work. Could you be more specific? :-) With the patch I sent, the builder should start with: (begin (use-modules (guix build python-build-system) (guix build utils)) ...) So the global variable named ‘%standard-phases’ here is necessarily that of (guix build python-build-system). Can you try this patch to check the value of ‘phases’? diff --git a/guix/build/python-build-system.scm b/guix/build/python-build-system.scm index 8429979..1b5eaa8 100644 --- a/guix/build/python-build-system.scm +++ b/guix/build/python-build-system.scm @@ -96,6 +96,6 @@ (define* (python-build #:key inputs (phases %standard-phases) #:allow-other-keys #:rest args) Build the given Python package, applying all of PHASES in order. - (apply gnu:gnu-build #:inputs inputs #:phases phases args)) + (apply gnu:gnu-build #:inputs inputs #:phases (pk 'the-python-phases phases) args)) ;;; python-build-system.scm ends here [...] Maybe we should try to use a variable name %python-standard-phases instead. That would be cheating. ;-) And really, it’s unnecessary. Ludo’.
Re: New ‘--list-generations’ and ‘--delete-generations’ options
How can I subtract 22 days from (current-time) using SRFI-19? Note that the above example suggests that ‘string-duration’ returns a time object with of type ‘time-duration’ (thus independent of the current time.) Ah, OK. But we’ll have to subtract from (current-time) later anyway, right? Why do you want to return a ‘time-duration’ object? So, here’s the parsing phase. WDYT? (use-modules (srfi srfi-1) (srfi srfi-19) (ice-9 regex)) ;;; ;;; Parsing. ;;; (define (string-generations str) (define (maybe-integer) (let ((x (string-number str))) (and (integer? x) (list x (define (maybe-comma-separated-integers) (let ((lst (delete-duplicates (map string-number (delete (string-split str #\,)) (and (every integer? lst) lst))) (define (safe-match:substring-number match n) (false-if-exception (string-number (match:substring match n (define (maybe-whole-range) (let* ((rx (make-regexp ^([0-9]+)\\.\\.([0-9]+)$)) (res (regexp-exec rx str)) (x (safe-match:substring-number res 1)) (y (safe-match:substring-number res 2))) (and (every integer? (list x y)) (= x y) (iota (1+ (- y x)) x (define (maybe-start-range) (let* ((rx (make-regexp ^([0-9]+)\\.\\.$)) (res (regexp-exec rx str)) (x (safe-match:substring-number res 1))) (and (integer? x) `(= ,x (define (maybe-end-range) (let* ((rx (make-regexp ^\\.\\.([0-9]+)$)) (res (regexp-exec rx str)) (x (safe-match:substring-number res 1))) (and (integer? x) `(= ,x (or (maybe-integer) (maybe-comma-separated-integers) (maybe-whole-range) (maybe-start-range) (maybe-end-range))) (define (string-duration str) (define (maybe-duration hours pattern) (let ((res (regexp-exec (make-regexp pattern) str))) (false-if-exception (make-time time-duration 0 (* 3600 hours (string-number (match:substring res 1))) (define (days) (maybe-duration 24 ^([0-9]+)d$)) (define (weeks) (maybe-duration (* 24 7) ^([0-9]+)w$)) (define (months) (maybe-duration (* 24 30) ^([0-9]+)m$)) (or (days) (weeks) (months))) pgpmILa9DDx6h.pgp Description: PGP signature
Re: Python-build-system does not honour phases
On Tue, Sep 10, 2013 at 11:34:29PM +0200, Andreas Enge wrote: Maybe. Bazaar does. Calibre creates elf executables, but also installs python modules. So I will go ahead with this. Okay, done in commit 824af8cadc1b4f1ac7a859f3d18cbe69b195a844, and used for python(2)-setuptools and a new package already. Andreas
GNU30 Security Hackathon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, your project is part of the selection for the GNU30 hackathon listed at http://www.gnu.org/gnu30/celebration In the course of the anniversary, there's a security conference in Buenos Aires, called Ekoparty, and I'm willing to organize a GNU security hackathon there. [0] Here is how it's supposed to work. Security hackers will be invited to do one of the following things: (1) Report zeroday vulnerabilities (2) Fix security or privacy bugs (3) Create, or give away security tools to the GNU project My objective with this email is to gather a list of suggestions as to where to put the effort on your various projects, in order to make it more convenient for them to choose. I'm willing to gather security-related bugs that they can look into and fix over a period of 3 days (obviously not full time), or ideas for useful tools related to privacy or security. Any suggestion welcome! Feel free to share this message in full or in parts with your fellow hackers. The sooner I get answers, and the better the participants can get ready and explore possibilities. Regards, and happy hacking! == hk [0] http://ekoparty.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCgAGBQJSMG0dAAoJEEgGw2P8GJg9rggP/0Gq5yQi61mz3/YiRYcEKzT0 geFlgVukY8IHA+CJkz3XkX8GcHBplCSxiRgRwCIwdfkamWWonzlU10sL2E9qfOcT 9lkmXHbUexh8YuJGGoTDqPbsuISCxfP7gtfPwvZGXtuf1jMQE75mrV1/qrcYZztt LmDF6USqYZEDB7QKF82uVyYNuJuvmuhByXgCTsJp5Ac+vfsrsLAC+D+LmhNxoTOk 6fZghCUcglFWbMaMNbIudb0L+b43Zbhp7Cc9ZxDwb4xjeSUkHNbSg+YIDVac0/Hh ac1UMAUuRMkFvPpWUPvvfh5Sp2YHF4jomVJn4jd+bKoOwIAiDn311KA4g6a7pkjz XyTCxG6noyM3o5QmuHOpr5EBzM1qfqm2uzYoGmUz4OWrzdUixOuNz5y6AVrLvHiG fA8jBveMrIwd1izohMpjnjXkfsn1dMt0qRdpyqEjjx8nnk1V7Ahw1auRdatSsDG7 DdAXrjG/8q1jCOH6GAgfElFPacQa0/Ms9v0DGXMkVU82SzCLmj4DhaX77ufSYF9T 5qCoskECq+0Ha8/Go278BKzM3S1DeRQHQfc3LNQyAccQzhz/6/YZycZ5FUfSiXLg /WWYuxTD8wmLluQMShOVZzP8O9uukwRjIOQ34RRehn/FG1dQRmMH7rTtsRo4ag8h HK7o2h1kEziCg7lsDGwZ =yfnR -END PGP SIGNATURE-
Re: GNU30 Security Hackathon
On Wed, 2013-09-11 at 10:16 -0300, hellekin wrote: your project is part of the selection for the GNU30 hackathon listed at http://www.gnu.org/gnu30/celebration Oh. This doesn't sound like sensitive material at all. May I forward it to our public dev list? - Jordi G. H.
Re: Python-build-system does not honour phases
Andreas Enge andr...@enge.fr skribis: On Tue, Sep 10, 2013 at 11:34:29PM +0200, Andreas Enge wrote: Maybe. Bazaar does. Calibre creates elf executables, but also installs python modules. So I will go ahead with this. Okay, done in commit 824af8cadc1b4f1ac7a859f3d18cbe69b195a844, and used for python(2)-setuptools and a new package already. Nice, thanks! Ludo’.
[PATCH] gnu: Add gobject-introspection.
* gnu/packages/gnome.scm: New file. * gnu-system.am: Add it. --- gnu-system.am |1 + gnu/packages/gnome.scm | 72 2 files changed, 73 insertions(+) create mode 100644 gnu/packages/gnome.scm This works fine on i686, but fails on x86-64 with: ERROR: can't resolve libraries to shared libraries: gobject-2.0, glib-2.0 Any idea why ? Also, some bits are gpl2+, other are lgpl2+, what should I use in the 'license' field ? Cyril. diff --git a/gnu-system.am b/gnu-system.am index 8712546..3c9e0db 100644 --- a/gnu-system.am +++ b/gnu-system.am @@ -69,6 +69,7 @@ GNU_SYSTEM_MODULES = \ gnu/packages/gkrellm.scm \ gnu/packages/glib.scm\ gnu/packages/global.scm \ + gnu/packages/gnome.scm \ gnu/packages/gnunet.scm \ gnu/packages/gnupg.scm \ gnu/packages/gnutls.scm \ diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm new file mode 100644 index 000..f85b4bc --- /dev/null +++ b/gnu/packages/gnome.scm @@ -0,0 +1,72 @@ +;;; GNU Guix --- Functional package management for GNU +;;; Copyright © 2013 Cyril Roelandt tipec...@gmail.com +;;; +;;; 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/. + +(define-module (gnu packages gnome) + #:use-module (guix licenses) + #:use-module (guix packages) + #:use-module (guix download) + #:use-module (guix build-system gnu) + #:use-module (gnu packages) + #:use-module (gnu packages bison) + #:use-module (gnu packages gtk) + #:use-module (gnu packages flex) + #:use-module (gnu packages glib) + #:use-module (gnu packages libffi) + #:use-module (gnu packages pkg-config) + #:use-module (gnu packages python)) + +(define-public gobject-introspection + (package +(name gobject-introspection) +(version 1.37.6) +(source (origin + (method url-fetch) + (uri (string-append http://ftp.gnome.org/pub/GNOME/sources/; + gobject-introspection/1.37/gobject-introspection- + version .tar.xz)) + (sha256 + (base32 1ks0lfh8x72pgvgmnys19caajj34klqjfkqqp8fz9qhvk3vb9svf +(build-system gnu-build-system) +(inputs + `((bison ,bison) + (cairo ,cairo) + (flex ,flex) + (glib ,glib) + (libffi ,libffi) + (pkg-config ,pkg-config) + (python ,python))) +(arguments + `(#:phases +(alist-replace + 'configure + (lambda* (#:key #:allow-other-keys #:rest args) + (let ((configure (assoc-ref %standard-phases 'configure))) + ;; giscanner/sourcescanner.py looks for 'CC', let's set it here. + (setenv CC gcc) + (apply configure args))) + %standard-phases))) +(home-page https://wiki.gnome.org/GObjectIntrospection;) +(synopsis Generate interface introspection data for GObject libraries) +(description + GObject introspection is a middleware layer between C libraries (using +GObject) and language bindings. The C library can be scanned at compile time +and generate a metadata file, in addition to the actual native C library. Then +at runtime, language bindings can read this metadata and automatically provide +bindings to call into the C library.) +; Some bits are distributed under the LGPL2+, others under the GPL2+ +(license gpl2+))) -- 1.7.10.4
Re: New ‘--list-generations’ and ‘--delete-generations’ options
By definition submatches 1 and 2 exist when RES is true.
Thus, I’d remove ‘safe-match:substring-number’ and do:
(match (string-match ^([0-9]+)\\.\\.([0-9]+)$ str)
(#f #f)
(matches
(let ((start (number-string (match:substring matches 1)))
(end (number-string (match:substring matches 2
...)))
Done.
Probably this can reduce to a big ‘cond’, which would be even more
readable:
(cond ((maybe-integer)
=
list)
((string-match ^([0-9]+)\\.\\.([0-9]+)$ str)
=
(lambda (match)
...))
...)
Are you sure? I haven’t found a way to make ‘cond’ as readable as ‘or’.
I’m attaching a sketchy version. If you don’t see any problems, I’ll
try to integrate this code into ‘package.scm’.
(Something is wrong with the store on my machine, so I can’t properly
test the filtering part. But I’ll do it as soon as possible.)
(define-module (avail-generations)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-19)
#:use-module (srfi srfi-26)
#:use-module (ice-9 regex)
#:use-module (ice-9 match))
(define profile-numbers (@@ (guix scripts package) profile-numbers))
(define %current-profile (@@ (guix scripts package) %current-profile))
;;;
;;; Parsing.
;;;
(define (string-generations str)
(define (maybe-integer)
(let ((x (string-number str)))
(and (integer? x)
(list x
(define (maybe-comma-separated-integers)
(let ((lst (delete-duplicates
(map string-number
(delete (string-split str #\,))
(and (every integer? lst)
lst)))
(define (maybe-whole-range)
(match (string-match ^([0-9]+)\\.\\.([0-9]+)$ str)
(#f #f)
(res
(let ((s (string-number (match:substring res 1)))
(e (string-number (match:substring res 2
(and (every integer? (list s e))
(= s e)
(iota (1+ (- e s)) s))
(define (maybe-start-range)
(match (string-match ^([0-9]+)\\.\\.$ str)
(#f #f)
(res
(let ((s (string-number (match:substring res 1
(and (integer? s)
`(= ,s))
(define (maybe-end-range)
(match (string-match ^\\.\\.([0-9]+)$ str)
(#f #f)
(res
(let ((e (string-number (match:substring res 1
(and (integer? e)
`(= ,e))
(or (maybe-integer) (maybe-comma-separated-integers)
(maybe-whole-range) (maybe-start-range) (maybe-end-range)))
(define (string-duration str)
(define (maybe-duration hours pattern)
(match (string-match pattern str)
(#f #f)
(res
(make-time time-duration 0
(* 3600 hours (string-number (match:substring res 1)))
(define (days)
(maybe-duration 24 ^([0-9]+)d$))
(define (weeks)
(maybe-duration (* 24 7) ^([0-9]+)w$))
(define (months)
(maybe-duration (* 24 30) ^([0-9]+)m$))
(or (days) (weeks) (months)))
;;;
;;; Filtering.
;;;
(define* (available-generations str #:optional (profile %current-profile))
(define (valid-generations lst)
(define (valid-gen? n)
(any (cut = n ) (profile-numbers profile)))
(fold-right (lambda (x lst)
(if (valid-gen? x)
(cons x lst)
lst))
'()
lst))
;; XXX: find a better name for this function.
(define (filter-generations gens)
(match gens
(() '())
(('= n)
(drop-while (cut n )
;; XXX: is it really necessary to sort? Check
;; 'profile-numbers'.
(sort (profile-numbers profile) )))
(('= n)
(valid-generations (iota n 1)))
((lst ..1)
(valid-generations lst))
(_ #f)))
;; XXX: find a better name.
(define (filter-by-duration dur)
(define dates-gens
;; Return an alist of dates and generations.
(map (lambda (x)
(cons (and= (stat (format #f ~a-~a-link
;; XXX: Should I check that
;; 'number-string's argument is
;; actually a number? Can I
;; trust 'profile-numbers'?
profile (number-string x)))
stat:ctime)
x))
;; XXX: Is there a need to sort?
(sort (profile-numbers profile) )))
(define dates
(fold-right (lambda (x lst)
(cons (first x) lst))
'()
dates-gens))
(match dur
(#f #f)
(res
(let ((s (time-second (subtract-duration (current-time) dur
(map (cut assoc-ref dates-gens )
(filter (cut = s ) dates))
(cond ((string-generations str)
=
filter-generations)
((string-duration str)
=
Re: New ‘--list-generations’ and ‘--delete-generations’ options
Nikita Karetnikov nik...@karetnikov.org skribis: Probably this can reduce to a big ‘cond’, which would be even more readable: (cond ((maybe-integer) = list) ((string-match ^([0-9]+)\\.\\.([0-9]+)$ str) = (lambda (match) ...)) ...) Are you sure? I haven’t found a way to make ‘cond’ as readable as ‘or’. Yes, it makes it easier to enumerate all the cases, and to reason about it. For instance, in ‘string-generations’, getting rid of ‘maybe-*-range’ and instead inlining the ‘string-match’ calls in ‘cond’ would greatly clarify things IMO: (cond ((maybe-integer) ...) ((maybe-comma-separated-integers) ...) ((string-match p1 x) = ...) ((string-match p2 x) = ...) ((string-match p3 x) = ...) (else #f)) I’m attaching a sketchy version. If you don’t see any problems, I’ll try to integrate this code into ‘package.scm’. I’d prefer clearer case analysis as shown above. Thanks, Ludo’.
Re: GNU30 Security Hackathon
Hello, hellekin helle...@gnu.org skribis: My objective with this email is to gather a list of suggestions as to where to put the effort on your various projects, in order to make it more convenient for them to choose. I'm willing to gather security-related bugs that they can look into and fix over a period of 3 days (obviously not full time), or ideas for useful tools related to privacy or security. This sounds like a great initiative. For Guix, a bug that we have is that pre-built binaries downloaded from hydra.gnu.org are not cryptographically signed. Note that, unlike most other distros, binaries are not uploaded manually by the package maintainer; instead, the build farm at hydra.gnu.org just builds all the packages using recipes from the Guix repo, and publishes the binaries over HTTP. So the fix is twofold: first Hydra (the software behind hydra.gnu.org) needs to be modified to produce and publish digital signatures; second Guix’s “substituter” (the program that fetches pre-built binaries) needs to actually fetch those signatures and check against them. Ways to do it have been discussed before: http://lists.gnu.org/archive/html/bug-guix/2013-05/msg00087.html http://lists.science.uu.nl/pipermail/nix-dev/2013-May/011200.html I think the task could fit the kind of hackathon you describe. Technically Hydra is written in Perl, and Guix is written in Scheme. Guix is a GNU package; Hydra is not, and Guix is not its only user. It’s unlikely that Guix hackers will be physically present, but hopefully you can find someone on #guix on Freenode! Thanks, Ludo’. pgpYw3iLXniPx.pgp Description: PGP signature
