Re: GSoC: Porting Guix to Hurd week 2 report

[Andreas Enge]

On Fri, May 15, 2015 at 10:17:14PM +0300, Manolis Ragkousis wrote:
> 5) Tomorrow if not today I will have ready the bootstrap-tarballs.

That sounds great, keep us updated when it happens!

Andreas

Re: Reproducible profiles

[Ludovic Courtès]

David Thompson  skribis:

> Lately I've been wanting to version control the list of packages that I
> install in my user profile so that I can sync it amongst many machines.
> So, I took a stab at adding a new '--apply' option to 'guix package'
> that reads in a package list from a Scheme file and creates a new
> generation of the profile with only those packages are installed.
> Here's an example configuration:
>
> (use-modules (gnu))
> (use-package-modules base less guile emacs admin ruby mail pumpio man)
> 
> (list ruby
>   coreutils
>   less
>   man-db
>   notmuch
>   guile-2.0
>   emacs
>   dmd
>   offlineimap
>   pumpa)

Yes, that sounds very useful.

As usual though, there’s the issue of multiple-output packages.  The
above snippet is nice, but doesn’t allow you to specify a particular
output of a package.

What about instead requiring people to return a manifest:

  (use-modules (guix profiles))
  (use-package-modules base emacs guile)

  (manifest (cons (package->manifest-entry gcc-toolchain "debug")
  (map package->entry
   (list gcc-toolchain emacs guile-2.0

That means we’ll have to document (guix profiles).

It’s more verbose than what you suggest, though.  If you insist ;-), we
could allow a list of packages instead of a manifest, though I’d prefer
not to do that.

WDYT?

> Below is a naive patch that does the job, but is unideal because it
> doesn't do some nice things like display the diff between generations
> before building.

For that you would need a procedure to infer the manifest transaction:

  (manifests->transaction m1 m2)
  ;; returns a 

and then that could be passed to ‘show-manifest-transaction’.

However, I’m not sure it’s very useful.  Perhaps it would be enough to
write “installing new manifest from foo.scm with 42 entries.”
WDYT?

> I'm looking for some guidance to make this option mesh better with the
> rest of the 'guix package' utility.  Any help is appreciated.

Overall it looks OK to me!

[...]

> + (option '("apply") #t #f
> + (lambda (opt name arg result arg-handler)
> +   (values (alist-cons 'apply (load arg) result)
> +   arg-handler)))

It would be better to delay loading until after arguments have been
parsed, as in ‘guix system’.  The procedure to load the file should be
similar to ‘read-operating-system’.

We’ll need documentation and tests, too.  :-)

Thank you!

Ludo’.

Re: Reproducible profiles

[宋文武]

Ludovic Courtès  writes:

> David Thompson  skribis:
>
>> Lately I've been wanting to version control the list of packages that I
>> install in my user profile so that I can sync it amongst many machines.
>> So, I took a stab at adding a new '--apply' option to 'guix package'
>> that reads in a package list from a Scheme file and creates a new
>> generation of the profile with only those packages are installed.
>> Here's an example configuration:
>>
>> (use-modules (gnu))
>> (use-package-modules base less guile emacs admin ruby mail pumpio man)
>> 
>> (list ruby
>>   coreutils
>>   less
>>   man-db
>>   notmuch
>>   guile-2.0
>>   emacs
>>   dmd
>>   offlineimap
>>   pumpa)
>
> Yes, that sounds very useful.
>
> As usual though, there’s the issue of multiple-output packages.  The
> above snippet is nice, but doesn’t allow you to specify a particular
> output of a package.
>
> What about instead requiring people to return a manifest:
>
>   (use-modules (guix profiles))
>   (use-package-modules base emacs guile)
>
>   (manifest (cons (package->manifest-entry gcc-toolchain "debug")
>   (map package->entry
>(list gcc-toolchain emacs guile-2.0
>
> That means we’ll have to document (guix profiles).
>
> It’s more verbose than what you suggest, though.  If you insist ;-), we
> could allow a list of packages instead of a manifest, though I’d prefer
> not to do that.
>
> WDYT?
>
+1 for return 'manifest', in a same way as 'operating-system'.
And how about use specification instead of package, so I can:

  (manifest
(map package-specification->manifest-entry
 '("emacs"
   "font-adobe-source-han-sans:cn")))

Re: Guix binary tarball

[Ludovic Courtès]

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> Additionally, it's a best-practice to disable password-authentication
> for the root account in sshd_config (Debian 8 proposes it at least) to
> prevent the chance of successful brute-force/dictionary attacks.

I think the default is to disable root login at all over SSH (that’s the
case with lshd), which is a good thing.

Ludo’.

Re: Guix binary tarball

[Ludovic Courtès]

Andreas Enge  skribis:

> On Fri, May 15, 2015 at 07:14:04PM +0200, Ludovic Courtès wrote:
>> > - The tarball also contains /, /root and /var. When unpacking it, the owner
>> >   and permissions are changed on the system.
>> No.  Maybe we can fix it by using two tar invocations with different
>> --owner.
>
> Hm. Then maybe the documentation should suggest the following?

Sorry I was referring to the implementation, not to the extraction.

>> A couple of days earlier would have been even better, but thanks for the
>> detailed feedback!  ;-)
>
> I thought it would avoid me to update the system immediately afterwards again
> if I waited for 0.8.2 :-)

Heh.  :-)

> Actually, we have not yet tried how this installation method interacts
> with "guix pull".

It shouldn’t make any difference.

Thanks,
Ludo’.

[PATCH] gnu: Add lpsolve.

[Andreas Enge]

Hello,

the attached patch adds a dependency of libreoffice with a build system
of its own. Since there is no check target, I have not tried whether the
resulting binary actually works as needed by libreoffice. We will see...

Comments are welcome.

Andreas


* gnu/packages/maths.scm (lpsolve): New variable.
---
 gnu/packages/maths.scm | 54 ++
 1 file changed, 54 insertions(+)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index f27903c..5c7fe6d 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1338,3 +1338,57 @@ library with poor performance.")
 library for graphics software based on the OpenGL Shading Language (GLSL)
 specifications.")
 (license license:expat)))
+
+(define-public lpsolve
+  (package
+(name "lpsolve")
+(version "5.5.2.0")
+(source
+ (origin
+  (method url-fetch)
+  (uri (string-append "mirror://sourceforge/lpsolve/lpsolve/" version
+  "/lp_solve_" version "_source.tar.gz"))
+  (sha256
+   (base32
+"176c7f023mb6b8bfmv4rfqnrlw88lsg422ca74zjh19i2h5s69sq"))
+  (modules '((guix build utils)))
+  (snippet
+   '(substitute* (list "lp_solve/ccc" "lpsolve55/ccc")
+  (("^c=cc") "c=gcc")
+  ;; Pretend to be on a 64 bit platform to obtain a common directory
+  ;; name for the build results on all architectures; nothing else
+  ;; seems to depend on it.
+  (("^PLATFORM=.*$") "PLATFORM=ux64\n")
+(build-system gnu-build-system)
+(arguments
+ `(#:tests? #f ; no check target
+   #:phases
+   (modify-phases %standard-phases
+ (delete 'configure)
+ (replace 'build
+   (lambda _
+ (with-directory-excursion "lpsolve55"
+   (system* "bash" "ccc"))
+ (with-directory-excursion "lp_solve"
+   (system* "bash" "ccc"))
+ #t))
+ (replace 'install
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(bin (string-append out "/bin"))
+(lib (string-append out "/lib")))
+   (mkdir-p lib)
+   (copy-file "lpsolve55/bin/ux64/liblpsolve55.a"
+  (string-append lib "/liblpsolve55.a"))
+   (copy-file "lpsolve55/bin/ux64/liblpsolve55.so"
+  (string-append lib "/liblpsolve55.so"))
+   (mkdir-p bin)
+   (copy-file "lp_solve/bin/ux64/lp_solve"
+  (string-append bin "/lp_solve"))
+   #t))
+(home-page "http://lpsolve.sourceforge.net/";)
+(synopsis "Mixed Integer Linear Programming (MILP) solver")
+(description
+ "lp_solve is a mixed integer linear programming solver based on the
+revised simplex and the branch-and-bound methods.")
+(license license:lgpl2.1)))
-- 
2.2.1

Re: GSoC: Porting Guix to Hurd week 2 report

[Ludovic Courtès]

Hello,

Thanks for the update, it all seems to be on track!

Hopefully the availability of the glibc-hurd tarball allow the code to
be simplified, and the Hurd-specific parts of the glibc recipes to be
reduced.

> I was thinking about following Mark's suggestion of having a generic
> glibc package with all the common
> configure flags and inputs, and the two others inheriting from it,
> defining the specific sources and
> inputs/flags. WDYT?

In an ideal world, the only differences between the two libcs would be
the source (and version) and the inputs.  How far are we from that now?

If we can achieve that, we’ll be able to keep a single glibc recipe.  If
there are other differences, we’ll see.

> Ludovic I don't have anything to report on the binaries actually
> running on hurd right now,
> because I am hoping to test that with the actual bootstrap tarballs.

No problem!

Cheers,
Ludo’.

Re: [PATCH] doc: Document native-inputs and propagated-inputs.

[Ludovic Courtès]

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> From 948fcdbb0cea1b8fcd7907554c61633db2f54dd8 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>  
> Date: Fri, 15 May 2015 21:54:11 +0200
> Subject: [PATCH] doc: Add "package Reference" and "origin Reference" sections.
>
> * doc/guix.texi (Defining Packages): Link to "package Reference".  Add menu.
> (package Reference, origin Reference): New subsections.

This looks great!

> +See @pxref{package Reference} for a full description of possible fields.

Should be:

  @xref{package Reference}, for a full description...

(@xref generates “See” and must be followed by a comma.)

> +@node package Reference
> +@subsection package Reference

@subsection @code{package} Reference

(Same for the second subsection.)

> +This section summarizes all the options available in ‘package’

@code{package}

> +@item @code{build-system}
> +The build system (@pxref{Build Systems}) that should be used to
> +build the package.

In general try to put parentheses at the end of the sentence so that
it’s easier to read.

> +@item @code{outputs} (default: @code{'("out")})
> +The list of output names of the package.

+ @xref{Packages with Multiple Outputs}, for typical uses of additional
outputs.

> +@item @code{native-search-paths} (default: @code{'()})
> +FIXME
> +
> +@item @code{search-paths} (default: @code{'()})
> +FIXME

You can group both with @itemx.  For now, let’s just say that it’s a
list of @code{search-path-specification} objects describing search-path
environment variables honored by the package.  We can write the
‘search-path-specification’ reference another day.  ;-)

> +@item @code{replacement} (default: @code{'()})
> +FIXME

Default is @code{#f}.
Something like:

  This must either @code{#f} or a package object that will be used as a
  @dfn{replacement} for this package.  @xref{Security Updates, grafts},
  for details.

> +@item @code{maintainers} (default: @code{'()})
> +The list of maintainers of the package.  FIXME: upstream, or package
> +recipe?

It’s still unused, but it’s meant to be the list of downstream package
maintainers, represented as a list of  objects (imagine a
(guix maintainers) module akin to (guix licenses) where we would all
live.)  Probably now would be a good time to start discussing it.

> +@item @code{properties} (default: @code{'()})
> +An alist of arbitrary properties of the package.

Leave that one undocumented (it’s currently unused and I’m not sure it’s
useful.)


[...]

> +@deftp {Data Type} origin
> +This is the data type representing a source code origin.
> +
> +@table @asis
> +@item @code{uri}
> +A string containing the URI of the source.

s/A string/An object/

You can add:

  The object type depends on the @code{method} (see below.)  For
  example, when using the @var{url-fetch} method of @code{(guix
  download)}, the valid @code{uri} values are: a URL represented as a
  string, or a list thereof.

> +@item @code{method}
> +A procedure that will handle the URI, such as @code{url-fetch}.

s/,.*//

Add a paragraph:

  Examples include:

  @table @asis
  @item @var{url-fetch} from @code{(guix download)}
  download a file the HTTP, HTTPS, or FTP URL specified in the
  @code{uri} field;

  @item @var{git-fetch} from @code{(guix git-download)}
  clone the Git version control repository, and check out the revision
  specified in the @code{uri} field as a @code{git-reference} object; a
  @code{git-reference} looks like this:

  @example
  (git-reference
(url "git://git.debian.org/git/pkg-shadow/shadow")
(commit "v4.1.5.1"))
  @end example
  @end @table

> +@item @code{sha256}
> +A bytevector containing the SHA-256 hash of the source.  Typically the
> +@code{base32} procedure is used here to generate the bytevector from a

s/procedure/form/

> +@item @code{patch-inputs} (default: @code{#f})
> +Input packages or derivations to the patching process.  When this is
> +@code{#f}, the usual set of inputs necessary for patching are provided,
> +such as GNU Patch.

GNU@tie{}Patch

> +@item @code{imported-modules} (default: @code{'()})

The list of Guile modules to import in the patch derivation, for use by
the @code{snippet}.

Could you send an updated patch?

Excellent work, thank you!

Ludo’.

Re: ftp Re: --with-store-dir and/or --localstatedir seem to be ignored

[Ludovic Courtès]

Alex Vorobiev  skribis:

> Thanks! I pulled the master from git and rebuilt/reinstalled guix. Now I 
> don't see that error! But I do see another one:
>
> $ guix package -i bash
> looking for the latest release of GNU bash...FTP to `ftp.gnu.org' failed:
> 530: User access denied.

This is annoying but harmless: ‘guix package’ is looking for the latest
Bash version available at ftp.gnu.org to tell you whether a newer one is
available upstream.  Here it cannot do that, so it just proceeds with
installation.

Perhaps we should allow users to somehow turn off this feature
altogether.  Thoughts?

> I do know that ftp connections are not allowed on my corporate network 
> for security reasons (http is fine). Is there any way to tell guix not to 
> use ftp repositories at all?

This particular feature (checking for newer upstream packages) is only
supported for GNU packages, and it’s ignored when it fails.

Substitutes are always downloaded over HTTP.

Source code for which no substitutes are available could be downloaded
either over HTTP, HTTPS, or FTP, depending on the package and mirrors.
I expect few are available solely over FTP, but for those, there’s no
workaround.

Then again, with substitutes enabled, you’re unlikely to stumble upon
such a case.

HTH,
Ludo’.

Re: Guix feedbacks

[Ludovic Courtès]

Daniel Pimentel  skribis:

> First, site: I like the new Guix website. It's beautiful design, so if
> you put a carrousel effect in screenshot pictures, maybe have more
> beautiful.

Personally I’m happier without a carousel.  :-)

> In documentation, there isn't command like "ifconfig eno1 up" for
> example. Why I speak about it? Because in some cases the interface not
> get IP with only "dhclient eno1", so in a lot of times I needed this
> command (up interface), so my suggestion is put in documentation
> too. References:
> https://www.gnu.org/software/guix/manual/html_node/System-Installation.html
> and
> https://www.gnu.org/software/guix/manual/html_node/System-Installation.html#FOOT11

Right, this was reported in
.  We’ll add a note
in the documentation.

> After install GuixSD 0.8.2, the Grub image (the GuixSd wallpaper, it's
> amazing) not appear. I need to update system (guix pull; guix system
> reconfigure /etc/config.scm)

Oh this is weird.

I just tried:

--8<---cut here---start->8---
$ ./pre-inst-env guix system init -n gnu/system/examples/bare-bones.tmpl /tmp
substitute: updating list of substitutes from 'http://hydra.gnu.org'... 100.0%
La jenaj derivoj estus konstruataj:
   /gnu/store/brc96mkj6kif5xn86g4a45s9p9nxj8s9-system.drv
   /gnu/store/gv5n9xgwrmddkj6xkvrhsgnq9h28571j-grub.cfg.drv
[...]
--8<---cut here---end--->8---

and it shows that grub.cfg is going to be built; grub.cfg.drv does
depend on the background image, and the resulting grub.cfg refers to the
background image as expected.

I guess a fresh install is needed to debug this.

> I wrote in my blog about free software, GNU, Guix, Emacs, XFCE and
> others things. So, I'd like opinion about it. Link:
> https://d4n1.org/guix-install/

Nice!  The URL of the installation image is wrong though.

Thanks for the feedback, it’s helpful!

Ludo’.

Re: Reproducible profiles

[Ludovic Courtès]

宋文武  skribis:

> And how about use specification instead of package, so I can:
>
>   (manifest
> (map package-specification->manifest-entry
>  '("emacs"
>"font-adobe-source-han-sans:cn")))

Sure, with:

  (use-modules (gnu) (guix profiles))

  (define package-specification->manifest-entry
(compose package->manifest-entry
 specification->package))

The advantage of using package names like this is that it’s less
sensitive to module changes; the disadvantage is that it is not as
precise, particularly if there are several packages matching a given
name.

Ludo’.

Re: [PATCH] doc: Document native-inputs and propagated-inputs.

[Taylan Ulrich Bayırlı/Kammer]

l...@gnu.org (Ludovic Courtès) writes:

>> +@item @code{imported-modules} (default: @code{'()})
>
> The list of Guile modules to import in the patch derivation, for use
> by the @code{snippet}.

I don't understand how this differs from `modules'?

> Could you send an updated patch?

Here it is.  Thanks for all the help!

>From 8e77504fef71b7679f52d257014a7d85a73a247a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
 
Date: Fri, 15 May 2015 21:54:11 +0200
Subject: [PATCH] doc: Add "package Reference" and "origin Reference" sections.

* doc/guix.texi (Defining Packages): Link to "package Reference".  Add menu.
(package Reference, origin Reference): New subsections.
---
 doc/guix.texi | 182 ++
 1 file changed, 182 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 049292d..b3a31c7 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1793,6 +1793,8 @@ However, any other dependencies need to be specified in the
 unavailable to the build process, possibly leading to a build failure.
 @end itemize
 
+@xref{package Reference}, for a full description of possible fields.
+
 Once a package definition is in place, the
 package may actually be built using the @code{guix build} command-line
 tool (@pxref{Invoking guix build}).  @xref{Packaging Guidelines}, for
@@ -1837,6 +1839,186 @@ and operating system, such as @code{"mips64el-linux-gnu"}
 Configure and Build System}).
 @end deffn
 
+@menu
+* package Reference ::  The package data type.
+* origin Reference::The origin data type.
+@end menu
+
+
+@node package Reference
+@subsection @code{package} Reference
+
+This section summarizes all the options available in @code{package}
+declarations (@pxref{Defining Packages}).
+
+@deftp {Data Type} package
+This is the data type representing a package recipe.
+
+@table @asis
+@item @code{name}
+The name of the package, as a string.
+
+@item @code{version}
+The version of the package, as a string.
+
+@item @code{source}
+An origin object telling how the source code for the package should be
+acquired (@pxref{origin Reference}).
+
+@item @code{build-system}
+The build system that should be used to build the package (@pxref{Build
+Systems}).
+
+@item @code{arguments} (default: @code{'()})
+The arguments that should be passed to the build system.  This is a
+list, typically containing sequential keyword-value pairs.
+
+@item @code{inputs} (default: @code{'()})
+Package or derivation inputs to the build.  This is a list of lists,
+where each list has the name of the input (a string) as its first
+element, a package or derivation object as its second element, and
+optionally the name of the output of the package or derivation that
+should be used, which defaults to @code{"out"}.
+
+@item @code{propagated-inputs} (default: @code{'()})
+This field is like @code{inputs}, but the specified packages will be
+force-installed alongside the package they belong to.  For example this
+is necessary when a library needs headers of another library to compile,
+or needs another shared library to be linked alongside itself when a
+program wants to link to it.
+
+@item @code{native-inputs} (default: @code{'()})
+This field is like @code{inputs}, but in case of a cross-compilation it
+will be ensured that packages for the architecture of the build machine
+are present, such that executables from them can be used during the
+build.  For example, this is necessary for build tools such as Autoconf,
+Libtool, pkg-config, or Gettext.
+
+@item @code{self-native-input?} (default: @code{#f})
+This is a Boolean field telling whether the package should use itself as
+a native input when cross-compiling.
+
+@item @code{outputs} (default: @code{'("out")})
+The list of output names of the package.  @xref{Packages with Multiple
+Outputs}, for typical uses of additional outputs.
+
+@item @code{native-search-paths} (default: @code{'()})
+@itemx @code{search-paths} (default: @code{'()})
+A list of @code{search-path-specification} objects describing
+search-path environment variables honored by the package.
+
+@item @code{replacement} (default: @code{#f})
+This must either @code{#f} or a package object that will be used as a
+@dfn{replacement} for this package.  @xref{Security Updates, grafts},
+for details.
+
+@item @code{synopsis}
+A one-line description of the package.
+
+@item @code{description}
+A more elaborate description of the package.
+
+@item @code{license}
+The license of the package; a value from @code{(guix licenses)}.
+
+@item @code{home-page}
+The URL to the home-page of the package, as a string.
+
+@item @code{supported-systems} (default: @var{%supported-systems})
+The list of systems supported by the package, as strings of the form
+@code{architecture-kernel}, for example @code{"x86_64-linux"}.
+
+@item @code{maintainers} (default: @code{'()})
+The list of maintainers of the package, as @code{maintainer} objects.
+
+@item @code{