Did you try something like
proot -0 -b /proc -b /dev -b /etc -r . -b etc_guix/acl:/etc/guix/acl
gnu/store/vir3l..-guix-0.x/bin/guix-daemon --disable-chroot
(note the extra -0 and chroot switches) and you should see on a guix package
install.
That used to work. But maybe no longer?
On Fri, Feb
ldc 1.13.0 was released two days ago. 32-bits version appears to be broken.
On Tue, Nov 06, 2018 at 03:21:29PM +0100, Ludovic Courtès wrote:
> As to why you’re not getting substitutes, it could be missing
> authorization, etc. What does ‘guix publish’ display?
Substitutes work fine for normal package install. No problem with the
setup. No, this is specific to guix pull w
I have a guix-publish server and I am building the packages with the
exact same checkout of 'guix pull'. Even though the client sees the
substitutes with --dry-run it still builds them.
On build host (check version first)
penguin2:~$ ~/.config/guix/current/bin/guix --version
guix
Patch coming up for updated ldc bootsrap, ldc 1.11.0, dub and rdmd.
I actually tried the ldc 1.12.0 release but I am facing a few issues.
With sambamba/BioD. Will update when I have found that problem.
Next step will be to add the latest GNU D compiler gdc. gdc which will
be included in the next
On Thu, Oct 11, 2018 at 06:32:20PM +0200, Ludovic Courtès wrote:
> Hi there!
>
> I believe commit ed9d7cb4d95f8f4776e6fee2778ab52bc2852969 fixes it.
>
> That is, if you run ‘guix pull’ as root and then start
> ~/.config/guix/current/bin/guix-daemon, everything should be fine.
It works on one pro
Hi Tim,
I am not sure this helps but in a project I have I use
CPPFLAGS= -std=c++11
and
CPPFLAGS += -I$(GUIX)/include/c++
-I$(GUIX)/include/c++/x86_64-unknown-linux-gnu
to find include files in Guix context with clang. Where $(GUIX) is the
profile.
Similar to yours. Glad to hear of a b
On Tue, Sep 11, 2018 at 03:23:13PM +0200, Pjotr Prins wrote:
> On Tue, Sep 11, 2018 at 12:12:15PM +0200, Ludovic Courtès wrote:
> > The download process is running as a build user, not as root, hence the
> > permission issue (silly me!).
> >
> > Now we need to find a wa
On Tue, Sep 11, 2018 at 12:12:15PM +0200, Ludovic Courtès wrote:
> The download process is running as a build user, not as root, hence the
> permission issue (silly me!).
>
> Now we need to find a way to use ‘guix’ from root’s
> ~/.config/guix/current. A solution may be to expose that profile und
It is working now. After a guix pull I did a guix package -i guix in a
new profile. Restarting the daemon from there it stopped complaining!
I don't know why the deamon from guix pull straight was not working,
but at least guix is building again.
Pj.
m using in Southern France ;)
Pj.
On Thu, Sep 06, 2018 at 11:10:33PM +0200, Pjotr Prins wrote:
> On Sun, Sep 02, 2018 at 10:04:32PM +0200, Ludovic Courtès wrote:
> > OK. Do reopen it if it shows up again.
>
> Just to report that I did a successful install on one of those
> ma
On Sun, Sep 02, 2018 at 10:04:32PM +0200, Ludovic Courtès wrote:
> OK. Do reopen it if it shows up again.
Just to report that I did a successful install on one of those
machines. Starting with a 0.14 guix as root
guix pull
restarted daemon using the new one in /root/.config/current/bin/
swit
recent tree.
> Thanks in advance!
>
> Ludo’.
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
> > Hi Pjotr,
> >
> > Pjotr Prins skribis:
> >
> >> Not completely sorted. Not sure what is going wrong but now starting
> >> with guix 0.14 daem
Ludo, I am so ready to try this!
GUIX_PACKAGE_PATH is killing me though it got a lot better after
latest guix pull developments.
Tell me what to run.
Pj.
On Sat, Aug 18, 2018 at 01:34:09PM +0200, Tobias Geerinckx-Rice wrote:
> Pjotr, Leo, Guix,
>
> Pjotr Prins wrote:
> > Someone still needs to push the patch.
>
> I went ahead and did so in 399c5fafcdb2d0c13ab51e4ab57d451d2c7cb1bd
> since it's not really acceptable
Someone still needs to push the patch.
closes 32466
> This failure is not directly in wine, but in gst-plugins-base.
>
> Strangely, gst-plugins-base built directly has no problems. Only as a
> dependency it somehow builds a different derivation and then the test
> fails.
>
> I have discussed it here already:
>
> #32360
>
> https://debbugs.gnu.or
Recent versions of wine and wine-staging in Guix are not building
after guix pull. I rolled back a month, but even that is a problem on
my 2017 Debian box. I can't check the build farm to see if it is
working there.
~/.config/guix/current/bin/guix package ~-i wine-staging
FAIL: elements/opus
=
Not completely sorted. Not sure what is going wrong but now starting
with guix 0.14 daemon and client and running guix pull a few times
successfully, running guix-daemon from $HOME/.config/guix/current/bin
and guix from a fresh git checkout using ./pre-inst-env guix I get
substitute:
/gnu/store/x
On Mon, Jul 02, 2018 at 11:39:40AM +0200, Ludovic Courtès wrote:
> Hello,
>
> swedebugia skribis:
>
> > Trying to get an updated an old GuixSD installation via guix pull on a pre
> > 0.10 GuixSD returned an error message about gexp-modules not found.
> > (details can be provided if asked).
>
On Sun, Jun 03, 2018 at 10:29:43PM +0200, Ludovic Courtès wrote:
> Pjotr Prins skribis:
>
> > On Fri, Jun 01, 2018 at 02:13:10PM +0200, Ludovic Courtès wrote:
> >> Thanks for your support! We’ll still have to make the whole build
> >> process faster but yeah, tha
On Fri, Jun 01, 2018 at 02:13:10PM +0200, Ludovic Courtès wrote:
> Thanks for your support! We’ll still have to make the whole build
> process faster but yeah, that’s one important step towards 1.0!
But we do get substitutes in principle, right?
Pj.
On Sat, Mar 17, 2018 at 07:39:28PM +0100, Ludovic Courtès wrote:
> It’s a bit weird that 0.6.0 tests passed at some point in Guix, and
> eventually started failing. Not sure what happened.
Probably an openblas or LLVM update. Unfortunately hydra no longer has
the logs.
Pj.
--
After some investigation I have found Julia's build system to be a
challenge. The problem is that, to 'control' the environment, the
developers have chosen to fixate all dependencies by pulling them in
and patching them (including LLVM). The only time I got a successful
build outside Guix was by us
On Tue, Mar 13, 2018 at 06:54:18PM +0100, Andreas Enge wrote:
> Hello,
>
> On Tue, Mar 13, 2018 at 06:02:07PM +0100, Ludovic Courtès wrote:
> > I tried the patch below (README.md in Julia 0.6.0 says that plain LLVM
> > 3.9 without patches is OK), but that didn’t solve the
> > distributed.jl-relate
One immediate problem is that Julia comes with patches for LLVM 3.9
only:
https://github.com/JuliaLang/julia#llvm
it downloads, patches and compiles a specific LLVM. We actually need
this even though the failing tests are possibly not related (I suspect
the math libraries are not showing the sa
> Help welcome!
I'll take a look.
Pj.
--
On Sun, Feb 11, 2018 at 12:45:18AM +0100, Chris Marusich wrote:
> Danny Milosavljevic writes:
>
> > This is only fixed in glibc 2.27 (not in core-updates).
>
> Should we upgrade glibc in core-updates, then? Or is it better to do it
> in the next core-updates cycle, to avoid still more unexpecte
The epipe error suggests a new external process is invoked (git)
which does not terminate properly and does not close the pipe. Maybe
it tries to access the network layer. The calling program throws an
epipe error. I see something similar happening
here: https://gist.github.com/knewter/533d22eb69ef
On Sat, Dec 02, 2017 at 07:04:09PM +0100, nee wrote:
> Hello, what is the current state for the elixir package?
>
> I saw this issue on elixir's github page:
> https://github.com/elixir-lang/elixir/issues/6586
> Has there been any progress since then? From what I understand the build
> fails becau
Hi Fred,
Can you send the exact commands you are using so we can replicate the
issue?
Pj.
--
On latest guix d30ce4a7e2ba8f4eca7b99bb8483353c753e91bf
./pre-inst-env guix pack hello
works. But this does not:
./pre-inst-env guix pack hello -f docker
I am sure guile-json is in the path (see below).
The following derivation will be built:
/gnu/store/xhfrvmh7vh2ipm32rdyisagnr5ac46
On Thu, May 18, 2017 at 11:43:31AM +0200, Ludovic Court??s wrote:
> Ooh, got it. I managed to reproduce it with a toy example. Should be
> fixed in 22ef06b801b284760b4ffd9587ea1a3dffd31baa. Can you confirm?
Fixed!
Pj.
On Wed, May 17, 2017 at 09:54:07PM +0200, Ludovic Court??s wrote:
> > I remember the python.1 path is a symlink not pointing anywhere. We
> > dealt with that a year ago. Maybe it now confuses the man db builder.
> > Does it somehow use the (existing) profile?
>
> Yes, it could be that it happens w
On Wed, May 17, 2017 at 03:08:05PM +0200, Ludovic Court??s wrote:
> Hi,
>
> Pjotr Prins skribis:
>
> > Note that I do most of my buiding with --no-grafts.
>
> This is an unsafe thing to do.
Depends on the machine and what it is used for. Yes, for services that
can b
The two errors are not related. When I choose a different target
profile the second error goes away.
In a clean profile both errors will probably go away...
--
Note that I do most of my buiding with --no-grafts.
Not sure they are related:
Using the Guix tree from source 4a3495d57c08dff9287fe559482a6d2009109304
./pre-inst-env guix package -i python@2.7.13
renders
Backtrace:
In ice-9/eval.scm:
432: 19 [eval # #]
In ice-9/boot-9.scm:
2412: 18 [save-
On Sat, Apr 15, 2017 at 06:48:40PM +0300, Frederick Muriithi wrote:
> Package: guix
> Version: 0.12.0
>
> Dear Guix,
>
> This is bug is to track adding conda and its dependencies. I will be
> sending patches adding the dependencies for conda here, until we get
> conda in mainline.
Thanks Frederi
On Mon, Mar 06, 2017 at 03:52:07PM +0100, Ricardo Wurmus wrote:
> > Removing the surprise can be […] by […] making `guix pull' able to update
> > guix-daemon as well.
>
> That’s what is planned for “guix pull” anyway IIRC. I suspect this
> would be easier if we had a daemon written in Guile.
Thi
On Sun, Mar 05, 2017 at 08:56:41AM +0100, Tomáš Čech wrote:
> And IMHO the best and also "Guix way" could be making guix-daemon aware of
> possible newer versions in /gnu/store and execing them instead...
Giving a loud warning should really be sufficient. The Guix way is to
have a system not surpr
We can make package 'daemon' aware if we provide the meta data in
channels, see 22...@debbugs.gnu.org. guix package could also suggest
upgrading with even numbers. Say running 0.12 guix on 0.10
guix-daemon.
I wrote up a 'white paper' on a new implementation of Guix channels.
The easy on the eyes version you can read here:
https://github.com/pjotrp/guix-notes/blob/master/proposals/channel.org
* On Channels
Related to debbugs https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22629 and
https://debbug
On Tue, Feb 21, 2017 at 09:44:03AM +1100, Ben Sturmfels wrote:
> On Sat, 18 Feb 2017 16:30:34 +
> Pjotr Prins wrote:
>
> > Yes, using the latest guix-daemon and guix client fixed it:
> >
> > /gnu/store/175nlv448nk5kagwwl3zyy2w4726qfz6-guix-0.12.0-4.d9da/bin/guix-
Yes, using the latest guix-daemon and guix client fixed it:
/gnu/store/175nlv448nk5kagwwl3zyy2w4726qfz6-guix-0.12.0-4.d9da/bin/guix-daemon
/home/pjotr/genenetwork/guix/scripts/guix --version
guix (GNU Guix) 20170218.09
./pre-inst-env guix import cpan Time::ParseDate
Starting download of /tmp/g
On Sat, Feb 18, 2017 at 04:35:06PM +0100, Ricardo Wurmus wrote:
>
> Pjotr Prins writes:
>
> > I am seeing the same on a fresh checkout and build:
>
> Sirgazil wrote that an old version of the guix-daemon is in use. What
> version of the guix-daemon are you u
And this appears to be related:
./pre-inst-env guix import cpan Time::ParseDate
Starting download of /tmp/guix-file.4UM1ZV
>From
>http://mirror.ibcp.fr/pub/CPAN/authors/id/M/MU/MUIR/modules/Time-ParseDate-2015.103.tar.gz...
...2015.103.tar.gz 26KiB 214KiB/s 00:00 [
I am seeing the same on a fresh checkout and build:
penguin2:~/genenetwork/guix$ ./pre-inst-env guix package -p
$HOME/opt/guix-build-system --install autoconf
warning: failed to install locale: Invalid argument
Backtrace:
In guix/packages.scm:
982: 19 [bag-grafts # #]
966: 18 [fold-bag-dependen
On Sat, Aug 13, 2016 at 06:05:17PM -0400, Harry Prevor wrote:
> Hey all,
>
> I'm running GuixSD on a Thinkpad X200. I typically run 'guix pull'
> almost every day without any troubles, but about two days ago I
> started getting this error every time I ran the command leaving me
> unable to update
while restoring
'/gnu/store/kcc3cxnx9l2hbg7pjhxsa0r5yq2j2f38-python-2.7.10/lib/python2.7/email/test/test_email_renamed.pyc'
from #{read pipe}#
killing process 17595
On Sun, Apr 03, 2016 at 10:20:00AM +0200, Pjotr Prins wrote:
> http://mirror.guixsd.org/nar/6kvy3ryb04nl49wwdy0dmhhf
http://mirror.guixsd.org/nar/6kvy3ryb04nl49wwdy0dmhhfnfbwrmna-tcl-8.6.4
1017KiB/s 00:02 | 1.7MiB transferred
bzip2: Compressed file ends unexpectedly;
perhaps it is corrupted? *Possible* reason follows.
bzip2: Inappropriate ioctl for device
Input file = (stdin), output file = (st
http://mirror.guixsd.org/nar/7v3093adf31b2sg2c46y3z2m24x2cjmi-gs-fonts-8.11
815KiB/s 00:02 | 1.2MiB transferred
bzip2: Compressed file ends unexpectedly;
perhaps it is corrupted? *Possible* reason follows.
I am also seeing such corruption on my substitutes server. Is there a way
we can validate files in a running cache so they can be rebuild? Would
be useful for the mirror.guixsd.org too.
I am glad they get picked up (even so) and that we have the --fallback
option :)
Pj.
On Wed, Mar 23, 2016 at 0
Same here. It is the new graft thing. Just a guix pull will do it.
288: 10 [#
"/gnu/store/8cv92vy3m47v2b2pf73jdz9k26lzl1xw-libgc-7.4.2" ...]
In guix/grafts.scm:
225: 9 [dependency-grafts
"/gnu/store/8cv92vy3m47v2b2pf73jdz9k26lzl1xw-libgc-7.4.2"]
156: 8 [item->deriver #
"/gnu/store/8cv92vy3m4
On Sun, Feb 21, 2016 at 11:36:50PM +0100, Ludovic Courtès wrote:
> Running ‘configure’ creates guix/config.scm. Could you check that this
> is the case?
Got it:
(define %gzip
"/home/wrk/.guix-profile/bin/gzip")
(define %bzip2
"/home/wrk/opt/guix-build-system/bin/bzip2")
(define %xz
"/ho
On Mon, Feb 15, 2016 at 12:28:14PM +0100, Ricardo Wurmus wrote:
> This looks like it is a result of an undefined %bzip2, %xz, and/or %gzip
> value. These values are used by utils.scm to assemble a command. They
> are defined in config.scm, which is created at configure/build time.
Nice error mes
When I run lint on a recent ceckout
./pre-inst-env guix lint
or
./pre-inst-env guix lint python
I get
filtered-port: failed to execute ' -dc ': No such file or directory
Backtrace:
In unknown file:
?: 19 [apply-smob/1 #]
In ice-9/boot-9.scm:
63: 18 [call-with-prompt prompt0 ...]
In
On Thu, Jan 21, 2016 at 09:50:18AM +0100, Ludovic Courtès wrote:
> This is expected: origins are fixed-output derivations, meaning that it
> does not matter how we perform them (using Git, over HTTP, or thanks to
> an avian carrier), as long as the result has the specified sha256.
>
> Thus, when y
I can reliably reproduce this using a recent version of GNU Guix.
When updating the commit hash to a different commit the git-fetch
derivation *does* change (I checked in guile), but the checked out git
tree in the store does not change - it gets shared between the
commits. I am not sure why the
it is by design that you can't symlink.
On Sat, Aug 08, 2015 at 06:51:17AM +0200, Claes Wallin wrote:
>Not commenting on the underlying problem, but on your workaround.
>
>On 07-Aug-2015 11:22 pm, "Kragen Javier Sitaker" <[1]kra...@canonical.org>
>wrote:
>>
>> Apparently I can
60 matches
Mail list logo
