I'm trying to generate a package definition from the following json:
{
"name" : "pysolfc",
"version" : "2.6.4",
"source" : "https://github.com/shlomif/PySolFC/archive/pysolfc-2.6.4.tar.gz";
"build-system" : "python",
"home-page" : "https://pysolfc.sourceforge.io/";,
"synops
Thank you for your feedback!
On Fri, May 24, 2019 at 05:37:01PM +0200, Ludovic Courtès wrote:
> > Tring to put the packages in gnu/packages/libusb.scm and not in their
> > own file gnu/packages/usb-modeswitch.scm again resulted in
> >
> > [ 11%] LOAD guix/scripts/search.scm
> > [ 11%] LOAD
Hi,
l...@gnu.org (Ludovic Courtès) skribis:
> There’s this possibility:
>
> guix package -u . -r python -i python@2
>
> I admit it’s a bit contrived though.
>
> There are several ways to address it:
>
> 1. Rename our Python 2.x package “python2”.
That was done long ago, so I’m closing this b
Hi Andy,
Andy Tai skribis:
> %guix pull && guix package -u
>
> these were printed:
>
> ...
> New in this revision:
> ...
> hint: Run `guix pull --news' to view the complete list of package changes.
>
> hint: After setting `PATH', run `hash guix' to make sure your shell refers
> to `/home/
Hello,
Reg skribis:
> Note: There was some discussion about this on IRC a couple of weeks ago.
>
> Guix won't boot on my ThinkPad T430 after an installation with fully
> encrypted disk:
>
> * First, at the end of the installation, I'm getting the following error
> message multiple times: "devi
Hi Ricardo,
Ricardo Wurmus skribis:
> I can now also reproduce this on a foreign distro. This only happens
> with “guix pull” (not with “guix package”) and with a newer daemon
> (which I didn’t have previously).
>
> When building things “guix pull” prints the full build log interspersed
> with
Hello,
"pelzflorian (Florian Pelz)" skribis:
> Tring to put the packages in gnu/packages/libusb.scm and not in their
> own file gnu/packages/usb-modeswitch.scm again resulted in
>
> [ 11%] LOAD guix/scripts/search.scm
> [ 11%] LOAD guix/scripts/gc.scm
> [ 11%] LOAD guix/scripts/hash.
The problem seems more wide-spread, so should probably be fixed within
import/cabal.scm.
E.g. warp:
http://hackage.haskell.org/package/warp-3.2.27/warp.cabal
http://hackage.haskell.org/package/streaming-commons-0.2.1.0/streaming-commons.cabal
contain things along the following lines:
benchmark
Hi,
I'm adding some more context in this bug report, adding more info below
Please note that I got the same result (verbosity in guix pull) on a
Guix System machine, other than the foreing distro one I'm adding infos
about
Giovanni Biscuolo writes:
> Ricardo Wurmus writes:
>
>>> I've run "gui
$ guix import hackage not-a-package
guix import: error: failed to download cabal file for package 'not-a-package’
$ echo $?
1
$ guix import hackage -r not-a-package
$ echo $?
0
It might be argued that the error code is fine, since in general it could be
useful for the recursive import to keep go
Ludovic Courtès writes:
>> When I started the daemon from “guix pull” without having set
>> GUIX_DATABASE_DIRECTORY and I asked Guix to build something I noticed
>> this error message:
>>
>>guix pull: error: cannot unlink
>> `/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/gconv
Hello Ricardo,
Ricardo Wurmus skribis:
> This is a store corruption bug.
>
> The problem appears to be that I accidentally ran the daemon with the
> wrong GUIX_DATABASE_DIRECTORY. The localstatedir is /gnu/var, not /var.
Ouch. :-/
> When I started the daemon from “guix pull” without having s
Recursive import from a cabal file on standard input doesn’t work,
since imports of dependencies are attempted from standard input.
This typically fails due to EOF.
The sensible behaviour would probably be to only read the initial
package from standard input, and then fall back to hackage.
Altern
Hello,
I'm forwarding my first findings here, with some details to try to
reproduce this bug
--- Begin Message ---
Hi Guix!
I've run "guix pull" many many times since today but now after that
command I see a lot of logs like this one:
--8<---cut here---start-
On Fri, May 24, 2019 at 08:49:30AM +0200, Giovanni Biscuolo wrote:
> the "semantic" reason not to include ~/.local/bin in default path is to
> clearly state "use Guix" (even on foreign distros) to allow users to
> install packages and avoid the ~//bin _broken_ workaround
>
> IMHO at most ~/.local/b
On Fri, May 24, 2019 at 08:17:10AM +0200, Ricardo Wurmus wrote:
>
> pelzflorian (Florian Pelz) writes:
>
> > Currently for a simple GTK application of mine, on other distros I run
> > it by
> >
> > dont-hang
> >
> > but on Guix I have to run it with:
> >
> > LD_LIBRARY_PATH=/gnu/store/b9p5rhhci7
Ricardo,
Ricardo Wurmus writes:
[...]
> This is a bug.
Thanks for reproducing this and for confirming this is a bug, I'll add
my further findings in the bug report (I still do not see it on
debbugs.gnu.org)
🖖 Live long and prosper. Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
sign
Hi Giovanni,
I can now also reproduce this on a foreign distro. This only happens
with “guix pull” (not with “guix package”) and with a newer daemon
(which I didn’t have previously).
When building things “guix pull” prints the full build log interspersed
with tags like “@ build-log 22902 23”.
18 matches
Mail list logo
