guix-comm...@gnu.org writes:
> apteryx pushed a commit to branch master
> in repository guix.
>
> commit 3f1f98d9d8c4e7f5dfca921fe1957e4d53783e35
> Author: Maxim Cournoyer
> AuthorDate: Tue Jan 28 01:21:24 2020 -0500
>
> gnu: Add libuemf.
>
> * gnu/packages/image.scm (libuemf): New v
Maxim Cournoyer writes:
> On the current master branch,
>
> make check TESTS=tests/guix-package.sh
>
> [...]
>
> PASS: tests/guix-package.sh
>
> Testsuite summary for GNU Guix 1.0.1.17120-e7b86a0
> ===
Hi Sandeep/uniq10, welcome!
I'm the person that worked on the rewrite last year (I like to go by
reepca in conversations and irc). I'm glad that you'll be working on it
this summer. I still feel like I didn't do enough last summer, though,
so if there's any way I can help, I'd be glad to (though t
atch.
signature.asc
Description: PGP signature
>From e9fdaec83568d14b5462757b473ed6f25b3f114e Mon Sep 17 00:00:00 2001
From: Caleb Ristvedt
Date: Tue, 8 Jan 2019 01:26:59 -0600
Subject: [PATCH] patches: honor NIX_STORE in site.py.
Previously various python packages would fail to work unless the store they
were kept in was /gnu/
I'd just like to add that if a user has guix installed for root but only
really keeps their user's guix up to date (I imagine a fairly common
situation), they're in for a weird situation when using sudo: a
bleeding-edge guix will complain about being outdated, since sudo (even
with -E) sets $USER,
to say that it's out of date, even
though the guix actually used for reconfiguring may not be out of date. It
pretty much only ever comes up when reconfiguring, but for those like
myself who are worried by messages like that it can be confusing to try to
resolve.
On Fri, Jan 18, 2019 at 11:33
Hello!
Ludovic Courtès writes:
> Could you try and rebase ‘guile-daemon’ on top of these modules? I’m
> happy to answer any questions you may have regarding modifications that
> I made.
I'm not sure what is meant by "on top of these modules". If I understand
correctly, the problem is that whil
Björn Höfling writes:
> Why does that take soo long?
Warning: technical overview follows.
It takes so long because after the garbage collection pass it then does
a *full* pass over the /gnu/store/.links directory. Which is huge. It
contains an entry for every unique file (not just store entry,
Ludovic Courtès writes:
> Note that the database would need to contain hashes of individual files,
> not just store items (it already contains hashes of store item nars).
Indeed! Although last night I thought of a way that it would only need
to contain hashes of *unique* individual files, see be
e way the test
currently is. But then again, ff...fff-fake is probably already not
the right filename to be generated for that file anyway. Should we try
to do things "the proper way" there?
> Could you send updated patches?
>From 5ae8c31826f06f4ad0b52a4d7b0cd6c4abc64a20 Mon Sep 17
The description of "replaces the likes of autools, cmake" makes sense, but
I'm not sure I understand the more advanced features being described -
specifically "... should ultimately be able to run complex workflows on
multiple servers...". Does that just mean that the build process should be
able t
time for those goals reasonable, evenly
spaced, etc?
Here's the full proposal as I have it now:
* Name
Caleb Ristvedt (irc nickname: reepca)
* email address
caleb.ristv...@cune.org
* name of project
Guix Rewrite build daemon in Guile Scheme
* Summary
Currently the build daemo
Hello everyone. I'm the aforementioned reepca (pronounced reep-kay). Nice
to meet you all, and I look forward to working on this project!
On Fri, May 5, 2017 at 3:50 PM, Ludovic Courtès wrote:
> Hello Guix!
>
> I’m happy to announce that reepca (Cc’d) will join us for the Google
> Summer of Code
lite, which
requires root access to open for writing. Perhaps the test is using an
environment variable or similar to specify a different database, which I
haven't implemented yet.
Comments welcome.
>From f4af8973a7b41664130b05bbe8a4069f62a087c3 Mon Sep 17 00:00:00 2001
From: Caleb Ris
new top-level posts? And how often should I send them?
Again, comments welcome.
>From 90f250814b1456387b8b0341b1f245a1c4e05f66 Mon Sep 17 00:00:00 2001
From: Caleb Ristvedt
Date: Sat, 3 Jun 2017 02:26:05 -0500
Subject: [PATCH 1/7] Implement prototype register-path in scheme
New file and mod
elsewhere? (If you have an account on Savannah we can give you access.)
I just made an account today as "reepca". Should I submit a "request for
inclusion"? In the meantime, here's a much less fixup-riddled patch set
that I think is just about feature-complete as far as re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Apologies for the delay - in a shocking twist, it turns out professors
insisting on only one exit from functions had a point, and trying to
fully understand what optimisePath_, with its 14 exits and a goto, does,
was a challenge. I think I handle mos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hm, M-x epa-mail-verify says the signature is wrong. When I test it
without an attachment, it works fine. That's strange, I would have
thought epa-mail-sign would be aware of such things. Anyway, here's a
message that should verify correctly.
-BE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I figured out why I was getting those two test failures after looking
more closely at tests/store.log: when I installed GuixSD, I did so
directly from another hard drive on the same system (having read in the
past about issues with multi-booting, I f
Hello everyone. It's already almost July! Which means I've been working
on replacing the build daemon for about a month now. So it seems like a
good time for an update.
So far, I've replaced the register-path procedure in store.scm, which
means we now have some support for using sqlite (via guile-
Hello guix!
After a pileup of changes and testing, I finally got around to pushing
my changes to the guile-daemon to the branch on savannah. The big
addition is half-working derivation-building (just one at a time, for
now, and only chroot builds for now) in the form of
guix/store/build-derivation
> Is there a line above or below the backtrace mentioning the uncaught
> exception? Could you ‘strace -f’ the daemon process?
No, no line above or below. Very strange.
> BTW, I see the code uses ‘clone’ directly. It would be safer to use
> ‘call-with-container’, which already handles bind moun
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
As the official work time for GSoC draws to a close, it seems fitting to
summarize where the project is at right now. *deep breath*
What works: building hello. I tried building SBCL as well, but building
one of the dependencies caused hanging (but t
> A problem is that we should not pull in these two modules here, because
> they are conceptually at a higher level (they have to do with talking to
> a separate daemon process.)
>
> So perhaps a first step would be to re-arrange things, probably along
> these lines:
>
> • Move the .drv parsing c
> I finally got around to fixing it in
> a31174e896047e6a0f42b69db331fdeebb3cc995.
>
> The kludge is no longer needed!
Great. Here are updated patches:
>From 287879a825f41c46cc5091c715467e476d465def Mon Sep 17 00:00:00 2001
From: Caleb Ristvedt
Date: Mon, 1 Apr 2019 15:04:5
I'm currently focusing on two particular RPCs that we use, addToStore
and addTextToStore. In the Nix thesis I only see reference to
addToStore. What's the difference between the two? I see that
addTextToStore allows specifying references while addToStore doesn't,
and addTextToStore is specifically
gcc-boot0 in (gnu packages commencement) compiles subtly differently
when built in a chroot (for example, by an installed daemon) compared to
when built without root privileges (for example, in
test-env). Specifically, the presence of this line in the build log:
../../gcc-5.5.0/gcc/genmultilib: ./
Maxim Cournoyer writes:
> Hello Caleb,
>
> Sorry if this answer is late; I noticed nobody had replied yet, so
> thought I'd try.
Thanks.
> That's an interesting find! What exactly is the 'test-env'? Do you mean
> an environment created using 'guix environment --pure' ?
No, test-env is the name
#:modules and #:imported-modules are distinct arguments. #:modules is the
modules that your builder is going to use (as in "they go in a (use-modules
...) form"), while #:imported-modules is the modules that need to be
available
in the build environment. It's complaining at build-time that it can't
Jan Wielkiewicz writes:
> I tried both ways - the second works, but the first doesn't.
That would be the "in theory, it would work" part. On further investigation,
source-module-closure has a #:select? keyword argument, which takes a module
name and returns #f if it shouldn't be included in the
30 matches
Mail list logo
