Hello!
Ricardo Wurmus skribis:
> Right. In the meantime we may want to discuss how to implement this.
> Could it just be done as a specification for the Guix CI? Since this
> should not be stealing resources from the build farm and thus should run
> on a separate system, how can we make sure t
> So I ran
>
>guix build --log-file
> /gnu/store/wk9qbhmdzs62mp40casrndcgm3p50m3b-diamond-0.9.22.drv
>
> which gave me
>
>/var/log/guix/drvs/wk/9qbhmdzs62mp40casrndcgm3p50m3b-diamond-0.9.22.drv.bz2
>
> which contains the build log for this failed build, including the "foo"
> error mess
On Wed, Sep 12, 2018 at 10:59:33PM +0200, Ricardo Wurmus wrote:
>
> Hi Pjotr,
>
> >> But even this may not be enough for an on-demand service. It might,
> >> however, be enough for a service that regularly builds packs for certain
> >> common environments from packages the build farm has already
Hi Pjotr,
>> But even this may not be enough for an on-demand service. It might,
>> however, be enough for a service that regularly builds packs for certain
>> common environments from packages the build farm has already built.
>>
>> (This would be done with the squashfs backend, which is way f
On Wed, Sep 12, 2018 at 07:43:42PM +0200, Ricardo Wurmus wrote:
>
> Ludovic Courtès writes:
>
> > A while back we fantasized about the possibility of having a web service
> > that would produce “packs” of Guix packages on demand. That may allow
> > us to be #1 on HN for a couple of hours ;-), b
I figured it out thanks to the people on IRC:
(arguments
`(;; Roundup has no check target (It does have a `test` target, but some
;; of its tests fail intentionally, bringing the entire build process
;; down)
#:tests? #f
;; Explicitly set the shell because
Hi Tobias,
> Ricardo Wurmus wrote:
>> Note that the patch cannot be applied because I had to change how “@
>> build-failed” is treated. The underlying problem here is that the
>> daemon may send a multi-line message through the port, which
>> unfortunately doesn’t necessarily arrive in one piec
Ludovic Courtès writes:
> A while back we fantasized about the possibility of having a web service
> that would produce “packs” of Guix packages on demand. That may allow
> us to be #1 on HN for a couple of hours ;-), but it would also be quite
> resource-hungry (and the service itself needs t
Ricardo,
[And apologies for another empty mail, everyone.]
Ricardo Wurmus wrote:
Note that the patch cannot be applied because I had to change
how “@
build-failed” is treated. The underlying problem here is that
the
daemon may send a multi-line message through the port, which
unfortunately d
Hello,
Pjotr Prins skribis:
> I know this is not a priority right now for maintainers, but I think
> it would be really useful if we provide ready-made containers for
> certain packages. This will allow people who have the infrastructure
> to run containers to start using reproducible Guix build
Ricardo Wurmus wrote:
Hi,
What about immediately giving the file name of the log, as with
the
patch attached? Several people have already mentioned not
knowing about
‘guix build --log-file’ so this would probably be helpful.
This would be fine.
Note that the patch cannot be applied becaus
Hi,
> What about immediately giving the file name of the log, as with the
> patch attached? Several people have already mentioned not knowing about
> ‘guix build --log-file’ so this would probably be helpful.
This would be fine.
Note that the patch cannot be applied because I had to change ho
Hello,
HiPhish skribis:
> Is there a way to get the module from a REPL? I can run a REPL in my editor,
> that's the crutch I have been using so far. (IMO tying the readability of the
> source code to the development environment is a bad idea, that's what IDEs
> always end up doing)
>From the
Hello,
HiPhish skribis:
> Thanks to both of you I can now at least get the configure script to run, but
> it stops because it cannot find `cat`:
>
> starting phase `configure'
> building for Linux on localhost at Tue Sep 11 10:46:19 UTC 2018
> looking for /bin/sh./configure: line 89: expr: comm
Hello,
Paul Garlick skribis:
> I have just needed to introduce a couple of concepts in order to use
> the ./pre-inst-env commands in the git checkout. Firstly, I use a
> development environment created by:
Once you have run ‘guix pull’, the ‘guile-gcrypt’ package is known and
it’s an input to
Hello,
Ricardo Wurmus skribis:
>> On latest
>>
>> ./pre-inst guix package -i something
>>
>> The new color scheme is nice for output. But I miss the old build
>> logs. How do I get them back?
>
> The build logs are stored by the daemon. You can get their location by
> doing
>
> guix build
On Wed, Sep 12, 2018 at 08:52:36AM +0200, Ricardo Wurmus wrote:
> It does seem to work. To test this I added (error "foo") to a build
> phase in the “diamond” package and ran
>
>guix package -i diamond
>
> This ends with
>
>Build failed:
> /gnu/store/wk9qbhmdzs62mp40casrndcgm3p50m3b-d
I know this is not a priority right now for maintainers, but I think
it would be really useful if we provide ready-made containers for
certain packages. This will allow people who have the infrastructure
to run containers to start using reproducible Guix builds. With that,
I think there will be an
On Fri, Aug 24, 2018 at 11:42:48AM +0200, Ricardo Wurmus wrote:
>
> Pjotr Prins writes:
>
> > Who wants to come to a separate 2 day GNU Guix event?
> >
> > That is the Thursday Jan 31st and/or Friday Feb 1st right before
> > FOSDEM. I.e., 4 days of hacker nirvana.
>
> I plan to be there for the
19 matches
Mail list logo
