On Sun, Oct 26, 2014 at 03:12:40PM +0100, Ludovic Courtès wrote:
> - (outputs '("out" "data"))
> + (outputs '("out" "data" "doc"))
I just tried this, and it does not work:
builder for `/gnu/store/r39sf9gzfdlxb6q2c4zaz18z63mmc8fz-texlive-2014.drv'
failed to produce output path
`/gnu/store/s75
On Wed, Oct 29, 2014 at 01:29:01PM +0100, Andreas Enge wrote:
> A problem is that I need a working texlive, and compiling an additional
> one may take too much space.
Actually, now that deduplication works, havings several texlive installations
with the same data is not a problem any more!
Andrea
Hello,
What would think of a patch like this:
diff --git a/emacs/guix-info.el b/emacs/guix-info.el
index 551d79a..c3499e4e 100644
--- a/emacs/guix-info.el
+++ b/emacs/guix-info.el
@@ -198,13 +198,27 @@ ENTRIES should have a form of `guix-entries'."
entries
gu
Currently, texlive has a certain number of native inputs:
(native-inputs
`(("perl" ,perl)
("pkg-config" ,pkg-config)
("python" ,python-2) ; incompatible with Python 3 (print syntax)
("tcsh" ,tcsh)))
But I think these are not needed during build time, but to patch-shebang
sc
On Wed, Oct 29, 2014 at 06:00:02PM +0100, Andreas Enge wrote:
Currently, texlive has a certain number of native inputs:
(native-inputs
`(("perl" ,perl)
("pkg-config" ,pkg-config)
("python" ,python-2) ; incompatible with Python 3 (print syntax)
On Wed, Oct 29, 2014 at 06:13:09PM +0100, John Darrington wrote:
> If they were "normal" inputs and you were cross compiling, then the packages
> which
> are made available, would be those for the target system, not the native one.
> Hence
> they could not run, and the build would break.
Well,
On Wed, Oct 29, 2014 at 06:13:09PM +0100, John Darrington wrote:
> You are probably right - to be sure they should be manually checked. An
> alternative would be to attempt cross building all the affected packages.
In the case that native inputs should instead be normal, if I understand
correct
On Wed, Oct 29, 2014 at 06:39:48PM +0100, Andreas Enge wrote:
On Wed, Oct 29, 2014 at 06:13:09PM +0100, John Darrington wrote:
> If they were "normal" inputs and you were cross compiling, then the
packages which
> are made available, would be those for the target system, not the nat
On Wed, Oct 29, 2014 at 06:43:03PM +0100, Andreas Enge wrote:
On Wed, Oct 29, 2014 at 06:13:09PM +0100, John Darrington wrote:
> You are probably right - to be sure they should be manually checked. An
> alternative would be to attempt cross building all the affected
packages.
On Wed, Oct 29, 2014 at 06:39:48PM +0100, Andreas Enge wrote:
> Would it work? One would need to patch-shebang with the normal input and
> use the native-input for scripts that are used during the build process.
> Is this distinguished somehow? (Well, there is of course the problem of
> scripts tha
> Personally my main use of ATLAS is through numpy/scipy. Therefore I
> would like to be able to use a good performing ATLAS with those
> packages. If that needs a manual installation step, that's fine with
> me.
>
> In principle we could make a second package and add a suffix to the
> version num
Updated patch.
Regards,
Fede
From 6673a353080fd4b5136553624a7d777d243fc9a2 Mon Sep 17 00:00:00 2001
From: Federico Beffa
Date: Wed, 29 Oct 2014 20:44:33 +0100
Subject: [PATCH] gnu: Add numpy.
* gnu/packages/python.scm (python-numpy, python2-numpy): New variables.
(python-wrapper): Add symlink
On Wed, Oct 29, 2014 at 07:51:44PM +0100, Andreas Enge wrote:
On Wed, Oct 29, 2014 at 06:39:48PM +0100, Andreas Enge wrote:
> Would it work? One would need to patch-shebang with the normal input and
> use the native-input for scripts that are used during the build process.
> Is
Federico Beffa skribis:
> In my opinion the fact that guix makes it easy to build a package on
> the user machine is really a key advantage over other package
> managers/distributions, for a few, somewhat special packages, ATLAS
> being one. It would really be a pity to give up such nice a featu
Federico Beffa skribis:
> On Tue, Oct 28, 2014 at 10:34 AM, Ludovic Courtès wrote:
[...]
>> Perhaps the right fix will be to change ‘python-wrapper’ to symlink the
>> ‘lib’ sub-directory of ‘python’.
>
> It was also suggested to make python a propagating input of the wrapper.
> https://lists.g
On Sun, Oct 26, 2014 at 12:07:13PM -0400, Mark H Weaver wrote:
> Hmm. It is indeed a hack, but maybe worth considering. When I think
> about Guix users downloading over 3 GiB from our humble hydra quite
> often just to have TeX, it makes me worry about our bandwidth
> requirements.
What do you m
Federico Beffa skribis:
> From 6673a353080fd4b5136553624a7d777d243fc9a2 Mon Sep 17 00:00:00 2001
> From: Federico Beffa
> Date: Wed, 29 Oct 2014 20:44:33 +0100
> Subject: [PATCH] gnu: Add numpy.
>
> * gnu/packages/python.scm (python-numpy, python2-numpy): New variables.
> (python-wrapper): Add
Ludovic Courtès (2014-10-29 19:25 +0300) wrote:
> Hello,
>
> What would think of a patch like this:
[...]
> (defun guix-info-insert-entry (entry entry-type &optional indent-level)
>"Insert ENTRY of ENTRY-TYPE into the current info buffer.
> If INDENT-LEVEL is non-nil, indent displayed info
On Tue, Oct 28, 2014 at 09:10:30AM +0100, Ludovic Courtès wrote:
> Alex Kost skribis:
> > Not related to this patch: what about renaming ‘freefont-ttf’ package
> > into ‘ttf-freefont’ to make all TrueType fonts have a name "ttf-…"?
> I think so. What do others think? Andreas?
So far, we have no
Andreas Enge skribis:
> On Sun, Oct 26, 2014 at 03:12:40PM +0100, Ludovic Courtès wrote:
>> - (outputs '("out" "data"))
>> + (outputs '("out" "data" "doc"))
>
> I just tried this, and it does not work:
> builder for `/gnu/store/r39sf9gzfdlxb6q2c4zaz18z63mmc8fz-texlive-2014.drv'
> failed to p
On Mon, Oct 27, 2014 at 09:26:41PM +0100, Federico Beffa wrote:
> I get error messages that matplotlib is missing. I started looking at
> matplotlib as well, but I've found that, for the TkAgg back-end, it
> needs TKinter which is part of the standard python libraries and it is
> built if, during
On Tue, Oct 28, 2014 at 09:03:44AM +0100, Ludovic Courtès wrote:
> Alex Kost skribis:
> > But currently it's not possible to install 2 (or more) packages with the
> > same name. So a user can't have guile 2.0 and guile 1.8 in the same
> > profile. The same thing with python: there is no ‘python2
On Tue, Oct 28, 2014 at 10:34:48AM +0100, Ludovic Courtès wrote:
> Ah right. And what if you again remove Python from ‘inputs’, and add
> #:python ,python
> to the arguments?
> That means it will use the actual Python 3.x package, not the wrapper,
> so everything will be visible. The downside i
Andreas Enge skribis:
> On Wed, Oct 29, 2014 at 06:13:09PM +0100, John Darrington wrote:
>> If they were "normal" inputs and you were cross compiling, then the packages
>> which
>> are made available, would be those for the target system, not the native
>> one. Hence
>> they could not run, and
On Wed, Oct 29, 2014 at 08:55:52PM +0100, Federico Beffa wrote:
> Updated patch.
> - (python (string-append (assoc-ref %build-inputs "python")
> "/bin/")))
> + (python (string-append (assoc-ref %build-inputs "python")
> "/bin/"))
> + (lib (string-a
On Wed, Oct 29, 2014 at 08:55:55PM +0100, John Darrington wrote:
> What do these scripts do anyway? Are they fundamental to TeXlive or are they
> for some bells and whistles?
I never use them as far as I know, so they do not seem to be fundamental.
Andreas
Andreas Enge skribis:
> But then I suppose that "make check" does not make much sense anyway when
> cross-compiling? Do we activate it then?
For Automake-generated makefiles, ‘make check’ does nothing when
cross-compiling, so no extra action needs to be taken.
Ludo’.
Hello,
when issueing
guix package -u icecat -n
I see:
The following package would be upgraded:
icecat 31.2.0 → 31.2.0
/gnu/store/rsf4pww335qqv7iyss54i8fmwr7kfm83-icecat-31.2.0
The following derivations would be built:
/gnu/store/wxfxjbbc268gxmbinb0bnckhxq6h
As discussed, I would like to push such a patch. But:
$ guix refresh -l python-wrapper
Building the following 185 packages would ensure 364 dependent packages are
rebuilt
In light of these numbers, should we do this in core-updates?
There is also the lingering update of pkg-config that I would
Manolis Ragkousis skribis:
> From 66df601071d093c5532dec4c1ff55beb141a53d1 Mon Sep 17 00:00:00 2001
> From: Manolis Ragkousis
> Date: Sun, 26 Oct 2014 11:29:41 +
> Subject: [PATCH] gnu: cross-base: Add libc/hurd.
>
> * gnu/packages/cross-base.scm (cross-libc/hurd): New variable.
Apologies f
30 matches
Mail list logo
