Re: Configuration System's Handling of Missing Packages

[Ricardo Wurmus]

Keith Osterheld  writes:

> What's the difference between a package being downloaded into /gnu
> instead of the system profile, and when should I use the package module
> instead of installing it normally? To me it seems like the only reason
> for using a package module is for easier deployment, is that right?

*Every* package is installed into /gnu.  Profile generations, too, have
their own directory somewhere in /gnu.  They are *also* linked
elsewhere, such as ~/.guix-profile or the system profile.  When a
package is installed it is first built or downloaded into some place in
/gnu/store, and then a new profile generation in /gnu/store is created,
which contains a link to the new package.

Package modules have nothing to do with package installation.  All
packages in Guix are Scheme expressions bound to names.  These bindings
are *defined* in modules.  If you want to refer to any package
expression by name in a programme or another expression (such as the
system configuration or a manifest) you have to make sure that the
module is loaded in the current file.

~~ Ricardo

Re: some questions about GUIX

[Ricardo Wurmus]

Sam Halliday  writes:

> Ludovic Courtès  writes:
>>> * Integration with existing software distribution managers
>>>
>>> How are you planning on handling these more modern languages that
>>> manage their own dependencies?
>>
>> Currently, we import those languages’ dependency trees into the Guix
>> dependency tree, and so some additional QA (make sure tests pass,
>> provide adequate licensing info, descriptions and synopses, etc.)
>
> OK, I'm not entirely sure what that means for JVM / Maven Central
> applications but it sounds like you're doing something sane.
>
> The important thing for JVM applications is that each jar doesn't end up
> getting tracked as a separate entity, because that just makes it
> infeasible and painful to package anything through the official
> channels.

I’m not sure I understand what you mean here.  I have been packaging a
couple of Java things and the reliance on prebuilt jars and Maven causes
quite a few problems.  This is the single most important reason why
there isn’t much of Java to be found in Guix yet.

Building a full non-trivial Java application from source without
resorting to some black box jars along the way is very difficult.  I’m
still working on slowly packaging the dependencies of log4j, one jar at
a time, ... and I even forgot why I’m working on log4j because the
dependency graph for an arbitrary Java package is overwhelmingly large.

(We have a minimal Ant, though, and I just finished abstracting an
ant-build-system, so packaging is already becoming a little easier and
considerably faster.)

We are building library for library as individual packages in Guix.  We
certainly won’t bundle prebuilt jars from Maven if it can be avoided at
all.

> The main problem I want to avoid is the situation where it can take
> longer to package a small application than it does to write it.

This depends a lot on the development culture fostered by the language
community.  For R packages, for example, packaging is almost trivial.
With the CRAN importer I created Guix package expressions from (almost)
all packages on CRAN within minutes.  Now I just have to look through
the stash for packages that I want to submit to Guix upstream, build
them and that’s it.

For Java, however, it is definitely true (for now) that packaging an
application can certainly take longer than writing one from scratch in a
different language.  This is largely due to the fact that Java
programmes are rarely ever built from source (recursively) as Maven
conveniently takes care of downloading binary artifacts.

I suppose we could have a Maven importer in due time that converts the
information contained in pom.xml files to a Guix package expression.  We
won’t have to be using Maven itself.  This would make packaging Java
libraries and applications about as easy as it is now to package R
packages from Bioconductor or CRAN.

>> Guix’s build daemon uses containers to perform isolated builds:
>>
>>   http://www.gnu.org/software/guix/manual/html_node/Features.html
>
> Interesting. I wonder if you wouldn't benefit from a docker / drone
> network, just as a distribution mechanism for your own build farm. It
> would be a shame to expend effort on that since it is somewhat something
> of a solved problem (and purely a DevOps matter, not a user concern).

Work is under way to distribute build artifacts over GNUnet.  Currently
it is already possible to share build results over HTTP.  Ideally,
package building is a distributed effort.  (We aren’t there yet.)

>>> * Issue tracker / comm channels
>>>
>>> Will you be continuing to use debbugs, savannah and mailing lists going
>>> forward or would you consider moving to a modern community management
>>> system like gitlab?
>>
>> I hear the appeal of GitLab and the like.  However, as was recently
>> discussed on guix-devel, while I think we must find ways to improve our
>> workflows (for instance, tracking patches is becoming tricky), I don’t
>> see us moving to one of those web-based approaches for several reasons:
>>
>>   https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00429.html
>
> I've never used GitLab, but I understand that it is free software. The
> thread above seems to suggest that it is proprietary.

There are two variants AFAIU; the hosted GitLab service uses the
proprietary version.

Although I personally started contributing to free software projects
regularly only at the time when Github came around (before that it was
quite awkward for me to send patches via email), I have come to really
appreciate the mail-based workflow we have for GNU projects.

Savannah certainly isn’t pretty (and I only used the web interface once
or twice to get the info I needed to get started), and I find debbugs
somewhat hard to use, but I think using mailing lists for discussing
patches (but not to keep track of them) is vastly superiour to the
workflow imposed by Github and similar systems.

~~ Ricardo

Re: some questions about GUIX

[Ricardo Wurmus]

Sam Halliday  writes:

> Does this mean that you have a GUIX package for every jar?

Some packages may provide more than one jar archive.  This depends on
what the build system prescribes.  For every *project* there will be at
least one jar, though.

> If so, can
> you have multiple versions of the same jar installed at the same time?

Yes!  This is a core feature enabled by functional package management.
We treat packages as if they were pure functions in that the exact same
set of inputs (source tarballs, compilers, libraries, and their own
inputs, and the inputs of those inputs, etc...) produces the exact same
output.  Instead of computing the output from scratch each time we want
to use the value (e.g. as an input to another package or in a profile)
we can cache or memoise it.  We do this by storing the unique output
artifact for a given bag of inputs in /gnu/store; outputs are prefixed
with a unique hash that is computed from all inputs.

Installing a package then is little more than the act of linking
individual items from the store into a profile.  We can store any
package output in /gnu/store because they all have their very own
directory; they don’t overlap.  Thus we can install/link different
versions into different profiles.
 
> Support for multiple versions of a library will be necessary as it is
> not always a simple case of bumping the version to use a library: many
> libraries introduce breaking changes at both source and binary level.

Correct.  We don’t have a problem with this as we never install anything
into a “global” namespace (such as /usr, /lib, or whatever).

> Will you be using the same version names as the official upstream
> binaries? I strongly recommend against doing this. The convention in
> corporate environments is that rebuilds of jars incur a postfix to their
> version. E.g. a rebuild of guava 18.0 (even with no changes to the
> sources) would be 18.0-guix1. Of course, there is no way for you to know
> that jars are not being loaded by name at runtime through the
> classloader, so you introduce further opportunity for bugs here.

FWIW Debian builds Java libraries from sources, too, and they do not
rename the resulting jars.

There is really no need to do that in Guix anyway, because installing
these jars is not going to affect global state — they are not installed
in well-known global directories, so they cannot be “picked up” by
accident.

There is, of course, one potential issue with building Java stuff on
Guix that I haven’t assessed yet.  I don’t yet know if there’s something
in the Java world that’s similar to the RUNPATH feature in native
applications, or if visibility of jars is determined exclusively by the
clunky CLASSPATH environment variable instead.  If there is no way to
“link” jars explicitly by their full path, then dependencies need to be
propagated and applications may need to be wrapped in an appropriate
CLASSPATH, which is somewhat inelegant, but not a real problem.  (This
is done for Python, R, Perl, and Ruby applications in Guix already,
because these languages control module visibility primarily through
environment variables.)

Re: some questions about GUIX

[Ricardo Wurmus]

Sam Halliday  writes:

> Thanks Ricardo,
>
> Ricardo Wurmus writes:
>> I’m not sure I understand what you mean here. I have been packaging a
>> couple of Java things and the reliance on prebuilt jars and Maven
>> causes quite a few problems. This is the single most important reason
>> why there isn’t much of Java to be found in Guix yet.
>
> If the GUIX-SD goal is to build every package from source, then I can
> see why you're doing it this way. It is possible to achieve this noble
> goal, but you are embarking on an absolutely *gigantic* mission.

It can be quite difficult to do this because many people seem to think
that it’s good enough to be able to build something with a binary
version of the very same thing.

For example: gradle needs gradle and groovy to be built, groovy needs
gradle and groovy to be built.  So you are encouraged to take their
binaries and use those to build binaries — that you already have, so
what is the point of building new binaries again...?

Whenever we have to bootstrap language environments we try hard to find
ways that do not require trust to be placed in binary blobs.

>> Building a full non-trivial Java application from source without
>> resorting to some black box jars along the way is very difficult. I’m
>> still working on slowly packaging the dependencies of log4j, one jar
>> at a time, ... and I even forgot why I’m working on log4j because the
>> dependency graph for an arbitrary Java package is overwhelmingly
>> large.
>
> I'm not sure I would refer to Maven Central binaries as "black box". The
> jars on Maven Central are digitally signed by the distributors and the
> source jars are available beside them, with meta data such as license
> and homepages available in the pom file.

We have the sources, so we should be able to build the binaries.  If we
cannot do that then the sources are really just unreliable/untrustworthy
documentation.  There is no clear relationship between published sources
and published binaries.  Users have no way of making this connection.
They have to trust that these binaries correspond to the published
sources.  We shouldn’t *have* to trust.

> It should not be difficult to set up Maven and Ivy to only use a
> GUIX-hosted repository (many organisations do this), or a local
> repository, but it will involve an incredible amount of effort to
> actually *rebuild* everything, as you are discovering.

You can continue to use Maven or any other repository.  But for Guix
packages we will just download binary artifacts.  We don’t do this for
any other language either (e.g. we don’t just download Ruby gems from
rubygems.org).  If people really want to use those artifacts they can
just continue to use “mvn” or “gem”.  Guix won’t stop them from doing
this.  But like any other GNU distribution the packages we provide will
not use pre-built binary artifacts.

~~ Ricardo

Re: Fwd: warning: collision encountered

[Ricardo Wurmus]

carl hansen  writes:

> 2354 packages in profile

What command did you use to install 2354 packages into your personal
profile?  Why would you install 2354 packages in your profile?

There are packages that provide files of the same name; for example
“samtools-0.1” and “samtools” both provide “$out/bin/samtools”.  When
they are both installed in the same profile, there is an obvious
collision.  People don’t install both these packages into the same
profile, because there is no way to disambiguate the colliding files.
Instead they will install them into *different* profiles using something
like

guix package -p /path/to/profile -i samtools

If you feel the need to install all available packages into your profile
you’re doing it wrong.  Each package has its own directory in
“/gnu/store”, but profiles are the union of the files of each of the
directories of selected packages; at this point collisions may arise.

To resolve serious collisions remove one or the other package from your
profile.  Install it in a separate profile instead.

~~ Ricardo

Re: developing for guix with git

[Ricardo Wurmus]

Nils Gillmann  writes:

> Do you happen to know why guix in the situation I described,
> being on an up to date branch following master refuses to build,
> but once I switch to master branch, make clean, make clean-go (or
> go-clean?) and run make (and the other commands) again it builds
> successfully? This was my initial confusion.

It’s hard to say without being able to take a look at the state of the
branch.  It is possible that a change you introduced in your branch
broke things.  Maybe you could share error messages?

> I might have a thing or 2 to learn about rebasing and branching, but in
> theory from what I know it shouldn't really matter which branch I am
> on unless something's corrupted or broken.

I think of a branch as a pointer to a some commit in the graph.
Rebasing takes a range of commits and applies the changes they introduce
on top of some other commit.

When things suddenly break after rebasing the reason is usually in of
two categories:

* one of your (now relocated) commits broke something

* after rebasing, master commits that have been added since you first
  committed your changes are now part of the history of your commits —
  maybe these commits altered assumptions that were still valid when you
  first committed your changes.  An example for this is when a variable
  was renamed or moved in a master commit and your commits still use the
  old name.

Sharing some error output with us might help us identify what’s going on
in your case.  In any case, you could try bisecting your changes (divide
the set of your commits in half, and see if things are broken at that
commit; then recurse until you find the commit that introduced the cause
for the failure).  This works best when you made many small commits.

I’m using multiple branches for things that take me too long.  For most
developments, however, I’m working in a local “wip” branch, which is
regularly and in short intervals rebased onto master.

~~ Ricardo

Re: developing for guix with git

[Ricardo Wurmus]

Nils Gillmann  writes:

> Leo Famulari  writes:
>
>> On Tue, Feb 02, 2016 at 10:28:25PM +0100, Nils Gillmann wrote:
>>> Ricardo Wurmus  writes:
>>> 
>>> > Nils Gillmann  writes:
>>> >
>>> >> Do you happen to know why guix in the situation I described,
>>> >> being on an up to date branch following master refuses to build,
>>> >> but once I switch to master branch, make clean, make clean-go (or
>>> >> go-clean?) and run make (and the other commands) again it builds
>>> >> successfully? This was my initial confusion.
>>> >
>>> > It’s hard to say without being able to take a look at the state of the
>>> > branch.  It is possible that a change you introduced in your branch
>>> > broke things.  Maybe you could share error messages?
>>> 
>>> I'll inline all the things here now:
>>
>> [...]
>>
>>> ;;; ERROR: Unbound variable: git-fetch
>>
>> Did you import (guix git-download)?
>
> I am not sure.
> Adding to the Email I just wrote to this thread, how would I do this?

Leo means to add this to the file you have edited (lisp.scm).
Currently, there’s only

  #:use-module (guix download)

but you need to also add

  #:use-module (guix git-download)

if you’re using the ‘git-fetch’ procedure.  Because ‘git-fetch’ is
undefined otherwise Guile fails to load “lisp.scm” and this failure
cascades through everything else.

It would certainly be nice if the actual error would appear on the last
line instead of one of the errors resulting from not being able to load
“lisp.scm”.

~~ Ricardo

leaky pipelines and Guix

[Ricardo Wurmus]

Hi Guix,

although I’m comfortable packaging software for Guix I’m still not
confident enough to tackle bioinformatics pipelines, as they don’t play
well with isolation.

In the pipeline that I’m currently working on as a consultant packager
I’m trying to treat the pipeline itself as a first-class package.  This
means that the locations of the tools it calls out to are all
configurable (thanks to auto{conf,make}) and they certainly do not have
to be in the PATH.  This allows us to install this pipeline (and the
tools it needs) easily alongside other variants of tools.  The pipeline
is also not just a bare Makefile but has a wrapper script to provide a
simplifed user interface.

However, most pipelines do not take this approach.  Pipelines are often
designed as glue (written in Perl, or as Makefiles) that ties together
other tools in some particular order.  These tools are usually assumed
to be available on the PATH.  Pipelines aren’t treated enough like
packages (which will be the subject of an inflammatory, click-baiting
blog post that I’m working on), so they usually come without a
configuration script to override implicit assumptions.

In the context of Guix this means that each pipeline would need its very
own isolated environment where the PATH is set up to contain the
locations of all tools that are needed at runtime (that’s what I mean by
“leaky”).  As many pipelines do not come with wrapper scripts there is
no easy way to sneakily set up such an environment for the duration of
the run.

So, how could I package something like that?  Is packaging the wrong
approach here and should I really just be using “guix environment” to
prepare a suitable environment, run the pipeline, and then exit?  I know
that there is work in progress to support profile-based environments
that would make this a little more feasible (as the environment wouldn’t
be as volatile as they are now), but it seems somewhat inconvenient.

This pains me especially in the context of multi-user systems.  I can
easily create a shared profile containing the tools that are needed by a
particular pipeline and provide a wrapper script that does something
like this (pseudo-code):

bash
eval $(guix package --search-paths=prefix)
do things
exit

But I wouldn’t want to do this for individual users, letting them
install all tools in a separate profile to run that pipeline, run
something like the above to set up the environment, then fetch the
tarball containing the glue code that constitutes the pipeline (because
we wouldn’t offer a Guix package for something that’s not usable without
so much effort to prepare an environment first), unpack it and then run
it inside that environment.

To me this seems to be in the twilight zone between proper packaging and
a use-case for “guix environment”.  I welcome any comments about how to
approach this and I’m looking forward to the many practical tricks that
I must have overlooked.

~~ Ricardo

Re: What prevents "guix package --profile" profiles from being gc'ed?

[Ricardo Wurmus]

Alex Kost  writes:

> Christopher Allan Webber (2016-02-25 03:30 +0300) wrote:
>
>> I'm a bit confused about profile management for profiles that *aren't*
>> your system or default user profile.
>>
>>   guix package --profile=/home/cwebber/guix-profiles/test -i hello
>>
>> then I run "guix gc", it seems like that profile is still kept around.

[...]

>> What's keeping that profile around?  Will it ever get gc'ed?  Is it
>> somehow recorded in Guix's state files?
>
> Look at /var/guix/gcroots/auto/.

It would be nice to have a user interface for that, too, so that users
can quickly get an overview on all their custom profiles that may be
littered across local and remote filesystems.

What do you think?

~~ Ricardo

Re: Export archive and import it on another machine

[Ricardo Wurmus]

白い熊＠相撲道  writes:

> Then I was able to import libreoffice to the store — the directory is there.
>
> However, it's not installed in my profile — “guix package -I” doesn't
> list it. Running “guix package -i libreoffice” again wants to rebuild
> it. How do I install the one that's been imported to the store?

You can run

guix package -i /gnu/store/...-libreoffice-...

i.e. install the particular store item into your profile.

~~ Ricardo

Re: leaky pipelines and Guix

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:
>
>> So, how could I package something like that?  Is packaging the wrong
>> approach here and should I really just be using “guix environment” to
>> prepare a suitable environment, run the pipeline, and then exit?
>
> Maybe packages are the wrong abstraction here?
>
> IIUC, a pipeline is really a function that takes inputs and produces
> output(s).  So it can definitely be modeled as a derivation.

This may be true and the basic abstraction you propose seems correct and
useful, but I was talking about existing pipelines.  They have already
been implemented using snakemake or make to keep track of individual
steps, etc.  My primary concern is with making these pipelines work, not
to rewrite them.

For a particularly nasty pipeline I’m just using a separate profile
just for the pipeline dependencies.  Users build the pipeline glue code
themselves by whatever means they deem appropriate and then load the
profile in a subshell:

bash
source /path/to/pipeline-profile/etc/profile
# run the pipeline here
exit

I think that these existing bio pipelines should really be treated more
like configurable packages.  For a pipeline that we’re currently working
on I’m involved in making sure that it can be packaged and installed.
We chose to use autoconf to substitute tool placeholders at configure
time.  This allows us to install the pipeline easily with Guix as we can
treat tools just as regular runtime dependencies.  At configure time the
actual full paths to the needed tools are injected into the sources, so
we don’t need to propagate anything and make assumptions about PATH.

Many problems with bio pipelines stem from the fact that they are not
treated as first-class applications, so they often don’t have a wrapper
script, nor a configuration or installation step.  I think the easiest
way to fix this is to encourage the design of pipelines as real software
packages rather than distributing bland Makefiles/snakefiles and
assuming that the user will arrange for a suitable environment.

~~ Ricardo

Re: Typing on GuixSD in languages other than English

[Ricardo Wurmus]

Chris Marusich  writes:

> How can I verify that ibus is working on its own?  I've tried installing
> ibus by itself into my profile.  When I do this, I can run ibus-setup,
> and I see a "Japanese" language input option.  This is true even when
> anthy and ibus-anthy are not installed, which surprised me. I had
> expected to find no Japanese language input options at all in ibus-setup
> when anthy and ibus-anthy are not installed.

It’s a bit tricky.  IBus caches input methods and reads them from the
cache.  This is also the reason why IBus breaks whenever it is updated
(see bug #22707).

This cache is in “~/.cache/ibus/bus”.

Another thing you might need to store settings for IBus is to run
“libexec/dconf-service” of the “dconf” package.

Then I had to set

IBUS_COMPONENT_PATH=$HOME/.guix-profile/share/ibus/component

and the usual

QT_IM_MODULE=ibus
XMODIFIERS=@im=ibus
GTK_IM_MODULE=ibus

You will also need

GUIX_GTK2_PATH=$HOME/.guix-profile/lib/gtk2.0
GUIX_GTK3_PATH=$HOME/.guix-profile/lib/gtk3.0

so that GTK+ can find the input method modules for ibus in your profile.
Then it should work in a GTK+ application such as “xfce4-terminal”.
Don’t try it in Emacs because it probably won’t work without even more
fiddling.

This is all not nice yet and I’ve only managed to get the Pinyin input
method to work (until the next upgrade).  I haven’t been able to get any
of the included input methods (like Arabic) to work at all.

This needs more work and I’d appreciate some assistance!

~~ Ricardo

Re: Is there a beginner's guide to using Guix with Scheme files?

[Ricardo Wurmus]

Zachary Kanfer  writes:

> Yes, this is *exactly* what I was looking for. Thanks incredibly.
>
> It took me a while to realize that the package module for racket was
> "scheme". I figured this out after getting an error with "racket", and then
> looking at the "location" field of the output of `guix package -s racket`.
> I assume the package module for any package is the last token in
> "gnu/modules/.scm? Are there packages not rooted in
> "gnu/modules"?

All package modules can be found at “gnu/packages/”.  A package is just
a value bound to a name, so a single module can hold one or many
packages.  An example for a module with a great number of packages is
“gnu/packages/python.scm”.

~~ Ricardo

Re: Typing on GuixSD in languages other than English

[Ricardo Wurmus]

Chris Marusich  writes:

> iyzs...@member.fsf.org (宋文武) writes:
>
>>> Chris Marusich  writes:
>>>
 Awesome!  Where you able to get this working?  I've tried installing it
 From the version you pushed, and I still can't get it to work.  Even
 when I set all the environment variables mentioned, and I install all
 the packages (ibus, ibus-anthy, and anthy) to my profile.  If you got it
 working, I'd like to know how so I can set it up on my end, too.
>>
>> Yes, I only tested in xterm.
>> set the environemnt variables, run ‘ibus-daemon –-xim -v’.
>> then use ‘ibus-setup’ to add ‘Japanese - Anthy’.
>> in xterm, ‘Super+Space’ work fine.
>>
>>
>> For GTK+ applications, I have to generate the ‘immodules.cache’ file:
>>
>> GTK_IM_MODULE_FILE=/tmp/immodules.cache gtk-query-immodules-3.0 
>> -–update-cache
>>
>> GTK_IM_MODULE_FILE=/tmp/immodules.cache gtk3-demo –-run search_entry
>>
>>
>> With the cache (it contains ibus), it will work.
>
> Thank you so much for the tips!  I've finally gotten ibus-anthy working
> (partially)!  However, I've encountered some additional
> problems/questions, and I hope you can provide some advice:
>
> * When I set up GTK_IM_MODULE_FILE like you've suggested, it works only
>   for GTK3 applications.  Applications using GTK2 crash due to some kind
>   of a version incompatibility problem [1].  However, if I generate the
>   immodules cache file with "gtk-query-immodules-2.0", then the same
>   thing happens in reverse: GTK2 applications work with Japanese input,
>   but GTK3 applications crash.  Do you know of a way we can get it
>   working for both GTK2 and GTK3 applications simultaneously?

This is the reason why we have GUIX_GTK2_PATH and GUIX_GTK3_PATH.  I
don’t set GTK_IM_MODULE_FILE.

> * If the ibus cache in $HOME/.cache/ibus exists, then installing
>   ibus-anthy will APPEAR to have no effect.  The only way I was able to
>   get GNOME's control panel ("All Settings" > "Region & Language" >
>   "Input Sources") or ibus-setup to recognize the "Japanese (Anthy)"
>   input method after installing ibus-anthy was to invoke "rm -rf" on the
>   $HOME/.cache/ibus directory and then restart ibus-daemon (e.g., by
>   restarting the xorg-server service).  To make it easier to install and
>   use ibus-anthy, there a way we can ensure that the ibus cache is
>   refreshed when the user installs ibus-anthy?

The cache is a problem.  It’s annoying also when upgrading IBus.  We
should patch IBus to improve this.

~~ Ricardo

Re: Switching to GuixSD - some packages missing for me

[Ricardo Wurmus]

Divan Santana  writes:

> 1) virt-manager - Since I may rely on a few VMs more as GuixSD has
> limited packages for now. Unless there is another easy way to run VMs?
> I'm not too familar with using qemu directly...

virt-manager is on my list of packages, but I haven’t yet found the time
to make it happen.  Hopefully soon.

> For the most part is seems almost all the essentials for me are there.
>
> Excited to see the progress with the distro. Wish you all the best of
> luck and hope one day in the future to get involved - can't at the moment.

I encourage you to play with Guix.  Packaging is really quite simple in
most cases.  Certainly not more complicated than writing PKGBUILD files.

Note that you can also run Guix as a package manager on top of your
current GNU system.

~~ Ricardo

Re: viewport declaration in the manual

[Ricardo Wurmus]

Catonano  writes:

> I know this is marginal, but it bothers me
>
> The Guix manual is not readable on mobile phones. It seems to me that the
> viewport declaration is missing
[...]
> Because I don't know the first thing about Texinfo, I don't know if this
> can be accomodated by the Guix project (maybe the build phase could feed
> Texinfo a revised html template) or of this requires the whole Texinfo
> project to be patched.

As far as I know we can freely choose a custom stylesheet.  Texinfo
produces only HTML and makes it use the specified stylesheet.

Could you please send a copy of this email to bug-g...@gnu.org, so that
we can keep track of this in the bug tracker?

Thank you!

~~ Ricardo

Re: cleaning the store

[Ricardo Wurmus]

Leo Famulari  writes:

> On Thu, May 26, 2016 at 08:16:59PM +0200, Catonano wrote:
>> There are only 2 profiles on this machine: mine and root's profile
>> 
>> As for mine, I eliminated ALL previous generations and emacs-cider is not
>> installed in the current one
>> 
>> As for root's profile:
>> 
>> $ guix package -p root --list-installed
>> 
>> returns nothing
>> 
>> 
>> and
>> $ guix package -p root --list-generations
>> guix package: error: profile 'root' does not exist
>
> I think the argument to '-p' is the generation of the profile (an
> integer). You should try running it as root, since I doubt you can read
> root's profiles as an unprivileged user.

No, “--profile” or “-p” expects a *path* to a profile.  For root’s
profile you would either be root and use the default (no “-p” option),
or use “-p /root/.guix-profile” or similar, provided you have read
access to this file.

~~ Ricardo

Re: GUIX_LOCPATH problems with guix on gentoo

[Ricardo Wurmus]

Hi,

I found it very hard to read this email, because there are so many
non-essential things pasted in the body :-/

I hope I didn't miss anything important while I paged through your
email, but one thing stood out to:

ng0  writes:

> python: stdout/stderr: import json
>   
>   perl: warning: Falling back to the standard locale ("Cpython: 
> stdout/stderr:   File "/usr/lib/python2.7/json/__init__.py", line 108, in 
> 
> python: stdout/stderr: from .decoder import JSONDecoder
> python: stdout/stderr:   File "/usr/lib/python2.7/json/decoder.py", line 
> 5, in 
> python: stdout/stderr: import struct
> python: stdout/stderr:   File "/usr/lib/python2.7/struct.py", line 1, in 
> 
> python: stdout/stderr: from _struct import *
> python: stdout/stderr: ImportError: 
> /usr/lib/python2.7/lib-dynload/_struct.so: undefined symbol: PyUnicode

That's not okay.  You cannot mix Python from your system with Python
from Guix.  Do you have system stuff on your PYTHONPATH?  Do you have
LD_LIBRARY_PATH set?  Guix packages should never use system libraries.

~~ Ricardo

Re: GUIX_LOCPATH problems with guix on gentoo

[Ricardo Wurmus]

ng0  writes:

> On 2016-06-18(09:45:12+0200), Ricardo Wurmus wrote:
>>
>> Hi,
>>
>> I found it very hard to read this email, because there are so many
>> non-essential things pasted in the body :-/
>
> I wasn't sure what's useful information and what's not.
>
>> I hope I didn't miss anything important while I paged through your
>> email, but one thing stood out to:
>>
>> ng0  writes:
>>
>> > python: stdout/stderr: import json 
>> >
>> > perl: warning: Falling back to the standard locale ("Cpython: 
>> > stdout/stderr:   File "/usr/lib/python2.7/json/__init__.py", line 108, in 
>> > 
>> > python: stdout/stderr: from .decoder import JSONDecoder
>> > python: stdout/stderr:   File "/usr/lib/python2.7/json/decoder.py", 
>> > line 5, in 
>> > python: stdout/stderr: import struct
>> > python: stdout/stderr:   File "/usr/lib/python2.7/struct.py", line 1, 
>> > in 
>> > python: stdout/stderr: from _struct import *
>> > python: stdout/stderr: ImportError: 
>> > /usr/lib/python2.7/lib-dynload/_struct.so: undefined symbol: PyUnicode
>>
>> That's not okay.  You cannot mix Python from your system with Python
>> from Guix.  Do you have system stuff on your PYTHONPATH?  Do you have
>> LD_LIBRARY_PATH set?  Guix packages should never use system libraries.
>>
>> ~~ Ricardo
>
> In the beginning this was an experiment, to see if Guix
> would run unaffected on a gentoo-hardened kernel.
> I am switching back to a desktop/amd64 profile, will check if
> things changed.

The problem above is unrelated to the kernel.  For some reason libraries
from /usr/lib are used.  If this really is a Guix package then that’s
wrong.

> Checking right now, LD_LIBRARY_PATH and PYTHONPATH are not set,
> but LIBRARY_PATH is.

LIBRARY_PATH is harmless and only used at compile time.

~~ Ricardo

Re: Microscheme failed

[Ricardo Wurmus]

Hi Daniel,

> I try compile to Arduino plataform using Microscheme (installed with: 
> guix package -i microscheme) on GuixSD, but there are errors.
>
> I did:
> sudo microscheme -m UNO -d /dev/ttyACM0 -au lightom.ms

This is unrelated but I recommend not using “sudo” here.  You can add a
udev rule to your system configuration to change the ownership of
/dev/ttyACM0.

For my AVR programmers I have this in my system configuration:


(define avrispmkii-udev-rule
  (udev-rule "90-avrispmkii.rules"
 "\
SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"

# Atmel Corp. JTAG ICE mkII
ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\", 
GROUP=\"dialout\"
# Atmel Corp. AVRISP mkII
ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\", 
GROUP=\"dialout\"
# Atmel Corp. Dragon
ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\", 
GROUP=\"dialout\"

LABEL=\"avrisp_end\"\n"))

(operating-system
  …
  (services (cons* (modify-services %desktop-services
 (udev-service-type config =>
(udev-configuration
 (inherit config)
 (rules (append 
(udev-configuration-rules config)
(list 
avrispmkii-udev-rule


> Errors:
> ...
>>> 32 lines compiled OK
>>> Assembling...
> avr-ld: cannot find crtatmega328p.o: No such file or directory

This is a bug in our AVR toolchain.  The internal search path for these
files appears to be wrong.  What I did was copy the “crt*.o” file I
needed to my working directory.  Maybe you can send an email to
bug-g...@gnu.org to report this as a bug?

> I have avr-gcc avr-libc avrdude avr-binutils avr-toolchain installed.

You only need “avr-toolchain” as it contains all the other packages.

~~ Ricardo

udev rules and system configuration (was: Microscheme failed)

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> Ricardo Wurmus  skribis:
>
>> For my AVR programmers I have this in my system configuration:
>>
>> 
>> (define avrispmkii-udev-rule
>>   (udev-rule "90-avrispmkii.rules"
>>  "\
>> SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"
>>
>> # Atmel Corp. JTAG ICE mkII
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\", 
>> GROUP=\"dialout\"
>> # Atmel Corp. AVRISP mkII
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\", 
>> GROUP=\"dialout\"
>> # Atmel Corp. Dragon
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\", 
>> GROUP=\"dialout\"
>>
>> LABEL=\"avrisp_end\"\n"))
>>
>> (operating-system
>>   …
>>   (services (cons* (modify-services %desktop-services
>>  (udev-service-type config =>
>> (udev-configuration
>>  (inherit config)
>>  (rules (append 
>> (udev-configuration-rules config)
>> (list 
>> avrispmkii-udev-rule
>> 
>
> Should we add this as an optional service or to the default set of udev
> rules?

I don’t think this should be the default.  This rule is only useful for
those who own one of Atmel’s USB programmer devices.  There is a
multitude of programmers for AVRs and users may want to use different
rules for different devices.

However, I’ve been wondering if we shouldn’t introduce nicer
abstractions for udev rules and make loading them a little less verbose.
It’s a bit unfortunate that while on other systems users are often told
to just dump a file somewhere in “/etc” to make device access work
without root on GuixSD it’s quite a bit more involved to achieve the
same.

Our documentation is also a little lacking in this respect.  The manual
has very little to say about the “udev-service” and how to extend it (or
any of the other services, really), making it hard for users coming from
other systems to find where they need to change something to make the
udev rules work that they were told to add somewhere.

Here’s an idea, which might be bad: how about adding a feature to load
and merge a directory tree of configuration files as they are?  For
example, if I had a directory “/etc/guix/system/udev/rules.d” then all
files therein would automatically be considered part of the system
configuration, maybe after adding “/etc/guix/system” as a prefix path to
some new field in the “operating-system” declaration.

I have a feeling that this will be considered a bad idea, but it also
seems to me that it would make the configuration of some parts of the
system easier than embedding file contents as strings in variables in
“/etc/config.scm” and modifying services manually.

~~ Ricardo

Re: udev rules and system configuration

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Ricardo Wurmus  skribis:

>> Here’s an idea, which might be bad: how about adding a feature to load
>> and merge a directory tree of configuration files as they are?  For
>> example, if I had a directory “/etc/guix/system/udev/rules.d” then all
>> files therein would automatically be considered part of the system
>> configuration, maybe after adding “/etc/guix/system” as a prefix path to
>> some new field in the “operating-system” declaration.
>>
>> I have a feeling that this will be considered a bad idea, but it also
>> seems to me that it would make the configuration of some parts of the
>> system easier than embedding file contents as strings in variables in
>> “/etc/config.scm” and modifying services manually.
>
> It’s a bad idea!  :-)
>
> Seriously, I think having a directory that is automatically picked up is
> a bad idea in the sense that it would defeat one of the main goals of
> GuixSD, which is to support reproducibility.  The hypothetical
> /etc/guix/udev directory would not be controlled by GuixSD, so rolling
> back wouldn’t be enough to return to the previous state, copying the
> GuixSD config file wouldn’t be enough to duplicate the system state on
> another machine, and so on.

These files are not loaded at system runtime but upon running “guix
system reconfigure”.  Their contents *at that time* would be embedded in
the configuration.  Their state *at runtime* would not matter (just like
the contents of “config.scm” don’t matter at runtime).

The files would become part of the configuration in the store.  Changing
them would always require the additional step of reconfiguring the
system.

> However, what we can do is improve the interface.  Things that come to
> mind:
>
>   1. Change or remove the ‘udev-rule’ procedure; we should be using
>  file-like objects instead, so one could store them alongside
>  config.scm and write:
>
>(local-file "./my-udev-rule")

Is this really so different from the bad idea I proposed?  As soon as we
load files outside of “config.scm” users would need to copy more than
just the GuixSD config file to duplicate the system state on another
machine.  In this example we would need both “config.scm” and
“my-udev-rule” in the same directory.

The bad idea still requires a user to tell Guix to load udev rule files
from somewhere.  The difference is that instead of loading files
individually by name it would load *all* rules from the directory.

I guess it’s not very different form what you propose in #3, actually.

>   2. Add a ‘extra-udev-rule’ procedure that you could use like this:
>
>(operating-system
>  ;; …
>  (services (extra-udev-rule (local-file "./my-udev-rule"))
>…))
>
>  thus avoiding the verbose ‘modify-services’ stanza.
>
>   3. (Instead of #2) Introduce a ‘udev-rules’ field in
>  ‘operating-system’, just like we do for firmware.
>
> WDYT?

I don’t know.  Although this would simplify configuration I don’t really
like either of them for somewhat conflicting reasons.  #3 gives special
treatment to udev rules (“What about Xorg config snippets?”), and with
#2 it seems like an unnecessary implementation detail that this
“extra-udev-rule” procedure is inside of the “services” field (“How come
this is a service?”).

I also feel that we should avoid adding “special” syntax.  Actually, I
really like how generic this whole “modify-services” business is.  It’s
just a little too verbose to be user-friendly, in my opinion.

~~ Ricardo

Re: GuixSD on arm

[Ricardo Wurmus]

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

> - Patches would get lost regularly.

Yeah, this is still a problem for me.  Many patches slip by because I
have no capacity to review them in time.  I have settled on reviewing
things that I feel I’m a little more qualified to review than others,
such as R packages, scientific software, audio software.  But it’s
really tough to review things *well* and in time.

In my opinion, patchwork hasn’t improved this, unfortunately, because
patch management requires too much effort (patches aren’t reliably
marked as merged, no email control, etc).

> I'm not cut out to what feels like nagging people when I don't know the 
> reasons
> why they haven't replied. Perhaps this is how things work in other systems, 
> but
> as someone that suffers from social anxiety and finds it hard enough to even
> send patches I can't deal with this, and Guix seems to be doing fine without 
> me.

I’m sad to hear that this makes it hard for you to continue to
contribute to Guix.

In my case a lack of a response is usually just a result of having too
many other things to work on.  Sometimes it’s because I really don’t
feel qualified to answer (as in the case of LUKS+Libreboot because at
that time I didn’t have any experience with Libreboot).

> As patches were lost and most discussion was done on the mail list, there was
> basically no discussion on patches or design problems. After getting Guix to
> boot on my Libreboot machine I went to work on fixing issues with the boot
> system, such as adding support for legacy Libreboot systems and encrypted
> bootloaders. This was lost.
>
> I also did some work to get LVM+LUKS working on Guix and tried to spark a
> discussion in to fixing the design issues in system configuration. I think 
> there
> was about one reply, and it was lost.

Now that my laptop is running Libreboot I’m actually looking at the
discussions you started to see how we can move forward there.  Thank you
for your experimentation and documenting your work on the mailing list!
I can assure you that it’s not lost (just not used in the moment).

> This experience has put me off of Guix, GNU and free software development. I
> don't blame any one, but more a system that doesn't incorporate people like 
> me.

That’s sad and I hope you will be able to reconsider some time in the
future as the project matures.

~~ Ricardo

AUR for GuixSD (was: GuixSD on arm (ng0))

[Ricardo Wurmus]

Hi David,

> I don't see guixsd as a linux distro but more as a linux distro
> building kit.

I cannot resist… :) We see GuixSD as a variant of the GNU system.  (I
think the term “linux distro” had its run and can be retired now.)

> Also on a related issue. At some point we may want something like the
> AUR for packages that don't comply with the guix packaging guidelines
> (for example linux-firmware). Or that have few users. So if I want to
> write my own bootloader and convince my friends to use it - it should
> not be in the guix tree, but it would be nice if there were a way to
> publish my package. This is something I missed in nixos.

This already exists or doesn’t, dependent on your point of view.  Guix
honours the GUIX_PACKAGE_PATH environment variable.  Any collection of
package modules in one of the directories mentioned in that variable
will be usable by Guix.  At the institute we use this for a local
collection of packages[*].

*Anyone* can put together a repository and tell people to download it
and add it to the GUIX_PACKAGE_PATH.  It’s a lot like Ubuntu’s ppa in
that regard.  Anyone could start a “GUR” (Guix User Repository) project
and try to convince others to use it.  We prefer to have most packages
in Guix itself, though.  Packages that do not match the Free System
Distribution Guidelines (GNU FSDG), however, won’t be added to Guix
upstream and also won’t be endorsed or advertised by the Guix project.
This also means that we do not welcome recommendations to use non-free
software on the mailing lists or the #guix IRC channel.

~~ Ricardo


[*]: We do this primarily for the sake of reproducibility, secondarily
for adding packages and package variants that are not useful or cannot
be in Guix upstream.  We use an unaltered version of the Guix upstream
repository, and we have a separate package repository.

Whenever a new free software package is needed I add it on my
development branch and send a patch upstream for review.  Immediately
afterward I backport it to our separate repository.  Both repositories
are accessible on the Internet, which allows users to fully describe the
state of their profiles with three things:

- the hash-like value returned by “git describe /path/to/guix”
- the hash-like value returned by “git describe /path/to/our/guix-addon”
- a manifest

Keeping things separate allows us to describe the state fully without
having to publish a modified version of the full Guix repository.  Other
scientists can just take the two repositories and reset them to the
given hashes, and then instantiate the manifest.

Re: AUR for GuixSD (was: GuixSD on arm (ng0))

[Ricardo Wurmus]

David Craven  writes:

> So how rigid are you on the gnu system thing? Was jookia right that
> you won't accept patches that will make guixsd a gnu system or
> something else? ;-) I did some work on using musl as a libc on nixos
> for embedded systems, I came here because I thought it was more
> hackable. I guess if you're not interested in uboot, this is a non
> starter...

We don’t restrict packages in Guix to only GNU packages.  For embedded
systems I have packaged newlib (a C library to be used instead of glibc)
and there is nothing in our guidelines that would speak against having a
package like that.

I also don’t know where the claim “you’re not interested in uboot” comes
from.  I consider it false.

>> This also means that we do not welcome recommendations to use non-free
> software on the mailing lists or the #guix IRC channel.
>
> Does this mean you prefer people not to use the "gnu system" then to
> use it with non-free firmware? I prefer free firmware to non-free
> firmware too, but one has the hardware that one has. I think I saw a
> webgui to guix somewhere, that means that at least some people have
> the ambition of getting non developers as users at some point right? I
> think telling non developers to go buy this wifi card if you want to
> use the gnu system or else we won't help you is kind of not very
> user-friendly.

We will not add non-free software to Guix.

That said, Guix gives you the means to swap out parts and change the way
packages are built (including the kernel).  However, for most users the
easiest way to overcome their dependency on non-free software is to use
hardware that works with free software.

~~ Ricardo

Re: Kernel config

[Ricardo Wurmus]

Vincent Legoll  writes:

> I'm wondering if it is possible to pass a .config file to be used for
> "guix system", as
> currently the config used is very heavy, and takes ages to build.

To use a different configuration you would create a new package variant
of the “linux-libre” package in “gnu/packages/linux.scm”, overriding the
native-input with the label “kconfig”.  Then you can specify your kernel
variant package in the “kernel” field of your system configuration.

I don’t recommend changing the default configuration in your local
checkout.

Hope this helps!

~~ Ricardo

Re: Kernel config

[Ricardo Wurmus]

Vincent Legoll  writes:
>
> Does it have to be in root's $GUIX_PACKAGE_PATH, or can guix system 
> reconfigure
> work as a user ? That would be a sufficiently good solution, I think...

“guix system reconfigure” has to be run as root.  With “sudo -E” you can
preserve the current user’s environment, so GUIX_PACKAGE_PATH doesn’t
need to be set for root explicitly.

~~ Ricardo

Re: Newbie packagers

[Ricardo Wurmus]

Hi Vincent,

> - the comma operator
> - the backquote operator
> - the quote operator
> - the arobase operator (is it for list unpacking ?)

These are all about list quoting.
This is code:

(+ 1 2 3)

It evaluates to 6.

This is quoted code (aka data):

'(+ 1 2 3)

It doesn’t get evaluated any further.
This is pretty much the same as:

`(+ 1 2 3)

But with the backtick (called “quasiquote”) you are permitted to
temporarily switch from “data mode” to “code mode”.  That’s what the
comma (“unquote”) does:

`(+ 1 2 3 4 ,(+ 3 2) 6)
^   ^
data mode   code mode

The result is the same as

'(+ 1 2 3 4 5 6)

What’s nice about this is that we can use the same syntax for code that
is to be evaluated right now and for code that we want to pass somewhere
else as inert data which will be evaluated at a later point.

This allows for “staging”.  When you look at a typical package
expression you see that the value of the “arguments” field is quoted.
It is not evaluated right away but in a second stage.

The value of the inputs field is also quoted.  You see that we unquote
the values of package variables there.  Package expressions in Guix are
just Scheme values.  The inputs field does not merely hold a list of
symbols that somehow represent the packages — it actually contains the
very values themselves!

“,@” is for splicing lists:

(let ((moo '(1 2 3)))
  `(foo bar ,@moo meh))

This binds the list '(1 2 3) to the name “moo” and then splices it into
another list.  This results in

'(foo bar 1 2 3 meh)

Without the “@” and just a regular unquote comma it would be a nested
list:

(let ((moo '(1 2 3)))
  `(foo bar ,moo meh))

=>  '(foo bar (1 2 3) meh)

Quoting and unquoting is a very useful feature.  I hope my explanations
above are easy to understand.

> - the percent operator

That’s no operator.  It’s part of the name.  We use the percent as a
prefix for variables that are “special”, e.g. global variables or
values that appear without having to be explicitly let-bound.

> - the #: operator

These are called keyword arguments.  They are no operators either.
Using keyword arguments allows you to specify arguments by name, not in
some fixed order.

> - the different module import things (#:use-module vs (use-modules) vs ...)

That’s probably explained in the Guile reference manual.  We use
“#:use-module” only in module definitions.  “(use-modules …)” can be
used anywhere else.

> I tried to find a good tutorial explaining all of those, but couldn't. I found
> snippets that helped me understand some of those, but they were scattered,
> and it's still blurry.
>
> Specific explanations will be more useful that a general scheme tutorial, the
> hello.scm is good as an example :
>
> (inputs `(("gawk" ,gawk)))
>
> here we use the backquote because ...
> the comma is there for ...
>
> (arguments `(#:configure-flags '("--enable-silent-rules")))
>
> here the #: means ...
> we use the simple quote because ...

Yeah, I agree.  There should be a quick crash course.  I spent half the
day yesterday to introduce all these things to a colleague who will
create a few Guix packages in the future.  It would be cool to have this
as part of the manual.

~~ Ricardo

Re: no patch applies

[Ricardo Wurmus]

Vincent Legoll  writes:

> Hello
>
>>> I attempted to apply the patch onto a fresh Guix master and the patch does
>>> not apply, I don't know why
>
> When I fail to apply a patch that's often because of a wrong -p parameter.
> Try with "--dry-run -p0" or "--dry-run -p1" to find the good one. You can also
> look at file paths in the patch and deduce the right path strip level.

I haven’t used “patch” in quite a while because usually “git am
the-patch-file” just works.  If the patch was created with “git
format-patch” against master you shouldn’t have any problems using “git
am” on it.

~~ Ricardo

Re: neo tty layout

[Ricardo Wurmus]

ng0  writes:

> I just installed NixOS on another system and noticed they offer neo
> layout not only in X11 but also for tty. Would it be okay to replicate
> this for Guix? I'll be looking into this soon for me personally, but
> maybe others can benefit from it by including it in Guix.

In general yes, but that ultimately depends on the proposed patch.

~~ Ricardo

Re: notmuch users: how do you filter debbugs?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> ng0  skribis:
>
>> Let's say you use notmuch as your Email sorting system, and you are
>> subscribed to more than one projects -b...@gnu.org, how do you filter
>> them? Currently it all ends up in inbox because they can't be
>> categorized, which is annoying for me. It's all debb...@gnu.org for
>> me. Is there some other value I can look for to sort them?
>
> I highly recommend the emacs-debbugs package if you use Emacs.

I second the use of emacs-debbugs.  It’s a reasonably convenient
interface albeit not entirely intuitive.

~~ Ricardo

Re: R install.packages() fails: 'Peer certificate cannot be authenticated with given CA certificates'

[Ricardo Wurmus]

myglc2  writes:

> With GuixSD user config ...
>
> (use-package-modules
>  base   ; glibc-utf8-locales
>  ssh; mosh
>  admin  ; tree
>  aspell ; aspell-dict-en
>  mail   ; notmuch mu isync
>  statistics ; r
>  emacs  ; emacs-ess
>  certs  ; nss-certs
>  )
> (packages->manifest
>  (list
>   mosh
>   tree
>   aspell-dict-en ; because emacs doesn't find system install
>   notmuch mu isync ; also building from git source but this gets run-time 
> dependencies
>   r emacs-ess
>   r-devtools r-openssl r-stringr r-xml2 r-httr 
>   )
>  )

You forgot to actually add “nss-certs” to the manifest.  After adding
“nss-certs” you need to set the environment variable CURL_CA_BUNDLE:

  export 
CURL_CA_BUNDLE=/home/rekado/.myglc2-profile/etc/ssl/certs/ca-certificates.crt

(I only recently patched r-curl to respect this environment variable.
We should patch libcurl so that all packages using libcurl understand
it.)

Now installation works.  Or rather: it fails with a different error :)
You should also make sure that your manifest contains a suitable build
environment, possibly including “gcc-toolchain”, “gfortran”, and “make”.

If you’re on a foreign distro it is important that you have
“gcc-toolchain” in the profile when you want to use install.packages
because there are quite a few R packages that build bindings to system
libs.  Our toolchain will refuse linking with system libs, but if you
use the system GCC and linker you will only notice breakage at runtime
when trying to use the package.  Our linker’s refusal to link to libs of
the host system is a blessing here, because it spares you the trouble of
runtime breakage later on.

(Better than “install.packages” is to use Guix with “r-*” packages
instead.  I’ll try to add more in the near future, so that it’s an
easier choice to make.)

BTW: you can simplify your manifest if you reference packages by name
instead of variable name.  I like to use suggest something like this for
users at the MDC because it looks cleaner:

~~
(define packages '("r"
   "emacs-ess"
   "emacs"
   "samtools@0"))

;; Boilerplate code to turn the above list of packages into a manifest
(use-modules (gnu packages))
(packages->manifest (map specification->package packages))
~~

Note that these package names can include version prefixes as in
“samtools@0”, which will get me the latest version of the Samtools 0.x
series instead of the latest version.

~~ Ricardo

Re: notmuch users: how do you filter debbugs?

[Ricardo Wurmus]

ng0  writes:

>>> ng0  skribis:
>>>
 Let's say you use notmuch as your Email sorting system, and you are
 subscribed to more than one projects -b...@gnu.org, how do you filter
 them? Currently it all ends up in inbox because they can't be
 categorized, which is annoying for me. It's all debb...@gnu.org for
 me. Is there some other value I can look for to sort them?

[…]
> But the email still ends up in my inbox, and as I filter through tags,
> I'd like to be able to throw guix related things into tag:guix::bug.
> Recommending to use another interface doesn't fix this problem.

Notmuch should be able to filter by list.  With mu4e I match for
“list:bug-guix.gnu.org”.  All emails to the bug-* lists contain a header
for “List-Id”, which you may be able to match on.

~~ Ricardo

Re: curl_ca_bundle, and gnurl?

[Ricardo Wurmus]

ng0  writes:

> Ricardo Wurmus  writes:
>
>> myglc2  writes:
>>
>>> With GuixSD user config ...
> ……
>>>  )
>>
>> You forgot to actually add “nss-certs” to the manifest.  After adding
>> “nss-certs” you need to set the environment variable CURL_CA_BUNDLE:
>>
>>   export 
>> CURL_CA_BUNDLE=/home/rekado/.myglc2-profile/etc/ssl/certs/ca-certificates.crt
>>
>> (I only recently patched r-curl to respect this environment variable.
>> We should patch libcurl so that all packages using libcurl understand
>> it.)
>>
>
> I wonder if we need this for gnurl or if the code base of gnurl is still
> curl-like enough that it respects the variable.. last time I tried gnurl
> as a user on its own (which is *not* the intended use) was on Gentoo.
> Gnurl is afaik not (yet) a gnu project and requires no sync with the gnu
> descriptions.. I should add this to the description.

Looking at the sources and searching for “getenv” I see this:

…
gnurl-7_50_3/src/tool_operate.c:env = curlx_getenv("CURL_CA_BUNDLE");
gnurl-7_50_3/src/tool_operate.c:  env = curlx_getenv("SSL_CERT_DIR");
gnurl-7_50_3/src/tool_operate.c:env = curlx_getenv("SSL_CERT_FILE");
gnurl-7_50_3/gnurl--/src/tool_operate.c:env = 
curlx_getenv("CURL_CA_BUNDLE");
gnurl-7_50_3/gnurl--/src/tool_operate.c:  env = 
curlx_getenv("SSL_CERT_DIR");
gnurl-7_50_3/gnurl--/src/tool_operate.c:env = 
curlx_getenv("SSL_CERT_FILE");
gnurl-7_50_3/gnurl--/lib/Makefile.netware:  @echo $(DL)#define 
CURL_CA_BUNDLE getenv("CURL_CA_BUNDLE")$(DL) >> $@
gnurl-7_50_3/gnurl--/lib/curl_setup.h:#define CURL_CA_BUNDLE 
getenv("CURL_CA_BUNDLE")
gnurl-7_50_3/gnurl--/lib/vtls/nss.c:  cert_dir = getenv("SSL_DIR");
gnurl-7_50_3/gnurl--/lib/config-dos.h:#define CURL_CA_BUNDLE  
getenv("CURL_CA_BUNDLE")
gnurl-7_50_3/lib/Makefile.netware:  @echo $(DL)#define CURL_CA_BUNDLE 
getenv("CURL_CA_BUNDLE")$(DL) >> $@
…

It looks like these common environment variables are indeed used for the
tool.  For the library it seems that the environment variable is only
respected when “config-dos.h” is used.  In other cases it’s a fixed file
path:

gnurl-7_50_3/src/Makefile:CURL_CA_BUNDLE = "/etc/ssl/certs/ca-certificates.crt"

So gnurl should also be patched to replace the definition of
CURL_CA_BUNDLE with “getenv("CURL_CA_BUNDLE")”.

> But can you share some insights why curl requires this? For gnurl I rely
> on its test suite, but I think curl does not complain about the missing
> CURL_CA_BUNDLE in its test suite either, or does it?

libcurl expects the user to configure the location of the bundle.  If
this does not happen it defaults to some hardcoded file path.  The
command line tool uses libcurl and overrides the value when the
environment variable CURL_CA_BUNDLE is set.

On Guix we cannot guarantee the existence of the hardcoded default path.
The bundle is not part of the curl package and we cannot presume to know
where the bundle file will be stored.  For per-profile certificates (a
user might want to distrust certain certificates, while another might
want to use the defaults) we should not hardcode this but defer the
decision to the CURL_CA_BUNDLE environment variable.

> And if gnurl should require this, how could I fix gnurl (not the package
> description in guix) to drop this strange behavior if it is possible at
> all?

It would be the same patch: we need to define CURL_CA_BUNDLE to be
“getenv("CURL_CA_BUNDLE)” instead of a fixed path.

~~ Ricardo

Re: notmuch users: how do you filter debbugs?

[Ricardo Wurmus]

ng0  writes:

>> n> Ricardo Wurmus  writes:
>
> If I may ask, what kind of mail writer/reader do you use which produces
> this really nice addition of initials between the quote chars?

This is what the email says:

User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

~~ Ricardo

running a script in a post-build hook?

[Ricardo Wurmus]

Hi Guix,

here’s my problem: I need to have the store on a big slow NFS server
with online compression and deduplication.  This means that *everything*
in Guix is slow: downloading binaries, building packages from source,
building a new profile generation — it’s all *very* slow.

So I thought: I should be able to just have the store on fast local
disks and copy over store items to the slow NFS server when they are
done.  This is not easy because the store is very big and at the
filesystem level we cannot take advantage of the fact that the store is
append-only for the most part.  So running rsync, for example, won’t cut
it.

The daemon, however, does have information about completed builds and
new store items.  Does the daemon have a post-build hook that can be
called with the names of the new store items which I could then copy
over?  (Or even the names of store items I need to delete after “guix
gc”.)

Could the build hook feature be used for this, maybe by wrapping the
normal build such that a script is run when it finishes?

Finally, is this a good idea?  Or is /gnu/store/.links going to be a
problem?  Should a post-build hook also inform about deduplication
decisions?  Or should I just turn of deduplication in my case?

~~ Ricardo

Re: guix package -r *downloads* new packages?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hi Hartmut,
>
> Hartmut Goebel  skribis:
>
>> I tried cleaning up my system. But when I did "guix package -r …", it
>> started to build derivations and download stuff.
>
> [...]
>
>> $ guix package -r guix
>> warning: failed to install locale: Invalid argument
>> The following package will be removed:
>>guix 0.10.0-0.e901  
>> /gnu/store/vw26xsn24jmrijn939fjjk50m5i4hfq3-guix-0.10.0-0.e901
>>
>> substitute: updating list of substitutes from
>> 'https://mirror.hydra.gnu.org'... 100.0%
>> The following derivations will be built:
>>/gnu/store/4mdahqlzar6fl9f9cx6i16561x2yclwx-profile.drv
>>/gnu/store/2pn3gbhq7hnnh8kzwblihlw8f34irkgg-module-import.drv
>>/gnu/store/j46m2a8fnxklnckiqkn7r9id6jhs94s1-module-import-compiled.drv
>>/gnu/store/zhdym8ynv7sbr1iiaj917ln1z1ris2zw-gtk-icon-themes.drv
>>/gnu/store/plq1855s06gi77x3qbsyp4217ssn635i-info-dir.drv
>>/gnu/store/n1kdin8g51m6dd7ds8hiv8pgv20dczki-fonts-dir.drv
>>/gnu/store/lcp53c781kk1d6fxr2xm4dhfm1fgv9x1-ca-certificate-bundle.drv
>>/gnu/store/19ngbl2rmvag3dgsii8pkfmhzbg3zbx8-xdg-mime-database.drv
>> The following files will be downloaded:
>>/gnu/store/ik15p8lrbk6jfa3fs3x34m78lj2c0ix1-guile-2.0.11
>>/gnu/store/1vmfjpapw15nmhdw3hvrkdp8k933j518-module-import-compiled
>>/gnu/store/f9m713c1v5db09b0asxd3mifdskllbri-texinfo-6.1
>
> This is counter-intuitive but expected.  First of all, the profile is
> built by running a Guile program, so Guile needs to be available if it’s
> not already there.
>
> Secondly, when the profile is built, a number of “profile hooks” are
> run.  We can see them above: gtk-icon-themes builds a registry of the
> installed GTK+ themes (which requires GTK+), info-dir builds the Info
> documentation directory (which requires Texinfo), and so on.

Do you think we could make this a little more intuitive by hiding the
derivations for the profile hooks (unless verbosity is increased), or by
listing them separately?

~~ Ricardo

Re: running a script in a post-build hook?

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello!
>
> Ricardo Wurmus  skribis:
>
>> here’s my problem: I need to have the store on a big slow NFS server
>> with online compression and deduplication.  This means that *everything*
>> in Guix is slow: downloading binaries, building packages from source,
>> building a new profile generation — it’s all *very* slow.
>
> This is a tricky use case…
>
>> So I thought: I should be able to just have the store on fast local
>> disks and copy over store items to the slow NFS server when they are
>> done.  This is not easy because the store is very big and at the
>> filesystem level we cannot take advantage of the fact that the store is
>> append-only for the most part.  So running rsync, for example, won’t cut
>> it.
>>
>> The daemon, however, does have information about completed builds and
>> new store items.  Does the daemon have a post-build hook that can be
>> called with the names of the new store items which I could then copy
>> over?  (Or even the names of store items I need to delete after “guix
>> gc”.)
>>
>> Could the build hook feature be used for this, maybe by wrapping the
>> normal build such that a script is run when it finishes?
>
> The build hook “protocol” doesn’t work like this.  The daemon sends a
> build request, which the hook can accept, postpone, or decline (see
> (guix scripts offload)).  When it accepts, the hook cannot invoke the
> daemon (it’s not “reentrant”.)  The substituter protocol is similar.

Hmm, thanks for your input!

Okay, so the build hook feature couldn’t be (ab)used for this, but would
it be okay to patch the daemon to optionally run a script upon
completing a store action?

>> Finally, is this a good idea?  Or is /gnu/store/.links going to be a
>> problem?  Should a post-build hook also inform about deduplication
>> decisions?  Or should I just turn of deduplication in my case?
>
> Turning off deduplication would probably help because deduplication is
> I/O intensive.
>
> Otherwise maybe a file system level hack?  Like making /gnu/store a
> unionfs that writes elsewhere?

I find the file system to be the wrong level of abstraction.  And
unionfs seems like a brittle solution.  I’d much rather operate on
individual store items on demand.  (The localstatedir is small enough to
copy fully each time something happens.)

I’d really like to take advantage of the facts that the store is append
only (with the exception of “guix gc”) and that the daemon knows what’s
going on.

~~ Ricardo

Re: After installing Java, what should I set JAVA_HOME to?

[Ricardo Wurmus]

Zachary Kanfer  writes:

> I am not sure what trust store is being used. I'm also not sure how to
> check what trust store is being used.

You can get more debug information by adding the following option to
your invocation of “java”:

-Djavax.net.debug=ssl

You can override the trust store with

-Djavax.net.ssl.trustStore=/path/to/jdk/lib/security/cacerts

~~ Ricardo

Re: After installing Java, what should I set JAVA_HOME to?

[Ricardo Wurmus]

Zachary Kanfer  writes:

> But I started the gradle quickstart guide
> ,
> and I've started running into problems. Right now I have $JAVA_HOME set to
> /home/zck/.guix-profile/, but I am suspecting that is not right. When I run
> `./gradlew clean`, I get the following error:
>
> zck@zck-laptop:~/code/gradle-test$ ./gradlew clean
> Downloading https://services.gradle.org/distributions/gradle-3.0-bin.zip
>
> Exception in thread "main" javax.net.ssl.SSLException:
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException:
> the trustAnchors parameter must be non-empty

[…]

> [1] The manifest file to install javac is:
>
> (use-package-modules java)
>
> (packages->manifest
>  (list ;;java
>icedtea
>(list icedtea "jdk")))

You only need “(list icedtea "jdk")” here.  The “jdk” output of the
“icedtea” package includes the JRE, which is the only thing you get with
the standard output of “icedtea”.

Versions 6 and 7 of “icedtea” come with a build phase to generate a
keystore.  I’m using this successfully with “jgit”, which has to
validate SSL certs.

As to the value of JAVA_HOME: I only ever set it in Guix package
expressions, where it is set to the directory name of the store item for
the “jdk” output.

~~ Ricardo

Re: After installing Java, what should I set JAVA_HOME to?

[Ricardo Wurmus]

Zachary Kanfer  writes:

> I want Guix to be widely adopted, because I think it's a really cool piece
> of software that deserves more support. To that end, I want to write about
> how high switching costs "use Guix for everything" has, and how much I
> think Guix adoption will be harmed by this advice.

Java is a bit of a special case for Guix.  We build *everything* from
source and that’s something the Java world seems to have agreed not to
do.  This means that there aren’t many Java packages in Guix at this
point and getting Java stuff to work is messy.

Right now I would not use Guix to develop Java things (I’m saying this
as the person who packaged the OpenJDK and various Java libraries for
Guix).  It takes a lot of effort to bootstrap Maven from source and I
don’t know of any other distribution that has even attempted to do
this.  (Maven relies on Maven and usually comes with a bootstrapped
binary to facilitate building Maven.)

That said, I had no problems *using* the Java toolchain for compiling
Java code or for running pre-compiled code from third-party jars.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: After installing Java, what should I set JAVA_HOME to?

[Ricardo Wurmus]

zloster  writes:

> There is icedtea-3.1.0

That’s the problem: icedtea 3.1.0 cannot build the keystore, which is
why this build phase has been removed.

IcedTea (the free software build system for OpenJDK) doesn’t come with a
keystore by default and doesn’t try to generate it, so what we do in
Guix is to add a build phase in which a “cacerts” file is built from the
NSS certificate store and saved to “$jdk/jre/lib/security” and
“$jre/lib/security”.

For 3.1.0 this phase fails for unknown reasons, so I removed it.  This
means that 3.1.0 doesn’t have SSL support out of the box.  The two
previous versions however do, so if you want to avoid custom hacks I
encourage you to install 2.6.7:

guix package -i icedtea@2.6

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: After installing Java, what should I set JAVA_HOME to?

[Ricardo Wurmus]

Chris Marusich  writes:

> Radoslav Petrov  writes:
>
>> About a proper fix: IMO iced3 JDK Guix definition needs to process
>> "java.security" file for the SunPKCS11 provider to override the
>> JAVA_HOME definition with the file in the current version/dir/instance
>> of the Guix package (I'm not sure for the correct term). But this have
>> to be done on each update/upgrade of NSS package. So I'm not so sure
>> about the proper way to fix this packaging problem.
>
> This sounds right to me.  If I'm hearing you correctly, there is a
> configuration file in the output of the icedtea package which needs to
> be updated whenever the nss package is updated.  I believe the correct
> way to accomplish that is to use "static composition" or "late static
> composition" [1].  I'm sure a convenient mechanism for this exists in
> Guix, but since I haven't done it myself, I'm not sure of the details.
>
> [1] See section 7.1.1 in Eelco Dolstra's thesis:
> http://nixos.org/%7Eeelco/pubs/phd-thesis.pdf

We are already genarting the keystore for IcedTea.  It just fails for
IcedTea 3, which is why it’s disabled there.  IcedTea 2 should work just
fine.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

GNU Guix & GuixSD 0.12.0 released

[Ricardo Wurmus]

g interfaces
  
  *** New procedure ‘package-for-guile-2.2’ for Guile package variants
  *** New ‘package-input-rewriting’ customization procedure in (guix packages)
  *** New ‘deprecated-package’ procedure in (guix packages)
  *** New ‘file-append’ procedure in (guix gexp)
  *** New (guix modules) module, to determine the closure of a Guile module
  *** ‘wrap-program’ from (guix utils) now produces only one wrapper file.
  
  ** Noteworthy bug fixes
  
  *** ‘ld-wrapper’ no longer aborts if Guile 2.2 modules are in the search path
  *** ‘guix system reconfigure’ no longer unloads services depended on
  *** GuixSD ‘menu-entry’ can specify arbitrary kernel and initrd file names
  (<http://bugs.gnu.org/20067>)
  *** Fix typo in device-opening code for ‘raid-device-type’
  *** Grafts are applied to replacement packages (<http://bugs.gnu.org/24418>)
  *** guix-daemon does not fail when deduplicating would lead to ENOSPC
  *** ‘guix download’ now checks X.509 certificates by default
  (<http://bugs.gnu.org/24466>)
  *** Avoid bootstrapping issue for HTTPS downloads
  (<http://bugs.gnu.org/22774>)
  *** Failed build directories are owned by the user to ease debugging
  (<http://bugs.gnu.org/15890>)
  *** Significantly reduced the closure of Perl (<http://bugs.gnu.org/23077>)
  *** Fixed importer for Nixpkgs (<http://bugs.gnu.org/25053>)
  
  ** Native language support
  
  Updated translations: da (Danish), pl (Polish), de (German), pt_BR
  (Portuguese, Brazil), and fr (French).
  

Please report bugs to bug-g...@gnu.org
Join guix-de...@gnu.org and #guix on Freenode for discussions.

Thanks to everyone who contributed to this release:

 3  8p8c
 2  Adonay Felipe Nogueira
 3  Al McElrath
 4  Alex Griffin
38  Alex Kost
 4  Alex Sassmannshausen
 6  Alex Vong
 2  Alex ter Weele
 1  Amirouche Boubekki
32  Andreas Enge
27  Andy Patterson
 8  Andy Wingo
16  Arun Isaac
 7  Ben J Woodcroft
   124  Ben Woodcroft
 1  Benz Schenk
 2  Brendan Tildesley
 2  Carlos Sánchez de La Lama
11  Chris Marusich
 7  Christopher Allan Webber
 1  Christopher Andersson
13  Christopher Baines
 4  Clément Lassieur
63  Danny Milosavljevic
   276  David Craven
 9  David Thompson
 1  Dmitry Bogatov
 2  Dylan Jeffers
 3  Eelco Dolstra
   469  Efraim Flashner
41  Eric Bavier
 1  Eric Le Bihan
 5  Erik Edrosa
34  Federico Beffa
 1  Florian Paul Schmidt
   161  Hartmut Goebel
 3  Ivan Vilata i Balaguer
21  Jan Nieuwenhuizen
 1  Jelle Licht
57  John Darrington
 1  John J. Foerch
 3  José Miguel Sánchez García
 2  Julian Graham
 7  Julien Lepiller
24  Kei Kebreau
   379  Leo Famulari
   442  Ludovic Courtès
 4  Lukas Gradl
21  Manolis Ragkousis
   114  Marius Bakke
   128  Mark H Weaver
 7  Mathieu Lirzin
 2  Maxim Cournoyer
 2  Mike Gerwitz
 1  Muriithi Frederick Muriuki
12  Nicolas Goaziou
 2  Paul Garlick
     3  Petter
 2  Raoul Bonnal
 9  Rene Saavedra
   465  Ricardo Wurmus
20  Roel Janssen
82  Sou Bunnbu (宋文武)
 4  Stefan Reichoer
 1  Stephen Webber
 4  Taylan Ulrich Bayırlı/Kammer
11  Theodoros Foradis
18  Thomas Danckaert
   141  Tobias Geerinckx-Rice
 7  Tomáš Čech
 1  Toni Reina
 9  Troy Sankey
 3  Vincent Legoll
 4  doncatnip
   170  ng0
 1  rennes

Ricardo, on behalf of the Guix team.


signature.asc
Description: PGP signature

clisp executable images fail at startup

[Ricardo Wurmus]

Hi Guix,

for fun I just ported Yale Haskell to CLISP (it only needed a handful of
changes).  I’m using EXT:SAVEINITMEM to generate an executable image.
Building the image outside of Guix I can run the executable and I get a
Haskell prompt as expected.

When I packaged it and tried to run the packaged executable, however, I
got this error:

module 'syscalls' requires package OS.

(This error is reported by CLISP.)

Attached is the patch I used to build the yale-haskell package.

>From d59f25c4ee8982a56342a03bcc66fc9048113c21 Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Sat, 24 Dec 2016 09:50:29 +0100
Subject: [PATCH] WIP: Add yale-haskell.

---
 gnu/packages/haskell.scm | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/gnu/packages/haskell.scm b/gnu/packages/haskell.scm
index 8e5927a..27ed7aa 100644
--- a/gnu/packages/haskell.scm
+++ b/gnu/packages/haskell.scm
@@ -29,6 +29,7 @@
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix utils)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system haskell)
@@ -44,6 +45,7 @@
   #:use-module (gnu packages ghostscript)
   #:use-module (gnu packages libffi)
   #:use-module (gnu packages libedit)
+  #:use-module (gnu packages lisp)
   #:use-module (gnu packages lua)
   #:use-module (gnu packages maths)
   #:use-module (gnu packages multiprecision)
@@ -53,6 +55,42 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages xorg))
 
+(define-public yale-haskell
+  (let ((commit "85f94c72a16c5f70301dd8db04cde9de2d7dd270")
+(revision "1"))
+(package
+  (name "yale-haskell")
+  (version (string-append "2.0.5-" revision "." (string-take commit 9)))
+  (source (origin
+(method git-fetch)
+(uri (git-reference
+  (url "http://git.elephly.net/software/yale-haskell.git";)
+  (commit commit)))
+(file-name (string-append "yale-haskell-" commit "-checkout"))
+(sha256
+ (base32
+  "0bal3m6ryrjamz5p93bhs9rp5msk8k7lpcqr44wd7xs9b9k8w74g"
+  (build-system gnu-build-system)
+  (arguments
+   `(#:tests? #f ; no tests
+ #:make-flags
+ (list (string-append "PREFIX=" (assoc-ref %outputs "out")))
+ #:phases
+ (modify-phases %standard-phases
+   (replace 'configure
+ (lambda _
+   (setenv "PRELUDE" "./progs/prelude")
+   (setenv "HASKELL_LIBRARY" "./progs/lib")
+   (setenv "PRELUDEBIN" "./progs/prelude/clisp")
+   (setenv "HASKELLPROG" "./bin/clisp-haskell")
+   #t)
+  (inputs
+   `(("clisp" ,clisp)))
+  (home-page "http://git.elephly.net/software/yale-haskell.git";)
+  (synopsis "Port of the Yale Haskell system to CLISP")
+  (description "TODO")
+  (license license:bsd-4
+
 (define ghc-bootstrap-x86_64-7.8.4
   (origin
 (method url-fetch)
-- 
2.10.2


-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0  writes:

> my previous releases of gnurl (https://gnunet.org/gnurl) have
> been tested on Gentoo and GuixSD and prepared to release only on
> Gentoo, copied back to GuixSD and finished up on that GuixSD
> system.
> With my switch to GuixSD (and leaving Gentoo) 2 or 3 versions ago
> I have to advice people to run ./buildconf again (essentially:
> run autotools again), because of artifacts in shebangs and paths
> of generated files.

I cannot reproduce this.  After packaging roffit I ran this:

guix environment gnurl --ad-hoc autoconf automake libtool roffit ghostscript
./buildconf
./configure --enable-ipv6 --with-gnutls --without-libssh2 \
--without-libmetalink --without-winidn --without-librtmp \
--without-nghttp2 --without-nss --without-cyassl \
--without-polarssl --without-ssl --without-winssl \
--without-darwinssl --disable-sspi --disable-ntlm-wb 
--disable-ldap \
--disable-rtsp --disable-dict --disable-telnet --disable-tftp \
--disable-pop3 --disable-imap --disable-smtp --disable-gopher \
--disable-file --disable-ftp --disable-smb
make dist

What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
specifies the version as a dash).  Unpacking it I see exactly *one*
reference to something in /gnu/store and that’s in “ltmain.sh”.

I haven’t tried the “maketgz” script because it contains references to
/usr/bin, but ultimately it runs “make dist” as well.

Attached is the patch to add roffit.

>From af81a0a3c796af583ec88dd4bc8d2e8a742c58fa Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Sat, 24 Dec 2016 11:12:45 +0100
Subject: [PATCH] gnu: Add roffit.

* gnu/packages/groff.scm (roffit): New variable.
---
 gnu/packages/groff.scm | 41 +
 1 file changed, 41 insertions(+)

diff --git a/gnu/packages/groff.scm b/gnu/packages/groff.scm
index 93d0380..2509a78 100644
--- a/gnu/packages/groff.scm
+++ b/gnu/packages/groff.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2013 Andreas Enge 
 ;;; Copyright © 2014 Mark H Weaver 
+;;; Copyright © 2016 Ricardo Wurmus 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -21,6 +22,7 @@
   #:use-module (guix licenses)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix git-download)
   #:use-module (guix build-system gnu)
   #:use-module (gnu packages)
   #:use-module (gnu packages bison)
@@ -56,3 +58,42 @@ formatted output based on formatting commands contained within the text.  It
 is usually the formatter of \"man\" documentation pages.")
(license gpl3+)
(home-page "http://www.gnu.org/software/groff/";)))
+
+;; There are no releases, so we take the latest commit.
+(define-public roffit
+  (let ((commit "e5228388e3faf2b7f1ae5bd048ad46ed565304c6")
+(revision "1"))
+(package
+  (name "roffit")
+  (version (string-append "0.11-" revision "." (string-take commit 9)))
+  (source (origin
+(method git-fetch)
+(uri (git-reference
+  (url "https://github.com/bagder/roffit.git";)
+  (commit commit)))
+(file-name (string-append "roffit-" commit "-checkout"))
+(sha256
+ (base32
+  "1y7ndbqciy7h0khlpi1bv4v1614vhybnmm4jysj6fwxkw9cwv1nc"
+  (build-system gnu-build-system)
+  (arguments
+   `(#:test-target "test"
+ #:make-flags
+ (list (string-append "INSTALLDIR="
+  (assoc-ref %outputs "out") "/bin"))
+ #:phases
+ (modify-phases %standard-phases
+   (delete 'configure)
+   (add-before 'install 'pre-install
+ (lambda* (#:key outputs #:allow-other-keys)
+   (mkdir-p (string-append (assoc-ref outputs "out")
+   "/bin"))
+   #t)
+  (inputs
+   `(("perl" ,perl)))
+  (home-page "https://daniel.haxx.se/projects/roffit/";)
+  (synopsis "Convert nroff files to HTML")
+  (description
+   "Roffit is a program that reads an nroff file and outputs an HTML file.
+It is typically used to display man pages on a Web site.")
+  (license expat
-- 
2.10.2


-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0  writes:

> Ricardo Wurmus  writes:
>
>> What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
>> specifies the version as a dash).  Unpacking it I see exactly *one*
>> reference to something in /gnu/store and that’s in “ltmain.sh”.
>
> Hm.. that's what I had too before I asked here, I just felt there
> must be 0 occurences of /gnu/store.

You wrote earlier:

> 3. Simply remove all occurences of any /gnu/store/… (if it's
>that simple) which could also happen in (2).

That made it sound like there are countless references that need to be
corrected somehow.

“ltmain.sh” is instantiated from a template by libtool.  It originally
contains a /bin/sh shebang, and I think it should not be patched when
installed to

/gnu/store/…-libtool-2.4.6/share/libtool/build-aux/ltmain.sh

This seems like a bug to me.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0  writes:

> Ricardo Wurmus  writes:
>
>> ng0  writes:
>>
>>> Ricardo Wurmus  writes:
>>>
>>>> What I get is a tarball named “gnurl--.tar.gz” (because “configure.ac”
>>>> specifies the version as a dash).  Unpacking it I see exactly *one*
>>>> reference to something in /gnu/store and that’s in “ltmain.sh”.
>>>
>>> Hm.. that's what I had too before I asked here, I just felt there
>>> must be 0 occurences of /gnu/store.
>>
>> You wrote earlier:
>>
>>> 3. Simply remove all occurences of any /gnu/store/… (if it's
>>>that simple) which could also happen in (2).
>>
>> That made it sound like there are countless references that need to be
>> corrected somehow.
>
> Well in 7.52.0 there are more than 1 reference to /gnu/store, and
> in 7.52.1 there were more than in 7.52.0 simply because I did not
> have the time to investigate what's wrong now.

If you did what I did on GuixSD (exact sequence in my previous email) I
don’t see how there could have been any more references to store items.

>> “ltmain.sh” is instantiated from a template by libtool.  It originally
>> contains a /bin/sh shebang, and I think it should not be patched when
>> installed to
>
> So I can assume that just changing the shebang in ltmain.sh back
> to /bin/sh is enough to make it distributable again, or is
> ltmain.sh something distributions have anyway and the local file
> is "just there"?

ltmain.sh is included by “make dist”, so it’s supposed to be
distributed.  One of the big ideas of autotools is that users don’t have
to have autotools to build a release tarball.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0  writes:

> Ricardo Wurmus  writes:
[…]
>> From af81a0a3c796af583ec88dd4bc8d2e8a742c58fa Mon Sep 17 00:00:00 2001
>> From: Ricardo Wurmus 
>> Date: Sat, 24 Dec 2016 11:12:45 +0100
>> Subject: [PATCH] gnu: Add roffit.
>>
>> * gnu/packages/groff.scm (roffit): New variable.
[…]
>> +;; There are no releases, so we take the latest commit.
>> +(define-public roffit
>> +  (let ((commit "e5228388e3faf2b7f1ae5bd048ad46ed565304c6")
>> +(revision "1"))
>> +(package
>> +  (name "roffit")
>> +  (version (string-append "0.11-" revision "." (string-take commit 9)))
>> +  (source (origin
>> +(method git-fetch)
>> +(uri (git-reference
>> +  (url "https://github.com/bagder/roffit.git";)
>> +  (commit commit)))
>> +(file-name (string-append "roffit-" commit "-checkout"))
>> +(sha256
>> + (base32
>> +  "1y7ndbqciy7h0khlpi1bv4v1614vhybnmm4jysj6fwxkw9cwv1nc"
>> +  (build-system gnu-build-system)
>> +  (arguments
>> +   `(#:test-target "test"
>> + #:make-flags
>> + (list (string-append "INSTALLDIR="
>> +  (assoc-ref %outputs "out") "/bin"))
>> + #:phases
>> + (modify-phases %standard-phases
>> +   (delete 'configure)
>> +   (add-before 'install 'pre-install
>> + (lambda* (#:key outputs #:allow-other-keys)
>> +   (mkdir-p (string-append (assoc-ref outputs "out")
>> +   "/bin"))
>> +   #t)
>
> My only difference is in the (arguments), where I do:
>
>   (arguments
>`(#:test-target "test"
>  #:phases
>  (modify-phases %standard-phases
>(replace 'configure ; No configure phase
>  (lambda* (#:key outputs #:allow-other-keys)
>(let* ((out  (assoc-ref outputs "out"))
>   (bin  (string-append out "/bin/")))
>  (substitute* "Makefile"
>(("/usr/local/bin")
> bin))

That’s not necessary, because we can override INSTALLDIR.

>(mkdir-p bin
>(add-after 'install 'wrap-programs
>  (lambda* (#:key outputs #:allow-other-keys)
>;; Make sure all executables in "bin" find the Perl modules
>;; provided by this package at runtime.
>(let* ((out  (assoc-ref outputs "out"))
>   (bin  (string-append out "/bin/"))
>   (path (getenv "PERL5LIB")))
>  (for-each (lambda (file)
>  (wrap-program file
>`("PERL5LIB" ":" prefix (,path
>(find-files bin "\\.*$"))
>  #t))

Why would this be necessary?  There are no Perl packages among the
inputs.

-- 
Ricardo
  
  GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
  http://elephly.net

Re: Seeking advice: preparing releases on GuixSD.

[Ricardo Wurmus]

ng0  writes:

> So the changed shebang in the ltmain.sh is a bug on my side or in
> the autotools in Guix?

Looks like a bug in how we install the file when building libtool.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: clisp executable images fail at startup

[Ricardo Wurmus]

Ludovic Courtès  writes:

>> When I packaged it and tried to run the packaged executable, however, I
>> got this error:
>>
>> module 'syscalls' requires package OS.
>>
>> (This error is reported by CLISP.)
>
> Could it be a search path issue?  Did you try strace’ing clisp to see
> where it’s looking for “OS”?

I couldn’t find anything of interest by strace’ing the binary, but I
noticed that the binary I built locally is an order of magnitude larger
than the binary that ended up in the store (21MB instead of 2.6MB).

Turns out that after disabling stripping I get an executable that works
fine.  Maybe executable CLISP images should never be stripped.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

StumpWM with SLIME

[Ricardo Wurmus]

Hi Guix,

I’m trying out StumpWM and I’d like to be able to interact with it via
Emacs using SLIME.

Here’s what I installed:

  guix package -i emacs-slime sbcl-stumpwm:bin

My ~/.stumpwmrc looks like this:

--8<---cut here---start->8---
(in-package :stumpwm)
;; Find fonts in my Guix profile
(run-shell-command "xset +fp ~/.guix-profile/share/fonts/X11/100dpi/")
;; Change window font to something readable
(set-font "-adobe-courier-medium-r-normal--14-100-100-100-m-90-iso8859-1")

;; TODO: this works in the sbcl REPL, but fails when starting stumpwm
(require "asdf")
(load 
"/home/rekado/.guix-profile/share/emacs/site-lisp/guix.d/slime-2.18/swank.asd")
(require :swank)
--8<---cut here---end--->8---

The last three lines are supposed to load swank, which is part of
SLIME.  When running these lines in a separate sbcl REPL everything
seems to be okay.  But as part of my ~/.stumpwmrc this isn’t working.

I get an error:

Don’t know how to REQUIRE SB-INTROSPECT

When I try this again in StumpWM using “C-t : (require :swank)” I get a
different error:

ASDF could not load swank because
The variable SWANK::*AFTER-INIT-HOOK* is unbound..

Does this work for anyone?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: binary installation on Fedora 25

[Ricardo Wurmus]

Marius Bakke  writes:

> Catonano  writes:
[…]
>> Several times selinux complained that some process was trying to read some
>> file unduly.
>
> I think SELinux needs to be disabled, since we don't have any policy for
> the Guix daemon at the moment. Can you try that and report back?

After FOSDEM I could take a look at this and see if I can come up with a
simple SELinux policy.  I don’t think it’s good to suggest SELinux be
disabled (other than as a workaround).

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

ath wireless power management failure

[Ricardo Wurmus]

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net
Hi Guix,

since a couple of days I’m experiencing problems with my wireless card
after waking up from suspend.  I suspend the laptop very often, so this
is really important to me.

Upon waking up from suspend the wireless card cannot be initialised any
more.  This results in a constant stream of error messages, which can be
seen in dmesg.  The messages disappear when unloading all ath-related
kernel modules.  Reloading the modules does not return the network card
to a workable state, so I have to reboot if I want to connect to a
wireless network (and I usually want to do that).

The error messages that appear in the log look like this:

--8<---cut here---start->8---
[ 1210.998408] ath: phy0: Unable to reset channel, reset status -22
[ 1211.078027] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x 
AR_DIAG_SW=0x DMADBG_7=0x
[ 1211.078038] ath: phy0: Could not stop RX, we could be confusing the DMA 
engine when we start RX up
--8<---cut here---end--->8---

(Repeat ad infinitum.)

According to ancient bug reports these messages relate to power
management problems and have been reported as fixed a long time ago.  I
confirmed with “iw” and “iwconfig” that power management for my WiFi
card is in fact disabled (I didn’t do this myself).

I see these errors with linux-libre-4.1 and linux-libre.  I’m using
a somewhat dated Libreboot (planning to upgrade *after* FOSDEM to be
sure that my machine is usable for the presentation).

Has anyone else experienced the same behaviour?  Any ideas how to fix
this?  Does this just mean that my WiFi card is dying?

--
Ricardo

Re: ath wireless power management failure

[Ricardo Wurmus]

Tiberiu  writes:

> On 07.02.2017 16:46, Ludovic Courtès wrote:
>> So I don’t know what’s happening in your case.  It’s a good idea to try
>> with a different WiFi card or dongle if you have one.
>
> Ricardo, do you have a WiFi card on mPCIe (driver ath9k) or a WiFi
> dongle on USB (driver ath9k_htc)? Ludo's using the WiFi dongle.

I’m using an internal WiFi card with ath9k.  I don’t have a WiFi dongle.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: ath wireless power management failure

[Ricardo Wurmus]

Tiberiu  writes:

> Do you also have ath9k log messages and if so, could you please paste
> them here? Also, what chip does your WiFi card have?

There aren’t many ath9k log messages.  Here are the messages from
yesterday and today:

Feb  6 00:35:57 localhost vmunix: [   11.849588] ath9k :02:00.0: enabling 
device ( -> 0002)
Feb  6 00:35:57 localhost vmunix: [   12.052196] ath9k :02:00.0 wlp2s0: 
renamed from wlan0
Feb  6 09:23:44 localhost vmunix: [   12.052555] ath9k :02:00.0 wlp2s0: 
renamed from wlan0
Feb  6 16:41:02 localhost vmunix: [21782.562086] [] ath_isr 
[ath9k]
Feb  6 16:48:04 localhost vmunix: [   67.024255] ath9k :02:00.0 wlp2s0: 
renamed from wlan0
Feb  6 18:18:40 localhost vmunix: [ 5507.166605] [] ath_isr 
[ath9k]
Feb  6 18:25:22 localhost vmunix: [   25.190524] ath9k :02:00.0 wlp2s0: 
renamed from wlan0
Feb  6 22:02:25 localhost vmunix: [   53.568402] ath9k :02:00.0 wlp2s0: 
renamed from wlan0
Feb  7 07:49:13 localhost vmunix: [ 4619.392030] ath9k :02:00.0: Refused to 
change power state, currently in D3
Feb  7 07:53:51 localhost vmunix: [   64.161516] ath9k :02:00.0 wlp2s0: 
renamed from wlan0
Feb  7 08:39:19 localhost vmunix: [ 2787.166577] [] ath_isr 
[ath9k]
Feb  7 08:50:07 localhost vmunix: [   18.319719] ath9k :02:00.0: enabling 
device ( -> 0002)
Feb  7 08:50:07 localhost vmunix: [   18.652179] ath9k :02:00.0 wlp2s0: 
renamed from wlan0
Feb  7 11:55:49 localhost vmunix: [   69.031690] ath9k :02:00.0 wlp2s0: 
renamed from wlan0

lspci says this about my network controller:

02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter 
(PCI-Express) (rev 01)

It used to work fine for several months.  Not sure if it’s failing or if
there’s bad interaction with the kernel/libreboot.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: ath wireless power management failure

[Ricardo Wurmus]

Björn Höfling  writes:

> Just curious:
>
> Is you operating system GuixSD? Do you still have an old system generation of
> the time "where it worked"? Have you tried to boot into that?

I’m using GuixSD but I reinstalled the system right before going to
FOSDEM.  I did this because my initial installation was on a tiny
partition at the end of my otherwise LVM/LUKS-formatted disk.  The
easiest way to use the whole disk was to reinstall GuixSD, instead of
trying to move around the partitions.

As a result I don’t have an older version of GuixSD that I could boot
into :-/

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Recursively propagate build-system 'arguments' to dependency packages?

[Ricardo Wurmus]

Myles English  writes:

> Hello Fede, Eric,
>
> on [2017-02-07] at 15:15 Federico Beffa writes:
>
>> Eric Bavier  writes:
>>
>>> On Mon, 06 Feb 2017 21:09:33 +
>>> Myles English  wrote:
>>>
 Trying to define a package to be compiled by ghc-8, and I think all of
 its dependencies must also be compiled by ghc-8 rather than ghc (which
 is version 7).  This is easy to do with one package, e.g..:

 (define-module (my-packages myhaskell)
  ...
   #:use-module ((gnu packages haskell) #:prefix haskellmain:))

 (define-public ghc-hunit8
   (package
 (inherit haskellmain:ghc-hunit)
 (arguments `(#:haskell ,ghc-8

 To do that recursively for all the dependencies seems Too Difficult so,
 is there a way to do something like --with-input=ghc=ghc-8 but with the
 build-system arguments?  Perhaps doing the work in between the Bag and
 the Derivation?
>
> Thanks Eric for your suggestion. I made a start on this...
>
>>> You may take a look at the 'package-with-python2' procedure in
>>> guix/build-system/python.scm, which seems like it could be adapted to
>>> work with haskell/ghc packages.
>>
>> Hi Eric, Myles,
>>
>> it seems that the only Python specific part of
>> 'package-with-explicit-python' is the keyword '#:python'. What do you
>> think of generalizing it by making it a function keyword argument and
>> move the procedure to its own module (maybe (guix build-system
>> utils)?).
>
> ...I came the same conclusion as Fede: it could be generalised.  It is
> probably close to working for me (with respect to ghc) so I will keep
> going for now.  I am not competent enough to generalise it but if
> someone else does I can help test it.

I’m doing the same for some Perl packages.  I defined a procedure
“package-for-perl-5.14” which takes a package and rewrites it.

It looks like this:

--8<---cut here---start->8---
(define (package-for-perl-5.14 pkg)
  (let* ((rewriter (package-input-rewriting `((,perl . ,perl-5.14))
perl-5.14-package-name))
 (new (rewriter pkg)))
(package
 (inherit new)
 (arguments `(#:perl ,perl-5.14
  ,@(package-arguments new))
--8<---cut here---end--->8---

The problem here is that it doesn’t rewrite the “#:perl” argument
recursively, so the dependencies of a Perl package will still refer to
the latest version of Perl as that’s what’s used in the build system.

We would need a solution that would take care of this problem for all
build systems.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: ath wireless power management failure

[Ricardo Wurmus]

Tiberiu  writes:

> On 07.02.2017 18:03, Ricardo Wurmus wrote:
>> Tiberiu  writes:
>>
>>> Do you also have ath9k log messages and if so, could you please paste
>>> them here? Also, what chip does your WiFi card have?
>>
>> There aren’t many ath9k log messages.  Here are the messages from
>> yesterday and today:
>>
>> Feb  6 00:35:57 localhost vmunix: [   11.849588] ath9k :02:00.0: 
>> enabling device ( -> 0002)
>> Feb  6 00:35:57 localhost vmunix: [   12.052196] ath9k :02:00.0 wlp2s0: 
>> renamed from wlan0
>> Feb  6 09:23:44 localhost vmunix: [   12.052555] ath9k :02:00.0 wlp2s0: 
>> renamed from wlan0
>> Feb  6 16:41:02 localhost vmunix: [21782.562086] [] 
>> ath_isr [ath9k]
>> Feb  6 16:48:04 localhost vmunix: [   67.024255] ath9k :02:00.0 wlp2s0: 
>> renamed from wlan0
>> Feb  6 18:18:40 localhost vmunix: [ 5507.166605] [] 
>> ath_isr [ath9k]
>> Feb  6 18:25:22 localhost vmunix: [   25.190524] ath9k :02:00.0 wlp2s0: 
>> renamed from wlan0
>> Feb  6 22:02:25 localhost vmunix: [   53.568402] ath9k :02:00.0 wlp2s0: 
>> renamed from wlan0
>> Feb  7 07:49:13 localhost vmunix: [ 4619.392030] ath9k :02:00.0: Refused 
>> to change power state, currently in D3
>> Feb  7 07:53:51 localhost vmunix: [   64.161516] ath9k :02:00.0 wlp2s0: 
>> renamed from wlan0
>> Feb  7 08:39:19 localhost vmunix: [ 2787.166577] [] 
>> ath_isr [ath9k]
>> Feb  7 08:50:07 localhost vmunix: [   18.319719] ath9k :02:00.0: 
>> enabling device ( -> 0002)
>> Feb  7 08:50:07 localhost vmunix: [   18.652179] ath9k :02:00.0 wlp2s0: 
>> renamed from wlan0
>> Feb  7 11:55:49 localhost vmunix: [   69.031690] ath9k :02:00.0 wlp2s0: 
>> renamed from wlan0
>>
>> lspci says this about my network controller:
>>
>> 02:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter 
>> (PCI-Express) (rev 01)
>>
>> It used to work fine for several months.  Not sure if it’s failing or if
>> there’s bad interaction with the kernel/libreboot.
>
> To make sure it's not a hardware problem, you could boot with a Live USB
> with Trisquel 7.0 (it has an older stable kernel) and see if you have
> stable WiFi. If not, maybe this is a good opportunity to upgrade to the
> best WiFi card compatible with fully free systems: Tehnoetic N450DB
> (a/b/g/n compliant, up to 450Mbps, Dual Band, 3-antenna connectors):
> https://tehnoetic.com/tet-n450db

I’m pretty sure now that it’s either a hardware problem or a weird
interaction of an older version of Libreboot with my failing hardware.
Can’t say for sure if it’s the mainboard giving up or just the WiFi card
(either is possible).  I’ll try updating Libreboot next and then move on
to buying a new WiFi card if that doesn’t help.

Thanks for the URL and the recommendation!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: gpg --verify

[Ricardo Wurmus]

Catonano  writes:

> $ ls
> Fedora-Workstation-25-1.3-x86_64-CHECKSUM
> Fedora-Workstation-Live-x86_64-25-1.3.iso
> guixsd-usb-install-0.12.0.x86_64-linux
> guixsd-usb-install-0.12.0.x86_64-linux.xz.sig

Looks like you’ve already unpacked the xz archive.  It should work fine
before unpacking.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: gpg --verify

[Ricardo Wurmus]

Catonano  writes:

> There' s a warning
>
> data probably signed in "guixsd-usb-install-0.12.0.x86_64-linux.xz"
> ...
> this key is not certified with a trusted signature
> There are no indications that the signature actually belongs to its owner
>
> is this good enough ?

Yes, this sounds scary but it is expected.  With GPG you can assign a
level of trust to keys.  If there’s a signature on my key from a key
that you have marked as trusted (e.g. Ludo’s signature, and you mark
Ludo’s key as trustworthy), then the warning would change or disappear.
The warning just indicates that there is no “trust path” to my key.

If this were a forged signature you would see a scarier validation
error, not just a warning.

It’s not great UX, I agree.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Installing the Xfce DE installs Unity

[Ricardo Wurmus]

Niall Dooley  writes:

> Hi Leo,
>
> On 12 February 2017 at 03:49, Leo Famulari  wrote:
>> On Thu, Feb 09, 2017 at 10:56:06PM +0100, Niall Dooley wrote:
>>
>> Hi!
>>
>>> I installed the Xfce (meta) package and on restarting the available DE
>>> on the login screen are the default (Trisquel) Gnome and Unity.
>>> Selecting Unity does indeed present a Unity session and not the
>>> expected Xfce. Any ideas?
>>
>> Can you share the operating system configuration file you're using for
>> this system, so that I can try to reproduce the issue?
>
> Excuse my ignorance - I don't believe I have one. I'm using Guix on a
> *foreign *distro. Do I need to create one to use a DE installed via Guix?
> Thanks for your patience.

As far as I know we haven’t packaged Unity for Guix at all.  Unity is
unrelated to Xfce.  I’m not sure you can actually use Xfce from Guix on
a foreign distro.  On GuixSD using a desktop environment requires that
certain services are running.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Package Installation Queries

[Ricardo Wurmus]

Niall Dooley  writes:

> I've installed Guix as a package manager on the Trisquel 7 distribution of
> GNU/Linux running on a (Minifree) Libreboot X60s. I believe it was
> successful. Hoping to transition to GuixSD at some point and would be
> grateful to hear if others have had success with this. Anyway,...

I’m using GuixSD on a X200s with Libreboot (flashed with the zerocat
chipflasher).  It’s working fine most of the time, but I’m experiencing
some weird behaviour that seems to be related to the version of
Libreboot I’m using (e.g. sometimes broken hotkeys).

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Package Installation Queries

[Ricardo Wurmus]

Ludovic Courtès  writes:

> I’ve been thinking we should have a way to hook importers and updaters
> directly to the command-line interface to facilitate this kind of
> experimentation.  Say:
>
>   guix package --importer=elpa -i something
>
> which would import ‘something’ and its dependencies on the fly.

This would be great!  For that to work reliably, though, we need to
improve the importers a little more.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: [ANN] Emacs-Guix 0.3

[Ricardo Wurmus]

Alex Kost  writes:

> Hello, I have updated 'emacs-guix' package to 0.3 (and guix development
> snapshot package as well btw).  For those, who don't know, Emacs-Guix is
> an Emacs interface for GNU Guix: .

[…]

Neat!  Congrats on the new release!

~~ Ricardo

Re: Backing up a GuixSD system? rsnapshot doesn't seem to like the store.

[Ricardo Wurmus]

dian_ce...@zoho.com writes:

>  My normal backup software (rsnapshot) doesn't seem to play
> terribly well with GuixSD because the software uses hardlinks for it's
> deduplication, so I'm looking for alternatives (or someone to tell me
> what needs to happen to get rsnapshot to backup /gnu/store without
> issue).
>
> I'd prefer something that has data deduplication at the very least.

I’m using borg for backups, but I haven’t tested backing up the store
itself because the state of my software environment is fully described
by the manifest and the guix version.

You can disable store deduplication if that causes problems, but that
has the obvious disadvantage of using more space.

~~ Ricardo

Re: normal user cant t login

[Ricardo Wurmus]

Catonano  writes:

> So I managed to install GuixSD
>
> When logging in as a normal user, I get taken back to the login screen
>
> I have these partitions:
>
> /
> /boot
> /home
> swap
>
> I report this because I remember this issue has been reported on the irc
> channel and it had to do with the partitions layout.

By default users don’t have passwords.  You need to log in as root on a
VT (e.g. after hitting Ctrl-Alt-F1) and then set the password for that
user.

~~ Ricardo

Re: guixsd

[Ricardo Wurmus]

Isorkin  writes:

> How to fix codepage in putty/kitty? The terminal is displayed normally.
> Bad view lines.
> config.scm
>
> (operating-system
>   (host-name "guixsd")
>   (timezone "Europe/Moscow")
>   (locale "ru_RU.utf8")

I’m afraid I don’t know.  This appears to be a question about using
PuTTY.  The characters look fine in your VNC session, so this is nothing
that should be fixed by changing GuixSD settings.

~~ Ricardo

Re: Operation System not found

[Ricardo Wurmus]

Catonano  writes:

> The installation process finished successfully but then the machine doesn'
> t boot :-/
>
> I tried also with a single huge partition mounted on /
>
> Same result :-/
>
> Did this happen to anyone else ?

Is this still a problem for you?  It is important that the information
in your operating-system configuration file accurately reflects your
partition layout.  In particular any UUIDs or device file names must
match.

Hopefully, the curses installer will make this a little easier.

~~ Ricardo

Re: [GuixSD] Extremely low framerate on desktop.

[Ricardo Wurmus]

Matthew Brooks  writes:

> Thanks for the reply; I hadn't even considered the issue of blobs
> separately from drivers.
> I just double-checked with a Trisquel liveUSB, and while it *does*
> show the same "VMWare" and "softpipe" stuff in glxinfo, the
> performance is much higher than on my GuixSD install, and it can even
> play HD videos without a hitch. So it looks like blobs aren't the
> issue. Which is nice, but does mean that it's probably a more
> difficult problem to track down. :/

It is possible that this is a problem with our mesa package, which does
not use LLVM for the Gallium drivers.  It might be worth changing this.

Unfortunately, this will result in quite a few rebuilds, so this change
would only be available in a few weeks.

Could you please send an email to bug-g...@gnu.org requesting that mesa
be built with LLVM for better performance of the Gallium drivers?

~~ Ricardo

Re: adawaita theme in Gnome

[Ricardo Wurmus]

Catonano  writes:

> So, our skillful thomasd solved an issue I had raised.
>
> In the Gnome desktop, when dragging an application toward the folating bar
> on the left, the whole desktop environment crashes, it restarts and you
> have to log on again.
>
> The problem is a missing mouse cursor, as stated here
> https://gnunet.org/bot/log/guix/2017-02-23#T1301986
>
> And the proposed workaround works like a charm.
>
> For reference, it is
> 1) "mkdir -p ~/.icons/default"
> 2) "ln -s /run/current-system/profile/share/icons/Adwaita/cursors/
> ~/.icons/default/cursors"
>
> What could be a definitive solution to patch the Gnome package with ?

We cannot (and don’t want to) let Guix packages modify the user’s home
directory.  On my system XDG_DATA_DIRS contains
“/run/current-system/profile/share”.  Is this not enough to let Gnome
find the cursors?

(The “adwaita-icon-theme” package is installed in my system profile.)

~~ Ricardo

Re: Backing up a GuixSD system? rsnapshot doesn't seem to like the store.

[Ricardo Wurmus]

dian_ce...@zoho.com writes:

> On Thu, 02 Mar 2017 13:56:28 +0100
> Ricardo Wurmus  wrote:
>> 
>> I’m using borg for backups, but I haven’t tested backing up the store
>> itself because the state of my software environment is fully described
>> by the manifest and the guix version.
>
> Doesn't that mean the system can't be restored from the backups without
> having to reinstall the entire OS?

Yes.  In my case that’s an acceptable trade-off.

~~ Ricardo

Re: persistent reproducibility ?

[Ricardo Wurmus]

zimoun  writes:

> One of the issues is that the Guix packages tree will never include
> some softwares, even if they are open source. Because the authors
> apply weird licences or non-GNU compliant licences, or simply because
> authors are not so motivated to push. Even if I totally agree with the
> paragraph about Proprietary Softwares in your cited paper, it is just
> a fact from my humble opinion.

If you mean “open source” in the sense of “using a license that is
certified by the Open Source Initiative” then that software is probably
Free Software.  There is no such thing as GNU compliance in licenses.

We do however follow the GNU FDSG (Free System Distribution Guidelines),
which may result in some software to be excluded or modified in rare
cases.  (One example is “Shogun”, which we modify to remove included
non-free software.)

> Therefore, what should be the "standard" way to manipulate against
> history version external and decentralised packages ? and guix repo
> packages too ?
>
>
> Well, if I understand your both answers, the correct process should
> be: Alice publishes a paper containing the exact version (commit hash
> or revision number or origin hash) of both the source tree and the
> recipe tree, and their both uri location, and then, Joe "just" needs
> to check out each (manually for now or possibly by nice UI glue).

It would be sufficient to provide two things: a manifest and the Guix
version (“git -C /path/to/guix.git describe”).  If additional package
repositories are used (such as guix-bimsb for my institute), their
versions have to be recorded as well.

Joe would then check out Guix and any additional package repositories at
the specified versions and then instantiate the manifest.  Provided that
all source tarballs are still obtainable (either directly or through a
mirror) and the builds are in fact bit-reproducible Joe would end up
with the same software environment that Alice fully specified in the
paper.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: downloading a tarball

[Ricardo Wurmus]

Catonano  writes:

> This
> https://sourceforge.net/projects/libxls/files/
>
> I attempted to build the package several times but every time the hash
> results to be wrong.
>
> I correct it and then it's wrong again
>
> For example, I get
>
> @ build-failed
> /gnu/store/dcaqrf007jxyi0jzlsakr3j7faxm122f-libxsl-1.4.0.tar.gz.drv - 1
> output path
> `/gnu/store/v6i85v3myb09nbsacq9ghx6yd0spcr67-libxsl-1.4.0.tar.gz' should
> have sha256 hash `1574bcyagix5fkbs0yi2npi59y1zck23y2aia52vdv6ra3i5raid',
> instead has `1zmsb0w6qh4vx7n7r3yijc5p4fwljyk5apzi1hwmrr5rkawmqmks'
>
> so I change it to
> 1zmsb0w6qh4vx7n7r3yijc5p4fwljyk5apzi1hwmrr5rkawmqmks
>
> and then I get
>
> @ build-failed
> /gnu/store/vsl7yz0nyklv0705jb5py015jkz3r6dg-libxsl-1.4.0.tar.gz.drv - 1
> output path
> `/gnu/store/wjyja461cr7kvvryp6v21q3iagf5rd8m-libxsl-1.4.0.tar.gz' should
> have sha256 hash `1zmsb0w6qh4vx7n7r3yijc5p4fwljyk5apzi1hwmrr5rkawmqmks',
> instead has `0fyd8h4i46qw3xii3pfa12k9k9ndmj59b552pmkpwcq7psyrbf32'
>
> So now it's not 1zmsb0w6qh4vx7n7r3yijc5p4fwljyk5apzi1hwmrr5rkawmqmks
> anymore. It's
> 0fyd8h4i46qw3xii3pfa12k9k9ndmj59b552pmkpwcq7psyrbf32
>
> I'm doing this with a master checkout.
>
> What am I missing ?

Have you confirmed that the file you get is actually a tarball?
Sometimes you might get an HTML page and Guix reports the hash for that.

In general it is better to download the tarball manually and then use
“guix hash” on the result after confirming that the tarball is in fact
okay (e.g. by validating signatures or inspecting it).

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: hg repos

[Ricardo Wurmus]

Catonano  writes:

> is there a hg-download in Guix ?

Yes.  There’s a module “(guix hg-download)”, which provides the
“hg-fetch” method and the “hg-reference” uri.

It’s used in the “seek” package in “(gnu packages bioinformatics)”.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: test-driver

[Ricardo Wurmus]

Catonano  writes:

> In trying to build libxls tests fail because a test-driver file is missing
>
> Like this
>
> ...
> make check-TESTS
> make[2]: ingresso nella directory
> "/tmp/guix-build-libxsl-1.4.0.drv-0/source/libxls/test"
> make[3]: ingresso nella directory
> "/tmp/guix-build-libxsl-1.4.0.drv-0/source/libxls/test"
> /gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0/bin/bash:
> ../test-driver: File o directory non esistente
> ...
>
> I asked upstream and I was informed that there's no "test-driver"
> occurrence in libxls source. So they suggest it has to be something
> specific of my build environment
>
> You can see the exchange we had, here
> https://sourceforge.net/p/libxls/discussion/294119/thread/4b5ce0d8/?limit=25#1550
>
> Here is my definition for libxls
> http://paste.lisp.org/display/342783

Here’s my updated definition:

http://paste.lisp.org/display/342783#1

> Is this a Guix thing ?

Unlikely.  I found that rebootstrapping fixes this, so it appears to be
part of the generated files in the release tarball.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Hwo to debug and teacking builds?

[Ricardo Wurmus]

Catonano  writes:

> I remember seeing an Emacs package that displays a preview of the whole
> document (buffer ?) in a small region of the window (frame ?)
>
> So that you can know which portion of the document is currently displayed
>
> Gedit, like many editors, does this, it's showed here (the small square on
> the right)
> ctrlv.in/938108

I cannot see the picture, but I think you mean a feature provided by
both “minimap” and “sublimity”.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

libstdc++ for cross compilers

[Ricardo Wurmus]

Hi Guix,

I’m trying to update my custom package for the Axoloti audio board,
which is not yet in Guix because it depends on bundled Java jars.  The
package includes a user interface written in Java and a cross-compiled
firmware for the board.

The latest version includes C++ sources for the firmware.
Unfortunately, our “arm-none-eabi” cross-compiler package does not
build libstdc++, nor does it come with any of the required C++ headers
like “cmath”.

So I tried to change our “arm-none-eabi” cross-compiler packages to also
build and install libstdc++ but failed in a multitude of ways.  The end
result is always that either the compiler fails to build (e.g. when
enabling libstdc++ via configure flags) or that the compiler fails to
find the header files that are included via “#include_next” directives
(e.g. when building libstdc++ as a separate package).

Could someone with GCC experience give me a hint despite my vague
problem description?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: libstdc++ for cross compilers

[Ricardo Wurmus]

Hi Ludo,

thanks for the hints.

> Ricardo Wurmus  skribis:
>
>> The latest version includes C++ sources for the firmware.
>> Unfortunately, our “arm-none-eabi” cross-compiler package does not
>> build libstdc++, nor does it come with any of the required C++ headers
>> like “cmath”.
>>
>> So I tried to change our “arm-none-eabi” cross-compiler packages to also
>> build and install libstdc++ but failed in a multitude of ways.  The end
>> result is always that either the compiler fails to build (e.g. when
>> enabling libstdc++ via configure flags) or that the compiler fails to
>> find the header files that are included via “#include_next” directives
>> (e.g. when building libstdc++ as a separate package).
>>
>> Could someone with GCC experience give me a hint despite my vague
>> problem description?
>
> libstdc++ itself can probably be cross-built with:
>
>   guix build libstdc++ --target=arm-none-eabi

I created a package variant like this:

--8<---cut here---start->8---
(define-public libstdc++-arm-none-eabi
  (let* ((xgcc gcc-arm-none-eabi-6)
 (libstdc++ (make-libstdc++ xgcc)))
(package (inherit libstdc++)
  (name "libstdc++-arm-none-eabi")
  (arguments
   (substitute-keyword-arguments (package-arguments libstdc++)
 ((#:configure-flags flags)
  ``("--target=arm-none-eabi"
 "--disable-libstdcxx-pch"
 ,(string-append "--with-gxx-include-dir="
 (assoc-ref %outputs "out")
 "/arm-none-eabi/include"
--8<---cut here---end--->8---

And adding it to the inputs for the Axoloti firmware seems to be fine
for a while until it fails to find headers with “#include_next”.  I’ll
try to gather some better error messages.

> The problem is getting a cross-g++.  I suspect libstdc++ sorta relies on
> having a “real” libc, which is why we normally do things like:
>
>(let ((triplet "arm-linux-gnueabihf"))
>  (cross-gcc triplet
> (cross-binutils triplet)
> (cross-libc triplet
>
> where the final ‘cross-gcc’ has C++ support.

I find this confusing because the binary release of the arm-none-eabi
cross-compiler includes the libstdc++ headers — and it doesn’t appear to
use the GNU libc at all.  It includes two libc variants which were both
derived from newlib (regular and “nano” configurations).

> I’m not sure if it makes sense for the board you’re targeting, but maybe
> you could try building with a full-blown cross-gcc like this?

I can give it a try but I don’t think it makes sense for the board.
It’s not supposed to use anything but the special implementations of
newlib-nano.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: walking up the filetree (in a Guix related package)

[Ricardo Wurmus]

ng0  writes:

> This is very similar to what I use in the gnURL release procedure,
> but it has one defect: It requires that the file is located in the
> top sourcedirectory / root directory of the source.
>
> I'm trying to change this:
>
> (define %source-dir (dirname (current-filename)))
>
> so that it interacts with the (source (local-file))
> of the package and allows the package to sit in contrib/guix-neomutt.scm,
> but I'm not sure how this can be achieved. All ways I've tried failed
> so far. What part of the Guile documentation could help?

What have you tried and how have these attempts failed?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: runpath validation

[Ricardo Wurmus]

Catonano  writes:

> 2017-04-20 10:10 GMT+02:00 Ludovic Courtès :
>
>>
>> You should grep for RUNPATH, and I guess that will show that
>> /gnu/store/zv2c9mbs4q7f75p9xlgxs62fb5wmp3ac-granite-0.4.0.1/lib is *not*
>> in there, even though it should (if it’s not in RUNPATH, then launching
>> ‘granite-demo’ will result in a “library not found” error, which is what
>> this validation phase wants to avoid.)
>>
>
> and instead what I found is that ...granite/lib *is* there

Cmake is a bit weird sometimes.  Look at the definition for “bamtools”
to see how you may be able to explicitly add the lib directory to the
RUNPATH.

Other examples are “powertabeditor” and “lmms” in music.scm.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: tree doesn't get called

[Ricardo Wurmus]

Catonano  writes:

> Would you mind to take a look at this new version ?
>
> http://paste.lisp.org/display/346142
>
> The
>
> (copy-file file
>dest-file)
>
> piece fails with
>
> ...
> In unknown file:
>?: 0 [copy-file "include.scm" ...]
>
> ERROR: In procedure copy-file:
> ERROR: In procedure copy-file: No such file or directory
>
> But as you can see on te "tree" output, include.scm is there indeed

It looks like you first need to create the target directory (with
“mkdir-p”).

BTW: instead of an explicit list for scm-files you could use this:

(find-files "." "\\.scm$")

--
Ricardo

  GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
  https://elephly.net

Re: tree doesn't get called

[Ricardo Wurmus]

Catonano  writes:

> In fact, I'd paste code even on IRC channels, I don't do so because I have
> been requested to abstain from pasting code in chat channels in the past
>
> But I don't understand the reason why that is not desirable, inconvenient
> and frown upon.

IRC is for real-time conversations, and pasting many lines of code there
makes it hard to converse.  A channel can be very crowded even without
pasting code snippets, so it’s best to keep excess text to a minimum.  I
guess that’s why it’s customary on IRC to paste code elsewhere and just
link to it.

For mails it’s fine (and desirable) to include code snippets inline or
as attachments.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: tree doesn't get called

[Ricardo Wurmus]

Here’s a version that works for me:

--8<---cut here---start->8---
(define-public guile-miniadapton
  (let ((commit "1b5749422304567c96ac5367f2221dda9eff5880")
(revision "1"))
(package
  (name "guile-miniadapton")
  (version (string-append "0-" revision "." (string-take commit 9)))
  (source (origin
(method git-fetch)
(uri (git-reference
  (url "https://github.com/fisherdj/miniAdapton.git";)
  (commit commit)))
(file-name (string-append name "-" version "-checkout"))
(sha256
 (base32
  "09q51zkw2fypad5xixskfzw2cjhjgs5cswdp3i7cpp651rb3zndh"
  (build-system gnu-build-system)
  (arguments
   `(#:modules ((guix build utils)
(ice-9 popen)
(ice-9 rdelim)
(srfi srfi-1)
(guix build gnu-build-system))
 #:tests? #f; there is no test target
 #:phases
 (modify-phases %standard-phases
   (delete 'configure)
   (delete 'build)
   (replace 'install
 (lambda* (#:key outputs #:allow-other-keys)
   (let* ((cwd(getcwd))
  (scm-files  (find-files "." "\\.scm$"))
  (effective  (read-line
   (open-pipe* OPEN_READ
   "guile" "-c"
   "(display 
(effective-version))")))
  (module-dir (string-append (assoc-ref outputs "out")
 "/share/guile/site/"
 effective)))

 ;; Make installation directories.
 (mkdir-p module-dir)

 (setenv "GUILE_AUTO_COMPILE" "0")

 ;; Compile .scm files and install.
 (every (lambda (file)
  (let ((go-file (string-append module-dir "/"
(basename file ".scm") 
".go")))
;; Install source module.
(install-file file module-dir)
;; Compile and install module.
(zero? (system* "guild" "compile" "-L" cwd
"-o" go-file file
scm-files)))
  (inputs
   `(("guile" ,guile-2.2)))
  (home-page "https://github.com/fisherdj/miniAdapton";)
  (synopsis "Minimal implementation of incremental computation in Guile
Scheme")
  (description "This package provides a complete Scheme implementation of
miniAdapton, which implements the core functionality of the Adapton system for
incremental computation (also known as self-adjusting computation).  Like
Adapton, miniAdapton allows programmers to safely combine mutation and
memoization.  miniAdapton is built on top of an even simpler system,
microAdapton.  Both miniAdapton and microAdapton are designed to be easy to
understand, extend, and port to host languages other than Scheme.")
  (license license:expat
--8<---cut here---end--->8---

If you have any questions about this just ask!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: tree doesn't get called

[Ricardo Wurmus]

Catonano  writes:

>> Here’s a version that works for me:
>>
>>
>>  ;; Compile .scm files and install.
>>  (every (lambda (file)
>>   (let ((go-file (string-append module-dir "/"
>> (basename file
>> ".scm") ".go")))
>> ;; Install source module.
>> (install-file file module-dir)
>> ;; Compile and install module.
>> (zero? (system* "guild" "compile" "-L" cwd
>> "-o" go-file file
>>
>
> The differences with my version is that you use install-file insted of
> copy-file  and you pass the -L (cwd) switch to guild

These were mostly cosmetic changes.  I evaluate “(getcwd)” once and bind
it to “cwd” instead of evaluating it again and again for each file.
This is not what fixed the crash.

“install-file” only takes a file and a directory, unlike “copy-file”
which takes a source file name and a target file name.  I did this just
to simplify the code.

> I wonder what was causing my issue ?

Another difference is that I’m using “basename”.  Your use of “match”
didn’t work, because the match pattern wasn’t correct for the
“find-files” case.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: tree doesn't get called

[Ricardo Wurmus]

Catonano  writes:

> I forgot: the linter crashes, but not only on guile-miniadapton. Also on
> guile-irregex that was already there

[…]

> Backtrace:uile-irregex@0.9.6 [cve]...
>9 (primitive-load
>"/home/catonano/projects/readxl/scripts…")

That’s suspicous…

> In guix/ui.scm:
>1255:8  8 (run-guix-command _ . _)
> In srfi/srfi-1.scm:
> 640:9  7 (for-each # …)
> In guix/scripts/lint.scm:
> 982:4  6 (run-checkers _ _)
> In srfi/srfi-1.scm:
> 640:9  5 (for-each # …)
> In guix/scripts/lint.scm:
> 805:4  4 (check-vulnerabilities _)
> 800:9  3 (_ _)
> In unknown file:
>2 (force #)
> In guix/scripts/lint.scm:
>789:24  1 (_)
> In ice-9/boot-9.scm:
> 837:9  0 (catch srfi-34 # …)
>
> ice-9/boot-9.scm:837:9: In procedure catch:
> ice-9/boot-9.scm:837:9: Wrong type to apply: # 0x7fd83aa8ae08) @ 0x7fd83b040318>

I cannot reproduce this running “./pre-inst-env guix lint guile-irregex”
on master.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: youtube in Web

[Ricardo Wurmus]

Catonano  writes:

> Youtube doesn't work anymore in Web
>
> It works like a charm in Icecat though

You need to install some gstreamer plugins, such as the following:

"gst-plugins-base"
"gst-plugins-good"
"gst-plugins-ugly"
"gst-libav"

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Help getting started with first contribution

[Ricardo Wurmus]

Hi André,

> I've been using Guix and GuixSD recently and I'd like to contribute!

Excellent!

> However, I'm not familiar at all with mailing list workflows (this is
> the first mailing list I actually subscribed to), so I may need some
> guidance with that.

It’s pretty simple: you send an email to guix-patc...@gnu.org (you will
get an automated reply with a bug identifier) and wait for someone to
comment.  If you need to make changes you just send email to the bug
address.

> I thought about starting by creating a Guix package for
> git-remote-gcrypt
> (https://spwhitton.name/tech/code/git-remote-gcrypt/). The package
> definition should be fairly simple, since the main program is just a
> shell script with no compilation dependencies.

Sounds good.  You may find that programmes using the GNU build system
are usually the easiest to package.  Sometimes simple shell scripts or
custom build systems make unrealistic assumptions about the system that
they are installed on, which makes the package definition a little more
complicated.

In the case of git-remote-gcrypt, for example, you will need to delete
the “configure” and “build” phases, set the “prefix” in a make-flag, and
create the target directories in an extra build phase.

> I'm looking forward to being part of this community.

We’d be happy to see you join us!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: youtube in Web

[Ricardo Wurmus]

Catonano  writes:

> 2017-05-12 7:42 GMT+02:00 Ricardo Wurmus :
>
>>
>> Catonano  writes:
>>
>> > Youtube doesn't work anymore in Web
>> >
>> > It works like a charm in Icecat though
>>
>> You need to install some gstreamer plugins, such as the following:
>>
>> "gst-plugins-base"
>> "gst-plugins-good"
>> "gst-plugins-ugly"
>> "gst-libav"
>>
>
> Thanks. The gly one was miiissing
>
> But that is not enough to get yotube working in Web

Hmm, for me youtube works in epiphany.  For me the missing ingredient
was gst-libav.

Also, I have this environment variable set:

  GST_PLUGIN_PATH=/home/rekado/.guix-profile/lib/gstreamer-1.0

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: libstdc++ for cross compilers

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Hi Ludo,
>
> thanks for the hints.
>
>> Ricardo Wurmus  skribis:
>>
>>> The latest version includes C++ sources for the firmware.
>>> Unfortunately, our “arm-none-eabi” cross-compiler package does not
>>> build libstdc++, nor does it come with any of the required C++ headers
>>> like “cmath”.
>>>
>>> So I tried to change our “arm-none-eabi” cross-compiler packages to also
>>> build and install libstdc++ but failed in a multitude of ways.  The end
>>> result is always that either the compiler fails to build (e.g. when
>>> enabling libstdc++ via configure flags) or that the compiler fails to
>>> find the header files that are included via “#include_next” directives
>>> (e.g. when building libstdc++ as a separate package).
>>>
>>> Could someone with GCC experience give me a hint despite my vague
>>> problem description?
>>
>> libstdc++ itself can probably be cross-built with:
>>
>>   guix build libstdc++ --target=arm-none-eabi
>
> I created a package variant like this:
>
> --8<---cut here---start->8---
> (define-public libstdc++-arm-none-eabi
>   (let* ((xgcc gcc-arm-none-eabi-6)
>  (libstdc++ (make-libstdc++ xgcc)))
> (package (inherit libstdc++)
>   (name "libstdc++-arm-none-eabi")
>   (arguments
>(substitute-keyword-arguments (package-arguments libstdc++)
>  ((#:configure-flags flags)
>   ``("--target=arm-none-eabi"
>  "--disable-libstdcxx-pch"
>  ,(string-append "--with-gxx-include-dir="
>  (assoc-ref %outputs "out")
>  "/arm-none-eabi/include"
> --8<---cut here---end--->8---
>
> And adding it to the inputs for the Axoloti firmware seems to be fine
> for a while until it fails to find headers with “#include_next”.  I’ll
> try to gather some better error messages.
>
>> The problem is getting a cross-g++.  I suspect libstdc++ sorta relies on
>> having a “real” libc, which is why we normally do things like:
>>
>>(let ((triplet "arm-linux-gnueabihf"))
>>  (cross-gcc triplet
>> (cross-binutils triplet)
>> (cross-libc triplet
>>
>> where the final ‘cross-gcc’ has C++ support.
>
> I find this confusing because the binary release of the arm-none-eabi
> cross-compiler includes the libstdc++ headers — and it doesn’t appear to
> use the GNU libc at all.  It includes two libc variants which were both
> derived from newlib (regular and “nano” configurations).
>
>> I’m not sure if it makes sense for the board you’re targeting, but maybe
>> you could try building with a full-blown cross-gcc like this?
>
> I can give it a try but I don’t think it makes sense for the board.
> It’s not supposed to use anything but the special implementations of
> newlib-nano.

It didn’t work.  I added a (cross-libc "arm-none-eabi") to the
cross-compiler, but all I got was:

--8<---cut here---start->8---
checking for sysdeps preconfigure fragments... aarch64 alpha arm configure: 
WARNING: arm/preconfigure: Did not find ARM architecture type; using default
hppa i386 m68k microblaze mips nacl nios2 powerpc s390 sh sparc tile x86_64
configure: running configure fragment for add-on libidn
configure: error:
*** The GNU C library is currently unavailable for this platform.
*** If you are interested in seeing glibc on this platform visit
*** the "How to submit a new port" in the wiki:
***   https://sourceware.org/glibc/wiki/#Development
*** and join the community!
phase `configure' failed after 1.3 seconds
note: keeping build directory 
`/tmp/guix-build-glibc-cross-arm-none-eabi-2.25.drv-0'
--8<---cut here---end--->8---

It would also have been weird to build with the GNU libc first and then
later drop it and replace it with newlib, which is what’s used to target
the board.

I’ll have to experiment more with this; maybe there’s another way to get
a functioning g++ cross-compiler for this board.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: libstdc++ for cross compilers

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Ricardo Wurmus  writes:
>>
>> I created a package variant like this:
>>
>> --8<---cut here---start->8---
>> (define-public libstdc++-arm-none-eabi
>>   (let* ((xgcc gcc-arm-none-eabi-6)
>>  (libstdc++ (make-libstdc++ xgcc)))
>> (package (inherit libstdc++)
>>   (name "libstdc++-arm-none-eabi")
>>   (arguments
>>(substitute-keyword-arguments (package-arguments libstdc++)
>>  ((#:configure-flags flags)
>>   ``("--target=arm-none-eabi"
>>  "--disable-libstdcxx-pch"
>>  ,(string-append "--with-gxx-include-dir="
>>  (assoc-ref %outputs "out")
>>  "/arm-none-eabi/include"
>> --8<---cut here---end--->8---
>>
>> And adding it to the inputs for the Axoloti firmware seems to be fine
>> for a while until it fails to find headers with “#include_next”.  I’ll
>> try to gather some better error messages.

The problem turned out to be right there: the configure flags set
“--target” but not “--host”, so libstdc++ wasn’t cross-built.

I have already overcome the problem and will submit a couple of patches
in the coming days.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Emacs-Guix 0.3.1

[Ricardo Wurmus]

Fox  writes:

>   Alex Kost wrote:
>
>> if you don't like to read "info", Emacs-Guix manual is available
>> online now:
>
>   https://alezost.github.io/guix.el/manual/latest/html_node/index.html
>
>
> html sure is better workable than the "info" format.

Actually, I think Info is superior, not least because of the index.  In
an Info reader (Emacs, for example) you can hit “i” and start typing a
concept.  A well-written manual will take you right to the section
explaining the concept, even if the exact phrase is not used in the
manual text.

For those who aren’t yet familiar or comfortable with Info readers work
is underway to add some JavaScript to HTML pages that can be generated
from the Texinfo sources.  The added scripts would provide similar
features as a traditional Info reader application.

Until then I really recommend learning a bit about Info and how to use
it.  It’s a really good system and generally provides better results
than a web search.

If there are concepts that are not in the index we welcome patches to
add them.

> But then, some GNU documentation suffers from lack of ability to explain
> things to folks who do NOT know it all already.
>
> case in point:
> https://www.gnu.org/software/emacs/manual/html_mono/eshell.html#Invocation

The Eshell documentation has long suffered from a lack of good
documentation, so I think it’s not a good example.  There are
some truly outstanding Info manuals in GNU.  It can be fun to browse
them in a local Info reader.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Kernel panic - not syncing: attempting to kill init! when booting GuixSD

[Ricardo Wurmus]

Christopher Baines  writes:

> Excluding the generations that I removed, the others don't boot. All I
> can really gather so far is a call stack, and the message:
>   Kernel panic - not syncing: Attempted to kill init!

Has the label of your root partition changed?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Retrieving the OpenPGP key used to sign the release

[Ricardo Wurmus]

Quiliro  writes:

> El Tue, 23 May 2017 22:24:38 +0200
> l...@gnu.org (Ludovic Courtès) escribió:
>
>> Quiliro  skribis:
>> 
>> > $ gpg --verify guixsd-usb-install-0.13.0.i686-linux.xz.sig 
>> > gpg: supozas subskribitajn datenojn en 
>> > 'guixsd-usb-install-0.13.0.i686-linux.xz'
>> > gpg: Signature made lun 22 Maj 2017 07:51:35 -0500 ECT using RSA key ID 
>> > 3D9AEBB5
>> > gpg: Ne povas kontroli subskribon: publika ŝlosilo ne trovita
>> >
>> > $ gpg --keyserver keys.gnupg.net --recv-keys 
>> > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5
>> > gpg: requesting key 3D9AEBB5 from hkp server keys.gnupg.net
>> > ?: keys.gnupg.net: Host not found
>> > gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused
>> > gpg: validaj OpenPGP-datenoj ne trovitaj.
>> > gpg:   Nombro traktita entute: 0
>> 
>> Oops, keys.gnupg.net seems to be retired.  Please use
>> pool.sks-keyservers.net instead, for example.
>
> How? Is that documented?

Instead of

gpg --keyserver keys.gnupg.net --recv-keys 
3CE464558A84FDC69DB40CFB090B11993D9AEBB5

use

gpg --keyserver pool.sks-keyservers.net --recv-keys 
3CE464558A84FDC69DB40CFB090B11993D9AEBB5


-- 
Ricardo
  
  GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
  https://elephly.net

Re: installing a mirror for offline installation

[Ricardo Wurmus]

Quiliro  writes:

> I finally could install bare-bones.scm GuixSD working machine. Now i
> am interested in installing a mirror [of hydra] for offline
> installation. There is no telecommunications where I live. So I could
> bring the server to download substitutes and then take it back to my
> network for local download. I was told that an nginx mirror of hydra
> would cache only substitutes after they have been requested through
> it.

This is a little complicated.  We build software continuously with
Hydra, so what you want would only really work for one particular
version of Guix.

Hydra provides binaries not only for a single version of Guix, so you
cannot just copy everything.  What you *can* do, however, is this:

* provision a portable computer with lots of disk space

* check out the version of Guix you plan to install elsewhere

* build *every* package that you know you will need at the remote site.
  (This could be done by building a system configuration, for example.)
  This will lead to every needed store item to be in your local
  /gnu/store.  Note that you don’t have to build everything from source;
  you can download substitutes for most things.

* set up “guix publish” to share items from your store with others.
  Also make sure to export your local key and authorize it on the
  machines that should install Guix “offline”.

* On the machines that are to be installed override the substitute
  server to be the local address of your portable computer running “guix
  publish”.  This could be a local IP address.

* Make sure that the machines use the exact same version of Guix,
  e.g. the latest release.

As the machines are installed they will download substitutes from the
portable computer instead of trying to go online to talk to hydra.
Since the portable computer has all needed binaries in its store,
nothing has to be built from source.

All you need for this on the remote offline site is a LAN where your
portable computer acts as a substitute server.

Does this make sense?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: installing a mirror for offline installation

[Ricardo Wurmus]

Quiliro  writes:

> El Fri, 26 May 2017 13:20:36 +0200
> Ricardo Wurmus  escribió:
>
>>
>> Quiliro  writes:
>>
>> > I finally could install bare-bones.scm GuixSD working machine. Now i
>> > am interested in installing a mirror [of hydra] for offline
>> > installation. There is no telecommunications where I live. So I could
>> > bring the server to download substitutes and then take it back to my
>> > network for local download. I was told that an nginx mirror of hydra
>> > would cache only substitutes after they have been requested through
>> > it.
>>
>> This is a little complicated.  We build software continuously with
>> Hydra, so what you want would only really work for one particular
>> version of Guix.
>>
>> Hydra provides binaries not only for a single version of Guix, so you
>> cannot just copy everything.  What you *can* do, however, is this:
>>
>> * provision a portable computer with lots of disk space
>
> Will 100GB be enough? 1TB?

Do you need *all* packages?  Note that it would only be for *one*
version of Guix, so you’d have to do this again if you want to update
the machines at some point.

>> * check out the version of Guix you plan to install elsewhere
>>
>> * build *every* package that you know you will need at the remote site.
>>   (This could be done by building a system configuration, for example.)
>
> I have no idea how to do this. I know how to install a group of
> packages to make a desktop for example. But is there a group where all
> packages are installed? Could there be a conflict where one package is
> not downloaded because it will conflict with another? (I know this is
> usually not the case in GuixSD but all cases have been considered?)

There will not be any conflicts.  You don’t install these packages into
a profile, you just add them to the store where every item has its own
directory.  Only when installing packages into a single profile there
can be file name conflicts.

Not all packages can actually be built.  There’s a small percentage of
packages that fails to build from source and you would probably waste a
lot of time trying to build them locally.  I don’t know if there’s an
easy way to exclude those packages and refuse to build anything locally
(maybe with a smart offloading setup).

It might be easier to just build a single complete system configuration,
export it (e.g. with “guix archive” or “guix copy”) and import it on the
other machine.  I don’t think it’s a good idea to repeatedly build and
copy store items over.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: installing a mirror for offline installation

[Ricardo Wurmus]

(+ help-guix)

Quiliro  writes:

> Yes. I will want all packages. I will work with all packages for an
> extended period. When I am desperate for an update, I would take the
> _server_ for update.

Okay.  Maybe it would be better then to set up an instance of cuirass on
your portable server and specifically enable the use of substitutes.  It
would build / download all packages according to its configuration.  You
can limit the configuration such that it only provides binaries for your
desired architecture.

I must admit, though, that I’ve been trying to do something just like
that, but I haven’t fully succeeded yet, because Cuirass doesn’t handle
errors well.  But it wouldn’t hurt to have more users and contributors
to Cuirass.

>> Not all packages can actually be built.  There’s a small percentage of
>> packages that fails to build from source and you would probably waste a
>> lot of time trying to build them locally.  I don’t know if there’s an
>> easy way to exclude those packages and refuse to build anything locally
>> (maybe with a smart offloading setup).
>
> How is this?

Not all software builds at all time.  That’s pretty normal.  All
software has bugs and some software requires patching before it can be
built with particular versions of other pieces of software.  That’s what
we’re working on collectively as package maintainers.

>> I don’t think it’s a good idea to repeatedly build and
>> copy store items over.
>
> It could be done every 2 months.

If the machines are not connected to the internet this is okay.  If they
are used to connect to the internet, however, it would be a bad idea to
let them use outdated software.  Patches come in at irregular intervals
that are shorter than a 2 month period.

Hardly a week goes by without some new vulnerability.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: installing a mirror for offline installation

[Ricardo Wurmus]

Quiliro  writes:

> El Thu, 25 May 2017 18:19:02 -0500
> Quiliro  escribió:
>
>> I finally could install bare-bones.scm GuixSD working machine. Now i am 
>> interested in installing a mirror [of hydra] for offline installation. There 
>> is no telecommunications where I live. So I could bring the server to 
>> download substitutes and then take it back to my network for local download. 
>> I was told that an nginx mirror of hydra would cache only substitutes after 
>> they have been requested through it. Nevertheless, for those that need that, 
>> here is the config:
>> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx/mirror.conf
>>
>> Since that solution is not for offline use, please suggest what I should do.
>>
>
> I would still want to test installing a hydra mirror. Is there a howto for 
> this?

I have already replied to your previous email on the 26th.  Have you
tried those suggestions?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Xorg won't start

[Ricardo Wurmus]

some...@selfhosted.xyz writes:

>> (define (my-slim-service)
>> (mlet* %store-monad ((config (xorg-configuration-file
>> ;;  #:drivers '("nouveau" "vesa")
>> #:resolutions '((1920 1080) (1366 768) (1024 768))
>> ))
>>  (startx (xorg-start-command
>> #:configuration-file config)))
>> (slim-service #:startx startx)))
> ..
> (services (cons* (xfce-desktop-service)
>   (my-slim-service)
>   %desktop-services))

This probably won’t do what you want.  First, the %desktop-services
contain an implementation of the slim-service-type, so you’ll get two
services that want to start X.

Instead of defining my-slim-service (which looks more complicated than
it should), how about just modifying the service with the
slim-service-type?  Here’s a snippet to append config snippets to the
xorg configuration file:

--8<---cut here---start->8---
  (services (cons* (whatever-service)
   (modify-services %desktop-services
 (slim-service-type
  config => (slim-configuration
 (inherit config)
 (startx (xorg-start-command
  #:configuration-file
  (xorg-configuration-file
   #:extra-config
   (list marble-mouse-settings
 dvorak-evdev)
--8<---cut here---end--->8---

Hope this helps!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

failed to resolve partition “my-root”

[Ricardo Wurmus]

Hi Guix,

I just installed Guix onto a server.  I ran “guix pull” before “guix
system init” and I made sure that my config file is correct.  It is
based on “bare-bones.scm” – I only changed the user name and replaced
“sdX” with “sdb” (because the hard disk was recognized as sdb).

In the GRUB console I confirmed that the first partition on the hard
disk has in fact the label “my-root”.

Linux appears to boot but then fails with “failed to resolve partition
"my-root"”.  I suspect that something in (gnu build file-systems) is
broken.  koosha on IRC previously reported a similar problem.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net