unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Building things other than Guix with Cuirass
@ 2017-09-18 20:59 Christopher Baines
  2017-09-19  8:24 ` Efraim Flashner
  2017-09-19 11:55 ` ng0
  0 siblings, 2 replies; 6+ messages in thread
From: Christopher Baines @ 2017-09-18 20:59 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]

Hey,

At the GHM, one of the things I looked in to was cuirass. Specifically,
I tried to see if I could build a collection of guix packages that sit
outside of Guix.

From trying to use cuirass for a few hours, I began thinking that it
might be beneficial to change the interface between cuirass and the
jobs.

The interface provided by cuirass to fetch jobs through consists of
specifying a Guile load path, file, procedure, and arguments to that
procedure.

Currently, something like this is used to describe how to get some
jobs.

  `((#:name . "hello")
    (#:url . "git://git.savannah.gnu.org/guix.git")
    (#:branch . "master")
    (#:no-compile? . #t)
    (#:load-path . ".")
    (#:proc . cuirass-jobs)
    (#:file . "/tmp/drv-file.scm")
    (#:arguments (subset . "hello")))

As an example, with minor changes to the way arguments are handled, I
think this could also be represented as a invocation of guile.

  `((#:name . "hello")
    (#:url . "git://git.savannah.gnu.org/guix.git")
    (#:branch . "master")
    (#:no-compile? . #t)
    (#:command "guile -L. -s /tmp/drv-file.scm -e cuirass-jobs -- --subset=hello"))

However, if you've gone to the trouble to have a Guile program, it
might be easier to make it executable directly.

  `((#:name . "hello")
    (#:url . "git://git.savannah.gnu.org/guix.git")
    (#:branch . "master")
    (#:no-compile? . #t)
    (#:command "/tmp/drv-file.scm --subset=hello"))

It might also be possible to remove the hardcoded compilation process
and just use the single command. However, it might be better to be able
to specify a separate compilation command or list of commands.

Back to the jobs though, Cuirass already executes a separate command to
load jobs, but this is hardcoded to the evaluate command. I think
changing the interface to allow directly specifying a command would
open up new possibilities for cuirass, and at the same time simplify
the implementation and interface.

I've tried out using this approach for building a collection of guix
packages that sit outside of guix, and it seems to work well. I copied
one of the examples, and wrote a guile program that when run prints out
the jobs. Cuirass then runs a bash script that sets up the correct
environment with the guix environment command, and then invokes the
guile script to generate the jobs.

I'm half way through writing a proper patch for this, but I haven't
moved all the functionality in the evaluate command in to cuirass yet.

Does anyone have any opinions or ideas about this part of cuirass, or
building things other than the packages in the Guix repository with it?

Thanks,

Chris

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Building things other than Guix with Cuirass
  2017-09-18 20:59 Building things other than Guix with Cuirass Christopher Baines
@ 2017-09-19  8:24 ` Efraim Flashner
  2017-09-20  5:53   ` Christopher Baines
  2017-09-19 11:55 ` ng0
  1 sibling, 1 reply; 6+ messages in thread
From: Efraim Flashner @ 2017-09-19  8:24 UTC (permalink / raw)
  To: Christopher Baines; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Mon, Sep 18, 2017 at 09:59:06PM +0100, Christopher Baines wrote:
> Hey,
> 
> At the GHM, one of the things I looked in to was cuirass. Specifically,
> I tried to see if I could build a collection of guix packages that sit
> outside of Guix.
> 
...
>
> Does anyone have any opinions or ideas about this part of cuirass, or
> building things other than the packages in the Guix repository with it?
> 
> Thanks,
> 
> Chris

I was thinking of running it on my aarch64 board to test some of the
packages that specifically give aarch64 a hard time, like gsl. Or the
gstreamer plugin packages, which sometimes pass and sometimes fail their
test suites.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Building things other than Guix with Cuirass
  2017-09-18 20:59 Building things other than Guix with Cuirass Christopher Baines
  2017-09-19  8:24 ` Efraim Flashner
@ 2017-09-19 11:55 ` ng0
  1 sibling, 0 replies; 6+ messages in thread
From: ng0 @ 2017-09-19 11:55 UTC (permalink / raw)
  To: Christopher Baines; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 3695 bytes --]

Christopher Baines transcribed 3.8K bytes:
> Hey,
> 
> At the GHM, one of the things I looked in to was cuirass. Specifically,
> I tried to see if I could build a collection of guix packages that sit
> outside of Guix.

I would be very much interested in exploring the possibility
(at the very least testing/experimenting with) to use cuirass to build
the "gnunet" and "gnunet-doc" guix definitions which reside inside the
gnunet repository (and more to come, in other GNUnet related repos
with the perspective on integrating it into our (GNUnet) infrastructure
once cuirass proves to be mature enough. Ultimately to evaluate if (or
when) it could replace buildbot (and if not, what needs to be improved
in cuirass to get to the point where it could replace it).

That is my "ideas for cuirass" (you can ask me to split up this horrible
long sentence if it's a problem.)

> From trying to use cuirass for a few hours, I began thinking that it
> might be beneficial to change the interface between cuirass and the
> jobs.
> 
> The interface provided by cuirass to fetch jobs through consists of
> specifying a Guile load path, file, procedure, and arguments to that
> procedure.
> 
> Currently, something like this is used to describe how to get some
> jobs.
> 
>   `((#:name . "hello")
>     (#:url . "git://git.savannah.gnu.org/guix.git")
>     (#:branch . "master")
>     (#:no-compile? . #t)
>     (#:load-path . ".")
>     (#:proc . cuirass-jobs)
>     (#:file . "/tmp/drv-file.scm")
>     (#:arguments (subset . "hello")))
> 
> As an example, with minor changes to the way arguments are handled, I
> think this could also be represented as a invocation of guile.
> 
>   `((#:name . "hello")
>     (#:url . "git://git.savannah.gnu.org/guix.git")
>     (#:branch . "master")
>     (#:no-compile? . #t)
>     (#:command "guile -L. -s /tmp/drv-file.scm -e cuirass-jobs -- --subset=hello"))
> 
> However, if you've gone to the trouble to have a Guile program, it
> might be easier to make it executable directly.
> 
>   `((#:name . "hello")
>     (#:url . "git://git.savannah.gnu.org/guix.git")
>     (#:branch . "master")
>     (#:no-compile? . #t)
>     (#:command "/tmp/drv-file.scm --subset=hello"))
> 
> It might also be possible to remove the hardcoded compilation process
> and just use the single command. However, it might be better to be able
> to specify a separate compilation command or list of commands.
> 
> Back to the jobs though, Cuirass already executes a separate command to
> load jobs, but this is hardcoded to the evaluate command. I think
> changing the interface to allow directly specifying a command would
> open up new possibilities for cuirass, and at the same time simplify
> the implementation and interface.
> 
> I've tried out using this approach for building a collection of guix
> packages that sit outside of guix, and it seems to work well. I copied
> one of the examples, and wrote a guile program that when run prints out
> the jobs. Cuirass then runs a bash script that sets up the correct
> environment with the guix environment command, and then invokes the
> guile script to generate the jobs.
> 
> I'm half way through writing a proper patch for this, but I haven't
> moved all the functionality in the evaluate command in to cuirass yet.
> 
> Does anyone have any opinions or ideas about this part of cuirass, or
> building things other than the packages in the Guix repository with it?
> 
> Thanks,
> 
> Chris



-- 
ng0
GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
GnuPG: https://krosos.org/dist/keys/
https://www.infotropique.org https://www.krosos.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Building things other than Guix with Cuirass
  2017-09-19  8:24 ` Efraim Flashner
@ 2017-09-20  5:53   ` Christopher Baines
  2017-09-20  6:20     ` Jan Nieuwenhuizen
  0 siblings, 1 reply; 6+ messages in thread
From: Christopher Baines @ 2017-09-20  5:53 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1008 bytes --]

On Tue, 19 Sep 2017 11:24:45 +0300
Efraim Flashner <efraim@flashner.co.il> wrote:

> On Mon, Sep 18, 2017 at 09:59:06PM +0100, Christopher Baines wrote:
> > Hey,
> > 
> > At the GHM, one of the things I looked in to was cuirass.
> > Specifically, I tried to see if I could build a collection of guix
> > packages that sit outside of Guix.
> >   
> ...
> >
> > Does anyone have any opinions or ideas about this part of cuirass,
> > or building things other than the packages in the Guix repository
> > with it?
> > 
> > Thanks,
> > 
> > Chris  
> 
> I was thinking of running it on my aarch64 board to test some of the
> packages that specifically give aarch64 a hard time, like gsl. Or the
> gstreamer plugin packages, which sometimes pass and sometimes fail
> their test suites.

Providing these packages sit within the Guix repository, I think there
are configuration examples for building a subset of packages already
(e.g. I think this is what the hello related examples do).

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Building things other than Guix with Cuirass
  2017-09-20  5:53   ` Christopher Baines
@ 2017-09-20  6:20     ` Jan Nieuwenhuizen
  2017-10-08 13:02       ` Christopher Baines
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Nieuwenhuizen @ 2017-09-20  6:20 UTC (permalink / raw)
  To: Christopher Baines; +Cc: guix-devel

Christopher Baines writes:

> Providing these packages sit within the Guix repository,

...and if they don't you can set

    (#:load-path . "/your/packages/directory")

(It says path, but means directory I think).

> I think there are configuration examples for building a subset of
> packages already (e.g. I think this is what the hello related examples
> do).

I have just[0] added, next to the hardcoded "hello", the option to build
a list of packakges, to be used like so

    (#:arguments (subset . ("hello" "sed" "grep")))

Does that help?
Greetings,
janneke

[0] http://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=bbab646926714ad6cdaac3e4578a14b408b65a84
    A similar patch is waiting for guix proper.
    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28487

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Building things other than Guix with Cuirass
  2017-09-20  6:20     ` Jan Nieuwenhuizen
@ 2017-10-08 13:02       ` Christopher Baines
  0 siblings, 0 replies; 6+ messages in thread
From: Christopher Baines @ 2017-10-08 13:02 UTC (permalink / raw)
  To: Jan Nieuwenhuizen; +Cc: guix-devel

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On Wed, 20 Sep 2017 08:20:18 +0200
Jan Nieuwenhuizen <janneke@gnu.org> wrote:

> Christopher Baines writes:
> 
> > Providing these packages sit within the Guix repository,  
> 
> ...and if they don't you can set
> 
>     (#:load-path . "/your/packages/directory")
> 
> (It says path, but means directory I think).
> 
> > I think there are configuration examples for building a subset of
> > packages already (e.g. I think this is what the hello related
> > examples do).  
> 
> I have just[0] added, next to the hardcoded "hello", the option to
> build a list of packakges, to be used like so
> 
>     (#:arguments (subset . ("hello" "sed" "grep")))
> 
> Does that help?

Thanks Jan. I've had another look at this, and I've got something
working with my current guix environment approach.

However, I've done this by getting the proc passed to cuirass to
execute a command which outputs the job definitions (in the same format
as the evaluate command).

This isn't very elegant, as it means that the data goes through a
rather convoluted path.

I guess that the environment could be set at the point the
specifications are created, but I'm not sure how to do that yet.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-10-08 13:02 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-18 20:59 Building things other than Guix with Cuirass Christopher Baines
2017-09-19  8:24 ` Efraim Flashner
2017-09-20  5:53   ` Christopher Baines
2017-09-20  6:20     ` Jan Nieuwenhuizen
2017-10-08 13:02       ` Christopher Baines
2017-09-19 11:55 ` ng0

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).