Re: Staging

[Leo Famulari]

On Tue, Feb 20, 2018 at 11:45:58AM +0200, Efraim Flashner wrote:
> Java currently only affects x86_64, so I'm not sure that it would need
> to be staging specifically. In any case if we can get it merged within
> the next week or so that'd be amazing. I know our cmake is in need of an
> upgrade, maybe libva?

Are there any specific issues that would be fixed by a CMake update, or
is it just "too old"? I think that changes on the staging branch should
have a low probability of breaking things, so that we can finish the
branch quickly.


signature.asc
Description: PGP signature

Staging

[Leo Famulari]

There are some patches on the staging branch, including an update to the
time zone database.

What are the plans for the next week or so? Should we try merging the
staging branch in that timeframe?


signature.asc
Description: PGP signature

Re: heads-up: Haskell updates

[Leo Famulari]

On Thu, Feb 15, 2018 at 06:03:56PM +0100, Danny Milosavljevic wrote:
> Hi Ricardo,
> 
> > Danny, could you please do this on master and core-updates?
> 
> I've done it on master now.
> 
> Maybe it's me being used to SVN, but can I git am the commit to core-updates?
> 
> Wouldn't that cause a conflict on the next merge of master to core-updates 
> (because of the missing in-betweens) ?

Git handles this case in my experience.

If you try it and it becomes complicated, you could instead merge master
into core-updates in order to get the change on core-updates.

If you're not comfortable doing it with Git just let me know and I'll do
it.


signature.asc
Description: PGP signature

Re: proposal: with-file-writeable

[Leo Famulari]

On Wed, Feb 14, 2018 at 02:51:08PM +0100, Ludovic Courtès wrote:
> Gábor Boskovits  skribis:
> 
> > the make-file-writeable function seems a bit too imperative to me, it would
> > look better if we could have a with-file-writeable function, so that we can
> > constrain the size effect, and more. Moreover if a file is read-only to
> > start with, it might be a good idea to keep it that way anyways. WDYT?
> 
> Which ‘make-file-writeable’ function?  I don’t see it in master.

There was a typo; it's ((guix build utils) make-file-writable)


signature.asc
Description: PGP signature

Re: [PATCH] Add SELinux policy for guix-daemon.

[Leo Famulari]

On Tue, Feb 13, 2018 at 09:46:53PM +0200, Efraim Flashner wrote:
> Should etc/guix-daemon.cil be added to .gitignore?

Yes, rekado confirmed this to me yesterday on #guix. Can you do it? :)


signature.asc
Description: PGP signature

Re: bug#30394: ARM compilation via qemu binfmt - Assertion failure

[Leo Famulari]

On Sun, Feb 11, 2018 at 12:45:18AM +0100, Chris Marusich wrote:
> Danny Milosavljevic  writes:
> 
> > This is only fixed in glibc 2.27 (not in core-updates).
> 
> Should we upgrade glibc in core-updates, then?  Or is it better to do it
> in the next core-updates cycle, to avoid still more unexpected breakage?

It's too late in this cycle. Upgrading glibc would require a full
rebuild and would introduce new failures.


signature.asc
Description: PGP signature

Re: Re: [PATCH] gnu: Add python2-gyp

[Leo Famulari]

On Mon, Feb 05, 2018 at 05:39:50PM -0500, dpg wrote:
> Sending a new patch, this will apply cleaner and has an actually good commit
> message :-) 

Thanks! But it still didn't apply :)

> From 300c37a8d9818cfc1a6315d2113cf58b110e1664 Mon Sep 17 00:00:00 2001
> From: DoublePlusGood 
> Date: Mon, 5 Feb 2018 17:26:34 -0500
> Subject: [PATCH] gnu: python: Add python2-gyp
> 
> * gnu/packages/python.scm: Added python2-gyp library.

> +;; Google does not release versions,
> +;; based on second most recent commit date.
> +(version "2017-10-11")

As described in the manual section Version Numbers, we handle versioning
of version control checkouts in a specific way:

https://www.gnu.org/software/guix/manual/html_node/Version-Numbers.html#Version-Numbers

This allows us to ensure that the versions always increase and can be
used to refer back to the upstream version control repository. At least
in Git, dates are not meaningful. They can be set to anything with the
--date parameter.

We also have the special helper functions git-version and git-file-name
to make it easy to use the standard versioning scheme.

I standardized the version and source file-name as in the attached diff,
standardized the commit message, updated the copyright date, and pushed
the result as commit 956ba99cb799889e0a0bc0f657f4e31b4f830775.
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index f77491a90..45ef7b5b6 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -46,7 +46,7 @@
 ;;; Copyright © 2017 Muriithi Frederick Muriuki 
 ;;; Copyright © 2017 Brendan Tildesley 
 ;;; Copyright © 2018 Fis Trivial 
-;;; Copyright © 2017 Ethan R. Jones 
+;;; Copyright © 2018 Ethan R. Jones 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -12420,30 +12420,31 @@ style guide, even if the original code didn't violate 
the style guide.")
   (package-with-python2 python-yapf))
 
 (define-public python-gyp
-  (package
-(name "python-gyp")
-;; Google does not release versions,
-;; based on second most recent commit date.
-(version "2017-10-11")
-(source
- (origin
-   ;; Google does not release tarballs,
-   ;; git checkout is needed.
-   (method git-fetch)
-   (uri (git-reference
- (url "https://chromium.googlesource.com/external/gyp;)
- (commit "5e2b3ddde7cda5eb6bc09a5546a76b00e49d888f")))
-   (sha256
-(base32
- "0fr7nxcrk292djmxzpcjaphnsd123k31gp8jnd91vwknhq6snmv9"
-(build-system python-build-system)
-(home-page "https://gyp.gsrc.io/;)
-(synopsis "GYP is a Meta-Build system")
-(description
- "GYP builds build systems for large, cross platform applications.
-It can be used to generate XCode projects, Visual Studio projects,
-Ninja build files, and Makefiles.")
-(license license:bsd-3)))
+  (let ((commit "5e2b3ddde7cda5eb6bc09a5546a76b00e49d888f")
+(revision "0"))
+(package
+  (name "python-gyp")
+  (version (git-version "0.0.0" revision commit))
+  (source
+   (origin
+ ;; Google does not release tarballs,
+ ;; git checkout is needed.
+ (method git-fetch)
+ (uri (git-reference
+   (url "https://chromium.googlesource.com/external/gyp;)
+   (commit commit)))
+ (file-name (git-file-name name version))
+ (sha256
+  (base32
+   "0fr7nxcrk292djmxzpcjaphnsd123k31gp8jnd91vwknhq6snmv9"
+  (build-system python-build-system)
+  (home-page "https://gyp.gsrc.io/;)
+  (synopsis "GYP is a Meta-Build system")
+  (description
+   "GYP builds build systems for large, cross platform applications.
+It can be used to generate XCode projects, Visual Studio projects, Ninja build
+files, and Makefiles.")
+  (license license:bsd-3
 
 (define-public python2-gyp
   (package-with-python2 python-gyp))


signature.asc
Description: PGP signature

Re: 01/01: gnu: Add badass.

[Leo Famulari]

On Mon, Jan 29, 2018 at 06:09:16PM -0500, Mark H Weaver wrote:
> Hi ng0,
> 
> > commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
> > Author: ng0 
> > Date:   Wed Jan 17 22:42:55 2018 +
> >
> > gnu: Add badass.
> [...]
> > +  (package
> > +(name "badass")
> > +(version (git-version "0.0" revision commit))
> [...]
> > +(synopsis "Hacking contribution graphs in git")
> > +(description
> > + "Badass generates false commits for a range of dates, essentially
> > +hacking the gamification of contribution graphs on platforms such as
> > +Github or Gitlab.")
> 
> Why do you think this belongs in Guix?  Do you intend to use it
> yourself, or do you have reason to believe that Guix users would want
> this?
> 
> There's a lot of garbage out there.  Guix doesn't need to include every
> script that someone uploaded to github.  Frankly, I'm embarrassed to
> have a package like this in Guix.

As the committer, I thought of this as an amusing toy, and we do have a
couple of those.

But if people would rather we not distribute it, I won't object.


signature.asc
Description: PGP signature

Re: 01/01: gnu: gource: Fix the hashes of mutated GitHub archives.

[Leo Famulari]

On Sun, Jan 28, 2018 at 08:36:42PM +0300, Oleg Pykhalov wrote:
> Leo Famulari <l...@famulari.name> writes:
> > Additionally, if a packager uses `guix download` to check the hash of
> > some file, but uses an incorrect URL in the package definition, Guix
> > will use the file in /gnu/store and never try the URL. So it's easy to
> > commit the wrong URL if you use `guix download`. Instead I recommend
> > downloading the file outside of Guix and using `guix hash`.
> 
> Ah, thank you!  I think because Guix doesn't make a new derivation if
> the URL in package recipe was changed.  But it's not clear if you don't
> think about that carefully.

Yes, this is tricky.

> Could we have following warnings in the documentation?
> 
>   - GitHub archive could lead to non-reproducible source tarball, please
> use a release tarball if it is available.

The problem of unstable upstream sources is a general problem, not
limited to GitHub. We noticed it recently on GitHub because they host so
many projects, but it happens at other mega-hosters and also with
self-hosted projects.

We use content addressing to make it easier to preserve and find these
sources over time. Guix will look on any substitute servers you are
using, our own content-addressed storage, and the Nix project's
content-addressed storage. The Software Heritage project [0] exists
to address this specific problem, and we'd like to eventually try
fetching sources from them, too.

>   - If you use a @code{guix download} command to check the hash of some
> file, but use an incorrect URL in the package definition, Guix will
> use the file in @file{/gnu/store/…pack.tar.gz} and never try the
> URL.  So it's easy to commit the wrong URL if you use @code{guix
> download}. Instead recommended to download the file outside of Guix
> and use a @code{guix hash} command.

Something like this would be helpful, but I'd like to write it more
carefully, and also think about exactly where in the manual it should
go.

To me the obvious choices are 'Invoking guix download' and 'Packaging
Guidelines'.

I'm also wary of filling the manual with warnings and caveats which
could overwhelm the reader...

[0] https://www.softwareheritage.org/


signature.asc
Description: PGP signature

Re: 01/01: gnu: gource: Fix the hashes of mutated GitHub archives.

[Leo Famulari]

On Thu, Jan 25, 2018 at 09:17:38AM -0500, Oleg Pykhalov wrote:
> wigust pushed a commit to branch master
> in repository guix.
> 
> commit 45b486984d8ab092cf002cd0b500df4dc62e186b
> Author: Oleg Pykhalov 
> Date:   Thu Jan 25 16:58:35 2018 +0300
> 
> gnu: gource: Fix the hashes of mutated GitHub archives.
> 
> * gnu/packages/version-control.scm (gource): Fix hash.

> -"https://github.com/acaudwell/Gource/archive/;
> -"gource-" version ".tar.gz"))
> +"https://github.com/acaudwell/Gource/releases/download;
> +"/gource-" version "/gource-" version ".tar.gz"))

Hey, thanks for fixing this up.

The commit message made me think that the hash had changed, but based on
this commit it seems that the URL changed somehow, or was originally
incorrect.

In cases where the hash actually changed, please send a message to
bug-guix so we can investigate publicy.

The automatically created per-tag GitHub snapshots are not guaranteed to
be cached forever by GitHub or recreated deterministically, so their
hashes are subject to change. [0]

Additionally, if a packager uses `guix download` to check the hash of
some file, but uses an incorrect URL in the package definition, Guix
will use the file in /gnu/store and never try the URL. So it's easy to
commit the wrong URL if you use `guix download`. Instead I recommend
downloading the file outside of Guix and using `guix hash`.

[0]
https://github.com/libgit2/libgit2/issues/4343
https://bugs.gnu.org/28659


signature.asc
Description: PGP signature

Re: [PATCHES] gnu: linux-libre: Full retpoline support on x86 [spectre mitigation]

[Leo Famulari]

On Sat, Jan 20, 2018 at 03:34:08PM -0500, Mark H Weaver wrote:
> Here are two patches that:
> 
> * Add gcc-7.3.0-RC-20180117, which includes support for retpoline.
> * Use gcc-7.3 to build linux-libre on x86 systems.
> 
> I'm currently running linux-libre-4.14.14 with full retpoline support:
> 
>   mhw@jojen ~$ cd /sys/devices/system/cpu/vulnerabilities
>   mhw@jojen /sys/devices/system/cpu/vulnerabilities$ grep . *
>   meltdown:Mitigation: PTI
>   spectre_v1:Vulnerable
>   spectre_v2:Mitigation: Full generic retpoline
> 
> There's also support for retpoline in linux-libre-4.9.77, but none yet
> in earlier kernels.
> 
> My question is: should we push these patches to 'master' now, or should
> we wait until gcc-7.3 is released (possibly as soon as January 24)?

I'm used this compiler and Guix packages to build a custom Linux 4.14.14
and have used it on my laptop for a day or so now. No problems and the
kernel does see the retpoline:

$ grep . /sys/devices/system/cpu/vulnerabilities/*
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v1:Vulnerable
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Full generic 
retpoline


signature.asc
Description: PGP signature

Re: [PATCHES] gnu: linux-libre: Full retpoline support on x86 [spectre mitigation]

[Leo Famulari]

On Sun, Jan 21, 2018 at 10:09:41PM -0800, Chris Marusich wrote:
> Mark H Weaver  writes:
> 
> > Here are two patches that:
> >
> > * Add gcc-7.3.0-RC-20180117, which includes support for retpoline.
> > * Use gcc-7.3 to build linux-libre on x86 systems.
> 
> Awesome!  Thank you for this.
> 
> > My question is: should we push these patches to 'master' now, or should
> > we wait until gcc-7.3 is released (possibly as soon as January 24)?
> 
> Since GuixSD makes it easy to roll back the entire system if it turns
> out there's a problem with the new kernel, I think we should just do it.

Agreed, the risk seems low. The only issue is that we (and anyone not
using substitutes) will have to build GCC 7 and linux-libre twice in a
short period of time, which could be annoying.

However, I don't have experience with GCC release candidates; I assume
they are of high quality.


signature.asc
Description: PGP signature

Re: Logging in with a prebuilt VM

[Leo Famulari]

On Sat, Jan 20, 2018 at 02:57:22AM +, Matthew Rennekamp wrote:
> Hello all.
> I've tried (albeit with little effort) a couple times to install v12 and v14 
> from the USB images. However, neither times worked, so I'm taking care of 
> school in the meantime.
> I found out while looking through documentation that ready vm images were 
> made, and I was surprised because these weren't noted on the main 
> (gnu.org/software/guix) website, but I had found a mention on 
> https://www.gnu.org/software/guix/manual/html_node/Running-GuixSD-in-a-VM.html
>  (doc #/page 6.2.14).

We offer VM images on the download page as "GuixSD 0.14.0 QEMU Image":

https://www.gnu.org/software/guix/download/

> I booted it up, but I have one question: where am I supposed to find a 
> working login and password? Is it listed somewhere, or alternatively, who 
> publishes these?

You should be able to log in as root with no password.

HTH!


signature.asc
Description: PGP signature

Re: 03/15: gnu: wxwidgets: Use webkitgtk-2.4.

[Leo Famulari]

On Mon, Jan 22, 2018 at 02:00:57PM -0500, Danny Milosavljevic wrote:
> dannym pushed a commit to branch master
> in repository guix.
> 
> commit 8a58182c12193ae27359591c92febfdd602411f4
> Author: Danny Milosavljevic 
> Date:   Mon Jan 22 17:34:13 2018 +0100
> 
> gnu: wxwidgets: Use webkitgtk-2.4.
> 
> * gnu/packages/wxwidgets.scm (wxwidgets)[inputs]: Replace "webkitgtk" by
> "webkitgtk-2.4".

Hi Danny,

What's the reason for this change?

Webkitgtk is actively examined and exploited by security researchers. I
think we should try not to build wxwidgets with this unmaintained
version of webkitgtk.

If some application needs wxwidgets with this older webkitgtk, we should
make a new package for it and maybe file a bug upstream pointing out the
risks of such a dependency. We already have a few such "special"
wxwidgets packages.


signature.asc
Description: PGP signature

Re: Prevent native-inputs references ending up in the final binary

[Leo Famulari]

On Sat, Jan 20, 2018 at 04:47:14PM +0100, Tobias Geerinckx-Rice wrote:
> Danny,
> 
> Danny Milosavljevic wrote on 20/01/18 at 11:40:
> > We should change that in core-updates-next, if possible.
> >  
> > I think that native-inputs shouldn't end up in the final binary as a
> > reference [...]
> This has been discussed before, and I agree. (I started a branch to do
> so but it breaks quite a few things and it got tedious. I think I'm
> ready for more now.)

Yeah, I think a lot of things will break.

Something to consider is that not every reference has an effect on the
built software. Sometimes the reference is a nonfunctional string that
ends up in documentation, or for error messages, or many other places.
It may be a lot of work to remove them all.

I'd rather we do it somewhere else than core-updates.

It's already very difficult to complete the core-updates cycles. We
should limit core-updates to updates of core packages, and handle big
changes to Guix itself on their own branches.


signature.asc
Description: PGP signature

core-updates: SELinux

[Leo Famulari]

On Wed, Jan 17, 2018 at 07:50:28PM -0800, Leo Famulari wrote:
> The latest core-updates evaluation is coming together [0], but there are
> still a few notable issues:

Some of the SELinux packages are also failing to build:

https://hydra.gnu.org/build/2414231

I tried updating libsepol to 2.7, and that fixes some things, but it
breaks other packages...

If you use SELinux, please help :)


signature.asc
Description: PGP signature

Re: Meltdown / Spectre

[Leo Famulari]

On Fri, Jan 19, 2018 at 05:06:25PM -0500, Mark H Weaver wrote:
> l...@gnu.org (Ludovic Courtès) writes:
> > Leo Famulari <l...@famulari.name> skribis:
> >> Something we can do very easily, even on the master branch, is to build
> >> specific packages with GCC 7, assuming the Retpoline technique would be
> >> effective in that context.
> >
> > Yes, I see Alex submitted a patch already.
> 
> There's now a GCC 7.3 release candidate that apparently contains the
> necessary compiler support to allow linux-libre-4.14.14 to use the
> retpoline technique internally.
> 
>   https://gcc.gnu.org/ml/gcc/2018-01/msg00115.html
> 
> They hope to release GCC 7.3 on January 24th.  It would be good to
> promptly add GCC 7.3 to Guix when its released, and to start using it to
> build linux-libre-4.14 on selected systems: x86_64 and possibly aarch64.
> 
> I'd prefer to continue using our default compiler to build linux-libre
> on systems where GCC 7.3 is not known to help with this issue.

Thanks for looking into this, Mark. Your plan sounds good to me.


signature.asc
Description: PGP signature

Re: Is it necessary to download the native inputs while installing packages?

[Leo Famulari]

On Thu, Jan 18, 2018 at 08:54:32PM +, Fis Trivial wrote:
> Sorry about the mess in the original question.
> 
> >
> > ‘Installing’ is too ambiguous to answer.
> >
> > - When *substituting* (installing a binary), native-inputs are not
> > required and should never be downloaded.
> 
> This answers my question in mind, thanks. :)

Although native-inputs are typically things that are only required while
building [0], there's nothing that prevents a built package from keeping
references to native-inputs.

[0] The "native" part is related to cross-compilation.


signature.asc
Description: PGP signature

Re: Is it necessary to download the native inputs while installing packages?

[Leo Famulari]

Sorry for the top-posting.

I need to clarify what --fallback does.

Guix will always build locally if the substitute servers say they lack 
something Guix needs.

--fallback works when the substitute servers say they have something, and then 
the substitution fails unexpectedly. For example, the server may become 
overloaded and drop the connection.


 Original Message 
From: Tobias Geerinckx-Rice 
Sent: January 18, 2018 9:36:50 AM PST
To: ybbs.da...@hotmail.com, guix-devel@gnu.org
Subject: Re: Is it necessary to download the native inputs while installing 
packages?

Hullo,

There are quite a few unrelated points mixed together here. I'll try to
address all of them, but I'm not entirely sure what your main question
is. I hope to answer it by accident.

Fis Trivial wrote on 18/01/18 at 16:19:
> The network connections to hydra is bad at day time from where I am,
>  the download speed is about 10kB/s, I can only work with guix at 
> night. And sometimes I use guix --fallback option(like texlive), guix
> will redirect to the upstream download link.

I get your meaning, but ‘redirect’ isn't the right word to use here.
Redirection is something servers do, and that's not the case here.

When installing a package, Guix queries all known substitute servers for
a pre-built binary substitute. What ‘--fallback’ does is tell Guix to
not give up if all servers answer negatively (404), but to build the
package from source locally. For that it needs to download the source
from upstream servers, and of course the native inputs required to
perform the build. There's no way around that.

If any of the substitute servers *can* provide a binary, no
native-inputs will be downloaded at all.

Why are you adding ‘--fallback’?

> Chances are the upstream has even worse network bandwidth, then I 
> have to manually find a mirror of that particular upstream and use 
> `guix download`.

This is an unrelated but valid point. I've previously mused that it
should be possible to let users choose (a set of) their favourite
mirror(s), instead of always downloading sources from the first mirror
queried.

It could be as simple as adding ISO codes to each mirror URI.

> In the case of *texlive-texmf*, it serves mostly as a build 
> dependence. To make things even less convenient, most of the mirror 
> site only store its ISO package, not the tar ball used in guix 
> package.

Oh. That's unfortunate. I'm not familiar with the Guix texlive packages,
and all the ones I happened to look at now have a direct ftp:// link.

Is upstream the one doing the — heh — redirection here? If so, it should
arguably doing a better job. We could still help matters by hard-coding
a shortlist of mirrors known to host the files we need.

> So, I gotta wonder, can we just download the normal inputs and 
> propagated inputs from hydra while installing packages? Would that 
> break something like the functional property of guix?

‘Installing’ is too ambiguous to answer.

- When *substituting* (installing a binary), native-inputs are not
required and should never be downloaded.
- When *building* (from source), they are.

Kind regards,

T G-R

PS: Oh. Right. Sigh... To complicate matters, texlive-texmf is a special
case that's never substituted, because doing so is thought to be worse
than just building it from source[1].

That's the reason you're downloading TexLive from upstream, but it's
*not* the reason you're pulling in TexLive to begin with and doesn't
change the native-inputs situation. I think.

[1]:
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/hydra.gnu.org-locations.conf#n23

Re: core-updates, let’s go!

[Leo Famulari]

On Mon, Jan 01, 2018 at 06:12:49PM +0100, Ludovic Courtès wrote:
> We’ll have to stay focused in the coming days to fix everything as
> quickly as we can.

The latest core-updates evaluation is coming together [0], but there are
still a few notable issues:

* Pandas is failing to build:

https://hydra.gnu.org/job/gnu/core-updates/python2-pandas-0.19.2.x86_64-linux

* CLISP is failing to build, which breaks SBCL:

https://hydra.gnu.org/job/gnu/core-updates/clisp-2.49-60.x86_64-linux

* Several packages are failing due to changes in ICU related to type
definitions. For example, evolution-data-server is failing to build,
which breaks GNOME:

https://hydra.gnu.org/job/gnu/core-updates/evolution-data-server-3.24.3.x86_64-linux

* ant-bootstrap failed to build, breaking most (all?) of the Java
packages. This is being discussed in . I
can't retry the ant-bootstrap build because the package is not public,
so there is no corresponding job on Hydra. An example:

https://hydra.gnu.org/build/2443807

* And more!

Why not check if the packages you rely on are working on core-updates?
These are the packages that fail compared to the master branch:

[0] 
https://hydra.gnu.org/eval/109888?compare=master=1#tabs-now-fail


signature.asc
Description: PGP signature

Re: diffoscope

[Leo Famulari]

On Sat, Jan 13, 2018 at 06:44:02PM +0100, Gábor Boskovits wrote:
> Hello guix,
> 
> I think we should consider moving some diffoscope inputs to propagated
> inputs.
> It would be nice to test it with a plain profile, to check what should be
> propagated.

Help wanted :)

> I don't know if package-management is a logical place for this package.
> Do we have any better to place this?

"Package management" doesn't cover all the potential uses of diffoscope,
but we put it there because it came out of the reproducible builds
project and most people seem to use it to compare the results of
building software.


signature.asc
Description: PGP signature

Re: LanguageKit (targets llvm)

[Leo Famulari]

On Sat, Jan 13, 2018 at 03:47:21PM +0100, Catonano wrote:
> This project
> 
> http://etoileos.com/etoile/features/languagekit/
> 
> targets llvm
> 
> As far as I understand it doesn't target llvm too. It targets llvm _only_
> 
> If I understand correctly, it aims to make dinamic languages wrap the
> GNUStep kernel
> 
> Sort of like Guile does
> 
> I know what Stallmand wrote about llvm
> 
> But what does this mean for Guix ?
> 
> Is LanguageKit acceptable in Guix ?

Yes, if LanguageKit is free software, it's acceptable. We have an LLVM
package and build several packages with it.


signature.asc
Description: PGP signature

Re: invoke instead of (system* ...

[Leo Famulari]

On Fri, Jan 12, 2018 at 08:16:40PM +0100, Catonano wrote:
> recently I read that we should move to using this invoke procedure instead
> of the (system* some-script) in defining little scripts in packages and
> services definitions
> 
> But I can't remember where exactly
> 
> Where is this invoke procedure defined ?

It's in guix/build/utils.scm


signature.asc
Description: PGP signature

Re: core-updates warning: Not ready for GuixSD deployment

[Leo Famulari]

On Wed, Jan 10, 2018 at 10:13:51AM +0100, Ludovic Courtès wrote:
> Leo Famulari <l...@famulari.name> skribis:
> 
> > After rebooting, I found that my user's numerical ID had changed, so I
> > no longer owned any of my files. Not being able to read ~/.ssh means you
> > can't log in remotely.
> >
> > Additionally, several of root's "dotfiles" had been replaced with their
> > default versions, erasing my modifications. For example,
> > ~root/.bash_profile no longer contained my modifications.
> >
> > Finally, my users's password no longer worked. I fixed this as root
> > before I noticed that my user's files were inaccessible; I don't know if
> > I could have avoided the password reset by re-chowning my files.
> 
> Long story short: this should be fixed by
> 
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=4610ab7c9a5327df0d475262817bc081a5891aa8
> 
> Below is the message I wrote as I was investigating, if you’re curious.
> :-)

Thanks, I was very curious :)


signature.asc
Description: PGP signature

Re: Meltdown / Spectre

[Leo Famulari]

On Wed, Jan 10, 2018 at 11:46:46AM +0100, Tobias Platen wrote:
> The Talos II is a free-er system. And its processor (the POWER9) does not
> seem to be affected by Meltdown/Sprectre [1].
> 
> [1] https://mobile.twitter.com/RaptorCompSys?p=s

The Talos teams says that their POWER8 and POWER9 systems are vulnerable
to Meltdown and Spectre, but that the CPUs will be patched somehow:

https://twitter.com/RaptorCompSys/status/949368929507520517

I expect any CPU that does speculative execution / executes out-of-order
will be found to be vulnerable.


signature.asc
Description: PGP signature

Re: Meltdown / Spectre

[Leo Famulari]

On Tue, Jan 09, 2018 at 06:10:02PM -0500, Mark H Weaver wrote:
> Marius Bakke  writes:
> > Katherine Cox-Buday  writes:
> >> I am also interested -- more from a philisophical perspective -- how
> >> GuixSD and GNU squares with these kinds of security updates.
> >
> > In my opinion, CPU microcode falls under "non-functional data", as
> > expressly permitted by the GNU FSDG.
> 
> I strongly disagree.  CPU microcode is absolutely functional data.
> It determines how the CPU functions.

Personally I would really like to have microcode deployment integrated
into GuixSD. But I agree with Mark here, and I don't see how it can be
reconciled with the FSDG.


signature.asc
Description: PGP signature

Re: Meltdown / Spectre

[Leo Famulari]

On Wed, Jan 10, 2018 at 05:39:59AM +0800, Alex Vong wrote:
> I have an idea. Should we add a news entry to Guix blog[0] summarizing
> all the above? For example, we can advice users to install noscript and
> turn off javascript by default and only enable it on trusted site when
> necessary.

I think it's a good idea to publish an advisory of some sort but I don't
know if I'll have time in the next few days to write it.

> About the "Retpoline" mitigation technique[1]. Right now only GCC 7.2.0
> is patched, but our default gcc version is 5.4.0 in master and 5.5.0 in
> core-updates.  So I tried to apply the patches apply the patches to
> 5.5.0. There are totally 17 commits/patches. The first 3 patch can be
> modified to work while the 4th patch cannot be easily modified to work
> because the function ``ix86_nopic_noplt_attribute_p'' is not present on
> 5.5.0. Perhaps discarding the hunk would be fine, but we need to be
> careful about it (maybe running tests make sure the fix really works).
> 
> Do you think we should modify the patch to make it work on GCC 5 or
> update core-updates to GCC 7 instead?

So far I haven't had time to read about Retpoline, how it works, and the
degree to which other mitigations work without it. So the following
opinion is from a place of ignorance. I'm very interested to hear what
everyone else thinks about your suggestion.

Having said that, my opinion is that it's too late in this core-updates
cycle to change the default GCC version, especially two major versions,
from 5 to 7.

My impression is that we are relatively close to finishing this cycle.
Changing the default GCC would surely cause lots of new build failures
requiring fixes to affected packages.

There are probably many unpublicized / undiscovered security fixes in
many of the updates on core-updates. It's valuable to deploy those as
quickly as possible. Is it more valuable than waiting until we can build
the packages with GCC 7? I don't know.

Something we can do very easily, even on the master branch, is to build
specific packages with GCC 7, assuming the Retpoline technique would be
effective in that context.


signature.asc
Description: PGP signature

Re: 01/01: gnu: python-pygpgme: Use GnuPG 1 for the test suite.

[Leo Famulari]

On Sun, Jan 07, 2018 at 06:57:43PM -0800, Chris Marusich wrote:
> That's good to know.  However, when I tried accessing the link
> 
> https://hydra.gnu.org/jobset/gnu/master
> 
> I get a 504 (gateway timeout).  I feel like I often get this while
> trying to browse Hydra.  Does it load reliably for you?

Some periodic tasks on that server are very demanding and the web
interface becomes unreliable. It's usually a bit slow as well.


signature.asc
Description: PGP signature

Meltdown / Spectre

[Leo Famulari]

On Sat, Jan 06, 2018 at 09:20:50PM +0800, Alex Vong wrote:
> I hope this is on topic. Recently, 2 critical vulnerabilities (see
> https://meltdownattack.com/) affecting virtually all intel cpus are
> discovered. I am running libreboot x200 (see
> https://www.fsf.org/ryf).

> What should I do right now to patch my laptop?

### What to do now ###

Assuming you are running GuixSD, do this as root to update your kernel:

# guix pull && guix system reconfigure path/to/config.scm && reboot

If you are running another distro, update the kernel in the normal way.
Take any updates to your web browser packages on that distro.

### Who is affected? ###

I'd like to clarify that these issues are not limited to Intel CPUs.
They affect any CPU that executes out-of-order, which is almost all of
them for several years now.

Some of the very slow and simple ARM CPUs execute in-order and are not
affected.

Please consult the chip makers for more detail.

### Guix status ###

The CPU makers are issuing microcode updates as a hardware-level
mitigation, but I don't think we'll be providing those in Guix.

The first mitigations available in Guix are in the kernel.

We got the initial mitigation for Meltdown, Linux page table isolation
(KPTI), in linux-libre 4.14.11 on January 3:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=10db5e98ed7036e873060501462345c37fe2855c

Last night we got KPTI for the 4.4 and 4.9 kernel series, in 4.4.110 and
4.9.75, respectively. At the same time, we made 4.14.12 available, which
has some changes to KPTI in that kernel:

4.4.110:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=630437d94eeeae52586ab2362aa4273e0424cdf3
4.9.75:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f2462bc3662733801d7df7c532c1d8b0c67b3c18
4.14.12:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=af3f7f22f43fbbdca9bdc00afc476dd2ac86c017

The primary Linux stable kernel maintainer, Greg Kroah-Hartman, has more
details about these problems, what Linux is doing about them, and what
you can expect from them next:

http://kroah.com/log/blog/2018/01/06/meltdown-status/

The Spectre bugs have to be fixed per-application for now. As far as I
know, we haven't made any related changes to packages besides
linux-libre.

Mozilla has released an update that is supposed to mitigate the
vulnerability but I don't if they'll be porting it back to the extended
support release that Icecat is based on.


signature.asc
Description: PGP signature

core-updates warning: Not ready for GuixSD deployment

[Leo Famulari]

I recommend you do not reconfigure any systems that are important based
on the current core-updates branch.

After applying the proposed fix for GPM [0], I reconfigured my headless
GuixSD system using core-updates.

After rebooting, I found that my user's numerical ID had changed, so I
no longer owned any of my files. Not being able to read ~/.ssh means you
can't log in remotely.

Additionally, several of root's "dotfiles" had been replaced with their
default versions, erasing my modifications. For example,
~root/.bash_profile no longer contained my modifications.

Finally, my users's password no longer worked. I fixed this as root
before I noticed that my user's files were inaccessible; I don't know if
I could have avoided the password reset by re-chowning my files.

[0] 


signature.asc
Description: PGP signature

Re: libmagic license

[Leo Famulari]

On Wed, Jan 03, 2018 at 11:21:02PM +0100, Catonano wrote:
> Libmagic has a weird license
> 
> Is it suitable for Guix ?
> 
> Here it is
> https://github.com/threatstack/libmagic/blob/master/COPYING

Here is the license text:

--
$File: COPYING,v 1.1 2008/02/05 19:08:11 christos Exp $
Copyright (c) Ian F. Darwin 1986, 1987, 1989, 1990, 1991, 1992, 1994, 1995.
Software written by Ian F. Darwin and others;
maintained 1994- Christos Zoulas.

This software is not subject to any export provision of the United States
Department of Commerce, and may be exported to any country or planet.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice immediately at the beginning of the file, without modification,
   this list of conditions, and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
 
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
--

It's a common 2-clause BSD license. It also has a sentence claiming that
the software is not affected by some USA laws. I think this sentence is
meaningless without references to any relevant caselaw, and I think we
can ignore it, although I am not a lawyer.

BTW, this is a 3rd-party mirror of libmagic. The canonical source of
libmagic is in the 'file' package.


signature.asc
Description: PGP signature

Re: core-updates, let’s go!

[Leo Famulari]

On Wed, Jan 03, 2018 at 01:35:31PM -0500, Leo Famulari wrote:
> Libtiff failed the first build attempt when the upstream FTP server
> timed out. It has succeeded since then, but this will have caused a lot
> of dependent packages to fail.
> 
> Should I "Restart all dependency failed builds" now?

I went ahead and did this because it was too hard to failed packages
that did not fail due to the earlier libtiff problem.


signature.asc
Description: PGP signature

Re: 01/01: gnu: python-pygpgme: Use GnuPG 1 for the test suite.

[Leo Famulari]

On Wed, Dec 27, 2017 at 07:57:17PM -0500, Mark H Weaver wrote:
> Alas, your most recent changes seem to have now broken qgpgme:
> 
>   https://hydra.gnu.org/eval/109869#tabs-now-fail
>   https://hydra.gnu.org/job/gnu/master/qgpgme-1.9.0.x86_64-linux
>   https://hydra.gnu.org/job/gnu/master/qgpgme-1.9.0.i686-linux
>   https://hydra.gnu.org/job/gnu/master/qgpgme-1.9.0.armhf-linux

Okay, this should be fixed in commit 0684f1d6b522b9e54. Sorry for the
mess...


signature.asc
Description: PGP signature

Re: 01/01: gnu: python-pygpgme: Use GnuPG 1 for the test suite.

[Leo Famulari]

On Wed, Dec 27, 2017 at 07:57:17PM -0500, Mark H Weaver wrote:
> Alas, your most recent changes seem to have now broken qgpgme:
> 
>   https://hydra.gnu.org/eval/109869#tabs-now-fail
>   https://hydra.gnu.org/job/gnu/master/qgpgme-1.9.0.x86_64-linux
>   https://hydra.gnu.org/job/gnu/master/qgpgme-1.9.0.i686-linux
>   https://hydra.gnu.org/job/gnu/master/qgpgme-1.9.0.armhf-linux

Sigh... I didn't even know this package existed. I'll take a look.


signature.asc
Description: PGP signature

Re: [rhell...@mykolab.com: 02/02: gnu: mpv: Update to 0.28.0.]

[Leo Famulari]

On Wed, Dec 27, 2017 at 08:52:12PM +0100, Rutger Helling wrote:
> Hi Leo,
> 
> You can find the new features at:
> https://github.com/mpv-player/mpv/blob/master/RELEASE_NOTES
> 
> There are two reasons for me personally why I wanted to update:
> 1. The mpv developers only support the latest release.
> 2. The initial Vulkan support, which I've got working (x86_64 only for
> now). I can't merge it yet until core-updates is merged though.
> 
> I agree having three ffmpeg versions is undesirable. However, looking
> at the release notes ("This release needs recent FFmpeg (newer than
> 3.4) due to major refactoring.") this is hopefully a one-time thing.
> 
> When stable ffmpeg is updated we can get rid of the -git version. mpv is
> the only one using the -git version and it's been very solid for me, so
> I don't foresee problems there. Replacing ffmpeg@3.4.1 entirely with
> this -git version seems too extreme a solution to me.
> 
> Hopefully that explains my rationale a bit!

Okay, let's keep this mpv and FFmpeg. I'm always eager to update to the
latest releases of C-language programs that handle untrusted input, and
it sounds like the mpv team is moving on from mpv 0.27.0.

Personally I think it's bad practice for mpv to depend on some random
commit of FFmpeg, but that is mpv's choice.

In the future, please send patches that introduce unreleased versions of
widely used libraries like FFmpeg to guix-patches for review.

The packaging guidelines say, "We usually package only the latest
version of a given free software project." [0]

I interpret "latest version" to mean the latest version released in the
way that the upstream developers typically do their releases. For
FFmpeg, this is a tarball.

Thank you very much for taking the time to explain your rationale!

[0]
https://www.gnu.org/software/guix/manual/html_node/Version-Numbers.html


signature.asc
Description: PGP signature

[rhell...@mykolab.com: 02/02: gnu: mpv: Update to 0.28.0.]

[Leo Famulari]

Hi Rutger,

- Forwarded message from Rutger Helling  -

Date: Wed, 27 Dec 2017 04:52:26 -0500 (EST)
From: Rutger Helling 
To: guix-comm...@gnu.org
Subject: 02/02: gnu: mpv: Update to 0.28.0.

rhelling pushed a commit to branch master
in repository guix.

commit abc5ef5a7f7fecb99ca8213c0962f42cc1a65552
Author: Rutger Helling 
Date:   Wed Dec 27 10:46:26 2017 +0100

gnu: mpv: Update to 0.28.0.

* gnu/packages/video.scm (mpv): Update to 0.28.0.
[inputs]: Change ffmpeg to ffmpeg-git, add wayland-protocols.

-

As a frequent user of mpv, I also noticed that its latest release
requires this unreleased branch of FFmpeg (it will eventually be
released as FFmpeg 3.5).

I wonder, does mpv 0.28.0 bring some new features that make it worth it
to build three copies of FFmpeg? There was already ffmpeg-2.8 and
ffmpeg@3.4.1 (the latest upstream release). And, do we know if this copy
of FFmpeg is ready to be deployed?

If I remember correctly, FFmpeg is pretty expensive to build from
source. But maybe it's no big deal, or the new features are worth it. Or
maybe we should replace ffmpeg@3.4.1 with this unreleased development
branch.


signature.asc
Description: PGP signature

Re: 01/01: gnu: python-pygpgme: Use GnuPG 1 for the test suite.

[Leo Famulari]

On Tue, Dec 26, 2017 at 07:11:13PM -0500, Mark H Weaver wrote:
> > Author: Leo Famulari <l...@famulari.name>
> > Date:   Wed Dec 20 03:20:01 2017 -0500
> > 
> > gnu: gpgme: Build with the latest GnuPG.
> > 
> > * gnu/packages/gnupg.scm (gpgme)[inputs]: Use the latest gnupg package.
> > [arguments]: Keep a reference to the gnupg package used for build.
> 
> Clearly you were aware that python-pygpgme needed adjustment to continue
> building, and I appreciate your attention to detail here, but something
> seems to have gone wrong.  Since these commits, Hydra has failed to
> build python-pygpgme and python2-pygpgme on all hydra-supported systems:

Thank you for bringing this to my attention.

It's a consequence of having configured GPGME with --enable-fixed-path,
which in our case forces GPGME to use the GnuPG executable it was built
with. [0]

I made this change rather late in the development of these patches,
after having tested them more fully.

Since we previously let GPGME find GnuPG in the environment, and that
worked fine, I'll revert that part of the change shortly.

[0] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29781#25


signature.asc
Description: PGP signature

Re: 02/02: gnu: python-pillow: Update to 4.3.0.

[Leo Famulari]

On Sun, Dec 24, 2017 at 06:16:29PM -0500, Kei Kebreau wrote:
> I've attempted to use the upstream patch, but it involves some GIT
> binaries which aren't supported by GNU patch. Among other hackish
> options, temporarily upgrading to the appropriate upstream commit may
> fix this for now.

Does it work if you pass '--binary' to patch-flags?


signature.asc
Description: PGP signature

Re: Removing configure option for Gnuastro 0.5

[Leo Famulari]

On Sun, Dec 24, 2017 at 08:53:28PM +0100, Mohammad Akhlaghi wrote:
> Hi Leo,
> 
> Thanks a lot of applying the configuration change.
> 
> 
> On December 24, 2017 8:28:43 PM GMT+01:00, Leo Famulari <l...@famulari.name> 
> wrote:
> 
> >I notice our package is using libjpeg-8, while we also have libjpeg-9
> >available. Gnuastro seems to build fine with libjpeg-9, but I don't
> >know
> >how to actually test it. Do you know if we can use libjpeg-9 for our
> >Gnuastro packaging?
> 
> There shouldn't be any problem with libjpeg-9. 
> 
> Several tests of libjpeg are made during "make check". So if nothing fails 
> there, then Gnuastro has used libjpeg-9 properly. Maybe this is the simplest 
> test.

Okay, thanks for the info.

I've updated our package with commit
09c9fe4a77e93949cdb51ff0be330650aa1a0486:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=09c9fe4a77e93949cdb51ff0be330650aa1a0486


signature.asc
Description: PGP signature

Re: Removing configure option for Gnuastro 0.5

[Leo Famulari]

On Sat, Dec 23, 2017 at 04:37:51PM +0100, Mohammad Akhlaghi wrote:
> Dear Guix developers,
> 
> This is Mohammad Akhlaghi, the maintainer of GNU Astronomy Utilities.
> 
> Gnuastro 0.5 was just released and since it is also packaged in Guix, I
> wanted to let you know that the `--enable-bin-op-alltypes' configure time
> option is now removed (it was added with the 0.3 release).
> 
> You kindly added this configure time option after my request in June 2017
> (link below). I now found a good way to solve the problem, so this option is
> also removed.
> 
> http://lists.gnu.org/archive/html/guix-devel/2017-06/msg00172.html

Thanks for the reminder!

I notice our package is using libjpeg-8, while we also have libjpeg-9
available. Gnuastro seems to build fine with libjpeg-9, but I don't know
how to actually test it. Do you know if we can use libjpeg-9 for our
Gnuastro packaging?


signature.asc
Description: PGP signature

Re: Seeding the Linux RNG at first boot

[Leo Famulari]

On Mon, Dec 11, 2017 at 10:16:42AM +0100, Ludovic Courtès wrote:
> Leo Famulari <l...@famulari.name> skribis:
> > At the same time we handle the random seed, we could also try reading
> > from /dev/hwrng and, if the read is successful, copy some bytes into
> > /dev/urandom. We'd have to try reading and handle failure since we
> > always create /dev/hwrng regardless of whether the Linux kernel module
> > is loaded or not.
> 
> OK.

Okay, I'll work on adding this to the urandom-seed-service.

> > If one always passes the same value to --entropy-seed, it will not
> > negatively affect the reproducibility of the image ;)
> >
> > This would not be something we do for the official release image, but
> > merely an optional tool.
> 
> Yeah it’d be OK to add this as an option.
> 
> When the option is present, ‘guix system’ would hook into the VM
> creation code somehow, or to extend ‘activation-service-type’ with code
> to create the file.
> 
> Maybe we could provide a more generic --copy-file=SOURCE[=DEST] option?
> Like --copy-file=./my-seed=/var/lib/random-seed or
> --copy-file=$HOME/.ssh/authorized_keys.
> 
> Thoughts?

That sounds good to me. I'll try implementing it.


signature.asc
Description: PGP signature

Re: Seeding the Linux RNG at first boot

[Leo Famulari]

On Thu, Dec 07, 2017 at 10:07:38PM +0100, Ludovic Courtès wrote:
> Leo Famulari <l...@famulari.name> skribis:
> > On the guest side, we would extend urandom-seed-service to also draw on
> > /dev/hwrng, which is where virtio-rng-pci makes the data from the host
> > available.
> 
> Maybe ‘virtualized-operating-system’ in (gnu system vm) could
> automatically customize ‘rngd-service-type’ (or add it)?

Yes, we could do that, although I don't think it's necessary to run a
daemon continuously. It is enough to seed the RNG once.

At the same time we handle the random seed, we could also try reading
from /dev/hwrng and, if the read is successful, copy some bytes into
/dev/urandom. We'd have to try reading and handle failure since we
always create /dev/hwrng regardless of whether the Linux kernel module
is loaded or not.

> > I have an idea for another improvement: to add an argument like
> > "--entropy-seed=" to `guix system` that could place the value in
> > '/var/lib/random-seed', where it would be used on first boot.
> 
> We could do that, though I very much prefer the idea of a “backdoor” à
> la virtio-rng-pci, because it allows to stick to bit-reproducible images
> (well, they’re not bit-reproducible yet I suppose, but let’s not add to
> it.)

I think it would be most useful for disk images, for which there is no
host.

If one always passes the same value to --entropy-seed, it will not
negatively affect the reproducibility of the image ;)

This would not be something we do for the official release image, but
merely an optional tool.


signature.asc
Description: PGP signature

Seeding the Linux RNG at first boot

[Leo Famulari]

On Wed, Dec 06, 2017 at 12:11:36AM +0100, Marius Bakke wrote:
> FWIW if you control the hypervisor, you can send something along the
> lines of:
> 
> qemu -device virtio-rng-pci,bus=pci.0,addr=0x1e,max-bytes=1024,period=1000
> 
> to feed the guest with entropy from the host through virtio, up to 1kB/s.

Exactly, this is along the lines of what I'm thinking for `guix system
vm`.

On the guest side, we would extend urandom-seed-service to also draw on
/dev/hwrng, which is where virtio-rng-pci makes the data from the host
available.

Currently there is the rngd-service-type, but that is doing something
slightly different. Using /dev/hwrng to seed urandom could be done
whenever it's enabled in the kernel.

I have an idea for another improvement: to add an argument like
"--entropy-seed=" to `guix system` that could place the value in
'/var/lib/random-seed', where it would be used on first boot.

Thoughts?


signature.asc
Description: PGP signature

Re: native-inputs ending up as run-time references [was: ISO image available for testing!]

[Leo Famulari]

On Wed, Dec 06, 2017 at 03:16:45AM +0100, Tobias Geerinckx-Rice wrote:
> Hold on. I thought this happened *all the actual time*.
> 
> To me, the output of ‘guix graph’ implies that ghc[*] refers directly to
> perl, and ghc-haddock-library to hspec-discover, and that both of those
> are native inputs.
> 
> These are just the first two examples of packages with native inputs
> that I happened to pull out of my haskell.scm. While Haskell does seem
> particularly naughty, I've no reason to believe it's unique.
> 
> Are these not ‘run-time references’? Is your use of the term narrower
> than mine?

I think of "run-time references" as explicit store references
(file-names) found in the build output by the post-build reference
scanner and recorded in /var/guix/db. These references are what grafting
rewrites.

`guix gc --references` can be used to query the database for a given
store item.

`guix graph`, on the other hand, shows the graphs of package
definitions. That is, the list of inputs, native-inputs,
propagated-inputs, etc. Some of these inputs could be totally
superfluous, and the build output would ideally not contain any
explicit references to them at all.

The term "reference" has a few meanings in Guix, but I think that Mark
is talking about explicit store paths.


signature.asc
Description: PGP signature

Re: Reducing default verbosity

[Leo Famulari]

On Tue, Dec 05, 2017 at 02:33:01PM +0100, Ricardo Wurmus wrote:
> * Redirect all build output to log files; as we can’t generally estimate
>   progress I’d use a spinner and maybe display the name of the current
>   build phase and the number of build phases that are left.
> 
>   Building openldap-2.4.45 (2/6)  [‐->---]
>   Building openldap-2.4.45 (2/6)  [‐-->--]
>   Building openldap-2.4.45 (3/6)  [‐--->-]
>   Building openldap-2.4.45 (4/6)  [‐-<---]
>   Building openldap-2.4.45 (4/6)  [-<]
> 
>   There are some pretty single character unicode spinners here:
> https://github.com/pmonks/spinner/blob/master/src/spinner/core.clj

Overall I like your suggestions.

I'd prefer to keep the full build output as the default of `guix build`,
and maybe `guix environment`.


signature.asc
Description: PGP signature

Re: java: switch to icedtea-8 as default JDK

[Leo Famulari]

On Mon, Dec 04, 2017 at 04:44:00PM +0100, Gábor Boskovits wrote:
> Now that this problem around glibc is resolved, I think I will do some
> history rewrite, so that these reverts, reverting the revert does not
> show up.
> I 'm also willing to rename the branch to have wip in the name, as this
> seems to be standard for longer runnig parts. WDYT?

In general, we don't rewrite history of any public branches on our
Savannah instance, except for branches whose name starts with "wip-".
That, is "work in progress".

But of course we can all follow our own rules on our own Git servers :)


signature.asc
Description: PGP signature

Re: A few thing we might consider hosting

[Leo Famulari]

On Sun, Dec 03, 2017 at 08:21:35AM +0100, Gábor Boskovits wrote:
> I was aware of the discussion thread, however I could not find out what the
> current state is? Do we plan to modify this behaviour in the next release?

I think the current state is "awaiting feedback" :)

Re: A few thing we might consider hosting

[Leo Famulari]

On Sat, Dec 02, 2017 at 05:28:51PM +0100, Gábor Boskovits wrote:
> Sometimes while working in guix I run into problems because:
> 1. a tarball was removed or modified upstream
> 
> It would be great to have the ability to install the latest release in all
> the supported ways on all supported architectures, and have the ability do
> guix pull without problems.
> Last time I tried that it did not worked, because one of the upstream
> linux-libre tarballs was removed. It would be nice if we could afford to
> host the sources, so that at lesat a bare-bones guixsd suffered no such
> problems.

We actually do host the sources, but Guix usually tries fetching them
from upstream first, which can be annoying. We are discussing this here:



> 2. some packages take very long time to build (notably guile)
> 
> It would be nice, if we could provide the substitutes that the current
> core-updates gnu-build-system needs. That would make development that needs
> to be done on core-updates much more pleasant to those who are working in a
> restricted hardware environment.

We use the core-updates branch like this:

1) For a couple months we just push changes to core packages to the
branch without worrying about if it works or not.
2) After some time, we try building the branch and fix everything that
is broken. Once that is done, we merge it into the master branch, which
is what `guix pull` uses by default.

So, for most of the life of a core-updates branch, it's likely that no
packages will be buildable, and thus we don't even try, so there are no
substitutes.

Once we start building it, substitutes are available in the normal way.


signature.asc
Description: PGP signature

Re: Release!

[Leo Famulari]

On Thu, Nov 30, 2017 at 11:40:16AM +0100, Ludovic Courtès wrote:
>   1. Do we pre-register berlin’s key on GuixSD?

I vote yes.

>   2. Do we add berlin.guixsd.org to the list of substitute servers on
>  GuixSD?  On Guix?  The drawback is that ‘guix’ sometimes talks to
>  both servers when retrieve substitute lists, which can be slightly
>  slower/annoying, but otherwise I think it’s a win.

I think it's worth the extra source of substitutes. Since adding
berlin.guixsd.org to my list of substitute URLs, it seems like I need to
build less often.

In my experience, it's annoying to query multiple servers when my
network connection is slow or unreliable. But, it's also annoying in
that situation to need to download source files from a variety of
upstream sites.

> The main GuixSD annoying messages that I think we should address by
> Tuesday are:
> 
>   1. “Error in finalization thread: Bad file descriptor” coming from the
>  Shepherd;

I'm not sure how to start debugging this :/ If I get some advice, I
could try to fix it on Sunday and Monday.

>   2. “udevd[304]: RUN{builtin}: 'uaccess' unknown 
> /gnu/store/q7c8yayywf76ai3sgvz16pmbz07gj4bp-udev-rules/lib/udev/rules.d/73-seat-late.rules:15”

I haven't seen this one before.


signature.asc
Description: PGP signature

Re: Idea: Install script to better support improving contributor-friendliness of projects

[Leo Famulari]

On Tue, Nov 28, 2017 at 10:43:49PM +0300, lamefun@gmail.com wrote:
> Another question, is Guix ever going to ship NVIDIA OpenGL libraries,
> considering that this is a GNU project? Flatpak for example ships them
> to support NVIDIA GPUs. The project I want to make contributor-friendly 
> with help of Guix is a 3D game, so without them Guix is essentially
> useless as a dependency installer for many of the potential
> contributors.

Are those libraries free software?

If not, no, we'll never include them in GNU Guix.

But Guix is free software, which means one can use it however they like.
So there is nothing stopping someone from packaging nonfree software and
distributing the packages on their own.


signature.asc
Description: PGP signature

Re: [PATCH] scripts: hash: Add --git option. WIP

[Leo Famulari]

On Tue, Nov 28, 2017 at 07:57:32PM +0100, Jan Nieuwenhuizen wrote:
> Andy Wingo writes:
> > Weird that we have done the same thing :)
> >
> > https://git.savannah.gnu.org/gitweb/?p=guix.git;a=commit;h=572907daff98a77a4215861a88b81d2f30542c09
> 
> :-) Nice!...on what branch is that?  You did see Ludo's suggestions?  I like
> them and planned to look at them when my mind is less occupied with
> bootstrapping.

I wasn't sure how to figure this out, so here's how to do it:

$ git branch --remote --contains 572907daff98a77a4215861a88b81d2f30
  origin/wip-potluck


signature.asc
Description: PGP signature

Re: 01/02: gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, CVE-2017-2736].

[Leo Famulari]

On Thu, Nov 02, 2017 at 05:22:34PM -0400, Marius Bakke wrote:
> commit 1df4f5c919937b60bfb21ac2a60d8f0a6737c421
> Author: Marius Bakke 
> Date:   Thu Nov 2 22:11:25 2017 +0100
> 
> gnu: openssl@1.0: Replace with 1.0.2m [fixes CVE-2017-3735, 
> CVE-2017-2736].
> 
> * gnu/packages/tls.scm (openssl)[replacement]: New field.
> (openssl-1.0.2m): New public variable.

[...]

> +;; Fixes CVE-2017-3735 and CVE-2017-3736.
> +;; See .
> +(define-public openssl-1.0.2m

In the early days of recursive grafts, Mark replaced libgcrypt with a
public variable, and it was resolved non-deterministically. We ended up
having to make the replacement private:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=69aa6e0995b55a38d5ce174602a107645be726d5

I remember doing something like this and getting different results
randomly:

$ while true; do guix build --source openssl@1.0.2 ;done
guix build: warning: ambiguous package specification `openssl@1.0.2'
guix build: warning: choosing openssl@1.0.2m from gnu/packages/tls.scm:402:2
/gnu/store/3hsffv38zzn3pafzr3g4x6mwqmxcmnr5-openssl-1.0.2m.tar.xz
[...]

But now it seems to consistently pick the correct package.

Did the implementation change to ensure that it does the right thing?


signature.asc
Description: PGP signature

Re: Problems with setting up prosody with IPv6 and certbot

[Leo Famulari]

On Sun, Nov 26, 2017 at 04:26:08PM +0100, nee wrote:
> Hello, I've been trying to setup the prosody xmpp service a few weeks
> ago, but a some things are not working out of the box.

This is a great write-up!

Can I ask you to send each problem to  separately? It
seems like the problems are unrelated to each other, and we are less
likely to lose track of things if we use the bug tracker.


signature.asc
Description: PGP signature

SECURITY: Exim CVE-2017-16943

[Leo Famulari]

Hello!

--
commit 5b327a2d6192adbabb5b98bc3a78eb8402bd6d1d
Author: Leo Famulari <l...@famulari.name>
Date:   Sun Nov 26 15:23:13 2017 -0500

gnu: exim: Fix CVE-2017-16943.

* gnu/packages/patches/exim-CVE-2017-16943.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/mail.scm (exim)[source]: Use it.
--

This commit fixes a bug in Exim that allows attackers to gain remote
code execution on your server. If you are using Exim from the Guix
package, please update it as soon as possible.

For more information:

https://bugs.exim.org/show_bug.cgi?id=2199
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16943


signature.asc
Description: PGP signature

Re: Please write "Update to " instead of "Update snapshot"

[Leo Famulari]

On Sat, Nov 25, 2017 at 07:43:11PM -0500, Mark H Weaver wrote:
> In my opinion, the version number is a very useful piece of information
> to see for update commits when browsing the commit history.  I regard
> the practice of omitting the version number to be a slowly creeping
> regression in our otherwise exceptionally good conventions for commit
> logs.  I humbly propose that we nip this regression in the bud.

I agree that the commit message should always include the new version of
the package being updated.


signature.asc
Description: PGP signature

Re: 01/01: gnu: audacity: Update to 2.2.0.

[Leo Famulari]

On Sat, Nov 18, 2017 at 08:38:54PM +0100, Pjotr Prins wrote:
> On Sat, Nov 18, 2017 at 10:42:48AM -0500, Leo Famulari wrote:
> > On Debian, the graphical user interface is broken for me (overlapping
> > and blank elements), and it crashes when opening a file, with
> > "(audacity:21456): GLib-GIO-ERROR **: Settings schema
> > 'org.gtk.Settings.FileChooser' is not installed".
> 
> that looks very familiar. Try
> 
>   env XDG_DATA_DIRS=/usr/local/share:/usr/share audacity

Thanks, that fixed the crash. Now I remember all the similar problems
with XDG_DATA_DIRS. It seems to be affecting lots of applications based
on GTK+3.


signature.asc
Description: PGP signature

Re: 01/01: gnu: audacity: Update to 2.2.0.

[Leo Famulari]

On Sat, Nov 18, 2017 at 10:08:20AM -0500, Ricardo Wurmus wrote:
> rekado pushed a commit to branch master
> in repository guix.
> 
> commit 3182a1d2f1f63bcc0840bf0c98e54a7037281163
> Author: Ricardo Wurmus 
> Date:   Sat Nov 18 14:49:29 2017 +0100
> 
> gnu: audacity: Update to 2.2.0.
> 
> * gnu/packages/patches/audacity-build-with-system-portaudio.patch: New 
> file.
> * gnu/local.mk (dist_patch_DATA): Add it.
> * gnu/packages/audio.scm (audacity): Update to 2.2.0.
> [source]: Add patch to build with system portaudio; add snippet to remove 
> most
> bundled libraries.
> [inputs]: Replace "gtk+-2" with "gtk+", replace "wxwidgets-gtk2" with
> "wxwidgets"; remove "libsbsms"; add "suil" and "portmidi".
> [arguments]: Adjust configure flags to avoid using bundled libraries; 
> remove
> phase "autoreconf"; add phases "fix-sbsms-check" and 
> "use-upstream-headers".

Is anyone else having problems with this new version of Audacity?

On Debian, the graphical user interface is broken for me (overlapping
and blank elements), and it crashes when opening a file, with
"(audacity:21456): GLib-GIO-ERROR **: Settings schema
'org.gtk.Settings.FileChooser' is not installed".


signature.asc
Description: PGP signature

Re: Is anyone opposed to GnuTLS with DANE by default?

[Leo Famulari]

On Tue, Nov 14, 2017 at 08:22:54PM +0100, Tobias Geerinckx-Rice wrote:
> ng0,
> 
> What a coincidence! I was slogging through some very old mail, had just
> read your original gnutls/dane message, and was about to post the very
> same question. Then I ran ‘guix size’.
> 
> ng0 wrote on 14/11/17 at 19:54:
> > If no one is opposed to this change, I will
> > prepare a patch tomorrow.
> 
> I certainly don't object, but am forced to note that ’gnutls-dane’ more
> than doubles the closure size of ‘gnutls’ proper (294.2 MiB vs. 138.5).
> 
> The only new input is ‘unbound’, but that manages to pull in both
> Pythons 2 and 3. It would be nice™ if it could first be -minimalised...

I have no opinion about DANE, but if this brings unbound into the GnuTLS
closure, we should make sure we can build it reliably. So far this is
not the case on Hydra (not sure about Berlin):

https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00182.html
https://hydra.gnu.org/job/gnu/master/unbound-1.6.3.x86_64-linux
https://hydra.gnu.org/job/gnu/master/unbound-1.6.7.x86_64-linux

Also, it would be a bit of a shame to make GnuTLS depend on Python, thus
making it depend on OpenSSL ;)


signature.asc
Description: PGP signature

Re: Let's build 'core-updates'!

[Leo Famulari]

To clarify, I haven't built anything on core-updates yet, so I don't know if 
this will fail on x86_64. I'm still cherry picking things to master in order to 
test.

Sorry for top-posting


 Original Message 
From: Efraim Flashner <efr...@flashner.co.il>
Sent: November 7, 2017 6:05:19 AM EST
To: l...@gnu.org
Cc: Leo Famulari <l...@famulari.name>, guix-devel@gnu.org
Subject: Re: Let's build 'core-updates'!

No one else mentioned it after the acl tests were enabled

On November 7, 2017 11:54:47 AM GMT+02:00, l...@gnu.org wrote:
>Efraim Flashner <efr...@flashner.co.il> skribis:
>
>> /gnu/store/mivyzxijvxh44g2r39071sm89vm9h0n6-make-boot0-4.2.1/bin/make
>-C test/ tests
>> make[1]: Entering directory
>'/tmp/guix-build-acl-2.2.52.drv-0/acl-2.2.52/test'
>> *** malformed-restore.test ***
>> Unescaped left brace in regex is illegal here in regex; marked by <--
>HERE in m/%{ <-- HERE (\w+)}/ at run line 73.
>> make[1]: *** [Makefile:39: malformed-restore.test] Error 255
>> make[1]: Leaving directory
>'/tmp/guix-build-acl-2.2.52.drv-0/acl-2.2.52/test'
>
>This looks like the new regex syntax issue introduced on the last Perl
>update we made, no?  Is it really aarch64-specific?
>
>Ludo’.

Re: The usability of Guix configurations

[Leo Famulari]

On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
> My system recently broke when I did an upgrade. I reported what I
> thought was a bug (bug#29072) but it turned out that, because qemu
> package code had been moved, my system configuration had become broken
> ;-(
> 
> Confronted with my situation, helpful developers said "The package code
> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
> config (Efraim)."

I'm sorry that my comment was not enough on its own!

> Once I understood what had happened I wondered, "Gee, I have been using
> guix for 18 months so why didn't I figure this out myself." ;-)
> 
> But a less committed user might say, "Wow, Guix breaks at random, error
> messages are hard to understand, and support is difficult."  :-(

Good point.

> ISTM this raises issues and questions about Guix configuration
> usability:

Indeed.

> Guix config errors are reported as raw scheme errors which are not
> user-friendly, except, perhaps, to guile users ;-) Could we improve this
> situation by adding config troubleshooting guidance to the doc?

Yes, we do try to add helpful error messages, although obviously there
is a lot more work to be done.

As far as I can tell, the issue was related to the fact that you are
using Guix by building it from source and re-using the same build
directory, which may contain stale compiled .go files. In this case,
there was a leftover qemu.go, which shadowed the correct file,
virtualization.go.

This is a useful development technique but not how Guix is supposed to
be deployed and updated. `guix pull && guix package --upgrade` is still
what we recommend and support.

If you want to deploy Guix by building it "by hand", I recommend using a
fresh Git checkout and directory each time you build it. That way, you
can be sure to avoid this class of error (stale module references in
leftover .go files), which is well-known to the seasoned Guix developers
but totally confounding for everyone else.

> Guix config errors consume meaningful amounts of user and support
> effort. I say this because a) it took quite a few iterations to figure
> out what was wrong in my situation, and b) google search for '"no code
> for module" guix' finds 613 hits, which will no doubt grow linearly with
> number of Guix users unless something is done. So I wonder, could an
> error handler that translates into more user-friendly terms reduce user
> frustration, increase the rate of user self help, reduce support load,
> and effectively pay for itself?

That would be awesome!

> Are the current Guix config errors usable by the average GNU/Linux
> distribution user? If not, don't they need to be improved before we call
> it 1.0?

Based on how much time it's possible to spend on IRC helping people, I'd
say there is lots of room for improvement in this area.

> Does this mean that package code must not be moved after 1.0?

A couple thoughts... it would be nice if the GuixSD configuration
example templates used a filename agnostic method of resolving module
imports. I'm not a strong enough Schemer to evaluate the situation or
suggest a solution, but I think that the filenames should not be
relevant at that level. Perhaps one could use
'specification->package+output',
as demonstrated in the documentation of package manifests:

https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html

> Finally: Should I close bug#29072? ;-)

The problem of the missing QEMU patch is resolved. The broader issue of
confusing error messages could be continued here, or elsewhere. It's up
to you :)


signature.asc
Description: PGP signature

Re: Can't download signing key for Guix 0.13.0

[Leo Famulari]

On Mon, Nov 06, 2017 at 10:26:40AM +0100, oge wrote:
> Hi all,
> 
> I'm starting out with Guix but for some reason I can't download the public
> key to verify the Guix 0.13.0 download.
> 
> The following command (from
> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html)
> failed:
> 
> $ gpg --keyserver pgp.mit.edu --recv-keys
> 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

The canonical source of Guix-related PGP keys is the membership list of
our project's page on Savannah:

https://savannah.gnu.org/projects/guix

That particular key belongs to Ludovic Courtès:

https://savannah.gnu.org/users/civodul


signature.asc
Description: PGP signature

Re: Let's build 'core-updates'!

[Leo Famulari]

On Thu, Nov 02, 2017 at 11:29:17PM +0200, Efraim Flashner wrote:
> On Thu, Nov 02, 2017 at 09:33:02PM +0100, Marius Bakke wrote:
> > We are still missing the "binutils" update.  Efraim, do you remember
> > what the issue with 2.29 was?
> 
> binutils-boot0 built fine, I don't remember what the next -boot0 package
> was, but it failed completely so I reverted it. I was also worried about
> all the CVEs showing up, and the couple that I checked didn't affect
> 2.28.1.

There are many recent bug disclosures in binutils that I have not paid
attention to. We should try to get them fixed in this cycle.

> > Is there anything else we should consider this round?  Maybe the
> > automatic wrapping from ?

Sounds good.

> We should update cmake. It would also be nice if we could get rid of
> some of libjpeg-8 and other similar older versions, but that's something
> that can wait for the next round if need be. We've already added the
> python update branch in, so we should make sure to update the packages
> like pytest to only have the later version. If we have any more packages
> without modify-phases that can be taken care of also.

Sounds good.

Does anyone volunteer to handle some of those tasks?

> I'm currently building out to gtk+ and gtk+@2 on aarch64 to see how
> everything goes.

Efraim, I saw you had issues with net-tools-for-tests. Can you give more
detail?


signature.asc
Description: PGP signature

Removing a store reference from a file

[Leo Famulari]

I noticed that Go executables built with the go-build-system keep an
unnecessary reference to Go itself:

$ guix gc --references $(realpath $(which syncthing))
/gnu/store/3h31zsqxjjg52da5gp3qmhkh4x8klhah-glibc-2.25
/gnu/store/bqlmgk6ngyi4pivnqpxma2wr5pj5mhkk-gcc-5.4.0-lib
/gnu/store/bzj472nmnnj5hcfd5yvfiqip1wzw84p9-tzdata-2017b
/gnu/store/qydgxm0sipn4bn5122a3zxiz1bz0vvnw-go-1.9.2
/gnu/store/z1lii251cy0y660910hsfc55cy82dk9i-net-base-5.3

The programs don't need or use this reference, so it would be nice to
get rid of it and save users some bandwidth when installing Go programs.

I'm still figuring out the best way to approach this issue (Go compiler
flags?), but here is some research.

In Nixpkgs, there is a switch to disallow this reference specifically:

--
# Do not enable this without good reason
# IE: programs coupled with the compiler
, allowGoReference ? false
--
https://github.com/NixOS/nixpkgs/blob/39cd40f7bea40116ecb756d46a687bfd0d2e550e/pkgs/development/go-modules/generic/default.nix#L29

... and it ends in a call to a general-purpose shell script,
remove-references-to, which uses sed to remove specific references:

https://github.com/NixOS/nixpkgs/blob/39cd40f7bea40116ecb756d46a687bfd0d2e550e/pkgs/build-support/remove-references-to/default.nix

I see that in Guix we have ((guix build utils) remove-store-references),
which removes *all* store references from a file, but using it here
leaves the Go executable unable to even start execution. I think it
needs libc's linker:

--
% strace -s1000 -f ./syncthing 
execve("./syncthing", ["./syncthing"], [/* 42 vars */]) = -1 ENOENT (No such 
file or directory)
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 3), ...}) = 0
write(2, "strace: exec: No such file or directory\n", 40strace: exec: No such 
file or directory
) = 40
getpid()= 5493
exit_group(1)   = ?
+++ exited with 1 +++
--


signature.asc
Description: PGP signature

Re: POWER Support

[Leo Famulari]

On Wed, Oct 25, 2017 at 03:47:19PM +0200, oury.dus...@tutanota.com wrote:
> Are there plans to support POWER 8-9 systems for the GUIX package
> manager and GUIXSD? I had read about TALOS and was just curious about
> that support being worked on.

I haven't heard of anyone working on it, but we have documentation about
porting Guix to a new platform:

https://www.gnu.org/software/guix/manual/html_node/Porting.html

[...]

> > You must know your password to change your options (including changing
> > the password, itself) or to unsubscribe without confirmation.  It is:
> >
> >   > http://releases.ubuntu.com/16.04.3/ubuntu-16.04.3-desktop-amd64.iso

You may want to change this password.


signature.asc
Description: PGP signature

Re: Expat in GuixSD, please update

[Leo Famulari]

On Wed, Oct 25, 2017 at 07:29:28PM +0200, Tobias Geerinckx-Rice wrote:
> Leo Famulari wrote on 25/10/17 at 19:22:
> > Expat 2.2.3's release notes only mentioned CVE-2017-11742, which is a
> > Windows vulnerability and out of scope for Guix. And I didn't see
> > security issues disclosed in the 2.2.4 release notes.
> 
> Ah, sorry to spread misinfo. I don't have Web access at the moment and
> erred on the side of caution. I'll adjust the patch accordingly & push.

I think we can still mention that we've fixed that bug. Somebody could
still use Guix as a source of free source code even if they were
developing for Windows.

No big deal either way, IMO.


signature.asc
Description: PGP signature

Re: Expat in GuixSD, please update

[Leo Famulari]

On Wed, Oct 25, 2017 at 02:58:13PM +0200, Sebastian Pipping wrote:
> Hi GuixSD team,
> 
> 
> from looking at [1] and [2] my impression is that GuixSD is still at
> version 2.2.2 with Expat, while there is version 2.2.4 with bugfixes
> upstream.  Is there anything blocking an update on your side that needs
> fixing upstream?

Thank you very much for reaching out, Sebastian.

No, there is nothing concrete blocking the update. I've just given
Tobias a "LGTM" for his 2.2.4 update patch.

There is a slight cost to updating packages with many dependents in Guix
[0], so we prefer not to update them between "core update" cycles unless
there are security issues affecting our users.

Expat 2.2.3's release notes only mentioned CVE-2017-11742, which is a
Windows vulnerability and out of scope for Guix. And I didn't see
security issues disclosed in the 2.2.4 release notes.

But, we can treat Expat as one of those "always update" libraries if
that is suggested. It's probably the right choice for any widely-used C
library.

[0] By treating package building as a pure function, if a lower-level
package changes, all dependent packages must be rebuilt. We have a
mechanism called grafting to cheat for security updates.


signature.asc
Description: PGP signature

Re: speed of qemu vms

[Leo Famulari]

On Tue, Oct 24, 2017 at 09:30:06PM +0200, Hartmut Goebel wrote:
> Hello,
> 
> for testing I used to build VM using "guix system vm …" and the machines
> are, well, reacting slowly:
> 
> Plasma start up: 80 sec.
> 
> Menu: 36 sec
> 
> When I tried a Vm created with "guix system vm-image …" the machine is
> much quicker:
> 
> Plasma start up:  25 sec.
> 
> Menu: immediately.
> 
> This is a huge contrast, so I wonder what is the reason for this. Any
> ideas? And any ideas how to speed up the first variant?

The two methods are pretty different "under the hood".

`guix system vm` shares the store with the host machine using virtio. By
default, only 256 MB of RAM is allocated for the system. I recommend
inspecting the script that is created by `guix system vm` to see what it
does.

`guix system vm-image`, on the other hand, is a full virtual machine
image, with its own store.

It's hard to give specific feedback without more information about the
host machine(s) and other details of the environment.


signature.asc
Description: PGP signature

Re: Our package names should not include "github-com"

[Leo Famulari]

On Mon, Oct 16, 2017 at 05:38:43PM -0400, Leo Famulari wrote:
> Using the domain name as part of the *upstream* library name is useful
> for upstream authors because of how Go's built-in dependency management
> tools work. Go integrates dependency management into the language and
> the `go` tool itself. Re-using the upstream library name is useful
> because they have already disambiguated for us.
> 
> I don't intend to be rude, but I'm not going to put much effort into
> responding to further comments that are not based on knowledge of how Go
> handles package / dependency management with its built-in tools, or
> modular programming in Go, in general. Already I used tons of my free
> time to learn this stuff, just so I could make Guix packages of Go
> software. Please meet me where I am.
> 
> Again, I don't see an ethical problem here, so any motivation for me to
> participate in this discussion, as a volunteer, must be technical. If
> it's *wrong* to name the packages in this way, I will behave
> differently.

I replied too harshly here, and I apologize for that. For me, this
conversation really started on the wrong foot.


signature.asc
Description: PGP signature

Re: 01/04: gnu: mesa: Disable imx driver for armhf-linux.

[Leo Famulari]

On Mon, Oct 16, 2017 at 02:56:38PM +0200, Ludovic Courtès wrote:
> From the maintainer’s viewpoint, it just stresses that we must keep
> going with the efforts to improve our build infrastructure.  Currently
> that has only benefited x86, but perhaps now is a good time to plug our
> ARM boxes behind berlin.guixsd.org, for a start.
> 
> Thoughts?

What sort of interface do we have for querying berlin.guixsd.org's
evalutions (to borrow the Hydra term)?

Is it just `guix weather`, or is there some sort of historical
continuous integration view as with the Hydra interface?

For all the frustrations with Hydra, it's still invaluable to be able to
compare evaluations and look at things like "newly failing jobs", and to
share hyperlinks with each other.


signature.asc
Description: PGP signature

Re: 01/04: gnu: mesa: Disable imx driver for armhf-linux.

[Leo Famulari]

On Fri, Oct 13, 2017 at 08:38:13PM -0400, Mark H Weaver wrote:
> Do you think it should be acceptable to merge a major branch into
> 'master' where *all* graphical packages are broken on armhf?

I think we all agree that we should not do this.

As somebody who also works on merging these branches, I'd like to point
out that the continuous integration process for armhf is difficult to
use effectively.

The core of the problem is that the feedback loop for armhf is
unreliable and slow.

Similar problems exist with Hydra for x86_64 and i686, but they are
mitigated because most of us have access to our own x86_64 machines
where we can test changes quickly before asking Hydra to verify a
positive result.

It would be great to have access to an armhf machine where we could do
the same thing, testing changes directly without going through Hydra.

Maybe if one has a fast enough x86_64 computer, they could virtualize an
armhf test machine.


signature.asc
Description: PGP signature

Re: Our package names should not include "github-com"

[Leo Famulari]

On Fri, Oct 13, 2017 at 01:12:32PM -0400, Mark H Weaver wrote:
> l...@famulari.name (Leo Famulari) writes:
> > gnu: Add go-github-com-templexxx-reedsolomon.
> 
> On this, and a great many other packages, you've included "github-com-"
> in the package names.  I think this is a very bad idea.  For one thing,
> we should not advertise, promote, or enhance the lock-in of GitHub, and
> this policy does all three.

Please don't suggest that I made a policy to promote or enhance GitHub
"lock-in". Please keep reading for more information on why the packages
are named this way.

> Sometimes a maintainer decides to change their hosting arrangements.
> When they do so, we should simply be able to update some URLs in one
> package definition.  We should not have to do a global find/replace on
> the package name and alert our users to update their profiles and OS
> definitions.  That contributes to lock-in.

These packages are libraries written in the Go programming language. Go
libraries are referred to by their "import path" [0], which is a string
intended to uniquely identify a particular software implementation.

As I wrote in the commentary on the go-build-system (part of the commit
series being discussed), import paths are based on the URL of the
software. A package hosted at https://github.com/leo/foo has an import
path of 'github.com/leo/foo'. In Go, this is the library's name.

These import paths are the sole mechanism by which Go software is
uniquely referred to by humans and the Go compiler. It is even baked
in to how dependencies are organized on disk.

If the software changes its source URL, all users of the software must
change how they refer to it, at least if they want to use versions of
the software after the URL change. This means they must go through their
code and change the module imports from 'github.com/leo/foo' to
'newsite.com/leo/foo'. They will also need to change the filesystem
hierarchy in which they store their dependencies, to reflect the change.

I'm trying to explain that, in Go, domain names of library sources are
very important, and not just an implementation detail. [1]

So, in fact, we will not be able to just change the source URL of a Go
package if it moves to a new domain name.

Based on these properties of Go, the Guix packages are named based on
the import paths, plus a 'go-' prefix, in accordance with our practice
of adding language names to library packages.

> What do you think?

There are many Go libraries with the same "base name" (foo in my
previous example). So, we'll need to at least include some of the import
path in order to distinguish them.

Will we always need to use the entire import path, including the
domain-name component? I think so, but having only packaged one Go
application, I don't have an example of a cross-domain package name
collision. However, I have seen Go libraries use domain redirections to
signal API changes [2].

Does an import path always include some unique string besides the domain
name and the base name? I don't know.

Ultimately, I think we need a way to refer to Go libraries uniquely. I
think it will be confusing to have two different unique naming schemes
(Go import paths and whatever we'd come up with).

Does anyone have an idea for another way to uniquely refer to Go
libraries?

Finally, I don't think that including the string 'github-com' in package
names is unethical. It's too bad that there is a hosting monoculture.
But simply mentioning it, which is how I see the package names, is not
unethical, IMO.

[0] https://golang.org/doc/code.html#ImportPaths
[1] If you did a double-take, thinking "That's crazy!", then you
probably understood correctly.
[2] The site <https://gopkg.in/> is used for this.


signature.asc
Description: PGP signature

Re: 01/01: gnu: red-eclipse: Add store "data" package path as default.

[Leo Famulari]

On Tue, Oct 10, 2017 at 08:26:31AM -0400, Kei Kebreau wrote:
> kkebreau pushed a commit to branch master
> in repository guix.
> 
> commit 42abb842f64f5dd7834cabd445a5f4d01f1e68a4
> Author: Adonay Felipe Nogueira 
> Date:   Sun Aug 20 15:28:20 2017 -0300
> 
> gnu: red-eclipse: Add store "data" package path as default.
> 
> * gnu/packages/games.scm (red-eclipse): Remove extra spaces. Make version
> respect documentation.
> [arguments]: Add "prefix" to make-flags. Add
> "add-store-data-package-path-as-default" phase. Improve "copy-data" phase.
> 
> Signed-off-by: Kei Kebreau 
> ---
>  gnu/packages/games.scm | 110 
> ++---
>  1 file changed, 68 insertions(+), 42 deletions(-)

[...]

> @@ -133,6 +133,7 @@
>#:use-module (gnu packages gnuzilla)
>#:use-module (gnu packages icu4c)
>#:use-module (gnu packages networking)
> +  #:use-module (guix build utils)
>#:use-module (guix build-system gnu)
>#:use-module (guix build-system haskell)
>#:use-module (guix build-system python)

This module import created an ambiguous reference to 'which':

WARNING: (gnu packages games): `which' imported from both (gnu packages base) 
and (guix build utils)

I don't know if it will be a problem in practice.


signature.asc
Description: PGP signature

Re: Wrong hashes for libgit2 archives

[Leo Famulari]

On Sun, Oct 08, 2017 at 06:46:04PM +0200, Hartmut Goebel wrote:
> Hi,
> 
> I'm currently stuck with building kde-frameworks due to mismatching
> hashes for libgit2:
> 
> @ build-failed
> /gnu/store/mgh4yjxkxfyqmc7c61vwq4vs8v837602-libgit2-0.26.0.tar.gz.drv -
> 1 sha256 hash mismatch for output path
> `/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz'
>   expected: 1fdk9yhwvl1w1z71ykzcvgh4nsf8scxcbclz5anh98zpplmhmisa
>   actual:   1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka
> 
> I tried downgrading to v0.25.1 (by reverting 58dce7bf), but that failed
> with the same error:
> 
> @ build-failed
> /gnu/store/h8vrairp09vg239d9vpli12661vrv9d3-libgit2-0.25.1.tar.gz.drv -
> 1 sha256 hash mismatch for output path
> `/gnu/store/c3npgqn9ag2ypi9bda1g779wwwlcqqrf-libgit2-0.25.1.tar.gz'
>   expected: 1cdwcw38frc1wf28x5ppddazv9hywc718j92f3xa3ybzzycyds3s
>   actual:   0ywcxw1mwd56c8qc14hbx31bf198gxck3nja3laxyglv7l57qp26

The auto-generated GitHub snapshots, which is what we use for libgit2,
are not created deterministically:

https://bugs.gnu.org/28659
https://github.com/libgit2/libgit2/issues/4343

For now, the workaround is to get the tarball from a substitute server.


signature.asc
Description: PGP signature

Re: Go packaging

[Leo Famulari]

On Tue, Oct 03, 2017 at 11:15:04AM -0400, Leo Famulari wrote:
> Based on my work creating a go-build-system and packaging a non-trivial
> Go application [0], I want to start a discussion on how we can
> efficiently package Go software in Guix.

Another question, which is bikesheddy, is how to name Go packages in
Guix.

So far, I've used "golang-$upstreamname", which is how Petter named the
work-in-progress packages I am finishing. This leads to very long
package names, but I don't know a better way to ensure unique names for
each package.

I think we should do "go-$upstreamname" instead. Golang is not the name
of the language, but rather the domain name (go.org was apparently not
available), and a term that has been adopted by the community. But, it
would be good to save 4 characters here.


signature.asc
Description: PGP signature

Re: Go packaging

[Leo Famulari]

On Wed, Oct 04, 2017 at 06:19:18AM +0200, Pjotr Prins wrote:

Thanks for your comments, Pjotr!

> Thanks Leo for the explanation. Now I understand why Go programs, such
> as the IPFS implementation, have so many dependencies...

Yes, so many. As for transitive dependencies... well, I probably won't
package IPFS in my free time because of the huge number of packages
required.

> What I understand now is that packages get built 'lazily' and there is
> really no way to force a build - other than running the target
> software.

Not exactly — you can build a Go library module with `go install
name-of-module`. My packaging of Syncthing's dependencies does this,
creating '.a' static library archives, which are used later when
building Syncthing itself.

https://github.com/lfam/guix/blob/contrib-syncthing/gnu/packages/syncthing.scm

The difficulty for Guix is that we can't build the entire library (all
its modules) with a single command. As far as I can tell, we'd have to
recurse the filesystem tree of the library source code and try building
each directory. It sounds unreliable to me.

> I noticed the hash values in dependencies, so these are git checkouts
> (i.e., they are versioned, but not in the standard sense).

Right, there are useful "version" references in the form of the Git
commit hashes, but the problem is that it seems each Go application uses
a different commit.

> When I read the package.json file it includes things like:
> 
>   "gxDependencies": [
> {
>   "hash": "QmSpJByNKFX1sCsHBEp3R73FL4NF6FnQTEGyNAXHm2GS52",
>   "name": "go-log",
>   "version": "1.2.0"
> },
> {
>   "author": "whyrusleeping",
>   "hash": "QmZfwmhbcgSDGqGaoMMYx8jxBGauZw75zPjnZAyfwPso7M",
>   "name": "go-libp2p-secio",
>   "version": "1.1.8"
> },
> {
>   "author": "whyrusleeping",
>   "hash": "QmaPbCnUMBohSGo3KnxEa2bHqyJVVeEEcwtqJAYxerieBo",
>   "name": "go-libp2p-crypto",
>   "version": "1.5.0"
> },
> pac
> 
> indeed, there are even two versions in there for 'whyrusleeping'
> deep dependencies ;). (would that be a reference to Ruby's Why?).

In this case, I don't know what whyrusleeping refers to.
go-libp2p-secio and go-libp2p-crypto are the names of the programs
themselves.

> On the surface, similar to Rubygems, I think it is no problem to
> distribute source packages from Guix and have them compile on the fly.
> In a way that is also an interesting model for late optimizations -
> something we are lacking in our current infrastructure. What I think
> we should do is import above json file and generate GNU binary
> packages that are GO source bundles.

That package.json file is not a standard thing in the Go world.
I've found that Go applications use a variety of dependency manifest
formats, or just use Git submodules.

> Provided GO can use a live build directory outside the store it will
> only compile bundles once, on demand. Ruby 'compiles' or interprets
> every time, so that is one up on Go ;). That target directory would be
> mutable, so that is a downside, a potential security risk.

I considered something like this earlier in this effort, but it's not
what I'm proposing now. As you say, it's messy to compile outside of the
store at run-time, and I don't think we need to do it.

Rather, I think we should have a special go-package procedure, used in
the inputs field of the calling application, which would build the
relevant library modules of the correct Git commit. Does that make
sense?

> We ought to have a look at how Nix packaged Go builds because they are
> already have a solution. Be interesting to see if they found a way to
> compile packages 'greedily', the way Python does it.

I looked at their build system itself a few weeks ago when I was still
learning how Go compilation works. I agree, it would be fruitful to see
how they handle the issues I've raised here.


signature.asc
Description: PGP signature

Go packaging

[Leo Famulari]

Based on my work creating a go-build-system and packaging a non-trivial
Go application [0], I want to start a discussion on how we can
efficiently package Go software in Guix.

Go software is developed rather differently from most of what we
package, and I think our package abstraction does not fit Go libraries
well.

The primary differences are 0) Go libraries are typically bundled as
source code, 1) Go software is typically unversioned, 2) static archives
(.a) are the norm, and 3) Go libraries are expected to be built as part
of the build process of the calling application. That is, there is no
standard way to build an entire Go library on its own.

Elaboration:

0,1) The problem with every application bundling unversioned libraries
is that we need to package a different Git commit of the library for
every application we package, or risk our packages not working. Adding
package variants per-version is a bit messy currently.

3) As an example of how Go libaries are built piecemeal, take the core
networking library, 'golang.org/x/net' [1]. It includes dozens of
submodules such as bpf, icmp, ipv4, ipv6, etc. There is no way to build
all these submodules with a single command. Instead, each one is built
when it is needed during the build process of the calling application.
There are no build scripts. The library compilation process is
standardized as, for example, `go install golang.org/x/net/ipv4`.

This means that the entire networking library would consist of several
dozen Guix packages, multiplied by the number of different Git commits
required by the calling applications. It's unreasonable, in my opinion.

My suggestion is that we have two layers of Go library packages: a) a
template layer that includes the source URI, unpack-path, and other
package metadata, and b) a layer to create instances of the package
within the inputs field of the calling package.

Perhaps the instantiation layer could look like this in practice:

(define-public my-go-program
  [...]
  (inputs
   `(("golang.org/x/net"
  ,(go-package golang-org-x-net
(version "ffcf1bedda")
(import-paths '("golang.org/x/net/ipv4"
"golang.org/x/net/context"
"golang.org/x/net/ipv6"
"golang.org/x/net/internal/iana")))

Or something like that. What do you think?

[0]
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28586#26
[1]
https://godoc.org/golang.org/x/net


signature.asc
Description: PGP signature

Re: [go-build-system]

[Leo Famulari]

On Thu, Aug 31, 2017 at 08:17:15AM -0400, Leo Famulari wrote:
> I have a work-in-progress of a go-build-system with packages for
> Syncthing up here:
> 
> https://github.com/lfam/guix/tree/wip-syncthing
> 
> It seems to work until the Syncthing build fails like this:

I'm *very* happy to report that these issues are resolved. The problem
was caused by the lack of a unique file-name for some of the Syncthing
dependencies source code checkouts. [0]

I'll push an updated branch to my tree on GitHub shortly.

[0] I think there are some dragons there... if not bugs. Report to
follow.


signature.asc
Description: PGP signature

Re: Fetching patches as origins instead of copying them into the Guix Git repo

[Leo Famulari]

On Thu, Aug 31, 2017 at 11:52:25PM +0200, Marius Bakke wrote:
> Leo Famulari <l...@famulari.name> writes:
> 
> > On Thu, Aug 31, 2017 at 09:52:49PM +0200, Marius Bakke wrote:
> >> Side note: I think we should start adding patches as origins instead of
> >> copying them wholesale, to try and keep the git repository slim.
> >
> > We should make a git-minimal package for things like this, or use
> > guile-git / libgit2. Git itself is a very "heavy" package.
> 
> No, I mean adding patches like this:
> 
> (define %CVE-1970-0001.patch
>   (origin
> (method url-fetch)
> (uri "https://example.com/CVE-2017-0001.patch;)
> (sha256
>  (base32
>   "12c60iwxyc3rj6ih06a1g80vmkf8khvhm44xr9va4h21b74v8f5k"
> 
> (package
>  (...
>   (patches (list (search-patch "guix-specific-stuff.patch")
>  %CVE-1970-0001.patch)))
> 
> That only requires the built-in guix downloader.

Ah, that's much better than what I was thinking.


signature.asc
Description: PGP signature

Re: [go-build-system] How to access properties or keys of a package on the build side?

[Leo Famulari]

On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote:
> 
> Ricardo Wurmus  writes:
> 
> > You could also access the arguments of another package with
> > “package-arguments”.  Using the “properties” field isn’t pretty because
> > it is a free form alist.
> >
> > You can use “find-tail” to jump to the keyword in “arguments” and then
> > pick the following value.
> 
> Here an example:
> 
> --8<---cut here---start->8---
> (define (assoc-args-ref pkg key)
>   "Return the value associated with KEY in the arguments of package PKG,
> or #F if there is no such key."
>   (let ((ref (find-tail (cut eq? <> key)
> (package-arguments pkg
> (and=> ref second)))
> 
> (assoc-args-ref golang-github-com-audriusbutkevicius-go-nat-pmp
> #:import-path)
> 
> => "github.com/AudriusButkevicius/go-nat-pmp"
> --8<---cut here---end--->8---

I didn't get very far in this direction before deciding to try another
technique. But wouldn't this not work on the build side, since (guix
packages) is not available there?

I considered building an alist of store items and "import paths" and
passing that into the build from the host side, but it started to feel
like the wrong approach.

Instead my latest approach [0] is to "record" the packages' import paths
via their store items' filesystem layouts.

[0]
https://lists.gnu.org/archive/html/guix-devel/2017-08/msg00323.html


signature.asc
Description: PGP signature

Fetching patches as origins instead of copying them into the Guix Git repo

[Leo Famulari]

On Thu, Aug 31, 2017 at 09:52:49PM +0200, Marius Bakke wrote:
> Side note: I think we should start adding patches as origins instead of
> copying them wholesale, to try and keep the git repository slim.

We should make a git-minimal package for things like this, or use
guile-git / libgit2. Git itself is a very "heavy" package.


signature.asc
Description: PGP signature

Re: [go-build-system]

[Leo Famulari]

On Tue, Aug 29, 2017 at 03:54:40PM +0300, Frederick Muriithi wrote:
> Maybe the following will help clarify the issue:
> 
> The package being built needs the sources of the dependenc(y/ies) to
> be available in its GOPATH.
> 
> The build system needs to set the GOPATH such that the Go build system
> will find the the dependencies and build against them.

Right.

> I have a repository[1] where I'm currently working on definitions for
> IPFS before translating them for mainline guix.
> If you checkout commit f7f97edc635381384c3532eb8a2bd92cf10a5ac9 and
> look at the code there, you can see that I manually set up GOPATH in
> the build of go-log so that it can find go-logging (the modified
> version[2]).

IPFS is interesting. I hope we can get it in Guix.

I have a work-in-progress of a go-build-system with packages for
Syncthing up here:

https://github.com/lfam/guix/tree/wip-syncthing

It seems to work until the Syncthing build fails like this:

--
/gnu/store/wr8r001nxr8ryfnw1kkgrmbij4yqldxi-golang-org-x-net-0.0.0-0.ffcf1be/src/golang.org/x/net/internal/netreflect/socket_19.go:15:2:
 errInvalidType redeclared in this block
previous declaration at 
/gnu/store/wr8r001nxr8ryfnw1kkgrmbij4yqldxi-golang-org-x-net-0.0.0-0.ffcf1be/src/golang.org/x/net/internal/netreflect/socket.go:15:2
/gnu/store/wr8r001nxr8ryfnw1kkgrmbij4yqldxi-golang-org-x-net-0.0.0-0.ffcf1be/src/golang.org/x/net/internal/netreflect/socket_19.go:16:2:
 errOpNoSupport redeclared in this block
previous declaration at 
/gnu/store/wr8r001nxr8ryfnw1kkgrmbij4yqldxi-golang-org-x-net-0.0.0-0.ffcf1be/src/golang.org/x/net/internal/netreflect/socket.go:16:2
/gnu/store/wr8r001nxr8ryfnw1kkgrmbij4yqldxi-golang-org-x-net-0.0.0-0.ffcf1be/src/golang.org/x/net/internal/netreflect/socket_19.go:20:37:
 SocketOf redeclared in this block
previous declaration at 
/gnu/store/wr8r001nxr8ryfnw1kkgrmbij4yqldxi-golang-org-x-net-0.0.0-0.ffcf1be/src/golang.org/x/net/internal/netreflect/socket.go:20:37
/gnu/store/wr8r001nxr8ryfnw1kkgrmbij4yqldxi-golang-org-x-net-0.0.0-0.ffcf1be/src/golang.org/x/net/internal/netreflect/socket_19.go:30:49:
 PacketSocketOf redeclared in this block
previous declaration at 
/gnu/store/wr8r001nxr8ryfnw1kkgrmbij4yqldxi-golang-org-x-net-0.0.0-0.ffcf1be/src/golang.org/x/net/internal/netreflect/socket.go:30:49
--

I have a hunch about what might be wrong [0] but do any Go programmers
have some guidance?

[0] It could be related to the use of these package unions:
https://github.com/lfam/guix/blob/wip-syncthing/gnu/packages/syncthing.scm#L1105
The affected package is part of a group of packages that uses a union
like that:
https://github.com/lfam/guix/blob/wip-syncthing/gnu/packages/syncthing.scm#L1845

I wonder if we should instead make a union of all the Go inputs so that
GOPATH has a single entry, rather than just using unions for selected
packages and letting GOPATH be a list of directories.


signature.asc
Description: PGP signature

Re: [go-build-system] How to access properties or keys of a package on the build side?

[Leo Famulari]

On Mon, Aug 28, 2017 at 10:32:41PM +0200, Ricardo Wurmus wrote:
> 
> Ricardo Wurmus  writes:
> 
> > You could also access the arguments of another package with
> > “package-arguments”.  Using the “properties” field isn’t pretty because
> > it is a free form alist.
> >
> > You can use “find-tail” to jump to the keyword in “arguments” and then
> > pick the following value.
> 
> Here an example:
> 
> --8<---cut here---start->8---
> (define (assoc-args-ref pkg key)
>   "Return the value associated with KEY in the arguments of package PKG,
> or #F if there is no such key."
>   (let ((ref (find-tail (cut eq? <> key)
> (package-arguments pkg
> (and=> ref second)))
> 
> (assoc-args-ref golang-github-com-audriusbutkevicius-go-nat-pmp
> #:import-path)
> 
> => "github.com/AudriusButkevicius/go-nat-pmp"
> --8<---cut here---end--->8---

Thanks, this is a nice example.

I realized that the GOPATH variable can be a list of directories, like
PATH, so I'm working in that direction instead of building the symlink
union.


signature.asc
Description: PGP signature

Re: The future of 'guix environment'

[Leo Famulari]

On Wed, Aug 30, 2017 at 11:11:33PM +0800, 宋文武 wrote:
> > 1) Add a caching mechanism.  The environment profile should get built
> > once, and then a symlink to it should be created in $PWD and
> > registered as a GC root.  This will, of course, require re-using some
> > 'guix package' code to delete the profile.  For the sake of the rest
> > of this post, let's say that a --cache flag does this, and a --update
> > flag forces a rebuilding of the cached profile.

I like that the results of `guix environment` are ephemeral by default.

> I always run 'guix environmeut guix' and have to wait for substitutes
> before entering the shell, indeed caching the environment will save me
> much time, but usually I don't mind that and was already used to the
> "awlays being latest" behaviour...
> 
> I definitely want this feature too, so how about rename the current
> implementation of 'environment' to 'guix shell', whose ad hoc behaviour
> is similar to the 'nix-shell', and start a new implementation with this
> persistent behaviour?

I agree. If we change the behaviour to leave files in the current
directory and register GC roots then we should use a new name or rename
the existing functionality. I'm in favor of using a new name for new
functionality.


signature.asc
Description: PGP signature

Re: GSoC final update

[Leo Famulari]

(off-list)

Hey Caleb,

On Tue, Aug 29, 2017 at 02:44:56AM -0500, Caleb Ristvedt wrote:
>  I found myself checking the guile reference quite
> frequently. One time I happened upon a part describing the ECMAScript
> implementation (curiosity and all that), and noticed that several times
> it was mentioned how irresponsible the implementor was. That scared me
> probably more than it should have. By all objective criteria, I have
> failed in this project, and it frightens me to think that, nice as the
> community is, I could screw up badly enough to end up a footnote
> somewhere as an example of what not to be. That fear pretty much sums up
> my mental state during the second half of the summer.
> 
> In short, I've failed to achieve the goals I set out in my
> proposal. Worst of all is that I failed to regularly communicate. I
> specifically said that I would regularly communicate, and then I failed
> to do so, especially during the second half of the summer. It seems that
> the less I communicated, the more afraid of communicating I
> became.

I've had similar feelings at different parts of my life. Sometimes it's
been related to work, sometimes to relationships.

I want to say that I can relate to what you experienced, and I hope you
can let go of those negative feelings.

For me, I've since realized that I was *way* too hard on myself each
time it happened.

From time to time, we all have the experience of not reaching some goal
that we have set for ourselves. This seems not to affect some people at
all; I tend to feel very bad about it.

But, as I've grown older I've learned to see it happening and tell
myself to let it go. Nobody else wants me to feel bad, and they won't be
upset that I didn't meet my goal. The harsh taskmaster is in my head, so
it's completely safe for me to tell him to get lost ;)

I hope you won't feel bad if you don't pick this work back up right
away, or ever.

Peace,
Leo


signature.asc
Description: PGP signature

[go-build-system] How to access properties or keys of a package on the build side?

[Leo Famulari]

Recently I made some progress on finishing the prototype go-build-system
from Petter [0], and I need some advice.

AFAICT, building a Go program requires the program's Go dependencies to
have a particular filesystem layout, which corresponds to the way these
dependencies are imported by the program's code.

So, a Go build system needs to somehow create a symlink union of the
dependency graph, making the dependencies available at the correct paths
relative to the root of the build environment. AFAICT, we can't figure
these paths out programatically; they must be supplied by the packager
in advance, for example:

--
(arguments
  `(#:import-path "github.com/AudriusButkevicius/go-nat-pmp"))
--

Petter's prototype creates the symlink union, but instead of using the
#:import-path key, it instead duplicates the import path while listing a
package's dependencies, like this:

--
(inputs
 `(("github.com/AudriusButkevicius/go-nat-pmp"
,golang-github-com-audriusbutkevicius-go-nat-pmp)
--

... putting the import path in the car of the input, and using it as shown
below:

--
(define* (symlinking #:key inputs #:allow-other-keys)
  (for-each (lambda (input)
  (let ((import-path (car input))
(storepath (cdr input)))
; Don't deal with the compiler or source inputs
(if (and (not (string=? import-path "go"))
 (not (string=? import-path "source")))
(begin
  (mkdir-p (string-append
"src/"
(string-take import-path
 (string-rindex import-path #\/
  (let ((from (string-append storepath "/src/" import-path))
(to (string-append "src/" import-path)))
(if (file-exists? to) (delete-file-recursively to))
(symlink (string-append
  storepath "/src/" import-path)
 (string-append
  "src/" import-path)))
inputs))
--

Are there any examples in the code base of accessing the inputs' keys? That
seems like a better solution to me, but I'm not sure how to achieve it.

[0]
https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00399.html


signature.asc
Description: PGP signature

Re: 'core-updates' status

[Leo Famulari]

On Fri, Aug 25, 2017 at 10:57:12PM +0300, Manolis Ragkousis wrote:
> On 08/25/17 21:34, Marius Bakke wrote:
> > Hello!
> > 
> > 'core-updates' has finished building on x86_64 on i686, and the grafting
> > failures should now be fixed.  Are we ready to merge this branch? :-)
> > 
> 
> Does cross-compilation work? Because I cannot cross-compile anything for
> any target I tried (i686-linux, i586-gnu).
> 
> http://paste.lisp.org/display/354303

Can you file a bug report? Do you know if this is a new regression or
has it been present for the last couple months of core-updates
development?


signature.asc
Description: PGP signature

Re: 'core-updates' status

[Leo Famulari]

On Fri, Aug 25, 2017 at 08:34:21PM +0200, Marius Bakke wrote:
> 'core-updates' has finished building on x86_64 on i686, and the grafting
> failures should now be fixed.  Are we ready to merge this branch? :-)

I think it's ready. There are a handful of failing packages left, but I
assume they will be fixed by their users after the merge :)


signature.asc
Description: PGP signature

Re: Grafting fails for latest Go release candidate

[Leo Famulari]

I saw this problem on the master branch.


 Original Message 
From: l...@gnu.org
Sent: August 21, 2017 10:32:01 AM CDT
To: Andy Wingo 
Cc: guix-devel@gnu.org
Subject: Re: Grafting fails for latest Go release candidate

Hi,

Andy Wingo  skribis:

> On Mon 07 Aug 2017 22:08, Marius Bakke  writes:
>
>> I've caught a couple other elusive grafting errors:
>>
>> grafting '/gnu/store/ccw7wzh9rbflc0fl968dbj2x0x9dn4y5-chromium-60.0.3112.90' 
>> -> '/gnu/store/b3f2d6l1c546xwcv4hg8619qh87cixhb-chromium-60.0.3112.90'...
>> ERROR: Wrong type to apply: "der */\n  max-width: 638px;\n  min" 
>
> This looks like a Guile 2.2 GC error somehow :-(

Marius, Leo: was the failure on ‘core-updates’, where Guile 2.2 is used?
(On ‘master’ 2.0 is used to build derivations.)

It could also be a thread-safety issue or something.

Ludo’.

Re: openssl is now a dependency of guix: possible license conflict?

[Leo Famulari]

On Fri, Aug 18, 2017 at 10:44:04PM +0800, Alex Vong wrote:
> It seems julia had merge the mbedtls patches, so they should be working:
> 
>   https://github.com/JuliaLang/julia/pull/22614
> 
> Should we also adopt the patches?

Personally, I think it depends on the advice of the libgit2 team. We
shouldn't add new TLS backends without being very careful that they work
properly.

I've seen many cases where TLS seemed to work but, upon examination,
turned out to not offer any security at all.

Currently, TLS in `guix pull` is the fundamental security mechanism in
Guix, so we must be very careful.


signature.asc
Description: PGP signature

Re: git cannot be built

[Leo Famulari]

On Wed, Aug 09, 2017 at 03:44:23PM -0400, Mark H Weaver wrote:
> Ricardo Wurmus  writes:
> 
> > Mark H Weaver  writes:
> >
> >> Ricardo Wurmus  writes:
> >>
> >>> Commit 7f171fdaadb15bb1b313b25e9be3d1988b0f650f broke git for me.  I
> >>> cannot build it from source because one of the many tests appears to
> >>> fail.
> >>>
> >>> This is on x86_64.  I have not tried this on other architectures.
> >>
> >> FWIW, it built successfully on my x86_64 GuixSD system.  I've
> >> transitioned to building everything locally.
> >
> > It also worked on my i686 machine, but it failed repeatedly on my x200s.
> 
> I built it on a Thinkpad X200.  Perhaps I got lucky.  Also, it case it's
> relevant, I've been using linux-libre@4.9 with selected patches from
> Debian.

Anecdata: It failed once on my Debian x230, which is using the 4.12
kernel series (compiled myself). It's passed three times since then.


signature.asc
Description: PGP signature

Re: core-updates: biber

[Leo Famulari]

On Mon, Aug 07, 2017 at 08:47:53PM +0200, Ricardo Wurmus wrote:
> For some reason even the updated patches didn’t apply correctly, so I
> applied them manually (maybe it’s a problem on my end).  I’ve tested
> biber on one of my old projects and it works as expected:
> 
> --8<---cut here---start->8---
> $ biber assignment1
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
> 5.30), passed through in regex; marked by <-- HERE in m/}(\pM+\pL){ <-- HERE 
> (?!\pL+\\)/ at 
> /gnu/store/b2l7hrs9cr4ky99j3nx582wl2v7ngk6y-biber-2.7/lib/perl5/site_perl/5.26.0/Biber/LaTeX/Recode.pm
>  line 316.
> INFO - This is Biber 2.7
> INFO - Logfile is 'assignment1.blg'
> INFO - Reading 'assignment1.bcf'
> INFO - Found 3 citekeys in bib section 0
> INFO - Processing section 0
> INFO - Looking for bibtex format file 'refs.bib' for section 0
> INFO - Decoding LaTeX character macros into UTF-8
> INFO - Found BibTeX data source 'refs.bib'
> INFO - Overriding locale 'en-US' defaults 'variable = shifted' with 'variable 
> = non-ignorable'
> INFO - Overriding locale 'en-US' defaults 'normalization = NFD' with 
> 'normalization = prenormalized'
> INFO - Sorting list 'apa/global/' of type 'entry' with scheme 'apa' and 
> locale 'en-US'
> INFO - No sort tailoring available for locale 'en-US'
> INFO - Writing 'assignment1.bbl' with encoding 'UTF-8'
> INFO - Output to assignment1.bbl
> --8<---cut here---end--->8---
> 
> The warning about “unescaped left brace in regex” is ugly, but it
> doesn’t break anything.
> 
> I’ve pushed the three commits to core updates (c97fbf55e).

Great! I've started a new evaluation. I think this could be the last
one.


signature.asc
Description: PGP signature

Re: Small documentation improvements

[Leo Famulari]

On Mon, Aug 07, 2017 at 01:37:16AM +0200, Martin H. wrote:
> Actually, it seems this change was totally wrong and broke my system. At
> least that's what happened: I didn't really realize it immediately, but
> after this change and the first successful package compile inside my guix
> checkout I ended up with broken links to libgcc and libstd++. That means I
> couldn't run any command anymore. I had to boot a live cd and fix those
> problems manually the hard way in order to get the system to boot again.

Yikes! I've reverted the change while we investigate.

> The "sudo -E" makes GUILE_LOAD_PATH contain the paths of the development
> guix instance *in addition* to the paths of the system instance (in
> /run/current-system). As far as I understand, that then means two guix
> daemons with different packages sources are partially operating on the same
> store directories. The development checkout should rather only use its own
> store directory, right? Can anyone clear up how it is supposed to work?

When using Guix from the development checkout with the 'pre-inst-env'
script, you can share the store and database if you pass
'--localstatedir=/var' to ./configure, assuming you are using the
default location of the local state directory.

I figure it should be safe to run multiple daemons on the same store as
long as they share the database, but I'm not 100% sure.

However, it's generally not necessary to run a guix-daemon from the
source checkout unless you are testing changes to the daemon, or the
source checkout and the GuixSD-provided guix-daemon are of wildly
different versions of Guix.

> The reason I tried this change in the first place was that each `guix build`
> call ends up with the following error, when the daemon is not started with
> "sudo -E":
> 
> > substitute: ;;; Failed to autoload make-session in (gnutls):
> > substitute: ;;; ERROR: missing interface for module (gnutls)
> > substitute: Backtrace:
> > substitute:1 (primitive-load
> > "/home/martin/git/guix/scripts/guix")
> > substitute: In guix/ui.scm:
> > substitute:   1331:12  0 (run-guix-command _ . _)
> > substitute:
> > substitute: guix/ui.scm:1331:12: In procedure run-guix-command:
> > substitute: guix/ui.scm:1331:12: In procedure module-lookup: Unbound
> > variable: make-session
> > guix build: error: corrupt input while restoring archive from # > file 1fe3d90>
> 
> There probably has to be a different solution to this problem. I found
> recent threads with similar problems, but this seems to be different.

Those errors indicate that Guix could not find the Guile bindings of
GnuTLS. They can be made available with `guix environment --ad-hoc
guile2.2-gnutls`.


signature.asc
Description: PGP signature

Re: core-updates: biber

[Leo Famulari]

On Sun, Aug 06, 2017 at 11:44:41AM +0200, Ricardo Wurmus wrote:
> Leo Famulari <l...@famulari.name> writes:
> > The attached patches update texlive to 2017 and remove biber-2.5.
> > Ricardo, can you check if biber@2.7 works with these patches?
> 
> These patches don’t apply cleanly to core-updates since the merge of
> master a couple of hours ago.  I cannot rebase and test them today, but
> I can give it a try on Monday.

I've attached an updated patch series.
From 02c2c1b2b4ffc9b95652b70b96967340c40ee800 Mon Sep 17 00:00:00 2001
From: Leo Famulari <l...@famulari.name>
Date: Sat, 5 Aug 2017 17:56:49 -0400
Subject: [PATCH 1/3] gnu: texlive: Update to 2017.

* gnu/packages/tex.scm (texlive, texlive-texmf): Update to 2017.
(texlive-texmf-src): Update to 20170524. Remove
'texlive-texmf-CVE-2016-10243.patch'.
(texlive-bin, texlive-extra-src): Update to 20170524.
* gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch: Delete file.
* gnu/local.mk (dist_patch_DATA): Remove it.
---
 gnu/local.mk   |  1 -
 .../patches/texlive-texmf-CVE-2016-10243.patch | 18 --
 gnu/packages/tex.scm   | 22 +++---
 3 files changed, 11 insertions(+), 30 deletions(-)
 delete mode 100644 gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index acdadd629..e7a870549 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1022,7 +1022,6 @@ dist_patch_DATA = 
\
   %D%/packages/patches/tcsh-fix-out-of-bounds-read.patch   \
   %D%/packages/patches/teensy-loader-cli-help.patch\
   %D%/packages/patches/teeworlds-use-latest-wavpack.patch  \
-  %D%/packages/patches/texlive-texmf-CVE-2016-10243.patch  \
   %D%/packages/patches/texi2html-document-encoding.patch   \
   %D%/packages/patches/texi2html-i18n.patch\
   %D%/packages/patches/thefuck-test-environ.patch  \
diff --git a/gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch 
b/gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch
deleted file mode 100644
index 3a9ae993f..0
--- a/gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch
+++ /dev/null
@@ -1,18 +0,0 @@
-Fix CVE-2016-10243:
-
-https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10243
-
-Patch adapted from upstream commit:
-
-https://www.tug.org/svn/texlive?view=revision=42605
-
 trunk/Master/texmf-dist/web2c/texmf.cnf2016/11/29 23:10:33 42604
-+++ trunk/Master/texmf-dist/web2c/texmf.cnf2016/11/29 23:27:53 42605
-@@ -568,7 +568,6 @@ extractbb,\
- gregorio,\
- kpsewhich,\
- makeindex,\
--mpost,\
- repstopdf,\
- 
- % we'd like to allow:
diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index 729f9c01b..60b4a837b 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2016 Federico Beffa <be...@fbengineering.ch>
 ;;; Copyright © 2016 Thomas Danckaert <p...@thomasdanckaert.be>
 ;;; Copyright © 2016, 2017 Ricardo Wurmus <rek...@elephly.net>
+;;; Copyright © 2017 Leo Famulari <l...@famulari.name>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -66,29 +67,28 @@
 (define texlive-extra-src
   (origin
 (method url-fetch)
-(uri 
"ftp://tug.org/historic/systems/texlive/2016/texlive-20160523-extra.tar.xz;)
+(uri 
"ftp://tug.org/historic/systems/texlive/2017/texlive-20170524-extra.tar.xz;)
 (sha256 (base32
-  "0q4a92zmwhn4ry6xgrp4k8wq11ax2sg9rg9yrsrdkr719y0x887a"
+  "0zvd2zskk78ig114mfj24g15qys41hzqv59fmqpirdbgq9c9gr5g"
 
 (define texlive-texmf-src
   (origin
 (method url-fetch)
-(uri 
"ftp://tug.org/historic/systems/texlive/2016/texlive-20160523b-texmf.tar.xz;)
-(patches (search-patches "texlive-texmf-CVE-2016-10243.patch"))
-(patch-flags '("-p2"))
+(uri 
"ftp://tug.org/historic/systems/texlive/2017/texlive-20170524-texmf.tar.xz;)
 (sha256 (base32
-  "1dv8vgfzpczqw82hv9g7a8djhhyzywljmrarlcyy6g2qi5q51glr"
+  "1v69y3kgkbk24f7s4dfkknwd317mqmck5jgpyb35wqgqfy5p0qrz"
 
 (define-public texlive-bin
   (package
(name "texlive-bin")
-   (version "2016")
+   (version "20170524")
(source
 (origin
  (method url-fetch)
-  (uri 
"ftp://tug.org/historic/systems/texlive/2016/texlive-20160523b-source.tar.xz;)
+  (uri (string-append "ftp://tug.org/historic/systems/texlive/2017/;
+  "texlive-" version "-source.tar.xz"))
   (sha256 (base32
-   "1v91vahxlxkdra0qz3f132vvx5d9cx2jy84yl1hkch0agyj2rcx8"
+   "1amjrxyasplv4alfwcxwnw4nrx7dz2ydmddkq16k6hg90i9njq81"
(build-system gnu-build-system)
(inputs
 `(("texlive-extra-src" ,tex

Re: core-updates: biber

[Leo Famulari]

On Sun, Aug 06, 2017 at 12:14:47PM +0200, Andreas Enge wrote:
> Hello,
> 
> On Sat, Aug 05, 2017 at 06:38:48PM -0400, Leo Famulari wrote:
> > The attached patches update texlive to 2017 and remove biber-2.5.
> 
> I did not follow the new modular texlive packages, but it looks as if
> at the same occasion texlive-minimal could be removed? I added it only
> to have a smaller package for building documentation of other packages,
> but all dependent packages have been switched to use the modular texlive.

Thanks for pointing it out. I've removed texlive-minimal and
texlive-texmf-minimal in the revise patches I'm sending to Ricardo.


signature.asc
Description: PGP signature

Re: core-updates: biber

[Leo Famulari]

On Sat, Aug 05, 2017 at 03:26:07PM -0400, Leo Famulari wrote:
> On Mon, Jul 31, 2017 at 09:26:56AM +0200, Ricardo Wurmus wrote:
> > If we upgrade those two, I’m pretty sure we won’t need Biber 2.5 any
> > more and can replace it with what is currently biber-next.
> > 
> > I would suggest not to spend too much time on Biber 2.5 as it is on its
> > way out — it just needs a texlive-texmf update.
> 
> Okay, I'm working on this today.

The attached patches update texlive to 2017 and remove biber-2.5.
Ricardo, can you check if biber@2.7 works with these patches?
From f7f1a75bd27014a97024f5b44b87861a2123de35 Mon Sep 17 00:00:00 2001
From: Leo Famulari <l...@famulari.name>
Date: Sat, 5 Aug 2017 17:56:49 -0400
Subject: [PATCH 1/2] gnu: texlive: Update to 2017.

* gnu/packages/tex.scm (texlive, texlive-texmf): Update to 2017.
(texlive-texmf-src): Update to 20170524. Remove
'texlive-texmf-CVE-2016-10243.patch'.
(texlive-bin, texlive-extra-src): Update to 20170524.
* gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch: Delete file.
* gnu/local.mk (dist_patch_DATA): Remove it.
---
 gnu/local.mk   |  1 -
 .../patches/texlive-texmf-CVE-2016-10243.patch | 18 --
 gnu/packages/tex.scm   | 22 +++---
 3 files changed, 11 insertions(+), 30 deletions(-)
 delete mode 100644 gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 37ee7f730..f2b72569d 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1016,7 +1016,6 @@ dist_patch_DATA = 
\
   %D%/packages/patches/tcsh-fix-out-of-bounds-read.patch   \
   %D%/packages/patches/teensy-loader-cli-help.patch\
   %D%/packages/patches/teeworlds-use-latest-wavpack.patch  \
-  %D%/packages/patches/texlive-texmf-CVE-2016-10243.patch  \
   %D%/packages/patches/texi2html-document-encoding.patch   \
   %D%/packages/patches/texi2html-i18n.patch\
   %D%/packages/patches/thefuck-test-environ.patch  \
diff --git a/gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch 
b/gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch
deleted file mode 100644
index 3a9ae993f..0
--- a/gnu/packages/patches/texlive-texmf-CVE-2016-10243.patch
+++ /dev/null
@@ -1,18 +0,0 @@
-Fix CVE-2016-10243:
-
-https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10243
-
-Patch adapted from upstream commit:
-
-https://www.tug.org/svn/texlive?view=revision=42605
-
 trunk/Master/texmf-dist/web2c/texmf.cnf2016/11/29 23:10:33 42604
-+++ trunk/Master/texmf-dist/web2c/texmf.cnf2016/11/29 23:27:53 42605
-@@ -568,7 +568,6 @@ extractbb,\
- gregorio,\
- kpsewhich,\
- makeindex,\
--mpost,\
- repstopdf,\
- 
- % we'd like to allow:
diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index 729f9c01b..60b4a837b 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -7,6 +7,7 @@
 ;;; Copyright © 2016 Federico Beffa <be...@fbengineering.ch>
 ;;; Copyright © 2016 Thomas Danckaert <p...@thomasdanckaert.be>
 ;;; Copyright © 2016, 2017 Ricardo Wurmus <rek...@elephly.net>
+;;; Copyright © 2017 Leo Famulari <l...@famulari.name>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -66,29 +67,28 @@
 (define texlive-extra-src
   (origin
 (method url-fetch)
-(uri 
"ftp://tug.org/historic/systems/texlive/2016/texlive-20160523-extra.tar.xz;)
+(uri 
"ftp://tug.org/historic/systems/texlive/2017/texlive-20170524-extra.tar.xz;)
 (sha256 (base32
-  "0q4a92zmwhn4ry6xgrp4k8wq11ax2sg9rg9yrsrdkr719y0x887a"
+  "0zvd2zskk78ig114mfj24g15qys41hzqv59fmqpirdbgq9c9gr5g"
 
 (define texlive-texmf-src
   (origin
 (method url-fetch)
-(uri 
"ftp://tug.org/historic/systems/texlive/2016/texlive-20160523b-texmf.tar.xz;)
-(patches (search-patches "texlive-texmf-CVE-2016-10243.patch"))
-(patch-flags '("-p2"))
+(uri 
"ftp://tug.org/historic/systems/texlive/2017/texlive-20170524-texmf.tar.xz;)
 (sha256 (base32
-  "1dv8vgfzpczqw82hv9g7a8djhhyzywljmrarlcyy6g2qi5q51glr"
+  "1v69y3kgkbk24f7s4dfkknwd317mqmck5jgpyb35wqgqfy5p0qrz"
 
 (define-public texlive-bin
   (package
(name "texlive-bin")
-   (version "2016")
+   (version "20170524")
(source
 (origin
  (method url-fetch)
-  (uri 
"ftp://tug.org/historic/systems/texlive/2016/texlive-20160523b-source.tar.xz;)
+  (uri (string-append "ftp://tug.org/historic/systems/texlive/2017/;
+  "texlive-" version "-source.tar.xz"))
   (sha256 (base32
-   "1v91vahxlxkdra0qz3f132vvx5d9cx2jy84yl1hkch0agyj2rcx8"
+   "1amjrxyasplv4alfwcxwnw4nrx7dz2ydmddkq16k6hg90i

Re: core-updates: biber

[Leo Famulari]

On Mon, Jul 31, 2017 at 09:26:56AM +0200, Ricardo Wurmus wrote:
> If we upgrade those two, I’m pretty sure we won’t need Biber 2.5 any
> more and can replace it with what is currently biber-next.
> 
> I would suggest not to spend too much time on Biber 2.5 as it is on its
> way out — it just needs a texlive-texmf update.

Okay, I'm working on this today.


signature.asc
Description: PGP signature

Re: [PATCH 001/303] gnu: Add opencolorio.

[Leo Famulari]

On Fri, Aug 04, 2017 at 11:02:07AM -0500, Christopher Allan Webber wrote:
> ng0 writes:
> 
> > Christopher Allan Webber transcribed 9.3K bytes:
> >> I have a friend who's a Blender user who said they'd like to see
> >> opencolorio support in the Blender package... this is an old patch,
> >> but maybe worth trying to get in again?
> >
> > Was this directed specifically at myself, or just a bump for the thread?
> > I welcome any further work on this, but I'm not able to do this
> > currently or in a foreseeable future.
> 
> Directed at whoever has the time :)

This package is a dependency of Krita, so it's certainly valuable!


signature.asc
Description: PGP signature

Difficulty starting with Cuirass

[Leo Famulari]

Hi,

I'm trying to set up Cuirass to build some manifests on a foreign
distro. I decided to start by adapting Mathieu O's examples from March
2017:

https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00222.html

However, when I try to use it with the files copied below, it fails:

--
$ cuirass --one-shot --specifications=/home/leo/tmp/test/specification.scm 
--database=/tmp/test.db --cache-directory=/tmp/cuirass-cache
fatal: repository '#f' does not exist
--

I've got a specification file:

--
(define base
  `((#:name . "my-spec")
(#:url . "git://git.savannah.gnu.org/guix.git")
(#:branch . "master")  
(#:no-compile? . #t)
(#:load-path . ".")
(#:file . "./guix-drv.scm")
(#:proc . drv-list)))

(list '(base))
--

... the procedures to turn my manifest into a list of derivations,
guix-drv.scm:

--
(use-modules (guix config)
 (guix store)
 (guix grafts)
 (guix packages)
 (guix ui)
 (guix derivations)
 (guix monads)
 (guix profiles)
 (gnu packages)
 (srfi srfi-1))

(define (drv-package store package)
  (lambda ()
`((#:job-name . ,(string-append
  (package-name package)
  "-"
  (package-version package)
  "-job"))
  (#:derivation . ,(derivation-file-name
(parameterize ((%graft? #f))
  (package-derivation store package #:graft? #f)))

(define (drv-list store arguments)
  (let* ((manifest
 (load* "leo.scm"
(make-user-module
 '((guix profiles) (gnu)
 (packages
  (map manifest-entry-item
   (manifest-entries manifest
(parameterize ((%graft? #f))
  (map (lambda (package)
 (drv-package store package))
   (delete-duplicates! packages)
--

... and the manifest, leo.scm:

--
(packages->manifest
 (map (compose list specification->package+output)
  '("coreutils" "nss-certs" "unzip" "bzip2" "which" "tar" "gawk" "vim" 
"bash")))
--


signature.asc
Description: PGP signature

Re: core-updates: biber

[Leo Famulari]

On Mon, Jul 31, 2017 at 09:26:56AM +0200, Ricardo Wurmus wrote:
> We haven’t yet updated the big texlive and texlive-bin packages to the
> 2017 versions.  (Actually, I have tested an update for the texlive-bin
> package, but not for “texlive-texmf”.)
> 
> If we upgrade those two, I’m pretty sure we won’t need Biber 2.5 any
> more and can replace it with what is currently biber-next.
> 
> I would suggest not to spend too much time on Biber 2.5 as it is on its
> way out — it just needs a texlive-texmf update.
> 
> (All of our small tex packages are from the 2017 release of TeX Live.
> We really should just upgrade texlive-texmf and texlive-bin.)
> 
> 
> --8<---cut here---start->8---
> -(define texlive-bin
> +(define-public texlive-bin
>(package
> (name "texlive-bin")
> -   (version "2016")
> +   (version "20170520")
> (source
>  (origin
>   (method url-fetch)
> -  (uri 
> "ftp://tug.org/historic/systems/texlive/2016/texlive-20160523b-source.tar.xz;)
> -  (sha256 (base32
> -   "1v91vahxlxkdra0qz3f132vvx5d9cx2jy84yl1hkch0agyj2rcx8"
> + (uri (string-append 
> "ftp://ftp.rrzn.uni-hannover.de/pub/mirror/tex-archive/systems/;
> + "texlive/Source/texlive-" version "-source.tar.xz"))
> + (sha256 (base32
> +  "0m49ggzgx777nhziji3a5834nfsz87b7k5v546spr7m2kym35860"
> --8<---cut here---end--->8---

I'll try these changes this weekend, unless someone beats me to it --
that would be nice :) AFAIK it's the last blocker for core-updates.


signature.asc
Description: PGP signature

Re: adwaita-icon-theme issue, cannot install GuixSD

[Leo Famulari]

On Wed, Aug 02, 2017 at 02:48:28PM +, Joshua Branson wrote:
> This is probably a question that should be asked on help-g...@gnu.org.  
> guix-devel is really more for development quesitions, not trouble shooting.

Yes, but it's okay :) We can answer it here, too.

> On 08/02/2017 07:27 AM, 8gw72f+eiv9z4mpir...@guerrillamail.com wrote:
> > I cannot install GuixSD because adwaita-icon-theme is broken (unexcepted 
> > end of file). If I'm doing guix pull, then guix fails to check (two tests 
> > are FAIL).

The first issue, with adwaita-icon-theme, can be worked around by
running whichever command failed with the '--fallback'. This will build
from source anything that failed to be downloaded.

Regarding `guix pull`, can you tell us which tests failed?

In general, my advice for installing GuixSD is to start with the
simplest GuixSD system configuration file (typically /etc/config.scm)
that you can boot the new system with. Once you've installed GuixSD, you
can edit your configuration file and reconfigure the system to include
all the bells and whistles.

I recommend this because the installation process is relatively fragile
compared to reconfiguring an installed system. So, if you make the
installation rely on the smallest number of packages and services, you
have a better chance of success.

> > I'm using EFI installation with encrypted root. EFI partition doesn't have 
> > mapped-devices dependency.

I don't have much experience with EFI. Hopefully somebody else has some
advice here.