Re: my latest blog post

[myglc2]

On 06/07/2018 at 17:25 Catonano writes:

> I just published my latest blog post
>
> In this post I discuss Guix
>
> And I discuss Guile too
>
> I understand that the language is strong and I expect someone to be upset
>
> But I feel this is due
>
> Happy reading
>
> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

Hi Catonano,

Thank you for taking the time to contribute your thoughts. I am sorry to
see you getting so beat up by the responses.  Unfortunately the
nit-picking of criticisms and the "we are busy, why don't you dig in and
fix it" responses occur too often on the Guix lists.

Such responses are fundamentally unhelpful: A defensive response of
counter-criticism that spirals out of control buries the original input
and alienates potential new contributors. I agree with you that the
suggestion that you dig in and fix something you are struggling with is
a fundamentally unfriendly response.

I appreciate the effort you made to learn Guix and the risk you took to
report on the problems you experienced. I am interested in getting to
the root causes of your frustration. I re-read your post and
emails. Would it be fair to say ...

1) The monad/daemon/store is presented as central to Guix and is very
difficult to understand. If a Guix user really needs to understand it,
it needs to be explained better.

2) Sending Guix users upstream for Guile support is not working.

If these are correct, the reality is that only a few people on the
planet are in a position to address these issues. The rest of us have to
hope that they can see why it is important to stop coding long enough to
do so, perhaps in collaboration with a confused user or two ;-)

- George

Re: [ANN] "Practical, verifiable software freedom with GuixSD" presentation now available

[myglc2]

Hi Dave,

On 03/29/2018 at 13:32 Ludovic Courtès writes:

> "Thompson, David"  skribis:
>
>> The FSF has uploaded my talk about Guix from this past weekend's
>> LibrePlanet conference.  If you're interested, you can watch it at
>> this URL:
>>
>> https://media.libreplanet.org/u/libreplanet/m/practical-verifiable-software-freedom-with-guixsd/
>
> Great talk!  It’s always refreshing to see new ways of approaching the
> problem space and solutions that Guix provides.

WOW, I agree. I found the motivational examples outstanding!

Highly recommended for current users too ... I discovered cool things I
had failed to learn in 2 years of using GuixSD ;-)

>> The slide stream is not incorporated into the video, so you can
>> download them separately and follow along:
>
> I heard the LP team may work on incorporating the slides somehow,
> let’s see…

Even as separate items, the video + slides would be a great addition to
the Guix web site.

- George

Re: [Orchestration][RFC] A simple draft for channels

[myglc2]

On 03/19/2018 at 19:31 Pjotr Prins writes:

> On Mon, Mar 19, 2018 at 02:21:35PM -0400, myg...@gmail.com wrote:
>> > Moving from one to the other, however, is too complicated and error
>> > prone. I can do it, but no one else really wants to. Even with my
>> > explanations it proves to be a royal pain.
>> 
>> How about making guix a submodule of the GeneNetwork repo?
>
> I don't like git submodules, unfortunately. I have plenty experience
> there, and often not good. It works as long as you don't update the
> modules ;)
>
> I am OK with two git trees, there is no tight coupling between
> GeneNetwork and Guix. But there is tight coupling between
> GUIX_PACKAGE_PATH (guix-bioinformatics tree) and guix. I could
> consider making guix-bioinformatics a module of guix. But I am sure I
> am in for pain there too.

Other people bash them, but I have used git modules a lot for
hierarchical bio analysis and never hit a real issue.  Maybe you could
say more about the specific problem you see in this application?

>> > Now I need a way to no longer rebuild all .go files for Guix tree
>> > updates/changes. Not only between switching branches, but also when
>> > just running 'git pull' from Guix savannah. I find I have to do that
>> > very often. So often that I don't even try running make anymore
>> > without make clean. Anyone here share that experience?
>> 
>> Yes the guix make does seem rather fragile ;-) So I usually do ...
>> 
>> guix environment guix  -M 4 -c 4 --ad-hoc help2man git strace
>> rm -fr /home/g1/.cache/guile/ccache/*
>> sudo git clean -dfx
>> git pull
>> ./bootstrap
>> ./configure --localstatedir=/var --sysconfdir=/etc
>> make -j 10
>> make -j 10 check
>
> Mine is comparable, but even more rigorous:
>
>   screen -S guix-build # I tend to build in screen
>   env -i /bin/bash --login --noprofile --norc
>   ./pre-inst-env guix environment guix --ad-hoc help2man git strace \
> pkg-config less vim binutils coreutils grep guile guile-git guile-json \
> gcc nss-certs --no-grafts
>   bash # you may want this shell
>   rm -rf autom4te.cache/ # to be sure
>   make clean
>   ./bootstrap
>   ./configure --localstatedir=/var
>   make clean# to be really sure
>   make clean-go # to be even surer
>   make -j 
>
> (forget the make check)

OK, but I prefer 'sudo git clean -dfx' because it innoculates me against
any errors in 'make clean' logic. I should use ./pre-inst-env more ;-)

> but, yes, the point is that I have to do this too often and it takes a
> long time. So much that I thrust my hand through the monitor every
> time I have to start again. It is costing me monitors.

I agree it is annoying, but maybe this is the cost of complete artistic
source code freedom? And MIPS are so cheap these days, no?

> And there are problems, usually with package updates that go out of
> sync between my trees.

guix as a submodule would avoid this, no?

>> This takes a while but it avoids me chasing spurious errors caused by
>> clashes between the state of my build directory and the upstream
>> changes ;-)
>
> I think we agree.
>
>> > One thing I could do is split out 3 git repos for every use case and
>> > update these individually not triggering rebuilds. And when I deploy
>> > on other machines move the complete repo across with .go files.
>> 
>> Have you considered a git-worktree for each of the development, testing
>> and production branches?
>
> Hmmm. That may be helpful. I should try that. 
>
> Still does not solve my deployment problems.

If it were me, I would do source deployment w/ 'git clone
--recurse-submodules', source update w/ 'git pull; git submodule update'
and try to use bespoke project code to check out development and testing
branches with git-subtree.

You can capture the .go files by checking them into disposable "deploy"
branches which you cam either pull to the target machine or a push to a
non-naked repo.

Am I missing something? - George

Re: [Orchestration][RFC] A simple draft for channels

[myglc2]

Hi Pjotr,

On 03/19/2018 at 13:04 Pjotr Prins writes:

> Let's start up again on this conversation in the context of
> deployment. I have a simple use case. For GeneNetwork we maintain
> GUIX_PACKAGE_PATH packages. It contains packages that ought to go in
> main line (such as python-gunicorn), but also packages that will never
> make it (such as a javascript twitter feed).
>
> Now we deploy multiple setups, which I'll simplify to development,
> testing and production here (there are more!). Each of these has a
> combination of a Guix git checkout and a GUIX_PACKAGE_PATH checkout.
>
> These git repo's are supposedly in sync with each other.
>
> Moving from one to the other, however, is too complicated and error
> prone. I can do it, but no one else really wants to. Even with my
> explanations it proves to be a royal pain.

How about making guix a submodule of the GeneNetwork repo?

> Now I need a way to no longer rebuild all .go files for Guix tree
> updates/changes. Not only between switching branches, but also when
> just running 'git pull' from Guix savannah. I find I have to do that
> very often. So often that I don't even try running make anymore
> without make clean. Anyone here share that experience?

Yes the guix make does seem rather fragile ;-) So I usually do ...

guix environment guix  -M 4 -c 4 --ad-hoc help2man git strace
rm -fr /home/g1/.cache/guile/ccache/*
sudo git clean -dfx
git pull
./bootstrap
./configure --localstatedir=/var --sysconfdir=/etc
make -j 10
make -j 10 check

This takes a while but it avoids me chasing spurious errors caused by
clashes between the state of my build directory and the upstream
changes ;-)

> One thing I could do is split out 3 git repos for every use case and
> update these individually not triggering rebuilds. And when I deploy
> on other machines move the complete repo across with .go files.

Have you considered a git-worktree for each of the development, testing
and production branches?

HTH - George

Re: website: say what Guix is at the very top

[myglc2]

On 01/31/2018 at 18:27 Pjotr Prins writes:

> On Wed, Jan 31, 2018 at 11:58:09AM -0500, myg...@gmail.com wrote:
>> To be explicit, I added a couple target groups and indicated the product
>> we would pitch with an x ...
>> 
>> | Target Group| Guix | GuixSD | Motivation   
>> |
>> |-+--++--|
>> | hacker  | x| x  | scheme, functional, free 
>> 
>> | sysadmin & devop| x| ?  | make 
>> user/developer/researcher happy 
>
> I doubt they will use GuixSD unless they have a very specific purpose
> in mind, e.g., say for mailserver deployment. Cloud/VMs. It could
> work, but I don't think it is a large group we can pitch to.

What about a forward-thinking sysadmin commissioning new systems for a
startup? If they know they want Guix is there a reason they wouldn't
install GuixSD?

>
>> | user/developer/researcher   | x|| productivity tool
>
> This is my favorite because they are potential packagers.
>
>> | generic organizational user | ?|| ?
>> |
>
> Yes, another target group, i.e., the pointy haired boss. Some of these
> understand the concept of reducing cost.

Here I am thinking of "unsophisticated" users, e.g., someone told to run
SAS on a server that is probably not going to actually ever call guix.

>
>> | desktop distro user |  | ?  | ?
>> |
>
> Libre desktop user. Yes.
>
>> |-+--++--|
>
> We also have embedded systems and phones as a potential audience. I
> think OpenWRT/LEDE, for example, could buy into Guix. And then there
> is Android. If we are able to strip down packages to a minimum that
> becomes very interesting to them.

OK, so like this ?

>> | Target Group| Guix | GuixSD | 
>> | embedded sys/phone  |  | x  |

>
> Then we have HPC as a specialization with optimized targets and
> relocatable packages.

OK, so like this?

>> | Target Group| Guix | GuixSD | 
>> | HPC sysadmin| x| x  | optimized targets and 
>> relocatable packages
>
> And light containers for webservice/cloud deployments...

Is this more detail on HPC or something else entirely?

TIA - George

Re: Package inclusion criteria

[myglc2]

On 01/31/2018 at 14:10 n...@n0.is writes:

> On Wed, 31 Jan 2018, l...@gnu.org (Ludovic Courtès) wrote:
>> Hello,
>>
>> Leo Famulari  skribis:
>>
>>> On Mon, Jan 29, 2018 at 06:09:16PM -0500, Mark H Weaver wrote:
 Hi ng0,
 
 > commit 57f9671d22bb4ee37962c31b9eed0ae50859398a
 > Author: ng0 
 > Date:   Wed Jan 17 22:42:55 2018 +
 >
 > gnu: Add badass.
 [...]
 > +  (package
 > +(name "badass")
 > +(version (git-version "0.0" revision commit))
 [...]
 > +(synopsis "Hacking contribution graphs in git")
 > +(description
 > + "Badass generates false commits for a range of dates, essentially
 > +hacking the gamification of contribution graphs on platforms such as
 > +Github or Gitlab.")
 
 Why do you think this belongs in Guix?  Do you intend to use it
 yourself, or do you have reason to believe that Guix users would want
 this?
 
 There's a lot of garbage out there.  Guix doesn't need to include every
 script that someone uploaded to github.  Frankly, I'm embarrassed to
 have a package like this in Guix.
>>>
>>> As the committer, I thought of this as an amusing toy, and we do have a
>>> couple of those.
>>>
>>> But if people would rather we not distribute it, I won't object.
>>
>> I can understand Mark’s concerns, though I don’t have a strong opinion
>> on this particular package (I find it both “weird” and “amusing”; it
>> reflects on how people use those Git services.)
>>
>> The only formal acceptance criterion for packages in Guix is that it
>> must be free software and FSDG-compatible.  However, there might be
>> software we’d rather not include in Guix proper for various reasons.
>>
>> One example we discussed recently is a package that allowed users to
>> exploit specific security vulnerabilities, IIRC, and at the time we
>> chose not to include it.

ISTM if we "publish" the rationale for excluding a package this would
capture it for posterity and potentially be useful to our users.

>> I suspect there are other situations where we
>> might be inclined to reject the package, but it’s hard to anticipate
>> them; I suspect it’s going to be rare, though.
>>
>> Thoughts?
>
> I think we should do the following:
>
> * list examples of what has been previously rejected or dropped,
>   there we can list LISPF4 (accepted, never worked, code to be
>   considered not really copyright worthy, dropped), the recent
>   black/greyhat / PoC package I've sent, software not aligned
>   with the guidelines of Guix (for example linux),...
>   Probably best in full sentences "Software packages which are
>   intend to be used by professionals bla bla bla ..."
> * include a way for exceptions..
>   the list we provide should give a clue about
>   what's possible and what not, but we should decide per
>   case, so that exceptions can be discussed.

Would it be feasible to capture such info in a "unpackage stub" that
make packaage appear in our package lists along with the rational for
why is is not in guix?

Re: website: say what Guix is at the very top

[myglc2]

On 01/29/2018 at 08:37 Pjotr Prins writes:

> On Sun, Jan 28, 2018 at 11:14:15PM -0500, myg...@gmail.com wrote:
>> > I’m not a fan of sales messages and that kind of language
>> > (“introducing”, “the first foo to do bar”, etc); I also don’t like that
>> > these are all worded negatively, which is something we should avoid.
>> 
>> OK but keep in mind that we have very little time to capture a
>> prospective user's attention. You normally do this by saying what is
>> unique about a product and what problem it solves.  This is my attempt
>> at points that might convince a sysadmin and/or user to try
>> Guix/GuixSD. We can make it less salesy. But are the points wrong?  Is
>> something missing? Are there better points to make?
>
> The case is a bit complicated here. Not only do we present two
> products we also have multiple audiences. The current website (in the
> true GNU spirit) addresses hackers. That works because Guix was WIP
> and needed more of those. The hacker spirit has served us and still
> serves us.
>
> But to popularize Guix we have at least two other audiences. The first
> one 'sysadmins' and 'devops' is an important one because we need to
> get Guix on systems they control. This proves to be a hard sell in my
> experience.  Mostly, I think, because sysadmins are not aware of the
> benefits - or simply don't want to be aware. No kidding, I have
> encountered that a few times. 
>
> Then there are end-users and developers who can use Guix for their
> purposes and it would liberate them.
>
> The net benefit for all is gaining control, reproducibility and
> (hopefully) saving time.
>
> I.e., to have a successful sales pitch you'll need to address 2*3=6
> targets.

To be explicit, I added a couple target groups and indicated the product
we would pitch with an x ...

| Target Group| Guix | GuixSD | Motivation  
 |
|-+--++--|
| hacker  | x| x  | scheme, functional, free
 |
| sysadmin & devop| x| ?  | make user/developer/researcher 
happy |
| user/developer/researcher   | x|| productivity tool   
 |
| generic organizational user | ?|| ?   
 |
| desktop distro user |  | ?  | ?   
 |
|-+--++--|

Note: "?" - not sure

WDYT? - George

Re: website: say what Guix is at the very top

[myglc2]

On 01/30/2018 at 02:03 Ricardo Wurmus writes:

> Hi Malcolm,
>
>> Sorry for the MisCaPITaliZAtion
>
> No WoRRieS!  It seems to be very common :)
>
>> Sorry if I lost the flow of the discussion.  I entirely trust your
>> understanding of the focus of the discussion.
>
> No, your comments were spot on and very helpful.  I’m just trying to
> understand if your suggestions would better fit in some sort of unified
> description for both GuixSD and Guix (as George proposed) or if it were
> clearer if we treated GuixSD as a special case (“A system derived from
> the extension of Guix features to the bare-metal/GNU+Linux distribution
> level”).

ISTM Malcom's comments apply equally well to Guix and Guix+GuixSD when a
sysops manager is involved in the deployment decision. If they have an
installed base on another distro, Guix will be deployed first and GuixSD
may never be deployed. OTOH, a forward thinking sysops setting up new
systems in a startup might deploy only GuixSD ;-) This possibility is a
reason to include GuixSD as part of a unified presentation to sysops
targets.

Malcom's comments don't apply to users that are owners of dedicated
desktop/laptop hardware. Other Distros address such "desktop" users by
a) ignoring them, b) treating them like sub project (debian), c)
targeting them with separate server and desktop installs (Ubuntu), or d)
providing only a desktop solution (mint).  ISTM we have the same
options. At the moment we are somewhere between a) and b).  We could
easily move to b) or c). Moving to d) would be a big step: we would
probably need to develop a "desktop variant" of GuixSD, re-brand it, and
market it separately to compete effectively against distros targeting
only desktop users.

WDYT? - George

Re: website: say what Guix is at the very top

[George myglc2 Clemmer]

On 01/29/2018 at 22:24 Cook writes:

> Ricardo,
>
> Sorry for the MisCaPITaliZAtion

Hey Malcolm, in sales and marketing we are thrilled if anybody remembers
our name, nevermind capitalization ;-)

> Sorry if I lost the flow of the discussion.  I entirely trust your
> understanding of the focus of the discussion.

I think this thread was already way off of Ricardo's original question,
due in no small part to my malfeasance. Your comments are, IMO, right on
the money WRT making the case for Guix/GuixSD.

Ricardo, do you have a suggestion of where/how to relocate this
discussion?

>
> Cheers,
>
> ~malcolm_c...@stowers.org
>
>  > -Original Message-
>  > From: Ricardo Wurmus [mailto:rek...@elephly.net]
>  > Sent: Monday, January 29, 2018 4:20 PM
>  > To: Cook, Malcolm 
>  > Cc: Pjotr Prins ; myg...@gmail.com; guix-
>  > de...@gnu.org; sirgazil 
>  > Subject: Re: website: say what Guix is at the very top
>  >
>  >
>  > Hi Malcolm,
>  >
>  > > I entirely agree that with the right educational materials you are
>  > > going to see have the possibility of appealing to other
>  > > groups/cultures/biases.
>  >
>  > Yes, I think that does make sense.
>  >
>  > > Having a section for each of the 2**3 type of user might be the
>  > > perfect compromise.
>  > >
>  > > Perhaps try to appeal to each audience not with "the first foo to bar"
>  > > language, but rather the language of use cases, such as:
>  > >
>  > >  As an administrator of a general purpose HPC cluster, I can focus on
>  > >  networking optimizations ("the last mile", I/O, CUDA, performance,
>  > >  permissions, interesting massively parallel etc) rather than keeping
>  > >  up-to-date with every last scientific application.
>  > >
>  > >  Guix's garbage collection capabilities remove the guess-work from
>  > >  deleting "old" versions of libraries from my installation!
>  > >
>  > >  As an system administrator, solving the dependency hell of end-
>  > user
>  > >  applications should not be my problem!  Guix puts this problem
>  > where
>  > >  it belongs - in the hand of application specialists.
>  > >
>  > >  As an sysadmin administrator, with guix I am removed from the
>  > >  politics of when to update an application!
>  > >
>  > >  Documenting what applications are installed used to be a separate
>  > >  problem from that of installing them.   With GUIX, performing the
>  > >  installation makes them appear in my software catalog.  No more
>  > >  worries about inconsistencies!
>  >
>  > (It’s “Guix”, not “GUIX”.  People at work also always write “GUIX” and I
>  > can’t figure out why…  Maybe we should come up with a backronym to
>  > make
>  > it a valid alternative spelling :))
>  >
>  > >  As a user of advanced scientific applications, I am now in a position
>  > to deploy which applications I need as I see fit, and have the upstream
>  > community support to share the tooling.
>  > >
>  > >  As a bioinformatics developer, the same tools I use to install
>  > application environments can be used to deploy advanced workflows with
>  > the same level of confidence.
>  > >
>  > > Does this strike a sweet spot?
>  >
>  > I like these testimonial style descriptions, and I think it makes sense
>  > to add separate sections for different archetypical users.  (We already
>  > have a related section entitled “GuixSD and GNU Guix in your field”,
>  > which I found intriguing, but it only links to blog posts with certain
>  > tags.)
>  >
>  > However, I think that this is tangential to the question of whether to
>  > move the GuixSD description and intro to a separate page.  If we added
>  > those sections they’d be only about Guix, not about GuixSD, no?
>  >
>  > --
>  > Ricardo
>  >
>  > GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
>  > https://elephly.net
>  >

Re: website: say what Guix is at the very top

[myglc2]

Hi Ricardo, 

On 01/28/2018 at 17:24 Ricardo Wurmus writes:

> Hi George,
>
>> You misunderstand.  I do not propose changing names. I do propose that
>> you present Guix + GuixSD to the outside world in a unified way. I meant
>> "GuixE" as a "handle" to that idea. Sorry if that was misleading.
>
> I understand the idea, and I recognize that this is a possible means to
> address the overlap between Guix and the distribution.
>
> Since you can build virtual machine images of GuixSD even if you don’t
> have GuixSD installed yourself, the difference between Guix and GuixSD
> may seem blurry.
>
> However, *installing* GuixSD and using it as distribution is *very
> different* from using Guix as a tool to build and share reproducible
> environments (be that as a Docker image, as a tarball, as a temporary
> environment, as a virtual machine image, or just by installing packages
> into a profile).
>
> GuixSD is both a natural extension of the ideas and features of Guix,
> but it is also a variant of the GNU system that you can install on
> your workstation, server, or laptop.

Agreed. But let's face it, distros are a dime a dozen. Distrowatch shows
306 distros. GuixSD is number 175. This is hardly surprising given how
difficult it is to gain user mind-share for "yet another distro".  For
anyone already running a distro with a graphical package manager on a
single-user laptop or workstation, GuixSD is a hard sell. For someone
already running another distro on servers, as you alluded to elsewhere,
Guix is more mature and probably a better pitch. So I am saying: Let's
not kill ourselves pitching GuixSD separately.

Where you say "may seem blurry" I say "is blurry". Why?  AFAICT every
guix command except 'guix reconfigure' runs everywhere.  

You say *very different*. I would say it is subtle. I wouldn't pitch the
difference hard to a prospect.  I would say to them: we don't care which
you buy: You can buy a) Guix and keep using your existing distro and
familiar package manager or b) you can buy GuixSD and use 'system
reconfigure' and gain benefits you may like. In either case, the primary
benefits are the same, users are freed from the sysadmin and the
sysadmin is freed from nonstop user package requests.

>> PRODUCT DESCRIPTION:
>>
>> The Guix software environment manager creates user environments that
>> are completely and independently specified by users. Guix users are
>> never stuck needing software that a Sysadmin can't, won't, or hasn't
>> installed. A Guix user can run multiple, differing environments
>> simultaneously and can replicate any environment on any Guix run-time
>> platform.
>
> I wouldn’t write it like this, but explicitly mentioning that users can
> specify any number of reproducible environments is a good idea, in my
> opinion.

My goal was to express the essence of the per-user Guix experience in a
few lines. Happy to hear edits/improvements if you have them.

>> Guix provides system-wide environment management when
>> appropriate to the run-time platform.
>
> This sounds *really* vague, and it shows that is done just to avoid
> speaking of GuixSD as a separate entity :)

But it is a true statement, isn't it?  I didn't say more because adding
GuixSD-specific features here duplicates features already described or
injects features described later in the paragraph. What would you add
here?
 
>> Creation, modification, and
>> upgrade are atomic and roll-back is instantaneous, so Guix users and
>> sysadmins are never stuck with a broken user environment or system.
>
> “instantaneous” is not true for GuixSD where a reboot is required.

I don't follow you. I was thinking of ‘guix system roll-back’ and ‘guix
system switch-generation’ here. Are you referring to the occasional need
to reboot GuxiSD to effect a change. If so expects to occasionally
reboot an OS. Compared to restoring a backup, rebooting and choosing a
different system generation is instantaneous IMO.

>> Guix implements a functional specification of package, user, and system
>> configurations using the Scheme language.  Guix complies with the FSF
>> Four Essential Freedoms and Free System Distribution Guidelines and
>> provides easy and immediate access to the exact source being run.
>
>> By
>> default, Guix uses pre-built package substitutes from the Guix build
>> farm and mirrors but users may build any package, or a complete system,
>> from package developer sources.
>
> I don’t think this feels at home in an introduction.  It doesn’t seem
> like much of a feature; in my opinion this is an implementation
> detail.

I know but this is here because I wanted to introduce the central Guix
concept of "substitutes" and because I wanted to mention what AFAICS is
a unique feature: the ability to easily and completely reinflate a user
or system environment from only developer source.

>> Guix is available on multiple run-time platforms including bare metal
>> (GuixSD), Virtual Machines (QEMU image), and any GNU/Linux distro (Guix
>> Binary).
>

Re: website: say what Guix is at the very top

[myglc2]

On 01/27/2018 at 17:14 Ludovic Courtès writes:

> Hello,
>
> myg...@gmail.com skribis:
>
>> Before you build these two sites, how about considering a more unified
>> approach? IMO this will be easier for users to understand and require
>> less work. Using 'GuixE' to refer to everything in '(guix) Top' you
>> could say:
>
> I think changing names to address a problem that is very real, yet not
> that terrible, would be a bit overkill.  :-)
>
> Ludo’.

You misunderstand.  I do not propose changing names. I do propose that
you present Guix + GuixSD to the outside world in a unified way. I meant
"GuixE" as a "handle" to that idea. Sorry if that was misleading.

Here it is again w/o GuixE.  Please read this pretending you don't know
anything about Guix/GuixSD (can you? ;-) And please consider these
questions: Does this give me a quick idea what Guix is?  What it does?
Why I might want it?  What I should download? And let me know where it
falls short.

PRODUCT DESCRIPTION:

The Guix software environment manager creates user environments that
are completely and independently specified by users. Guix users are
never are stuck needing software that a Sysadmin can't, won't, or hasn't
installed. A Guix user can run multiple, differing environments
simultaneously and can replicate any environment on any Guix run-time
platform.  Guix provides system-wide environment management when
appropriate to the run-time platform.  Creation, modification, and
upgrade are atomic and roll-back is instantaneous, so Guix users and
sysadmins are never stuck with a broken user environment or system.
Guix implements a functional specification of package, user, and system
configurations using the Scheme language.  Guix complies with the FSF
Four Essential Freedoms and Free System Distribution Guidelines and
provides easy and immediate access to the exact source being run.  By
default, Guix uses pre-built package substitutes from the Guix build
farm and mirrors but users may build any package, or a complete system,
from package developer sources.

Guix is available on multiple run-time platforms including bare metal
(GuixSD), Virtual Machines (QEMU image), and any GNU/Linux distro (Guix
Binary).


SALES MESSAGE:

Introducing Guix - the first software environment manager that solves
the problems of both sysadmins and users of GNU/Linux:

- sysadmin problems:

 - Because I have to modify the system to meet user needs and these are
   risky, I have to prototype every change on a test system

 - because system changes takes time, I can't keep up with user software
   requests and users are unhappy

 - Users request conflicting packages, so I can't make everyone happy

- user problems:

 - I need software that sysops won't or hasn't provided

 - sysops changes stuff and my environment breaks

 - I need software that sysops can't provide because it conflicts with
   other user requirements

Re: website: say what Guix is at the very top

[myglc2]

On 01/24/2018 at 15:22 Ludovic Courtès writes:

> Hello!
>
> Ricardo Wurmus  skribis:
>
[...]
>> - The two sites should have separate Download sections.
[...]
> Agreed.

> So I guess we should start working in that direction.

[...]

Hello Ludo’ and Ricardo,

Before you build these two sites, how about considering a more unified
approach? IMO this will be easier for users to understand and require
less work. Using 'GuixE' to refer to everything in '(guix) Top' you
could say:


The GuixE software environment manager creates user environments that
are completely and independently specified by users. GuixE users are
never are stuck needing software that a Sysadmin can't, won't, or hasn't
installed. A GuixE user can run multiple, differing environments
simultaneously and can replicate any environment on any GuixE run-time
platform.  GuixE provides system-wide environment management when
appropriate to the run-time platform.  Creation, modification, and
upgrade are atomic and roll-back is instantaneous, so GuixE users and
sysadmins are never stuck with a broken user environment or system.
GuixE implements a functional specification of package, user, and system
configurations using the Scheme language.  GuixE complies with the FSF
Four Essential Freedoms and Free System Distribution Guidelines and
provides easy and immediate access to the exact source being run.  By
default, GuixE uses pre-built package substitutes from the GuixE build
farm and mirrors but users may build any package, or a complete system,
from package developer sources.

GuixE is available on multiple run-time platforms including bare metal
(GuixSD), Virtual Machines (QEMU image), and any GNU/Linux distro (Guix
Binary).


A "product sales message" that goes with this looks like ...

Introducing GuixE - the first software environment manager that solves
the problems of both sysadmins and users of GNU/Linux:

- sysadmin problems:

 - Because I have to modify the system to meet user needs and these are
   risky, I have to prototype every change on a test system

 - because system changes takes time, I can't keep up with user software
   requests and users are unhappy

 - Users request conflicting packages, so I can't make everyone happy

- user problems:

 - I need software that sysops won't or hasn't provide

 - sysops changes stuff and my environment breaks

 - I need software that sysops can't provide because it conflicts with
   other user requirements

WDYT?

George

[1] https://www.gnu.org/software/guix/manual/guix.html

Re: [RFC] A simple draft for channels

[myglc2]

On 01/24/2018 at 19:20 Ricardo Wurmus writes:

> myg...@gmail.com writes:
>
>> Ricardo, AIUI, your channels don't work like this. But I am at a loss to
>> say how they will work in practice from the user's POV. If you could
>> write such a description it would sure help us understand the proposal
>> better.
>
> This draft is similar to how Conda channels[1] work:
>
> Conda packages are downloaded from remote channels, which are URLs
> to directories containing conda packages. The conda command searches
> a default set of channels, and packages are automatically downloaded
> and updated from http://repo.continuum.io/pkgs/. You can modify what
> remote channels are automatically searched. You might want to do
> this to maintain a private or internal channel.
>
> [1]: https://conda.io/docs/user-guide/concepts.html#conda-packages
>
> In our case a channel consists of a git repository with Guile module
> definitions and a channel description file.  Optionally, it points to a
> URL from where substitutes can be fetched.
>
> Other than that it behaves like a Conda user would expect:
>
>“Guix does not yet include ‘foolicious 2000’, but I know it has been
> packaged by someone else and made available on the
> ‘garlic-onion-sweat’ channel.  So I enable this channel, authorize
> its public key, and then install ‘foolicious 2000’.”
>
> Users can add any number of channels; their modules will be downloaded
> and built (TODO: this might be dangerous, so try sandboxing), and then
> added to GUIX_PACKAGE_PATH.
>
> The second iteration of this would involve some potluck ideas for extra
> safety and convenience.
>
> --
> Ricardo
>
> GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
> https://elephly.net

Thanks Ricardo.

So here is the most brief intro I can come up with:

'guix Channel' allows you to use software packages provided by any
third-party git repo.  To use substitutes that may be provided by the
channel, root must authorize the third-party server. Warning: Channels
may expose you to non-free or harmful software.

WDYT?

I don't think you should call them "channels." Why? Only advanced Nix or
Conda users will know what it means.  For anyone familiar with Chrome,
Red Hat, or TV channels, the "channels" label works against you: they
have to learn and remember that a Guix channel works differently. These
labels might work better: "Guix Sources" (ala Debian sources list[1]),
"third party sources" or "third party repos".

WDYT?

[1] https://wiki.debian.org/SourcesList

Re: website: say what Guix is at the very top

[myglc2]

On 01/21/2018 at 15:47 Ricardo Wurmus writes:

> Ludovic Courtès  writes:
>
>> Ricardo Wurmus  skribis:
>>
>>> It seems unfortunate to me that we have one shared website for GuixSD
>>> and Guix.  As much as I love GuixSD, I think Guix is the main “product”
>>> and GuixSD would need to be moved to a subsite.  That’s primarily
>>> because GuixSD can be explained in terms of Guix, but explaining Guix as
>>> “the package manager we use for GuixSD” seems less helpful.
> […]
>>> My proposal is to keep https://gnu.org/s/guix focussed on Guix the
>>> functional software environment manager, and have the distro under
>>> https://gnu.org/s/guix/distro.
>>>
>>> What do you think?
>>
>> In principle I think it’s a good idea.  In practice I’m not sure what
>> this would look like, though.
>>
>> For instance, does that mean /distro would be a “second home page”, with
>> screenshots, contacts, blog entries, baseline, and all?  Or would it be
>> different?  What would be remove from or add to the actual home page?
>
> I think of /distro as just a leaf page, not a whole website on its own.
>
> - The logo in the menu bar should be the Guix logo.  The GuixSD logo
>   could be shown in the contents of the /distro page.
>
> - The menu should probably have an item for GuixSD
>
> - The screenshots are applicable to GuixSD only, in my opinion, so they
>   don’t make much sense on the Guix home page.  I guess we could have
>   Guix-only text “screenshots” to show the command-line user interface.
>
> - I’d remove the “All packages” button from “Discover GuixSD”
>
> - “GNU Guix in other GNU/Linux distros” is a great section that should
>   link to the Guix package manager’s home page.
>
> - I would remove the blog, contact, and “GuixSD and GNU Guix in your
>   field” sections from the distro sub-page to avoid duplication.
>
> - The two sites should have separate Download sections.
>
> … and as I imagine these changes I become confused about how to link to
> these two download pages.  Having a single “Download” link at the top
> bar would not work when we want to offer separate pages for GuixSD and
> Guix.  We could have /distro/download, which would be linked from the
> /distro page, just like we currently have /download linked from right
> after the introduction.  It would have to be a very prominent button,
> shown “above the page fold” so that we can drop the “Download” item
> from the menu bar.
>
> The download page for GuixSD should offer the GuixSD options first and
> link to the Guix download page ater the options — and vice versa.
>
> (I’m not as sure about these proposed individual changes as I am about
> the proposal to separate the pages for Guix and GuixSD.)

ISTM this difficulty in splitting the content across two pages is a
reason to consider again how to unify the presentation of Guix/GuixSD.

Re: [RFC] A simple draft for channels

[myglc2]

On 01/19/2018 at 14:41 Ludovic Courtès writes:

> Hi!
>
> Ricardo Wurmus  skribis:
>
>> As a first implementation of channels I’d just like to have a channel
>> description file that records at least the following things:
>>
>> * the channel name (all lower case, no spaces)
>> * a URL from where package definitions can be loaded (initially, this
>>   can be restricted to git repositories)
>>
>> Optional fields:
>>
>> * a description of the channel
>>
>> * a URL from where substitutes for the packages can be obtained (this
>>   will be backed by “guix publish”)
>>
>> * a mail address or URL to contact the maintainers of the channel, or to
>>   view the status of the channel
>>
>> * the Guix git commit that was used when this channel was last
>>   updated.  This is useful when Guix upstream breaks the ABI or moves
>>   packages between modules.
>
> Sounds good.
>
>> On the Guix side we’d need to add the “guix channel” command, which
>> allows for adding, removing, updating, and downgrading channels.  Adding
>> a channel means fetching the channel description from a URL and storing
>> state in ~/.config/guix/channels/, and fetching the git repo it
>> specifies (just like what guix pull does: it’s a git frontend).
>
> I think what you described above is “config” rather than “state.”
>
> To me, “state” would be the current channel commit being used and the
> list of previous commits that were used (akin to the Git reflog).  That
> way, one could always roll back a “guix pull” or “guix channel update”
> operation.
>
> The reflog thing is a feature we can already add to ‘guix pull’.  I
> think the migration to channels can be incremental.
>
>> It also authorizes the the substitute server’s public key.
>
> This would require root access.
>
>> Internally, it’s just like GUIX_PACKAGE_PATH in that the repos are used
>> to extend the modules that Guix uses.  Unlike GUIX_PACKAGE_PATH,
>> however, we now have a way to record the complete state of Guix,
>> including any extensions: the version of Guix and all active channels
>> with their versions.  We would also have a way to fetch substitutes from
>> channels without having to “globally” enable new substitute servers and
>> authorize their keys.  (Is this safe?  Can we have per-user extensions
>> to the set of public keys that are accepted?)
>
> Authorizing keys is necessarily limited to root since the store is
> shared among all users of the machine.  I don’t see any way around that
> (other than switching to the other model presented in Eelco’s thesis,
> which is to content-address derivation outputs—but I don’t imagine us
> playing with that idea in the near future :-)).
>
>> Downsides: Guix has no stable ABI, so channels that are not up-to-date
>> will break with newer versions of Guix.  Moving around packages to
>> different modules might break channels.  That’s okay.  It’s still an
>> improvement over plain GUIX_PACKAGE_PATH.
>>
>> I don’t think it has to be more complicated than that.  What do you
>> think?
>
> I agree!
>
> One thing that’s still an open question is how we should treat Guix
> itself in that channelized world.
>
> Should Guix be a “normal” channel?  It’s tempting to think of it as a
> regular channel; however, it’s definitely “special” in that it can
> update the ‘guix’ command, maybe guix-daemon & co., locale data, etc.
> How does that affect ‘guix channel’?

ISTM this design allows channels to inject non-free &/or non-safe
components into other user's Guix systems. Is that true?

If so, how will it impact the Guix promise of software freedom/safety?

WDYT? - George

Re: website: say what Guix is at the very top

[myglc2]

On 01/21/2018 at 23:04 Chris Marusich writes:

> Ricardo Wurmus  writes:
>
>> Hi Guix,
>>
>> on the website it starts right away with a list of features:
>> “Liberating”, “Dependable”, and “Hackable”.  But what is this thing
>> called Guix?
>>
>> We should add a very short paragraph above that list to say what Guix
>> and GuixSD are.
>>
>> What do you think?
>
> How is Guix different from other package managers?  Why is it better?
> I think that's the most important thing to explain.  I've also found
> that it's one of the most difficult things to explain.  I think we
> should entice readers by concisely explaining that, if we can.

Agreed. The first step: STOP calling Guix a "package manager".  Why?
Users aren't shopping for a package manager. They either already have
one, or expect one to come with the software they are looking for.  They
will think, "I don't need one."

So calling Guix a "package manager" sets up a marketing problem like
selling transmissions to car drivers :-(

How can we avoid this?  Call it something else!  What?

Ricardo called Guix a "software environment manager". This is a better
term and we can apply it to both Guix and GuixSD ;-)

> Perhaps the best way to do that would be to write a problem statement.
> Instead of explaining what Guix is, explain what problems Guix solves.
> The first chapter of Eelco Dolstra's Ph. D. thesis [1] did a fantastic
> job of explaining what problems Nix solves, and by the end of that
> chapter, I was really excited to learn more about Nix (and Guix) and try
> it out.  In particular, the list of problems with the state of the art
> in section 1.3 "Motivation" and the list of solutions that Nix offers in
> section 1.5 "Contributions" were particularly concise and convincing.
> Maybe we can aim for something similar on our Guix website?
>
> Footnotes: 
> [1]  https://nixos.org/~eelco/pubs/phd-thesis.pdf

Agreed. If we could reduce this to a short list of problems we could
then say, "Introducing Guix/GuixSD, the first software environment
manager that solves these key problems. "

WDYT? - George

Re: website: say what Guix is at the very top

[myglc2]

On 01/19/2018 at 14:32 Ludovic Courtès writes:

> Ricardo Wurmus  skribis:
>
>> It seems unfortunate to me that we have one shared website for GuixSD
>> and Guix.  As much as I love GuixSD, I think Guix is the main “product”
>> and GuixSD would need to be moved to a subsite.  That’s primarily
>> because GuixSD can be explained in terms of Guix, but explaining Guix as
>> “the package manager we use for GuixSD” seems less helpful.
>>
>> We have many more use-cases for Guix than for GuixSD, Guix is mature and
>> GuixSD is still exploring ways to provide its own spin on traditional
>> features (e.g. “guix deploy”).
>>
>> It’s much easier to tell people to “upgrade” to GuixSD when they already
>> know Guix as a mature, reliable, and understandable piece of software,
>> than to get them to “settle” for just Guix on a foreign distro, when
>> we’re “selling” them GuixSD.
>>
>> My proposal is to keep https://gnu.org/s/guix focussed on Guix the
>> functional software environment manager, and have the distro under
>> https://gnu.org/s/guix/distro.

"functional software environment manager" applies equally well to Guix
and GuixSD. It nicely captures the POV of all our users and potential
users, be they lowly users or sysadmins.

"software environment manager" is equally applicable, has only 3K web
hits, and defers the need to explain what functional means.

So I think we should use "software environment manager" for our product
category / tag line.

>>
>> What do you think?
>
> In principle I think it’s a good idea.  In practice I’m not sure what
> this would look like, though.
>
> For instance, does that mean /distro would be a “second home page”, with
> screenshots, contacts, blog entries, baseline, and all?
>
> Or would it be
> different?  What would be remove from or add to the actual home page?
>
> Thoughts?

NixOS is a good example of what a well-executed second home page might
look like. IMO it fails to help a noob understand Nix/NixOX. I doubt we
could do better.

How about visualizing our situation this way ...

1) We have one product, a software environment manager (temporarily
   referred to below as "GuixU")

2) GuixU possesses the union of all the features and benefits of Guix
   and GuixSD

3) GuixU features become available depending on how you install it


With this in mind, we can visualize our home page as a one-page menu
designed to help you select which item to download.  It could look
something like ...

V

GuixU, the first software environment manager with

< list 6 key things: the GuixU features/benefits that are
currently the most important to our users >

GuixU is used by

< clickable user types >

GuixU alternatives

< Comparison table: GuixU features/benefits vs your alternatives >

The availability of GuixU features depends on how you install it

< checklist: (GuixU features U download status) vs download options >

^

This is a nicely durable and familiar design from a marketing POV. It
can be easily kept current by adjusting tables and lists as relevant
technology, features, substitutes, and download options come and go.

WDYT?

- George

Re: website: say what Guix is at the very top

[George myglc2 Clemmer]

On 01/17/2018 at 18:30 Ricardo Wurmus writes:

> Hi Guix,
>
> on the website it starts right away with a list of features:
> “Liberating”, “Dependable”, and “Hackable”.  But what is this thing
> called Guix?
>
> We should add a very short paragraph above that list to say what Guix
> and GuixSD are.
>
> What do you think?

Hi Ricardo,

Yes we should. We need a title too. But before we can get to those we
need a discussion.  Why?  Because the "Guix-verse" needs to grapple with
the surprisingly difficult challenge that every successful new
technology or software startup faces: Stepping away from technical
complexity and internal detail and describing what the product does and
the distinguishing features that will cause customers to buy it.

The first step is to accept that when a person selects our "product", no
matter how novel we feel it is, 99% of the time they are substituting it
for the product(s) they would otherwise buy.

While users may not pay money for our software, terms like customer,
buy, and substitute help us keep sight of the fact that our users do pay
for Guix by investing in discovering, understanding, installing and
using it instead of something else, free or otherwise. We must figure
out how to get our users to make those investments to be successful.

At the moment, if a potential user asks, "What is the Guix-verse?" We
might reasonably say: Well it has some parts ...

A) The GuixSD GNU/Linux distro, which is better than other distros
   because ... , and

B) The Guix package manager, which is cooler than other package
   managers because ... and by the way, Guix comes with GuixSD, and

C) A custom personal software bubble maker that comes with both A) or
   B), and

D) A puncher of custom QEMU VMs and Docker containers that comes with
   both A) and B) also, and

E) Source you can download to easily build your own custom personal
   packages, distros, bubbles, or punchers with total artistic control,
   or, you can, we hope, help us make guix better."

Listening to this our prospect might reasonably respond ...

1) TMI, I'm out of here! , or

2) Sounds like you have multiple personality disorder, or

3) Come back when you know what you are selling, or

4) I might be interested, maybe I will come back when I have more time,
   or

5) I think I understand. I may need part X.

Next they will ask us, "who is buying it?" To which we might reasonably
reply:

a) guile hackers with libreboot notebooks

c) emacs nuts

b) technodudes looking for the next whacky distro

d) HPC cluster managers that want to give users more freedom

e) Renegade Bioinformatic researchers attempting to get work done in
   spite of archaic CentOS releases

f) We are not actually sure who will buy it

So to summarize, we don't yet know how to describe what we are selling
or who will buy it. Our website reflects our confusion: We don't clearly
say there are multiple products and what they are. Instead of "selling"
the "mature" guix we park it at the bottom of the page. We focus on
GuixSD, never mentioning that it is in beta. We're not sure which
features are most important so we list them all.  The net effect is that
if someone says "Yes!" and clicks download they will next say, "HUH, I
didn't realize I have to choose between 2 things!  And why is the thing
they pitched hardest in beta!"

There are standard ways to help an organization like ours move toward
marketing clarity and sales success. Here are some:

The recommended approach is to pick a single product and focus all
energy on that. Then find people that are about to buy a something for
which they can substitute the product, and talk to them about it.

Our immediate challenge is that we seem to think we have at least two
products. We need to decide if we really have multiple products and, if
we do, how many and what they are. Then we must clearly separate them
and make it easy for potential customers to determine which one they
might use.

Then we need a "good sales message" for each product. The prototypical
sales message for a successful product follows an outline like this:

Introducing  - the first  designed to  that addresses the six key problems faced by :

1
2
3
4
5
6

I suggest that a sales message along these lines is the "very short
paragraph" you want.

- George

Re: Drive identifiers

[myglc2]

On 01/18/2018 at 10:29 Danny Milosavljevic writes:

[...]

> Maybe we could make the user specify the serial number in the operating-system
> bootloader-configuration.  Installing the bootloader to the wrong
> drive would be very bad otherwise.  Also, it's not exactly declarative if the
> labels sda, sdb etc can move around - and reconfiguring / booting ends up like
> a game of musical chairs.
>
> Although if a drive fails and an administrator replaces it by a new drive,
> one would have to change the operating-system configuration and reconfigure
> (which could potentially download gigabytes of data and take hours).
>
> Not ideal.
>
> Maybe store the original serial number into a file on disk and make Guix
> fall back to checking those in a second pass (with a warning).
>
> (Guix could still call the bootloader's installer with the name of the
> device file it found out - so it wouldn't be an involved change)
>
> We would still have to check what happens with the hard drive emulators of
> CD-ROMs - do these have a unique persistent serial number?

Hi Danny,

I commented in a separate post on requiring our users to provide the
drive SN in the config file.  Here I comment on consequences of having
the SN of a HD in a file held by that HD. IMO this is like having the
directory name in a file held by the directory. Both raise the same
issue: the file is no longer relocatable.

In our case, as you point out, this creates a new error
case. Unfortunately we can't possibly know the best way to handle
it. E.G.: If the user has created an image backup of a mission-critical
GuixSD server and if they start it on a second server as a warm-backup
and if they have forgotten to change critical identify files (say
hostname) and if this can cause both servers to become corrupted,
halting on this error might be helpful. But first we should consider how
many "ifs" I used to construct this hypothetical downside. Maybe we are
protecting against very unlikely downsides.  Second: if we halt the user
may well say, "Yep, it's an image BU", override the error, and end up in
the same fix ;-) OTOH, if our user is feverishly trying to start the
image because the primary server failed, halting hurts the user. I
expect that, in practice, the latter case will be much more likely than
the former.

HTH - George

Re: Drive identifiers

[myglc2]

On 01/18/2018 at 10:29 Danny Milosavljevic writes:

>> IIRC the details are: when running on a system disk (say: /dev/sda) and
>> installing to new disk (say: /dev/sdb) you must set the bootloader
>> target to /dev/sdb so the boot loader will be copied to the new system
> ^
> |
> +--- we could change that to enable specifying a model and
>  serial number
>
>> disk.
>
>> But, at least on my servers, when I remove the original system
>> disk, the new disk system becomes /dev/sda, and the bootloader fails.
>
> It does?  What error message does it fail with?  Does the grub shell
> still start?

I am recounting what I experienced almost 2 years ago, see
bug#23072. The bug is sill open.
[...]
> Maybe we could make the user specify the serial number in the operating-system
> bootloader-configuration.  Installing the bootloader to the wrong
> drive would be very bad otherwise.  Also, it's not exactly declarative if the
> labels sda, sdb etc can move around - and reconfiguring / booting ends up like
> a game of musical chairs.

[...]

I would not recommend doing this because forcing the specification of
serial number would further complicate the system config process for all
users but provide insurance that, at best, would protect only the small
subset of users with multiple drives. IOW, it would force everybody to
buy insurance that single drive guixSD users will never need, and savvy
sysadmins won't want.

WRT multi-drive systems, the most pressing issue involves raided system
drives. (e.g, see my config below). This works great but has a HUGE
vulnerability: When the raid member holding the bootloader fails
(e.g. "/dev/nvme0n1" below) the system is unbootable. On my Debian
systems I easily fix this by duplicating the boot loader to all the raid
members. But this doesn't work on GuixSD because the bootloader is
constantly changing. So the most pressing need, IMO, is to provide a way
to maintain the bootloader on multiple targets (e.g., all the mapped
devices in "/dev/md3" below).

  ;; RAID1 root using 1 NVMe SSD + 2 HDs
  (bootloader (grub-configuration (target "/dev/nvme0n1")
  (terminal-outputs '(console))
  (terminal-inputs '(serial console))
  (serial-speed 115200) 
  
  ))
  (initrd (lambda (file-systems . rest) (apply base-initrd file-systems
   #:extra-modules '("raid1")
   rest)))
  (mapped-devices (list (mapped-device
 (source '("/dev/nvme0n1p1" "/dev/sda1" "/dev/sdb1"))
 (target "/dev/md3")
 (type raid-device-mapping
  (file-systems (cons (file-system
(title 'device)
(device "/dev/md3")
(mount-point "/")
(type "ext4")
(dependencies mapped-devices))
  %base-file-systems))
  (swap-devices '("/dev/nvme0n1p2" ))

HTH - George

Re: Installation

[myglc2]

On 01/18/2018 at 16:11 Ricardo Wurmus writes:

> ng0  writes:
>
>> Do we have the ability to separate features, like --enable-experimental 
>> passed
>> to configure build Guix with certain features that might break your
>> OS?
>
> That would be too vague to be useful.
>
>> Otoh
>> we already presume that people setting up GuixSD today know enough about 
>> systems
>> to recover from failures (which is another undocumented problem/usecase with 
>> GuixSD).
>
> I don’t think that we do.  There should not be failures that leave the
> system broken.  If there are then these are bugs and should be reported.

I agree with Ricardo's assesment and in my experience (running
Guix/Debian and GuixSD on physical intel E3 servers for that last two
years) 'guix system reconfigure" has NEVER left my system broken.

The only times guixSD has become broken are when I physically moved the
boot drive around. Maybe this is fixed. For details see ...

http://lists.gnu.org/archive/html/guix-devel/2018-01/msg00245.html

Re: Installation

[George myglc2 Clemmer]

On 01/17/2018 at 15:35 Ludovic Courtès writes:

> Hi Gábor,
>
> Gábor Boskovits  skribis:
>
>> I believe, that we could make a powerful extension to guixsd if we could do
>> an installation from an installation description.
>>
>> I think this installation description should look like the operating-system 
>> description we
>> already have.
>
> In what way would it defer?  :-)
>
> ‘operating-system’ *is* an “installation description.”

War story, FWIW: In the past I have upgraded systems from Guix/Debian
and and from GuixSD to new system disks by simply doing 'guix system
init config.scm'. I found this a lot easier than using an install
disk. The only problem I hit was that removing the original system disk
caused the boot to hang but putting it back into the original slot and
pointing the the BIOS at the new disk booted just fine from the new
disk. The behavior I observed at the time is described in bug#23072:

https://lists.gnu.org/archive/html/bug-guix/2016-03/msg00182.html

IIRC the details are: when running on a system disk (say: /dev/sda) and
installing to new disk (say: /dev/sdb) you must set the bootloader
target to /dev/sdb so the boot loader will be copied to the new system
disk. But, at least on my servers, when I remove the original system
disk, the new disk system becomes /dev/sda, and the bootloader fails.

Presumably this happens when, at boot time, the previously specified
target no longer matches the current deviceID of the actual boot device.
I am actively interested in perfecting my understanging of this topic
because I am about to overhall my server configs, and plan to use the
approach again. So Ludo’, if you see faulty logic above I would love to
hear about it.

TIA - George

Re: Guix - installation script

[myglc2]

On 10/02/2017 at 09:15 Pjotr Prins writes:

> A script that would install the binary install package of Guix would
> be very useful. It should unpack the tarball into /gnu/store and
> /var/guix (checking nothing is there), set the keys and (optionally)
> the build users. Ideally we should have:
>
>wget install.sh
>sudo sh install.sh
>  - fetchin' guix...
>  - unpacking guix...
>  - installing guix...
>  - fetching keys...
>  - set build users...
>  - running guix pull...
>guix package -i hello
>(binary installs...)
>
> They keys of main substitute servers should just work.
>
> I just went through helping someone install Guix remotely and it is
> *too* painful. He is an experienced devop(!) It took hours, mostly
> because he forgot to set the keys correctly (Guix gives no proper
> feedback).
[...]

I don't see how we can recommend Guix with a clear conscience if we
don't automate these tedious steps, at least for a few popular
distributions.

FWIW, the last time I grappled with a binary install (guix-0.9.0 in Mar
2016 on Debian), I found a makefile to be the most handy way to automate
install/uninstall. I'm not posting it because it doesn't work w/ Guix
0.15.0, but happy to provide to anyone interested. - George

Re: meetup in Boston?

[myglc2]

On 12/07/2017 at 10:43 Ricardo Wurmus writes:

> Hi Guix,
>
> I’m going to visit Boston, MA for a conference on the 15th of May 2018.
> Would some of you be interested to meet my colleague and myself on the
> 14th for lunch or dinner?
>
> --
> Ricardo
I'm interested - George Clemmer

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

[myglc2]

On 11/26/2017 at 15:35 Mark H Weaver writes:

> Hi,
>
> Никита Чураев  writes:
>
>> Here's how I want to use Guix and it is to increase
>> contributor-friendliness of a project, so that the user can simply run
>> a distribution-independent command to install all dependencies without
>> having to hunt for them with `apt` and `dnf` manually.
>>
>> Unfortunately, Guix itself is not very easy to install, and the
>> instructions are full of rather technical stuff like 'systemd' and
>> 'upstart'.
>>
>> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html
>>
>> There should be a script like the one Haskell Stack uses:
>>
>> |curl -sSL https://get.haskellstack.org/ | sh|

Agreed, thank you for raising these issues.

As you point out, the current manual binary install imposes a minimum
bound on the technical sophistication and determination of Guix
"triers". The absence of an automated install effectively filters out
"less sophisticated" users. It no doubt strongly limits the rate of
adoption and size of the user base.

Something like you have suggested is a must to reach a larger audience.
Not having it is like an exclusionary fence around Guix.  If we are
committed to usability and availability of Guix for anyone, we should
provide an automated install. Why haven't we done this yet?  Probably
because no Guix developer has to in/uninstalled Guix on multiple
GNU/Linux distributions every day ;-)

> I can understand the appeal of such a convenient approach.  However,
> this practice of downloading a script via HTTPS and immediately running
> it as root without inspection puts you at considerable risk.  A
> man-in-the-middle with the resources to compromise or bribe *any*
> certificate authority in your trust store (the attacker could choose
> which one) could acquire a fraudulent certificate to impersonate our
> site, and then substitute in a different script than the one we
> provided.  Quite a few organizations are capable of such an attack
> today.
>
> Therefore, I believe it would be irresponsible for us to promote this
> style of installation.
>
> However, if there's sufficient interest, and if we could produce a
> sufficiently robust "auto-install" script, we could perhaps do something
> close to what you suggested.  We could provide a script along with a
> GnuPG digital signature.  We could ask the user to download the script,
> acquire our signing key, verify the signature on the script, and then
> run the script as root.

+1

WRT "sufficient interest", script users will be the prospective Guix
users that today hit a wall on the manual install.  This number no doubt
exceeds all Guix users today ;-)

ISTM, these are the downsides to releasing such a script:

1) increased "less sophisticated" Guix noob support load

2) stress-tests of Guix package management usability

3) increased hydra etal loads

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

On 11/11/2017 at 23:02 Ludovic Courtès writes:

> myglc2 <myg...@gmail.com> skribis:
>
>> On 11/10/2017 at 00:04 Ludovic Courtès writes:
>>>
>>> Thrilled by this idea, I pushed an unbound-variable handler that can
>>> provide hints, such as:
>>>
>>>   configuration.scm:88:19: zip: unbound variable
>>>   hint: Try adding `(use-modules (gnu packages compression))'.
>>>
>>> Feedback welcome!
>>
>> I built and played with this.  If I follow some of the hints literally
>> they lead me astray. Here are some suggested hint rewording.
>
> Again, it’s a hint, it could be wrong.
>
> So perhaps that’s a good reason for “Did you mean xyz?”, ending with a
> question mark (like GCC does), rather than a sentence that looks
> assertive.
>
> In the example above, it may be less confusing if we write:
>
>   Did you forget (use-modules …)?
>
> With the question mark, the user understands that this may or may not be
> the cause of the error.
>
> Thoughts?
>
Hi Ludo’,

I have lost your context here. But if you mean that in e.g., ...

>  *** test2: "NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE SPECIFIED"
>
> The error messages ...
>
> /root/ctest/test2:4:0: error: module (gnu packages qemu) not found
> hint: Try adding `(use-package-modules virtualization)'.
>
> ... are followed literally in test2.fix, which does not fix the
> problem because the stale and non-existant 'qemu' package module
> reference also needs to be removed.
>
> Maybe a better hint would be ...
>
> hint: Remove the reference to the pachage module that was not 
> hint: found and add `(use-package-modules virtualization)'.

... something like ... 

hint: Did you remove reference to package module that was not found?
hint: Did you forget `(use-package-modules virtualization)'?

... may be less confusing ...  I agree.  HTH - George

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

On 11/10/2017 at 00:04 Ludovic Courtès writes:
>
> Thrilled by this idea, I pushed an unbound-variable handler that can
> provide hints, such as:
>
>   configuration.scm:88:19: zip: unbound variable
>   hint: Try adding `(use-modules (gnu packages compression))'.
>
> Feedback welcome!

I built and played with this.  If I follow some of the hints literally
they lead me astray. Here are some suggested hint rewording.

Note: You can reproduce the errors/hints below with the attached files.

HTH - George

HINT REWORDING SUGGESTIONS:

 *** test2: "NON EXISTANT PACKAGE MODULE (qemu) for qemu PACKAGE SPECIFIED"

The error messages ...

/root/ctest/test2:4:0: error: module (gnu packages qemu) not found
hint: Try adding `(use-package-modules virtualization)'.

... are followed literally in test2.fix, which does not fix the
problem because the stale and non-existant 'qemu' package module
reference also needs to be removed.

Maybe a better hint would be ...

hint: Remove the reference to the pachage module that was not 
hint: found and add `(use-package-modules virtualization)'.

 *** test3: 'NON EXISTANT (openssh) SERVICE MODULE specified'

This has the same conceptual problem as test2 above. 

The error messages ...

/root/ctest/test3:3:0: error: module (gnu services openssh) not found
hint: Try adding `(use-service-modules ssh)'.

... are followed literally in test3.fix, which does not fix the
problem because the non-existant 'openssh' service module
reference also needs to be removed.

Maybe a better hint would be ...

hint: Remove the reference to the service module that was not 
hint: found and add `(use-service-modules ssh)'.

 *** test4: "SERVICE MODULE (ssh) for openssh-service-type SERVICE MISSING"

A more helpful hint here ...

/root/ctest/test4:46:19: /root/ctest/test4:46:19: openssh-service-type: unbound 
variable
hint: Did you forget a `use-modules' form?

... would be ...

hint: Try adding `(use-service-modules ssh)'.

 ***
 
VERSION INFO:

74bea6a03 gnu: linux-libre: Update to 4.13.12.

make check failed as reported in bug#29245 but I don't think those
errors affect what I am seeing here.

TEST FILES:



test0.scm
Description: Binary data


try.sh
Description: Bourne shell script


try.sh.log
Description: Binary data

Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 11:23 Ludovic Courtès writes:

> Hello,
>
> myglc2 <myg...@gmail.com> skribis:
>
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>
> It should be noted that you were using a “developer setup”, specifically
> running Guix from a checkout with ./pre-inst-env and all.
>
> The issue with the stale module wouldn’t happen with “guix pull”, which
> is the recommended “user setup.”
>
> While I agree the situation is not ideal, I think we have to admit that
> developers can always shoot themselves in the foot, and that was one way
> of doing it.  ;-)
>
> Thoughts?
>
> Ludo’.

I think I misinterpreted this earlier as dismissing the usability
points.  Now I think you are referring to the bug specifically, and from
that point of view I agree. I have closed the bug as notabug.

I posted thoughts/questions re use of "developer setup" by users and
'make clean-go' here ...

http://lists.gnu.org/archive/html/guix-devel/2017-11/msg00080.html

Best - George

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

Hi Ludo’,

I built and played with this. I see you also provide a search hint when
you don't find an obvious match, as in ...

sys.scm:3:0: error: module (gnu services sshx) not found
hint: You may use `guix system search sshx' to search for a service matching 
`sshx'.  If you get the line `location: gnu/services/foo.scm:188:2', add `foo' 
to the `use-service-modules'
form.

This is very nice indeed.

Based on testing, may I suggest the hint rewording shown below ...

On 11/08/2017 at 12:42 myglc2 writes:

> On 11/08/2017 at 16:33 julien lepiller writes:
>
>> Le 2017-11-08 14:09, Ludovic Courtès a écrit :
>>> Hi!
>>>
>>> Here’s an improved version that supports hints (with Texinfo markup and
>>> i18n) and error reporting with source location info.
>>>
>>> Hints try to make suggestions.  If you write:
>>>
>>>   (use-package-modules qemu)
>>>
>>> You’ll get:
>>>
>>>   configuration.scm:7:0: error: module (gnu packages qemu) not found
>>>   hint: Did you mean `(use-package-modules virtualization)'?

hint: Try adding `(use-package-modules virtualization)'

>>>
>>> If you write:
>>>
>>>   (use-service-modules openssh)
>>>
>>> You get:
>>>
>>>   configuration.scm:9:0: error: module (gnu services openssh) not found
>>>   hint: Did you mean `(use-service-modules ssh)'?

hint: Try adding `(use-service-modules ssh)'

Re: [PATCH 0/6] Error reporting and hints for missing modules

[myglc2]

On 11/08/2017 at 16:33 julien lepiller writes:

> Le 2017-11-08 14:09, Ludovic Courtès a écrit :
>> Hi!
>>
>> Here’s an improved version that supports hints (with Texinfo markup and
>> i18n) and error reporting with source location info.
>>
>> Hints try to make suggestions.  If you write:
>>
>>   (use-package-modules qemu)
>>
>> You’ll get:
>>
>>   configuration.scm:7:0: error: module (gnu packages qemu) not found
>>   hint: Did you mean `(use-package-modules virtualization)'?
>>
>> If you write:
>>
>>   (use-service-modules openssh)
>>
>> You get:
>>
>>   configuration.scm:9:0: error: module (gnu services openssh) not found
>>   hint: Did you mean `(use-service-modules ssh)'?
>>
>> The “did you mean” hints are based on exact matches on the package or
>> service names.  We could go as far as doing inexact searches akin to
>> what “guix package -s” and “guix system search” do, but maybe that’s
>> overkill given that the suggestions could be wrong.
>>
>> Anyway, I think that’s already an improvement and we can always refine
>> it later.
>>
>> Thoughts?
>
> This is great! I don't understand it all, but it seems like when there
> is
> no exact match for a package or service, we get the more generic hint
> I wrote.
>
> I'm happy with this version, so LGTM (though untested). Let's see what
> George thinks about it.

Oh YEAH! This is truly awesome!

Re: Reporting module errors

[myglc2]

On 11/07/2017 at 23:47 Ludovic Courtès writes:

> Hello!
>
> You’re too fast!  :-)
>
> julien lepiller  skribis:
>
[...]
>
> I’d propose a variant of it, see below.  With this, one gets a message
> like:
>
>   /tmp/config.scm:6:0: module (gnu packages foobar) could not be found
>
> where line 6 is:
>
>   (use-package-modules foobar)
>
> How does that sound?
>
> It lacks the hints that you were proposing, which isn’t great, but I
> think we’d need to provide a homogeneous and internationalized API in
> (guix ui) if we are to display hints.  But overall I like the idea of
> providing hints somehow.
>
> Perhaps we could simply introduce another condition type for hints as a
> first step, similar to ‘’?
>
> Speaking of hints, we should have something that suggests a module name
> based on the Levenshtein distance with available modules.  :-)
>
> Thanks,
> Ludo’.

FWIW, if you give me the choice between no hints and the hints produced
by julien's patch translated into a random foreign (to me) language, I
strongly prefer the hints.

Why? Because I am will benefit from the embedded data/examples (e.g.,
`guix package --show=foo | grep location`, which, by the way, will never
be translated) even when I do not understand the surrounding words.

Wouldn't speakers of any language feel this way about these specific
hints?

WDYT?

- George

Re: [PATCH] Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 22:27 Julien Lepiller writes:

> Le Tue, 07 Nov 2017 13:06:41 -0500,
> myglc2 <myg...@gmail.com> a écrit :
>
>> On 11/07/2017 at 17:25 julien lepiller writes:
>> 
>> > Le 2017-11-07 16:59, myglc2 a écrit :  
>> >> On 11/07/2017 at 15:52 julien lepiller writes:  
>> >>>
>> >>> Maybe that's too much?  
>> >>
>> >> Not for me. Looks great! Just a couple minor suggestions:
>> >>
>> >> 1) How about narrowing search to locations like this:
>> >>
>> >> Hint: You may use `guix package --show=foo | grep location` to
>> >> search for foo's location.  
>> >
>> > Oh, I didn't know this option, good idea, thanks :D
>> >  
>> >>
>> >> 2) I think you mean to say "foo" where you say "ssh" in the last
>> >> two HINTs  
>> >
>> > You're right, though I prefer to use "bar" to show there is no
>> > relation between
>> > the package name and its module.
>> >
>> > I added "[PATCH]" to the subject to get others look at this
>> > message. I plan to
>> > push it in a few days unless it gets more comments. If an
>> > experienced schemer
>> > could look at that, I'm sure the coding style could be improved a
>> > lot ;)  
>> 
>> Hmm, I think you  introduced a bug in your last changes because I now
>> get ...
>> 
>> root@g1 ~/con/17# guix system build sys.scm
>> guix system: error: failed to load 'sys.scm':
>> /root/con/17/sys.scm:79:19: /root/con/17/sys.scm:79:19: In procedure
>> module-lookup: Unbound variable: x11-forwarding?
>> 
>> ... on the attached sys.scm
>> 
>
> I don't understand the error... When trying to do (service
> openssh-service-type (openssh-configuration))), I get
>
> sys.scm:86:41: sys.scm:86:41: Wrong type to apply: # openssh-configuration>
>
> and I can't reproduce from the REPL... Why don't we get the same error
> with agetty-configuration (removing the openssh service does not make
> any error)?
>
> I was too optimistic I guess :)

Dunno. I double checked. I definitely get 'module-lookup: Unbound
variable: x11-forwarding?'  here with your latest patch.

I am happy to test something if that will help.

Just to be clear, I tested the patch that you sent immediately before
and _it worked great._ Did you diff these two patches?

> I was too optimistic I guess :)

This is not a problem for because, in my experience, there is usually
too little optimism ;)

It seems like I broke the thread. Sorry about that. - George

Re: The usability of Guix configurations

[myglc2]

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade.
[...] replied to separately
>> because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>>
[...] replied to separately
>> 
>> But a less committed user might say, "Wow, Guix breaks at random, error
>> messages are hard to understand, and support is difficult."  :-(
>
> Good point.
>
>> ISTM this raises issues and questions about Guix configuration
>> usability:
>
> Indeed.
>
>> Guix config errors are reported as raw scheme errors which are not
>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>> situation by adding config troubleshooting guidance to the doc?
>>
[...] replied to separately
>>
>> Guix config errors consume meaningful amounts of user and support
>> effort. I say this because a) it took quite a few iterations to figure
>> out what was wrong in my situation, and b) google search for '"no code
>> for module" guix' finds 613 hits, which will no doubt grow linearly with
>> number of Guix users unless something is done. So I wonder, could an
>> error handler that translates into more user-friendly terms reduce user
>> frustration, increase the rate of user self help, reduce support load,
>> and effectively pay for itself?
>
> That would be awesome!
>
>> Are the current Guix config errors usable by the average GNU/Linux
>> distribution user? If not, don't they need to be improved before we call
>> it 1.0?
>
> Based on how much time it's possible to spend on IRC helping people, I'd
> say there is lots of room for improvement in this area.
>
>> Does this mean that package code must not be moved after 1.0?

Note: On a sub-thred, julien lepiller has proposed a patch that, IMO,
improves these errors and should enable users to help themselves more.

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

I agree. I didn't realize until looking at the 0.13.0.4499-17480 doc
today that ...

 (use-modules (gnu packages))
 (operating-system
   ;; ...
   (packages (append (map specification->package
  '("tcpdump" "htop" "gnupg@2.0"))
 %base-packages)))

... is available in system configs. I currently use ...

 (use-modules (gnu packages))
 (specifications->manifest
 '("emacs" "guile@2.2" "guile@2.2:debug"))

... in manifests.

And, to your point, ISTM that if the manual and templates were revised
to present these as the cannonical guix configuration methods in all
examples and templates, guix config usability would be dramatically
improved.

Is this feasible to do?

If we go down this path, ISTM it would be helpful to users for ...

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

... to provide valid text string(s) for each available package.

>> Finally: Should I close bug#29072? ;-)
>
> The problem of the missing QEMU patch is resolved. The broader issue of
> confusing error messages could be continued here, or elsewhere. It's up
> to you :)

OK, Thanks, I will close the bug.

Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 15:52 julien lepiller writes:

> Le 2017-11-07 15:11, myglc2 a écrit :
>> On 11/07/2017 at 14:13 julien lepiller writes:
>>>
>>> This new version outputs something like this :
>>>
>>>
>>> guix system: error: failed to load 'vm-image.tmpl':
>>> vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not
>>> exist.
>>> Check the "use-package-modules" line in your configuration.
>>
>> Thanks Julien, I tried the patch and it works for me. I think it is a
>> great improvement.
>>
>> Small suggestion: is it feasible for the last line to read:
>>
>> Please add a module containing "abc" to the "use-package-modules" line
>> in your configuration.
>
> Wouldn't that be confusing though?
>
> Maybe you're confused because modules have the same name as some
> packages,
> but there is no relation between a package name and its module in
> general.
> In (use-package-modules abc), abc refers to a file named
> 'gnu/packages/abc.go'
> and the error happens when this file doesn't exist.
>
> Maybe that last line could be a hint as to how to find the correct
> module, though,
> such as:
>
> guix system: error: failed to load 'vm-image.tmpl':
> vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not
> exist.
> Check the "use-package-modules" line in your configuration.
> Hint: You may use `guix package -s foo` to search for foo's location.
> Hint: If you get the line "location: gnu/packages/ssh.scm:174:2",
> Hint: you want to add ssh in use-package-modules.
>
> And similarly with services:
>
> guix system: error: failed to load 'vm-image.tmpl':
> vm-image.tmpl:7:0: vm-image.tmpl:7:0: Service module "abc" does not
> exist.
> Check the "use-service-modules" line in your configuration.
> Hint: You may use `guix system search foo` to search for foo's location.
> Hint: If you get the line "location: gnu/services/ssh.scm:188:2",
> Hint: you want to add ssh in use-service-modules.
>
> Maybe that's too much?

Not for me. Looks great! Just a couple minor suggestions:

1) How about narrowing search to locations like this:

Hint: You may use `guix package --show=foo | grep location` to search for foo's 
location.

2) I think you mean to say "foo" where you say "ssh" in the last two HINTs

Re: Let’s meet before FOSDEM!

[myglc2]

On 11/07/2017 at 14:39 Ludovic Courtès writes:

> Hello Guix!
>
> Since we didn’t get a devroom this time in spite of the efforts of
> Manolis and Pjotr, what about holding a Guix meeting let’s say on Friday
> before FOSDEM (Feb. 2nd, in Brussels)?
>
> We could meet for the whole day, in a place that remains to be defined,
> to discuss about all things Guix{,SD}.  The event could be a mixture of
> short talks on specific topics, discussions on technical and less
> technical topics (multiple bootloader support & GuixSD on ARM, making
> ‘guix pull’ great again, Cuirass, reaching out to more
> users/contributors, Guix & HPC, improving our infrastructure and
> organization, etc.), and possibly hacking sessions.
>
> Who would be willing to join?  (You can reply privately if you prefer.)
>
> Based on the show of hands, we’ll arrange for a venue of the appropriate
> size.
>
> Thanks!
>
> Ludo’.

Hi Ludo’,

I am thinking of coming from Boston on the cheap to finally put a face
on all you helpful Guixers, and maybe go to FOSDEM.

My personal interests are HPC, reproducible research, Cuirass, and
"user-level" use of git pull instead of guix pull.

Are you saying there will be no Guix discussion at FOSDEM?

Re: The usability of Guix configurations

[myglc2]

On 11/07/2017 at 14:13 julien lepiller writes:

> Le 2017-11-07 13:52, Hartmut Goebel a écrit :
>> Am 07.11.2017 um 12:05 schrieb julien lepiller:
>>> Since we encourage users to use use-package-modules etc, I think it's
>>> better
>>> to catch this error and explain it to users as soon as it happens.
>>> It's more
>>> friendly for users than a troubleshooting section in the manual.
>>
>> +1
>> Thanks for proposing a patch so quickly!
>>
>>> Package module "abc" does not exist.
>>> ERROR: In procedure scm-error:
>>> ERROR: check "use-package-modules" line in your configuration.
>>
>> For me this looks confusing: The actual error message is not
>> prefixed by
>> "ERROR:". Also (nitpicking) the explanation could by a bit more
>> verbose.
>> Like this:
>>
>> ERROR: In procedure scm-error:
>> ERROR: Package module "abc" does not exist.
>> ERROR: Please check the "use-package-modules" line in your
>> configuration.
>>
>> It would even be better is the fist line would not refer to "procedure
>> scm-error", but to the config actually processed (and even the line in
>> there). But nevertheless this patch is a big improvement already.
>
> This new version outputs something like this :
>
>
> guix system: error: failed to load 'vm-image.tmpl':
> vm-image.tmpl:6:0: vm-image.tmpl:6:0: Package module "abc" does not
> exist.
> Check the "use-package-modules" line in your configuration.

Thanks Julien, I tried the patch and it works for me. I think it is a
great improvement.

Small suggestion: is it feasible for the last line to read:

Please add a module containing "abc" to the "use-package-modules" line in your 
configuration.

TIA - George

Re: The usability of Guix configurations

[myglc2]

Sorry Leo, please disregard this miss-fire

On 11/06/2017 at 21:30 myglc2 writes:

> On 11/06/2017 at 17:16 Leo Famulari writes:
>
>> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>>> My system recently broke when I did an upgrade. I reported what I
>>> thought was a bug (bug#29072) but it turned out that, because qemu
>>> package code had been moved, my system configuration had become broken
>>> ;-(
>>> 
>>> Confronted with my situation, helpful developers said "The package code
>>> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
>>> config (Efraim)."
>>
>> I'm sorry that my comment was not enough on its own!
>>
>>> Once I understood what had happened I wondered, "Gee, I have been using
>>> guix for 18 months so why didn't I figure this out myself." ;-)
>>> 
>>> But a less committed user might say, "Wow, Guix breaks at random, error
>>> messages are hard to understand, and support is difficult."  :-(
>>
>> Good point.
>>
>>> ISTM this raises issues and questions about Guix configuration
>>> usability:
>>
>> Indeed.
>>
>>> Guix config errors are reported as raw scheme errors which are not
>>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>>> situation by adding config troubleshooting guidance to the doc?
>>
>> Yes, we do try to add helpful error messages, although obviously there
>> is a lot more work to be done.
> [...]
>>
>>> Guix config errors consume meaningful amounts of user and support
>>> effort. I say this because a) it took quite a few iterations to figure
>>> out what was wrong in my situation, and b) google search for '"no code
>>> for module" guix' finds 613 hits, which will no doubt grow linearly with
>>> number of Guix users unless something is done. So I wonder, could an
>>> error handler that translates into more user-friendly terms reduce user
>>> frustration, increase the rate of user self help, reduce support load,
>>> and effectively pay for itself?
>>
>> That would be awesome!
>>
>>> Are the current Guix config errors usable by the average GNU/Linux
>>> distribution user? If not, don't they need to be improved before we call
>>> it 1.0?
>>
>> Based on how much time it's possible to spend on IRC helping people, I'd
>> say there is lots of room for improvement in this area.
>>
>>> Does this mean that package code must not be moved after 1.0?
>>
>> A couple thoughts... it would be nice if the GuixSD configuration
>> example templates used a filename agnostic method of resolving module
>> imports. I'm not a strong enough Schemer to evaluate the situation or
>> suggest a solution, but I think that the filenames should not be
>> relevant at that level. Perhaps one could use
>> 'specification->package+output',
>> as demonstrated in the documentation of package manifests:
>>
>> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html
>>
> There is a parallel solution 
>>> Finally: Should I close bug#29072? ;-)
>>
>> The problem of the missing QEMU patch is resolved. The broader issue of
>> confusing error messages could be continued here, or elsewhere. It's up
>> to you :)

Re: The usability of Guix configurations

[myglc2]

Please note: these replies are separated by topics in an effort to make the
threads more topical ...

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
[...]
> As far as I can tell, the issue was related to the fact that you are
> using Guix by building it from source and re-using the same build
> directory, which may contain stale compiled .go files. In this case,
> there was a leftover qemu.go, which shadowed the correct file,
> virtualization.go.
>
> This is a useful development technique but not how Guix is supposed to
> be deployed and updated. `guix pull && guix package --upgrade` is still
> what we recommend and support.

Yes, the initial issue as I reported and labeled it was caused by
building from source and the fact that 'make clean-go' unexpectedly (at
least to me) left stale files laying around. But if 'make clean-go' had
nuked all the .go files as I expected, or if I had been using guix pull,
I would still have experienced the configuration breakage caused by the
qemu package being moved from ./gnu/packages/qemu.scm to
./gnu/packages/virtualization.scm which produced the error messages that
befuddled me and which are the primary focus in this post.

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

That sounds really inconvenient and would not fit my mode of use (for
details on my mode of use and how I see stale files, please this post:

http://lists.gnu.org/archive/html/guix-devel/2017-11/msg00080.html

Can you tell me what the benefit to developers are, if any, of keeping
stale .go files around?

TIA - George

Re: The usability of Guix configurations

[myglc2]

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
>> My system recently broke when I did an upgrade. I reported what I
>> thought was a bug (bug#29072) but it turned out that, because qemu
>> package code had been moved, my system configuration had become broken
>> ;-(
>> 
>> Confronted with my situation, helpful developers said "The package code
>> was moved in commit xxx" (Leo) and "maybe you have a mistake in your
>> config (Efraim)."
>
> I'm sorry that my comment was not enough on its own!
>
>> Once I understood what had happened I wondered, "Gee, I have been using
>> guix for 18 months so why didn't I figure this out myself." ;-)
>> 
>> But a less committed user might say, "Wow, Guix breaks at random, error
>> messages are hard to understand, and support is difficult."  :-(
>
> Good point.
>
>> ISTM this raises issues and questions about Guix configuration
>> usability:
>
> Indeed.
>
>> Guix config errors are reported as raw scheme errors which are not
>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>> situation by adding config troubleshooting guidance to the doc?
>
> Yes, we do try to add helpful error messages, although obviously there
> is a lot more work to be done.
[...]
>
>> Guix config errors consume meaningful amounts of user and support
>> effort. I say this because a) it took quite a few iterations to figure
>> out what was wrong in my situation, and b) google search for '"no code
>> for module" guix' finds 613 hits, which will no doubt grow linearly with
>> number of Guix users unless something is done. So I wonder, could an
>> error handler that translates into more user-friendly terms reduce user
>> frustration, increase the rate of user self help, reduce support load,
>> and effectively pay for itself?
>
> That would be awesome!
>
>> Are the current Guix config errors usable by the average GNU/Linux
>> distribution user? If not, don't they need to be improved before we call
>> it 1.0?
>
> Based on how much time it's possible to spend on IRC helping people, I'd
> say there is lots of room for improvement in this area.
>
>> Does this mean that package code must not be moved after 1.0?
>
> A couple thoughts... it would be nice if the GuixSD configuration
> example templates used a filename agnostic method of resolving module
> imports. I'm not a strong enough Schemer to evaluate the situation or
> suggest a solution, but I think that the filenames should not be
> relevant at that level. Perhaps one could use
> 'specification->package+output',
> as demonstrated in the documentation of package manifests:
>
> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html
>
There is a parallel solution 
>> Finally: Should I close bug#29072? ;-)
>
> The problem of the missing QEMU patch is resolved. The broader issue of
> confusing error messages could be continued here, or elsewhere. It's up
> to you :)

Re: The usability of Guix configurations

[myglc2]

Please note: these replies are separated by topics in an effort to make the
threads more topical ...

On 11/06/2017 at 17:16 Leo Famulari writes:

> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:
[...]
>> Guix config errors are reported as raw scheme errors which are not
>> user-friendly, except, perhaps, to guile users ;-) Could we improve this
>> situation by adding config troubleshooting guidance to the doc?
>
> Yes, we do try to add helpful error messages, although obviously there
> is a lot more work to be done.

I didn't mean this point critically. Rather as a statement of fact. When
I said ...

>> Could we improve this situation by adding config troubleshooting
>> guidance to the doc?

... I was thinking something like ...

vv

Troubleshooting your config file:

If you get an error like:

ice-9/boot-9.scm:[...] no code for module (gnu packages )

You have either specified a package name that does not exist, or your
(use-package-modules ) does not contain the name
of a package module that contains the definition of .

You can determine which, if any, module contains a package definition by
yada yada yada

^^

... thinking that then there would be a search hit in the doc for 'no
code for module' which might enable some users to understand what they
are doing wrong.

WDYT? - George

Re: [PATCH] Clean all .go in clean-go

[myglc2]

On 09/16/2016 at 01:15 Eric Bavier writes:

> On Fri, 02 Sep 2016 14:42:27 +0200
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> Eric Bavier  skribis:
>> 
>> > On Thu, 01 Sep 2016 14:37:58 +0200
>> > l...@gnu.org (Ludovic Courtès) wrote:  
>> 
>> [...]
>> 
>> >> > In regards of the .go files remaining in the build directory, I agree
>> >> > that this is not good, however I don't think it is worth trying to fix
>> >> > this issue which equally applies to every file generated by Make.  Using
>> >> > wildcards can be tempting in such cases but it can lead to accidental
>> >> > file deletions which is worse IMO.  As a consequence I would prefer
>> >> > keeping the current 'clean-go' rule.
>> >> 
>> >> I sympathize with that.  
>> >
>> > How about simply printing  a warning if there are any .go files laying
>> > around after a `make clean` or `make clean-go`?  
>> 
>> Sure, why not.
>
> So, with the attached patch, I get the following output after `make
> clean-go`:
>
> warning: stray .go files: ./guix/scripts/import/cpan.go ./gnu/services/dmd.go
> ./gnu/system/linux.go ./gnu/packages/yasm.go ./gnu/packages/cursynth.go 
> ./gnu/packages/lightning.go ./gnu/packages/doxygen.go ./gnu/packages/tre.go 
> ./gnu/packages/asciidoc.go ./gnu/packages/texlive.go ./gnu/packages/i3.go 
> ./gnu/packages/fish.go ./gnu/packages/slim.go ./gnu/packages/tcsh.go 
> ./gnu/packages/zsh.go ./gnu/packages/lsh.go ./gnu/packages/rc.go 
> ./gnu/packages/openssl.go ./gnu/packages/aria2.go ./gnu/packages/gdbm.go 
> ./gnu/packages/gnutls.go ./gnu/packages/grue-hunter.go 
> ./gnu/packages/aarddict.go
>
> Maybe this means that I've not been doing due diligence in keeping my
> builddir clean, or maybe its just the result of developing on guix for
> so long.

Hi, I would like to request that you revisit the disposition of stray
.go files:

Grated, my request is subjective: I am primarily a guix user. But I want
_total artistic control_ so I do my guix upgrades using 'git pull; make'
in order to have editable guix source handy, should I be inspired to
make a change. In practice I do 'git pull; make' every few weeks. I
seldom actually submit patches, but sometimes I mess with packages for
my own ends.

 As I understand it, my mode of use is not "supported". This
mystifies me because I actually think it is in stronger solidarity with
the FWF source mantra than guix pull, which gives read-only source in
the store which is not, by default, easily editable and so is just plain
annoying to moi! If Guix wants to encourage users to look at source,
find problems, and submit patches, I think you should encourage them to
use git checkout the same way the "real developers" do 

Anyway, in my case I can't imagine why I would ever want "stray .go
files" kicking around my guix working tree. Can you?

Previously I was bitten when the guix API changed and was advised to do
'make clean-go' to "fix" the apparent bugs that this generated for
me. Having a reasonably powerful machine, I have adopted the practice of
routinely doing 'git pull; make clean-go; ./bootstrap ;./configure
--localstatedir=/var' to avoid such problems in the future.

Recently I was bitten by a stray .go file (bug#29072). In that situation
I would have been better off if 'make clean-go' nuked all the .go
files. Admittedly, I failed to notice the subtle stray .go warning, but,
in my defense, I was assuming that 'make clean-go' would just nuke all
the .go files so I wasn't expecting or looking for such a warning.

Maybe I am missing something here. Are there situations where it is
truly desirable for the guix 'make clean-go' to preserve .go files for
which no source exists? If not, maybe 'clean-go' should delete the stray
files by default, and issue a warning saying which stray files were
deleted.

Alternatively... how about adding a new make target that also removes
the stray .go files?

- George

Re: The usability of Guix configurations

[myglc2]

Please note: these replies separated by topics in an effort to make the
threads more topical ...

On 11/06/2017 at 22:16 Leo Famulari writes:

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

Hey Leo,

Please understand that don't mean this as a complaint your reply, which
was helpful and I was very happy to receive.

I am just trying to step back and think about the bigger picture.

The usability of Guix configurations

[myglc2]

My system recently broke when I did an upgrade. I reported what I
thought was a bug (bug#29072) but it turned out that, because qemu
package code had been moved, my system configuration had become broken
;-(

Confronted with my situation, helpful developers said "The package code
was moved in commit xxx" (Leo) and "maybe you have a mistake in your
config (Efraim)."

Once I understood what had happened I wondered, "Gee, I have been using
guix for 18 months so why didn't I figure this out myself." ;-)

But a less committed user might say, "Wow, Guix breaks at random, error
messages are hard to understand, and support is difficult."  :-(

ISTM this raises issues and questions about Guix configuration
usability:

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

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

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

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

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

Re: Browsing Guix (or any) lists with Gmane

[myglc2]

On 10/01/2017 at 12:45 Maxim Cournoyer writes:

> Hello Guix!
>
> For Guix and Gnus (or to become) users out there, I thought I'd share
> this brief post where I explained the process of setting up Gnus and Gmane.
>
> Here are some benefits:
> 1. No need to locally store emails; just view them over NNTP.
> 2. Easily subscribe to some lists in Gnus without having to go through
> the mailman registration.
> 3. Much nicer/convenient UI than the web archives pages; you can post
> follow-ups directly.
> 4. Rich collection of some 3+ mailing list archives.
>
> The main drawback I've found so far is that server-side search facility
> doesn't seem to be available yet in the new Gmane. Still, it's not too
> long to load the full list of messages ever post to a list and use Emacs
> or Gnus native features to search/sort.

For several years I used and really liked gmane + gnus. I was shocked
when gmane went offline at my vulnerability to something I had taken for
granted. When gmane came back I found that the loss of search, which I
relied on, was a killer. So I cooked up a workaround (see below). Gmane
has been back, but, IMO, stagnant, for a year.  I say stagnant because a
year has gone by with no new news posts and the gmane search is still
not working. NNTP without search is, IMO, TOTALLY lame. This makes me
wonder about the depth of support at gmane and whether it makes sense to
rely on it going forward.

My workaround is to download the mail list archives to a local maildir
cache indexed/searched by gnus/notmuch/nnir and read with gnus +
nnmaildir. I use a makefile and mb2md running in the background to do
downloads and trigger indexing. While not elegant, this bit of hackage
frees me from depending on gmane or any other 3rd party and has turned
out to be very reliable. There is really only one hitch - it suffers a
hit each time you (re)open gnus. Apparently gnus has a scaling problem
with large nnmaildir directories. E.g., my 1.9G cache takes ~45 sec to
open on a 3.4 Ghz E3 w/2500 MB/sec Samsung 950PRO SSD. This is not
really a problem in my situation because I run on the server and leave
gnus open all the time. The 1.9 G includes all the guix lists,
emacs-orgmode and geiser-users. But if I followed more or bigger lists
expect the gnus (re)open might become prohibitive.

I could avoid the gnus open hit by reading the cache with the notmuch
gui or indexing/reading the maildir cache with mu/mu4e (which I do for
my email accounts) since then I wouldn't be using gnus at all. I guess I
continue to read these lists with gnus because I got into the habit :-)

Of course the best thing would be for gmane to restore search and to be
managed by an organization that has dept and staying power. If that
happened I would gladly discard my workaround because gmane was truly a
thing of beauty when search worked.

[...]

Re: Guix infrastructure

[myglc2]

On 07/07/2017 at 14:19 Ludovic Courtès writes:

> Hello Guix!
>
> Leo Famulari <l...@famulari.name> skribis:
>
>> On Thu, Jul 06, 2017 at 08:09:17PM -0400, myglc2 wrote:
>>> On 07/01/2017 at 14:01 Leo Famulari writes:
>>> > ... Bayfront is still not fully operational, so hydra.gnu.org is still
>>> > serving as the front-end of the build farm. We are still relying on the
>>> > Hydra software. That is, the situation is basically the same as before.
>>> > Adding build machines will not help very much until the front-end
>>> > hardware gets faster.
>>> 
>>> This leaves me wondering ...
>>> 
>>> Is the hydra/front-end hardware going to be upgraded?
>>
>> Yes...
>>
>>> Is bayfront/cuirass intended to replace hydra?
>>
>> ... and yes.
>>
>>> The bayfront hardware described here ...
>>> 
>>> https://www.gnu.org/software/guix/news/growing-our-build-farm.html
>>> 
>>> ... seems weak to me. Is there a plan to scale it up and make it redundant?
>>
>> It will be a lot more powerful than the current Hydra system. As for
>> specific plans, I'll let those administering the system chime in.
>
> That machine is super powerful…

Well, I disagree. A 2010 motherboard with 2 x 2011 CPUs (16 core at
1.6GHz) is weak compared to modern servers. 

> but alas, it has also been terribly
> unstable.  Vikings has been kind enough to assist us; they’ve notably
> provided us with CPU replacements once already.  Despite these efforts,
> the machine is still crashing.  We’re investigating with them what to
> do next.
>
> On top of that, all the testing and all the back and forth takes an
> awful lot of time, which is in part due to hardware problems being hard
> to pinpoint and debug in general, and in part due to us here in Bordeaux
> (where the machine is hosted) being unable to scale up.

As you have experienced here, the learning/deployment costs and hassle
associated with each new type of server often dwarfs other costs. The
best way to minimize this is to minimize the number of types of servers
you own. In practice this means you need to place your bets carefully
and quickly cut you loses if things don't work out.  It also means that
when (not if) a server breaks you should buy one exactly like the broken
one.

At this point it makes sense to abandon the Vikings motherboard and
choose a popular, mainstream, current x86_64 motherboard. Since AMD has
not been a competitive server vendor for the last ~8 years this means,
practically speaking, picking a popular intel-based motherboard.

> Infrastructure has been the project’s Achilles’ heel since we run the
> crowdfunding campaign in Dec. 2015 (!).  Now it’s becoming detrimental
> to the project.  Our initial plan was to buy more Libreboot-based
> machines like the one above once the first one has proved to work
> well.  However, given the situation, we’ve been discussing on
> guix-sysadmin a change in strategy, at least in the short term;
> Ricardo has been working on re-purposing used hardware for our needs,
> and that may well be our short- to medium-term solution.

Hmm, didn't know about guix-sysadmin until now but couldn't easily read
it. So, FWIW, here are some additional comments/suggestions ...

It should be pretty easy to estimate the requirements to run the front
end and do a nightly x86_64 build of guixSD, projected out 3 years. Do
we have a handle on what this is?

You should buy hardware that supports this and plan to discard it in 3
years.

Since things always break, visualize a system in which every server has
a redundant warm backup or is a pair of servers at 50% load.

You can choose between amazingly cheap used servers that guzzle power or
new servers that use less power. If you buy used computers ~ 3 years old
the total cost of ownership will be nearly a wash over ~ 3 years of
deployment. So, if you are cash rich, buy new computers. If you are
cash-poor, buy used computers, but don't buy anything more than 3 years
old, unless you want a computer museum ;-)

The benefit of a used server is that it comes assembled and tested and
probably has good driver support. Shiny new motherboards expose you to
the risk of unstable drivers and BIOS.  So, if you want new, you should
probably buy last year's model ;-)

In either case, it is tempting to assemble the computer. But this is not
a good idea because there is always some glitch.

The best strategy would be to buy assembled, tested servers with GuixSD
installed and running. If you can't find a vendor that will do that for
you, buy a test unit on the condition that the machine will be returned
if GuixSD doesn't install smoothly.

Specify RAIDed SSDs or, ideally, NVMe drives.

Acquire a test unit quickly. If it works great, buy an

Re: stability of master - just QA and hydra is not enough

[myglc2]

On 07/01/2017 at 14:01 Leo Famulari writes:

> On Sat, Jul 01, 2017 at 05:36:04PM +, ng0 wrote:
[...]
>> 0: What is it these days? Is hydra now just a in-retirement frontend
>> for cuirass or how does bayfront work these days? I understand cuirass,
>> not hydra.
>
> ... Bayfront is still not fully operational, so hydra.gnu.org is still
> serving as the front-end of the build farm. We are still relying on the
> Hydra software. That is, the situation is basically the same as before.
> Adding build machines will not help very much until the front-end
> hardware gets faster.

This leaves me wondering ...

Is the hydra/front-end hardware going to be upgraded?

Is bayfront/cuirass intended to replace hydra?

The bayfront hardware described here ...

https://www.gnu.org/software/guix/news/growing-our-build-farm.html

... seems weak to me. Is there a plan to scale it up and make it redundant?

A reliable, resourced, managed, "nightly Guix build" should pay big
dividends for the project. But, from reading the lists, I get the
impression that such a thing does not exist. Is that correct?

Do we know what would be needed to achieve a complete nightly build?

TIA - George

Re: new manifest format readers?

[myglc2]

On 06/09/2017 at 14:03 Ricardo Wurmus writes:

> Hi Guix,
>
> I received some feedback on the usability of Guix and one of the points
> I got was about manifests.
>
[...]
> What do you think?

I use manifests all the time.  In my experience, a more basic issue than
the syntax is that, when you make an error, you get smacked with an
uninformative trace back. It doesn't help that, depending on the
manifest form used, you must use specify a package in terms of a string
or a symbol.

So I wonder: When users complain about manifests, is it really about the
syntax or is it about the error handling?

ISTM that, before we create a new manifest syntax, we should add some
"package validation" that traps errors and produces more informative
messages.  I know nothing about guile error handling but that doesn't
stop me from imagining ...


... an enhanced 'package->manifest' function that does something like ...

  (use-package-modules guile emacs)
  (packages->manifest
   (list emacs
 guile-2.0
 foo
 ;; Use a specific package output.
 (list guile-2.0 "debug")))

Error: packages->manifest: 'foo' is unspecified.

Message: guix module foobar contains recipes for foo versions 3.0 &
 3.2. You can install package foo version 3.2 by adding
 '(use-package-modules foobar)' before '(packages->manifest
 ...'.


... an enhanced 'specification->package+output' function that does something 
like ...

(packages->manifest
   (map (compose list specification->package+output)
'("emacs" "guile@2.0" "guile@2.0:debug" foo@3.4)))

Error: specification->package+output: You used 'foo@3.4' where a quoted
   string was expected.

Message: Guix contains recipes for foo versions 3.0 & 3.2. You can
 install foo version 3.2 by replacing 'foo' with '"foo"' or
 '"foo@3.2"'


... and an enhanced 'packages' function that does something like ...

   ;; Globally-installed packages.
   (packages (package-check tcpdump foo %base-packages))

Error: packages: 'foo' is unspecified.

Message: guix module foobar contains recipes for foo versions 3.0 &
 3.2. You can install package foo version 3.2 by adding
 '(use-package-modules foobar)' before '(packages ...'.

WDYT? - George

Re: 02/02: gnu: emacs-debbugs: Install missing file.

[myglc2]

On 05/30/2017 at 11:30 Alex Kost writes:

> alezost pushed a commit to branch master
> in repository guix.
>
> commit 91762db6fe208365e64c32c8eb5d2cfeec36ebed
> Author: Alex Kost 
> Date:   Sat May 27 11:31:03 2017 +0300
>
> gnu: emacs-debbugs: Install missing file.
> 
[...]
Way cool! Thanks - George ;-) 

Re: What’s next?

[myglc2]

On 05/24/2017 at 21:56 Ricardo Wurmus writes:

> Catonano  writes:
>
>> 2017-05-24 18:25 GMT+02:00 Jan Nieuwenhuizen :
> […]
>>> A friend of mine is having a second look at Guix (not SD yet) and one of
>>> the most confusing things initially is `guix pull'.  "When/how do I use
>>> that," he asks...and I can only say: I'm not using that...I think we
>>> want this to work--or something like this, we talked about this at
>>> FOSDEM, but AFAIK everyone is using Guix with Git.
>>>
>>> He responds with: then *why* is it in the manual.  I have no answer.
>>> Possibly I'm wrong and/or my information is outdated?
>>>
>>
>> This is an important point for me too
>>
>> I realized that everyone is using git and not guix pull just yesterday
> […]
>> I think this is a problem. It' s unfair to newcomers and it damages Guix as
>> a project because it makes the learning curve steeper with not so much of a
>> point why.
>
> There are two reasons why developers use Guix from git:
>
> * it allows them to add new packages and features to Guix itself.  This
>   is something “guix pull” doesn’t support well.
>
> * it doesn’t require compiling all of Guix on each update.

Hmm, that explains how it feels. Why doesn't it just pull the compiled guix 
files?

Re: What’s next?

[myglc2]

On 05/27/2017 at 12:13 Ludovic Courtès writes:

> Ricardo Wurmus  skribis:
>
>> Chris Marusich  writes:
>>
>>> Leo Famulari  writes:
>>>
 So, I use and recommend `guix pull`!
>>>
>>> I use it too.  Statements by others in this thread that "nobody" uses it
>>> or that "everyone" is using Git are mistaken.
>>>
>>> I use Git when I want to hack on Guix.  Otherwise, I use 'guix pull'.
>>> IMO, the biggest problem with 'guix pull' is that there is no easy
>>> rollback.  I can live with long execution times (--fallback is fine, but
>>> it'd be nice if substitutes were available more often), and I can live
>>> with 'guix pull' causing me to get a version of guix that's broken
>>> somehow, but the inability to easily roll back when things go south
>>> makes me hesitant to run 'guix pull' regularly.
>>
>> I believe this can be fixed by adding more links to “.config/guix”,
>> i.e. before creating “latest” it would create “2017-05-24:08:21:01.123”
>> and then link from there to “latest”.  On update it would create a new
>> link “2017-05-25:17:45:45.123” and link that to latest.  Roll back would
>> be a matter of pointing “2017-05-24:08:21:01.123” to “latest”.
>
> There would be some similarity with profiles.  Should we simply use
> profiles, and effectively turn ~/.config/guix/latest into a profile,
> with generations etc.?

+1

Re: "your installation is old" when running via a git checkout

[myglc2]

On 05/29/2017 at 10:20 Christopher Allan Webber writes:

> Hi!  I've done this hack so I can run the Guix I'm hacking on from git
> as I know some others are as well:
>
>   ln -s ~/devel/guix ~/.config/guix/latest
>
> However, I am getting:
>
>   guix package: warning: Your Guix installation is 233 days old
>
> It looks like it's looking at the age of the "latest" directory, which
> wouldn't be useful information since I've symlinked it intentionally.
>
> I wonder if there's a way to turn this off for people who have
> intentionally symlinked guix to their git checkout?

AIUI, the warning is based on the date of the ~/.config/guix/latest link
but FWIW I just refresh the links like this periodically ...

ln -f -s -T ~/src/guix/ ~/.config/guix/latest
sudo ln -f -s -T ~/src/guix/ /root/.config/guix/latest

HTH - George

Note: GUIX_DISTRO_AGE_WARNING as described below was implemented by
commit 7fd952e05203d975fcb6cdabd2f742ade1b31b66

*** From: l...@gnu.org (Ludovic Courtès) Subject: bug#25852: Users not
updating their installations of Guix To: Ricardo Wurmus
<rek...@elephly.net> Cc: 25852-d...@debbugs.gnu.org, myglc2
<myg...@gmail.com> Date: Fri, 12 May 2017 10:29:12 +0200 (2 weeks, 3
days, 13 hours ago) Resent-From: l...@gnu.org (Ludovic Courtès)

Ricardo Wurmus <rek...@elephly.net> skribis:

> Ludovic Courtès <l...@gnu.org> writes:
>
>> myglc2 <myg...@gmail.com> skribis:
>>
>>> How about extending this ...
>>>
>>>> +  (warning (G_ "Your Guix installation is getting old.  Consider
>>>> +running 'guix pull' followed by '~a' to get up-to-date
>>>> +packages and security updates.\n")
>>>
>>> ... to inform the user how old the installation is?
>>
>> Good idea.  I did that and pushed as
>> 7fd952e05203d975fcb6cdabd2f742ade1b31b66.
>
> Does this do the right thing when .config/guix/latest points at a git
> checkout?

No it doesn’t, but I would argue that it unsupported.  ;-)

> The mtime of the “.config/guix/latest” link on one of my machines is
> from 2016, so Guix says it is too old, but it points to a git
> checkout, which is recent.

I would suggest:

  export GUIX_DISTRO_AGE_WARNING=1000m

as a workaround.  WDYT?

Thanks,
Ludo’.

Re: WARNING: loading compiled file activation.go failed: ERROR: not an ELF file

[myglc2]

On 05/19/2017 at 11:05 Ludovic Courtès writes:

> Hi,
>
> myglc2 <myg...@gmail.com> skribis:
>
>> The warning/error shown below sounds alarming but seems to be
>> harmless. But it leaves me wondering, is there a way to fix it?
>>
>> TIA - George
>>
>> root@g1 ~/con/4# guix system --fallback --cores=4 --max-jobs=4
>> reconfigure sys.scm
>> [...]
>> activating system...
>> ;;; WARNING: loading compiled file 
>> /gnu/store/zaj3a5fsxjalirfypz6hn7hx3vc9d5kp-module-import-compiled/gnu/build/activation.go
>>  failed:
>> ;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
>> ;;; WARNING: loading compiled file 
>> /gnu/store/zaj3a5fsxjalirfypz6hn7hx3vc9d5kp-module-import-compiled/gnu/build/activation.go
>>  failed:
>> ;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
>> making '/gnu/store/fz77c02mf1dh84zj5vxfswcq1m3ibhxz-system' the current 
>> system...
>> [...]
>> Installation finished. No error reported.
>
> Contrary to what the messages say, these are actually warnings. ;-)
> They come from Guile 2.2 complaining that it stumbled upon Guile 2.0 .go
> files:
>
>   https://lists.gnu.org/archive/html/guix-devel/2017-04/msg00515.html
>
> (The warnings didn’t prevent ‘guix system reconfigure’ from completing.)
>
> From now on, you should make sure you only have 2.2 .go files around.
> If you use ‘guix pull’, that means that you have to run ‘guix pull’.
>
> If instead ~/.config/guix/latest is a symlink to a checkout that you
> made yourself, then make sure to “make clean && make” with Guile 2.2.
>

Thanks Ludo’. I tried both approaches:

In the g1 user account I did git pull, "make clean && make". I ended up
with guile 2.2. But when I tried to reconfigure as root I got the
"activation.go failed:" messages.

So, as root, I tried guix pull (please see below). I still ended up with
"activation.go failed:" and now I have guile 2.0.

TIA - George

root@g1 ~/con/7# guix pull

Starting download of /tmp/guix-file.tCtCOM
>From https://git.savannah.gnu.org/cgit/guix.git/snapshot/master.tar.gz...
 ….tar.gz   2.8MiB/s 00:05 | 13.1MiB transferred
unpacking '/gnu/store/5xv70jwadhknhhma3c3vv2jhj2jwh62m-guix-latest.tar.gz'...
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivation will be built:
   /gnu/store/ihg334sz1vh99pp0ck0dvwahnw26nhqc-guix-latest.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
copying and compiling to 
'/gnu/store/b05wix312n8b0r2slcjrxrjf85h1ylr2-guix-latest' with Guile 2.2.2...
loading...   24.7% of 595 filesrandom seed for tests: 1495218038
loading...   99.8% of 595 files
compiling... 98.7% of 595 files

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
updated GNU Guix successfully deployed under `/root/.config/guix/latest'
root@g1 ~/con/7# guix system --cores=4 --max-jobs=4 -K --on-error=debug build 
sys.scm
/gnu/store/zga47bix1jjqxskmc7z470rjqj21z2hj-system
root@g1 ~/con/7# guix system --fallback --cores=4 --max-jobs=4 reconfigure 
sys.scm
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivation will be built:
   /gnu/store/1lbk6yyxq6ll86cymyjdp4qaf6xqj6z1-grub.cfg.drv
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
/gnu/store/zga47bix1jjqxskmc7z470rjqj21z2hj-system
/gnu/store/a309iqd2s0fr1w1ljy0a4pra3v3nwm23-grub.cfg
/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02
/gnu/store/ldk2vqmxsmfk4ibwhijxxyzqv8wha54n-bootloader-installer
activating system...
;;; WARNING: loading compiled file 
/gnu/store/yayx5714vbxrl7fn4gygvbp662hbc53y-module-import-compiled/gnu/build/activation.go
 failed:
;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
;;; WARNING: loading compiled file 
/gnu/store/yayx5714vbxrl7fn4gygvbp662hbc53y-module-import-compiled/gnu/build/activation.go
 failed:
;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
making '/gnu/store/zga47bix1jjqxskmc7z470rjqj21z2hj-system' the current 
system...
setting up setuid programs in '/run/setuid-programs'...
populating /etc from /gnu/store/3ic3cb3k5vabfc0cilgz79pc5jsrdvak-etc...
usermod: no changes
usermod: no changes
usermod: no changes
usermod: no changes
usermod: no changes
guix system: unloading service 'user-homes'...
shepherd: Removing service 'user-homes'...
shepherd: Done.
guix system: loading new services: user-homes...
shepherd: Evaluating user expression (register-services (primitive-load 
"/gnu/s...")).
shepherd: Service user-homes could not be st

Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2]

[myglc2]

On 05/17/2017 at 14:45 Ludovic Courtès writes:

> Ricardo Wurmus  skribis:
>
>> I think that a first step towards improving the experience with “guix
>> pull” is to build Guix continuously on Hydra and tell “guix pull” to
>> download that.  Users would no longer have to wait for compilation on
>> their local machines, removing a big incentive to go with a git
>> checkout.  Maybe we should do this first to stop the worst problems,
>> buying us a bit more time to implement channels.
>
> That’s probably what we’ll do next.  But remember that users will still
> have to compute the derivation for that Guix, which in turn should allow
> them to get the corresponding substitute, and computing that derivation
> is currently relatively costly since you need to compile or interpret a
> subset of the Guix code.
>
> Ludo’.

This hints at the weirdly "re-entrant nature" of guix. And I mean that
in the most friendly way possible ;-)

I just wish I understood this aspect of guix better. Do we have a
diagram? Could we produce one? I sure would like to see it, or even help
make it.  Any suggestions along this line would be welcome.

Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2]

[myglc2]

Oops, sent before done, please see corrections ...

On 05/17/2017 at 12:06 myglc2 writes:

> On 05/16/2017 at 17:55 Ricardo Wurmus writes:
>
>> myglc2 <myg...@gmail.com> writes:
>>
>>> I believe there will be many guix "users" that want to run from git
>>> checkout. They just may not know it, yet. They will want it not just
>>> because they are trying to get around the limitations of git pull.  For
>>> example, even users that don't do development have occasion to...
>>>
>>> - select non-stock package config options
>>>
>>> - need/apply/use patches from guix developers
>>>
>>> - need/apply/use patches from package developers
>>>
>>> - need/apply/use some crazy stuff from a friend
>>
>> For those things I believe it to be better to use the package rewriting
>> framework, i.e. *adding* package variants that have additional patches
>> or modified configuration options.
>
> I don't follow you. Are you talking about (guix) Defining Packages ...
>
>  -- Scheme Procedure: package-input-rewriting REPLACEMENTS
>   [REWRITE-NAME]
>
> ... or something else?
>
>> Using the git checkout directly comes with too many disadvantages for
>> users who are not developers.  Git’s UI is famously weird, and there
>> hardly is anyone who really loves it.
>
> Agreed. But I am not saying you should force guix users to learn git. I
> mean you should leverage git to make guix better. For example, Homebrew
> (https://github.com/Homebrew) users don't know anything about git.
>
>> Using the git checkout also requires the use of “make clean-go” whenever
>> the ABI changes, and occasionally even necessitates re-bootstrapping, or
>> in the case of upgrading to Guile 2.2 re-configuration.
>
> These are shortcomings in how guix uses git, not problems with git
> itself. Changes in the way guix uses git can overcome these.
>
>>> Furthermore, ISTM that current guix packaging is a rather nasty tease:
>>> Our user installs guix/guixSD, does 'guix pull' & 'guix-edit', and what
>>> do they get?
>>>
>>> READ-ONLY source in an editor that BEEPS when they TRY TO CHANGE IT :-(
>>>
>>> Right out of the box this seem contrary to the Guix promise of _freedom_
>>> and _hackability_.
>>
>> True, “guix edit” could do better, e.g. create a new package variant in
>> a user module that inherits from the given package and puts the cursor
>> in the right spot to make changes right there.  Upon saving, the package
>> could be used right away with GUIX_PACKAGE_PATH.
>
> OK, you are jumping to an implementation that uses GUIX_PACKAGE_PATH. I
> am saying you should consider whether an implementation of guix-edit
> based on git may be better.
>
> Confession: I don't use GUIX_PACKAGE_PATH and probably never will: The
> GUIX_PACKAGE_PATH as described in the doc has multiple issues. The fact
> that it is mentioned 7 times in guix.texi is one indication of the
> problem. But the killer is the inherent problem of consistency between
> guix and code on the GUIX_PACKAGE_PATH. Someone trying to use
> GUIX_PACKAGE_PATH to share work with someone else is in for a word or
> hurt. 
>
> IMO a better alternative is git submodules and private git branches.
>
>> I think that a first step towards improving the experience with “guix
>> pull” is to build Guix continuously on Hydra and tell “guix pull” to
>> download that.  Users would no longer have to wait for compilation on
>> their local machines, removing a big incentive to go with a git
>> checkout.  Maybe we should do this first to stop the worst problems,
>> buying us a bit more time to implement channels.

Are you saying that users currently use the git checkout so they can
"stay put" on an old commit?

Are you saying that the version delivered by guix pull should be delayed
WRT the most current guix git repo master commit to allow hydra to
complete the build? If so +1

> I have been actively using guix pull and git pull for the last year. My
> "hillbilly impression" is that the problem with hydra that it is almost
> always either
[...]
- behind: user guix version is old and no longer in hydra's store

- ahead: user just did 'guix pull' but hydra hasn't build it.  I think
  you addressed this above

- new-commit: a developer has done git pull and hydra hasn't looked at
  it yet

- patch: a developer applies a patch from another developer

ISTM these can be addressed ...

- behind: save everything hydra builds, or at least the last few
  installation images. Can't we just accomplish this by never doing
  "guix gc" on hydra?

- new-commit: Here we want hydra to build every commit that lands in the
  guix git repo, prioritizing some branches (e.g. master) over others.

An approach that splits hydra's resources between building for ahead and
new-commit branches would be very nice to have, EH? ;-) 

WDYT? - George

Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2]

[myglc2]

On 05/16/2017 at 17:55 Ricardo Wurmus writes:

> myglc2 <myg...@gmail.com> writes:
>
>> I believe there will be many guix "users" that want to run from git
>> checkout. They just may not know it, yet. They will want it not just
>> because they are trying to get around the limitations of git pull.  For
>> example, even users that don't do development have occasion to...
>>
>> - select non-stock package config options
>>
>> - need/apply/use patches from guix developers
>>
>> - need/apply/use patches from package developers
>>
>> - need/apply/use some crazy stuff from a friend
>
> For those things I believe it to be better to use the package rewriting
> framework, i.e. *adding* package variants that have additional patches
> or modified configuration options.

I don't follow you. Are you talking about (guix) Defining Packages ...

 -- Scheme Procedure: package-input-rewriting REPLACEMENTS
  [REWRITE-NAME]

... or something else?

> Using the git checkout directly comes with too many disadvantages for
> users who are not developers.  Git’s UI is famously weird, and there
> hardly is anyone who really loves it.

Agreed. But I am not saying you should force guix users to learn git. I
mean you should leverage git to make guix better. For example, Homebrew
(https://github.com/Homebrew) users don't know anything about git.

> Using the git checkout also requires the use of “make clean-go” whenever
> the ABI changes, and occasionally even necessitates re-bootstrapping, or
> in the case of upgrading to Guile 2.2 re-configuration.

These are shortcomings in how guix uses git, not problems with git
itself. Changes in the way guix uses git can overcome these.

>> Furthermore, ISTM that current guix packaging is a rather nasty tease:
>> Our user installs guix/guixSD, does 'guix pull' & 'guix-edit', and what
>> do they get?
>>
>> READ-ONLY source in an editor that BEEPS when they TRY TO CHANGE IT :-(
>>
>> Right out of the box this seem contrary to the Guix promise of _freedom_
>> and _hackability_.
>
> True, “guix edit” could do better, e.g. create a new package variant in
> a user module that inherits from the given package and puts the cursor
> in the right spot to make changes right there.  Upon saving, the package
> could be used right away with GUIX_PACKAGE_PATH.

OK, you are jumping to an implementation that uses GUIX_PACKAGE_PATH. I
am saying you should consider whether an implementation of guix-edit
based on git may be better.

Confession: I don't use GUIX_PACKAGE_PATH and probably never will: The
GUIX_PACKAGE_PATH as described in the doc has multiple issues. The fact
that it is mentioned 7 times in guix.texi is one indication of the
problem. But the killer is the inherent problem of consistency between
guix and code on the GUIX_PACKAGE_PATH. Someone trying to use
GUIX_PACKAGE_PATH to share work with someone else is in for a word or
hurt. 

IMO a better alternative is git submodules and private git branches.

> I think that a first step towards improving the experience with “guix
> pull” is to build Guix continuously on Hydra and tell “guix pull” to
> download that.  Users would no longer have to wait for compilation on
> their local machines, removing a big incentive to go with a git
> checkout.  Maybe we should do this first to stop the worst problems,
> buying us a bit more time to implement channels.

I have been actively using guix pull and git pull for the last year. My
"hillbilly impression" is that the problem with hydra that it is almost
always either

- "ahead" of the user (e.g., files that the user needs are no longer in
   hydra's store) or

- "behind" the user (e.g. a developer that has just pulled someone
   else's commit, which aren't built yet).

Can't the "ahead" problem be fixed by just saving everything hydra has
ever built? Disks are cheap aren't they?

As regards the "behind" problem, can't this be fixed by having 'guix
pull' deliver only the git commits that are completely built?

- George

WARNING: loading compiled file activation.go failed: ERROR: not an ELF file

[myglc2]

The warning/error shown below sounds alarming but seems to be
harmless. But it leaves me wondering, is there a way to fix it?

TIA - George

root@g1 ~/con/4# guix system --fallback --cores=4 --max-jobs=4
reconfigure sys.scm
[...]
activating system...
;;; WARNING: loading compiled file 
/gnu/store/zaj3a5fsxjalirfypz6hn7hx3vc9d5kp-module-import-compiled/gnu/build/activation.go
 failed:
;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
;;; WARNING: loading compiled file 
/gnu/store/zaj3a5fsxjalirfypz6hn7hx3vc9d5kp-module-import-compiled/gnu/build/activation.go
 failed:
;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
making '/gnu/store/fz77c02mf1dh84zj5vxfswcq1m3ibhxz-system' the current 
system...
[...]
Installation finished. No error reported.
root@g1 ~/con/4#

Version info
: guix (GNU Guix) 0.12.0.3894-6f543
: Copyright (C) 2017 the Guix authors
: License GPLv3+: GNU GPL version 3 or later 
: This is free software: you are free to change and redistribute it.
: There is NO WARRANTY, to the extent permitted by law.
:   File: /root/.config/guix/latest -> /home/g1/src/guix/
: v0.12.0-3911-ge7620b649
: e7620b649 gnu: qemu: Fix CVE-2017-7493.
: * o-mastere7620b649 gnu: qemu: Fix 
CVE-2017-7493.

Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2]

[myglc2]

On 05/15/2017 at 17:48 Ludovic Courtès writes:

> Hi,
>
> Pjotr Prins  skribis:
>
[...]
>> Everyone, I mean everyone, is building guix with different toolsets, i.e,
>> combinations of tools and versions.
>>
>> This is wrong and unguixy.
>
> Yes, I kinda agree, though again, we need to distinguish between
> developers and users (I know I know, the deficiencies of ‘guix pull’
> gives users an incentive to do use the
> checkout/autoreconf/configure/make dance, but let’s put that aside for
> now.)

I believe there will be many guix "users" that want to run from git
checkout. They just may not know it, yet. They will want it not just
because they are trying to get around the limitations of git pull.  For
example, even users that don't do development have occasion to...

- select non-stock package config options

- need/apply/use patches from guix developers

- need/apply/use patches from package developers

- need/apply/use some crazy stuff from a friend

Furthermore, ISTM that current guix packaging is a rather nasty tease:
Our user installs guix/guixSD, does 'guix pull' & 'guix-edit', and what
do they get?

READ-ONLY source in an editor that BEEPS when they TRY TO CHANGE IT :-(

Right out of the box this seem contrary to the Guix promise of _freedom_
and _hackability_.

Now, if our user thinks they really do want to try making a change, they
first have to wade thru various and confusing config options and set
guix up in a _non-standard_ way. This is currently a large hurdle and
_far from liberating_.

Now there are no doubt different "classes" of guix users that need to be
accommodated. We should think about and agree on a model of what these
classes are and the services that guix provides in each class. Maybe some
of the discussions of channels, potluck, etc can also be fit into such a
framework.

Thinking about these issues I ended up wondering: why don't we use git
checkout in "guix pull" for all classes of user? Then there won't be a
big hurdle to get over when a user decides they want to try editing a
source. In this approach, different user classes would be accommodated
in the documentation structure and with a config option or two. As an
optimization, compiled .go modules can be pulled to minimize user-side
guix source compilation.

ISTM there would be no downside. WDYT?

- George

Re: emacs-build-system installs too many files

[myglc2]

On 05/14/2017 at 19:15 Arun Isaac writes:

>> I have a work in progress patch implementing the ideas discussed.
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26559
>
> Alex Kost and I have finalized this patch, more or less. It would be
> good if someone else could review it, and provide feedback so that we
> can push it and close the bug report.
>
> Thanks!

Hi Arun,

I'm not qualified to review the code, but, FWIW, I used these patches to
install emacs packages I use and don't use ... and I encountered no
difficulty. ;-)

- George

Re: Performance of the man page database generation

[myglc2]

On 05/13/2017 at 23:18 Maxim Cournoyer writes:

> Hello!
>
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hello,
>>
>> Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
>>
>>> myglc2 <myg...@gmail.com> writes:
>>
[...]
>>> 50 seconds for 33 packages on such a powerful machine seems abnormal,
>>> unless you have a specific package(s) which would install an unusually
>>> large amount of manual pages (which would take more time to be indexed).
>>>
[...]
>>
>> You can see those .drv names when building the profile.  So you just
>> need to copy/paste them and run “guix build --check” above.
>>
>> If you have the profile but not its .drv, you can find out what the .drv
>> for that profile was but there’s no command-line interface for that (you
>> have to use ‘valid-derivers’ from (guix store).)
>>
>> HTH,
>> Ludo’.
>
> Thanks Ludovic; that was helpful.
>
> I did a small test and it takes about 40 s on my system, with 60
> packages or so in my profile. I removed the "--quiet" flag of mandb in
> the profile hook (guix profile) to see the output of mandb while it was
> indexing the manual pages:
>
> time guix build --check 
> /gnu/store/vk10zmd5nm8kppd0f655fraradr019fq-manual-database.drv
[...]
> real0m39.890s
> user0m0.356s
> sys 0m0.040s
>
[...]

Hi Maxim and Ludo’,

I hacked profiles.scm (please see git diff below) so that start and end
seconds appear in the message like this:

creating manual page database for 23 packages...1494773268...1494773275 DONE

I tested a few cases and man-db typically takes only a few seconds.  It
only _appears_ to take a long time because other processing occurs after
the man-db command.

So, I suggest either ...

1) delete the message altogether, or
2) close the message with a "DONE"

SORRY for the run-around. In my defense, when I first raised the
question I did suggest the idea of closing the message:

http://lists.gnu.org/archive/html/guix-devel/2017-04/msg00196.html

HTH, George

g1@g1 ~/src/guix [env]$ git diff
diff --git a/guix/profiles.scm b/guix/profiles.scm
index eb172ef45..4dbf44a81 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1011,13 +1011,15 @@ the entries in MANIFEST."
 (mkdir-p man-directory)
 (setenv "MANPATH" (string-join entries ":"))
 
-(format #t "creating manual page database for ~a packages...~%"
-(length entries))
+(format #t "creating manual page database for ~a packages...~a"
+(length entries)(current-time))
 (force-output)
 
 (zero? (system* #+(file-append man-db "/bin/mandb")
 "--quiet" "--create"
-"-C" "man_db.conf"
+"-C" "man_db.conf"))
+(format #t "...~a DONE~%" (current-time))
+(force-output)))
 
   (gexp->derivation "manual-database" build
 #:modules '((guix build utils)
g1@g1 ~/src/guix [env]$ 

Re: Heads-up: transition to Guile 2.2

[myglc2]

On 05/11/2017 at 10:29 Ludovic Courtès writes:

> myglc2 <myg...@gmail.com> skribis:
>
>> g1@g1 ~/src/guix$ guix package -i icecat
>> guix package: warning: Your Guix installation is 85 days old.
>> guix package: warning: Consider running 'guix pull' followed by
>> 'guix package -u' to get up-to-date packages and security updates.
>> [...]
>>
>> But I just did a git pull ...
>>
>> g1@g1 ~/src/guix$ git -C ~/.config/guix/latest describe
>> v0.12.0-3681-gbc0e6c931
>>
>> ... and my ~/.config/guix/latest points to it ...
>
> This is a special setup.  The warning above just stats
> ~/.config/guix/latest.  For someone using ‘guix pull’, it’s a symlink
> that’s updated each time ‘guix pull’ is invoked.
>
> In your case it’s a symlink that’s never updated… but your warranty is
> void anyway.  ;-)
>
> Ludo’.

Oh! Thanks! I can force a new symlink each time I re-make guix.

Maybe this is a situation where it would be beneficial to embed a
date. ISTM a canonical date can be determined for any guix version so it
would not lead to un-reproducibility. And it would be a nice gift to
researchers doing an archelogical dig 1000 years from now ;-)

Re: Heads-up: transition to Guile 2.2

[myglc2]

On 05/10/2017 at 13:11 myglc2 writes:

> On 05/10/2017 at 14:05 Ludovic Courtès writes:
>
>> Hi,
>>
>> myglc2 <myg...@gmail.com> skribis:
>>
>>> I run GuixSD from git checkout this way ...
>>>
>>> cd ~/src/guix
>>> guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \
>>> -c 4
>>> git pull
>>> make clean-go
>>> ./bootstrap
>>> ./configure --localstatedir=/var --sysconfdir=/etc
>>> make -j 10 check
>>> exit
>>> sudo guix system build /root/con/55.scm -M 4 -c 4
>>> sudo guix system reconfigure /root/con/55.scm -M 4 -c 4
>>> sudo reboot
>>>
>>> Should this just work? Or is there something that needs to be done
>>> differently for the 2.0 >>> 2.2 change?
>>
>> That should just work.
>>
>> The only issue you might have is warnings about invalid .go files if
>> ~/.config/guix/latest contains 2.0 .go files and you’re running Guile
>> 2.2.  The fix is to run ‘guix pull’.
>
> Thanks, I did that and, as you suggested, I got warnings ...
>
> g1@g1 ~/src$ guix package -m g1.scm
> ;;; WARNING: loading compiled file /home/g1/.config/guix/latest/guix/ui.go 
> failed:
> ;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
> ;;; note: source file /home/g1/.config/guix/latest/guix/ui.scm
> ;;;   newer than compiled 
> /gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/lib/guile/2.2/site-ccache/guix/ui.go
>
> ... but I really didn't want to do a git pull. So I re-built guix.  
>
> Bottom line: FWIW, I upgraded from 2.0 to 2.2 without 'guix pull' like
> this way ...
>
> cd ~/src/guix
> guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \
> -c 4
> git pull
> make clean-go
> ./bootstrap
> ./configure --localstatedir=/var --sysconfdir=/etc
> make -j 10 check
> exit
> sudo guix system build /root/con/55.scm -M 4 -c 4
> sudo guix system reconfigure /root/con/55.scm -M 4 -c 4
> sudo reboot
> 
> cd ~/src/guix
> guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \
> -c 4
> make clean-go
> ./bootstrap
> ./configure --localstatedir=/var --sysconfdir=/etc
> make -j 10 check

Or maybe not. With your recent change, guix says it's 85 days old ...

g1@g1 ~/src/guix$ guix package -i icecat
guix package: warning: Your Guix installation is 85 days old.
guix package: warning: Consider running 'guix pull' followed by
'guix package -u' to get up-to-date packages and security updates.
[...]

But I just did a git pull ...

g1@g1 ~/src/guix$ git -C ~/.config/guix/latest describe
v0.12.0-3681-gbc0e6c931

... and my ~/.config/guix/latest points to it ...

g1@g1 ~/src/guix$ stat ~/.config/guix/latest | grep File:
  File: /home/g1/.config/guix/latest -> /home/g1/src/guix/

... and I did 'make' and 'git system reconfigure' & reboot so that guix
claims it is the latest version ...

g1@g1 ~$ guix --version guix
(GNU Guix) 0.12.0.3681-bc0e6

So...  is some part of my guix 85 days old?

Or... there a problem with the new "days old" message?

TIA - George


  

backup w/ duplicity borg attic bup?

[myglc2]

I am looking for a command line de-duplicating backup tool. I will be
using it between GuixSD, Guix/GNU/Linux, and MacOS.

Based on what I see in gnu/packages/backup.scm and in https://brew.sh,
duplicity, borg and attic seem like they could be good choices.

I am also intrigued by bup (https://github.com/bup/bup), for which we
don't have a package (yet).

I would like to avoid python, but all of the above seem to use it ;-(

Does anyone out have suggestions?

TIA - George

Re: Heads-up: transition to Guile 2.2

[myglc2]

On 05/09/2017 at 23:22 Ludovic Courtès writes:

> Hello Guix!
>
> l...@gnu.org (Ludovic Courtès) skribis:
>
>> There’s a problem though, called “guix pull”.  ~/.config/guix/latest
>> currently contains 2.0 .go files.  Thus after reconfiguring GuixSD to
>> use Guix-for-2.2, running ‘guix’ typically gives loads of warnings like:
>>
>>   ;;; WARNING: loading compiled file 
>> /home/ludo/.config/guix/latest/guix/derivations.go failed:
>>   ;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
>
> With commit 838ba73d6e49bd2b1f2d4ed9329b65cc4e8c1f54, ‘guix pull’ builds
> with the currently used Guile, be it 2.0 or 2.2.  To achieve that, it
> tries hard to pick 2.0 or 2.2 packages for the dependencies of Guix.
>
> If it cannot find a “guile-ssh” package for the Guile being used (for
> instance, you’re using Guile 2.2 but lacking the “guile-ssh” package
> built with 2.2), then it simply skips modules that depend on Guile-SSH;
> they are optional anyway.  For Guile-JSON, it just assumes that there is
> a matching Guile-JSON, which should be the case anyway.
>
> As I wrote before, ‘guix pull’ in its current form is pretty fragile;
> please report any problems you have.
>
>
> In addition, with commit 7561881f2a5d2dc463c24713745eca03e67044bf, the
> “guix” package is now built with Guile 2.2 instead of 2.0.  Thus, next
> time you update GuixSD, /run/current-system/profile/bin/guix will be
> using Guile 2.2.  At that point, if ~/.config/guix/latest contains .go
> files for 2.0, you’ll get warnings as shown above, and you’ll have to
> “guix pull” to get rid of them.
>
>
> At this point, we’re still using Guile 2.0 (1) to build derivations, and
> (2) in the Shepherd, mcron, and modules imported inside the Shepherd.
> In ‘core-updates’ we have addressed #1 and we’ll address #2 as well.
>
> Ludo’.

Hi Ludo, this sounds great!

I run GuixSD from git checkout this way ...

cd ~/src/guix
guix environment -e "(@ (gnu packages package-management) guix)" -M 4 \
-c 4
git pull
make clean-go
./bootstrap
./configure --localstatedir=/var --sysconfdir=/etc
make -j 10 check
exit
sudo guix system build /root/con/55.scm -M 4 -c 4
sudo guix system reconfigure /root/con/55.scm -M 4 -c 4
sudo reboot

Should this just work? Or is there something that needs to be done
differently for the 2.0 >>> 2.2 change?

TIA - George

Re: ;;; ERROR: missing interface for module (charting)

[myglc2]

On 05/08/2017 at 14:25 Ludovic Courtès writes:

> Hi!
>
> myglc2 <myg...@gmail.com> skribis:
>
>>   GUILEC   guix/scripts/size.go
>> ;;; Failed to autoload make-page-map in (charting):
>> ;;; ERROR: missing interface for module (charting)
>
> These messages are about Guile-Charting, an optional dependency of this
> tool:
>
>   https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-size.html
>
> You’re expecting to have this message when Guile-Charting is missing,
> but that’s fine: it just means that you won’t be able to use ‘guix size
> --map-file’.
>
> That said, I agree that these messages are needlessly alarming.  Not
> sure how to fix them.
>
> Ludo’.

Thanks, that's what I thought but I am confused because I already have
guile-charting installed ...

g1@g1 ~/src/guix$ guix package -I | grep charting
guile-charting  0.2.0   out 
/gnu/store/pykm7a8a9p2qs5nwxsb48vvl8iz1kjd4-guile-charting-0.2.0

I have tried adding it to the environment, but I still get these
messages ...

g1@g1 ~/src/guix$ guix environment --ad-hoc guile-charting -e "(@ (gnu packages 
package-management) guix)" -M 4 -c 4
g1@g1 ~/src/guix [env]$ rm guix/scripts/size.go
g1@g1 ~/src/guix [env]$ make
make  all-recursive
make[1]: Entering directory '/home/g1/src/guix'
Making all in po/guix
make[2]: Entering directory '/home/g1/src/guix/po/guix'
make[2]: Leaving directory '/home/g1/src/guix/po/guix'
Making all in po/packages
make[2]: Entering directory '/home/g1/src/guix/po/packages'
make[2]: Leaving directory '/home/g1/src/guix/po/packages'
make[2]: Entering directory '/home/g1/src/guix'
Compiling Scheme modules...
  LOAD (guix scripts size)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
  GUILEC   guix/scripts/size.go
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
guix/scripts/size.scm:211:2: warning: possibly unbound variable `make-page-map'
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
make[2]: Leaving directory '/home/g1/src/guix'
make[1]: Leaving directory '/home/g1/src/guix'
g1@g1 ~/src/guix [env]$


g1@g1 ~/src/guix [env]$ guix --version
guix (GNU Guix) 0.12.0.3556-484f

g1@g1 ~/src/guix [env]$ git -C ~/.config/guix/latest describe
v0.12.0-3556-g484f7a886

TIA - George

;;; ERROR: missing interface for module (charting)

[myglc2]

How do i fix these non-blocking "ERROR:" messages?

g1@g1 ~/src/guix $ guix environment -e "(@ (gnu packages package-management) 
guix)" -M 4 -c 4
g1@g1 ~/src/guix [env]$ make clean-go
g1@g1 ~/src/guix [env]$ ./bootstrap
g1@g1 ~/src/guix [env]$ ./configure --localstatedir=/var --sysconfdir=/etc
g1@g1 ~/src/guix [env]$ make -j 10
[...]
  LOAD (guix scripts build)
  LOAD (guix scripts archive)
  LOAD (guix scripts import)
  LOAD (guix scripts package)
  LOAD (guix scripts gc)
  LOAD (guix scripts hash)
  LOAD (guix scripts pack)
  LOAD (guix scripts pull)
  LOAD (guix scripts substitute)
  LOAD (guix scripts authenticate)
  LOAD (guix scripts refresh)
  LOAD (guix scripts system)
  LOAD (guix scripts lint)
  LOAD (guix scripts challenge)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
[...]
  GUILEC   guix/scripts/challenge.go
  GUILEC   guix/scripts/import/cran.go
  GUILEC   guix/scripts/import/gnu.go
  GUILEC   guix/scripts/import/nix.go
  GUILEC   guix/scripts/import/hackage.go
  GUILEC   guix/scripts/import/stackage.go
  GUILEC   guix/scripts/import/elpa.go
  GUILEC   guix/scripts/environment.go
  GUILEC   guix/scripts/publish.go
  GUILEC   guix/scripts/edit.go
  GUILEC   guix/scripts/size.go
  GUILEC   guix/scripts/graph.go
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
guix/scripts/size.scm:211:2: warning: possibly unbound variable `make-page-map'
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)
;;; Failed to autoload make-page-map in (charting):
;;; ERROR: missing interface for module (charting)

I am using a recent origin/master commit ...

g1@g1 ~/src/guix [env]$ git -C ~/.config/guix/latest log -n 1 --oneline
484f7a886 gnu: libtiff: Add fixes several security flaws.
g1@g1 ~/src/guix [env]$ git -C ~/.config/guix/latest describe
v0.12.0-3556-g484f7a886

TIA - George

Re: Doc: reference to guix-devel for submitting patches

[myglc2]

>   export INFOPATH="$HOME/guix/doc${INFOPATH:+:}$INFOPATH"
>
> where $HOME/guix is my local checkout of Guix's Git repository.  This
> ensures that the manual I read using Emacs and the Info reader matches
> the Guix code I have checked out (after I've built it, of course).  Do
> you think it would be worth it if I added a small section about this to
> the "Contributing" section in the manual?  It seems to come up from time
> to time on the mailing list.

+1

Re: Non-graphical GRUB configuration

[myglc2]

On 04/05/2017 at 07:59 Leo Famulari writes:

> On Sun, Apr 02, 2017 at 05:06:20PM -0400, Leo Famulari wrote:
>> Based on the GRUB manual [0], how about this plan?
>> 
>> We'd add these fields to (grub-configuration): 
>> 
>> terminal-outputs: One or more symbols: console, serial, gfxterm,
>> ofconsole, vga_text. Default gfxterm.
>> 
>> terminal-inputs: One or more symbols: console, serial, ofconsole,
>> at_keyboard,usb_keyboard. Default unset.
>> 
>> If 'terminal-inputs' or 'serial-*' are unset, we do what we do now:
>> nothing. If 'terminal-outputs' is unset, we also do the same thing we
>> now, which is set it to gfxterm.
>> 
>> If any of them are set, we'd insert the corresponding text into the
>> generated grub.cfg.
>> 
>> If terminal-outputs does not include the symbol 'gfxterm', we'd disable
>> the "setup_gfxterm" function.
>
> Here's a WIP patch that I'd like some advice about. It does insert the
> relevant text into grub.cfg, although I recommend testing it in a
> virtual machine for now.
>
> Questions:
>
> 1) In general, is this approach okay?
>
> 2) I think that (grub-setup-io) should be used in
> (grub-configuration-file) instead of (eye-candy). But, when I try
> calling it there, in the builder, it has no effect on grub.cfg. Any
> suggestions for debugging this?

Hey Leo, As reported earlier, this works for me. IMO it is good to
go. If there is anything I can do to help, please let me know.

Re: [PATCH] doc: Improve guile load path recommendation.

[myglc2]

On 04/16/2017 at 11:06 Alex Kost writes:

> myglc2 (2017-04-16 00:19 -0400) wrote:
>
>> On 04/15/2017 at 16:20 Chris Marusich writes:
> [...]
>> The geiser doc says ...
>>
>>You can also specify a couple more initialisation parameters.  For
>> Guile, 'geiser-guile-load-path' is a list of paths to add to its load
>> path (and its compiled load path) when it's started, ...
>>
>> ... which implies that geiser sets the compiled load path to the
>> geiser-guile-load-path. But it does not seem to be doing that. I guess
>> that could be a bug.
>
> Previously I also thought that setting ‘geiser-guile-load-path’ is not
> enough as it would only set the %load-path, because Geiser starts Guile
> like this ( comes from ‘geiser-guile-load-path’):
>
>   guile ... -L 
>
> while it should be:
>
>   guile ... -L  -C 
>
> to set the %load-compiled-path as well.  However, I've just found that
> geiser sets %load-compiled-path internally in its Scheme code, so the
> current recommendation in the manual should probably work (I didn't
> check it, as I prefer to set environment variables).
>
> BTW, according to the commit message at
> <https://github.com/jaor/geiser/commit/393305d2fcf612f4e5f99383f680f819b458c326>,
> it looks like Ludovic was the person who proposed this change ;-)

Thanks for the comments. I now see that I was confusing the effects of
installing guile 2.2, which causes recompilation of everything, with the
effects of this change, which I made at about the same time.

So please forget about the patch. SORRY for the run around!

Re: [PATCH] doc: Improve guile load path recommendation.

[myglc2]

On 04/15/2017 at 16:20 Chris Marusich writes:

> myglc2 <myg...@gmail.com> writes:
>
>> Using geiser-guile-load-path as currently recommended results in source
>> that was already compiled by the guix build being recompiled :-(
>>
>> This patch avoids that. It also moves the configuration to
>> '~/.bash_profile' so it applies when guile is used directly.
>>
>> From 4585499f99336dc3e626c3105f0539ef3b5ce33c Mon Sep 17 00:00:00 2001
>> From: George Clemmer <myg...@gmail.com>
>> Date: Sat, 15 Apr 2017 14:21:09 -0400
>> Subject: [PATCH] doc: Improve guile load path recommendation.
>>
>> * doc/contributing.texi (The Perfect Setup): Advise setting GUILE_LOAD_PATH 
>> and
>> GUILE_LOAD_COMPILED_PATH in .bash_profile rather than emacs init.
>> ---
>>  doc/contributing.texi | 19 +++
>>  1 file changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/doc/contributing.texi b/doc/contributing.texi
>> index bbc93424b..d23f55a6b 100644
>> --- a/doc/contributing.texi
>> +++ b/doc/contributing.texi
>> @@ -171,14 +171,17 @@ Emacs: code compilation and evaluation from within 
>> buffers, access to
>>  on-line documentation (docstrings), context-sensitive completion,
>>  @kbd{M-.} to jump to an object definition, a REPL to try out your code,
>>  and more (@pxref{Introduction,,, geiser, Geiser User Manual}).  For
>> -convenient Guix development, make sure to augment Guile’s load path so
>> -that it finds source files from your checkout:
>> -
>> -@lisp
>> -;; @r{Assuming the Guix checkout is in ~/src/guix.}
>> -(with-eval-after-load 'geiser-guile
>> -  (add-to-list 'geiser-guile-load-path "~/src/guix"))
>> -@end lisp
>> +convenient Guix development, make sure to augment Guile’s load paths so
>> +that it finds source and compiled files from your checkout. Assuming the
>> +Guix checkout is in @code{~/src/guix}, add the following lines to your
>> +‘~/.bash_profile’ (*note (bash)Bash Startup Files::):
>> +
>> +@verbatim
>> +export GUILE_LOAD_PATH=\
>> +"$HOME/src/guix${GUILE_LOAD_PATH:+:$GUILE_LOAD_PATH}"
>> +export GUILE_LOAD_COMPILED_PATH=\
>> +"$HOME/src/guix${GUILE_LOAD_COMPILED_PATH:+:$GUILE_LOAD_COMPILED_PATH}"
>> +@end verbatim
>>  
>>  To actually edit the code, Emacs already has a neat Scheme mode.  But in
>>  addition to that, you must not miss
>
> How does this change avoid the recompilation you mentioned?  It looks to
> me like before this change, Geiser would find Guix modules in
> ~/src/guix, and after this change, Geiser will still find Guix modules
> in ~/src/guix.  So from that perspective, it seems like it won't change
> the way Geiser behaves.

Hi Chris, thank you for the comments ;-)

I can report that this has a big, positive effect on the geiser user
experience.  Before this change guile didn't find the compiled files in
the git checkout work tree and so it compiled everything it touched
(putting compiled files in '~/.cache/guile/ccache/'). This produced big
delays and it just felt broken.

> However, before this change, other Guile processes (e.g., launched via
> "guix package -i foo") would not see the modules in ~/src/guix, and
> after this change, it looks to me like they will see the modules in
> ~/src/guix.

I believe the guix commands find compiled files in the git work tree
because '~/.config/guix/latest' points there ...

  /home/g1/.config/guix/latest -> /home/g1/src/guix/

> If the intended goal is just to let Geiser know where the
> Guix source lives, then this method might not be the best solution,
> since it will affect programs outside of Geiser, too.
>
> If I'm mistaken, please help me understand what I'm missing.

The geiser doc says ...

   You can also specify a couple more initialisation parameters.  For
Guile, 'geiser-guile-load-path' is a list of paths to add to its load
path (and its compiled load path) when it's started, ...

... which implies that geiser sets the compiled load path to the
geiser-guile-load-path. But it does not seem to be doing that. I guess
that could be a bug.

Regarding our other guile apps ...

The guix makefile unsets GUILE_LOAD_COMPILED_PATH, so the guix build is
unaffected.

With the proposed change, a guile user exploring guix via the REPL has a
better experience than before.

Are there other guile apps you have in mind?

HTH, please let me know. - George

[PATCH] doc: Improve guile load path recommendation.

[myglc2]

Using geiser-guile-load-path as currently recommended results in source
that was already compiled by the guix build being recompiled :-(

This patch avoids that. It also moves the configuration to
'~/.bash_profile' so it applies when guile is used directly.

>From 4585499f99336dc3e626c3105f0539ef3b5ce33c Mon Sep 17 00:00:00 2001
From: George Clemmer 
Date: Sat, 15 Apr 2017 14:21:09 -0400
Subject: [PATCH] doc: Improve guile load path recommendation.

* doc/contributing.texi (The Perfect Setup): Advise setting GUILE_LOAD_PATH and
GUILE_LOAD_COMPILED_PATH in .bash_profile rather than emacs init.
---
 doc/contributing.texi | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index bbc93424b..d23f55a6b 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -171,14 +171,17 @@ Emacs: code compilation and evaluation from within buffers, access to
 on-line documentation (docstrings), context-sensitive completion,
 @kbd{M-.} to jump to an object definition, a REPL to try out your code,
 and more (@pxref{Introduction,,, geiser, Geiser User Manual}).  For
-convenient Guix development, make sure to augment Guile’s load path so
-that it finds source files from your checkout:
-
-@lisp
-;; @r{Assuming the Guix checkout is in ~/src/guix.}
-(with-eval-after-load 'geiser-guile
-  (add-to-list 'geiser-guile-load-path "~/src/guix"))
-@end lisp
+convenient Guix development, make sure to augment Guile’s load paths so
+that it finds source and compiled files from your checkout. Assuming the
+Guix checkout is in @code{~/src/guix}, add the following lines to your
+‘~/.bash_profile’ (*note (bash)Bash Startup Files::):
+
+@verbatim
+export GUILE_LOAD_PATH=\
+"$HOME/src/guix${GUILE_LOAD_PATH:+:$GUILE_LOAD_PATH}"
+export GUILE_LOAD_COMPILED_PATH=\
+"$HOME/src/guix${GUILE_LOAD_COMPILED_PATH:+:$GUILE_LOAD_COMPILED_PATH}"
+@end verbatim
 
 To actually edit the code, Emacs already has a neat Scheme mode.  But in
 addition to that, you must not miss
-- 
2.12.2

Re: [PATCH] gnu: emacs-ag: build/install info

[myglc2]

On 04/12/2017 at 18:18 Alex Kost writes:

[...]
> I added a copyright line for you and committed:
>
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=99517d92709ee979c3507994caeb18db1eed08a6
>
> Thanks!

Thank you for the corrections. Stumbling around in the dark and happy to have 
them ;-)

Re: Some suggestion about "Contributing" documents.

[myglc2]

On 04/11/2017 at 09:40 ng0 writes:

> Can you come up with an chapters, subchapters, + briefly described /
> expected content map? This might help to work on it.
>
> Hartmut Goebel transcribed 0.5K bytes:
>> Am 11.04.2017 um 07:28 schrieb Feng Shu:
>> > "Contributing" document is hard to be understood i think.
>> > In my opinion, "Contributing" part of document should split
>> > two sub parts:
>> >
>> > 1. I am a guix core developer
>> >
>> > 2. I Just want to add a new apps's "define-public"
>> 
>> Good idea. I'd even put the "add a new apps" part first since this is
>> what more people will do more often.
>> 
>> -- 
>> Regards
>> Hartmut Goebel
>> 
>> | Hartmut Goebel  | h.goe...@crazy-compilers.com   |
>> | www.crazy-compilers.com | compilers which you thought are impossible |
>> 
>>

ISTM this should organized around an assumed "normal"
pattern-of-use. e.g., starting from assumption that Guix or GuixSD is
already installed and we use Guix to simplify the steps. Callouts should
be provided if any steps differ between for Guix or GuixSD users. In
this case a outline might look like ...

7 Contributing

- Setting up a Guix build from Git
 - git checkout
 - tool chain setup
  - sample: system.scm
  - sample: user.scm
 - first guix build
  - hacking steps
- modify an existing package
 - hacking steps
- add new package
 - hacking steps
- Submitting Patches::  Share your work.
- For guix core developers
 - Install Guix from source
 - Run Guix Before It Is Installed::  Hacker tricks.

[PATCH] gnu: emacs-ag: build/install info

[myglc2]

Info source was included but not previously being built.

>From 5b757a33ffb1528621027aeecff07a7b95c5df39 Mon Sep 17 00:00:00 2001
From: George Clemmer 
Date: Mon, 10 Apr 2017 18:31:52 -0400
Subject: [PATCH] gnu: emacs-ag: build/install info

* gnu/packages/emacs.scm (emacs-a): build/install info
---
 gnu/packages/emacs.scm | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index cc14fd228..4e788830c 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -56,6 +56,7 @@
   #:use-module (gnu packages gtk)
   #:use-module (gnu packages gnome)
   #:use-module (gnu packages ncurses)
+  #:use-module (gnu packages python)
   #:use-module (gnu packages tex)
   #:use-module (gnu packages texinfo)
   #:use-module (gnu packages tls)
@@ -1125,9 +1126,23 @@ than @code{electric-indent-mode}.")
("ag-executable"
 (string-append (assoc-ref inputs "the-silver-searcher")
"/bin/ag")))
- #t)
+ #t))
+ (add-before 'install 'make-info
+   (lambda _
+ (with-directory-excursion "docs"
+   (unless (zero? (system* "make" "info"))
+ (error "makeinfo failed")
+ (add-after 'install 'install-info
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let* ((out  (assoc-ref outputs "out"))
+(info (string-append out "/share/info")))
+   (install-file "docs/_build/texinfo/agel.info" info)
+   #t))
 (inputs
  `(("the-silver-searcher" ,the-silver-searcher)))
+(native-inputs
+ `(("python-sphinx" ,python-sphinx)
+   ("texinfo" ,texinfo)))
 (propagated-inputs
  `(("dash" ,emacs-dash)
("s" ,emacs-s)))
-- 
2.12.2

Re: 04/06: profiles: Generate database file for man pages.

[myglc2]

On 04/10/2017 at 10:22 Maxim Cournoyer writes:

> Hi myglc2!
>
> On Mon, Apr 10, 2017 at 2:28 AM, myglc2 <myg...@gmail.com> wrote:
>>
>> On 04/05/2017 at 16:56 Ludovic Courtès writes:
>>
>> > civodul pushed a commit to branch master
>> > in repository guix.
>> >
>> > commit a0b87ef8ec7735aa42cf35d380e9cff04f3236f3
>> > Author: Maxim Cournoyer <maxim.courno...@gmail.com>
>> > Date: Wed Apr 5 01:09:22 2017 -0700
>> [...]
>>
>> So now q'guix package -m' produces messages like ...
>>
>> guix package -m g1.scm
>> installing new manifest from 'g1.scm' with 22 entries
>> substitute: updating list of substitutes from 
>> 'https://mirror.hydra.gnu.org'... 100.0%
>> The following derivations will be built:
>> /gnu/store/smyjh63avay2gb6yq47h3hrlyxfrsajp-profile.drv
>> /gnu/store/ygp7n87177fngqqpb5l5bkkba5cawcvh-gtk-icon-themes.drv
>> /gnu/store/wrad8m1vhck9bb7dzqqlxb03rq1ifsm8-gtk-im-modules.drv
>> /gnu/store/qv12155lx8y195my98970mmfawqpnrcs-info-dir.drv
>> /gnu/store/ndiq7ccmi32rlxdyf52f506jil0zn9p0-ca-certificate-bundle.drv
>> /gnu/store/90gzasiixp9np5m4nn28vbfqd1zd5azq-fonts-dir.drv
>> /gnu/store/3l8kl1b438qr3yk2qca4pzvlpv04q7rc-xdg-mime-database.drv
>> /gnu/store/2brridy714shmik1zksysik36kn2iwsf-manual-database.drv
>> creating manual page database for 23 packages...
>> 22 packages in profile
>> g1@g1 ~/src$
>>
>> And... watching this, it seems like a long time between ...
>>
>> creating manual page database for 23 packages...
>>
>> ... and ...
>>
>> 22 packages in profile
>>
>> Does it really take this long? If not, can we close the message ...
>
> FWIR it is CPU bound, so your mileage will vary; in my case on an old
> low-power laptop it can take a few seconds for ~65 packages.

It is taking more like 50 seconds on my 3.4 Ghz server for 33 packages.

> I wonder why the odd package count mismatch (23 vs 22) ?

That's my fault. I cut and pasted from two different runs. SORRY! ;-)

> I don't recall observing this while testing (maybe it only happens
> when using the -m option) ?

No, I get the same effect w/ 'guix package -r foo.

Re: 04/06: profiles: Generate database file for man pages.

[myglc2]

On 04/05/2017 at 16:56 Ludovic Courtès writes:

> civodul pushed a commit to branch master
> in repository guix.
>
> commit a0b87ef8ec7735aa42cf35d380e9cff04f3236f3
> Author: Maxim Cournoyer 
> Date:   Wed Apr 5 01:09:22 2017 -0700
[...]

So now q'guix package -m' produces messages like ...

guix package -m g1.scm
installing new manifest from 'g1.scm' with 22 entries
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 
100.0%
The following derivations will be built:
   /gnu/store/smyjh63avay2gb6yq47h3hrlyxfrsajp-profile.drv
   /gnu/store/ygp7n87177fngqqpb5l5bkkba5cawcvh-gtk-icon-themes.drv
   /gnu/store/wrad8m1vhck9bb7dzqqlxb03rq1ifsm8-gtk-im-modules.drv
   /gnu/store/qv12155lx8y195my98970mmfawqpnrcs-info-dir.drv
   /gnu/store/ndiq7ccmi32rlxdyf52f506jil0zn9p0-ca-certificate-bundle.drv
   /gnu/store/90gzasiixp9np5m4nn28vbfqd1zd5azq-fonts-dir.drv
   /gnu/store/3l8kl1b438qr3yk2qca4pzvlpv04q7rc-xdg-mime-database.drv
   /gnu/store/2brridy714shmik1zksysik36kn2iwsf-manual-database.drv
creating manual page database for 23 packages...
22 packages in profile
g1@g1 ~/src$ 

And... watching this, it seems like a long time between ...

creating manual page database for 23 packages...

... and ...

22 packages in profile

Does it really take this long? If not, can we close the message ...

'creating manual page database for 25 packages...DONE'

... so that our gentle users will not be thinking ...

"I don't want this 

Re: Why did INFO disappear in 13e4a6c86 * gnu: screen: Update to 4.5.1?

[myglc2]

Please ignore. I see the problem ...

https://mirror.hydra.gnu.org/log/3si822dbkwnr4y71imwzgx9r3sx2q8cp-screen-4.5.1
[...]
./screen.texinfo:5799: unknown command `suse'
./screen.texinfo:5800: unknown command `deuxchevaux'
make[2]: *** [Makefile:31: screen.info] Error 1
[...]

... and it has been reported upstream ...

http://lists.gnu.org/archive/html/screen-devel/2017-03/msg0.html

... so sorry for the chatter ...

... but happy to discover hydra build logs  ;-)

On 04/08/2017 at 18:10 myglc2 writes:

> Hi Efraim & Leo,
>
> gnu screen 4.5.0 has INFO ...
>
>   /gnu/store/bxnzlqz31011w3rf04bvg03agz15s4dw-screen-4.5.0/share/info:
>   -r--r--r-- 3 root root 74621 Dec 31  1969 screen.info.gz
>
> ... but 4.5.1 doesn't ...
>
>   /gnu/store/3si822dbkwnr4y71imwzgx9r3sx2q8cp-screen-4.5.1/share/info:
>
> I can't figure out how/why it disappeared. Any idea how to get it back?
>
> TIA - George

Re: how to "install" guixsd on a digitalocean server

[myglc2]

On 04/07/2017 at 14:31 ng0 writes:

> Andy Wingo transcribed 1.0K bytes:
>> Hi :)
>> 
>> On Fri 07 Apr 2017 16:04, myglc2 <myg...@gmail.com> writes:
>> 
>> > On 04/07/2017 at 14:07 Andy Wingo writes:
>> >
>> >> I just "installed" GuixSD on a DigitalOcean droplet.  You can't actually
>> >> install GuixSD; you have to mutate an existing installation into
>> >> GuixSD.  But fine.
>> > [...]
>> >
>> > I upgraded Debian to GuixSD on a physical server in a similar way ...
>> >
>> > https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00354.html
>> >
>> > ... but I used 'guix system init' instead of 'guix system reconfigure'.
>> >
>> > I wonder, could that approach have been used in this situation to avoid
>> > the need to "clean up the remaining Debian bits"?
>> 
>> Neat.  For me the answer is, I don't know :)  I thought with guix system
>> init you had to do a bunch of partitiony type things?  Certainly if I
>> had a blank scratch space I could do that.
>> 
>> In hindsight it is something of a miracle that "reconfigure" worked on a
>> previously non-GuixSD system.  Strange.  I will accept it though :)
>> 
>> Andy
>> 
>
> Okay, you have to provide a config.scm and you have to have root or
> sudo, in which case you already have the rights to cause total
> destruction on the machine... but should we point that out that it is
> possible to "accidentally" run a succesful guix system init on a system
> which is let's say Debian or whatever, ever if it is just for curiosity
> of discovery?

I think we should. Because an inadvertent 'guix system init' can easily
produce a machine that no longer boots.

> And why would we point it out?

It is useful. Here are some examples ...

1) Before installing GuixSD, our users may well install Guix to check it
   out (I did with both with nix/nixOS and guix/GuixSD). Once they do,
   'guix system init' is easier than USB install because ...

   - it's quicker.

   - they don't have to find a USB key.

   - they can do install steps (edit config.scm, fdisk, etc) on a fully
 functional OS rather than a less functional install image.

   - If installing a server, they can do it all over ssh. This is way
 easier than plugging in a USB key + monitor or fiddling around with
 remote management tools.

2) As Andy has demonstrated, 'Guix Binary install + guix system init'
   works in situations where the USB install may be inconvenient or may
   not work.

3) In my experience (several headless server installs over the last
   year, including testing the graphical USB installer), I have found
   that 'Guix Binary install + guix system init' is more convenient. A
   simple makefile (attached) makes it even more convenient.

Note: None of this meant as a criticism of our USB install, or the
upcoming Graphical GuixSD installer.

> Is there any harm in it or do we trust sudo/root users to know that
> this can happen?

In my experience, the most likely "bad outcome" with 'guix system init'
is that the system hangs because of a problem with the
grub-configuration or file-system "device" fields. See for example ...

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23072

If a user experiences this they may be better off with the USB install
since can reboot from USB and try again. So maybe we should recommend
making a "GuixSD USB rescue key" before trying 'guix system init' for
the first time ;-)



makefile
Description: Binary data

Re: how to "install" guixsd on a digitalocean server

[myglc2]

On 04/07/2017 at 14:07 Andy Wingo writes:

> Hi,
>
> I just "installed" GuixSD on a DigitalOcean droplet.  You can't actually
> install GuixSD; you have to mutate an existing installation into
> GuixSD.  But fine.
[...]

Hi Andy,

I upgraded Debian to GuixSD on a physical server in a similar way ...

https://lists.gnu.org/archive/html/guix-devel/2016-03/msg00354.html

... but I used 'guix system init' instead of 'guix system reconfigure'.

I wonder, could that approach have been used in this situation to avoid
the need to "clean up the remaining Debian bits"?

Re: cuirass question

[myglc2]

> Cuirass is a piece of software, which is hosted on
> https://notabug.org/mthl/cuirass.  The “(gnu services cuirass)” module
> only provides Guix services to make it easier to configure Cuirass on
> GuixSD.

Hmm... Now why wasn't that obvious to me? Thanks Ricardo ;-)

cuirass question

[myglc2]

In "6.2.7.15 Continuous Integration" there is a reference to
'(https://notabug.org/mthl/cuirass)' but the doc is all for of GuixSD
'(gnu services cuirass)'. Also
git://git.sv.gnu.org/guix/maintenance.git/hydra/bayfront.scm uses GuixSD
'(gnu services cuirass)'.

This left me wondering... has '(https://notabug.org/mthl/cuirass)' been
replaced by (gnu servies cuirass) on GuixSD?

If so, should the reference to '(https://notabug.org/mthl/cuirass)' be
removed?

TIA - George

cuirass question

[myglc2]

In "6.2.7.15 Continuous Integration" there is a reference to
'(https://notabug.org/mthl/cuirass)' but the doc is for GuixSD '(gnu
services cuirass)'.

And git://git.sv.gnu.org/guix/maintenance.git/hydra/bayfront.scm also
uses GuixSD '(gnu services cuirass)'.

So here is the question... Is it correct to assume that the primary
cuirass way forward is (gnu servies cuirass) on GuixSD?

If so, should the reference to '(https://notabug.org/mthl/cuirass)' be
removed?

TIA - George

Re: Non-graphical GRUB configuration

[myglc2]

On 04/06/2017 at 11:18 Leo Famulari writes:

> On Wed, Apr 05, 2017 at 04:43:32PM -0400, myglc2 wrote:
>> > ... you won't get '--unit=0' unless you specify (serial-unit 0) in your
>> > GuixSD configuration. However, GRUB defaults to '0', according to its
>> > manual.
>> 
>> Yes I noticed. I was operating on the hope that less would be more ;-)
>
> I decided against hard-coding the current GRUB defaults into this code.
> I'd rather take them from GRUB at run-time, and accept the upstream
> changes as they come. Plus, we won't have to update our code as often :)

Nice!

Re: 01/02: gnu: Add emacs-ag.

[myglc2]

On 01/18/2017 at 10:02 Alex Kost writes:

> alezost pushed a commit to branch master
> in repository guix.
>
> commit cf006d2e738f473e7fb630b566e04c4872fa204b
> Author: Christopher Baines 
> Date:   Tue Jan 17 20:07:06 2017 +

Hi Alex & Christopher,

I installed emacs-ag but was a bit disappointed there was no INFO. I see
it can be built from ...

/gnu/store/...emacs-ag-0.47/share/emacs/site-lisp/guix.d/ag-0.47/docs

... using python-sphinx + texinfo. Is there any interest on your part(s)
in adding INFO to the package? If not, I was wondering how one might add
it. Would it be something like ...

(native-inputs ;; so we can build INFO doc
 `(("python-sphinx" ,python-sphinx)
   ("texinfo" ,texinfo)))

... plus fiddle with #:phases? Or is there a better way? TIA - George

Re: Non-graphical GRUB configuration

[myglc2]

On 04/05/2017 at 12:07 Leo Famulari writes:

> On Wed, Apr 05, 2017 at 11:14:06AM -0400, myglc2 wrote:
>> I interpreted your doc to say I should use something like this ...
>> 
>>   (bootloader (grub-configuration (device "/dev/nvme0n1")
>>(serial-speed 115200)
>>(terminal-inputs '(serial console))
>>(terminal-outputs '(console
>
> Right, except...
>
>> ... to produce something like this in my grub config ...
>> 
>> serial --unit=0 --speed=115200
>> terminal_input serial console; terminal_output console
>
> ... you won't get '--unit=0' unless you specify (serial-unit 0) in your
> GuixSD configuration. However, GRUB defaults to '0', according to its
> manual.

Yes I noticed. I was operating on the hope that less would be more ;-)

After following Marius Bakke's advice to revert
dfee7daedb760f1b1d7506829ca31633f4173356 "gnu: bc: Update to 1.07" I can
confirm that this works on an ASRock MT-C224 motherboard over IPMI SOL.

Please let me know if there is anything else you need me to test.

- George

Re: Non-graphical GRUB configuration

[myglc2]

On 04/05/2017 at 11:59 Leo Famulari writes:

> Questions:
>
> 1) In general, is this approach okay?

Hi Leo,

This LGTM, but I was unable to test it because my 'system build' hangs
as reported in bug#26370. Running your commit produced a similar hang
but I think it is not caused by your changes so I reported against the
origin/master commit.

I interpreted your doc to say I should use something like this ...

  (bootloader (grub-configuration (device "/dev/nvme0n1")
  (serial-speed 115200)
  (terminal-inputs '(serial console))
  (terminal-outputs '(console


... to produce something like this in my grub config ...

serial --unit=0 --speed=115200
terminal_input serial console; terminal_output console

Does that look right?

If so, it may be nice to include an example like this in the doc.

Once I get the system build working I will test further.

TIA - George

Re: Non-graphical GRUB configuration

[myglc2]

On 04/02/2017 at 22:13 Leo Famulari writes:

> On Sun, Apr 02, 2017 at 05:06:20PM -0400, Leo Famulari wrote:
>> Based on the GRUB manual [0], how about this plan?
>>
>> We'd add these fields to (grub-configuration):
>
> [...]
>
> NixOS has the user provide a string:
>
> https://nixos.org/nixos/manual/options.html#opt-boot.loader.grub.extraConfig
>
> It is much simpler than my plan...

I agree this is also workable. It actually is more flexible since it
allows access to all grub config features.

If you go this way, the guix doc should point the user to the relevant
grub doc. Since one needs to install grub in order to read the grub doc
in guix, it might be helpful for the guix doc to mention that as well.

HTH - George

Re: Non-graphical GRUB configuration

[myglc2]

On 04/02/2017 at 21:06 Leo Famulari writes:

> On Sun, Apr 02, 2017 at 12:31:19PM -0400, myglc2 wrote:
>> I gather you are focused on KVM deployment, so this may be off-
>> topic. But FWIW, the patch that I use to run GRUB menus both locally on
>> the console and over IPMI SOL (serial over LAN) on an headless ASRock
>> server (MT-c224 w/ ASPEED 2300 BMC controller) is attached below.
>
> I think we can make it work on KVM and bare metal in the same commit :)
>
>> The important point is that 'terminal_output console' displays grub
>> menus on _both_ the local console and via serial ... but ... grub does
>> not receive the serial inputs ... unless ... 'terminal_input serial
>> console' is also specified.
>
> Okay, but your diff only selects the "console" terminal_output. Is that
> because the native console is accessed over the serial line? Or should
> it be 'terminal_output console serial'?

I grant you it seems odd, but with 'terminal_output console serial', the
grub output on the serial line is "garbled" in the sense that each line
is "doubled". Meanwhile, the appearance on the local console (on the
attached VGA display) is fine.

I don't know if this behavior is peculiar to this motherboard, or if
this is typical.

>> diff --git a/gnu/system/grub.scm b/gnu/system/grub.scm
>> index 4f9bde6a6..8199f6f0b 100644
>> --- a/gnu/system/grub.scm
>> +++ b/gnu/system/grub.scm
>> @@ -199,7 +199,8 @@ system string---e.g., \"x86_64-linux\"."
>>  insmod vga
>>fi
>>
>> -  terminal_output gfxterm
>> +  serial --unit=0 --speed=115200
>> +  terminal_input serial console; terminal_output console
>>  "
>>  ""))
>>
>
> Based on the GRUB manual [0], how about this plan?
>
> We'd add these fields to (grub-configuration):
>
> terminal-outputs: One or more symbols: console, serial, gfxterm,
> ofconsole, vga_text. Default gfxterm.

Yes

> terminal-inputs: One or more symbols: console, serial, ofconsole,
> at_keyboard,usb_keyboard. Default unset.

Yes

> serial-unit: An integer from {0,1,2,3}, default 0

yes

> serial-port: ??? I don't know which values are accepted

I don't think this is required.

> serial-speed: GRUB default is 9600. Should this be an arbitrary
> integer, or should we offer a list of values?

An integer is probably OK.

> serial-word: An integer from {5,6,7,8}, default 8
> serial-stop: An integer from {1,2}, default 1
> serial-parity: A symbol from {no, odd, even}, default no

I think you can skip these.

> They would correspond to the GRUB configuration keys
> GRUB_TERMINAL_OUTPUT, GRUB_TERMINAL_INPUT, and GRUB_SERIAL_COMMAND,
> respectively. [0]
>
> If 'terminal-inputs' or 'serial-*' are unset, we do what we do now:
> nothing. If 'terminal-outputs' is unset, we also do the same thing we
> now, which is set it to gfxterm.
>
> If any of them are set, we'd insert the corresponding text into the
> generated grub.cfg.
>
> If terminal-outputs does not include the symbol 'gfxterm', we'd disable
> the "setup_gfxterm" function.
>
> We can use the `grub-script-check` program to check the syntax of the
> generated grub.cfg.
>
> [0]
> https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html
> https://www.gnu.org/software/grub/manual/html_node/terminal_005foutput.html
> https://www.gnu.org/software/grub/manual/html_node/terminal_005finput.html
> https://www.gnu.org/software/grub/manual/html_node/serial.html

This seems very fine to me! Thanks - George

Re: question about pty, agetty for an intermediate virtual server image

[myglc2]

On 04/01/2017 at 16:29 Leo Famulari writes:

> On Sat, Apr 01, 2017 at 07:27:40AM +, ng0 wrote:
>> Leo Famulari transcribed 2.8K bytes:
>> > And you will probably want a non-graphical GRUB menu as well (this
>> > should be parameterized eventually...):
>> 
>> Yeah, that would be useful as it is not uncommon for servers.
>
> Here's a patch that works in my tests:
>
> https://bugs.gnu.org/26334

Hi Leo,

I gather you are focused on KVM deployment, so this may be off-
topic. But FWIW, the patch that I use to run GRUB menus both locally on
the console and over IPMI SOL (serial over LAN) on an headless ASRock
server (MT-c224 w/ ASPEED 2300 BMC controller) is attached below.

The important point is that 'terminal_output console' displays grub
menus on _both_ the local console and via serial ... but ... grub does
not receive the serial inputs ... unless ... 'terminal_input serial
console' is also specified.

I don't recall the exact rationale for 'serial --unit=0 --speed=115200',
but I am pretty sure it was needed. I can check on that if you like.

So... it would sure be "nice" if you could expand your patch to also
support this use case.

Best, George

diff --git a/gnu/system/grub.scm b/gnu/system/grub.scm
index 4f9bde6a6..8199f6f0b 100644
--- a/gnu/system/grub.scm
+++ b/gnu/system/grub.scm
@@ -199,7 +199,8 @@ system string---e.g., \"x86_64-linux\"."
 insmod vga
   fi
 
-  terminal_output gfxterm
+  serial --unit=0 --speed=115200
+  terminal_input serial console; terminal_output console
 "
 ""))
 

Re: [V2 PATCH 1/1] services: Add agetty service.

[myglc2]

On 02/17/2017 at 17:59 Leo Famulari writes:

> On Fri, Feb 17, 2017 at 01:35:44PM -0500, myglc2 wrote:
>> Hi Leo,
>> 
>> I think that what you have is great. With this in my system config ...
>> 
>> (agetty-service (agetty-configuration
>>   (tty "ttyS1")
>>   (baud-rate "115200")))
>>
>> ... it works painlessly on a headless GuixSD server over IPMI.  I think
>> you can put a brief example in the doc, refer the user to the code and
>> the agetty man page for more info, and declare victory.
>
> Awesome!
>
> Veering off-topic, I wonder what created that device node /dev/ttyS1? I
> have 32 of them, but (gnu build linux-boot) appears to only create the
> first one:
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/linux-boot.scm#n160

I found the serial line on my server by doing ...

g1@g1 ~$ dmesg | grep tty
[0.00] console [tty0] enabled
[2.192386] 00:07: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 
16550A

... but linux-boot.scm only specifies ttyS0 ...

 160;; Serial line.  
 161(mknod (scope "dev/ttyS0") 'char-special #o660  
 162   (device-number 4 64))  

... but gnu/packages/linux-libre-4.9-i686.conf has ...

CONFIG_SND_SERIAL_U16550=m

... so maybe the kernel probes for and finds the UART.

>> But let me digress a bit on this topic. What if, in situations like
>> this, Guix provided an easy way to export the "native config" generated
>> by Guix?
>> 
>> Then we could tell the user ...
>> 
>> 1) If you want to know exactly what we are doing, export the native
>> config and read the native doc.
>> 
>> 2) If you want features we don't support, export the native config, read
>> the doc, modify it, and feed it into the "native config hatch."
>> 
>> With this approach, we could implement and document only "key features"
>> with a clear conscience.  When we haven't implemented a feature the user
>> needs they will be no worse off that they were before. In fact, they
>> will usually be ahead, because Guix has taken care of the general
>> requirements and provided a sound starting point for a native config.
>
> An interesting idea! I guess the implementation would vary based on
> services that use a configuration file (like nginx) and those that are
> configured on the command-line (like agetty). But I'm still finding my
> way around services, in general, so I'm not sure.

Agreed. Ideally there would be a strategy and reusable modules that
supports either approach, or a mix. Then maybe this would lighten the
effort required for each service and help regularize these interfaces.

Re: [V2 PATCH 1/1] services: Add agetty service.

[myglc2]

On 02/16/2017 at 02:06 Leo Famulari writes:

> On Tue, Feb 14, 2017 at 07:24:17PM -0500, Leo Famulari wrote:
>> This 'extra' is a time-saving kludge. I'll add fields for all of
>> agetty's configuration options once I'm satisfied that the service works
>> on GuixSD.
>
> Here's a patch that exposes (almost all) of agetty's command-line
> options.
>
> Is this the right way? Or would we rather wrap only the most
> commonly-used options, and leave an "escape hatch" as in the first
> version of the patch? If so, which options should we expose in Scheme?
>
> I'll wait for feedback before writing the documentation.

Hi Leo,

I think that what you have is great. With this in my system config ...

(agetty-service (agetty-configuration
 (tty "ttyS1")
 (baud-rate "115200")))

... it works painlessly on a headless GuixSD server over IPMI.  I think
you can put a brief example in the doc, refer the user to the code and
the agetty man page for more info, and declare victory.

But let me digress a bit on this topic. What if, in situations like
this, Guix provided an easy way to export the "native config" generated
by Guix?

Then we could tell the user ...

1) If you want to know exactly what we are doing, export the native
config and read the native doc.

2) If you want features we don't support, export the native config, read
the doc, modify it, and feed it into the "native config hatch."

With this approach, we could implement and document only "key features"
with a clear conscience.  When we haven't implemented a feature the user
needs they will be no worse off that they were before. In fact, they
will usually be ahead, because Guix has taken care of the general
requirements and provided a sound starting point for a native config.

Re: [PATCH 1/1] services: Add agetty service.

[myglc2]

On 02/14/2017 at 19:24 Leo Famulari writes:

> On Tue, Feb 14, 2017 at 07:12:44PM -0500, Leo Famulari wrote:
>> * gnu/services/base.scm (): New record type.
>> (agetty-shepherd-service, agetty-service): New procedures.
>> (agetty-service-type): New variable.
>
> My intention is to get a serial tty, for example /dev/ttyS0, so that I
> can install GuixSD on a device that lacks any graphical display
> interfaces:
[...
> However, it doesn't work when I boot my physical device with the same
> installer image.
>
> When I connect to my physical device using the Keyspan USA-19H
> serial-to-USB converter, I can watch the system boot, but Shepherd never
> reports that the 'term-ttyS0' service has started, and I never see the
> MOTD or login prompt.
>
> Any advice or debugging ideas?

Hi Leo,

I'm very happy to see you doing this. I got agetty working on IPMI
serial over LAN (SOL) on a ASRock MT-C224 motherboard as follows:

I made these changes in GRUB.scm ...

diff --git a/gnu/system/grub.scm b/gnu/system/grub.scm
index b18b8be6d..e68cec7f4 100644
--- a/gnu/system/grub.scm
+++ b/gnu/system/grub.scm
@@ -197,7 +197,8 @@ system string---e.g., \"x86_64-linux\"."
 insmod efi_uga
   fi
 
-  terminal_output gfxterm
+  serial --unit=0 --speed=115200
+  terminal_input serial console; terminal_output console
 "
 ""))
 
I found the serial port like so ...

dmesg | grep tty
[0.00] Command line: 
BOOT_IMAGE=/gnu/store/ksigckplbh1669iy62pqa17j7sid9vmw-linux-libre-4.9.9/bzImage
 --root=/dev/md3 --system=/gnu/store/ssh2kjijcg7fvfaafmn4jj0chkmzaxzr-system 
--load=/gnu/store/ssh2kjijcg7fvfaafmn4jj0chkmzaxzr-system/boot 
console=ttyS1,115200
[0.00] Kernel command line: 
BOOT_IMAGE=/gnu/store/ksigckplbh1669iy62pqa17j7sid9vmw-linux-libre-4.9.9/bzImage
 --root=/dev/md3 --system=/gnu/store/ssh2kjijcg7fvfaafmn4jj0chkmzaxzr-system 
--load=/gnu/store/ssh2kjijcg7fvfaafmn4jj0chkmzaxzr-system/boot 
console=ttyS1,115200
[0.00] console [ttyS1] enabled
[3.622999] 00:07: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200)
is a 16550A

... I installed the shadow package and I did this ...

agetty ttyS1 -l /root/.guix-profile/bin/login &

And I can log in, run screen and run emacs.

FWIW, there is no mention in sheperd.log of the serial port.

HTH, George

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/14/2017 at 17:43 Maxim Cournoyer writes:

> Hi George and Ludovic,
>
> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>>
>> ‘guix pull’ preserves your (guix config) module.  So if the ‘guix’ you
>> run was configured to use /etc, it’ll keep using that; if it was
>> configured to use /usr/local/etc, it’ll keep using that.

Could you please clarify? Does it do this when invoked by 'guix pull' or
by './pre-inst-env guix pull', or in both cases?

>> If you run “./pre-inst-env guix pull”, then you end up using (guix
>> config) from your build tree, which is configured to use /usr/local/etc
>> by default.  That’s probably what happened, no?

I don't use './pre-inst-env' so I don't think so. But maybe I did on the
system from which I did 'system init' to create this one. Would that
explain it?

[...]

> George, as an alternative, you might be interested in declaring the extra
> key in your system's config.scm file [0].

Great point, thank you Maxim.

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/14/2017 at 16:29 Ludovic Courtès writes:

> myglc2 <myg...@gmail.com> skribis:
>
>> g1@g1 ~/src/guix [env]$ ./configure --sysconfdir=/etc
>>
>> ... it gave this message ...
>>
>> [...]
>> checking the current installation's localstatedir... /var
>> configure: error: chosen localstatedir '/usr/local/var' does not match that 
>> of the existing installation '/var'
>> Installing may corrupt /gnu/store!
>> Use './configure --localstatedir=/var'.
>>
>> ... which left me wondering if it meant ...
>
> Do like it says.  :-)
>
> That is, it noticed that your system has /var/guix/db and that you were
> configuring with a different state directory, which is a mistake you’d
> rather avoid (see the bits about localstatedir at
> <https://www.gnu.org/software/guix/manual/html_node/Requirements.html>).
>
> So:
>
>   ./configure --localstatedir=/var --sysconfdir=/etc -C

OK, thank you. That works :-) Many thanks! 

FWIW, here are a couple patches that would make this clearer.

diff --git a/doc/guix.texi b/doc/guix.texi
index 6cdb5e592..60cc073a0 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -582,12 +582,13 @@ C++11 standard.
 
 @cindex state directory
 When configuring Guix on a system that already has a Guix installation,
-be sure to specify the same state directory as the existing installation
-using the @code{--localstatedir} option of the @command{configure}
-script (@pxref{Directory Variables, @code{localstatedir},, standards,
-GNU Coding Standards}).  The @command{configure} script protects against
-unintended misconfiguration of @var{localstatedir} so you do not
-inadvertently corrupt your store (@pxref{The Store}).
+you should specify the same state directory as the existing
+installation, (typically @code{/var} on GuixSD, and @code{???} on Guix
+installations) using the @code{--localstatedir} option of the
+@command{configure} script (@pxref{Directory Variables,
+@code{localstatedir},, standards, GNU Coding Standards}).  If in doubt,
+leave it unspecified and the @command{configure} script will recommend
+the correct value.
 
 @cindex Nix, compatibility
 When a working installation of @url{http://nixos.org/nix/, the Nix package


diff --git a/m4/guix.m4 b/m4/guix.m4
index 663059841..25de46516 100644
--- a/m4/guix.m4
+++ b/m4/guix.m4
@@ -357,10 +357,9 @@ AC_DEFUN([GUIX_CHECK_LOCALSTATEDIR], [
   case "$localstatedir" in
 NONE|\${prefix}*)
   # User kept the default value---i.e., did not pass '--localstatedir'.
-  AC_MSG_ERROR([chosen localstatedir '$guix_localstatedir' does not 
match \
-that of the existing installation '$guix_cv_current_localstatedir'
-Installing may corrupt $storedir!
-Use './configure --localstatedir=$guix_cv_current_localstatedir'.])
+  AC_MSG_ERROR([The default localstatedir '$guix_localstatedir' does 
not match \
+that of the existing installation, which is '$guix_cv_current_localstatedir'
+so you should add './configure 
--localstatedir=$guix_cv_current_localstatedir'.])
   ;;
 *)
   # User passed an explicit '--localstatedir'.  Assume they know what

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/14/2017 at 09:20 Ludovic Courtès writes:

> myglc2 <myg...@gmail.com> skribis:
>
>> On 02/13/2017 at 14:05 Ludovic Courtès writes:
>>
>>> Hi Maxim,
>>>
>>> Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
>>>
>>>> l...@gnu.org (Ludovic Courtès) writes:
>>>>
>>>>> myglc2 <myg...@gmail.com> skribis:
>>>>>
>>>>>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>>>>>> directory other than this one?  What does:
>>>>>>>
>>>>>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>>>>>
>>>>>>> print?
>>>>
>>>> I remember being equally confused by not finding the key imported in the
>>>> /etc/guix/acl file, as per the manual.
>>>>
>>>> On my GuixSD system, the value of %config-directory is:
>>>> "/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
>>>> contain multiple times the public key of Bayfront, which must be due
>>>> to passed attempts at adding the Bayfront key using "guix archive".
>>>
>>> I suppose that’s because you installed Guix in /usr/local at some point?
>>>
>>> myglc2, are you in a similar situation?
>>
>> Hmm, apparently so ...
>>
>> guile -c '(use-modules (guix config)) (pk %config-directory)'
>>
>> ... returns ...
>>
>> ;;; ("/etc/guix")
>>
>> ... but in the REPL I get ...
>>
>> (use-modules (guix config))
>> (pk %config-directory)
>>
>> => "/usr/local/etc/guix"
>>
>> ... /usr/local/etc/guix/acl is the only file under /usr and I didn't
>> install in /usr/local.  The system was created with 'guix init' on a
>> previous GuixSD system and has since been modified by 'guix reconfigure'
>> and 'guix package', running either from 'git pull' or git checkout.
>>
>> I don't know if this is related, but I see that guix config.log
>> (attached) has ...
>>
>> guix_sysconfdir='/usr/local/etc'
>>
>> Also, you may recall that, on the previous system, we had to make
>> /usr/local/sbin/guix-register a symlink to guix-register to get 'guix
>> init' to work ...
>
> Right.
>
> ‘guix pull’ preserves your (guix config) module.  So if the ‘guix’ you
> run was configured to use /etc, it’ll keep using that; if it was
> configured to use /usr/local/etc, it’ll keep using that.
>
> If you run “./pre-inst-env guix pull”, then you end up using (guix
> config) from your build tree, which is configured to use /usr/local/etc
> by default.  That’s probably what happened, no?
>
> To fix it, you can either run:
>
>   rm -f ~/.config/guix/latest && guix pull
>
> or just do:
>
>   ./configure --sysconfdir=/etc
>
> in your checkout.

Hi Ludo,

I tried both approaches but ...

sudo guix archive --authorize < bayfront.guixsd.org.pub

... continues to add the key to /usr/local/etc/guix/acl

:-(

Like Maxim, I usually run from the git checkout with
/home/g1/.config/guix/latest pointing to the checkout.

But after ...

rm -f ~/.config/guix/latest && guix pull

... I confirmed ...

stat ~/.config/guix/latest | grep File
  File: '/home/g1/.config/guix/latest' ->
  '/gnu/store/8ag16yziir9gl7rq02vswr31ip4k33ab-guix-latest'

I have attached the config log again in hopes it might provide
insight. I can also provide shell logs if they are of interest.


Also, FWIW, when I did ...

g1@g1 ~/src/guix [env]$ ./configure --sysconfdir=/etc

... it gave this message ...

[...]
checking the current installation's localstatedir... /var
configure: error: chosen localstatedir '/usr/local/var' does not match that of 
the existing installation '/var'
Installing may corrupt /gnu/store!
Use './configure --localstatedir=/var'.

... which left me wondering if it meant ...

1) it failed, or

2) it worked, but results would be unpredictable

So maybe this message should be made more clear.



config.log.gz
Description: Binary data

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/13/2017 at 14:05 Ludovic Courtès writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> myglc2 <myg...@gmail.com> skribis:
>>>
>>>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>>>
>>> [...]
>>>
>>>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>>>> directory other than this one?  What does:
>>>>>
>>>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>>>
>>>>> print?
>>
>> I remember being equally confused by not finding the key imported in the
>> /etc/guix/acl file, as per the manual.
>>
>> On my GuixSD system, the value of %config-directory is:
>> "/usr/local/etc/guix", and the file "/usr/local/etc/guix/acl" does
>> contain multiple times the public key of Bayfront, which must be due
>> to passed attempts at adding the Bayfront key using "guix archive".
>
> I suppose that’s because you installed Guix in /usr/local at some point?
>
> myglc2, are you in a similar situation?

Hmm, apparently so ...

guile -c '(use-modules (guix config)) (pk %config-directory)'

... returns ...

;;; ("/etc/guix")

... but in the REPL I get ...

(use-modules (guix config))
(pk %config-directory)

=> "/usr/local/etc/guix"

... /usr/local/etc/guix/acl is the only file under /usr and I didn't
install in /usr/local.  The system was created with 'guix init' on a
previous GuixSD system and has since been modified by 'guix reconfigure'
and 'guix package', running either from 'git pull' or git checkout.

I don't know if this is related, but I see that guix config.log
(attached) has ...

guix_sysconfdir='/usr/local/etc'

Also, you may recall that, on the previous system, we had to make
/usr/local/sbin/guix-register a symlink to guix-register to get 'guix
init' to work ...

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25444

HTH, - George



config.log.gz
Description: Binary data

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/11/2017 at 15:32 Ludovic Courtès writes:

> myglc2 <myg...@gmail.com> skribis:
>
>> On 02/09/2017 at 17:36 Ludovic Courtès writes:
>
> [...]
>
>>> Could it be that the ‘guix archive’ you ran uses a configuration
>>> directory other than this one?  What does:
>>>
>>>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>>>
>>> print?
>>
>> Thanks Ludo ...
>>
>> g1@g1 ~/src/guix [env]$ guile -c '(use-modules (guix config)) (pk 
>> %config-directory)'
>>
>> ;;; ("/etc/guix")
>
> Hmm so that should definitely be writing to /etc/guix/acl.  Maybe you
> could strace it to see what’s happening?

Thanks. Seems like a lot of "No such file or directory" messages.  I
have attached the installed packages (user and system) & a compressed
strace log.  HTH. - George


g1@g1 ~/src$ guix package -I
strace  4.7 out /gnu/store/1iz5kyphiv1hbmbfpmn92f4ykjrxza5w-strace-4.7
icecat  45.5.1-gnu1 out 
/gnu/store/4x3vwpm5lc92ks0pklvnizd5gh1z9zzx-icecat-45.5.1-gnu1
conkeror1.0.3   out 
/gnu/store/nbq3lidc743m2dqn0mx5c98x7cy82841-conkeror-1.0.3
unzip   6.0 out /gnu/store/g4r98y5lrnvri4bi5x8ghkallxng323y-unzip-6.0
curl7.50.3  out /gnu/store/73ypa3smnqcj9pwnay42mfn07g00yjly-curl-7.50.3
xev 1.2.2   out /gnu/store/x95xnxh26c64p9g8w1382c91wf8bvhbi-xev-1.2.2
r-hmisc 4.0-2   out 
/gnu/store/8qi4v3ayrpy6rz7s21gw69phc4f0i5iq-r-hmisc-4.0-2
nss-certs   3.27.1  out 
/gnu/store/nd946vlingp0ff63y18sqmv823cday9w-nss-certs-3.27.1
emacs-ess   16.04   out 
/gnu/store/8pf9wjfhqpsk1dfv85wvyhdzxa39rvim-emacs-ess-16.04
r   3.3.2   out /gnu/store/ckawwykzravj0kyxxm8mhf32ar6qk6al-r-3.3.2
graphviz2.38.0  out 
/gnu/store/s9haf97nzfcj02ph1y5kkcm7aqy64y04-graphviz-2.38.0
isync   1.2.1   out /gnu/store/kwmsrdnq72j5241qdzylfylkrshylf7k-isync-1.2.1
mu  0.9.18  out /gnu/store/nkafv9ry3nxf1p44azzslalvlafjbvzc-mu-0.9.18
notmuch 0.23.5  out 
/gnu/store/c98yr3va54fr0ppp3cn3klyiz1kvvb8s-notmuch-0.23.5
aspell-dict-en  2016.11.20-0out 
/gnu/store/r6sk12qgms7g7rv5idg64xzbms80n74d-aspell-dict-en-2016.11.20-0
tree1.7.0   out /gnu/store/w17yydrmw1sndzad7yh1pvsjnixvlqh6-tree-1.7.0
mosh1.2.6   out /gnu/store/9l555sgh8gl7nsz8fr444f1lwmp8whir-mosh-1.2.6

g1@g1 ~/src$ guix package --list-installed --profile=/run/current-system/profile
shepherd0.3.2   out 
/gnu/store/qfax650mynyx9x8wm8lq8w7fp82kkfc6-shepherd-0.3.2
lzip1.16out /gnu/store/41q4ln3k4f9awmyrsmazv84mrwc1i5xq-lzip-1.16
xz  5.2.2   out /gnu/store/4yg6q1kp856m68arkpqc85hqgbffhpxf-xz-5.2.2
bzip2   1.0.6   out /gnu/store/d5nscny560slzpljixqzim6b8ms7hhv2-bzip2-1.0.6
gzip1.8 out /gnu/store/ginbign0swn8h69k3z4fy18r8pwq3rqx-gzip-1.8
tar 1.29out /gnu/store/9l52vcmb1ambc3ypf7nxn38ac0976yyf-tar-1.29
gawk4.1.4   out /gnu/store/k03y1lfaj1xw0d7j2lxdil8ii5c67fdy-gawk-4.1.4
patch   2.7.5   out /gnu/store/fs49m4pvdf2v7kixf9sls8nmhvh40ajl-patch-2.7.5
diffutils   3.5 out 
/gnu/store/g0lyirlbqday5n2n0n6lh6nmdxi8a45z-diffutils-3.5
sed 4.2.2   out /gnu/store/9761yfpvyr1fcpjhry8pgb3f0k6kj8n4-sed-4.2.2
grep2.25out /gnu/store/hb301wl5s7352vbn1vds85dhy32n0hkw-grep-2.25
findutils   4.6.0   out 
/gnu/store/cz7dl482c1j6j5s4vh1pll4lzdl5sl6b-findutils-4.6.0
coreutils   8.25out 
/gnu/store/9xfn6q7cxqxaxsv6kgiic9iygl2iv2ci-coreutils-8.25
bash4.4.0   out /gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0
guile   2.0.12  out /gnu/store/6slzn4ixcjlhy3av3biglqfli9pwxcn9-guile-2.0.12
bash-completion 2.4 out 
/gnu/store/nwwbi0b9r7ssw6z76pn6l4ags2w8d37q-bash-completion-2.4
kbd 2.0.3   out /gnu/store/xd59ar5n2dhgc5szbgryhwchpry8dn6g-kbd-2.0.3
e2fsprogs   1.42.13 out 
/gnu/store/k1lp8v81m07aykvpn5ky2dqs2nckw804-e2fsprogs-1.42.13
eudev   3.2 out /gnu/store/ji6b6zhk7l3y7vbjhx7kpnb9v7hlbc6v-eudev-3.2
kmod23  out /gnu/store/vzlgcmkys1dpw238wq7qb9klb4g84p5l-kmod-23
sudo1.8.19p1out 
/gnu/store/2j4rpb610jr1fr5fm5m0p6dy80zw11dn-sudo-1.8.19p1
info-reader 6.3 out 
/gnu/store/z2awzispx2fhmbpv0rn1g7bsfz56gy85-info-reader-6.3
man-db  2.7.5   out /gnu/store/vmxcccvhlfyc64x5772cp3wfwb57a3pp-man-db-2.7.5
net-tools   1.60out 
/gnu/store/s6p28awc14di0r1w3d6s3a90cj0hyzyi-net-tools-1.60
iproute24.9.0   out 
/gnu/store/v963yg0fiqv16xbnd38390qzfxzisyl3-iproute2-4.9.0
rfkill  0.5 out /gnu/store/sjs8rhamynivkvk7sx5zh4596zwrds09-rfkill-0.5
wireless-tools  30.pre9 out 
/gnu/store/9fmsh9i7vwnvn8swkdf1whyl9ww52x7n-wireless-tools-30.pre9
iw  4.9 out /gnu/store/v7r8v0v7bm1hgldwhq5wi8hbh69hjcda-iw-4.9
isc-dhcp4.3.5   out 
/gnu/store/94l9y9sch5p6lblbhzsxxbixwdzg9gzj-isc-dhcp-4.3.5
inetutils   1.9.4   out 
/gnu/st

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/09/2017 at 17:36 Ludovic Courtès writes:

> Hi!
>
> myglc2 <myg...@gmail.com> skribis:
>
>> Hi Ludo, I have a couple questions. I autorized bayfront like so ...
>>
>> g1@g1 ~/src$ cat bayfront.guixsd.org.pub
>>  (public-key 
>>   (ecc 
>>(curve Ed25519)
>>(q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))
>>
>> g1@g1 ~/src$ sudo guix archive --authorize < bayfront.guixsd.org.pub
>>
>> ... and I read this ...
>>
>> 3.7 Invoking ‘guix archive’
>> ===
>> [...]
>>  The list of authorized keys is kept in the human-editable file
>>  ‘/etc/guix/acl’.  The file contains “advanced-format s-expressions”
>>  (http://people.csail.mit.edu/rivest/Sexp.txt) and is structured as
>>  an access-control list in the Simple Public-Key Infrastructure
>>  (SPKI) (http://theworld.com/~cme/spki.txt).
>>
>> ... so I expected to find the bayfront key here ...
>
> [...]
>
>> ... but no. Where did it go?
>
> Could it be that the ‘guix archive’ you ran uses a configuration
> directory other than this one?  What does:
>
>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>
> print?

Thanks Ludo ...

g1@g1 ~/src/guix [env]$ guile -c '(use-modules (guix config)) (pk 
%config-directory)'

;;; ("/etc/guix")

I'm Running git checkout ...

g1@g1 ~/src/guix [env]$ git -C ~/.config/guix/latest log -n 1 --oneline
e1a65ae57 doc: Fix typos.

g1@g1 ~/src/guix [env]$ stat ~/.config/guix/latest | grep File
  File: '/home/g1/.config/guix/latest' -> '../../src/guix'

>> Also you recommended ...
>>
>>>   guix challenge gdk-pixbuf \
>>> --substitute-urls="https://mirror.hydra.gnu.org 
>>> https://bayfront.guixsd.org;
>>
>> ... which I tried _before_ I had authorized bayfront. I was surprised that it
>> worked before authorization. Should it?
>
> Yes.  It is not actually importing the archives into your store, only
> looking at the content hashes that the servers advertise, so there is no
> risk here and no requirement to authenticate.

Oh DUH! Of course. Thanks! - George

Re: Archive authentication & ‘guix challenge’

[myglc2]

On 02/09/2017 at 17:36 Ludovic Courtès writes:

> Hi!
>
> myglc2 <myg...@gmail.com> skribis:
>
>> Hi Ludo, I have a couple questions. I autorized bayfront like so ...
>>
>> g1@g1 ~/src$ cat bayfront.guixsd.org.pub
>>  (public-key 
>>   (ecc 
>>(curve Ed25519)
>>(q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))
>>
>> g1@g1 ~/src$ sudo guix archive --authorize < bayfront.guixsd.org.pub
>>
>> ... and I read this ...
>>
>> 3.7 Invoking ‘guix archive’
>> ===
>> [...]
>>  The list of authorized keys is kept in the human-editable file
>>  ‘/etc/guix/acl’.  The file contains “advanced-format s-expressions”
>>  (http://people.csail.mit.edu/rivest/Sexp.txt) and is structured as
>>  an access-control list in the Simple Public-Key Infrastructure
>>  (SPKI) (http://theworld.com/~cme/spki.txt).
>>
>> ... so I expected to find the bayfront key here ...
>
> [...]
>
>> ... but no. Where did it go?
>
> Could it be that the ‘guix archive’ you ran uses a configuration
> directory other than this one?  What does:
>
>   guile -c '(use-modules (guix config)) (pk %config-directory)'
>
> print?

Thanks Ludo ...

g1@g1 ~/src/guix [env]$ guile -c '(use-modules (guix config)) (pk 
%config-directory)'

;;; ("/etc/guix")

Running from git checkout ...

g1@g1 ~/src/guix [env]$ git -C ~/.config/guix/latest log -n 1 --oneline
e1a65ae57 doc: Fix typos.

g1@g1 ~/src/guix [env]$ stat ~/.config/guix/latest | grep File
  File: '/home/g1/.config/guix/latest' -> '../../src/guix'

>> Also you recommended ...
>>
>>>   guix challenge gdk-pixbuf \
>>> --substitute-urls="https://mirror.hydra.gnu.org 
>>> https://bayfront.guixsd.org;
>>
>> ... which I tried _before_ I had authorized bayfront. I was surprised that it
>> worked before authorization. Should it?
>
> Yes.  It is not actually importing the archives into your store, only
> looking at the content hashes that the servers advertise, so there is no
> risk here and no requirement to authenticate.

Oh DUH! Of course. Thanks! - George

Re: It’s building!

[myglc2]

On 01/12/2017 at 17:10 Ludovic Courtès writes:

> Hello Guix!
>
> Good news: the new machine, bayfront.guixsd.org, is building Guix master
> for x86_64/i686 with Cuirass⁰!
>
> You can get substitutes from https://bayfront.guixsd.org; just authorize
> its key (with ‘guix archive --authorize’), which is:
>
>   (public-key 
>(ecc 
> (curve Ed25519)
> (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))

Hi Ludo, I have a couple questions. I autorized bayfront like so ...

g1@g1 ~/src$ cat bayfront.guixsd.org.pub
 (public-key 
  (ecc 
   (curve Ed25519)
   (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#)))

g1@g1 ~/src$ sudo guix archive --authorize < bayfront.guixsd.org.pub

... and I read this ...

3.7 Invoking ‘guix archive’
===
[...]
 The list of authorized keys is kept in the human-editable file
 ‘/etc/guix/acl’.  The file contains “advanced-format s-expressions”
 (http://people.csail.mit.edu/rivest/Sexp.txt) and is structured as
 an access-control list in the Simple Public-Key Infrastructure
 (SPKI) (http://theworld.com/~cme/spki.txt).

... so I expected to find the bayfront key here ...

g1@g1 ~/src$ sudo cat /etc/guix/acl
(acl 
 (entry 
  (public-key 
   (rsa 
(n 
#00DB1634E3D9DFAC97AE4734DAE968CCB15EE4815C82BDC254883DBB49FE1EF32268E82D4BBE0E35298C481C9DA1551642FAFF05AEC1A60712F1BB4BE7D25D7EFF7A4F89704A5A9AC232870CB9F2476C3B538A0E990A8825DEB73081D317001FB8A188600F2FEF5F5F570E857F3EE4355077A3C3918ED72723A56BA55C466D400658974D7DAD1F6B7B63C192B9C2704D98BBFF1C3BD5B8EF11A8ADC83ACB8FD8E9F1E792FDAD262415D13F2DEE55F330908CFDA9C3C8C32B64F7DD088457D34F445E2E2C83C6D680549DC9B6E6573B89496567204ED285E67A279F2F667080BA941D80D015CE87B0FB6A91A99CECC7D91D2D210B00E4B6E611DA51DB008F1DFE3FCAC6B27393FA781D45F9A15FC7B8785A3E86BA6592B2916CA22CF1E40FC85F85CACA590461154F58F3580B16398908EF32076F411299C28727C94D88B6A618F84DD73AEBED8270BCB6690928CB1BF250C35E1F6BF3B1B30D05BA246ECE8F69D9065DE26F4B3E0D814D70A9C27CB5B7B050C9090590D3A9EF83374F2643E5446FBD39DDB124DBF6DFDAA6D18E2560AD0CBFA11C959C9B7316BF19963A191967054E9FD97DC14D71082B30B1C90A46E8996682474C3BCB51BA0882958897B6DD35E41B5174D0A6BCDE97B89043E95BD1B70DE61DA666893B417196A180005466BC3A742FDF04E89B04460E3E6BC72E7F1B5FEA5B3092FEE551A3C447C12E104E65#)
(e #010001#)
)
   )
  (tag 
   (guix import)
   )
  )
 )


... but no. Where did it go?

Also you recommended ...

>   guix challenge gdk-pixbuf \
> --substitute-urls="https://mirror.hydra.gnu.org 
> https://bayfront.guixsd.org;

... which I tried _before_ I had authorized bayfront. I was surprised that it
worked before authorization. Should it?

TIA - George

Re: Graphical Installer - Call for Testing.

[myglc2]

Oops, herewith the attachment for previous email.

> In my case I want emacs, so I put emacs in my system configs.

Another rationale for installing emacs in the system config is the very
nice emacs-guix tools for package search and config management. It seems
to me that emacs could also be used to create a less emacsen-ish config
manager, if that was desired.



system8.scm
Description: Binary data