Re: Lint on line
On Tue, Dec 1, 2015 at 11:04 PM, Ludovic Courtès wrote: > Andreas Enge skribis: > >> On Mon, Nov 23, 2015 at 12:11:13AM +0100, Ludovic Courtès wrote: >>> Here’s a new tool! >>> https://www.gnu.org/software/guix/packages/issues.html >> >> Very interesting! How about omitting all the packages with "Nothing to >> declare!" from the web page? > > Initially I left them so that each package at gnu.org/s/guix/packages > could contain a reference to its (possibly empty) issue list (each > package has an anchor in issues.html.) > > Do you think that would make sense? Or maybe one extra button and a tiny piece of javascript to show/hide the no-issue packages? -- Jan Synáček
Re: Python updates
Andreas Enge skribis: > Backtrace: > In ice-9/boot-9.scm: > 157: 16 [catch #t # ...] > In unknown file: >?: 15 [apply-smob/1 #] > In ice-9/boot-9.scm: > 63: 14 [call-with-prompt prompt0 ...] > In ice-9/eval.scm: > 432: 13 [eval # #] > In ice-9/boot-9.scm: > 2401: 12 [save-module-excursion # ()>] > 4050: 11 [#] > 1724: 10 [%start-stack load-stack # ice-9/boot-9.scm:4041:10 ()>] > 1729: 9 [#] > In unknown file: >?: 8 [primitive-load "/home/privat/Programme/guix/scripts/guix"] > In guix/ui.scm: > 1173: 7 [run-guix-command refresh] > In ice-9/boot-9.scm: > 157: 6 [catch srfi-34 # ...] > 157: 5 [catch system-error ...] > In srfi/srfi-1.scm: > 616: 4 [for-each # (package)> ...] > In guix/scripts/refresh.scm: > 391: 3 [# #] > In guix/upstream.scm: > 136: 2 [package-update-path # #] > In guix/import/pypi.scm: > 237: 1 [latest-release "ansible"] > In unknown file: >?: 0 [scm-error misc-error #f ...] > > ERROR: In procedure scm-error: > ERROR: No source release found for pypi package: "ansible" "2.0.0" We have a bug here; updaters should never fail. Fixed in 85dce71. Ludo’.
Re: Lint on line
Andreas Enge skribis: > On Mon, Nov 23, 2015 at 12:11:13AM +0100, Ludovic Courtès wrote: >> Here’s a new tool! >> https://www.gnu.org/software/guix/packages/issues.html > > Very interesting! How about omitting all the packages with "Nothing to > declare!" from the web page? Initially I left them so that each package at gnu.org/s/guix/packages could contain a reference to its (possibly empty) issue list (each package has an anchor in issues.html.) Do you think that would make sense? Ludo’.
Re: Tkinter moved to separate output
Federico Beffa skribis: > The attached patch fixes the problem and I can now plot with TkAgg :-) > > Thanks for making Tkinter available! > Fede > > From b40cf5522bcc15166ca07dfbae50167203d29e2d Mon Sep 17 00:00:00 2001 > From: Federico Beffa > Date: Tue, 1 Dec 2015 17:20:59 +0100 > Subject: [PATCH 1/2] gnu: python-matplotlib: Add 'TkAgg' backend and update to > version '1.4.3'. > > * gnu/packages/python.scm (python-matplotlib): Do it. > * gnu/packages/patches/matplotlib-setupext-tk.patch: New file. Nice! Please make sure to add the patch to gnu-system.am, but otherwise looks great! Thanks for fixing it! I gather this addresses http://bugs.gnu.org/20888, right? Ludo’.
Re: [PATCH] openssh: install ssh-copy-id.
Ricardo Wurmus skribis: > and this is after: > > $ guix size /gnu/store/65rd6p154y13dqcbkbimnwjq39k8dnym-openssh-7.0p1 > store item total > self > /gnu/store/65rd6p154y13dqcbkbimnwjq39k8dnym-openssh-7.0p1 91.5 > 3.9 4.3% > /gnu/store/zmqhwsl9vvxr4ihdnhwwpc3dpgmpsgsy-openssl-1.0.2d 73.0 > 12.3 13.4% > /gnu/store/54wpn20cik292k5hl4nxsivv614xl8c2-zlib-1.2.7 61.1 > 0.3 0.4% > /gnu/store/zy233badri3sffqi2s2kq8md6qz65iiz-gcc-4.9.3-lib 60.7 > 22.9 25.0% > /gnu/store/311nvir0pz1mhf0mgsmfrw00qfj7yq0j-bash-4.3.39 52.0 > 6.3 6.9% > /gnu/store/92f66z198h876byrjwwbgzv9rfsdm048-readline-6.345.7 > 1.2 1.3% > /gnu/store/5ljf8bnl2z5ykrrcs8352b9lh8j6139h-ncurses-6.0 44.5 > 6.6 7.3% > /gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22 37.9 > 36.5 39.9% > /gnu/store/7jhakv1r1nbs2sr2f7ammq256w7niarh-bash-static-4.3.39 1.4 > 1.4 1.5% > > There are new references to bash, readline, and ncurses. It’s a bash > script, so a new reference to bash is expected. OK, sounds reasonable. > I wonder why it also retains references to readline and ncurses, > though. These are indirect references (Bash depends on Readline.) Thanks, Ludo’.
Re: [PATCH] Add cereal + sparsehash
Ricardo Wurmus skribis: > Andreas Enge writes: > >> On Thu, Nov 26, 2015 at 01:53:25PM +0100, Ricardo Wurmus wrote: >>> The second patch adds “sparsehash” to the “crypto” module. It’s >>> probably not the best module for this package — can you suggest any >>> other location for a hash table library? >> >> If it is not a cryptographically secure hash, it should go anywhere, but >> not to the cryptography module. Both are called by the same name in English, >> but are completely different things. Could you move it somewhere else? > > I’d like to do this, but I’m pretty bad at naming things. How about a > new module “datastructures.scm” where this could comfortably fit in? Or > is this too vague? Or should it go in the equally vague “code.scm” > (which actually is for tools operating on source code)? I see there’s cityhash in textutils.scm and gperf in its own module. Maybe textutils.scm? Or next to cereal? Ludo’.
Re: Tkinter moved to separate output
Federico Beffa writes:
> On Sun, Nov 29, 2015 at 11:09 PM, Ludovic Courtès wrote:
>> Federico Beffa skribis:
> Looking into the failed build directory, it seems that PKG_CONFIG_PATH
> is set correctly. Still, it doesn't get the correct flags.
The attached patch fixes the problem and I can now plot with TkAgg :-)
Thanks for making Tkinter available!
Fede
From b40cf5522bcc15166ca07dfbae50167203d29e2d Mon Sep 17 00:00:00 2001
From: Federico Beffa
Date: Tue, 1 Dec 2015 17:20:59 +0100
Subject: [PATCH 1/2] gnu: python-matplotlib: Add 'TkAgg' backend and update to
version '1.4.3'.
* gnu/packages/python.scm (python-matplotlib): Do it.
* gnu/packages/patches/matplotlib-setupext-tk.patch: New file.
---
gnu/packages/patches/matplotlib-setupext-tk.patch | 30 +++
gnu/packages/python.scm | 17 +
2 files changed, 42 insertions(+), 5 deletions(-)
create mode 100644 gnu/packages/patches/matplotlib-setupext-tk.patch
diff --git a/gnu/packages/patches/matplotlib-setupext-tk.patch b/gnu/packages/patches/matplotlib-setupext-tk.patch
new file mode 100644
index 000..cd0332e
--- /dev/null
+++ b/gnu/packages/patches/matplotlib-setupext-tk.patch
@@ -0,0 +1,30 @@
+Use 'pkg-config' instead of heuristics to find 'tk' flags.
+
+--- matplotlib-1.4.3/setupext.py.orig 2015-12-01 14:21:19.554417453 +0100
matplotlib-1.4.3/setupext.py 2015-12-01 14:35:51.28797 +0100
+@@ -1457,7 +1457,7 @@
+ p = subprocess.Popen(
+ '. %s ; eval echo ${%s}' % (file, varname),
+ shell=True,
+-executable="/bin/sh",
++executable="sh",
+ stdout=subprocess.PIPE)
+ result = p.communicate()[0]
+ return result.decode('ascii')
+@@ -1601,8 +1601,15 @@
+ # of distros.
+
+ # Query Tcl/Tk system for library paths and version string
++def getoutput(s):
++ret = os.popen(s).read().strip()
++return ret
+ try:
+-tcl_lib_dir, tk_lib_dir, tk_ver = self.query_tcltk()
++#tcl_lib_dir, tk_lib_dir, tk_ver = self.query_tcltk()
++pkg_config_res = getoutput('pkg-config --libs tk').split()
++tk_ver = pkg_config_res[-1][-3:]
++tcl_lib_dir = pkg_config_res[0][2:] + '/tcl' + tk_ver
++tk_lib_dir = pkg_config_res[1][2:] + '/tk' + tk_ver
+ except:
+ tk_ver = ''
+ result = self.hardcoded_tcl_config()
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 39d0751..5e23bab 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -3175,7 +3175,7 @@ transcendental functions).")
(define-public python-matplotlib
(package
(name "python-matplotlib")
-(version "1.4.2")
+(version "1.4.3")
(source
(origin
(method url-fetch)
@@ -3183,13 +3183,15 @@ transcendental functions).")
"/matplotlib-" version ".tar.gz"))
(sha256
(base32
- "0m6v9nwdldlwk22gcd339zg6mny5m301fxgks7z8sb8m9wawg8qp"
+ "1dn05cvd0g984lzhh72wa0z93psgwshbbg93fkab6slx5m3l95av"))
+ (patches (list (search-patch "matplotlib-setupext-tk.patch")
(build-system python-build-system)
(outputs '("out" "doc"))
(propagated-inputs ; the following packages are all needed at run time
`(("python-pyparsing" ,python-pyparsing)
("python-pygobject" ,python-pygobject)
("gobject-introspection" ,gobject-introspection)
+ ("python" ,python "tk")
;; The 'gtk+' package (and 'gdk-pixbuf', 'atk' and 'pango' propagated
;; from 'gtk+') provides the required 'typelib' files used by
;; 'gobject-introspection'. The location of these files is set with the
@@ -3224,7 +3226,8 @@ transcendental functions).")
;; FIXME: Add backends when available.
;("python-wxpython" ,python-wxpython)
;("python-pyqt" ,python-pyqt)
- ))
+ ("tcl" ,tcl)
+ ("tk" ,tk)))
(native-inputs
`(("pkg-config" ,pkg-config)
("texlive" ,texlive)
@@ -3243,8 +3246,12 @@ transcendental functions).")
(setenv "HOME" (getcwd))
(call-with-output-file "setup.cfg"
(lambda (port)
-(format port "[rc_options]~%
-backend = GTK3Agg~%")
+(format port "[directories]~%
+basedirlist = ~a,~a~%
+[rc_options]~%
+backend = TkAgg~%"
+(assoc-ref inputs "tcl")
+(assoc-ref inputs "tk"))
(alist-cons-after
'install 'install-doc
(lambda* (#:key outputs #:allow-other-keys)
--
2.4.3
Re: proposal: add "packagers" field (list of strings (names)) to package definition
I should add a disclaimer: take my point of view with a grain of salt. There are other Guix contributors with a much broader perspective on the project. I'm still a newbie! On December 1, 2015 12:35:18 PM EST, Leo Famulari wrote: >On Tue, Dec 01, 2015 at 09:12:12AM +0100, Florian Paul Schmidt wrote: >> ...and encourage its use. The intended semantics is to list people >> that have contributed to the packaging effort. The motivation behind >> this proposal is that in many free software projects attribution can >> be a major source of motivation to get people involved. Having the >> packagers be first class citizens in the package definitions (as >> opposed to the information being only implicitly available through >> e.g. "git blame") would allow things like "guix package" or the >> package list on the website to display the contributor's names. > >All the contributors do get attribution in the copyright notice at the >top of each file, although that information is not linked to their >actual contributions except through git. > >> And if in a standard format containing additional info like an email >> address then bug reports for a package might even get CC'ed >> automatically to the contributors (though this might have some >privacy >> implications - but providing an email address or even any entry in >the >> packagers field is purely opt-in). > >I like the idea of using this information programatically. > >> WDYT? > >The nice thing about `git blame` is that it's "never wrong" — you can >easily find out who is actually invested in the relevant code based on >their actions, rather than what they claimed when putting their name in >the "maintainer" or "packager" field. That is, `git blame` shows >revealed preferences while the "maintainer" field shows rhetorical >preferences. Maybe `git blame` gets stale, but you can judge freshness >based on the age of the commits. > >Plus I can see some "political" issues in the future where people lay >claim to parts of the code base and justify it based on their name >being in >the packager field. Personally, I think we should avoid creating these >sorts of bureaucracies if its not necessary. > >I noticed that the NixOS github has a "mention-bot" that >automatically contacts people based on `git blame` if their old code is >subject to a pull request. You can see it in action here: >https://github.com/NixOS/nixpkgs/pull/11329 > >I think we should let the git repository be the single source of truth >for figuring out who is responsible for the code. If necessary, we can >build some automation around the git repo. > >Thoughts?
Re: package updater: operate on package structs, not names?
On Tue, Dec 01, 2015 at 11:41:25AM +0100, Ricardo Wurmus wrote: > There are two ways to approach this: we change the Guix package names to > closely match those of the upstream packages, or we pass the complete > package structure to ‘latest-release’. The latter approach would allow > the CRAN updater to extract the appropriate name from the tarball URI. I think we should work on the package, or more concretely, the uri and the version. Then we should do some pattern matching to find occurrences of major-minor-patchlevel, major-minor or major versions in the uri. And then we should try +1 in each of them (with later components set to 0). For instance with qt: (version "5.5.1") (uri (string-append "http://download.qt.io/official_releases/qt/"; (version-major+minor version) "/" version "/single/qt-everywhere-opensource-src-" version ".tar.xz")) which expands to http://download.qt.io/official_releases/qt/5.5/5.5.1/single/qt-everywhere-opensource-src-5.5.1.tar.xz we should try http://download.qt.io/official_releases/qt/5.5/5.5.2/single/qt-everywhere-opensource-src-5.5.2.tar.xz http://download.qt.io/official_releases/qt/5.6/5.6.0/single/qt-everywhere-opensource-src-5.6.0.tar.xz http://download.qt.io/official_releases/qt/6.0/6.0.0/single/qt-everywhere-opensource-src-6.6.0.tar.xz (and maybe some recursion to find the latest version). What do you think? Andreas
Re: proposal: add "packagers" field (list of strings (names)) to package definition
On Tue, Dec 01, 2015 at 09:12:12AM +0100, Florian Paul Schmidt wrote: > ...and encourage its use. The intended semantics is to list people > that have contributed to the packaging effort. The motivation behind > this proposal is that in many free software projects attribution can > be a major source of motivation to get people involved. Having the > packagers be first class citizens in the package definitions (as > opposed to the information being only implicitly available through > e.g. "git blame") would allow things like "guix package" or the > package list on the website to display the contributor's names. All the contributors do get attribution in the copyright notice at the top of each file, although that information is not linked to their actual contributions except through git. > And if in a standard format containing additional info like an email > address then bug reports for a package might even get CC'ed > automatically to the contributors (though this might have some privacy > implications - but providing an email address or even any entry in the > packagers field is purely opt-in). I like the idea of using this information programatically. > WDYT? The nice thing about `git blame` is that it's "never wrong" — you can easily find out who is actually invested in the relevant code based on their actions, rather than what they claimed when putting their name in the "maintainer" or "packager" field. That is, `git blame` shows revealed preferences while the "maintainer" field shows rhetorical preferences. Maybe `git blame` gets stale, but you can judge freshness based on the age of the commits. Plus I can see some "political" issues in the future where people lay claim to parts of the code base and justify it based on their name being in the packager field. Personally, I think we should avoid creating these sorts of bureaucracies if its not necessary. I noticed that the NixOS github has a "mention-bot" that automatically contacts people based on `git blame` if their old code is subject to a pull request. You can see it in action here: https://github.com/NixOS/nixpkgs/pull/11329 I think we should let the git repository be the single source of truth for figuring out who is responsible for the code. If necessary, we can build some automation around the git repo. Thoughts?
[PATCH v2] gnu: Add myrepos.
* gnu/packages/version-control.scm (myrepos): New variable.
---
gnu/packages/version-control.scm | 30 ++
1 file changed, 30 insertions(+)
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index b132663..548fb7f 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -7,6 +7,7 @@
;;; Copyright © 2014, 2015 Mark H Weaver
;;; Copyright © 2014 Eric Bavier
;;; Copyright © 2015 Efraim Flashner
+;;; Copyright © 2015 Kyle Meyer
;;;
;;; This file is part of GNU Guix.
;;;
@@ -925,3 +926,32 @@ any project with more than one developer, is one of
Aegis's major functions.")
a history browser. It can also stage hunks for commit, or colorize the
output of the 'git' command.")
(license gpl2+)))
+
+(define-public myrepos
+ (package
+(name "myrepos")
+(version "1.20151022")
+(source
+ (origin
+ (method url-fetch)
+ (uri (string-append
+ "https://github.com/joeyh/myrepos/archive/";
+ version ".tar.gz"))
+ (file-name (string-append name "-" version ".tar.gz"))
+ (sha256
+(base32 "0c93lqsngpsxsca7nygk4qhidr40ijgih86q81x1mfcwbs0gbds8"
+(build-system gnu-build-system)
+(inputs
+ `(("perl" ,perl)))
+(arguments
+ `(#:test-target "test"
+ #:phases (alist-delete 'configure %standard-phases)
+ #:make-flags (list (string-append "PREFIX=" %output
+(home-page "http://myrepos.branchable.com/";)
+(synopsis "Multiple repository management tool")
+(description
+ "Myrepos provides the @code{mr} command, which maps an operation (e.g.,
+fetching updates) over a collection of version control repositories. It
+supports a large number of version control systems: git, svn, mercurial, bzr,
+darcs, cvs, fossil and veracity.")
+(license gpl2+)))
--
2.6.2
Re: [PATCH] gnu: Add myrepos.
Ricardo Wurmus writes:
[...]
> You should add a ‘(file-name ...)’ expression here, because the tarball
> does not include the name of the package:
>
>(file-name (string-append name "-" version ".tar.gz"))
OK.
>> + #:make-flags (list (string-append "DESTDIR=" (assoc-ref %outputs
>> "out"))
>> + "PREFIX=")))
>
> Is it really correct to set DESTDIR and unset PREFIX? I thought setting
> PREFIX would be sufficient.
Right, setting PREFIX works fine. Myrepo's Makefile forms the path as
"${DESTDIR}${PREFIX}", so the end result should be the same. I'm not
sure why I decided setting DESTDIR would be better.
Sending an updated patch. Thanks for the comments.
--
Kyle
[PATCH] services: nginx: Allow for server extensions.
Hey folks,
Looking for some feedback on my first stab at making the nginx service
extensible. With this extension mechanism, future web applications
(such as GNU MediaGoblin) that use nginx as a front-end web server will
be able to extend nginx with the server configuration that they need in
order to work.
Here's a useless service that adds nginx configuration to serve the
contents of /tmp:
(define server
(plain-file "foo.conf"
"
server {
listen 80;
root /tmp;
index index.html;
server_name dthompson.us;
}
"))
(define foo-service-type
(service-type (name 'foo)
(extensions
(list (service-extension nginx-service-type
(const (list server)))
(define foo-service
(service foo-service-type #f))
One big question I have is whether I should enforce that configuration
be in file-like objects or if I should allow strings, too. Thoughts?
>From 108db2d183526c42b53060e55f7fb292b53663cb Mon Sep 17 00:00:00 2001
From: David Thompson
Date: Mon, 30 Nov 2015 08:49:08 -0500
Subject: [PATCH] services: nginx: Allow for server extensions.
* gnu/services/web.scm ()[servers]: New field.
(nginx-configuration-servers): New accessor.
(default-nginx-config): Delete.
(nginx-configuration-file*): New procedure.
(nginx-activation): Perform the syntax check on the full computed
configuration file.
(nginx-dmd-service): Use the full computed configuration file when
starting the service.
(extend-nginx): New procedure.
(nginx-service-type): Specify extension procedures.
(nginx-service): Add #:servers argument.
---
gnu/services/web.scm | 97
1 file changed, 60 insertions(+), 37 deletions(-)
diff --git a/gnu/services/web.scm b/gnu/services/web.scm
index 84bb30d..a5bc364 100644
--- a/gnu/services/web.scm
+++ b/gnu/services/web.scm
@@ -26,7 +26,16 @@
#:use-module (guix records)
#:use-module (guix gexp)
#:use-module (ice-9 match)
- #:export (nginx-service))
+ #:use-module (srfi srfi-1)
+ #:export (nginx-configuration
+nginx-configuration?
+nginx-configuration-log-directory
+nginx-configuration-run-directory
+nginx-configuration-file
+nginx-configuration-servers
+
+nginx-service-type
+nginx-service))
;;; Commentary:
;;;
@@ -37,23 +46,26 @@
(define-record-type*
nginx-configuration make-nginx-configuration
nginx-configuration?
- (nginx nginx-configuration-nginx) ;
- (log-directory nginx-configuration-log-directory) ;string
- (run-directory nginx-configuration-run-directory) ;string
- (file nginx-configuration-file)) ;string | file-like
+ (nginx nginx-configuration-nginx) ;
+ (log-directory nginx-configuration-log-directory) ; string
+ (run-directory nginx-configuration-run-directory) ; string
+ (file nginx-configuration-file) ; file-like
+ (servers nginx-configuration-servers)) ; list of file-like
-(define (default-nginx-config log-directory run-directory)
- (plain-file "nginx.conf"
- (string-append
- "user nginx nginx;\n"
- "pid " run-directory "/pid;\n"
- "error_log " log-directory "/error.log info;\n"
- "http {\n"
- "access_log " log-directory "/access.log;\n"
- "root /var/www;\n"
- "server {}\n"
- "}\n"
- "events {}\n")))
+(define (nginx-configuration-file* config)
+ (match config
+(($ _ log run file servers)
+ (apply mixed-text-file "nginx.conf"
+`("user nginx nginx;\n"
+ "pid " ,run "/pid;\n"
+ "error_log " ,log "/error.log info;\n"
+ "include " ,file ";\n"
+ "http {\n"
+ " access_log " ,log "/access.log;\n"
+ ,@(append-map (lambda (server-config)
+ (list "include " server-config ";\n"))
+servers)
+ "}\n")
(define %nginx-accounts
(list (user-group (name "nginx") (system? #t))
@@ -66,37 +78,43 @@
(shell #~(string-append #$shadow "/sbin/nologin")
(define nginx-activation
- (match-lambda
-(($ nginx log-directory run-directory config-file)
- #~(begin
- (use-modules (guix build utils))
+ (lambda (config)
+(match config
+ (($ nginx log-directory run-directory _)
+ #~(begin
+ (use-modules (guix build utils))
- (format #t "creating nginx log directory '~a'~%" #$log-directory)
- (mkdir-p #$log-directory)
- (format #t "creating nginx run directory '~a'~%" #$run-directory)
- (mkdir-p #$run-directory)
- ;; Check configuration file syntax.
- (system* (string-append #$nginx
Re: proposal: add "packagers" field (list of strings (names)) to package definition
On 12/01/2015 09:12 AM, Florian Paul Schmidt wrote: > > ...and encourage its use. The intended semantics is to list people > that have contributed to the packaging effort. The motivation > behind [...] Something like: diff --git a/guix/packages.scm b/guix/packages.scm index 68fb091..efe1dbf 100644 --- a/guix/packages.scm +++ b/guix/packages.scm @@ -78,6 +78,7 @@ package-home-page package-supported-systems package-maintainers +package-packagers package-properties package-location package-field-location @@ -266,6 +267,9 @@ name of its URI." (default %supported-systems)) (maintainers package-maintainers (default '())) + (packagers package-packagers (default '())) ; list of people that worked + ; on the package + (properties package-properties (default '())) ; alist for anything else (location package-location Regards, Flo -- https://fps.io
Re: package updater: operate on package structs, not names?
Ricardo Wurmus writes: > Hi Guix, > > I noticed a flaw in the CRAN updater. The ‘latest-release’ procedure is > called with the result of ‘(package-name package)’. The problem here is > that Guix package names follow much stricter naming rules than the > upstream packages. > > Here are a couple of examples of R package names and their related Guix > package names: > > GenomicRanges —> r-genomic-ranges > data.table—> r-data-table > formatR –> r-formatr > DBI —> r-dbi > > When we only pass the Guix name to ‘latest-release’, the updater won’t > know how to find the package and its upstream version because the names > don’t match. > > There are two ways to approach this: we change the Guix package names to > closely match those of the upstream packages, or we pass the complete > package structure to ‘latest-release’. The latter approach would allow > the CRAN updater to extract the appropriate name from the tarball URI. > > We have the same problem for Ruby gems, I think, so I think that it > generally would be a good idea to pass the whole package object to > ‘latest-release’. Those updaters that only need the package name can > just reduce it by calling ‘(package-name package)’ themselves. > > What do you think? It just occurred to me that I could do something like this: (specification->package the-package-name) and then operate on the package. Then I noticed that ‘guix/import/pypi.scm’ does this already. Since we start out with a package object wouldn’t it be better to just keep it rather than convert back and forth between names and packages? ~~ Ricardo
Re: [PATCH] Add cereal + sparsehash
Andreas Enge writes: > On Thu, Nov 26, 2015 at 01:53:25PM +0100, Ricardo Wurmus wrote: >> The second patch adds “sparsehash” to the “crypto” module. It’s >> probably not the best module for this package — can you suggest any >> other location for a hash table library? > > If it is not a cryptographically secure hash, it should go anywhere, but > not to the cryptography module. Both are called by the same name in English, > but are completely different things. Could you move it somewhere else? I’d like to do this, but I’m pretty bad at naming things. How about a new module “datastructures.scm” where this could comfortably fit in? Or is this too vague? Or should it go in the equally vague “code.scm” (which actually is for tools operating on source code)? ~~ Ricardo
package updater: operate on package structs, not names?
Hi Guix, I noticed a flaw in the CRAN updater. The ‘latest-release’ procedure is called with the result of ‘(package-name package)’. The problem here is that Guix package names follow much stricter naming rules than the upstream packages. Here are a couple of examples of R package names and their related Guix package names: GenomicRanges —> r-genomic-ranges data.table—> r-data-table formatR –> r-formatr DBI —> r-dbi When we only pass the Guix name to ‘latest-release’, the updater won’t know how to find the package and its upstream version because the names don’t match. There are two ways to approach this: we change the Guix package names to closely match those of the upstream packages, or we pass the complete package structure to ‘latest-release’. The latter approach would allow the CRAN updater to extract the appropriate name from the tarball URI. We have the same problem for Ruby gems, I think, so I think that it generally would be a good idea to pass the whole package object to ‘latest-release’. Those updaters that only need the package name can just reduce it by calling ‘(package-name package)’ themselves. What do you think? ~~ Ricardo
Re: [PATCH] gnu: Add myrepos.
Hi Kyle,
thanks for the patch!
> * gnu/packages/version-control.scm (myrepos): New variable.
> ---
> gnu/packages/version-control.scm | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/gnu/packages/version-control.scm
> b/gnu/packages/version-control.scm
> index b132663..d7c4f8c 100644
> --- a/gnu/packages/version-control.scm
> +++ b/gnu/packages/version-control.scm
> @@ -7,6 +7,7 @@
> ;;; Copyright © 2014, 2015 Mark H Weaver
> ;;; Copyright © 2014 Eric Bavier
> ;;; Copyright © 2015 Efraim Flashner
> +;;; Copyright © 2015 Kyle Meyer
> ;;;
> ;;; This file is part of GNU Guix.
> ;;;
> @@ -925,3 +926,32 @@ any project with more than one developer, is one of
> Aegis's major functions.")
> a history browser. It can also stage hunks for commit, or colorize the
> output of the 'git' command.")
> (license gpl2+)))
> +
> +(define-public myrepos
> + (package
> +(name "myrepos")
> +(version "1.20151022")
> +(source
> + (origin
> + (method url-fetch)
> + (uri (string-append
> + "https://github.com/joeyh/myrepos/archive/";
> + version ".tar.gz"))
You should add a ‘(file-name ...)’ expression here, because the tarball
does not include the name of the package:
(file-name (string-append name "-" version ".tar.gz"))
> + (sha256
> +(base32 "0c93lqsngpsxsca7nygk4qhidr40ijgih86q81x1mfcwbs0gbds8"
> +(build-system gnu-build-system)
> +(inputs
> + `(("perl" ,perl)))
> +(arguments
> + `(#:test-target "test"
> + #:phases (alist-delete 'configure %standard-phases)
> + #:make-flags (list (string-append "DESTDIR=" (assoc-ref %outputs
> "out"))
> + "PREFIX=")))
Is it really correct to set DESTDIR and unset PREFIX? I thought setting
PREFIX would be sufficient.
> +(home-page "http://myrepos.branchable.com/";)
> +(synopsis "Multiple repository management tool")
> +(description
> + "Myrepos provides the @code{mr} command, which maps an operation (e.g.,
> +fetching updates) over a collection of version control repositories. It
> +supports a large number of version control systems: git, svn, mercurial, bzr,
> +darcs, cvs, fossil and veracity.")
> +(license gpl2+)))
The rest looks fine to me. Thanks!
~~ Ricardo
Re: [PATCH] gnu: Add python-contextlib2
Hi Ludo', Yes, your explanation about the quoting makes sense. Also, it looks like you were right: the PYTHONPATH leaked from my current environment. Thank you for your help. Would you like me to adjust the length of the longest line as mentioned by Ben, or is my patch good to go as-is? Thank you, Chris On Thu, Nov 26, 2015 at 5:44 AM Ludovic Courtès wrote: > Hi! > > Sorry for the delay. > > Chris Marusich skribis: > > > However, there is one curiosity. I've noticed that when I run > > "./pre-inst-env guix environment python2-contextlib2", the PYTHONPATH > > is configured to allow importation of contextlib2 from the > > $profile/lib/python3.4/site-packages directory tree, rather than > > $profile/lib/python2.7/site-packages. When I run python in this > > environment, I get a Python 2.7 interpreter. > > The interpreter you get here is probably one that was already in PATH, > because the command above lacks --pure. > > If you want to be sure, use: > > ./pre-inst-env guix environment --pure \ > python2-contextlib python-2 -- python > > (Even better: --container instead of --pure.) > > Can you confirm? > > > I'm also curious: why does the "(#:phases" part need to be > > quasi-quoted with the backtick symbol "`"? > > The #:phases part specified build code (info "(guix) G-Expressions"). > That code is quoted because we don’t want to evaluate it; we merely want > to pass the code itself for future execution in the build environment. > > Does that make sense? > > Thanks, > Ludo’. >
proposal: add "packagers" field (list of strings (names)) to package definition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ...and encourage its use. The intended semantics is to list people that have contributed to the packaging effort. The motivation behind this proposal is that in many free software projects attribution can be a major source of motivation to get people involved. Having the packagers be first class citizens in the package definitions (as opposed to the information being only implicitly available through e.g. "git blame") would allow things like "guix package" or the package list on the website to display the contributor's names. And if in a standard format containing additional info like an email address then bug reports for a package might even get CC'ed automatically to the contributors (though this might have some privacy implications - but providing an email address or even any entry in the packagers field is purely opt-in). Note that the (largely unused) maintainer field [1] plays a slightly different role - judging purely from its name, since it's not too well documented: A maintainer has responsibilities beyond the role of a contributor. [1] https://www.gnu.org/software/guix/manual/guix.html#package-Reference WDYT? Regards, Flo - -- https://fps.io -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWXVZbAAoJEA5f4Coltk8ZwNMH/2HLaUhO+j4U3dYLR4BhKvcN YKLd7lJyIRXYHCgjePny1avV+QwUrUEyDz22EE4Ucktfm85wHxoILWN4eIPiCLno SQCEiqkVExRGzqbVzTfpqtEbhpxv8xT/vnR+IGNjS7PBwAODVar2jv3RIrPLhS0+ 2gLeMUemHg21isfJh+eREYybYdYX6KKDTOfJFAoKZh3y7HB1QuO7JtCj7rUx+pKz X2vRovQYJobg+9IMbmDum4v7+ptXV6fKc0P0z4aB1QGmGyiyok9nFDifNEw7CiE/ 9XaV30fwYPGeZqJ1SPWm9Pc80OXM+gEOrVWemW/fgFOYiIz3JkeEjz6aKIS9km8= =FmOO -END PGP SIGNATURE-
