Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Tue, Jul 26, 2016 at 05:40:49AM +0200, Pjotr Prins wrote:
> On Mon, Jul 25, 2016 at 11:21:43AM +0200, Ludovic Courtès wrote:
> > I like the idea!  (With the caveat that, again, external repos can break
> > anytime.)
> >
> > Partly related to that:
> > .

And I think we can use a much smaller git package for this. No need to
include the kitchen sink!

Re: A registry for distributed sources and binaries

[Pjotr Prins]

On Mon, Jul 25, 2016 at 11:21:43AM +0200, Ludovic Courtès wrote:
> I like the idea!  (With the caveat that, again, external repos can break
> anytime.)
>
> Partly related to that:
> .

Actually very much related because a git pull attached to a git tree
can be tied with a remote repo - allowing for elegant API transitions.

guix channel add genenetwork git://git.sv.gnu.org/guix.git master HASHTAG
guix channel pull genenetwork
guix channel set genenetwork

Do the Ricardo stuff...

Pretty much solves the API problem.

Pj.

FOSDEM 2016 was awesome! Let's do FOSDEM 2017

[Pjotr Prins]

FOSDEM 2017 call for proposals has started:

  https://fosdem.org/2017/news/2016-07-20-call-for-participation/

We need help with writing the proposal (we can build on last years
this time), we need help on selecting talks and we need help creating
the schedule. Finally, if we get a slot, we need help to organise the
day.

Who wants to be part of this exciting day? 

Pj.

On Tue, Feb 02, 2016 at 11:35:45AM -0800, Christopher Allan Webber wrote:
> Alex Sassmannshausen writes:
> 
> > Hello,
> >
> > Ludovic Courtès writes:
> >
> >> Hi there!
> >>
> >> I just came back from FOSDEM where we had an awesome Guile devroom with
> >> nice people and great talks!
> >
> > I really want to echo Ludo's sentiments.  I had a great time in our dev
> > room and it was really nice to put faces to the names I see popping up
> > in IRC and on the mailing list. I really hope we'll be able to do this
> > again next year!
> 
> An extra echo from me.
> 
> >> The room of 80 seats was full pretty much all the time, and I think we
> >> were all excited to see so many people stop by the devroom.  Many shared
> >> the impression that we were at an important moment of Guile’s history.
> >> The transition with the Lua track that followed was also insightful and
> >> a pleasant experience.
> 
> I was optimistic about this being a big moment in Guile's history, but
> after this FOSDEM, my enthusiasm and excitement has doubled, maybe
> tripled!  I can't wait to see what's happening in the year ahead!
> 
> >> I would like to send a big Thank You to Pjotr Prins who took the
> >> initiative and organized all this masterfully, from applying for the
> >> devroom, to contacting potential speakers (dozens and dozens of
> >> messages!), to getting up early on Saturday to make sure everything
> >> would be fine in the devroom…  Pjotr, you did an awesome job!
> >>
> >> Thanks to Paul van der Walt who also woke up early to help out with
> >> video in the devroom, and obviously, thanks to all the speakers and
> >> attendees!
> >
> > +1 for sure.  Thank you very much for the commitment in time and energy!
> >
> > Alex
> 
> Yes, thank you! :)

-- 

Re: Go & bundling

[Catonano]

2016-07-26 0:05 GMT+02:00 Ludovic Courtès :

> Leo Famulari  skribis:
>
> > We will have to decide what to do about bundled dependencies. Bundling
> > the source code of dependencies appears to be standard practice in the
> > world of Go.
>
> Bundling appears to be standard practice in the world.
> :-)
>
> > The compiler began supporting this directly in the 1.5 series:
> >
> https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment
> >
> > This is the manifest of Syncthing's dependencies, which are bundled in
> > the same directory:
> > https://github.com/syncthing/syncthing/blob/master/vendor/manifest
> >
> > If that manifest is a standard thing, we could make a go-importer that
> > used it to create new packages.
>
> Indeed, that would be pretty cool as it effectively provides an easy way
> for users to “unbundle” if they want to.  Much more transparent that
> what is often practiced.
>

The "new packages" indicated in the manifest could, in turn, have bundled
dependencies. So the importer should be a recursive one.

Like the one that Jelle is using for npm.

Right ?

Re: core-updates, next release, and all that

[Ludovic Courtès]

Andreas Enge  skribis:

> On Sun, Jul 24, 2016 at 12:59:22PM -0400, Leo Famulari wrote:
>> So strange. Could the source code have been corrupted while unpacking?
>> Can anyone replicate this locally, so they can use --keep-failed?
>
> Yes, but I still cannot make anything of it.
>
> The build phase boils down to
>cd /tmp/guix-build-lpsolve-5.5.2.0.drv-0/lp_solve_5.5/lpsolve55
>bash ccc
> where the latter command eventually runs
>gcc -s -c -I.. -I../shared -I../bfp -I../bfp/bfp_LUSOL 
> -I../bfp/bfp_LUSOL/LUSOL -I../colamd -O3 $def $NOISNAN -DYY_NEVER_INTERACTIVE 
> -DPARSER_LP -DINVERSE_ACTIVE=INVERSE_LUSOL -DRoleIsExternalInvEngine 
> ../lp_MDO.c ../shared/commonlib.c ../shared/mmio.c ../shared/myblas.c 
> ../ini.c ../fortify.c ../colamd/colamd.c ../lp_rlp.c ../lp_crash.c 
> ../bfp/bfp_LUSOL/lp_LUSOL.c ../bfp/bfp_LUSOL/LUSOL/lusol.c ../lp_Hash.c 
> ../lp_lib.c ../lp_wlp.c ../lp_matrix.c ../lp_mipbb.c ../lp_MPS.c 
> ../lp_params.c ../lp_presolve.c ../lp_price.c ../lp_pricePSE.c ../lp_report.c 
> ../lp_scale.c ../lp_simplex.c ../lp_SOS.c ../lp_utils.c ../yacc_read.c
>
> When I source the environment variables of the build, then gcc-4.9 is used,
> and the error message is printed. When I just install gcc-toolchain@5, it
> passes. But I do not think that the compiler version makes a difference.
>
> The offending lines are
> #ifndef FALSE
>   #define FALSE0
>   #define TRUE 1
> #endif
> which looks perfectly good. When I remove them, then the compiler complains
> that FALSE is not defined.

Fixed in commit 5dbfbef7292a43029b17e89d682d9e24703d5cd2.

(The problem was a wrong ‘isnan’ feature test, leading to -DNOISNAN,
leading to “#define isnan(x) FALSE”, so the ‘isnan’ declaration in
 was turned into “extern int FALSE __attribute__
((__nothrow__ , __leaf__)) __attribute__ ((__const__));”…)

Ludo’.

Re: Odd behavior with --dry-run and --upgrade

[Roel Janssen]

Ludovic Courtès writes:

> Hi!
>
> Alex Kost  skribis:
>
>> Roel Janssen (2016-07-23 18:11 +0300) wrote:
>>
>>> Dear Guix,
>>>
>>> For some time now, running `guix package --dry-run --upgrade' results in
>>> build actions involving grafting.  For a dry-run, I find that really
>>> odd.  I believe the correct behavior should be what can be achieved
>>> with: `guix package --dry-run --no-grafts --upgrade'.
>>
>> I'm totally agree with this; nowadays I always use --dry-run with
>> --no-grafts option.
>
> Same here…
>
>> As a user I expect that --dry-run means no building at all.
>>
>> BTW it's not just about ‘guix package --dry-run --upgrade’, it relates
>> to all commands, for example ‘guix build --dry-run foo’, etc.
>>
>> OTOH, if a future ‘--dry-run’ would mean what ‘--dry-run --no-grafts’
>> means now, than how to achieve what ‘--dry-run’ means now?  Or rather:
>> does anyone use just --dry-run (without --no-grafts)?  Is it really
>> useful?
>
> In theory it could be useful for ‘guix build’, since it’s a “low level”
> tool and people using it may want to be able to distinguish between
> grafted and non-grafted results.
>
> But honestly, I think changing ‘--dry-run’ to do ‘--dry-run --no-grafts’
> would be fine, and probably better than the current situation.

Could you provide some insight in where I should be looking to att the
check to 'graft?'?

Kind regards,
Roel Janssen

Re: Broken Calibre package

[Roel Janssen]

Andreas Enge writes:

> On Mon, Jul 25, 2016 at 10:42:16PM +0200, Andreas Enge wrote:
>> As a first fix, we should revert and replace qtbase by qt in the package.
>
> Things were a bit more complex; I also needed to build the python bindings
> in python2-pyqt with the non-modular Qt. So I re-added the previous version
> as python2-pyqt-5.5. I am going to push in a moment.

Thanks for your very quick response and solution!

Kind regards,
Roel Janssen

Go & bundling

[Ludovic Courtès]

Leo Famulari  skribis:

> We will have to decide what to do about bundled dependencies. Bundling
> the source code of dependencies appears to be standard practice in the
> world of Go.

Bundling appears to be standard practice in the world.
:-)

> The compiler began supporting this directly in the 1.5 series:
> https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment
>
> This is the manifest of Syncthing's dependencies, which are bundled in
> the same directory:
> https://github.com/syncthing/syncthing/blob/master/vendor/manifest
>
> If that manifest is a standard thing, we could make a go-importer that
> used it to create new packages.

Indeed, that would be pretty cool as it effectively provides an easy way
for users to “unbundle” if they want to.  Much more transparent that
what is often practiced.

> I don't fully understand Debian's packaging, but it seems that they only
> use external packages to provide 2 of 39 dependencies, bootstrap and
> font-awesome:
> https://anonscm.debian.org/git/pkg-go/packages/syncthing.git/tree/debian/rules#n42

It might be that even the bravest have given up.  ;-)

Ludo’.

Reviewer assignment

[Ludovic Courtès]

Hello!

Andy Wingo  skribis:

> A fully distributed system sounds nice but it has costs too.  In my mind
> for a project of Guix's target size the best situation would be having
> around 100 committers or so who have internalized the coding style and
> patterns of Guix so that they can work more or less directly on the
> parts they feel comfortable with, posting patches to the list as
> necessary for feedback.

Agreed.  That’s the spirit of the text in ‘HACKING’.

> An incoming patch would be assigned to one of those people based on
> automatic tooling.  In that way Guix can scale to the next step while
> remaining a consistent, hackable project.

That sounds like a good approach to me.

With the upcoming libgit2 bindings, we could cook up a tool that gives
people a list of likely reviewers that submitters could Cc, and suggest
it in
.

Thanks,
Ludo’.

DMD

[Andreas Enge]

Hello,

I just noticed that we still have a dmd package (that does not build on arm).
Should we not drop it now that we have the shepherd?

Andreas

Re: Broken Calibre package

[Andreas Enge]

On Mon, Jul 25, 2016 at 10:42:16PM +0200, Andreas Enge wrote:
> As a first fix, we should revert and replace qtbase by qt in the package.

Things were a bit more complex; I also needed to build the python bindings
in python2-pyqt with the non-modular Qt. So I re-added the previous version
as python2-pyqt-5.5. I am going to push in a moment.

Thanks for the report!

Andreas

Re: extending initrd

[Ludovic Courtès]

Hi,

Tomáš Čech  skribis:

> I'm playing a bit with initrd and I miss there a way, how to add
> additional content to the image (busybox in my case now). Is there
> really no way yet how to do that?

The initrd automatically contains everything the given gexp refers to:

--8<---cut here---start->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> ,use(gnu system linux-initrd)
scheme@(guile-user)> ,use(gnu packages busybox)
scheme@(guile-user)> ,enter-store-monad
store-monad@(guile-user) [1]> (expression->initrd #~(execl (string-append 
#$busybox "/bin/uname") "uname" "-a"))
$2 = # /gnu/store/5m2vp3z30b8f9yxv6yqa0x5imssl2qvr-guile-initrd 377cc30>
store-monad@(guile-user) [1]> (built-derivations (list $2))
[...]
--8<---cut here---end--->8---

… and then:

--8<---cut here---start->8---
$ gunzip < /gnu/store/5m2vp3z30b8f9yxv6yqa0x5imssl2qvr-guile-initrd/initrd | 
cpio -tv|grep busybox.*bin/uname
lrwxrwxrwx   1 root root7 Jan  1  1970 
./gnu/store/0rgimvxi572zncpr87q3867hkwkfmlva-busybox-1.25.0/bin/uname -> busybox
106143 blocks
--8<---cut here---end--->8---

> In expression->initrd it refers to closure yet I fail to find how is
> it found/constructed...

If you look at the definition of ‘expression->initrd’, you’ll see that
it turns the given gexp into a script using ‘gexp->script’.  In the
example above, said script refers to Busybox, because our expression
refers to Busybox.

Then, ‘expression->initrd’ queries the closure of this script via
#:references-graphs and populates the initrd with exclusively what’s in
that closure.  In this example, the closure includes Busybox and Guile.

Very short introduction, but I hope it helps!

Ludo’.

Re: [GSoC] Continuous integration tool à la Hydra.

[Ludovic Courtès]

Hello!

Mathieu Lirzin  skribis:

> Since my second update I have first fixed a major bug.  When building
> different branches of Guix and evaluating package derivations the
> results were always the same.  The issue was that the evaluations were
> happening in the same Guile process which does not play well with module
> changes.  To fix that I have used a separate process + pipe to get the
> evaluation results.

Sounds good.  Using a separate process makes sure what’s evaluated
doesn’t erroneously ends up using modules already loaded by the
evaluator, and vice versa.

> In the last update, I have introduced usage of SRFI-9 records for
> specifications, jobs, and builds.  While they are nice to organize data,
> they have major drawbacks:
>
> - not flexible when you want to informally create a container.
> - require serialization when passing them throught pipes.
>
> For those reasons I have switched to good ol' alists, which are flexible,
> persistant, directly readable and don't require messing with load paths.
> The downside is of course that there is no compile time checks when
> manipulating data.

OK.

> As stated in my last update.  I have been working on storing data in a
> database.  For that I have decided to use Guile-sqlite3.  The principal
> efforts have consist of using an external schema file and design it.
>
> I have come up with this, but this will likely evolve in the future:
>
> CREATE TABLE Specifications (
>   idINTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
>   repo_name TEXT NOT NULL,
>   url   TEXT NOT NULL,
>   load_path TEXT NOT NULL,
>   file  TEXT NOT NULL,
>   proc  TEXT NOT NULL,
>   arguments TEXT NOT NULL,
>   -- The following columns are optional.
>   branchTEXT,
>   tag   TEXT,
>   revision  TEXT
> );
>
> CREATE TABLE Evaluations (
>   derivationTEXT NOT NULL PRIMARY KEY,
>   job_name  TEXT NOT NULL,
>   specification INTEGER NOT NULL,
>   FOREIGN KEY (specification) REFERENCES Specifications (id)
> );

An evaluation leads to several derivations (for Guix, roughly one
derivation per package and per system type), but the table above seems
to suggest that each evaluation is mapped to only one derivation?

> CREATE TABLE Builds (
>   id  INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
>   derivation  TEXT NOT NULL,
>   log TEXT NOT NULL,
>   output  TEXT, -- NULL if build failed
>   FOREIGN KEY (derivation) REFERENCES Evaluations (derivation)
> );
>
> The next step will be to continue improving the database communication,
> and start looking how to implement the HTTP API.

Cool!  It seems that the database already has or is about to have the
info we typically look for at
: which evaluations were
performed, what commit (specification) they correspond to, which
derivations they correspond to and whether they
succeeded/failed/aborted.

If the HTTP API exposes this info, possibly using the same API as Hydra
(see guix-hydra-jobset.el), that will cover an important part of our
daily needs.

> For those willing to follow my work, a Git repository is available here:
>
>   https://notabug.org/mthl/cuirass

… and the README has instructions on how to run it.  If anyone has spare
CPU cycles, run Cuirass, ‘guix publish’, and share.  :-)

I’m happy with the progress that’s been made, thank you!

Ludo’.

Re: [GSoC update] Npm & guix

[Ludovic Courtès]

Hello!

Jelle Licht  skribis:

> On Ludo's advice, I snarfed Ricardo's recursive importer and bolted it
> on my npm importer. After leaving the importer running for a quite
> some hours (and making it more robust in the face of inconsistent npm
> information), it turns out that jQuery has a direct or indirect
> dependcy on about everything. We are talking pretty much all of the
> build systems, all of the testing frameworks and all of the test
> runners. Literally thousands of packages, and multiple (conflicting)
> versions of most.

I’m really impressed that your importer can already grovel this much!
In itself, that’s already a significant achievement, despite the
frustration of not getting “guix package -i jquery” right away.

Do you have figures on the number of vertices and edges on this graph?
Could it be that the recursive importer keeps revisiting the same nodes
over and over again?  :-)

I would suggest publishing the code somewhere so others can try to
import their favorite JS library and give feedback.

> This makes it IMHO a worthwhile goal bootstrap to a working test
> framework, with of course at first tests disabled for the dependencies
> of this test framework.  Test frameworks all have an (indirect)
> dependency on the Coffeescript compiler, of which the first version
> was written in Ruby. Using this initial (alpha) compiler, and the
> awesome git-bisect command, I was able to subsequently compile and use
> the more modern (but still old) Coffeescript-in-coffeescript
> compilers.
>
> I am currently hovering between version 0.6 and 0.7, which can
> properly recompile itself and slightly more contemporary
> version. Getting to version 1.6 from June 2013 should be doable using
> this exact same approach.  This will allow us to package a 2014
> version of the Mocha testing framework.

Impressive.

> For the people more knowledgeable in these matters, how would you deal
> with deprecated functionality in languages such as python, ruby etc?
> Because npm packages are so interdependent, I simply need to start
> somewhere, by packaging things back when they did not have as many
> dependencies. Currently, I have a file containing implementations of
> old Node (pre 1.0) functionality on Node 6.0.  I was thinking of
> releasing this 'hack' as an npm package and then package it in Guix.
>
> The alternative would be to package each version of Node that was used
> to build these ancient packages. For bootstrapping Coffeescript, this
> already forces us to have 3~4 versions of Node, although it is
> conceptually a lot cleaner.
>
> So my current view of our options: * Backport ancient node features to
> a contemporary node version * Package a significant variety of node
> versions Please let me know if anyone has some thoughts, critiques or
> silver bullets for this problem.

People have looked at bootstrapping compilers using their historical
ancestor, and it often looked hard first to find what each
implementation’s ancestor was, and then to actually chain them (I
remember Ricardo going back to an old Haskellish implementation in
Scheme at one point.)

Of the two options you list, packaging several Node versions sounds like
the simplest one.  There may be other stumbling blocks though, so be
prepared to stop the packaging recursion before you get mad.  ;-)  In
practice, we’ve never managed to get this far for the other compilers we
have.

Thanks for the status update!

Ludo’.

Re: Help with Perl security update

[Tomáš Čech]

On Mon, Jul 25, 2016 at 04:00:09PM -0400, Leo Famulari wrote:

I'm trying to patch our Perl package against CVE-2016-1238 and
CVE-2016-6185:



This patch uses a graft to apply new patches which are composed of
commits from the 'maint-5.22' branch of
.

Unfortunately, some of the changes related to CVE-2016-1238 don't apply
to our Perl source code. There are several '.rej' files that look like
this:

--- dist/PathTools/lib/File/Spec.pm
+++ dist/PathTools/lib/File/Spec.pm
@@ -3,7 +3,7 @@ package File::Spec;
use strict;
use vars qw(@ISA $VERSION);

-$VERSION = '3.56_01';
+$VERSION = '3.56_02';
$VERSION =~ tr/_//;

my %module = (MacOS   => 'Mac',

Any advice?


This looks like we're missing some patches. My guess is that this is
consequence of the fact that upstream is on 5.22.2 already and we're
on 5.22.1. I'm not sure what value to choose here as the result won't
be neither 3.56_01 nor 3.56_02. Maybe add extra suffix?

Or we can just skip bfe2dd1e9c3296bebf3ab9adc2ca48d3eb8d105d and let
the version same. Someone with deeper perl experience should decide.

I just verified that source code in 5.22.2 has the version strings
patch expects (I haven't checked them all).

S_W


signature.asc
Description: Digital signature

Re: [PATCH} Add RAID devices.

[Andreas Enge]

Hello!

On Sat, Jul 23, 2016 at 10:43:58PM -0700, Chris Marusich wrote:
> Cool!  Is it possible to use them in combination?  Using the example
> From the documentation, would it possible to use LUKS to create an
> encrypted /dev/mapper/home which uses /dev/md0 instead of /dev/sda3?

unfortunately not. This is an area where some work should be invested.
It would require to do things properly in order also. LVM support also
comes to mind. I think these devices can be staged in an arbitrarily
complex way, no? Encrypting a RAID device, or creating a RAID device
from encrypted partitions, for instance (of which the former sounds more
reasonable to me).

> I understand that in Linux, the device file names (e.g., /dev/sda3) can
> sometimes change unexpectedly.  If they change later on, will anything
> bad happen?

Yes, the RAID could not be assembled, and then the machine could not boot
up. But I have never experienced this kind of problem for hard disks.

> Does the code in this gexp get invoked every time the system starts up?
> Why is a loop better here than an error?

Yes. An error is too harsh: When I tried things out, my RAID assembling
was (tried to be) carried out before the hard disks were visible, so this
failed. Waiting a little solved the problem.

Andreas

Re: [PATCH 0/5] Improve the pypi updater.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> On 07/22/2016 11:22 PM, Ludovic Courtès wrote:
>> Neat!  So the test dependencies go to ‘inputs’ instead of
>> ‘propagated-inputs’, right?  That can definitely save time and avoid
>> errors.
>> 
>
> Indeed, the runtime dependencies are propagated inputs, and the test
> dependencies are native inputs. This is what we currently do when
> writing packages "by hand".

OK.

>> Is there an example package that illustrates this?
>
> Anything from OpenStack :-D

Like ‘guix import pypi hacking’ or other packages found in
openstack.scm, right?

Thanks,
Ludo’.

Re: [PATCH 4/5] import: pypi: Compute test requirements when reading requirements files.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> On 07/22/2016 11:30 PM, Ludovic Courtès wrote:
>> This seems to suggest that this could be factorized somehow.  Maybe
>> unpack once and read the two files at once?
>
> The problem is that both files might not be there, and unzip will return
> a non-zero exit code if any of them is missing, so it seems easier to
> just run unzip twice. WDYT?

OK, I see.  Then what about adding a procedure like:

  (define (file-from-zip-archive archive file)
"Return the contents of FILE from ARCHIVE as a string, or #f if FILE
  could not be found in ARCHIVE or extraction failed."
;; … invoke unzip in temporary dir, check return code, then:
(call-with-input-file (string-append tempdir "/" file)
  get-string-all))

That would move the bits about exit codes and all that out of the main
logic.

WDYT?

Thanks,
Ludo’.

Re: [PATCH 2/5] import: pypi: Remove setuptools from the inputs.

[Ludovic Courtès]

Cyril Roelandt  skribis:

> On 07/22/2016 11:43 PM, Leo Famulari wrote:
>> In my experience, it is more often required for Python 2.x, but
>> sometimes it is required by Python 3.x packages, and sometimes not for
>> Python 2.x packages.
>> 
>> I'd be happy to get a more systematic explanation, or to be shown wrong.
>> A simple rule would be great :)
>> 
>
> Yes, we usually do not need to include python-setuptools in the native
> inputs of our Python 3 packages, we just add it to the Python 2 version.

OK, thanks for explaining.  This patch looks good!

Ludo’.

Re: [PATCH} Add RAID devices.

[Ludovic Courtès]

Hello,

Chris Marusich  skribis:

> Andreas Enge  writes:

[...]

>> +  #~(let ((every (@ (srfi srfi-1) every)))
>
> Can't you just use "every" on its own?  It looks like you've imported
> the srfi-1 module earlier on.

I’m the one who suggested it as a “temporary hack”, as we call such
things.  ;-)

The story is that this expression here gets stages in non-top-level
position, where it cannot directly do ‘use-modules’, hence this hack.

This should be fixed eventually, possibly in gexp themselves.

>> +(unless (every file-exists? '#$source)
>> +  (format #t "waiting a bit...~%")
>> +  (sleep 1)
>> +  (loop)))
>
> Does the code in this gexp get invoked every time the system starts up?
> Why is a loop better here than an error?  What if the source device
> files never show up?

Right, another super-temporary hack.  The right thing would be to do
like ‘canonicalize-device-spec’ in (gnu build file-systems) does, which
is to error out after a few iterations, with the effect of spawning an
emergency REPL.

The mechanism to wait for devices should be factorized.

> Also, will that string be properly localized?

No it won’t, indeed.  Currently message catalogs and locales are
unavailable in the initrd, and it would probably make the initrd pretty
big to add them, so I’d be tempted to ignore i18n for early boot
messages that hopefully few people will notice.

Thanks,
Ludo’.

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

[Andreas Enge]

On Mon, Jul 25, 2016 at 12:02:11PM +0200, Cyril Roelandt wrote:
> This could probably be useful:
> https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

Indeed, thanks a lot!

Andreas

Re: Broken Calibre package

[Andreas Enge]

On Mon, Jul 25, 2016 at 10:15:08PM +0200, Roel Janssen wrote:
> Thanks for the recent upgrade to version 2.62.0 of Calibre.  I encounter
> the following problem after completing the setup dialog:
> Are we missing a qtwebkit package?

Yes. It is not the calibre upgrade that poses problems, but the switch
to the modular qt. This was apparently done without testing the package -
I noticed a similar problem when trying to use qtbase instead of qt in
bitcoin-core: The package compiles, but does not work; probably it tries
to dlopen a library that does not exist.

As a first fix, we should revert and replace qtbase by qt in the package.
I will give it a try and push if this works.

Then it would be good to add a qtwebkit package. Are there any takers?

Andreas

Separate Mailing Lists for Patches vs General Dev Discussion?

[Florian Paul Schmidt]

Hi,

I'm following the Guix-Project, even if not contributing much because of 
time constraints. The one, very simple to implement, thing that would 
make following the project more easy IMHO would be a separate list for 
patches. Or maybe the other way around: A separate list for more general 
discussion :)


What do you think?

Regards,
Flo

Broken Calibre package

[Roel Janssen]

Dear Guix,

Thanks for the recent upgrade to version 2.62.0 of Calibre.  I encounter
the following problem after completing the setup dialog:

Traceback (most recent call last):
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/bin/.calibre-real", 
line 20, in 
sys.exit(calibre())
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui_launch.py",
 line 63, in calibre
main(args)
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/main.py",
 line 525, in main
gui_debug=gui_debug)
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/main.py",
 line 371, in run_gui
from calibre.gui2.ui import Main
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/ui.py",
 line 42, in 
from calibre.gui2.init import LibraryViewMixin, LayoutMixin
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/init.py",
 line 19, in 
from calibre.gui2.library.views import BooksView, DeviceBooksView
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/library/views.py",
 line 19, in 
from calibre.gui2.library.delegates import (RatingDelegate, PubDateDelegate,
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/library/delegates.py",
 line 23, in 
from calibre.gui2.dialogs.comments_dialog import CommentsDialog
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/dialogs/comments_dialog.py",
 line 9, in 
from calibre.gui2.dialogs.comments_dialog_ui import Ui_CommentsDialog
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/dialogs/comments_dialog_ui.py",
 line 41, in 
from calibre.gui2.comments_editor import Editor
  File 
"/gnu/store/zyxad0fziqvyf28x0ibwgp9xgqdzizn0-calibre-2.62.0/lib/calibre/calibre/gui2/comments_editor.py",
 line 18, in 
from PyQt5.QtWebKitWidgets import QWebView, QWebPage
ImportError: No module named QtWebKitWidgets


Are we missing a qtwebkit package?

Kind regards,
Roel Janssen

Re: core-updates, next release, and all that

[Andreas Enge]

Hello Leo,

replying personally, since I am getting embarrassed...

On Mon, Jul 25, 2016 at 08:40:56PM +0200, Andreas Enge wrote:
> I had the impression that the new wxwidgets url did not appear, since the
> build still fails on hydra. Now I see that the url is there, and the failure
> on hydra is probably just cached because the hash did not change. I will
> download it manually there and restart the failing builds.

I was again mistaken, the URL is not there. I think I did a "git pull" in
core-updates, then a "git merge master", which was probably not up to date.
Now I redid a "git merge origin/master", and things look much better :-)

I will push and evaluate again.

Andreas

Re: Go build system

[Leo Famulari]

On Mon, Jul 25, 2016 at 12:25:40AM +0200, Ludovic Courtès wrote:
> It outlines the command sequence that needs to be run.  I’d suggest
> starting from that in ‘go-build-system’.  Let’s make it work for this
> package, and then we can adjust if some of the assumptions happened to
> be specific to Syncthing.

Okay, I'll try it out.

We will have to decide what to do about bundled dependencies. Bundling
the source code of dependencies appears to be standard practice in the
world of Go. The compiler began supporting this directly in the 1.5
series:
https://github.com/golang/go/wiki/PackageManagementTools#go15vendorexperiment

This is the manifest of Syncthing's dependencies, which are bundled in
the same directory:
https://github.com/syncthing/syncthing/blob/master/vendor/manifest

If that manifest is a standard thing, we could make a go-importer that
used it to create new packages.

I don't fully understand Debian's packaging, but it seems that they only
use external packages to provide 2 of 39 dependencies, bootstrap and
font-awesome:
https://anonscm.debian.org/git/pkg-go/packages/syncthing.git/tree/debian/rules#n42

Re: core-updates, next release, and all that

[Andreas Enge]

On Mon, Jul 25, 2016 at 12:30:03PM -0400, Leo Famulari wrote:
> What went wrong?

I had the impression that the new wxwidgets url did not appear, since the
build still fails on hydra. Now I see that the url is there, and the failure
on hydra is probably just cached because the hash did not change. I will
download it manually there and restart the failing builds.

Andreas

Re: core-updates, next release, and all that

[Leo Famulari]

On Mon, Jul 25, 2016 at 09:51:49AM +0200, Andreas Enge wrote:
> On Sun, Jul 24, 2016 at 06:48:13PM +0200, Andreas Enge wrote:
> > It worked out and did not take that long after all. I pushed the fix, merged
> > master into core-updates
> 
> This does not seem to have worked out. I will let someone more git-savvy
> do it next time, maybe after someone more C-savvy has been able to solve
> the lpsolve build failure... Sorry,

What went wrong?

Re: [PATCH] gnu: gmime: Remove gpg to gpg2 patch.

[Leo Famulari]

On Mon, Jul 25, 2016 at 11:47:51AM +, ng0 wrote:
>  (with-fluids ((%default-port-encoding #f))
>(substitute* (find-files "tests" "\\.c$")
>  (("(system *\\(\")(/[^ ]*)" all pre prog-path)
>   (let* ((base (basename prog-path))
> -(prog (which (if (string=? base "gpg") "gpg2" 
> base
> +(prog (which base)))
> (string-append pre
>(or prog (error "not found: " 
> base

I can confirm this fixes the build failure. But, I don't fully
understand the code that was changed. Can somebody double-check it?

Re: [PATCH] gnu: Add perceptualdiff.

[Leo Famulari]

On Mon, Jul 25, 2016 at 12:49:56PM +0200, Vincent Legoll wrote:
> Hello,
> 
> > Maybe you're right. Unlike the gnu-build-sytem, the cmake-build-system
> > seems to create a 'build/' directory adjacent to the unpacked source
> > code.
> 
> Yes, I think in cmake's land, the recommended way is to build in a directory
> outside of the source code , generally at the same level than the source tree
> which can be made read-only...

Thanks for the clarification, Vincent.

I think the package is ready :)

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

[Leo Famulari]

On Mon, Jul 25, 2016 at 10:59:07AM +0200, Ludovic Courtès wrote:
> All the Guix repositories on Savannah now reject unsigned Git commits:
> 
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#112
> 
> Please report any problems.

Since the repo disables forced-pushing, we instead delete branches and
recreate them to get the same effect. We do this for WIP branches, and
perhaps some others?

If those branches contain unsigned commits (from before we decided to
sign everything), we won't be able to push them to Savannah. I ran into
this problem with my pre-push hook that prevents me from pushing
unsigned commits.

Just a heads up. I don't know whether or not it will be a problem in
practice.

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

[Leo Famulari]

On Mon, Jul 25, 2016 at 12:02:11PM +0200, Cyril Roelandt wrote:
> On 07/25/2016 10:59 AM, Ludovic Courtès wrote:
> > Hello!
> > 
> > All the Guix repositories on Savannah now reject unsigned Git commits:
> > 
> >   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#112
> > 
> 
> This could probably be useful:
> https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
> 
> 
> What will we do about patches sent by casual contributors, that will
> probably be unsigned? Should the committer sign them?

Yes. Signing a patch that is emailed is a separate action from signing a
Git commit (`git commit --gpg-sign`). Submitters are invited to sign
their emails, but those signatures will not appear in the Git repo.

Re: [PATCH] doc: Explain when guix edit is read-only.

[Alex Kost]

Ludovic Courtès (2016-07-24 20:06 +0300) wrote:

> Alex Kost  skribis:
>
>> myglc2 (2016-07-22 01:35 +0300) wrote:
>>
>>> * doc/guix.texi (Invoking guix edit): Explain when you can and can't
>>>   edit the recipe
>>> ---
>>>  doc/guix.texi | 10 --
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>>
>>> diff --git a/doc/guix.texi b/doc/guix.texi
>>> index e7b233d..914d24d 100644
>>> --- a/doc/guix.texi
>>> +++ b/doc/guix.texi
>>> @@ -4485,7 +4485,7 @@ You can freely access a huge library of build logs!
>>>  
>>>  @cindex package definition, editing
>>>  So many packages, so many source files!  The @command{guix edit} command
>>> -facilitates the life of packagers by pointing their editor at the source
>>> +facilitates the life of users and packagers by pointing their editor at 
>>> the source
>>>  file containing the definition of the specified packages.  For instance:
>>>  
>>>  @example
>>> @@ -4494,9 +4494,15 @@ guix edit gcc@@4.9 vim
>>>  
>>>  @noindent
>>>  launches the program specified in the @code{VISUAL} or in the
>>> -@code{EDITOR} environment variable to edit the recipe of GCC@tie{}4.9.3
>>> +@code{EDITOR} environment variable to view the recipe of GCC@tie{}4.9.3
>>>  and that of Vim.
>>>  
>>> +If you are using a Guix Git checkout (@pxref{Building from Git}), or
>>> +have created your own packages on ‘GUIX_PACKAGE_PATH’ (*note Defining
>>> +Packages::), you will be able to edit the package recipes. Otherwise,
>
> Looks Info syntax here.  Should be “@code{GUIX_PACKAGE_PATH}
> (@pxref{Package Modules})”?

I also think so, fixed.

>>> +you will be able to examine the read-only recipes for packages currently
>>> +in the store.
>>> +
>>>  If you are using Emacs, note that the Emacs user interface provides the
>>>  @kbd{M-x guix-edit} command and a similar functionality in the ``package
>>>  info'' and ``package list'' buffers created by the @kbd{M-x
>>
>> This looks reasonable to me, so if there are no comments/objections, I'm
>> going to commit it.
>
> Sounds good to me.

Committed as 424a323¹, thanks myglc2!

¹ 
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=424a323e92d92284efcd30cf548d1f41c556d592

-- 
Alex

Re: [PATCH 2/3] profiles: Add fonts-dir-file hook.

[Alex Kost]

Ludovic Courtès (2016-07-24 20:09 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2016-07-05 17:31 +0300) wrote:
>>
>>> Alex Kost  skribis:
>>>
 Ludovic Courtès (2016-07-02 17:34 +0300) wrote:

> Alex Kost  skribis:
>
>> * guix/profiles.scm (fonts-dir-file): New procedure.
>> (%default-profile-hooks): Add it.
>
> [...]
>
> A potential problem with this hook is that it pulls mkfontscale and
> mkfontdir regardless of whether they are needed; I can’t really think of
> a way to avoid it though.

 Yes, I also don't like it.  We have the same problem with
 'info-file-dir' hook: it always pulls texinfo and gzip, but not all
 profiles include info manuals.
>>>
>>> Yes, but I thought it was OK to make these mandatory dependencies.
>>>
>>> The closure of mkfontscale + mkfontdir is small; it’s slightly annoying
>>> for someone building from source because you have to build a few X11
>>> libraries, but it’s not that much either (‘guix graph’ shows just a few
>>> boxes.)
>>>
>>> So this hook is probably fine, after all.
>>>
>>> What do people think?
>>
>> Since there were no objections in 2 weeks, I think it's OK to commit
>> this 'fonts-dir-file' hook, right?
>
> I think so!

Committed, thanks!

-- 
Alex

Re: [PATCH] gnu: emacs: Install site-start.el in non-versioned directory.

[Alex Kost]

Alex Kost (2016-07-24 09:16 +0300) wrote:

> Ricardo Wurmus (2016-07-24 08:06 +0300) wrote:
>
>> Alex Kost  writes:
>>
>>> Ricardo tested Emacs 25 with this package definition:
>>>  and noticed that it doesn't find
>>> Emacs packages in ~/.guix-profile.
>>>
>>> This happens because "site-start.el" in the inherited package is placed
>>> "/share/emacs/24.5/site-lisp" directory (the version part is wrong).  To
>>> avod this, we can put "site-start.el" into a non-versioned site-lisp
>>> directory.  The patch is attached.
>>
>> Thank you, Alex.
>>
>> As far as I understand, the generated “site-start.el” file is
>> version-agnostic, so I think this is the right approach.
>
> Yes, the code to find guix packages doesn't care about Emacs version.
>
>> (I haven’t yet found the time to actually test your patch with my Emacs
>> 25 package.)
>
> I tested it :-)  So I'm going to commit it soon.

Committed as c48899e.

-- 
Alex

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

[Tobias Geerinckx-Rice]

Cyril,

On 2016-07-25 12:02, Cyril Roelandt wrote:

What will we do about patches sent by casual contributors, that will
probably be unsigned? Should the committer sign them?


Yes. (Most already do this, though.)

Kind regards,

T G-R
--
Sent from a web browser. Excuse my brevity.

Re: [PATCH] gnu: sbcl: Update to 1.3.7.

[宋文武]

Andy Patterson  writes:

> This patch allows sbcl to build using the newer texlive.

Pushed, thanks!

[PATCH] gnu: gmime: Remove gpg to gpg2 patch.

[ng0]

gmime building broke with gpg@2.1 --build-gpg2-as-gpg or what it
was. This fixes it.
Please also fix the typo in the commit message ("peviously").

From 3bc7d2c8d94da0a81ecc16b2e12791f9ed466c95 Mon Sep 17 00:00:00 2001
From: ng0 
Date: Mon, 25 Jul 2016 11:38:37 +
Subject: [PATCH] gnu: gmime: Remove gpg to gpg2 patch.

* gnu/packages/mail.scm (gmime)[arguments]: Remove the patch which peviously
changed gpg to gpg2 in 'patch-paths-in-tests phase.
---
 gnu/packages/mail.scm | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/mail.scm b/gnu/packages/mail.scm
index 9214b73..f7a7623 100644
--- a/gnu/packages/mail.scm
+++ b/gnu/packages/mail.scm
@@ -15,6 +15,7 @@
 ;;; Copyright © 2016 Lukas Gradl 
 ;;; Copyright © 2016 Alex Kost 
 ;;; Copyright © 2016 Troy Sankey 
+;;; Copyright © 2016 ng0 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -240,14 +241,14 @@ operating systems.")
   'unpack 'patch-paths-in-tests
   (lambda _
 ;; The test programs run several programs using 'system' with
-;; hard-coded paths.  Here we patch them all.  We also change "gpg"
-;; to "gpg2".  We use ISO-8859-1 here because test-iconv.c contains
+;; hard-coded paths.  Here we patch them all.
+;; We use ISO-8859-1 here because test-iconv.c contains
 ;; raw byte sequences in several different encodings.
 (with-fluids ((%default-port-encoding #f))
   (substitute* (find-files "tests" "\\.c$")
 (("(system *\\(\")(/[^ ]*)" all pre prog-path)
  (let* ((base (basename prog-path))
-(prog (which (if (string=? base "gpg") "gpg2" base
+(prog (which base)))
(string-append pre
   (or prog (error "not found: " 
base
 (home-page "http://spruce.sourceforge.net/gmime/;)
-- 
2.9.1


-- 
♥Ⓐ  ng0
Current Keys: https://we.make.ritual.n0.is/ng0.txt
For non-prism friendly talk find me on http://www.psyced.org


signature.asc
Description: PGP signature

Re: [GSoC update] Npm & guix

[Jan Nieuwenhuizen]

Jelle Licht writes:

> On Ludo's advice, I snarfed Ricardo's recursive importer and bolted it on my 
> npm
> importer. After leaving the importer running for a quite some hours (and 
> making
> it more robust in the face of inconsistent npm information), it turns out that
> jQuery has a direct or indirect dependcy on about everything. We are talking
> pretty much all of the build systems, all of the testing frameworks and all of
> the test runners. Literally thousands of packages, and multiple (conflicting)
> versions of most.

Have you asked the jQuery developers for their view on the number of
dependencies you found and some of the conflicts you see?

Thanks for your great effort!
Greetings, Jan

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: [PATCH] gnu: Add perceptualdiff.

[Vincent Legoll]

Hello,

> Maybe you're right. Unlike the gnu-build-sytem, the cmake-build-system
> seems to create a 'build/' directory adjacent to the unpacked source
> code.

Yes, I think in cmake's land, the recommended way is to build in a directory
outside of the source code , generally at the same level than the source tree
which can be made read-only...

-- 
Vincent Legoll

Re: Heads-up: git.sv.gnu.org now rejects unsigned commits

[Cyril Roelandt]

On 07/25/2016 10:59 AM, Ludovic Courtès wrote:
> Hello!
> 
> All the Guix repositories on Savannah now reject unsigned Git commits:
> 
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#112
> 

This could probably be useful:
https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work


What will we do about patches sent by casual contributors, that will
probably be unsigned? Should the committer sign them?


Cyril.



signature.asc
Description: OpenPGP digital signature

Re: Gs

[Ludovic Courtès]

¡Hola!

Andreas Enge  skribis:

> On Sat, Jul 23, 2016 at 01:03:07PM +0200, Ludovic Courtès wrote:
>> For the current solution (avoiding a full rebuild), see commit
>> 61dc82d9b90d0545739c30bfc33003bd062071f0.  LilyPond could hard-code the
>> file name of ‘gsc’.
>
> This looks like too much work to implement for each package separately.
> And as a permanent solution, I do not like it.
>
>> Alternately, we could provide a wrapper containing a ‘gs’ symlink.
>
> This would be one option. Or we could add another package, corresponding
> to the previous definition, that we would use only as an input to the
> packages in core-updates that do not build right now. This solution could
> be implemented using copy-paste and not take much time. I would then also
> remove the ad-hoc lilypond patching.

I went ahead and pushed these two commits, which seem to address the
issue:

  d8eb912 * gnu: Use 'ghostscript-gs' in packages that need the 'gs' command.
  71eba3e * gnu: Add 'ghostscript-gs' and 'ghostscript-gs-with-x'.

> Then after core-updates is merged, we could add the gs->gsc link to our
> ghostscript packages.

Yes, we should do that afterwards.

Apologies for the breakage!

Ludo'.

Re: A registry for distributed sources and binaries

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> Currently, GUIX_PACKAGE_PATH depends on some manual work to be done
> first.  Finding a third-party repository, downloading it, updating it
> separately from Guix itself (it won’t get updated via “guix pull”),
> setting the variable.
>
> When binary substitutes are involved some more steps are required: find
> and download the public key of the distributor (who might be running
> hydra or something like “guix publish”) and authorise it.
>
> Taken together it may seem a little too cumbersome compared to what
> other package managers do.  To enable a third-party repository for
> Ubuntu, for example, I only need to run one command.  When downloading
> packages I may also need to verify and accept a GPG key.

That’s a two-step process (or one-step if there are no binaries).

Honestly, I don’t find it intimidating (definitely not a showstopper),
but I agree it’s even better if it can be simplified.

> Could it be enough if Guix offered a simpler way to fetch package
> definitions and (optionally) binary substitutes from a third party who
> maintains both the package definitions and (optionally) distributes
> pre-built binary substitutes?
>
> Here are some concrete proposals:
>
> * Add a “guix config” command, which allows users to modify the
>   behaviour of their instance of Guix.
>
> * Support adding repositories via “guix config”.  A “repository” is a
>   remote set of Guile modules and (optionally) an public endpoint of
>   “guix publish” through which substitutes of only those packages that
>   are defined in the repository’s modules can be downloaded.
>
> * The first time a repository is accessed, the specified modules are
>   cloned and stored in a per-user state directory
>   (“~/.cache/guix/” maybe?).  Guix is automatically configured
>   to use the modules from “~/.cache/guix/” in addition to what
>   is on GUIX_PACKAGE_PATH.  Additionally, the distribution public key
>   for binary substitutes is fetched from a well-known location (if
>   applicable) and users are asked to confirm.
>
> * When a user runs “guix pull” all enabled repositories are also
>   updated.  Otherwise the cached copy from last access is used.
>
> * Update “guix --version” to also return the version of each configured
>   repository.
>
> * Add a command line switch “--vanilla” (or similar) to disable any
>   custom configuration and any configured repositories.

I like the idea!  (With the caveat that, again, external repos can break
anytime.)

Partly related to that:
.

Ludo’.

Replying to bug reports

[Ludovic Courtès]

Hi,

Jookia <166...@gmail.com> skribis:

> Even worse, if I want to reply to an issue on a mailing list that I'm not
> subscribed to, it's difficult.

To reply to a bug report listed at , email
n...@debbugs.gnu.org, where N is the bug number.

For mailing lists in general, another option is to use Gmane’s NNTP
interface:

  http://dir.gmane.org/gmane.comp.gnu.guix.devel

HTH,
Ludo’.

Heads-up: git.sv.gnu.org now rejects unsigned commits

[Ludovic Courtès]

Hello!

All the Guix repositories on Savannah now reject unsigned Git commits:

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22883#112

Please report any problems.

In the future the hook will also check that commits are signed by
authorized keys, but the details need to be laid out.

Ludo’.


signature.asc
Description: PGP signature

Re: [PATCH 3/3] gnu: ecl: Wrap with PATH, CPATH, LIBRARY_PATH and LD_LIBRARY_PATH

[Ludovic Courtès]

Andy Patterson  skribis:

> * gnu/packages/lisp.scm (ecl)[arguments]: Wrap with PATH, CPATH,
>   LIBRARY_PATH and LD_LIBRARY_PATH

[...]

> +  ("libffi" ,libffi)
> +  ("linux-headers" ,linux-libre-headers)
> +  ("gcc" ,gcc)
> +  ("binutils" ,binutils)
> +  ("ld-wrapper" ,(make-ld-wrapper "ld-wrapper" #:binutils 
> binutils))
> +  ("libc" ,glibc)))

I removed these inputs because they’re implicit and don’t need to be
added.

> +(binaries '("gcc" "binutils" "ld-wrapper"))

I also moved ld-wrapper before binutils so that ld-wrappers ‘ld’ command
is picked up.

Pushed, thank you!

Ludo’.

Re: Go build system

[Andy Wingo]

On Mon 25 Jul 2016 00:25, l...@gnu.org (Ludovic Courtès) writes:

>> Should Go packages refer to the compiler? This Syncthing package does
>> retain a reference.
>
> I suppose it keeps a reference to run-time support libraries provided by
> the ‘go’ package?

I believe that unless you specifically compile shared objects, that the
runtime should be statically linked in.  There is still a dynamic link
to libc and some things like that.  But, I could be wrong :)  It could
also be that it embeds the path to the build tools somehow.



Andy

Re: [GSoC update] Npm & guix

[Andy Wingo]

On Sun 24 Jul 2016 03:06, Jelle Licht  writes:

> On Ludo's advice, I snarfed Ricardo's recursive importer and bolted it
> on my npm importer. After leaving the importer running for a quite
> some hours (and making it more robust in the face of inconsistent npm
> information), it turns out that jQuery has a direct or indirect
> dependcy on about everything. We are talking pretty much all of the
> build systems, all of the testing frameworks and all of the test
> runners. Literally thousands of packages, and multiple (conflicting)
> versions of most.

Wow, how frustrating!

> This makes it IMHO a worthwhile goal bootstrap to a working test
> framework, with of course at first tests disabled for the dependencies
> of this test framework.  Test frameworks all have an (indirect)
> dependency on the Coffeescript compiler, of which the first version
> was written in Ruby. Using this initial (alpha) compiler, and the
> awesome git-bisect command, I was able to subsequently compile and use
> the more modern (but still old) Coffeescript-in-coffeescript
> compilers.

For what it's worth, to me as a bystander this looks like great progress
:)

Andy

Re: [PATCH 2/3] gnu: ecl: Enable tests.

[Ludovic Courtès]

Andy Patterson  skribis:

> * gnu/packages/lisp.scm (ecl): Enable tests.

That’s good news.  Applied, thanks!

Ludo’.

Re: A registry for distributed sources and binaries

[Andy Wingo]

On Sun 24 Jul 2016 15:58, Andreas Enge  writes:

> A problem, as mentioned in another reply, is the lack of people doing code
> review, which is not a very rewarding task. That can be changed by everyone
> of us :-)

Could we just focus on this problem perhaps?

One of the issues is that there's no clear reviewer -- anyone just
pitches in.  We could try to have a culture of asking for particular
reviewers, perhaps via the IRC channel.  If you build up a relationship
with a particular reviewer then they can be your default reviewer, more
or less.  You put them in the Cc of your mails to the list.  This
approach has worked well in some other projects I have been involved in.

Another is to get Guix to suggest a reviewer.  For example if you modify
a package, Guix could look at the git history of that file in those
lines and see who changed it recently, and suggest a person to Cc.

I think Pjotr's example of Elixir was perhaps a bad one.  Languages are
tricky because they are not leaf nodes in the tree.   It's natural for a
Guix maintainer to have an opinion on how a language should be
integrated into Guix, even if they are not an expert.

A fully distributed system sounds nice but it has costs too.  In my mind
for a project of Guix's target size the best situation would be having
around 100 committers or so who have internalized the coding style and
patterns of Guix so that they can work more or less directly on the
parts they feel comfortable with, posting patches to the list as
necessary for feedback.  An incoming patch would be assigned to one of
those people based on automatic tooling.  In that way Guix can scale to
the next step while remaining a consistent, hackable project.

Andy

Re: [PATCH 1/3] gnu: ecl: Update to 16.1.2.

[Ludovic Courtès]

Andy Patterson  skribis:

> * gnu/packages/lisp.scm (ecl): Update to 16.1.2.

Applied, thanks!

Re: [PATCH v2] gnu: Add lrzip.

[Ludovic Courtès]

Leo Famulari  skribis:

> On Sun, Jul 24, 2016 at 11:36:24PM +0200, Ludovic Courtès wrote:
>> No, I’ll try and adjust what’s available at:
>> .
>> (Suggestions welcome, though!)
>
> I will also review this script.

I submitted something simpler, because we don’t want to have a list of
allowed keys set in stone:

  https://savannah.gnu.org/support/?109104

Eventually I think we’ll do proper checks against a list of authorized
keys stored in the repo itself.  Needs more thought!

Ludo’.

Re: help with setenv of perl-curses

[Vincent Legoll]

Hello,

> +(build-system perl-build-system)
> +(inputs `(("ncurses" ,ncurses)))
> +(arguments
> + `(#:phases
> +   (modify-phases %standard-phases
> + (add-before
> + 'configure 'set-curses-ldflags
> +   (lambda* (#:key inputs #:allow-other-keys)
> + (setenv "CURSES_LIBTYPE" "ncurses")
> + (setenv "CURSES_CFLAGS"
> + (string-append "-I" (assoc-ref inputs "ncurses")
> +"/include"))
> + (setenv "CURSES_LDFLAGS"
> + (string-append "-L" (assoc-ref inputs "ncurses")

Is this specific to perl-ncurses or would other ncurses-using packages also need
these definitions ?

-- 
Vincent Legoll

Re: Cook source disappeared

[Ludovic Courtès]

Leo Famulari  skribis:

> This project is trying to address the problem:
> https://www.softwareheritage.org/
>
> I wonder if Guix can use that archive as a last resort?

Yes, when it’s available (currently there’s no HTTP API that we can
use).  I discussed our use case with the developers:

  https://sympa.inria.fr/sympa/arc/swh-devel/2016-07/msg00010.html

Ludo’.

Re: core-updates, next release, and all that

[Ludovic Courtès]

Andreas Enge  skribis:

> On Sun, Jul 24, 2016 at 06:04:39PM +0200, Andreas Enge wrote:
>> Right now, I am trying to disable parallel builds; so far
>> things look good, I think we are beyond the previous point of failure.
>> But of course this would not be a very pleasant solution, given the build
>> time of the package...
>
> It worked out and did not take that long after all. I pushed the fix, merged
> master into core-updates and started a new evaluation.

Awesome, thanks!

Ludo’.

Re: [PATCH] gnu: Bump version of "hplip" to "3.16.5".

[Danny Milosavljevic]

Please ignore patch. There's already a newer version in the git repo.

Re: [PATCH 4/7] gnu: Add spice-gtk.

[David Craven]

> Likewise if its .pc file “Requires” the .pc file of a dependency.

Maybe we want to patch pkg-config to not check for propagated
dependencies?

> If an installed .h file of spice-gtk #includes a .h file of a
> dependency, that dependency should be a propagated input.
> Likewise if its .pc file “Requires” the .pc file of a dependency.

Then I think the inputs I propagated in my first submission of the
patches follow this criteria.

[PATCH] gnu: Bump version of "hplip" to "3.16.5".

[Danny Milosavljevic]

* gnu/packages/cups.scm (hplip): Version bump to 3.16.5.

---
 gnu/packages/cups.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/cups.scm b/gnu/packages/cups.scm
index 8437170..f1df906 100644
--- a/gnu/packages/cups.scm
+++ b/gnu/packages/cups.scm
@@ -306,14 +306,14 @@ device-specific programs to convert and print many types 
of files.")
 (define-public hplip
   (package
 (name "hplip")
-(version "3.16.3")
+(version "3.16.5")
 (source (origin
   (method url-fetch)
-  (uri (string-append "mirror://sourceforge/hplip/"
+  (uri (string-append "http://prdownloads.sourceforge.net/hplip/;
   "hplip-" version ".tar.gz"))
   (sha256
(base32
-"1501qdnkjp1ybgagy5188fmf6cgmjygjl3543nlbwcp31lj2"
+"1nay65q1zmx2jxiwn66n7mlr73azacz5097gw98kqqf90dh522f6"
 (build-system gnu-build-system)
 (home-page "http://hplipopensource.com/;)
 (synopsis "HP Printer Drivers")

Re: core-updates, next release, and all that

[Andreas Enge]

On Sun, Jul 24, 2016 at 06:48:13PM +0200, Andreas Enge wrote:
> It worked out and did not take that long after all. I pushed the fix, merged
> master into core-updates

This does not seem to have worked out. I will let someone more git-savvy
do it next time, maybe after someone more C-savvy has been able to solve
the lpsolve build failure... Sorry,

Andreas

extending initrd

[Tomáš Čech]

Hi,

I'm playing a bit with initrd and I miss there a way, how to add
additional content to the image (busybox in my case now). Is there
really no way yet how to do that?

In expression->initrd it refers to closure yet I fail to find how is
it found/constructed...

Thanks in advance for pointers.

S_W


signature.asc
Description: Digital signature

Re: Odd behavior with --dry-run and --upgrade

[Andreas Enge]

On Mon, Jul 25, 2016 at 12:18:41AM +0200, Ludovic Courtès wrote:
> > I'm totally agree with this; nowadays I always use --dry-run with
> > --no-grafts option.
> Same here…
> > As a user I expect that --dry-run means no building at all.
> But honestly, I think changing ‘--dry-run’ to do ‘--dry-run --no-grafts’
> would be fine, and probably better than the current situation.

Yes, this is what I would expect. We could also have a "--dry-run --grafts"
option if anybody complains about the missing feature.

Andreas

icecat "mailto" handler does not work - and cannot be reconfigured by user

[Danny Milosavljevic]

> Unless I misunderstood what you mean: this already exists.  On the page
> you linked to above look for “reply via email to”.  It’s followed by a
> button.  When you click on it you get a “mailto”-Link.

Whoops. I should have read the page better.

However, clicking on that button in icecat does not send E-Mail for me. 

Monitoring the network interface I can see that it redirects to a mailto: URL. 
So that's nice.

Checking the application preferences of icecat, it only gives "always ask" 
(note: it doesn't ask) and not an application for "mailto". (in GuixSD)

Creating my own HTML page with a mailto link doesn't work either.

Therefore, I reported a bug to Guix too.

Bug report follows:

"mailto:; links don't work in icecat.

Checking the icecat source code, there are several ways to handle E-Mail. One 
of them is as "external helper app". One of those (not sure whether it's the 
correct one) uses gio's g_app_info_launch_default_for_uri in order to launch 
helper applications.

There is a test 
icecat-38.8.0/uriloader/exthandler/tests/unit/test_handlerService.js that does:

  let isLinux = ("@mozilla.org/gio-service;1" in Components.classes);
  if (isLinux) {
// Check mailto handler from GIO
// If there isn't one, then we have no mailto handler
let gIOSvc = Cc["@mozilla.org/gio-service;1"].
 createInstance(Ci.nsIGIOService);
try {
  gIOSvc.getAppForURIScheme("mailto");
  noMailto = false;
} catch (ex) {
  noMailto = true;
}
  }

And this ./toolkit/system/gnome/nsGIOService.cpp uses 
g_app_info_launch_default_for_uri .

Therefore, I tried it out:

#include 
#include 
#include 

int main() {
GError* error;
g_app_info_launch_default_for_uri("mailto:f...@example.com;, NULL, 
);
// g_app_info_launch_default_for_uri("http://www.google.at/;, NULL, 
);
if (error) {
g_warning("err %s", error->message);
g_error_free(error);
return 1;
} else
return 0;
}

I get:

** (process:12464): WARNING **: err Operation not supported

If I debug it some more I get:

$ strace -f ./g 2>&1 |grep open |grep -v ENOENT

open("/home/dannym/.local/share//mime/mime.cache", O_RDONLY) = 3
open("/home/dannym/.guix-profile/share/mime/mime.cache", O_RDONLY) = 3
open("/run/current-system/profile/share/mime/mime.cache", O_RDONLY) = 3
open("/home/dannym/.guix-profile/share/mime/mime.cache", O_RDONLY) = 3
open("/run/current-system/profile/share/mime/mime.cache", O_RDONLY) = 3
open("/home/dannym/.guix-profile/lib/gio/modules", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/dannym/.guix-profile/lib/gio/modules/giomodule.cache", O_RDONLY) = 4
open("/home/dannym/.guix-profile/lib/gio/modules/libdconfsettings.so", 
O_RDONLY|O_CLOEXEC) = 4
open("/run/current-system/profile/lib/gio/modules", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/run/current-system/profile/lib/gio/modules/giomodule.cache", O_RDONLY) = 
4
open("/gnu/store/6qrijb6cfyvs8svacr0l9a75vcpypr5f-glib-2.48.0/lib/gio/modules", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/gnu/store/4lbgxvsk8xl75hlkjqgrqvmpq74app73-dconf-0.26.0/lib/gio/modules",
 O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/gnu/store/4lbgxvsk8xl75hlkjqgrqvmpq74app73-dconf-0.26.0/lib/gio/modules/giomodule.cache",
 O_RDONLY) = 4
open("/home/dannym/.guix-profile/lib/gio/modules", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/home/dannym/.guix-profile/lib/gio/modules/giomodule.cache", O_RDONLY) = 4
open("/run/current-system/profile/lib/gio/modules", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/run/current-system/profile/lib/gio/modules/giomodule.cache", O_RDONLY) = 
4
open("/gnu/store/m3py3rk71ihlfgvj2kss7054hwfqwkpq-glib-2.48.0/lib/gio/modules", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid 12632] open("/usr/share/locale/locale.alias", O_RDONLY 
[pid 12632] open("/home/dannym/.config/mimeapps.list", O_RDONLY) = 5
[pid 12632] 
open("/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/gconv/gconv-modules",
 O_RDONLY|O_CLOEXEC) = 5
[pid 12632] open("/home/dannym/.local/share/applications", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] open("/home/dannym/.local/share/applications/mimeapps.list", 
O_RDONLY) = 5
[pid 12632] open("/home/dannym/.local/share/applications/mimeinfo.cache", 
O_RDONLY) = 5
[pid 12632] open("/home/dannym/.guix-profile/share/applications", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] open("/run/current-system/profile/share/applications", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] 
open("/run/current-system/profile/share/applications/mimeinfo.cache", O_RDONLY) 
= 5
[pid 12632] open("/home/dannym/.guix-profile/share/applications", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] open("/run/current-system/profile/share/applications", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5
[pid 12632] 

Re: A registry for distributed sources and binaries

[Tomáš Čech]

On Sun, Jul 24, 2016 at 10:35:43PM +0200, Ricardo Wurmus wrote:

What do you think about that?  Does this align with your vision?

What do others think?  Is this something that would benefit the Guix
project and its audience?


I like the idea a lot.

I'm only concerned with security of such thing. When the number of
other package sources will grow, it should be ensured that some
package definition will not touch core/library without user
consent. If they will take packages from random sources (as they are
careful when downloading applications for windows from various sources
or reading licenses), it may easily become security threat to whole
system.

I'd be glad if we can stop using GUIX_PACKAGE_PATH environment
variable (which is a bit clumsy) and have support for multiple source,
with priorities (for cases of collisions) and maybe in future support
for some digital signatures.

\o/

S_W


signature.asc
Description: Digital signature

Re: [PATCH] Add Elixir (was: )

[Pjotr Prins]

On Mon, Jul 25, 2016 at 08:13:33AM +0200, Ricardo Wurmus wrote:
> back to the original patch, which I didn’t look at as the ensuing
> discussion on review process and registry proposals took up more time
> than I anticipated.

:)

> I’m a little uncertain on how to proceed.  I have a couple of things
> here that I’d like to change before commiting.  I’ll add some comments
> below.  Indentation changes won’t be mentioned ;)
> 
> If you are okay with the proposed changes I can apply them on top of
> your patch and resubmit the squashed patch to the ML for a final
> look-over.  Deal?

Sure. I have no ego in this. I am happy if you take over.

> > +   (native-inputs
> > +`(("patch" ,patch)
> > +  ("patch/elixir-disable-failing-tests"
> > +   ,(search-patch "elixir-disable-failing-tests.patch"))
> > +  ("patch/elixir-disable-mix-tests"
> > +   ,(search-patch "elixir-disable-mix-tests.patch"
> 
> This has been mentioned already and I’d like to move these to the
> “source” field after identifying the reason why the build fails
> otherwise.  I see that you’re doing this in order to patch after the
> build phase.  Let’s see if this can be avoided.

I tried and failed. Elixir people do not know either:

  https://github.com/elixir-lang/elixir/issues/5043

I think it is Mix magic. Probably tracking files in some way.

> > +  (add-after 'build 'disable-breaking-elixir-tests
> > +;; when patching tests as part of source the build breaks, so we do
> > +;; it after the build phase
> > +(lambda* (#:key inputs #:allow-other-keys)
> > +  (and
> > +   (zero? (system* "patch" "--force" "-p1" "-i"
> > +   (assoc-ref inputs 
> > "patch/elixir-disable-failing-tests")))
> > +   (zero? (system* "patch" "--force" "-p1" "-i"
> > +   (assoc-ref inputs 
> > "patch/elixir-disable-mix-tests")))
> > +   ;; Tests currently fail in these two files:
> > +   (delete-file "./lib/mix/test/mix/tasks/deps.git_test.exs")
> > +   (delete-file "./lib/mix/test/mix/shell_test.exs"
> 
> “delete-file” has an unspecified return value, so chaining it up in
> “and” isn’t guaranteed to work.  Should this patch-after-build business
> turn out to be unavoidable I suggest just deleting the files first, then
> and-ing the “zero?” expressions.

Cool.

> > +  (replace 'check
> > +   (lambda _
> > + (zero? (system* "make" "test") ;; 3124 tests, 0 
> > failures, 11 skipped
> 
> We can use “#:test-target "test"” instead of replacing the “check” phase.

Yes, I forgot.

> > +  #:make-flags (list (string-append "PREFIX=" %output
> > +   (home-page "http://elixir-lang.org/;)
> > +   (synopsis "The Elixir programming language")
> 
> s/The//
> 
> > +   (description "Elixir is a dynamic, functional language used to
> > +build scalable and maintainable applications.  Elixir leverages the
> > +Erlang VM, known for running low-latency, distributed and
> > +fault-tolerant systems, while also being successfully used in web
> > +development and the embedded software domain.")
> > +   (license license:asl2.0)))
> 
> Looks good!
> 
> > diff --git a/gnu/packages/patches/elixir-disable-failing-tests.patch 
> > b/gnu/packages/patches/elixir-disable-failing-tests.patch
> > new file mode 100644
> > index 000..802cb1e
> > --- /dev/null
> > +++ b/gnu/packages/patches/elixir-disable-failing-tests.patch
> 
> While I’m generally okay with disabling failing tests (see the
> embarassing situation we have with the “icedtea” packages), I think
> these can be fixed with little effort.  Many of them seem to be related
> to the location of the temp directory.

Note we are talking a rather small minority of tests. 11 out of 2000+
for Elixir. For Mix 10% fails, mostly because of git. The Elixir
people wrote there should be no network access involved.

> > +diff --git a/lib/elixir/test/elixir/node_test.exs 
> > b/lib/elixir/test/elixir/node_test.exs
> > +index d1f1fe6..5c2d469 100644
> > +--- a/lib/elixir/test/elixir/node_test.exs
> >  b/lib/elixir/test/elixir/node_test.exs
> > +@@ -6,8 +6,10 @@ defmodule NodeTest do
> > +   doctest Node
> > + 
> > +   test "start/3 and stop/0" do
> > +-assert Node.stop == {:error, :not_found}
> > +-assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
> > +-assert Node.stop() == :ok
> > ++IO.puts "Skipping test because GNU Guix does not allow the HOME 
> > environment variable."
> > ++
> > ++# assert Node.stop == {:error, :not_found}
> > ++# assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
> > ++# assert Node.stop() == :ok
> > +   end
> > + end
> 
> This was already addressed earlier.  We can probably just setenv HOME
> before the tests.
> 
> Some of the remaining tests don’t seem to have any obvious fixes, so
> I’ll get to them after making the above changes first.  Maybe the
> failures disappear then.
> 
> Thanks again for 

Re: Seeking guidance regarding system roll-back and switch-generation

[Chris Marusich]

Hi Ludo,

Thank you for the concrete suggestions.  I've looked into using the
parameters file.  It contains almost all the info I need, but I think
some is still missing.

> The output of ‘guix system build’ contains the ‘parameters’ file, which
> is enough to generate grub.cfg (see ‘previous-grub-entries’ in (guix
> scripts system)).

What if someone specifies extra "menu-entries" in their operating system
configuration file?  (as described in "(guix) GRUB Configuration")?
Those extra entries don't appear to be stored in the parameters file.

It would be very convenient if we could just store the entire
 in the built system output (e.g., the parameters
file).  Is that possible?

> However, the activation script is indeed missing.  We can add it to the
> output of ‘guix system build’ by extending ‘system-service-type’:
>
>
> diff --git a/gnu/services.scm b/gnu/services.scm
> index 5479bfa..fc3e17e 100644
> --- a/gnu/services.scm
> +++ b/gnu/services.scm
> @@ -352,11 +352,18 @@ ACTIVATION-SCRIPT-TYPE."
>  
>  (define (second-argument a b) b)
>  
> +(define (gexps->activation-system-entry gexps)
> +  "Return a directory entry to add to the result of the 'system' derivation."
> +  (mlet %store-monad ((script (activation-script gexps)))
> +(return `(("activate" ,script)
> +
>  (define activation-service-type
>(service-type (name 'activate)
>  (extensions
>   (list (service-extension boot-service-type
> -  gexps->activation-gexp)))
> +  gexps->activation-gexp)
> +   (service-extension system-service-type
> +  gexps->activation-system-entry)))
>  (compose append)
>  (extend second-argument)))
>  
>
>
> This way we have direct access to each generation’s activation script
> and we should be fine with (3).
>
> WDYT?

I'm afraid I don't yet know enough about gexps and the activation
process to give an informed opinion on that suggestion.  After I finish
the first milestone (switch symlinks and rebuild grub.cfg), I'll study
those topics in more detail and revisit your proposal.

Thank you,

-- 
Chris


signature.asc
Description: PGP signature

[PATCH] Add Elixir (was: )

[Ricardo Wurmus]

Hi Pjotr

> From 5fd8f64794b27f59f6688177a7a9e532b5d57f01 Mon Sep 17 00:00:00 2001
> Date: Tue, 19 Jul 2016 11:13:27 +
> Subject: [PATCH] gnu: Add elixir.
> To: guix-devel@gnu.org
> From: Pjotr Prins 
> References: <578e47d0.i8ovns6khzhqzvnc%pjotr.publi...@thebird.nl>
>
> * gnu/packages/elixir.scm: New file.
> * gnu/local.mk (GNU_SYSTEM_MODULES): Add it.

back to the original patch, which I didn’t look at as the ensuing
discussion on review process and registry proposals took up more time
than I anticipated.

I’m a little uncertain on how to proceed.  I have a couple of things
here that I’d like to change before commiting.  I’ll add some comments
below.  Indentation changes won’t be mentioned ;)

If you are okay with the proposed changes I can apply them on top of
your patch and resubmit the squashed patch to the ML for a final
look-over.  Deal?

> +   (native-inputs
> +`(("patch" ,patch)
> +  ("patch/elixir-disable-failing-tests"
> +   ,(search-patch "elixir-disable-failing-tests.patch"))
> +  ("patch/elixir-disable-mix-tests"
> +   ,(search-patch "elixir-disable-mix-tests.patch"

This has been mentioned already and I’d like to move these to the
“source” field after identifying the reason why the build fails
otherwise.  I see that you’re doing this in order to patch after the
build phase.  Let’s see if this can be avoided.

> +  (add-after 'build 'disable-breaking-elixir-tests
> +;; when patching tests as part of source the build breaks, so we do
> +;; it after the build phase
> +(lambda* (#:key inputs #:allow-other-keys)
> +  (and
> +   (zero? (system* "patch" "--force" "-p1" "-i"
> +   (assoc-ref inputs 
> "patch/elixir-disable-failing-tests")))
> +   (zero? (system* "patch" "--force" "-p1" "-i"
> +   (assoc-ref inputs 
> "patch/elixir-disable-mix-tests")))
> +   ;; Tests currently fail in these two files:
> +   (delete-file "./lib/mix/test/mix/tasks/deps.git_test.exs")
> +   (delete-file "./lib/mix/test/mix/shell_test.exs"

“delete-file” has an unspecified return value, so chaining it up in
“and” isn’t guaranteed to work.  Should this patch-after-build business
turn out to be unavoidable I suggest just deleting the files first, then
and-ing the “zero?” expressions.

> +  (replace 'check
> +   (lambda _
> + (zero? (system* "make" "test") ;; 3124 tests, 0 
> failures, 11 skipped

We can use “#:test-target "test"” instead of replacing the “check” phase.

> +  #:make-flags (list (string-append "PREFIX=" %output
> +   (home-page "http://elixir-lang.org/;)
> +   (synopsis "The Elixir programming language")

s/The//

> +   (description "Elixir is a dynamic, functional language used to
> +build scalable and maintainable applications.  Elixir leverages the
> +Erlang VM, known for running low-latency, distributed and
> +fault-tolerant systems, while also being successfully used in web
> +development and the embedded software domain.")
> +   (license license:asl2.0)))

Looks good!

> diff --git a/gnu/packages/patches/elixir-disable-failing-tests.patch 
> b/gnu/packages/patches/elixir-disable-failing-tests.patch
> new file mode 100644
> index 000..802cb1e
> --- /dev/null
> +++ b/gnu/packages/patches/elixir-disable-failing-tests.patch

While I’m generally okay with disabling failing tests (see the
embarassing situation we have with the “icedtea” packages), I think
these can be fixed with little effort.  Many of them seem to be related
to the location of the temp directory.

> +diff --git a/lib/elixir/test/elixir/node_test.exs 
> b/lib/elixir/test/elixir/node_test.exs
> +index d1f1fe6..5c2d469 100644
> +--- a/lib/elixir/test/elixir/node_test.exs
>  b/lib/elixir/test/elixir/node_test.exs
> +@@ -6,8 +6,10 @@ defmodule NodeTest do
> +   doctest Node
> + 
> +   test "start/3 and stop/0" do
> +-assert Node.stop == {:error, :not_found}
> +-assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
> +-assert Node.stop() == :ok
> ++IO.puts "Skipping test because GNU Guix does not allow the HOME 
> environment variable."
> ++
> ++# assert Node.stop == {:error, :not_found}
> ++# assert {:ok, _} = Node.start(:hello, :shortnames, 15000)
> ++# assert Node.stop() == :ok
> +   end
> + end

This was already addressed earlier.  We can probably just setenv HOME
before the tests.

Some of the remaining tests don’t seem to have any obvious fixes, so
I’ll get to them after making the above changes first.  Maybe the
failures disappear then.

Thanks again for the patch.  I hope you are willing to provide some
guidance when I have some problems understanding certain bits of the
build.

~~ Ricardo


PS: Elixir is big and getting it accepted in Guix upstream is a
precondition for more Elixir packages.  This is why I think it’s worth
picking this up.  For other patches this amount