bug#26215: gschemas.compiled should not be added to the profile by multiple packages

"pelzflorian (Florian Pelz)" writes: > On 03/23/2017 05:20 PM, Federico Beffa wrote: >> Note that if you mix GTK-2 and GTK-3 schemas many applications will >> crash. The glib-or-gtk-build-system tries to avoid mixing the two. >> >> Fede >> > >

bug#26215: gschemas.compiled should not be added to the profile by multiple packages

"pelzflorian (Florian Pelz)" writes: > Currently multiple packages contain the file > share/glib-2.0/schemas/gschemas.compiled (which is built by > glib-or-gtk-build-system). Doing so *works* (because each package’s > share directory in the Store is part of the XDG_DATA_DIRS environment > variabl

bug#25882: gcc-wrapper doesn't handle response files

l...@gnu.org (Ludovic Courtès) writes: > The attached version adds handling of unreadable files and recursion. > It does not address parsing of quote-delimited options though, but I’m > tempted to punt on that one. My worry is that not handling them may lead to hard to debug, guix specific errors

bug#25882: gcc-wrapper doesn't handle response files

l...@gnu.org (Ludovic Courtès) writes: > On closer inspection, it’s an easy change to make. > > Could you test the attached patch with GHC? Thanks for the patch. I've tested it with GHC 8.0.2 and seems to work for it. However, this is an excerpt of the description of the use of response files f

bug#25882: gcc-wrapper doesn't handle response files

l...@gnu.org (Ludovic Courtès) writes: > Federico Beffa skribis: > >> gcc-wrapper doesn't handle compiler/linker flags passed through >> response files. >> >> One package which recently started using such files is GHC (I believe >> since 7.10.3). For

bug#25882: gcc-wrapper doesn't handle response files

gcc-wrapper doesn't handle compiler/linker flags passed through response files. One package which recently started using such files is GHC (I believe since 7.10.3). For this reason we currently need to patch it. However, the problem is with our tool chain wrapper and not with GHC itself. See dis

bug#25793: wxMaxima output display error

Federico Beffa writes: > On Tue, Feb 21, 2017 at 5:01 AM, Leo Famulari wrote: >> Did you try building 5.38.1 with Guix? That could help us know if the >> problem is in maxima or in our packaging. > > No, I didn't . I referred to the maxima version, but the problem i

bug#25793: wxMaxima output display error

On Tue, Feb 21, 2017 at 5:01 AM, Leo Famulari wrote: > Did you try building 5.38.1 with Guix? That could help us know if the > problem is in maxima or in our packaging. No, I didn't .

bug#25793: wxMaxima output display error

I'm using Guix on Debian testing. The output displayed in a wxMaxima session is unreadable: lines are overlapping. Please see attached screenshot. The maxima Guix package version is 5.39.0. The maxima 5.38.1 coming with Debian works without any problem.

bug#25138: failing hackage import

On Fri, Dec 9, 2016 at 9:57 PM, Ludovic Courtès wrote: > I’m seeing a different error: > > --8<---cut here---start->8--- > $ git describe > v0.11.0-3322-gf80b4d2 > $ ./pre-inst-env guix import hackage -t darcs > Syntax error: unexpected token : (buildable (False

bug#24076: gnupg [-agent]: when signing [commits], it claims that there is no pinentry - but there is

Note that installing 'gnupg' doesn't automatically bring in 'pinentry'. For this reason installing 'gnupg' doesn't work out of the box as a user would expect: gpg: agent_genkey failed: No pinentry Key generation failed: No pinentry Fede

bug#22073: Fwd: search-paths and propagated inputs

On Sun, Dec 20, 2015 at 1:56 PM, Ludovic Courtès wrote: >> To get all the required search paths recursively we should replace the >> last 'manifest-entry' slot with a call to a function like this: > > Right. > > Here’s a variant of what you propose. With that, I get: > > --8<---cut he

bug#22073: Fwd: search-paths and propagated inputs

Any feedback on this? Thanks, Fede

bug#22073: Fwd: search-paths and propagated inputs

Looking at my manifest file I see that, e.g., the entry for 'python-matplotlib' lists all recursively propagated dependencies. Differently from this the 'search-paths' entry only lists the entries defined in the package (in this case none), neglecting the search paths in the 'propagated-inputs'. I

bug#20889: Tkinter moved to separate output

On Tue, Dec 1, 2015 at 11:00 PM, Ludovic Courtès wrote: > I gather this addresses http://bugs.gnu.org/20888, right? Well, it partially solves it: Now there is a working backend suitable for interactive plotting which is enabled by default. However, the 'GTK3Agg' backend is still there and still n

bug#22073: Fwd: search-paths and propagated inputs

Federico Beffa writes: > Federico Beffa writes: > >> Hi, >> >> the package 'gobject-introspection' declares a >> search-path-specification for the variable GI_TYPELIB_PATH and >> 'matplotlib' uses and propagates said package. I have &

bug#20889: 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 t

bug#20889: Tkinter moved to separate output

On Sun, Nov 29, 2015 at 11:09 PM, Ludovic Courtès wrote: > Federico Beffa skribis: > >> On Mon, Nov 16, 2015 at 1:57 PM, Ludovic Courtès wrote: >>> Federico Beffa skribis: >>>> Yes, given that the back-end currently used by matploblib doesn't >>&g

bug#21829: guix import hackage failures

On Wed, Nov 25, 2015 at 10:45 PM, Ludovic Courtès wrote: > Please add “Partly fixes .” or “Fixes > .” in the commit logs as appropriate (see > past commits for examples.) After committing I realized that I forgot about this. Sorry! Fede

bug#21829: guix import hackage failures

On Wed, Nov 25, 2015 at 10:45 PM, Ludovic Courtès wrote: > Federico Beffa skribis: [...] >>>> + ;; indentation based block recognition. >>>> + (begin (unread-char #\newline port) (read-char port) 0) >>> >>> Isn’t this equivalent to: 0 ? &g

bug#21829: guix import hackage failures

On Sun, Nov 15, 2015 at 9:59 PM, Ludovic Courtès wrote: > Federico Beffa skribis: >> * guix/import/cabal.scm (lex-word): Add support for tests with no spaces. >> (impl): Fix handling of operator "==". > > LGTM, but I think it’d be great to add a test that illustr

bug#20889: Tkinter moved to separate output

On Mon, Nov 16, 2015 at 1:57 PM, Ludovic Courtès wrote: > Federico Beffa skribis: >> Yes, given that the back-end currently used by matploblib doesn't >> work, I would change that by using 'Tkinter'. >> >> Since you are at it, I would also change the de

bug#20889: Tkinter moved to separate output

On Mon, Nov 16, 2015 at 9:42 AM, Ludovic Courtès wrote: > In ‘tk-update’ the ‘python’ packages now have a separate ‘tk’ output for > Tkinter (adding ~50 MiB to the closure of Python.) I’ve tested it along > these lines, for 2.x and 3.x: > > guix environment --ad-hoc python python:tk --pure -- p

bug#21829: guix import hackage failures

On Fri, Nov 13, 2015 at 10:19 PM, Ludovic Courtès wrote: > Federico Beffa skribis: > >> --- >> (define (canonical-newline-port port) >> "Return an input port that wraps PORT such that all newlines cons

bug#21829: guix import hackage failures

On Thu, Nov 12, 2015 at 9:21 PM, Ludovic Courtès wrote: > If we go for the CRLF conversion port, we should avoid the pipe and > extra thread. Instead, I would suggest something like: > > (define (canonical-newline-port port) > "Return an input port that wraps PORT such that all newlines con

bug#21829: guix import hackage failures

On Thu, Nov 12, 2015 at 10:07 AM, Ludovic Courtès wrote: > Federico Beffa skribis: > I wonder if it wouldn’t be easier to change the lexer to recognize line > feeds are white space or newlines, maybe along these lines: What you suggest is not enough. You have to tweak a couple of oth

bug#21829: guix import hackage failures

On Wed, Nov 11, 2015 at 12:18 PM, Ludovic Courtès wrote: > Federico Beffa skribis: > >> * I do not get backtraces, but the following error: > > The backtrace thing was fixed in 5453de3d. > >> * The following packages fail because the file has DOS line endings: >&

bug#21829: guix import hackage failures

Hi, I have checked the errors and have found the following: * I do not get backtraces, but the following error: -- $ ./pre-inst-env guix import hackage xmonad-contrib Starting download of /tmp/guix-file.yf7Cor >From http://hackage.haskell.org/package/xmonad-contrib/xm

bug#20889: python Tkinter

... and the configure script for Python defines the flag '--with-tcltk-libs'. Maybe that would help... Regards, Fede

bug#20889: python Tkinter

with: $TCLLIBPATH=/gnu/store/c4rpx4050d0qkccwbzggabag403b31l3-tk-8.6.4/lib python3 it works. So I guess that 'tcl' needs a search-path-specification. Regards, Fede

bug#20889: python Tkinter

If I start python3 and do: --- $ python3 Python 3.4.3 (default, Oct 9 2015, 22:53:58) [GCC 4.9.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import tkinter >>> root = tkinter.Tk() Traceback (most recent c

bug#21842: Brasero fails to start on foreign distros

On Fri, Nov 6, 2015 at 3:49 PM, Ludovic Courtès wrote: > As Andy notes on IRC, Brasero currently fails to start: > > --8<---cut here---start->8--- > $ /gnu/store/dq3817g8w80c9hffbgzspslqjy7szq35-brasero-3.12.1/bin/brasero > > ** (brasero:21487): WARNING **: Err

bug#20889: python Tkinter

On Mon, Jul 6, 2015 at 12:39 AM, Cyril Roelandt wrote: > On 07/05/2015 12:16 PM, Ludovic Courtès wrote: >> I’m asking because it might be that we could keep the default Python >> without Tk, and only use the Tk-enabled Python for the few packages that >> need it, if it’s rare enough. > > No, we do

bug#20888: Fwd: matplotlib

To make it work I had to (with the old version) set export GI_TYPELIB_PATH="$HOME/.guix-profile/lib/girepository-1.0" As far as I know, 'Agg' can only be used to generate files. It can't be used interactively a la MATLAB. That's the reason for including the 'GTK3Agg' backend. Regards, Fede

bug#20888: matplotlib

Maybe I should add, that, given that python-matplotlib didn't change in any way, the problem is likely with one of the inputs. Regards, Fede

bug#20889: python Tkinter

The python package does not provide Tkinter which is part of the Python Standard Library https://docs.python.org/3/library/tkinter.html?highlight=tkinter#module-tkinter

bug#20888: matplotlib broken

I was a happy matplotlib user. Unfortunately, recently it stopped working. Starting ipython3 and executing the following commands %matplotlib import numpy as np import matplotlib.pyplot as plt t = np.r_[0:5] plt.plot(t, t) now produces an empty, gray window. This was working fine in a previous v

bug#19805: Numpy failures

On Tue, Feb 10, 2015 at 12:07 AM, Ludovic Courtès wrote: >> At some point we should fix the support for '#:substitutable?' on hydra > > That probably means that #:substitutable? should be propagated–i.e., > that anything depending on ATLAS should not be substituted. I guess so. Is there a way to

bug#19819: Numpy failures

Andreas Enge writes: > python-numpy-bootstrap currently fails its tests on hydra, which entails a > bunch of other failures. On my own x86_64 machines, the build succeeds, > however. We believe the reason being the fact that hydra doesn't handle the flag '#:substitutable?' properly. As a result

bug#18933: ATLAS fails to build on mips

I'm trying to pass an architecture parameter to configure. However, if I do something like ... #:configure-flags `(... ;; On non "x86_64" / "i686" platforms, do not guess processor ;; architecture (because it fails) and do not use ISA extensions. ;; We set

bug#18933: ATLAS fails to build on mips

What I see is that ATLAS is not able to detect the type of system on which it is running. My first question then is: * Are we corss-compiling, or are we on proper hardware? If we are cross-compiling, then the only solution that I see it to try to fix the configuration with parameters passed to c