Re: New England Guix Meetup Interest?

[Thompson, David]

On Wed, Feb 7, 2024 at 5:46 PM Juliana Sims  wrote:
>
> Hello everyone,
>
> Coming off the wonderful experience of meeting up with a bunch of
> fellow Guixers (Guixs? Guix? what is our demonym?) in person for the
> first time at Guix Days, I would very much like to have similar
> experiences more often. I know there are Paris and London meetups;
> would there be interest in a New England meetup? I am based in Boston
> and know a few other Guix users in the area, but meeting up with even
> more would be great!

I'd possibly attend if there was a meetup. Curious to know if there's
a critical mass. I'm near Worcester but can drive or take commuter
rail to Boston.

- Dave

Re: Why is it acceptable to have digital-ocean-configuration in the Guix?

[Thompson, David]

On Thu, Jan 4, 2024 at 5:34 AM Tomas Volf <~@wolfsden.cz> wrote:
>
> Greetings,
>
> I would like to inquire regarding digital-ocean-configuration type used for
> provisioning DigitalOcean Droplets.  I do not understand why it is acceptable 
> to
> have this type in the source code.  Reading the Free GNU/Linux distributions
> criteria[0] I see this sentence (emphasis mine):
>
> > This means they will include, and *propose*, exclusively free software.
>
> As far as I know DigitalOcean Droplets are not free software (please correct 
> me
> if I am wrong).  I contemplated on this for a bit, and I do not understand why
> it is acceptable.
>
> Would someone be so kind to explain the reason to me?

Perhaps this will help explain why you can't simply call a web service
nonfree: 
https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.en.html

To use a different example: Google doesn't publish the source code for
YouTube. Guix includes the free software yt-dlp program that can talk
to YouTube and download videos. Would you consider this a violation of
the FSDG?

Guix also downloads a lot of source code from GitHub. Is this an issue?

- Dave

Re: ActtivityPub and Haunt

[Thompson, David]

Hi Jonathan,

On Tue, Sep 19, 2023 at 11:48 AM indieterminacy
 wrote:
>
> In wider fediverse news,
>
> The ActivityPub webpage is getting a rejig:
> https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-from-standards-movement-to-grassroots-fedi/3577
>
> Im emailing, as within the technical discourse page is whether the tech
> stack should be moved away from (scheme based) Haunt (which powers
> Guix's website):
> https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-technical-discussion/3578
>
> Naturally, Id be keen on continuing the furrow carved by Christine
> Lemmer-Webber and thought it would be worth seeing if there are any
> Lispers here who would be keen on volunteering, lest the platform goes
> Typescript.
>
> At my end, I consider the benefits to i18n to be a useful synergy:
> https://socialhub.activitypub.rocks/t/activitypub-rocks-portal-technical-discussion/3578/3
>
> If you agree, Id love you contribute your input there.

I'm the creator and maintainer of Haunt. I can't volunteer time to
maintain activitypub.rocks but I can help answer questions about Haunt
and help with bug fixes, patch review, etc. for Haunt itself. Haunt
posts can be written in Markdown, BTW.  You don't have to layer on the
obscurity by using a format like Skribe (even though Skribe is cool.)
I haven't integrated anything i18n related in Haunt itself because I
don't know a lot about it, but Guix being able to add in i18n on top
of what Haunt provides is a good sign that it's workable. I'm totally
open to include built-in i18n features in future releases.

I also understand and sympathize that keeping Haunt will probably be
swimming upstream against the pressure to be more mainstream.  I guess
a positive spin on things is that ActivityPub has succeeded enough to
call attention to all the Scheme that was cleverly snuck in when
Christine was the driving force of the project. It's been a small
point of pride that activitypub.rocks was built with Haunt, so it
would be a bit disappointing to see it go away, but I understand that
whatever is easiest for the volunteers actually doing the work is the
right thing. Scheme is *obviously* better than TypeScript, though. ;)

- Dave

Re: Implementing the guix-dameon in Guile

[Thompson, David]

Hey Christopher and Ludovic,

First, congrats on the NLnet funding! I've wanted to see this project
happen for years so I'm excited to see it finally happening.

On Thu, Sep 14, 2023 at 9:30 AM Ludovic Courtès  wrote:
>
> Hi Christopher,
>
> Christopher Baines  skribis:
>
> > My plan is to focus on this over the next year. I left my previous day
> > job quite a few months ago now to take a bit of a break, that's the main
> > reason I've been able to spend more time trying to push forward some of
> > the QA stuff. With some monetary support from NLNet [2], I'm planning to
> > continue this break and focus for the next year on getting a Guile
> > implementation of the guix-daemon written and adopted.
> >
> > 2: https://nlnet.nl/project/GuixDaemon-Guile/
>
> Yay, this is great news!! But also: thank you for your long-term
> commitment, it’s an invaluable contribution to the project.
>
> ...
>
> I imagine the daemon could be structured as a set of actors (it’s really
> my thing these days ;-)), with an eye on facilitating code sharing and
> interaction with the Coordinator, Cuirass, and all that.

Sounds like an excellent idea to us Spritely folks, too! :)

Christopher, if you ever need help with actor model related things,
come talk to us in #spritely on libera.chat.

- Dave

Re: Cuirass actors

[Thompson, David]

On Thu, Sep 14, 2023 at 11:31 AM Ludovic Courtès  wrote:
>
> Hi!
>
> "Thompson, David"  skribis:
>
> > I'm curious to hear more about your inter-process transport needs!
>
> I’d like to have actors running in separate processes on the same
> machine.  I wouldn’t want them to communicate over Tor or TCP+TLS;
> rather, I’d like them to use AF_UNIX sockets, “abstract sockets”, pipes,
> socketpairs—one of these local IPC mechanisms.
>
> My understanding is that there could be an ocapn “netlayer” based on
> that.  Does that make sense?  Is this something you’re considering?

Thanks for clarifying! Yes, we definitely intend to provide local IPC
netlayers such as UNIX domain sockets.  We actually have a test
netlayer that uses UNIX domain sockets, so some of this work has
already been done.

- Dave

Re: Cuirass actors

[Thompson, David]

Hey Ludo,

On Wed, Sep 13, 2023 at 5:08 PM Ludovic Courtès  wrote:
>
> With this actor split, one could implement another “builder” backend,
> for instance one that talks to a Build Coordinator process.  It’s also
> obviously close to the programming model encouraged by Goblins, which
> should make eventual migration easier (and when that happens, if Goblins
> provides an inter-process transport, we’ll no longer need the custom
> “bridge” and we’ll be able to move actors from one process to another
> much more easily.)

We're obviously very excited by this development over at Spritely. :)

I'm curious to hear more about your inter-process transport needs!

- Dave

Re: Swineherd: Guix System container manager

[Thompson, David]

Hey, nice job Ricardo! This looks awesome!

On Wed, Sep 13, 2023 at 11:29 AM Katherine Cox-Buday
 wrote:
>
> On 9/13/23 3:06 AM, Ricardo Wurmus wrote:
> > Hi there,
> >
> > you know the Shepherd: it is an elegant service manager looking after a
> > herd of daemons.  Since it can be extended with Guile, I decided to do
> > just that to add an extra skill to the Shepherd, turning it into the
> > Swineherd.
> >
> > The Swineherd is a manager of Guix System containers.  It is implemented
> > as a Shepherd service called “swineherd” that lets you manage Guix
> > System containers as Shepherd services.  These system container services
> > implement a few common features to bring up bridge networking, execute
> > commands inside the containers, peek at files, and get simple usage
> > stats.
> >
> > Swineherd also provides an optional HTTP API server to launch, manage,
> > and destroy containers through an HTTP client.  This makes the Swineherd
> > useful for building web applications that launch Guix System containers
> > on demand.  It comes with an Info manual describing the assumptions, the
> > required setup, as well as the implemented commands and the HTTP API.
> >
> > The Swineherd was designed to be used with Shepherd on foreign distros,
> > so it does not assume to be running on top of Guix System (for better or
> > worse).
> >
> > You can find the code here:
> >
> >  https://github.com/BIMSBbioinfo/swineherd
> >
> > Of course the Swineherd is also available as a Guix package called
> > “swineherd”.
> >
> > If this tickles your interests I’d be very happy to hear your comments
> > and incorporate patches to extend it beyond my original requirements.
>
> This is really cool stuff! I'd love to see Guix continue to eat the
> dev-ops space, which, in my opinion, loves to stack complexity on top of
> complexity.

+1 to that. I did devops professionally for about 6 years and it
really is a mess.

> Can you share any ways you're currently using this?
>
> Any plans/interest in hooking it into `guix deploy`?

Hey now that's a cool idea!

Speaking of devops, I believe with swineherd it is now possible to
implement something I've wanted for many years: the Guix equivalent of
docker-compose.  It would be like an enhanced guix shell that also
starts up services needed for development like PostgreSQL or Redis or
whatever.

- Dave

Re: Shepherd news + planned feature removal

[Thompson, David]

Hi Ludo,

On Tue, Feb 21, 2023 at 5:07 PM Ludovic Courtès  wrote:
>
> Hello Guix!
>
> I recently pushed an updated and rebased variant of
> ‘wip-service-monitor’ in the Shepherd, previously discussed here:
>
>   https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00350.html
>
> I’m going to merge it real soon if there are no objections, with the
> goal of using it as the basis for 0.10.x and hopefully soonish 1.0.x.
>
> The main news are:
>
>   • Services can now be in one of 4 states: stopped, starting, started,
> and stopping.  (Previously it was just started/stopped.)
>
>   • ‘herd status SERVICE’ reports those new states.
>
>   • ‘start’ waits if the service was already starting; ‘stop’ waits if
> the service was already being stopped.
>
>   • Services are now started in parallel, to the extent possible.
>
> Internally, the big change is that, in addition to a “service registry”
> actor (a fiber and associated channel where it receives requests), each
> service has an associated actor (likewise, a fiber) that handles
> service-specific operations such as ‘start’ and ‘stop’.  I find it
> aesthetically pleasing and fun to work with; incidentally, it should
> sound familiar to the goblins among us.  :-)
>
> There’s a couple of shepherd features that I’d like to remove:
> “persistency” (sic), and the “unknown” service.  These things were added
> in the early days of dmd ca. 2003 but they’re totally untested, likely
> broken, and probably useless.  If you have objections, now’s the time to
> let it be known.
>
> Feedback welcome!

All of these changes sound like welcome ones to me!  Love the use of
actors for managing services.  Feels kinda like Goblins meets Erlang!
I hope it proves to be a robust change.

- Dave

Re: shepherd: prefix output with service names?

[Thompson, David]

Hi Ricardo,

On Wed, Dec 14, 2022 at 5:44 AM Ricardo Wurmus  wrote:
>
> What do you think of prefixing every line with the name of the service
> that is responsible for it?  This way we could probably also
> prettify/post-process the output somewhat.

I think that's a great idea!

- Dave

Re: [EXT] Re: Emacs integration for 'guix shell'

[Thompson, David]

Hey Philip,

Just a little update for this old thread.  Around the time of your
email the Emacs package was modified to enable native compilation.
Unfortunately, it made Emacs unusable on my computer which stopped my
Emacs experimentation for a bit.  I'm past that now, thankfully.

On Sat, Oct 1, 2022 at 10:38 AM Philip Kaludercic  wrote:
>
> I wrote about it in some more detail here:
> https://amodernist.com/texts/emacs-guix.html, but the post didn't
> attract much attention.

Thanks for writing that blog post!  It was very helpful.  I now have
buffer-env handling 'guix shell' integration and it works like a
charm.

- Dave

Re: emacs-next native compilation failures

[Thompson, David]

Hi Max,

On Wed, Oct 12, 2022 at 4:24 AM Max Brieiev  wrote:
>
> Hi,
>
> Recently, Guix started building Emacs with native compilation.
>
> I did 'guix pull' few days ago (I hadn't done it for a few months), and
> it broke my Emacs.
>
> The 'guix package -u emacs-next' finished building Emacs successfully.
>
> However, when I start Emacs, the native compiler starts doing it's job
> and I see tons of compilation errors like this:
>
> Deleting /tmp/comp-lambda-RCGJQI.eln
> comp--native-compile: Native compiler error: (lambda ( arg1) (let 
> ((f #'make-process)) (apply f arg1))), "Compiling 
> /tmp/comp-lambda-RCGJQI.eln...
> x86_64-unknown-linux-gnu-gcc-10.3.0: fatal error: cannot execute ‘as’: 
> execvp: No such file or directory
> compilation terminated.
>
> This seems to be something wrong with libgccjit dependency.
>
> If I understand correctly, it did its job successfully during build time
> (since Emacs compiled successfully), but it fails now to compile
> packages during runtime. Is it correct?
>
> How do I fix this?

I don't know of a fix, but Guix is tracking this issue here:
https://issues.guix.gnu.org/issue/57878

I have been unable to upgrade Guix due to this issue.  In my case it
locks down my whole system with endless compilation processes.  I
wouldn't mind seeing native compilation disabled until upstream
improves the experience, but it's been decided that native compilation
is staying on. So, we're stuck on an old Guix until there's a
solution.

- Dave

Re: Emacs integration for 'guix shell'

[Thompson, David]

Hi Philip,

On Sat, Oct 1, 2022 at 4:22 AM Philip Kaludercic  wrote:
>
> "Thompson, David"  writes:
>
> > Hello all,
> >
> > I recently wrote a little blog post titled "Guix for development" [0]
> > and in it I mentioned using a tool called direnv and emacs-direnv as a
> > way to integrate 'guix shell' with Emacs. This integration has vastly
> > improved my Emacs experience. I can open a shell buffer and the
> > environment variables are automatically configured the way I want. I
> > can run M-x compile and simply enter 'make' as the command instead of
> > 'guix shell -D -f guix.scm -- make'.
> >
> > It's very cool that it works, and I should have done this years ago,
> > but direnv is an unnecessary middleman for me because I don't use it
> > for any other purpose.  It would be *even cooler* if Emacs could call
> > 'guix shell --search-paths' directly, parse the result, and update the
> > buffer environment.  Furthemore, it could integrate with project.el
> > (thus requiring Emacs 28) so that per-project search paths "just
> > work." The emacs-guix-shell [1] project attempts to do this.
> >
> > I'm not an experienced elisp programmer so I'm sure there's stuff to
> > fix, and there are no customizable variables yet, but the essentials
> > seem to work OK for me.  If you'd like to try it out, eval
> > guix-shell.el and then M-x guix-shell-global-mode to enable it
> > everywhere, or M-x guix-shell-mode to enable it just for the current
> > buffer.
> >
> > Whether through direnv or guix-shell.el, integrating Emacs with 'guix
> > shell' has been a game changer for my development workflow and I
> > highly recommend it!
>
> I haven't used direnv, but how does it compare to buffer-env?  I worked
> on the Guix integration a few months ago and it has been working really
> well for me.

Oh, I didn't realize buffer-env had Guix integration. My little
project may be completely unnecessary, then. When I looked at it I
noticed that it still used .envrc files and wasn't fully compatible
with direnv so it didn't seem as good compared to something that just
directly invoked 'guix shell'.  Will buffer-env automatically invoke
'guix shell' without the presence of a .envrc file?  And does it
integrate with project.el?  I guess I can answer these myself by
trying it out.  If it does both of these things then I can happily
switch over to it.

Thanks for the pointer!

- Dave

Re: Emacs integration for 'guix shell'

[Thompson, David]

On Mon, Sep 26, 2022 at 10:44 PM Maxim Cournoyer
 wrote:
>
> Hi,
>
> Olivier Dion via "Development of GNU Guix and the GNU System
> distribution."  writes:
>
> [...]
>
> > I have the following in my .dir-locals.el for my library libpatch.  The
> > idea is the same, but without direnv:
> >
> > ((nil
> >   . ((eval .
> >   (let ((root (locate-dominating-file
> >default-directory ".dir-locals.el")))
> > (when root
> >   (let ((real-root (directory-file-name (expand-file-name root
> > (setq-local geiser-guile-binary (concat real-root 
> > "/.geiser-guile"))
> > (setq-local projectile-project-compilation-cmd
> > (concat real-root "/.projectile-compile"))
> > (setq-local projectile-project-test-cmd
> > (concat real-root "/.projectile-test")
> >
>
> It seems to me it'd help everyone if Geiser should handle the above by
> itself.  It'd be cool to have the above functionality merged into Geiser
> itelf.  Just saying; thank you for sharing!

With Emacs 28 and new versions of Geiser (such as the one in Guix) I
highly recommend enabling per-project REPLs.  By setting
geiser-repl-per-project-p to 't', commands like M-x run-guile and C-c
C-a will open/switch to a REPL associated with the current project as
determined by project.el.  This is useful for when you are working on
multiple projects at once as it makes it harder to mix up REPLs, but
Geiser also automatically inserts the project root directory into
Guile's load path.  When combined with emacs-direnv, emacs-envrc,
emacs-buffer-env, or emacs-guix-shell, the Guile binary that Geiser
uses when launching a per-project REPL will be the one from the 'guix
shell' profile, and it will honor the
GUILE_LOAD_PATH/GUILE_LOAD_COMPILED_PATH settings.  So now, at long
last, my Geiser REPLs automatically use the proper build of Guile, it
can load the external libraries my project depends on, *and* it can
load my local project modules.  I'm quite happy with this setup.
Maybe I could write a blog post specifically about setting up a Guile
development environment with Guix and include all these details.

- Dave

Emacs integration for 'guix shell'

[Thompson, David]

Hello all,

I recently wrote a little blog post titled "Guix for development" [0]
and in it I mentioned using a tool called direnv and emacs-direnv as a
way to integrate 'guix shell' with Emacs. This integration has vastly
improved my Emacs experience. I can open a shell buffer and the
environment variables are automatically configured the way I want. I
can run M-x compile and simply enter 'make' as the command instead of
'guix shell -D -f guix.scm -- make'.

It's very cool that it works, and I should have done this years ago,
but direnv is an unnecessary middleman for me because I don't use it
for any other purpose.  It would be *even cooler* if Emacs could call
'guix shell --search-paths' directly, parse the result, and update the
buffer environment.  Furthemore, it could integrate with project.el
(thus requiring Emacs 28) so that per-project search paths "just
work." The emacs-guix-shell [1] project attempts to do this.

I'm not an experienced elisp programmer so I'm sure there's stuff to
fix, and there are no customizable variables yet, but the essentials
seem to work OK for me.  If you'd like to try it out, eval
guix-shell.el and then M-x guix-shell-global-mode to enable it
everywhere, or M-x guix-shell-mode to enable it just for the current
buffer.

Whether through direnv or guix-shell.el, integrating Emacs with 'guix
shell' has been a game changer for my development workflow and I
highly recommend it!

That's all for now,

- Dave

[0] https://dthompson.us/guix-for-development.html
[1] https://git.dthompson.us/emacs-guix-shell.git/

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[Thompson, David]

Okay so I was a little confused because gitolite has no test suite.
Turns out this failure is for the system test of the gitolite service
that I didn't know existed.  I figured out how to run that and
reproduced the failure.  Despite git-minimal being sufficient for
everything I use gitolite for on my server, using it breaks the system
test. I reverted back to using the bigger git package and the test is
passing again.  Revert pushed as commit
c4504dfb1da78f2f21fc5139a2fd5e82ed0ef21c.

Sorry for the breakage,

- Dave

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[Thompson, David]

On Mon, Sep 5, 2022 at 1:22 PM Tobias Geerinckx-Rice  wrote:
>
> Thompson, David 写道：
> > Will this build be retried at some point?
>
> Yes: now ;-)
>
> (There are no automatic retries.)
>
> Fresh new errors at
> <https://ci.guix.gnu.org/build/1333185/log/raw>.
>
> I would say these look fundamental and not transient, but if you
> say you built this at home, I don't know what to say…

This log looks much different than the last one I saw.  I'll see if I
can figure out what's going on.

- Dave

Re: branch master updated: gnu: gitolite: Wrap programs instead of using propagated inputs.

[Thompson, David]

On Mon, Sep 5, 2022 at 9:01 AM Mathieu Othacehe  wrote:
>
>
> Hello David,
>
> I noticed that the gitolite test is now failing. Any chance it is
> related to the recent work on the package?
>
> https://ci.guix.gnu.org/build/1333185/details

Hmm, it built successfully for me and worked when I deployed it to my
own server. Looking at the log file from the CI system it seems that
the build failed due to a network issue:

@ substituter-started
/gnu/store/pszh9ml0nz1izsxi6d6x08dfl6cc11qb-manual-database-builder
substitute
  2172:10 14 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
Downloading 
http://141.80.167.131/nar/lzip/pszh9ml0nz1izsxi6d6x08dfl6cc11qb-manual-database-builder...
  1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
   771:15 11 (_)
In ice-9/exceptions.scm:
   406:15 10 (process-substitution # _ "/gnu/store/?" ?)
In ice-9/boot-9.scm:
  1752:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
479:9  8 (_)
In ice-9/boot-9.scm:
  1747:15  7 (with-exception-handler # ?)
  1685:16  6 (raise-exception _ #:continuable? _)
  1683:16  5 (raise-exception _ #:continuable? _)
  1685:16  4 (raise-exception _ #:continuable? _)
  1780:13  3 (_ #< components: (#<> #)
  1685:16  2 (raise-exception _ #:continuable? _)
  1683:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
  1. :
  uri: #< scheme: http userinfo: #f host: "141.80.167.131"
port: #f path: "/nar/zstd/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv"
query: #f fragment: #f>
  code: 504
  reason: "Gateway Time-out"
  2. : 
"http://141.80.167.131/nar/zstd/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv:
HTTP download failed: 504 (\"Gateway Time-out\")"
fetching path `/gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv'
(empty status: '')
@ substituter-failed
/gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv  fetching path
`/gnu/store/j8mqqhvihc2bg4nczbs6rs6iih1g5619-iw-5.19.drv' (empty
status: '')

Will this build be retried at some point?

- Dave

Re: [EXT] cloud-init?

[Thompson, David]

Hi Simon,

On Fri, Aug 26, 2022 at 4:16 AM Simon Josefsson via Development of GNU
Guix and the GNU System distribution.  wrote:
>
> I would like to deploy Guix VM's and in many VM hosting environments,
> having cloud-init on the Guix VM image would be useful for configuration
> of network interfaces etc.  I tried searching the mailing list archives
> and bug database, but could not find anything except that the
> cloud-utils package has been added to Guix.
>
> The philosophy of cloud-init and Guix system configuration is probably
> at odds, but basic support for booting and starting sshd and printing
> the SSH fingerprint, and possibly some DHCP/network config is probably
> not too difficult to achieve.  A 'cloud-init' package in Guix could do
> as much as is possible to do, or at least document the gap between
> philosophies.
>
> I haven't looked into packaging cloud-init, but first wanted to ask if
> anyone is aware of work in this area?  Are people interested in this?

I can only cite my experiences doing devops on AWS for the past 5
years, but I personally avoid relying on cloud-init on EC2 and try to
catch when other developers use it to do something because there's
always a better way.  That better way is almost always to add a
one-shot systemd service (these are not Guix System servers) to the VM
image that starts on boot.  What are some situations in which
cloud-init is unavoidable?  I wouldn't think cloud-init would need to
start sshd since the init system would automatically do that.

None of this is to say that I wouldn't be in favor of having
cloud-init support.  I'm just trying to understand if it's a necessity
in a certain context or if it would be for the purpose of providing a
familiar tool to help people who are used to using it with other
distros.

- Dave

Re: [EXT] Please reply: License of your contributions to the blog at guix.gnu.org

[Thompson, David]

Hi,

Sorry, I haven't been paying attention to mailing lists lately.

I agree with CC-BY-SA 4.0 and GFDL 1.3+ dual-licensing for my contributions
to the Guix blog.

- Dave

On Mon, Jul 4, 2022 at 9:56 AM Ludovic Courtès  wrote:

> Hello Danny, David, and Laura!
>
> I hope this message finds you well.
>
> If I’m not mistaken, you’re the last people who have not replied to my
> message below, also visible at:
> .
>
> Could you please take a look and reply ASAP?
>
> Your reply might be as simple as “I agree with CC-BY-SA 4.0 and GFDL
> 1.3+ dual-licensing for my contributions to the Guix blog.”
>
> Thanks in advance!
>
> Ludo’.
>
> Ludovic Courtès  skribis:
>
> >> Hello,
> >>
> >> I am emailing you on behalf of the GNU Guix project because you are the
> >> author or coauthor of one or more articles to the blog at
> >> .
> >>
> >> With a few exceptions, these articles do not have a clear license, which
> >> we would like to fix.  We propose to dual-license all the articles under
> >> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> >> no Front-Cover Texts, and no Back-Cover Texts.
> >>
> >> Do you agree with the proposed licensing terms for your contributions to
> >> the blog?
> >>
> >> If you do, please reply to this message to say so, keeping
> >> guix-devel@gnu.org Cc’d (if you already replied in the previous thread,
> >> you do not need to reply again).
> >>
> >> If you would prefer different licensing terms, or if you have any
> >> questions, feel free to ask them publicly on guix-devel@gnu.org or
> >> privately with guix-maintain...@gnu.org.
> >>
> >> The clarified license will allow us and others to reuse material in the
> >> manual, cookbook, and in other free cultural works.  See
> >> 
> >> for the initial discussion.
> >>
> >> Thanks in advance!
> >>
> >> Ludo’.
>

Re: [EXT] Re: [EXT] Re: Medium-term road map

[Thompson, David]

On Wed, May 6, 2020 at 3:46 PM Jack Hill  wrote:
>
> > Long story short: Guix need not worry about this.
>
> I think we may want to do some work in Guix to support this workflow
> conveniently. That work could include having a secrets management service,
> bootstrapping new hosts for access to the service, or writing system
> services that can be easily configured for different secret management at
> deploy time. It's fun to think about what we could do, but as Ludo’
> suggested elsewhere in the thread, we'll find out by trying to deploy more
> hosts with more complex configurations. I hope to be able to do so soon.

To that end, I think a good starting place would be to research the
available free secrets management applications (my knowledge is a few
years out of date), package it, and write a shepherd service for it.
>From there, we could see what additional integration would be useful
for clients (your other servers being clients of the secrets
management server.)  I don't know if this would actually work, but I
can picture a world where service configuration objects are aware of
secret fields (some new Scheme data type) and will arrange to lazily
generate config files in a just-in-time fashion on the server when
shepherd starts the service.  Sounds like a real fun project, IMO!

Okay, so I take it back: Guix *should* worry about this, but in a very
specific way that is orders of magnitude better than every other
configuration management system out there, just like the rest of Guix.
:)

- Dave

Re: [EXT] Re: Medium-term road map

[Thompson, David]

On Sat, Apr 25, 2020 at 5:38 PM Jack Hill  wrote:
>
> * Continued development of guix deploy. Figuring out how to deploy secrets
> to remote machines would be great.

I used to think this was a problem that guix deploy had to deal with
but after many years doing devops full-time I no longer think this is
a concern. Industry best practice is to use a secrets management
service to fetch secrets at application boot time.  For example, you
could write a shepherd service that downloads and installs an SSH host
key from AWS Secrets Manager (or a self-hosted free tool or another
cloud provider's service, you get the idea) before the SSH service
starts.  In my experience, every application requires a slightly
different strategy: Maybe you need to put a key into a specific file,
maybe you need to set environment variables, maybe you need to
templatize the config file, etc. There's no single general solution to
the problem, but I strongly the believe that the guix client that is
doing the deployment should never access such secrets.

Long story short: Guix need not worry about this.

- Dave

Re: Ansible and GuixOps questions

[Thompson, David]

Hello Robert,

On Mon, Dec 16, 2019 at 6:57 AM rchar01  wrote:
>
> Probably many admins / DevOps are heavily using Ansible. I also use this 
> solution to configure systems and services (on Debian and CentOS).
> I would like to transfer infrastructure to the Guix System and some questions 
> arose:
>
> - is there any way to combine Ansible and GuixOps?

In short, no.  I'm assuming that "GuixOps" means 'guix deploy', which
is its own special tool that would take the place of Ansible if you
choose to use it.

> - is there any way to continue using Ansible to configure Guix (some in guile 
> script and some in ansible)?

In the past I've used Chef (very similar to Ansible) to install Guix
on Ubuntu machines.  You could do the same with Ansible.  If you wish
to deploy systems running Guix System proper, I think that's possible,
too, but you'd have to do some work on your own.  You would have to
build yourself a base image of a barebones Guix system and run your
Ansible scripts from that base.  I imagine that Ansible would be
little more than a thin layer for running 'guix system reconfigure
system.scm' on a remote machine at that point.

> - would it be possible to generate a guile script (for GuixOps) from Ansible?

Sorry, I don't quite understand this.  Maybe?

> - would it be possible to change the Ansible to talk to the Guix (or GuixOps) 
> system?

Need more clarity here as well.  Seems like a duplicate of your second
question??

> Rewriting to Guile (Guix config files):
> * Against:
> ** time consuming
> ** may require new skills
> ** only for Guix, Ansible can configure other GNU / Linux systems

If you're already using Ansible for everything, then yes it would be a
hard sell to switch to something Guix specific, but Guix tools offer
features that no mainstream tools could ever hope to offer.  As I said
earlier, though, you could make a Guix + Ansible mix work if you want.

> * What might the benefits be?

One of the big benefits is getting to use the Guix tooling and
libraries for system deployment in addition to packaging and system
configuration which many people already use.  For people who are used
to Guix, it's relatively easy to use 'guix deploy' whereas it would be
very difficult to use something else.  Another reason is that Ansible
is, frankly, not a very good tool from our point of view.  Ansible's
model is "start from a base image and mutate it into the system you
want."  If you're into reproducibility, this isn't great.  How was the
base image created?  Will running the same Ansible scripts a day from
now produce the exact same image, bit for bit?  Almost certainly not.
Ansible is already mostly redundant with 'guix system' because that
tool takes care of all the configuration management chores.  What is
*not* covered by 'guix system' is remote system management, thus 'guix
deploy' was created. It takes things further by helping you deploy the
same system configurations you use with 'guix system' to many remote
systems.  'guix deploy' is still very new and doesn't have a lot of
features, but it's built on the right foundation to avoid the big
issues with mainstream devops tools.

Hope this helps,

- Dave

Re: Guix and FSDG

[Thompson, David]

On Fri, Nov 22, 2019 at 2:20 PM Raghav Gururajan
 wrote:
>
> I completely agree with you. The way you explained, does show that Guix
> comply with FSDG. The thing is, the semantics used in current version
> of FSDG does not explain things well. That's why I pointed out that
> FSDG require revision, such that this new scenario is included in FSDG.
> So that Guix or any future distros that gonna use same/similar
> mechanism, does not pose confusion to readers of FSDG. That is all. :-)

Glad that we're in agreement. :)

- Dave

Re: Guix and FSDG

[Thompson, David]

Hi, just a quick note to begin: Please do not cross-post to multiple
mailing lists because it tends to cause confusion for everyone reading
those lists.  I have included only guix-devel in the CC list for this
reply.

On Wed, Nov 20, 2019 at 5:02 AM Raghav Gururajan
 wrote:
>
> (b) Facilitation of non-free information/code/program/software:
> As per FSDG, free system should neither steer users nor refer to third-
> party repositories, to obtain information/code/program/software that
> can contain non-free parts. Let's consider the same two main things
> provided by Guix, that are, (i) Package Definitions (Scheme Code) and
> (ii) Subsitiutes (Pre-Built Binary). If we take substitutes,they are
> pre-built binaries, built on the guix build farm, where the source is
> obtained, de-blobbed (if required) and compiled. Since guix provides
> substitutes only for free software/programs, there is no facilitation
> of non-free information/code/program/software here. If we take the
> package definitions, that is were issue rises. When no substitutes are
> available or when the program/software is chosen to be built, guix on
> the user's system does this: downloads source directly from upstream
> (along with non-free parts if it contains), then strips out non-free
> parts (if any), then builds and installs binaries. So these package
> definitions, contains information/lines-of-code, that steer users or
> refer to third-party repositories, to obtain
> information/code/program/software that can contain non-free parts.
> Therefore, Guix DOES violate FSDG in this aspect.

I believe this is incorrect and I will explain why.  This exact
circumstance was brought up in the early days of the Guix project when
FSDG compliance was a big topic of discussion because Ludovic and RMS
were making sure that Guix conformed to it.  It is true that Guix will
download source archives for packages that *may* contain files with a
nonfree license.  However, Guix has a special mechanism developed
specifically to deal with this issue.  In Guix, the  data type
is used to store information about a package's source code.  In this
data structure there is a field called "snippet" which may contain a
custom procedure written by the person that wrote the package.  The
role of the snippet procedure is to *remove* any files in the source
archive that are not freely licensed.  The result is a new source
archive that contains only freely licensed files.  The most important
part of this process is that the original source archive is *never*
accessible to the Guix user via any Guix tools.  The original archive
is discarded and does not end up in the canonical location for Guix
data: /gnu/store.  Thus, running `guix build --source
problematic-package` will only ever return the cleaned archive, never
the original with nonfree files.  Therefore, Guix has taken sufficient
technical measures to avoid steering its user towards nonfree software
and thus Guix is compliant with the FSDG.

Hope this helps,

- Dave

Re: Joint statement on the GNU Project

[Thompson, David]

Stop sending these incoherent essay length rants to the Guix mailing
lists.  You've made your point dozens of times.  Thanks in advance.

- Dave

Re: “Guix Profiles in Practice”

[Thompson, David]

On Fri, Oct 25, 2019 at 6:57 AM Ludovic Courtès  wrote:
>
> Hello Guix!
>
> Here’s a new blog post by Pierre Neidhardt entitled “Guix Profiles in
> Practice”:
>
>   https://guix.gnu.org/blog/2019/guix-profiles-in-practice/
>
> A great discussion on the benefits of manifests and on ways to manage
> several profiles!

Great article!

I spotted a typo in the first paragraph: "on a same system" should be
"on the same system."

The section below reminds me about some unfinished work from back when
I wrote 'guix environment':

Eventually, we set to work on that project again, so we run guix
environment -m manifest.scm. But now we have to wait for Guix to
build and install stuff!

This is indeed a frustration.  It takes a bunch of extra switches to
have 'guix environment' create a profile and even I don't bother with
it, just opting to build a new profile if I've upgraded guix since the
last time I worked on the project.  This gets me into trouble when I
upgrade guix and decide that I want to work on the project while I'm
somewhere with no network connection or too slow of a connection to
download everything in a reasonable time.  It has happened to me
multiple times while commuting by train.

'guix environment' is a very composable command, and it's not clear to
me how I would add the stuff I want onto it and it's even less clear
if it's a good idea.  Probably not.  So, I wonder if maybe a new
subcommand, say 'guix develop', could address this common development
use-case while allowing 'guix environment' to continue being the swiss
army knife that it is.  Some simple naming conventions could make this
tool "just work."  Running 'guix develop' would check for a profile
symlink with some canonical name, for example '.guix-develop-profile'.
If it exists, it applies the environment variables and spawns a
subshell.  If it doesn't exist, it looks for a 'develop.scm' file
(canonical name TBD), builds the profile, symlinks it to
'.guix-develop-profile', and then does the prior steps.  The tool
would provide a mechanism to update, etc. and it could even be
expanded later to spawn services like databases.

- Dave

Re: "guix deploy" is in git master

[Thompson, David]

On Mon, Jul 8, 2019 at 3:29 PM Ricardo Wurmus  wrote:
>
> Similarly, it would be great if “guix deploy” would continue deploying
> other machines in the list even if one of them couldn’t be deployed due
> to an error.  I have a list of 24 machines and a few of them fail with
> the user-homes error above.  Would be nice if all the other deployments
> would still go through, because they are independent.

Agreed. Also this should be done in parallel eventually because
updating 24 machines serially is silly.

> (On the other hand, the current behaviour might be desirable in case
> there’s a problem with “guix deploy” itself.  Rather break just one
> machine instead of wrecking the whole site.  Dunno.)

I think we need to make 'guix deploy' robust enough so that we can trust it. :)

This does bring up the question of what to do upon failure. Other
deployment systems that I've worked with (mainly AWS CodeDeploy)
provide some options. First, the user can specify what it means for a
deploy to succeed. Does it have to successfully deploy to each of them
or should it allow some amount of failure? Then, upon failure, the
user can specify whether or not a rollback should happen.  My personal
preference for default behavior right now is to update everything
possible and print out a report so users can see what failed, but I
think ultimately we'll need to provide more options.

We need to also keep in mind that in-place updates to machines is just
a primitive initial use-case.  Things will get really fun when we get
to blue-green deployments in cloud environments because "rollback"
takes on a whole new meaning. :)

- Dave

Re: Guix beyond 1.0: let’s have a roadmap!

[Thompson, David]

On Thu, Jun 27, 2019 at 12:31 PM Ludovic Courtès  wrote:
>
> What do *you* want Guix to address in the future?

* Extend 'guix environment' to cover use-cases that people currently
use docker-compose for
* Improve UX of 'guix environment' by using sane defaults and
conventions such as reading from 'guix.scm' file in current directory
* Add a small-scale, general-purpose, "serverless" computing
environment a la AWS Lambda using g-expressions + call-with-container
+ a web server
* Improve portable application bundles so that only files needed at
runtime (no headers, docs, etc.) are included somehow (not sure how to
do this one)
* Allow system services to run unprivileged (perhaps via user
namespaces) so that each user may have their own shepherd instance
(would be useful for other features, too, such as the first item in
this list)

That's all I've got for now. :)

- Dave

Re: One-shot Shepherd services

[Thompson, David]

On Thu, Apr 18, 2019 at 5:38 PM Ludovic Courtès  wrote:
>
> Hello Guix!
>
> Today I added support for “one-shot” services in the Shepherd:
>
>   
> https://git.savannah.gnu.org/cgit/shepherd.git/commit/?id=c121eedfff7a50feddcf08e173d2b0dd807e8804
>
> One-shot services start, perform a short action, and are immediately
> marked as “stopped.”  (systemd has something similar:
> .)
>
> The use case is initialization or cleanup actions like the ‘user-homes’
> service.  So far ‘user-homes’ is a regular service whose ‘start’ method
> always fails; as a result, we always see this message:
>
>   Service user-homes could not be started.
>
> From there on, we’ll be able to mark this service as one-shot (patch
> below), and thus shepherd will notice that it successfully started (or
> not) and yet mark it as stopped, which was always the intent.
>
> There are other cases where this could be useful.  For instance, we
> could turn service activation snippets into one-shot services.
>
> Since this augments the Shepherd API, I plan to release it as 0.6.0
> in time for Guix 1.0.  It contains other rather minor changes compared
> to 0.5.0.
>
> Feedback welcome!

A big +1 from me. I use one-shot systemd services all the time.

- Dave

Re: GNU Guix 1.0.0 released

[Thompson, David]

Congrats everyone! What an accomplishment!

- Dave

Re: Status update on 1.0

[Thompson, David]

On Fri, Mar 15, 2019 at 10:33 AM Ludovic Courtès  wrote:
>
> Hi,
>
> Gábor Boskovits  skribis:
>
> > Ludovic Courtès  ezt írta (időpont: 2019. márc. 13., Sze, 
> > 16:21):
> >>
> >> Hello Guix!
> >
> >>   • IPv6 support in ‘static-networking-service’: as discussed at the
> >> Guix Days, we’ll probably need to Linux Netlink sockets to do that
> >> rather than the old ioctls currently used in (guix build syscalls).
> >>
> >> The netlink interface for network config is vaguely documented at
> >> .
> >> Writing bindings for ‘sendmsg’ and the associated data structures
> >> looks reasonable… it just needs to be done.
> >>
> >
> > I am interested in doing this.
>
> Awesome!
>
> > However, there are a few points that needs to be clarified: 1. I came
> > to the same conclusion regarding the netlink stuff, but the old ioctl
> > cannot be fully dropped. (It still provides funcions that are needed
> > to get the netlink working)
>
> Yes, I think we can keep it.
>
> > 2. This might be linux specific. What do we do on other kernels?
> > (It might be reasonable to provide the abstractions in a module, and
> > from there select an available implementation, or signal an error that
> > the functionality is not yet implemented for this system...)
> > Wdyt?
>
> For now, we’ll have to ignore the other kernel.
>
> Longer-term, I suppose we should provide an abstraction over network
> configuration and have it translated to Netlink messages or Hurd RPCs.
>
> > Also a nice low level binding written in C is available as libmnl:
> > https://netfilter.org/projects/libmnl/index.html
>
> Or libnl also.  Though if it’s not too hard, I’d rather have us directly
> bind to ‘sendmsg’, ‘struct msghdr’, and so on.

Quick tangent: My memory is a bit fuzzy, but I think that netlink API
wrappers would put us one step closer to being able to implement
useful network isolation in our container implementation (right now
you only have loopback, not so fun), like what Docker can do. Just
something to consider. :)

- Dave

building "guix deploy"

[Thompson, David]

Hello everyone!

Chris Webber and I spent the morning chatting about how we want to
approach making "guix deploy" a reality and then started hacking on it
in the afternoon.  Although we weren't able to complete a working
prototype by the end of the day, we were able to get pretty close.  We
created a 'guix deploy' CLI to build derivations for any number of
remote systems on a local workstation and initiate the transfer to the
remote systems, but we encountered a difficult to debug SSH error that
blocked our progress:

sending 85 store items (0 MiB) to 'test.activitypub.rocks'...
exporting path 
`/gnu/store/ylcdmrj3vf00ixdcjvkl3mbs8f5i9w8l-git-minimal-2.20.1.drv'
;;; [2019/03/09 17:32:48.792589, 0] write_to_channel_port: [GSSH
ERROR] Remote channel is closed: #
Backtrace:
  10 (apply-smob/1 #)
In ice-9/boot-9.scm:
705:2  9 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  8 (_ #(#(#)))
In guix/ui.scm:
  1654:12  7 (run-guix-command _ . _)
In guix/scripts/deploy.scm:
 72:8  6 (guix-deploy . _)
In srfi/srfi-1.scm:
640:9  5 (for-each # …)
In guix/scripts/deploy.scm:
74:20  4 (_ _)
In gnu/machine.scm:
58:22  3 (_ _ _ _)
In guix/ssh.scm:
313:4  2 (send-files # _ _ # _ # …)
In guix/store.scm:
   1504:7  1 (export-paths # _ # …)
In unknown file:
   0 (put-bytevector # …)

ERROR: In procedure put-bytevector:
Throw to key `guile-ssh-error' with args `("write_to_channel_port"
"Remote channel is closed" #
#f)'.

If anyone knows what might be going on here and how we could resolve
it, your input would be much appreciated!  We verified via the sshd
logs that we were indeed successfully establishing a connection.

Once we're past this blocking issue and are able to transfer OS
closures to remote systems, we plan to write a modified version of
switch-to-system that uses guile-ssh to switch remote symlinks for the
active system and run the activation script.  We'll save
upgrade-shepherd-services for later, as it is quite a bit more
complex.

There's not a lot of code yet, but you can check it out in the
wip-deploy2 branch.  Currently, the only supported use-case is running
the equivalent of 'guix system reconfigure' on machines already
running GuixSD that have an OpenSSH daemon running, but the basic
design allows for additional use-cases to be supported in the future.

Thanks to Ricardo for his install-berlin.scm script that provided a
basis for most of our code, and to Ludovic for the (guix ssh) module
that I wish I had when I attempted to write 'guix deploy' all those
years ago.

Until next time...

- Dave

Re: virtual network interfaces in container

[Thompson, David]

On Wed, Feb 13, 2019 at 12:55 PM Giovanni Biscuolo  wrote:
>
> Hello devel!
>
> please is there any wip on implementing virtual network interfaces in
> "guix system container"s?

Not that I know of. I punted on that when I wrote the container
implementation because it's a lot of extra work and complexity.  It
can certainly be added if someone were to put in the effort to figure
out what needs to be done.  IIRC there are some bindings to C
libraries that may be needed.

- Dave

Re: It's time to build "guix deploy"

[Thompson, David]

On Tue, Feb 12, 2019 at 8:34 AM Christopher Lemmer Webber
 wrote:
>
> Thompson, David writes:
>
> >> Maybe Dave and I can meet up IRL now that we're close enough to each
> >> other to chat about it.  But I know it's less fun than it used to be for
> >> Dave to consider this because now that's Dave's actual job... but all
> >> the more reason we need Dave's wisdom! :)
> >
> > We could meet up IRL about this and I can try to make an earnest
> > effort to deal with this. I think what has stopped me in the past is
> > the sheer size of this project, and maybe dramatically scaling down
> > the scope will allow us to get *something* out the door.
>
> Yes I think we shouldn't allow ourselves to get too overwhelmed!  We
> should give the warnings that this is an alpha system in alpha (soon
> beta?) software and we don't guarantee that the api will be stable :)
>
> Furthermore, I think if we put an emphasis on composable layers, and
> start with the simplest lower layers, and then add some other layers
> above it (and actually the different use cases you lay out may actually
> swap out which layers are above this), then I think we could be good?

Something like that, yeah.

> > Here are some general use-cases I know about for deployments, roughly
> > ordered from small scale to large scale, and least complex to most
> > complex:
> >
> > * Managing a physical machine or two that have been given memorable
> > names that you update in-place (home scale)
> > * Managing a virtual machine or two that have been given memorable
> > names that you update in-place (blog scale)
>
> In the past we have discussed storing "deployment state", and where and
> how we would store it.  I will make the argument that for these two
> cases, we actually don't need state!  We can just do the simplest thing
> possible: build the system derivation for each of these machines, log in
> and see if the system already has that derivation running, and if not
> copy over the closure and install it as the system state.  This could
> be entirely declarative.

Right, since these are pet servers, the user already knows all the
relevant information about them.

> I think initially we can ignore entirely the issue of provisioning an
> initial guix image.  We can also ignore things like getting the right
> public keys and configuring the initial authority of how you can be
> authorized to copy over that data.

Yes, the pet server use-cases assume the systems have been setup
manually.  Automated provisioning will be relevant for cloud
deployments.

> > * Managing a large number of virtual machines whose names don't matter
> > that you update in-place (proto-cloud scale)
> > * Managing a large number of virtual machines whose names don't matter
> > that are replaced when there is an update (cloud scale)
> > * Managing 1 or more clusters of physical machines (datacenter scale)
> > * Managing 1 or more clusters of physical machines and virtual
> > machines ("corporation with a datacenter that is moving some stuff to
> > the cloud" scale)
>
> For all these, I think there can be one or more abstraction layers that
> build on top of the same declarative primitives described above.  And
> this may be where state comes in; since you don't really know what the
> identifiers are ahead of time, but you do need to keep track of them,
> yes we do want to serialize the state somewhere.

I don't think this tool should ever store state.  For example, if you
have a bunch of EC2 instances, you can use the AWS API to query for
the instances you want to update.  No need for us to worry about state
and deal with the inevitable synchronization issues.

> > There are, of course, more scenarios to consider (haven't even touched
> > upon things like a Kubernetes cluster), but this is enough to
> > illustrate the point that is a great diversity in setups.  How many
> > machines are there? Are the bare metal, virtual machines, or a mix of
> > both? In the case of virtual machines, are updates applied in an
> > immutable fashion or not?  If immutable, which technique (blue-green,
> > rolling release, etc.)?  It makes my head spin to think about all the
> > use-cases.
>
> ... I don't know anything about the things you said above so I guess
> that would be nice to go over in person :)
>
> I think maybe my ignorance is helpful for optimism in this case!
>
> > So... let's start small. Can we write a tool that handles in-place
> > updates to machines (physical or virtual) whose name and IP address we
> > know well (our special pet servers) without precluding the possibility
> > of scaling up to more sophisticated architectures?  T

Re: It's time to build "guix deploy"

[Thompson, David]

Hi Chris,

Here we go again, eh? :)

On Mon, Feb 11, 2019 at 8:31 AM Christopher Lemmer Webber
 wrote:
>
> Hi,
>
> This has come up several times.  A lot of us want "guix deploy".
> Personally, I'm running a variety of Debian servers and one Guix server
> and I am terrible at maintaining all of them.

I have just a single Linode VPS that I can't be bothered to maintain
most of the time. I would like to switch to Guix, as well.

> It's time for Guix Deploy... or it's time for me to give up and use
> something like Ansible + Debian.  (Egads!  I don't want to do that.)
>
> David's thoughts on this are below, and here's the original thread:
>
> Original thread can be found at the links below:
>   https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00525.html

Wow, 2015. I was so young and full of hope then. ;)

>   https://lists.gnu.org/archive/html/guix-devel/2015-05/msg7.html
>   https://lists.gnu.org/archive/html/guix-devel/2015-06/msg6.html
>
> There is a heavily, heavily bitrotted branch named "wip-deploy" where
> David originally started exploring these ideas.  Conveniently, it's all
> in one commit:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy=fcd6fc84e493d05be1f7590ee77509c81ac315c2

Useful for context, but the code can probably be tossed at this point.

> That seems like a good starting point.  But I know David feels that with
> real-world experience in devops type work that actually things would be
> a bit different than what's described in his original email.  I'm not
> sure myself what would be different.  It would be helpful to hear Dave
> weigh in on that point.

Sure, since 2015 I've become the lead devops person at my company, so
I like to think I'm a bit wiser now.

> Maybe Dave and I can meet up IRL now that we're close enough to each
> other to chat about it.  But I know it's less fun than it used to be for
> Dave to consider this because now that's Dave's actual job... but all
> the more reason we need Dave's wisdom! :)

We could meet up IRL about this and I can try to make an earnest
effort to deal with this. I think what has stopped me in the past is
the sheer size of this project, and maybe dramatically scaling down
the scope will allow us to get *something* out the door.  Here are
some general use-cases I know about for deployments, roughly ordered
from small scale to large scale, and least complex to most complex:

* Managing a physical machine or two that have been given memorable
names that you update in-place (home scale)
* Managing a virtual machine or two that have been given memorable
names that you update in-place (blog scale)
* Managing a large number of virtual machines whose names don't matter
that you update in-place (proto-cloud scale)
* Managing a large number of virtual machines whose names don't matter
that are replaced when there is an update (cloud scale)
* Managing 1 or more clusters of physical machines (datacenter scale)
* Managing 1 or more clusters of physical machines and virtual
machines ("corporation with a datacenter that is moving some stuff to
the cloud" scale)

There are, of course, more scenarios to consider (haven't even touched
upon things like a Kubernetes cluster), but this is enough to
illustrate the point that is a great diversity in setups.  How many
machines are there? Are the bare metal, virtual machines, or a mix of
both? In the case of virtual machines, are updates applied in an
immutable fashion or not?  If immutable, which technique (blue-green,
rolling release, etc.)?  It makes my head spin to think about all the
use-cases.

So... let's start small. Can we write a tool that handles in-place
updates to machines (physical or virtual) whose name and IP address we
know well (our special pet servers) without precluding the possibility
of scaling up to more sophisticated architectures?  This would address
the "home" and "blog" scale items above, which is probably what most
of the people actually using Guix today would want.  I got stuck
trying to do in-place updates to remote machines years ago, but that
was before Ludo made it easy to connect to remote systems.

Other thoughts?

Yours in vaporware,

- Dave

Re: Guix Days starting in two days!

[Thompson, David]

On Tue, Jan 29, 2019 at 4:58 AM Ludovic Courtès  wrote:
>
> Hello Guix!
>
> The Guix Days are starting in two days!  \o/
>
> We’ll be meeting this Thursday 31st at ICAB¹ at 9:30AM for coffee and
> starting at 10AM.
>
> We’ll update  as
> needed to share practical info.  Please email Pjotr, Manolis, Ricardo,
> or myself if you have any questions.

Have fun, everyone!

Since I'll be on another continent, I'm looking forward to seeing the
talks/blog posts that come out of FOSDEM.

- Dave

Re: Using a CDN or some other mirror?

[Thompson, David]

On Tue, Dec 4, 2018 at 4:15 PM  wrote:
>
> Hartmut Goebel transcribed 771 bytes:
> > Am 03.12.2018 um 17:12 schrieb Ludovic Courtès:
> > > Thus, I’m thinking about using a similar setup, but hosting the mirror
> > > on some Big Corp CDN or similar.
> >
> > Isn't this a contradiction: Building a free infrastructure relaying on
> > servers from some Big Corporation? Let allow the privacy concerns
> > raising when delivering data via some Big Corporation.
> >
> > If delivering "packages" works via static data without requiring any
> > additional service, we could ask universities to host Guix, too. IMHO
> > this is a much preferred solution since this is a decentralized publish
> > infrastructure already in place for many GNU/Linux distributions.
>
> Regardless of me agreeing with Hartmut here, I suggest https://wasabi.com/
> as an S3 compatible storage (, which is not run by Amazon.).

But can Wasabi provide what CloudFront does?  CloudFront is distinct
from S3, and can fetch and cache data from any origin. Additionally,
it stores data on edge nodes across the globe and routes requests
accordingly to maximize download speed.

- Dave

Re: Using a CDN or some other mirror?

[Thompson, David]

On Tue, Dec 4, 2018 at 9:06 AM Ludovic Courtès  wrote:
>
> Hi Hartmut,
>
> Hartmut Goebel  skribis:
>
> > Am 03.12.2018 um 17:12 schrieb Ludovic Courtès:
> >> Thus, I’m thinking about using a similar setup, but hosting the mirror
> >> on some Big Corp CDN or similar.
> >
> > Isn't this a contradiction: Building a free infrastructure relaying on
> > servers from some Big Corporation? Let allow the privacy concerns
> > raising when delivering data via some Big Corporation.
> >
> > If delivering "packages" works via static data without requiring any
> > additional service, we could ask universities to host Guix, too. IMHO
> > this is a much preferred solution since this is a decentralized publish
> > infrastructure already in place for many GNU/Linux distributions.
>
> As you know, berlin.guixsd.org is hosted at the Max Delbrück Center in
> Berlin, a public research institute.  So in a way, we’re already doing
> that.  We shouldn’t take it for granted that public institutes will
> happily host our stuff and donate hardware: without Ricardo’s work and
> the generosity of the MDC, we wouldn’t have anything there.
>
> I understand the reluctance regarding “Big Corp” hosting, and I actually
> share it to some extent.  However, having put much thought into it (and
> also much sweat in build farm sysadmin…), I think the alternative is:
> commercial hosting, or peer-to-peer.
>
> Florian has been looking at the latter approach with IPFS, and perhaps
> we’ll be able to put it in production in a few months and be happy with
> it (I have good hopes given what Florian already demonstrated.)
>
> In the meantime, we need redundant storage, high bandwidth, and high
> availability.  If you know of non-profit organizations that can provide
> such services, please let us know; if not, we’ll resort to a commercial
> service.  The bottom line is: we cannot reasonably pretend to offer such
> a service ourselves.
>
> (Note that we’re just talking about substitute delivery—I wouldn’t want
> to *build* packages on one of these commercial hosting services.)
>
> I hope this clarifies my position.

Using CloudFront with a custom (non-S3) origin sounds like a
reasonable solution to me, though I understand the hesitance to use a
commercial service.

If AWS CloudFront is the path chosen, it may be worthwhile to follow
the "infrastructure as code" practice and use CloudFormation to
provision the CloudFront distribution and any other supporting
resources. The benefit is that there would be a record of exactly
*how* the project is using these commercial services and the setup
could be easily reproduced.  The timing is interesting here because I
just attended the annual AWS conference on behalf of my employer and
while I was there I felt inspired to write a Guile API for building
CloudFormation "stacks".  You can see a small sample of what it does
here: https://gist.github.com/davexunit/db4b9d3e67902216fbdbc66cd9c6413e

- Dave

guile-next package needs new native-search-paths

[Thompson, David]

Hey everyone,

First of all: Thanks, Ludo, for the new guile-next package.  I tried
building it myself but couldn't figure out how to make the test suite
pass.

There's just one small issue: The native search paths are wrong.  They
are using the 2.2 search paths currently and thus you can't use it
as-is to develop projects that depend on other Guile libraries. The
fix is just to add this to the package recipe:

(native-search-paths
 (list (search-path-specification
(variable "GUILE_LOAD_PATH")
(files '("share/guile/site/3.0")))
   (search-path-specification
(variable "GUILE_LOAD_COMPILED_PATH")
(files '("lib/guile/3.0/site-ccache"
 "share/guile/site/3.0")

Any objection to me pushing a commit that does this to master?

- Dave

Re: Have GPGPU support in guix?

[Thompson, David]

On Thu, Apr 26, 2018 at 11:31 PM, Chris Marusich  wrote:
> Jonathan Brielmaier  writes:
>
>> On 26/04/2018 10:04, Mark H Weaver wrote:
>>> What about firmware?  Do we know which AMD Radeon cards, if any, can be
>>> used without including nonfree software in the OS?
>>
>> I'm not aware of an AMD/ATI Radeon card which doesn't need nonfree
>> firmware. The in-tree firmware in kernel goes back until ATI Radeon
>> R100[0], out-tree (linux-firmware.git) are all cards who run the amdgpu,
>> radeon or r600 kernel driver. So no card without nonfree firmware in the
>> last ~20 years...
>>
>> There could be some Nvidia cards who doesn't need nonfree firmware
>> according to [1]. It have to be before Geforce 8000[2].
>>
>> AFAIK Intel integrated GPUs didn't need nonfree firmware.
>>
>> [0]
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/firmware/radeon?h=v4.4.129
>> [1]
>> https://unix.stackexchange.com/questions/393504/which-amd-ati-cards-dont-require-non-free-firmware-when-using-radeon
>> [2] https://en.wikipedia.org/wiki/GeForce_8_series
>
> Are there any new graphics cards being made today by anybody, which do
> not require non-free firmware?  I don't know much about the state of
> graphics cards in the GNU/Linux world, but I'm very curious about it.

I'm not aware of a single new GPU that fits the bill. Last year I
bought the most recent NVIDIA GPU I could find that works blob-free
with nouveau drivers, the GTX 770. That will last me awhile but I
don't know what I will do when it becomes too weak to handle modern
software. Furthermore, I don't know what to do when my Thinkpad X220
and it's aging Intel GPU are no longer good enough, since all new
Intel GPUs also require firmware blobs. The future looks bleak.

- Dave

Re: Preferred blog format - Markdown or SXML?

[Thompson, David]

On Sun, Apr 22, 2018 at 10:22 AM, Adam Massmann  wrote:
>
> Hi,
>
> Pierre Neidhardt  writes:
>
>> What about Org-mode?
>> Rationale:
>>
>>   http://karl-voit.at/2017/09/23/orgmode-as-markup-only
>
> The website uses the haunt [1] static site generator which
> does not currently support direct reading of org files. However, you
> could easily export an org file to one of the supported formats (like
> html).

If anyone writes an org-mode parser in Guile, let me know and I'll add
support for it in Haunt. I wouldn't even know where to begin with
trying to parse org files. :)

- Dave

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

[Thompson, David]

Hello everyone,

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/

The slide stream is not incorporated into the video, so you can
download them separately and follow along:

https://git.dthompson.us/presentations.git/blob_plain/HEAD:/2018-03-25-guix-libreplanet/guix-libreplanet.pdf

Enjoy!

- Dave

Re: Guix orchestration notes

[Thompson, David]

Hi Chris,

On Sat, Feb 17, 2018 at 11:37 PM, Chris Marusich  wrote:
> Hi,
>
> At FOSDEM, some of us discussed "orchestration", which means something
> like "how to deploy services to more than 1 machine in a coordinated
> fashion".  Many people contributed to the discussion.  I took notes.
> I've thought about this more, reviewed the "wip-deploy" branch, and
> written up my thoughts in the attached file.
>
> It's a rough sketch of ideas, biased with my own opinions and
> experience, but I think it's good enough to share.  I invite you to
> improve upon it: share your own thoughts, hack some code together, and
> just iterate on this a bit, so we can make some progress.
>
> Hopefully, we can agree on a basic design and get a working proof of
> concept.  Then we can make a blog post about it!

These are good notes, thanks for sharing them!

One additional use-case I would consider for an orchestration tool
would be so-called "immutable deployment", where virtual machines are
replaced entirely rather than updated in-place. This is commonly used
for deploying web applications into auto scaling groups (where the
actual number of hosts at any given time is dynamic) using a
"blue-green" deployment technique (in a nutshell it's a double buffer
that allows updating the application without downtime and allows easy
rollback in the event the deploy breaks critical functionality).  This
is the kind of thing that I do at my day job, and we are but one of
many companies that do things this way.

- Dave

Re: [orchestration] AWS public cloud images

[Thompson, David]

Hi Mark,

On Mon, Mar 26, 2018 at 4:18 PM, Mark Meyer  wrote:
> Hi,
> I've the beginning of Guix cloud images available over at Github at
>
>   https://github.com/ofosos/guix-packer/
>
> There's a small writeup of what has been done and what's still missing over 
> here:
>
>   https://ofosos.org/2018/03/26/guix-images-01/
>
> All in all, I split the heavy lifting between Packer (AWS API calls) and 
> `guix system` and that worked remarkably well. There's some integration with 
> EC2 (You can inject a pubkey into the image via the console), but there's 
> also a lot of stuff missing. In the end, I would like to provide public cloud 
> images in some weeks time. Of course you'll have all the tools to rebuild 
> your own images (surprisingly simple).
>
> I think there's still a lot of polish we can apply, but at some point we'll 
> need some help from AWS. I do have AWS support access at work, but am not 
> really comfortable to use company resources for this yet, but I'll probably 
> ask if there's some  avenue to get some 'official' help as a free software 
> project, when I run across our technical account manager.

First of all: Thanks! This is a great start! I've wanted to run GuixSD
EC2 instances for some time but haven't gotten around to it. The more
I think about it, though, the more I wonder how useful an official
GuixSD image is vs. providing software to create AMIs for any given
system configuration. The use-case I'm particularly interested in is
using GuixSD instances in auto scaling groups.  I'm wondering if
there's any other way to create GuixSD AMIs than starting from some
official image, updating Guix, running 'guix system reconfigure', and
using the result as the basis for the AMI. While this ought to work,
it feels very imperative and hacky.  In the future it would also be
great to eliminate the need for Packer entirely and replace it with
Guile.

Anyway, just some food for thought.  Awesome work!

- Dave

Re: Status of "GuixOps"?

[Thompson, David]

On Sun, Sep 17, 2017 at 2:34 PM, Hartmut Goebel
 wrote:
> Hi,
>
> in Ludo's presentation at GHM he presented "GuixOps" on a slide. What is
> the status of this approach? I'm very interested in trying it out and
> contributing.

I made a wip-deploy branch years ago that allowed you to describe a
cluster of machines and then launch them all simultaneously with qemu.
It was an interesting prototype but nothing has been done since.  I
have since become a full-time DevOps person and have some opinions
about how 'guix deploy' ought to work.  The most important thing is
that there needs to be a generic interface for
creating/updating/destroying machines that can be implemented for bare
metal machines on some LAN, VMs at some VPS provider, VMs at AWS, VMs
on OpenStack, etc.  I think it's also important to support both
in-place updates and "immutable deploys".  A bare metal machine would
need an in-place update, but an Amazon EC2 instance in an auto-scaling
group could be replaced entirely.  As a long term thing, I think that
we need to leave a door open for supporting the all-inclusive
infrastructure creation tools like OpenStack's HEAT templates and
Amazon's CloudFormation.  I use CloudFormation extensively at my day
job and a tool that just managed EC2 instances for me wouldn't cut it.
In summary I think that we need to think carefully about what a
convenient interface is for someone managing a few personal servers
and implement that without making it impossible to scale up to more
"enterprise" use-cases later.

> I contributed to DebOps when it was "young". So my point of view is
> influenced by how DebOps works. DebOps is a collection of interoperating
> role/recipes for Ansible. Debops has become quite complex and I would
> like to migrate to GuixSD for new systems.

Yeah, anything based on the status quo configuration management tools
is bound to be overly complex.  With Guix we can do s much better,
we just need some free time, a plan, and a few good hackers. :)

> Q1: I did not follow the development closely, but I seem to recall that
> there is some guix sub-command for configuring a remote system. But
> grepping the manual for "remote", I did not find it, neither one of the
> commands did attract me. How is it called?

I haven't tried it but I think Ludo said that it was going to be a
flag to 'guix system'.  Has that code been merged?  Not being able to
easily connect to a remote daemon is what blocked me when I first
tried writing 'guix deploy'.

> Q2: DebOps has some tooling to securely store credentials, certificates,
> etc. It uses a gpg-encrypted container which is mounted using FUSE. When
> I unlock this container, the appropriate data is transferred to the
> target system. How can this be handled with GuixSD? AFAIU with GuixSD
> all data in the system-configuration is world-readable in the store. So
> how can I automatically transfer e.g. passwords and private keys the the
> target system?

I don't think that is the best approach, or at least it should not be
an approach that GuixSD users *have to* use.  I use Chef at work, and
the equivalent technology there is called "encrypted data bags"
(terrible name, I know).  They are a pain and thus we do not manage
secrets with it.  You're right, everything in the store is
world-readable, therefore you should never store secrets there.  The
most important thing to know is that secrets are stateful, which
contrasts with many things in Guix that are stateless.  Secrets can't
be configured at build-time, it has to be done at runtime.  So how do
we get secrets onto machines?  I think this is a job for GuixSD system
services.  Let's take for example a web application that connects to a
MariaDB database.  When the web application service starts, it will
fetch the database password from the secret store and initialize the
application with it by whatever means is supported (command line flag,
environment variable, etc.).  The secrets store could be a local
GPG-encrypted file (getting the decryption key onto the machine is
non-trivial, of course) or an external service.  To give you an idea
of the possibilities available when it comes to secrets management,
I'll give a more complex example.  All of my experience with this is
with Amazon web services, so if you don't know AWS stuff you can skip
this part but I'll describe it anyway for people that might be
interested: EC2 instances are assigned an IAM role that allows them to
decrypt a set of secrets that have been encrypted using a KMS key.
The encrypted secrets happen to be stored in a DynamoDB table.  A
command line tool for fetching the secrets is installed on the
instances and is integrated into the application startup processes
that need secrets.  When we want to rotate a key, we replace the
DynamoDB record with a new one and restart the relevant services.
Whether the secrets are stored in an encrypted file on each machine or
in some external database, the basic process is 

Re: My experiences with GuixSD

[Thompson, David]

Hello Jonathan,

On Fri, Sep 8, 2017 at 6:58 PM, Jonathan Brielmaier
 wrote:
> Hello Guix,
>
> two weeks ago I got a new desktop computer. I decided to remove the
> ubuntu on it and tried to install GuixSD on it. I'm not a
> super-linux-crack just an "average" user.
>
> I'll describe my experiences and ask some questions/give some input
> (indicated with "=>").
>
> 1. I had a hard time during installation on the "live-system" to figure
> out how to do the GRUB setup the right way. The error was quite simple:
> I only have to write "target /dev/sda" instead of "target /dev/sda1".
>
> => Beside I'm not very experienced with setting up GRUB, something like
> "guix lint" for the system config would be nice :)

I agree. Something that would detect that you are trying to install
GRUB to a partition instead of the disk itself would be nice.

> 2. After booting in the installed GuixSD the fonts were awful and I
> didn't get them to a better state.
>
> => I never saw such "bad rendered" fonts on other Linux distributions.
> It would be nice if the default font setup would be more pretty. (could
> be connected to 3.)

What desktop environment were you using?  I use GNOME and it's default
configuration is quite nice, I think.  Please note that unlike Ubuntu,
GuixSD is not a "just works" distro for beginners at this time.  It's
essentially a framework for creating your own distro.  Making things
nice is generally up to you.  Maybe if you point out which desktop
environment had the displeasing fonts we could potentially make the
default better.

> 3. The system was using CPU (llvmpipe or how it's named) as renderer and
> not the GPU. I have an AMD Radeon RX 480 card which worked quite well on
> Ubuntu with FOSS driver. I added a package which includes the non-free
> firmware, but after all I didn't got GPU rendered distro :(
>
> => I bought an AMD card because of there all-open Linux drivers and I
> want to support them in that way (=> Nvidia...). The drivers work well
> on other distros. I know they need non-free firmware, I don't like it
> but there is no "real" alternative. Having just CPU accelerated graphic
> is for me a blocker to _not_ use GuixSD. What can we do to solve or just
> to ease that situation?

The solution is for the graphics card vendors to stop shipping
proprietary firmware.  The Guix project has no power over these
companies.  Instead of thinking of things that we are powerless to
change, we can focus on what we can.  We could do a better job of is
pointing users to places where they can get hardware that is
compatible.  I run GuixSD on a laptop and a desktop with fully free
GPU drivers as I use compatible Intel and Nvidia GPUs, respectively.
This works because I knew from many years of using fully free distros
that Linux, despite being allegedly free, ships lots of proprietary
firmware that linux-libre removes, and purchased hardware accordingly.
I think it should be easier for newcomers to discover if their systems
are compatible and what they can do to fix the incompatible bits.

> 4. Icecat... I had to restart it like every five minutes because it
> doesn't show websites. Yes, I disabled all those add-ons (LibreJS etc.).
> It was not usable for me, really not. And without all those FOSS add-ons
> on addons.mozilla.org Icecat/Firefox is bad.
>
> => Could we not just have a Firefox ESR version without DRM, Pocket and
> the other closed-source stuff, but _with_ the ability to install add-ons
> and stability?

Maintaining our own Firefox fork would take a lot of effort.  Instead
it would best to send feedback to the IceCat maintainer so they can
set better defaults.  I don't use LibreJS either.  I will say right
now that pointing to addons.mozilla.org isn't going to ever happen as
long as Mozilla continues to encourage users to install proprietary
extensions.

> After lots of hours (10-20h) investing in the setup of GuixSD I decided
> to install Ubuntu as the system was not "usable" for me :(
>
> Beside those "negative" records I have to say: guix package rocks
> (install, environment...)!!!
>
> So for the moment I stay a guix user on foreign distros :P

Thanks for the feedback.  Sorry that GuixSD doesn't work for you.  I
would say that the GPU and IceCat things are "won't fix" (these aren't
GuixSD problems, nor really problems at all, they are facts of life
for running a system that fully respects your freedom), and the GRUB
and font thing could definitely be improved with some effort.

Thanks!

- Dave

Re: The future of 'guix environment'

[Thompson, David]

On Sun, Sep 3, 2017 at 3:15 AM, Jan Nieuwenhuizen  wrote:
> Ludovic Courtès writes:
>
>>> I do use guix.scm for testing `guix build'.  Maybe I ma the only one
>>> though.  It turns out to be very useful to find out whether or not I've
>>> done something that borked my package that's not obvious because I have
>>> some compiled .go file around in working directory or something.
>>
>> I use it too, occasionally!  :-)
>
> Me too!  It's great to test if all is fine.  What I'm also using is your
> git-file? hack
>
> https://git.dthompson.us/guile-sdl2.git/blob/HEAD:/guix.scm
>
> does anyone see a nice way to put that function/functionaly in guix?

git-file? was snarfed from some internal Guix code that Ludovic wrote.
I would also like to see a public API for it.

- Dave

Re: The future of 'guix environment'

[Thompson, David]

On Fri, Sep 1, 2017 at 7:50 AM, Jan Nieuwenhuizen  wrote:
>
> One thing I didn't see in your proposal is something like
>
> guix environment --manifest manifest.scm
>
> It really bothers me that I can only declaritavely populate/maintain
> named profiles.  Do you have an idea about that?

Never thought about it before.  Maybe --load could support evaluating
to a package, a manifest, or an environment?  Seems like that might be
getting into crazy territory, but maybe not.

- Dave

Re: The future of 'guix environment'

[Thompson, David]

On Thu, Aug 31, 2017 at 11:57 PM, Christopher Allan Webber
<cweb...@dustycloud.org> wrote:
> Thompson, David writes:
>
>> Ricardo, you are correct that we would lose the ability to use the
>> guix.scm file for both 'guix environment' and 'guix build'.  In
>> practice I don't actually use my guix.scm file this way, so I think
>> it's worth breaking, but maybe you (or someone else) actually uses
>> this and we should think more about it?
>
> I do use guix.scm for testing `guix build'.  Maybe I ma the only one
> though.  It turns out to be very useful to find out whether or not I've
> done something that borked my package that's not obvious because I have
> some compiled .go file around in working directory or something.

Ludovic's suggestion of supporting both package and environment
objects with --load will solve the issue.

>> I wasn't very clear about whether ephemeral or cached would be the new
>> default.  I don't think there is one default for all cases, I think
>> it's more context sensitive.
>
> I'm a bit confused by caching, but IMO maybe the right solution is
> actually guix environment for "environment profiles".  Ie, I want to be
> able to update my guix environment and if it turns out I made a mistake
> easily roll back, just like I can with my user's profile.  Currently
> you can use --root, but you don't have the generations support.

This is what caching would allow.

- Dave

Re: The future of 'guix environment'

[Thompson, David]

On Thu, Aug 31, 2017 at 11:16 AM, Ludovic Courtès <l...@gnu.org> wrote:
> Heya,
>
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> If you've followed along this far, great!  Now here's my list of
>> proposed changes:
>>
>> 1) Add a caching mechanism.  The environment profile should get built
>> once, and then a symlink to it should be created in $PWD and
>> registered as a GC root.  This will, of course, require re-using some
>> 'guix package' code to delete the profile.  For the sake of the rest
>> of this post, let's say that a --cache flag does this, and a --update
>> flag forces a rebuilding of the cached profile.
>
> One way to put it is that ‘guix environment’ would be syntactic sugar
> for ‘guix package -p $PWD/.guix-environment’, right?

Yeah, I guess so.  I've never used the -p flag and don't know if it
should stay.  I'll try to preserve it and see how that goes!

> This would make “guix environment” stateful: if you have something in
> cache, that’s what you get (it could be old versions of “foo” and
> “bar”), but if you don’t, you get the current versions of “foo” and
> “bar”.  Is this what you have in mind?

Yes. For regularly hacked on project environments I think this is the
most useful behavior.  Because then, much like my regular user
profile, I can update at a time when I feel ready to do so, rather the
current situation where I'm forced to rebuild and deal with potential
breakage or long download/compile times.

> I prefer the current stateless behavior, whereby “guix environment
> --ad-hoc foo bar” always gives you the same environment, given a Guix
> commit.  But maybe we can make “guix environment” (no arguments)
> stateful, and keep “guix environment foo bar baz” stateless?

That's what I had in mind.  In my head there's two important cases:
the on-the-fly, stateless environment, and the persistent environment
that you update every now and then when you feel like living on the
edge.  'guix environment foo bar' (ad-hoc being the new default)
should absolutely be stateless, just like it is now.

>> 3) Change how --load behaves.  Instead of evaluating a file and
>> expected a package object in return, instead expect a
>>  record.  This would provide a declarative way to
>> specify the complete environment: which packages to pull in, whether
>> to purify the environment (--pure), whether to run in a container
>> (--container), whether to give the container network access
>> (--network), etc.  Command line flags would take precedence over what
>> is specified in the config file.  --load may only appear *once* in the
>> command line args, whereas now it many appear N times.
>
> +1, probably with automatic conversion of  to , as
> I wrote in another message.

Ah, this is a clever hack!  I will do that.  Thanks for suggesting it.

>> 4) Make 'guix environment' with no other args operate like 'guix
>> environment --cache --load=guix.scm'.  'guix.scm' is a placeholder
>> name for whatever we decide the conventional name for an environment
>> config should be.  Throwaway environments (such as 'guix environment
>> ruby -- irb') would not have caching turned on by default, because
>> that would quickly become a burden.
>
> +1, except perhaps for --cache, not sure.

I think I will convince you it's a good idea. ;)

> Also, I would prefer the convention to be “.guix.scm” (to avoid
> confusion with the (guix) module, and to mimic existing conventions
> followed by Travis and all that.)

Sure, that's fine with me, but FYI there are existing conventions of
using non-hidden files. Bundler uses 'Gemfile', Docker uses
'Dockerfile', Vagrant uses 'Vagrantfile', npm uses 'package.json',
etc.

> Bonus: honor “.guix.json” (see <https://bugs.gnu.org/28251>) as one way
> to get us closer to world domination.

Maybe someone else can add that after I do everything else. :)

> I’d rather not add a new command, which means we’ll have to agree to
> break the “guix environment” CLI.  I think that’s OK, but we should
> discuss it.

I agree.  We can discuss more when I have patches.  I will probably
have additional questions as I go.  The biggest unknown for me so far
is how environment profile generation management will work (if it
should even exist), but I'll get the basics sorted out first.

Thanks for your feedback!

- Dave

Re: The future of 'guix environment'

[Thompson, David]

On Thu, Aug 31, 2017 at 3:18 AM, Jan Nieuwenhuizen <jann...@gnu.org> wrote:
> Thompson, David writes:
>
>> Hi all, been awhile!
>
> Hi David!
>
> Great suggestions all!  I use guix environment heavily and like it a
> lot.

Thanks!

>> 4) Make 'guix environment' with no other args operate like 'guix
>> environment --cache --load=guix.scm'.  'guix.scm' is a placeholder
>> name for whatever we decide the conventional name for an environment
>> config should be.
>
> Wouldn't that be
>
> guix environment --cache --dependencies --load=guix.scm

No, because guix.scm would no longer evaluate to a package object, but
an environment object.  Flags like --dependencies are for environments
defined on the fly at the command line.  I haven't yet decided if
--load should be mutually exclusive from all those other things, but I
think that should probably be the case.  Perhaps introducing
subcommands is the best thing UX-wise.  'guix environment load
guix.scm', 'guix environment shell direnv --dependencies ruby', and
'guix environment' would be a shorthand for 'guix environment load'.
This will take some fiddling to see.  I'm going to get the core
features implemented first, then work on the UX.

> I have been using an ugly hack to switch profiles (or environments; look
> at $GUIX_ENVIRONMENT) in Emacs, see attached.  As discussed briefly on
> irc yesterday are various ways this could go: use emacs-direnv, read the
> manifest file in elisp, use guix repl to read it..etc

I took a look at emacs-direnv and did not like it because it's not
fully implemented in elisp. You also need the direnv tool itself,
which is written in Go. No thanks!  I think the integration should
happen with emacs-guix, which could use the Guile REPL to read the
profile manifest, and send an sexp back to Emacs with key/value pairs
for the values of all environment variables.  From there it's easy to
use setenv and tweak exec-path in the case of $PATH.  Alex Kost would
know a lot better than I about how to get this done.

- Dave

Re: The future of 'guix environment'

[Thompson, David]

Thanks for the feedback, everyone.  I'm going to try to address what
everyone has been discussing.

宋文武, I agree with Andreas that making a new command is undesirable and
would just lead to confusion.  I think a single tool can support the
major use cases well.  I'd go so far as to say that I will have failed
if two commands are necessary.  We can always add subcommands to 'guix
environment' itself, if that turns out to be better for usability.  We
will see.

As for a 'guix environment up' command, I think that's worth thinking
about but I'm going to avoid thinking about it too much because we're
still quite a ways off from being able to make this happen.  My
general feeling is the same as Ricardo's, though, that 'guix
environment' should just spawn the services automatically and there
would have to be some notion of "attaching" to an existing session.
This topic deserves a whole separate thread when the time comes.

Ricardo, you are correct that we would lose the ability to use the
guix.scm file for both 'guix environment' and 'guix build'.  In
practice I don't actually use my guix.scm file this way, so I think
it's worth breaking, but maybe you (or someone else) actually uses
this and we should think more about it?

I wasn't very clear about whether ephemeral or cached would be the new
default.  I don't think there is one default for all cases, I think
it's more context sensitive.  When the user specifies --load, I think
caching should be the default because loading such a file means that
you are working on a project for which you'd like a persistent
environment.  When the user specifies ad-hoc packages, caching would
be disabled because most likely they are running a one-off job.  For
example, 'guix environment ruby -- irb' should spawn a Ruby REPL,
discarding the environment when the user exits.  'guix environment
--load=guix.scm' would check for a cached profile, use it if it is
there, otherwise build the profile and cache it for next time.  'guix
environment', without --load or any packages specified, would be
equivalent to 'guix environment --load=guix.scm'.  A little
"convention over configuration" will greatly improve usability, I
think.  There's really only 2 major use cases, and I want those to
work without having to fiddle with a bunch of command line flags.  All
the underlying flags will still be there to fiddle with for those who
are interested.

- Dave

The future of 'guix environment'

[Thompson, David]

Hi all, been awhile!

I wrote the initial version of 'guix environment' almost 2 years ago,
and have used it constantly since.  It was a great start, but from my
own experiences and feedback from others, I have identified a number
of areas that need improvement.  Fixing them will require breaking
changes, but I think it's important to break things sooner rather than
later because after 1.0 it will be a hard sell.

By far the most annoying thing is that leaving and coming back to a
project (say, after a reboot) may entail rebuilding your entire
environment if you have updated Guix in between.  What was supposed to
be a quick hack turns into a long Guix maintenance session,
potentially building things from source and dealing with build
failures.

As an avid Emacs user, I want to do everything in Emacs, but if I want
to use, say, M-x compile but in the context of my development
environment, I have to wrap the command in 'guix environment' and now
everything takes way longer because Guix wastes tons of time talking
to the daemon to build a profile that I know already exists.   This
goes hand in hand with the previous issue.  We need a cache.

Another issue is that 'guix environment' doesn't have any sane
defaults to speak of.  In the Ruby world, the 'guix environment'
equivalent is called Bundler.  When you want to work on someone's Ruby
project, you enter the source tree and run 'bundle'. No other
arguments.  It fetches everything you need based upon a configuration
file, which by convention is named 'Gemfile'.  There's no good reason
why 'guix environment' cannot be this simple to use.

The default behavior of 'guix environment foo' creating an environment
with the *dependencies* of the package 'foo' seemed like a good idea
at the time (it's what nix-shell did, after all), but most of the time
when I define throwaway environments on the command-line (as opposed
to a guix.scm file) I *always* use the --ad-hoc flag.  Using the
packages themselves rather than the dependencies should be the
default.

The final issue is more of a wishlist thing, but I think it is
something that will make 'guix environment' far and away the most
powerful development environment setup tool there is.  We should be
able to define more than just what packages to include in the
environment.  We should be able to define services, too.  A great
use-case for such a feature is a web application.  Think about how
convenient it would be if a newcomer to a project could run 'guix
environment' and have nginx and mysql automatically launched for them
with the proper configuration.  The closest tool to this today would
be Docker's 'compose' tool, which can manage many containers, each
running a single service.  Surely we can do better than that!

If you've followed along this far, great!  Now here's my list of
proposed changes:

1) Add a caching mechanism.  The environment profile should get built
once, and then a symlink to it should be created in $PWD and
registered as a GC root.  This will, of course, require re-using some
'guix package' code to delete the profile.  For the sake of the rest
of this post, let's say that a --cache flag does this, and a --update
flag forces a rebuilding of the cached profile.

2) Make "ad-hoc" the default.  Remove the --ad-hoc flag and replace it
with a --dependencies flag instead, reversing the current behavior.
'guix environment --dependencies guix' would create a guix dev
environment, for example.

3) Change how --load behaves.  Instead of evaluating a file and
expected a package object in return, instead expect a
 record.  This would provide a declarative way to
specify the complete environment: which packages to pull in, whether
to purify the environment (--pure), whether to run in a container
(--container), whether to give the container network access
(--network), etc.  Command line flags would take precedence over what
is specified in the config file.  --load may only appear *once* in the
command line args, whereas now it many appear N times.

4) Make 'guix environment' with no other args operate like 'guix
environment --cache --load=guix.scm'.  'guix.scm' is a placeholder
name for whatever we decide the conventional name for an environment
config should be.  Throwaway environments (such as 'guix environment
ruby -- irb') would not have caching turned on by default, because
that would quickly become a burden.

5) Add support for Shepherd services.  When an environment is created,
a new Shepherd process is launched to handle all the necessary
services.  For a web application this could be nginx, mysql, redis,
etc.  This feature can be implemented later, even post 1.0, provided
we agree upon using a  record type.

After all these changes, a Guix user should be able to jump into a new
project, run 'guix environment' and be ready to go.  When they update
Guix and want to refresh their environment, they would run 'guix
environment --update'.

Thoughts?

- Dave

Re: Combining Guix, direnv and Emacs for environment customisation

[Thompson, David]

Hello Christopher,

Reviving this old thread, if you don't mind. :)

On Sat, May 27, 2017 at 7:31 AM, Christopher Baines  wrote:
>
> In summary, using direnv provides a convinient way to manage different
> environments created from Guix. There is now support for using direnv
> directly from Emacs.

This is great.  I need to try it out sometime.

> One issue with this is that running guix environment from direnv will
> slow down switching buffers. To make it a bit more useable, I found
> some bash code that caches the results of running commands, and wrapped
> that around guix environment when invoked from direnv. This helps speed
> things up, but I don't think its useful in the long term.
>
> For this particular use case, it would help if guix environment was
> faster, perhaps by doing caching internally? On my system, running guix
> environment --ad-hoc guile --search-paths repeatedly takes ~2 seconds,
> I haven't looked at what the breakdown of this is yet.
>
> I'd be interested in hearing if anyone does something similar for using
> Guix, or if anyone does something different, but to the same effect?

There is a feature missing in 'guix environment': saving the resulting
profile for easy access later.  I often want to build an environment
once and not update it for awhile, but with the current state of 'guix
environment' it's not possible. This leads me to pulling my hair out
when I do an upgrade of Guix and have to rebuild all of my development
environments. What was supposed to be a quick hack turns into a Guix
maintenance session.

Let's imagine that the first time `guix environment` is invoked it
creates a symlink in $PWD to the generated profile named
.guix-environment.  Future invocations of 'guix environment' would
short-circuit all the daemon communication, package module loading,
etc. and just apply the environment variables in the already built
profile.  Once we have that built, emacs-direnv integration is as
simple as sourcing .guix-environment/etc/profile, or running 'guix
environment' if the profile is not yet built.

WDYT?

(If time permits, I'd like to start contributing to Guix again by
overhauling 'guix environment' to be more convenient for day-to-day
development)

- Dave

Re: [PATCH] update haunt to 0.2.1

[Thompson, David]

Hey Ludo,

On Tue, Jan 24, 2017 at 5:12 PM, Ludovic Courtès  wrote:
> Catonano  skribis:
>
>> From 015719506600bcb674b1d47398af27c2b4f32d18 Mon Sep 17 00:00:00 2001
>> From: humanitiesNerd 
>> Date: Tue, 24 Jan 2017 14:55:12 +0100
>> Subject: [PATCH] gnu: haunt: Update to 0.2.1
>>
>> * gnu/packages/guile.scm (haunt): Update to 0.2.1.
>
> Applied, thanks.  :-)
>
>>  (propagated-inputs
>> - `(("guile-reader" ,guile-reader)))
>> + `(("guile-reader" ,guile-reader)
>> +   ("guile-commonmark" ,guile-commonmark)))
>
> We could (should?) avoid this by augmenting the ‘wrap-haunt’ phase.
>
> Thoughts?

Agreed, but even better would be if I knew how to make upstream just
do the right thing to begin with. ;)  Do you know how this could be
done?

Thanks,

- Dave

Re: [PATCH] scripts: container: Pass through TERM when calling exec

[Thompson, David]

Hey Christopher,

On Wed, Jan 25, 2017 at 2:24 AM, Christopher Baines  wrote:
> * guix/scripts/container/exec.scm (guix-container-exec): Capture the value of
>   the TERM environment variable, and pass it through to the container.  This
>   means some applications now work where they did not before (e.g. htop), and
>   others have more functionality, providing that the terminal was capable of
>   enabling that functionality in the first place.

Good idea! Thanks for doing this!

- Dave

Re: [PATCH] gnu: services: Add redis-service

[Thompson, David]

Hello,

On Tue, Jan 10, 2017 at 2:24 AM, Christopher Baines  wrote:
>
> diff --git a/gnu/services/databases.scm b/gnu/services/databases.scm
> index d88c839f7..b6bdd6080 100644
> --- a/gnu/services/databases.scm
> +++ b/gnu/services/databases.scm
> @@ -35,7 +35,11 @@
>  mysql-service
>  mysql-service-type
>  mysql-configuration
> -mysql-configuration?))
> +mysql-configuration?
> +
> +redis-configuration
> +redis-configuration?
> +redis-service-type))
>
>  ;;; Commentary:
>  ;;;
> @@ -287,3 +291,78 @@ database server.
>  The optional @var{config} argument specifies the configuration for
>  @command{mysqld}, which should be a @code{} object."
>(service mysql-service-type config))
> +
> +
> +;;;
> +;;; Redis
> +;;;
> +
> +(define-record-type* 
> +  redis-configuration make-redis-configuration
> +  redis-configuration?
> +  (redis redis-configuration-redis ;
> + (default redis))
> +  (bind  redis-configuration-bind
> + (default "127.0.0.1"))
> +  (port  redis-configuration-port
> + (default 6379))
> +  (working-directory redis-configuration-working-directory
> + (default "/var/lib/redis"))
> +  (config-file   redis-configuration-config-file
> + (default #f)))

I'm seeing a trend where people write services with configuration
types that don't cover nearly the amount of configuration options to
make the service useful.  MySQL, and now this Redis server, are
examples of this.  There are many more configuration options in Redis
than this service exposes.

What do we do?

- Dave

Re: Emacs-Guix released outside from Guix

[Thompson, David]

Hey Alex,

On Thu, Dec 15, 2016 at 9:48 AM, Alex Kost  wrote:
> Hello, I've been working on Emacs interface outside from the Guix repo
> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(

Sorry to hear about this.  This move will make it difficult for me to
use guix.el moving forward due to inevitable API incompatibilities, so
I've decided to just stop using it.  I hope that one day this code
will come back into the guix source tree.

- Dave

Re: ‘guix copy’

[Thompson, David]

Hi Ludo,

On Sat, Dec 31, 2016 at 12:40 PM, Ludovic Courtès  wrote:
> Hello Guix!  :-)
>
> I’m pleased to announce the last(?) feature of the year: ‘guix copy’!
> It copies store items over SSH, pretty much like ‘guix offload’ already
> does; documentation below.
>
> Currently there’s no progress report and error reporting is suboptimal,
> but I find it useful already.
>
> Feedback welcome!

This is awesome!  I really wanted such a feature back when I was
poking around with a 'guix deploy' prototype.  Now I could use the
Scheme API to 'guix copy' to build an OS on my workstation, then ship
it to one or more remote machines and use guile-ssh to run the code to
instantiate it.  Exciting!

- Dave

Re: [PATCH] make nginx service extensible

[Thompson, David]

Hi Julien,

On Tue, Dec 13, 2016 at 3:56 PM, Julien Lepiller  wrote:
> Hi,
>
> here are three patches for the nginx service. I finally worked on
> them.
>
> 1. s/vhost/server/ in the web.scm and guix.texi
> 2. fix a mistake with the list of names and index.
> 3. make the service extensible, change the default options and document
>it.
>
> I hope that's correct now :)

Thank you for making these improvements.  I wrote the original
barebones nginx-service and just never got around to making it
extensible.  This should make a bunch of people very happy. :)

- Dave

Re: Graphical Installer - Call for Testing.

[Thompson, David]

Hi John,

On Wed, Jan 4, 2017 at 2:59 AM, John Darrington
 wrote:
> The wip-installer branch is ready for testing and general review.
>
> This branch provides a curses based graphical interface to the disk
> images used for installing GuixSD. It is intended to allow users
> unfamiliar with bash and other aspects of unix-like operating systems
> to easily install GuixSD.   This means, it should allow you to install
> GuixSD on a bare PC, without ever touching a shell (whilst still
> providing that option for those who want it).

I don't have any real feedback, but I just want to say that this is an
awesome initiative that will make GuixSD accessible to many more
people!  Thanks for working on this!

- Dave

Re: [PATCH] Creating a docker image with Guix

[Thompson, David]

Hi Ricardo,

This is awesome! Just a couple things:

1) The amd64 architecture is hardcoded in the image.  Should this
instead be set to the current architecture?
2) s/configuratio/configuration/ in the docstring for 'config' in
guix/docker.scm

Ludovic, Ricardo, anyone else: It might be nice if in the future 'guix
environment' had a flag to output the resulting profile instead of
having to spawn the sub-shell and refer to $GUIX_ENVIRONMENT.  Food
for thought. :)

LGTM (Let's Get This Merged)!

- Dave

[PATCH] gnu: mesa: Enable floating point textures.

[Thompson, David]

With this patch, I'm finally able to run programs that require OpenGL
3.0 when using a Nouveau powered GPU.  Floating point textures are
disabled by default in Mesa due to patent concerns.  I assume that
it's okay to include this in Guix because it's similar to how we
include lame despite MP3 being patent encumbered.  Please correct me
if I'm wrong! ;)

- Dave
From 1a8de1631ec4d538bdb9caa8b623e8bb62a6c203 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sat, 12 Nov 2016 17:59:16 -0500
Subject: [PATCH] gnu: mesa: Enable floating point textures.

* gnu/packages/gl.scm (mesa): Add --enable-texture-float to configure flags.
---
 gnu/packages/gl.scm | 4 
 1 file changed, 4 insertions(+)

diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index 50b474c..a663b3b 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2014, 2015, 2016 Mark H Weaver 
 ;;; Copyright © 2016 ng0 
 ;;; Copyright © 2016 Ricardo Wurmus 
+;;; Copyright © 2016 David Thompson 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -257,6 +258,9 @@ also known as DXTn or DXTC) for Mesa.")
  "--enable-gles2"
  "--enable-gbm"
  "--enable-shared-glapi"
+ ;; Without floating point texture support, drivers such as Nouveau
+ ;; are stuck at OpenGL 2.1 instead of OpenGL 3.0+.
+ "--enable-texture-float"
 
  ;; on non-intel systems, drop i915 and i965
  ;; from the default dri drivers
-- 
2.6.3

Re: [PATCH] gnu: Add emacs-lua-mode.

[Thompson, David]

On Thu, Oct 20, 2016 at 12:52 PM, ng0  wrote:
> Hi,
>
> We already have lua-mode, what is the difference with this one?
>
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=26e08b4d33918a844a42fd0f859ee640990ca757

The difference is that I didn't notice that package and duplicated
work, which is a bit embarrassing.

Let's pretend this thread never happened! :)

Thanks,

- Dave

Redis security fix release 3.2.4 now available

[Thompson, David]

I just pushed an update to our Redis package (commit
5f4194f68728531f09596bb359c58addf86efc5e) to address a security
vulnerability which has been out for 16 days:


https://github.com/antirez/redis/commit/6d9f8e2462fc2c426d48c941edeb78e5df7d2977

The set of people using Redis provided by Guix on production servers
is probably 0 at this time, but letting the list know just in case. ;)

- Dave

Re: guix environment guix doesn't provide guix dependencies?

[Thompson, David]

On Wed, Sep 28, 2016 at 5:20 PM, Ludovic Courtès  wrote:
> Hi Chris,
>
> Chris Marusich  skribis:
>
>> John Darrington  writes:
>
> [...]
>
>>> I don't think so.   Running ./bootstrap is not part of the normal process 
>>> for *building*
>>> guix - only for bootstrapping.  But you are right - it is common to want to 
>>> do that.
>>> For this reason I often run:
>>>
>>>  guix environment guix --ad-hoc automake autoconf texinfo help2man
>>>
>>>
>>> But perhaps you are right - the manual might want to mention this.
>>>
>>> J'
>>
>> That makes sense.  I feel like it used to provide all the dependencies,
>> including autoconf etc., but that was months ago, and I might be
>> mis-remembering.  It works fine when I add the needed bootstrap
>> dependencies with --ad-hoc.
>
> In fact there’s a small time window during which “guix environment guix”
> doesn’t provide autoconf et al.: it’s when the ‘guix’ variable in (gnu
> packages package-management) refers to a released tarball instead of a
> Git checkout, since a build from tarball doesn’t depend on autoconf et
> al.
>
> So if you run “guix environment guix” on a commit different from
> v0.11.0 + 1, you effectively get all the dependencies.
>
> I admit this is a bit confusing.  Not sure how to document/improve that.
>
> Ideas?

How about a public guix-devel package that always builds from the Git repo?

- Dave

Re: [PATCH 5/7] gnu: Add kiss-fft-for-extempore.

[Thompson, David]

On Wed, Sep 14, 2016 at 5:38 AM, Ricardo Wurmus  wrote:
> * gnu/packages/algebra.scm (kiss-fft-for-extempore): New variable.

LGTM.

- Dave

Re: [PATCH 6/7] gnu: Add portmidi-for-extempore.

[Thompson, David]

On Wed, Sep 14, 2016 at 5:38 AM, Ricardo Wurmus  wrote:
> * gnu/packages/music.scm (portmidi-for-extempore): New variable.
> ---
>  gnu/packages/music.scm | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
> index f294564..c62dbbc 100644
> --- a/gnu/packages/music.scm
> +++ b/gnu/packages/music.scm
> @@ -1081,6 +1081,23 @@ projects.")
>  using a system-independent interface.")
>  (license license:expat)))
>
> +(define-public portmidi-for-extempore
> +  (package (inherit portmidi)
> +(name "portmidi-for-extempore")
> +(version "217")
> +(source (origin
> +  (method url-fetch)
> +  (uri (string-append 
> "https://github.com/extemporelang/portmidi/;
> +  "archive/" version ".tar.gz"))
> +  (file-name (string-append name "-" version ".tar.gz"))
> +  (sha256
> +   (base32
> +"0gjikwciyr8kk4y3qiv1pcq58xpgw38ql1m2gs6g0qc1s8sx4235"
> +(build-system cmake-build-system)
> +(arguments `(#:tests? #f)) ; no tests
> +(native-inputs '())

Remove this line. ^

> +(home-page "https://github.com/extemporelang/portmidi/;)))
> +
>  (define-public python-pyportmidi
>(package
>  (name "python-pyportmidi")
> --
> 2.10.0

LGTM otherwise.

- Dave

Re: [PATCH 1/7] gnu: Add nanovg-for-extempore.

[Thompson, David]

On Wed, Sep 14, 2016 at 5:38 AM, Ricardo Wurmus  wrote:
> * gnu/packages/gl.scm (nanovg-for-extempore): New variable.

LGTM.

- Dave

Re: [PATCH 4/7] gnu: Add llvm-for-extempore.

[Thompson, David]

On Wed, Sep 14, 2016 at 5:38 AM, Ricardo Wurmus  wrote:
> * gnu/packages/llvm.scm (llvm-for-extempore): New variable.
> ---
>  gnu/packages/llvm.scm | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
> index a9eba79..b55a200 100644
> --- a/gnu/packages/llvm.scm
> +++ b/gnu/packages/llvm.scm
> @@ -3,6 +3,7 @@
>  ;;; Copyright © 2015 Mark H Weaver 
>  ;;; Copyright © 2015 Ludovic Courtès 
>  ;;; Copyright © 2016 Dennis Mungai 
> +;;; Copyright © 2016 Ricardo Wurmus 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -267,3 +268,10 @@ code analysis tools.")
>  (define-public clang-3.5
>(clang-from-llvm llvm-3.5 clang-runtime-3.5
> "0846h8vn3zlc00jkmvrmy88gc6ql6014c02l4jv78fpvfigmgssg"))
> +
> +(define-public llvm-for-extempore
> +  (package (inherit llvm-3.7)
> +(source
> + (origin
> +   (inherit (package-source llvm-3.7))
> +   (patches (list (search-patch "llvm-for-extempore.patch")))

This could use a comment explaining the rationale.  Also, you forgot
to include the patch file in this commit.

- Dave

Re: [PATCH 2/7] gnu: Add assimp.

[Thompson, David]

On Wed, Sep 14, 2016 at 5:38 AM, Ricardo Wurmus  wrote:
> * gnu/packages/graphics.scm (assimp): New variable.

Awesome!  Now someone can package guile-assimp. :)

LGTM.

- Dave

Re: [PATCH 3/7] gnu: Add stb-image-for-extempore.

[Thompson, David]

On Wed, Sep 14, 2016 at 5:38 AM, Ricardo Wurmus  wrote:
> * gnu/packages/image.scm (stb-image-for-extempore): New variable.

LGTM.

- Dave

Re: [PATCH] Adding .xsession to guile-wm

[Thompson, David]

On Mon, Sep 12, 2016 at 9:23 PM, Alex ter Weele
 wrote:
> I don't believe there is a standard, but different packages do it
> different ways. Under my patch, guile-wm will regenerate its .desktop as
> part of the build process, so its Exec= should be kept up-to-date.

We should always refer to the absolute path to binaries so that we
don't rely on $PATH, which would be nondeterministic.

- Dave

Re: [PATCH] Adding .xsession to guile-wm

[Thompson, David]

On Mon, Sep 12, 2016 at 11:56 AM, Alex ter Weele
 wrote:
> Manually making a .desktop is what xmonad and fluxbox do:
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/wm.scm#n244
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/wm.scm#n359
> Hence this approach. I could also work on moving this to a patch.
> Which is preferred?
>
> -Alex

Well... if we already have prior art then I suppose it's OK!  I'll let
someone else weigh in here and apply the patch.

Thanks for your contribution!

- Dave

Re: [PATCH] gnu: Add sonata

[Thompson, David]

On Sun, Sep 11, 2016 at 11:08 AM, Leo Famulari  wrote:
> On Sun, Sep 11, 2016 at 11:00:37AM +0100, Christopher Baines wrote:
>> * gnu/packages/mpd.scm (sonata): New variable.
>
> Thanks! Pushed as 6c86cef5d36d613be0a62f8f18e276232abf51f0.
>
> This will make it easier for my houseguests to control the stereo :)

This is awesome.  Thanks, everyone!  Sonata used to be my music player
of choice many years ago until it became unmaintained, but it looks
like there is a new maintainer!  I'll have to give it a go.

And using Sonata for visitors to control the stereo sounds like a
fantastic idea.

- Dave

Re: [PATCH] Adding .xsession to guile-wm

[Thompson, David]

On Sun, Sep 11, 2016 at 11:01 PM, Alex ter Weele
 wrote:
> Adding an xsession to guile-wm so that display managers will identify it
> as an available wm.

I think it would be best if this were submitted as a patch to guile-wm
upstream instead, and we can include the patch in the "patches" field
until a new release is made.

- Dave

Re: [PATCH] services: nginx: Actually check if configuration is valid.

[Thompson, David]

On Thu, Sep 8, 2016 at 10:21 PM, Tobias Geerinckx-Rice <m...@tobias.gr> wrote:
> Dave,
>
> On 09/09/16 04:09, Thompson, David wrote:
>> Maybe this could be done at build-time instead?
>
> The nginx service points to a stateful configuration file, like
> /etc/nginx.conf, that isn't built or handled by Guix.

No, it doesn't.  I wrote the nginx service.  The config file used is
part of the g-expression and is absolutely not stateful.

> I'd like that to change, but that will have to wait for now.
>
>> Would be nice to know that when you boot the system the nginx config
>> will be valid.
>
> It's currently printed near the end of ‘guix system reconfigure’, if
> that's what you mean.

I mean that it should throw an error before the system is made active.
The derivation that builds the service file should fail.  Not
suggesting it needs to be done right now, but I think it would be
cool.

- Dave

Re: [PATCH] services: nginx: Actually check if configuration is valid.

[Thompson, David]

On Thu, Sep 8, 2016 at 10:05 PM, Tobias Geerinckx-Rice  wrote:
> * gnu/services/web.scm (nginx-activation): Fix path to nginx binary.
> ---
>
> Hullo again!
>
> I suspect not many people run nginx (or dovecot, but that's a different
> matter) on Guix. The nginx activation script will now correctly print a
> non-fatal error if the configuration smells off.

Maybe this could be done at build-time instead?  Would be nice to know
that when you boot the system the nginx config will be valid.

- Dave

Re: GSoC NPM

[Thompson, David]

On Sun, Sep 4, 2016 at 10:11 AM, Jan Nieuwenhuizen  wrote:

>* add --binary option to importer, sets (arguments (#:binary? #t))

This violates a core principle of Guix: reproducible builds.  I don't
support patches that encourage using pre-built binaries.

> As a first attempt, I tried to recursively import `q', a fairly basic
> package from my possibly ignorant perspective: can you write anything
> non-trivial in node without using q?.  When that resulted in over 6004
> dependencies (using build systems grunt, gulp and node-gyp, listing 582
> errors), I was pretty sure there was a problem with your importer.
> Using the --binary option, q has no dependencies.  None.  Single
> package.  Hmm.

That's because the thing on npm has already been built for you.  q
*does* have dependencies if you want to build it from source, which is
what we should all be striving for.

- Dave

Re: GSoC NPM

[Thompson, David]

On Fri, Sep 2, 2016 at 10:24 AM, Jan Nieuwenhuizen  wrote:

> Also, I found that you prefer going through the repository/github
> instead of using the dist tarball.  Why is that?

The tarballs distributed by NPM are considered binaries, not source.

- Dave

Re: [PATCH] gnu: Add Infernal.

[Thompson, David]

On Fri, Sep 2, 2016 at 9:35 AM, Ricardo Wurmus
 wrote:
> * gnu/packages/bioinformatics.scm (infernal): New variable.
> ---
>  gnu/packages/bioinformatics.scm | 27 +++
>  1 file changed, 27 insertions(+)
>
> diff --git a/gnu/packages/bioinformatics.scm b/gnu/packages/bioinformatics.scm
> index 08c2545..1652f71 100644
> --- a/gnu/packages/bioinformatics.scm
> +++ b/gnu/packages/bioinformatics.scm
> @@ -4835,6 +4835,33 @@ data in the form of VCF files.")
>  ;; at https://vcftools.github.io/license.html
>  (license license:lgpl3)))
>
> +(define-public infernal
> +  (package
> +(name "infernal")
> +(version "1.1.2")
> +(source (origin
> +  (method url-fetch)
> +  ;; There are no versioned tarballs

But the version appears in the URL?

> +  (uri (string-append "http://eddylab.org/software/infernal/;
> +  "infernal-" version ".tar.gz"))
> +  (sha256
> +   (base32
> +"0sr2hiz3qxfwqpz3whxr6n82p3x27336v3f34iqznp10hks2935c"
> +(build-system gnu-build-system)
> +(native-inputs
> + `(("perl" ,perl))) ; for tests
> +(home-page "http://eddylab.org/infernal/;)
> +(synopsis "Inference of RNA alignments")
> +(description "Infernal (\"INFERence of RNA ALignment\") is a tool for
> +searching DNA sequence databases for RNA structure and sequence similarities.
> +It is an implementation of a special case of profile stochastic context-free
> +grammars called @dfn{covariance models} (CMs).  A CM is like a sequence
> +profile, but it scores a combination of sequence consensus and RNA secondary
> +structure consensus, so in many cases, it is more capable of identifying RNA
> +homologs that conserve their secondary structure more than their primary
> +sequence.")
> +(license license:bsd-3)))
> +
>  (define-public r-vegan
>(package
>  (name "r-vegan")
> --
> 2.9.3
>
>

LGTM overall.

- Dave

Re: Building for Android and F-Droid

[Thompson, David]

On Thu, Sep 1, 2016 at 7:33 AM, Hartmut Goebel
 wrote:
> Hello,
>
> I just want to share an idea I had:
>
> Recently I was involved in packaging a app for f-droid. The f-droid build
> system consists of 1) a virtual machine which get cleaned up after each
> build. and 2) meta-data descriptions of each package. The meta-data includes
> build instructions and is basically a ini-like file. For a simple examples
> see [1] and for a complex one see [2].
>
> One of f-droid's goals is reproducible build. De-facto they fail on this,
> given the current set up since they update the virtual machine to some
> current state.
>
> In got the idea to make f-droid use guix as a base. Of course, this would be
> a lot of work, and I do not expect this to happen any time soon. We have
> quite a lot of work to do on the guix-side, like building the Android tools,
> implement maven and graddle builds, etc.

You are indeed correct that it would be a lot of work, but it is
certainly possible and sounds like it would be a big improvement over
the status quo.  I would also like to see this happen because I am an
F-Droid user.

Does anyone know what we are missing to be able to package android
tools?  I would like to be able to use the android debug bridge again
to shell into my phone. :)

- Dave

Re: screenshot of the web interface to the GNU Guix package manager

[Thompson, David]

On Wed, Aug 31, 2016 at 9:56 AM, ng0  wrote:
> Ricardo Wurmus  writes:
>
>> knx...@onionmail.info writes:
>>
>>> On https://git.dthompson.us/guix-web.git/blob/HEAD:/README.md
>>>
>>> there is a dead link to
>>> http://media.dthompson.us/mgoblin_media/media_entries/20/Screenshot_from_2014-08-13_180724.png
>>>
>>> - so no visible screenshot of the web interface to the GNU Guix package
>>> manager here...
>>>
>>>
>>> Does anyone have a screenshot maybe?  Thx!
>>
>> You can see a running instance of Guix web at
>> .
>>
>> It runs a slightly modified version of Dave’s code.
>>
>> ~~ Ricardo
>>
>
> A good number of people have pointed out to me that our /packages page
> crashes their browser or in general is really uncomfortable to load.
> The impression would be better if we provided something which might not
> be 100% done but at least does not crash/hang systems.
> What's in the way to use guix-web instead of the listing we have?
> Perfectionism and/or a lack of time?

Pagination can be achieved without the use of a dynamic web
application.  I wouldn't recommend guix-web for this right now because
it also loads slowly.  Some dynamic thing with a search box would be
cool in the future, but not now.

The Guile source that generates the web pages is available and
hackable, so it would be relatively easy for someone to break this
list up in some sane fashion and send a patch.  Any volunteers?

- Dave

Re: screenshot of the web interface to the GNU Guix package manager

[Thompson, David]

On Wed, Aug 31, 2016 at 9:45 AM,   wrote:
> On https://git.dthompson.us/guix-web.git/blob/HEAD:/README.md
>
> there is a dead link to
> http://media.dthompson.us/mgoblin_media/media_entries/20/Screenshot_from_2014-08-13_180724.png

Sorry about that, my MediaGoblin server is down at the moment.

Do note that guix-web was a prototype that I haven't touched in quite
some time.  It doesn't do much beyond allowing you to search the
available packages.

- Dave

Re: [PATCH] gnu: node: Update to 6.4.0.

[Thompson, David]

On Fri, Aug 26, 2016 at 1:55 PM, Jelle Licht  wrote:
>
> This patch builds reproducible, although that was also the case for me
> with the previous Node 6.3.1. patch. It would be great if someone could
> verify this.
>
> This patch supercedes the 'gnu: node: Update to 6.3.1.' patch at [0].

LGTM.  Thanks!

- Dave

Re: [PATCH v2 2/6] gnu: fpga: Add abc.

[Thompson, David]

diff --git a/gnu/packages/fpga.scm b/gnu/packages/fpga.scm
index 112d53b..7571f87 100644
--- a/gnu/packages/fpga.scm
+++ b/gnu/packages/fpga.scm
@@ -38,3 +38,46 @@
   #:use-module (gnu packages version-control)
   #:use-module (gnu packages libftdi))

+;; To compile as C code (default):
+;;   make sure that CC=gcc and ABC_NAMESPACE is not defined.
+;; To compile as C++ code with namespaces:
+;;   make sure that CC=g++ and ABC_NAMESPACE is set to the namespace.
+;;   For example, add -DABC_NAMESPACE=xxx to OPTFLAGS.
+(define-public abc
+ (let ((commit "5ae4b975c49c"))
+  (package
+(name "abc")
+(version (string-append "0.0-" (string-take commit 7)))
+(source (origin
+  (method url-fetch)
+  (uri
+   (string-append "https://bitbucket.org/alanmi/abc/get/;
+  commit ".zip"))
+  (file-name (string-append name "-" version "-checkout.zip"))
+  (sha256
+(base32
+   "1syygi1x40rdryih3galr4q8yg1w5bvdzl75hd27v1xq0l5bz3d0"
+(build-system gnu-build-system)
+(native-inputs
+ `(("unzip" ,unzip)))
+(inputs
+ `(("readline" ,readline)))
+(arguments
+ `(#:tests? #f ; 'check target does not exist.
+   #:phases
+(modify-phases %standard-phases

The opening paren should be aligned with the "#" in "#:phases" and the
rest of the form should be reindented accordingly.

+  (delete 'configure)
+  (replace 'install
+(lambda* (#:key outputs #:allow-other-keys)
+  (let* ((out (assoc-ref outputs "out"))
+ (outbin (string-append out "/bin"))
+ (target (string-append outbin "/abc")))
+(mkdir-p outbin)
+(copy-file "abc" target)))

You over-indented by 4 spaces here and the line above it.

+(home-page "http://people.eecs.berkeley.edu/~alanmi/abc/;)
+(synopsis "Sequential Logic Synthesis and Formal Verification")
+(description "ABC is a program for sequential logic synthesis
+and formal verification.")
+;; FIXME use license: MIT Modern variant as described in:
+;;   
+(license license:expat

Could someone who knows more about this license chime in about what
the best thing to do is?

LGTM other than these few minor things.

- Dave

Re: [PATCH v2 1/6] gnu: Add fpga module.

[Thompson, David]

On Tue, Aug 16, 2016 at 2:06 PM, Danny Milosavljevic
 wrote:
>
> * gnu/packages/fpga.scm: New file.
> ---
>  gnu/local.mk  |  1 +
>  gnu/packages/fpga.scm | 40 
>  2 files changed, 41 insertions(+)
>  create mode 100644 gnu/packages/fpga.scm
>

You should merge this commit with the first patch that adds a variable
to this module.

- Dave

Re: [PATCH v2 3/6] gnu: fpga: Add iverilog.

[Thompson, David]

diff --git a/gnu/packages/fpga.scm b/gnu/packages/fpga.scm
index 7571f87..b0d4819 100644
--- a/gnu/packages/fpga.scm
+++ b/gnu/packages/fpga.scm
@@ -81,3 +81,30 @@ and formal verification.")
 ;; FIXME use license: MIT Modern variant as described in:
 ;;   
 (license license:expat
+
+(define-public iverilog
+  (package
+(name "iverilog")
+(version "10.1.1")
+(source (origin
+  (method url-fetch)
+  (uri
+   (string-append
"ftp://ftp.icarus.com/pub/eda/verilog/v10/verilog-; version
".tar.gz"))
+  (sha256
+(base32
+   "1nnassxvq30rnn0r2p85rkb2zwxk97p109y13x3vr365wzgpbapx"
+(build-system gnu-build-system)
+(native-inputs
+ `(("flex" ,flex)
+   ("bison" ,bison)
+   ("ghostscript" ,ghostscript) #| ps2pdf |#))

A minor nit, but we don't really use that form of comments, so I would
change it to this:

   ("ghostscript" ,ghostscript))) ; ps2pdf

+(home-page "http://iverilog.icarus.com/;)
+(synopsis "FPGA Verilog Simulation and Synthesis Tool")
+(description "Icarus Verilog is a Verilog simulation and synthesis tool.
+It operates as a compiler, compiling source code written in Verilog
+(IEEE-1364) into some target format.
+For batch simulation, the compiler can generate an intermediate form called
+vvp assembly.
+This intermediate form is executed by the ``vvp'' command.
+For synthesis, the compiler generates netlists in the desired format.")
+(license license:gpl2)))

Is it really GPL2 only?

LGTM otherwise, thanks!

- Dave

Re: Specifying Java version when using ant-build-system

[Thompson, David]

On Mon, Aug 15, 2016 at 10:17 AM, Danny Milosavljevic
 wrote:
> Hi,
>
> how can I specify that I need a Java 1.8 compiler and source level when using 
> ant-build-system?
>
> Also, guix/build-system/ant.scm says:
>
> (define* (ant-build store name inputs
> #:key
> (tests? #t)
> (test-target "tests")
> (configure-flags ''())
> (make-flags ''())
> (build-target "jar")
> (jar-name #f)
> (phases '(@ (guix build ant-build-system)
> %standard-phases))
> (outputs '("out"))
> (search-paths '())
> (system (%current-system))
> (guile #f)p
>   ^^^ what does this mean?
> (imported-modules %ant-build-system-modules)
> (modules '((guix build ant-build-system)
>(guix build utils
>

Seems to me that it's missing an argument for that.  We'll need to add
a "java" or "jdk" or whatever argument.

- Dave

Re: [PATCH 2/5] gnu: Add avr-gcc.

[Thompson, David]

On Mon, Aug 15, 2016 at 7:59 AM, Danny Milosavljevic
 wrote:

> What does the search-paths form do? Does it set environment variables in the 
> profile as well?

Search path information is used in build environments (guix build),
user-defined environments (guix environment), and profiles (guix
package).  For example, when you run 'guix package --search-paths',
the environment variables printed are determined by the
native-search-paths field for each package in your profile.

I found that without CROSS_CPATH and CROSS_LIBRARY_PATH the compiler
doesn't work because it can't find all of its headers and libraries
since they aren't in /usr.

Some background: avr-gcc was broken for a very long time, until
Manolis, Ricardo, and I worked out the problems several months ago.  I
tested avr-gcc by successfully compiling the various KADE miniArcade
firmwares using the 'make-all.sh' script found here:
https://github.com/kadevice/KADE/tree/master/open%20software/firmwares/KADE%20miniArcade/sources

I don't know what has changed since I got things working, but I can no
longer compile that firmware.  I get errors like this:

main.c:38:20: fatal error: avr/io.h: No such file or directory

- Dave

Re: [PATCH] ui: 'package->recutils' serializes the source field.

[Thompson, David]

On Wed, Aug 10, 2016 at 9:42 AM, Ricardo Wurmus  wrote:
>
> Ben Woodcroft  writes:
>
>> On 10/08/16 22:27, David Craven wrote:
 I don't have anything to to contribute beyond psuedo-quoting Ludo: let's 
 not lose our hair over this!
>>> I'll let the fact that that could interpreted as being insulting slide.
>>>
>>
>> Oh, no that wasn't my intended meaning. I just saw this thread getting a
>> bit heated in general and I wanted to help it in the reverse direction,
>> for all concerned. That's all.
>
> I agree, let’s cool it a bit please.
>
> Aside from the possible FDSG issue (which I need to think about before
> forming an opinion, although I’m leaning towards not seeing it as a
> problem), I’m not yet convinced that all fields need to be printed in
> recutils format.
>
> For programmatic access to packages we recommend using the Scheme values
> directly as they also hold additional information about the location of
> a value in the dependency graph (package expressions are code, not plain
> meta-data).  I always understood the recutils output to be just a user
> interface for the command line, which is why it doesn’t need to and
> probably shouldn’t print *all* fields.
>
> I think it is not desirable to show that much more information in the
> output, because it is not a programming interface but primarily a user
> interface.
>
> Even so, if one insisted on using the recutils output in a programmatic
> fashion (e.g. in a bash script), it would be best to run “guix build
> --source” on the package names to obtain the actual source tarballs that
> are used by Guix.  What would be the point of printing a URL that is not
> necessarily used by Guix directly?  “guix build --source” (which can be
> used in bash scripts) already provides the *actual* tarball (patched and
> with snippets applied), so this would be more meaningful than an
> upstream URL, in my opinion.
>
> What do others think?

+1

- Dave

Re: [PATCH 2/5] gnu: Add avr-gcc.

[Thompson, David]

On Wed, Aug 10, 2016 at 3:52 AM, Ricardo Wurmus
 wrote:
>
> Maybe Dave knows more about this?

I haven't had time to look into anything, but last I checked I was
able to successfully compile the firmware I'm interested in with
avr-toolchain.

- Dave

Re: Adding ruby-rails and ruby-sinatra.

[Thompson, David]

On Wed, Aug 10, 2016 at 8:11 AM, Ben Woodcroft  wrote:
> Hi all,
>
> I am quite happy to announce that we are almost on rails. There's a new
> branch 'wip-rails' on savannah with a new file 'gnu/packages/rails-wip.scm',
> which includes ~100 ruby packages towards rails and sinatra, both of which
> can be built and used, though I have not yet used them for anything
> significant.
>
> These packages are mostly in bad shape and not ready for master. I will
> slowly get them into shape and push them over, but in the meantime I thought
> that early adopters might have a use for them, find bugs or even help
> improve them.
>
> Hope this all helps someone out there.

Wow!  At work we're still on Rails 3 so I cannot give these packages a
real-world test since I assume they are for Rails 5, but this is very
exciting nonetheless.

Great work!

- Dave

Re: [PATCH v2] gnu: node: Update to 6.3.1.

[Thompson, David]

On Tue, Aug 9, 2016 at 9:13 AM, Jelle Licht  wrote:
>
> Attached you will find the updated version of this patch. Please let me
> know what you think.

I could point out a few nits about the commit message, but I think
someone with commit access should just clean it up and push.  The code
itself looks good.  Thanks, Jelle!

- Dave

Re: [PATCH] gnu: red-eclipse: Update to 1.5.5.

[Thompson, David]

On Mon, Aug 1, 2016 at 9:03 AM, Kei Kebreau  wrote:
>
> An important version bump for Red Eclipse, with necessary changes to
> keep it building properly. I've also included the example server
> configuration file in the config directory.

LGTM.  I really need to try this game out when I get a chance.

Thanks!

- Dave

Re: 'guix environment' as a build tool.

[Thompson, David]

On Sun, Jul 31, 2016 at 9:55 AM, Ludovic Courtès <l...@gnu.org> wrote:
> Hello!
>
> "Thompson, David" <dthomps...@worcester.edu> skribis:
>
>> On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin <m...@gnu.org> wrote:
>>> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>>>> What about providing a ‘guix.scm’ file that people could pass to ‘guix
>>>> environment -l’ (instead of typing the long command above), and to ‘guix
>>>> package -f’ (info "(guix) Invoking guix package")?
>>>
>>> 'guix environment -l' uses a package definition.  To me this abstraction
>>> doesn't fit well in a development context:
>>
>> It *does* fit well.  This use-case is why I wrote 'guix environment'
>> in the first place.
>
> [...]
>
>>> if the user wants to enter this environment Later it will have to invoke
>>> './guix-env'.
>>
>> This just makes things more inconvenient and limits potential utility.
>
> That sounds harsh.

I'm sorry.

> I don’t have a better answer for Mathieu other than ‘guix environment
> -l’, and I think it does the job well.
>
> But I also think that Mathieu’s concerns must not be dismissed.  For
> instance, it’s true that some of the metadata in ‘package’ forms looks
> irrelevant for the purposes of setting up a build environment—no big
> deal, but still it doesn’t “feel” completely right.

My intention was to define it just like a regular package so that
users can do whatever they want with it: build it, install it, or make
a development environment using it.

> Conversely, useful metadata is missing: for instance, I’d like to add
> something that would allow me to specify the equivalent of ‘--network
> --expose=$HOME/.gdbinit’ in development environments I use.
>
> Perhaps the solution is to introduce a new way to declare development
> environments?  It would be similar to ‘package’, but without ‘synopsis’,
> ‘description’, and a couple other things; it could have additional
> fields to describe container setups and such likes; it would compile
> down to a bag, just like packages.
>
> What do you think?

Hmm, that sounds like a good idea.  Maybe I'll try to write a
prototype sometime.  The downside of this method is that one could no
longer use the same expression as input to 'guix build -f' or 'guix
package -f'.

- Dave

Re: 'guix environment' as a build tool. (was: [GSoC] Continuous integration tool à la Hydra.)

[Thompson, David]

On Sat, Jul 30, 2016 at 10:05 PM, Mathieu Lirzin  wrote:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mathieu Lirzin  skribis:
>>
>>> I have tested successfully with the following command on a foreign
>>> system:
>>>
>>>   guix environment --ad-hoc automake pkg-config guile guix libgcrypt sqlite 
>>> guile-sqlite3
>>>
>>> Tell me if it works for you.
>>>
 How about including a guix package definition then we can easily build
 it assuming "we" know how to do out-of-guix-tree package building :)
>>>
>>> It would indeed be nice to provide an easy way for Guix users to install
>>> Cuirass.  IMHO package definitions meant as a development build tool is
>>> confusing and should be avoided.  Nonetheless, I think it is useful to
>>> document the previous 'guix environment ...' command in the README.
>>
>> What about providing a ‘guix.scm’ file that people could pass to ‘guix
>> environment -l’ (instead of typing the long command above), and to ‘guix
>> package -f’ (info "(guix) Invoking guix package")?
>
> 'guix environment -l' uses a package definition.  To me this abstraction
> doesn't fit well in a development context:

It *does* fit well.  This use-case is why I wrote 'guix environment'
in the first place.

>  - the origin hash doesn't make sense.

You don't need one.  Use local-file for the source field.

>  - packages already included in Guix have redundant description and synopsis.

I don't understand what this means.

>  - package definitions rely on Guix internals.

The package API rarely changes in practice.

> In fact what 'guix.scm' contains feels more like a "debian" directory or
> a "PACKAGE.spec" file on steroid because of the "guix environment -l"
> feature which derives from it but doesn't appear as first class.
>
> An idea that I like better and is less invasive, would be to complement
> bootstrap scripts with:
>
>   ./bootstrap --with-guix
>
> This command would:
>
> - generate a guix-env script that wraps 'guix environment ...' if it
>   doesn't exist.
> - Invoke ./guix-env
> - Invoke autoreconf -vfi
>
> if the user wants to enter this environment Later it will have to invoke
> './guix-env'.

This just makes things more inconvenient and limits potential utility.
You would lose the ability to tweak the dependency graph with custom
package recipes.  I do this frequently in my projects that use
bleeding edge features of other software that may not even have an
official release yet.  Also, with a package file, Guix users can
install the development snapshot with 'guix package -f' or simply
build it with 'guix build -f'.

> Some interesting things could be done beyond this, for example by using
> per repository profiles that would save development environments.  This
> would allow developpers to easily use different setups.

'guix environment' already serves this purpose.  I do want to extend
'guix environment' with a --save flag that will register the profile
it generates as a GC root so that it can be saved for future sessions
so that the environment doesn't need to be rebuilt every time the user
upgrades Guix.

Hopefully this clears things up.

- Dave

Re: [PATCH] gnu: password-store: Wrap PATH.

[Thompson, David]

On Fri, Jul 29, 2016 at 5:07 AM, Mathieu Lirzin  wrote:
> Hello,
>
> Alex Griffin  writes:
>
>> On Thu, Jul 28, 2016, at 07:20 PM, Alex Griffin wrote:
>>
>> From 74b838fea52293386169299881cdd7cfefff7f4d Mon Sep 17 00:00:00 2001
>> From: Alex Griffin 
>> Date: Thu, 28 Jul 2016 19:06:10 -0500
>> Subject: [PATCH] gnu: password-store: Wrap PATH.
>>
>> * gnu/packages/password-utils.scm (password-store):
>> [arguments]: Wrap PATH more thoroughly.
>> [native-inputs]: Move getopt to inputs.
>> [inputs]: Add sed & alphabetize packages.
>   ^^
> Indentation and formatting changes can be omitted in commit log.
>
>> ---
>>  gnu/packages/password-utils.scm | 33 -
>>  1 file changed, 16 insertions(+), 17 deletions(-)
>>
>> diff --git a/gnu/packages/password-utils.scm 
>> b/gnu/packages/password-utils.scm
>> index a03214a..497717f 100644
>> --- a/gnu/packages/password-utils.scm
>> +++ b/gnu/packages/password-utils.scm
>> @@ -6,6 +6,7 @@
>>  ;;; Copyright © 2016 Jessica Tallon 
>>  ;;; Copyright © 2016 Andreas Enge 
>>  ;;; Copyright © 2016 Lukas Gradl 
>> +;;; Copyright © 2016 Alex Griffin 
>>  ;;;
>>  ;;; This file is part of GNU Guix.
>>  ;;;
>> @@ -266,27 +267,25 @@ any X11 window.")
>>   '(#:phases
>> (modify-phases %standard-phases
>>   (delete 'configure)
>> - (add-after
>> -  ;; The script requires 'getopt' at run-time, and this allows
>> -  ;; the user to not install the providing package 'util-linux'
>> -  ;; in their profile.
>> -  'unpack 'patch-path
>> -  (lambda* (#:key inputs outputs #:allow-other-keys)
>> -(let ((getopt (string-append (assoc-ref inputs "getopt")
>> - "/bin/getopt")))
>> -  (substitute* "src/password-store.sh"
>> -(("GETOPT=\"getopt\"")
>> - (string-append "GETOPT=\"" getopt "\"")))
>> -  #t
>> + (add-after 'install 'wrap-path
>> +   (lambda* (#:key inputs outputs #:allow-other-keys)
>> + (let* ((out (assoc-ref outputs "out"))
>> +(path (map (lambda (pkg)
>> + (string-append (assoc-ref inputs pkg) 
>> "/bin"))
>> +   '("coreutils" "getopt" "git" "gnupg" "pwgen"
>> + "sed" "tree" "which" "xclip"
>> +   (wrap-program (string-append out "/bin/pass")
>> + `("PATH" ":" prefix (,(string-join path ":"
>
> 'let*' can safely be replaced by 'let' here.
>
>> #:make-flags (list "CC=gcc" (string-append "PREFIX=" %output))
>> #:test-target "test"))
>> -(native-inputs `(("getopt" ,util-linux))) ; getopt for the tests
>> -(inputs `(("gnupg" ,gnupg)
>> -  ("pwgen" ,pwgen)
>> -  ("xclip" ,xclip)
>> +(inputs `(("getopt" ,util-linux)
>>("git" ,git)
>> +  ("gnupg" ,gnupg)
>> +  ("pwgen" ,pwgen)
>> +  ("sed" ,sed)
>>("tree" ,tree)
>> -  ("which" ,which)))
>> +  ("which" ,which)
>> +  ("xclip" ,xclip)))
>>  (home-page "http://www.passwordstore.org/;)
>>  (synopsis "Encrypted password manager")
>>  (description "Password-store is a password manager which uses GnuPG to
>
> Pushed in commit 61201e46a72b715e1a38ce56932c3f4f2d3885b4.

Sorry I'm late, but I don't think this is the right fix.  Wrapping
programs should only be considered after other options are exhausted.
The correct fix is to patch the source directly to refer to
executables by their absolute path.  Why wasn't it done this way?

- Dave

Re: Ricardo Wurmus appointed co-maintainer

[Thompson, David]

On Tue, Jul 26, 2016 at 6:27 AM, Ludovic Courtès  wrote:
> Hello Guix!
>
> I’m happy to announce that Ricardo Wurmus has just been appointed by the
> GNU overseers to join me as co-maintainer of GNU Guix.

Congrats Ricardo!  I can think of no one better for the job. :)

- Dave

Re: [PATCH] gnu: fish: Update to 2.3.1.

[Thompson, David]

On Fri, Jul 22, 2016 at 3:01 AM, Tobias Geerinckx-Rice  wrote:
> * gnu/packages/fish.scm (fish): Update to 2.3.1.
> [home-page, source]: Use 'https' in the URL.

LGTM. Do you have commit access?

- Dave