Getting rid of alpha label

[Pjotr Prins]

Can we get rid of the alpha status? It suggests packages are in alpha,
which they are not. 

I have already had two different administrators in two environments
claiming that Guix packages can not be deployed on HPC systems because
it is alpha. 

The excuse is too easy ;)

I think GuixSD should be alpha. But it should not be proclaimed on the
main website. Sure there are bugs to be ironed out, but we are
actually better than Debian for the packages that we have.

Pj.

A Suggestion about guix-devel-mode

[Feng Shu]

Maybe we should add three addition keybinding:

1. Force rebuild the package defined by the current variable definition.
2. Install/upgrade the package defined by the current variable definition.
3  Remove package defined by the current variable definition.

#+BEGIN_COMMENT
4.9 Development

By default, when you open a Scheme file, guix-devel-mode will be activated (if 
you don’t want it, set guix-devel-activate-mode to nil). This minor mode 
provides the following key bindings:

C-c . k

Copy the name of the current Guile module into kill ring 
(guix-devel-copy-module-as-kill).
C-c . u

Use the current Guile module. Often after opening a Scheme file, you want 
to use a module it defines, so you switch to the Geiser REPL and write ,use 
(some module) there. You may just use this command instead 
(guix-devel-use-module).
C-c . b

Build a package defined by the current variable definition. The building 
process is run in the current Geiser REPL. If you modified the current package 
definition, don’t forget to reevaluate it before calling this command—for 
example, with C-M-x (see To eval or not to eval in Geiser User Manual) 
(guix-devel-build-package-definition).
C-c . s

Build a source derivation of the package defined by the current variable 
definition. This command has the same meaning as guix build -S shell command 
(see Invoking guix build) (guix-devel-build-package-source).
C-c . l

Lint (check) a package defined by the current variable definition (see 
Invoking guix lint) (guix-devel-lint-package).

#+END_COMMENT
-- 

Problem installing Guix on OpenVZ host that uses zfs

[Stefan Reichör]

Hi all,

I tried today to install Guix v12.0 on an OpenVZ hoster:
https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation

But I failed with the following problem:

~/bin% ./guix package -i hello
The following package will be installed:
   hello2.10/gnu/store/rvs42awwwby7pq3j0znglmz3vyznvbh1-hello-2.10

The following derivations will be built:
   /gnu/store/3rjlwl02c69c71jdcjcp96r41byqbv54-profile.drv
   /gnu/store/va7p6kn3c5836aw0risjxc0m6s3cj5jx-ca-certificate-bundle.drv
   /gnu/store/qbx513w8j5ikrjjnn2pv7qq91zmpylw8-fonts-dir.drv
   /gnu/store/9b7gxm83y7x4ps2mimp6jpfzx7hjypvd-info-dir.drv
guix package: error: build failed: while setting up the build environment: 
unable to make filesystem `/' private: Permission denied

~/bin% mount
satazpool/data/subvol-618-disk-1 on / type zfs (rw,noatime,xattr,posixacl)


Is there a work around for this problem?

Thanks,
  Stefan.

Re: Having trouble packaging DefaultEncrypt for Emacs

[Alex Kost]

Chris Marusich (2017-04-11 00:40 -0700) wrote:

> Alex Kost  writes:
>
>> Note, however, that in most cases (not in this case) using "require" is
>> not needed at all!  Usually it is enough to have the generated
>> autoloads.  For example, if you install 'magit', you don't need to (and
>> shouldn't!) put "(require 'magit)" in your emacs config.  You can use
>> "M-x magit-status" right away as 'magit-status' command is "autoloaded".
>
> That's good to know.  I guess this module didn't do the "autoload magic"
> that some modules, like magit, do?

Unlike such packages as magit, this package doesn't provide any
interactive command (thus there is no point to autoload anything), it
just extends the existing Emacs functionality when it is loaded.  It
does so simply by adding a couple of hooks, so if you would like to
avoid loading this package on Emacs start, you can add these hooks
yourself:

(add-hook 'gnus-message-setup-hook 'mml-secure-encrypt-if-possible)
(add-hook 'message-send-hook 'mml-secure-check-encryption-p)

If you add the above 2 lines to your emacs config (instead of the
"require" line), "jl-encrypt" package will not be loaded on Emacs
start.  It will be loaded when you'll begin to write a message.

-- 
Alex

libxml2: Wrong separator in XML_CATALOG_FILES?

[Hartmut Goebel]

Hi,

I just discovered that libxml2 sets the search-path-specification for
variable "XML_CATALOG_FILES" using space as separator, which is very
uncommon. The documentation for libxml2 does not state which separator
to use, while the docbook-tutorial [1] has an example using colons.

So I'm curious whether the space is correct.

[1] 

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |



0xBF773B65.asc
Description: application/pgp-keys

Re: Some suggestion about "Contributing" documents.

[myglc2]

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

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

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

7 Contributing

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

Re: Issues while updating fossil to 2.1

[ng0]

ng0 transcribed 5.3K bytes:
> ng0 transcribed 4.7K bytes:
> > Hi,
> > 
> > my editor wraps at 80 lines but I hope the errors are obvious for
> > someone who did fix fossil before (Efraim?).
> > Could it be that not all tests have been updated for the new format?
> 
> Looking at their timeline
> (https://www.fossil-scm.org/index.html/timeline?y=ci), commits like
> https://www.fossil-scm.org/index.html/info/6167f69a218804bd
> suggest that there are issues. However I guess we can use nothing after
> https://www.fossil-scm.org/index.html/timeline?c=303a2084a35beec1&unhide
> where they updated sqlite to 3.18 beta and later they updated to 3.18
> (released?).
> 
> I'll just see if including appropriate commits from their timeline fixes
> the tests.
> 

There's also an OpenSSL-1.1.0 related bug which was fixed since the
release of fossil 2.1, reported by Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847556#10

I think we should update to at least
https://www.fossil-scm.org/index.html/info/8c22e1bbcd8ec048

I don't know when they plan to release version 2.2, but it will require
a version of sqlite we do not have. Would it be okay to fall back to the
bundled one then?
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Issues while updating fossil to 2.1

[ng0]

ng0 transcribed 4.7K bytes:
> Hi,
> 
> my editor wraps at 80 lines but I hope the errors are obvious for
> someone who did fix fossil before (Efraim?).
> Could it be that not all tests have been updated for the new format?

Looking at their timeline
(https://www.fossil-scm.org/index.html/timeline?y=ci), commits like
https://www.fossil-scm.org/index.html/info/6167f69a218804bd
suggest that there are issues. However I guess we can use nothing after
https://www.fossil-scm.org/index.html/timeline?c=303a2084a35beec1&unhide
where they updated sqlite to 3.18 beta and later they updated to 3.18
(released?).

I'll just see if including appropriate commits from their timeline fixes
the tests.

> There's no test log. The output below can be reproduced with the the
> attached patch.
> 
> phase `build' succeeded after 21.6 seconds
> starting phase `test-setup'
> phase `test-setup' succeeded after 0.0 seconds
> starting phase `check'
> tclsh ./src/../test/tester.tcl fossil -quiet
> test amend-setup-failure FAILED!
> RESULT: New_Version:
> 74afca56eee6c4ee6fc8428b9f1dacc24b35f08cebf0e3f8440635a034dea628
> ERROR: current directory is not within an open checkout
> test pre-commit-warnings-1 FAILED!
> RESULT: current directory is not within an open checkout
> Fossil was not compiled with JSON support.
> ERROR: SQLITE_ERROR: table config has no column named mtime
> /tmp/guix-build-fossil-2.1.drv-0/fossil-2.1/fossil: table config has no
> column named mtime: {REPLACE INTO config(name,value,mtime)
> VALUES('hash-policy',1,now())}
> ERROR: SQLITE_ERROR: table config has no column named mtime
> /tmp/guix-build-fossil-2.1.drv-0/fossil-2.1/fossil: table config has no
> column named mtime: {REPLACE INTO config(name,value,mtime)
> VALUES('hash-policy',1,now())}
> ERROR: use --repository or -R to specify the repository database
> ERROR: current directory is not within an open checkout
> current directory is not within an open checkout
> while executing
> "exec $::fossilexe ls -l"
> (procedure "checkout-test" line 3)
> invoked from within
> "checkout-test 10 {
>   da5c8346496f3421cb58f84b6e59e9531d9d424d  one.txt
>   ed24d19d726d173f18dbf4a9a0f8514daa3e3ca4  three.txt
>   278a402316510f6ae4a7718..."
> (file "/tmp/guix-build-fossil-2.1.drv-0/fossil-2.1/test/merge5.test"
> line 50)
> invoked from within
> "source $testdir/$testfile.test"
> ("foreach" body line 3)
> invoked from within
> "foreach testfile $argv {
>   protOut "* $testfile **"
>   source $testdir/$testfile.test
>   protOut "* End of $testfile: [llength $bad_test] er..."
> (file "./src/../test/tester.tcl" line 944)
> make: *** [src/main.mk:497: test] Error 1
> phase `check' failed after 144.0 seconds
> builder for `/gnu/store/iyh8xcg4x8w3zd89mn8yz9c5wgy5iqar-fossil-2.1.drv'
> failed with exit code 1
> @ build-failed
> /gnu/store/iyh8xcg4x8w3zd89mn8yz9c5wgy5iqar-fossil-2.1.drv - 1 builder
> for `/gnu/store/iyh8xcg4x8w3zd89mn8yz9c5wgy5iqar-fossil-2.1.drv' failed
> with exit code 1
> guix build: error: build failed: build of
> `/gnu/store/iyh8xcg4x8w3zd89mn8yz9c5wgy5iqar-fossil-2.1.drv' failed
> 
> 
> -- 
> PGP and more: https://people.pragmatique.xyz/ng0/

> From 361c92d948be8216efdb7cca86c583e355e7bd30 Mon Sep 17 00:00:00 2001
> From: ng0 
> Date: Fri, 3 Mar 2017 13:25:53 +
> Subject: [PATCH] gnu: fossil: Update to 2.1.
> 
> * gnu/packages/version-control.scm (fossil): Update to 2.1.
> ---
>  gnu/packages/version-control.scm | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/gnu/packages/version-control.scm 
> b/gnu/packages/version-control.scm
> index 45b9e9240..5c220d7f7 100644
> --- a/gnu/packages/version-control.scm
> +++ b/gnu/packages/version-control.scm
> @@ -1232,16 +1232,21 @@ repository\" with git-annex.")
>  (define-public fossil
>(package
>  (name "fossil")
> -(version "1.35")
> +(version "2.1")
>  (source
>   (origin
> (method url-fetch)
> -   (uri (string-append
> - "https://www.fossil-scm.org/index.html/uv/download/";
> - "fossil-src-" version ".tar.gz"))
> +   ;; Older downloads are moved to another URL.
> +   (uri (list
> + (string-append
> +  "https://www.fossil-scm.org/index.html/uv/download/";
> +  "fossil-src-" version ".tar.gz")
> + (string-append
> +  "https://www.fossil-scm.org/index.html/uv/";
> +  "fossil-src-" version ".tar.gz")))
> (sha256
>  (base32
> - "07ds6rhq69bhydpm9a01mgdhxf88p9b6y5hdnhn8gjc7ba92zyf1"
> + "01ggrwijy2gvghr8j2hlka54klkkmbxccf9qypp43gpis08dzp45"
>  (build-system gnu-build-system)
>  (native-inputs
>   `(("tcl" ,tcl) ;for configuration only
> @@ -1272,7 +1277,7 @@ repository\" with git-annex.")
>(setenv "TZ" "UTC")
>;; Fixing the th1 test would require many backports, so
> 

Issues while updating fossil to 2.1

[ng0]

Hi,

my editor wraps at 80 lines but I hope the errors are obvious for
someone who did fix fossil before (Efraim?).
Could it be that not all tests have been updated for the new format?

There's no test log. The output below can be reproduced with the the
attached patch.

phase `build' succeeded after 21.6 seconds
starting phase `test-setup'
phase `test-setup' succeeded after 0.0 seconds
starting phase `check'
tclsh ./src/../test/tester.tcl fossil -quiet
test amend-setup-failure FAILED!
RESULT: New_Version:
74afca56eee6c4ee6fc8428b9f1dacc24b35f08cebf0e3f8440635a034dea628
ERROR: current directory is not within an open checkout
test pre-commit-warnings-1 FAILED!
RESULT: current directory is not within an open checkout
Fossil was not compiled with JSON support.
ERROR: SQLITE_ERROR: table config has no column named mtime
/tmp/guix-build-fossil-2.1.drv-0/fossil-2.1/fossil: table config has no
column named mtime: {REPLACE INTO config(name,value,mtime)
VALUES('hash-policy',1,now())}
ERROR: SQLITE_ERROR: table config has no column named mtime
/tmp/guix-build-fossil-2.1.drv-0/fossil-2.1/fossil: table config has no
column named mtime: {REPLACE INTO config(name,value,mtime)
VALUES('hash-policy',1,now())}
ERROR: use --repository or -R to specify the repository database
ERROR: current directory is not within an open checkout
current directory is not within an open checkout
while executing
"exec $::fossilexe ls -l"
(procedure "checkout-test" line 3)
invoked from within
"checkout-test 10 {
  da5c8346496f3421cb58f84b6e59e9531d9d424d  one.txt
  ed24d19d726d173f18dbf4a9a0f8514daa3e3ca4  three.txt
  278a402316510f6ae4a7718..."
(file "/tmp/guix-build-fossil-2.1.drv-0/fossil-2.1/test/merge5.test"
line 50)
invoked from within
"source $testdir/$testfile.test"
("foreach" body line 3)
invoked from within
"foreach testfile $argv {
  protOut "* $testfile **"
  source $testdir/$testfile.test
  protOut "* End of $testfile: [llength $bad_test] er..."
(file "./src/../test/tester.tcl" line 944)
make: *** [src/main.mk:497: test] Error 1
phase `check' failed after 144.0 seconds
builder for `/gnu/store/iyh8xcg4x8w3zd89mn8yz9c5wgy5iqar-fossil-2.1.drv'
failed with exit code 1
@ build-failed
/gnu/store/iyh8xcg4x8w3zd89mn8yz9c5wgy5iqar-fossil-2.1.drv - 1 builder
for `/gnu/store/iyh8xcg4x8w3zd89mn8yz9c5wgy5iqar-fossil-2.1.drv' failed
with exit code 1
guix build: error: build failed: build of
`/gnu/store/iyh8xcg4x8w3zd89mn8yz9c5wgy5iqar-fossil-2.1.drv' failed


-- 
PGP and more: https://people.pragmatique.xyz/ng0/
>From 361c92d948be8216efdb7cca86c583e355e7bd30 Mon Sep 17 00:00:00 2001
From: ng0 
Date: Fri, 3 Mar 2017 13:25:53 +
Subject: [PATCH] gnu: fossil: Update to 2.1.

* gnu/packages/version-control.scm (fossil): Update to 2.1.
---
 gnu/packages/version-control.scm | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 45b9e9240..5c220d7f7 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -1232,16 +1232,21 @@ repository\" with git-annex.")
 (define-public fossil
   (package
 (name "fossil")
-(version "1.35")
+(version "2.1")
 (source
  (origin
(method url-fetch)
-   (uri (string-append
- "https://www.fossil-scm.org/index.html/uv/download/";
- "fossil-src-" version ".tar.gz"))
+   ;; Older downloads are moved to another URL.
+   (uri (list
+ (string-append
+  "https://www.fossil-scm.org/index.html/uv/download/";
+  "fossil-src-" version ".tar.gz")
+ (string-append
+  "https://www.fossil-scm.org/index.html/uv/";
+  "fossil-src-" version ".tar.gz")))
(sha256
 (base32
- "07ds6rhq69bhydpm9a01mgdhxf88p9b6y5hdnhn8gjc7ba92zyf1"
+ "01ggrwijy2gvghr8j2hlka54klkkmbxccf9qypp43gpis08dzp45"
 (build-system gnu-build-system)
 (native-inputs
  `(("tcl" ,tcl) ;for configuration only
@@ -1272,7 +1277,7 @@ repository\" with git-annex.")
   (setenv "TZ" "UTC")
   ;; Fixing the th1 test would require many backports, so
   ;; just disable for now.
-  (delete-file "test/th1.test")
+  ;; (delete-file "test/th1.test")
   #t)
 (home-page "https://fossil-scm.org";)
 (synopsis "Software configuration management system")
-- 
2.12.2

Re: Some suggestion about "Contributing" documents.

[ng0]

Can you come up with an chapters, subchapters, + briefly described /
expected content map? This might help to work on it.

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

-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: Some suggestion about "Contributing" documents.

[Hartmut Goebel]

Am 11.04.2017 um 07:28 schrieb Feng Shu:
> "Contributing" document is hard to be understood i think.
> In my opinion, "Contributing" part of document should split
> two sub parts:
>
> 1. I am a guix core developer
>
> 2. I Just want to add a new apps's "define-public"

Good idea. I'd even put the "add a new apps" part first since this is
what more people will do more often.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Having trouble packaging DefaultEncrypt for Emacs

[Chris Marusich]

Alex Kost  writes:

> So the error is:
>
> Starting download of /tmp/guix-file.ugdVEh
> From 
> https://www.informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt4.1/jl-encrypt.el...
> ERROR: Bad media-type header component: text/plain
>
> failed to download "/tmp/guix-file.ugdVEh" from 
> "https://www.informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt4.1/jl-encrypt.el";
> guix download: error: 
> https://www.informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt4.1/jl-encrypt.el:
>  download failed
>
> IIUC, we had a similar problem before, and it is considered to be the
> upstream problem.  Look at the following message, for example:
>
> http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00578.html

I've sent an email privately to the DefaultEncrypt author asking them to
fix this.  If they do, I'll update the origin URI.

-- 
Chris


signature.asc
Description: PGP signature

Re: Having trouble packaging DefaultEncrypt for Emacs

[Chris Marusich]

Alex Kost  writes:

> Chris Marusich (2017-04-08 17:21 -0700) wrote:
>
>> Hi,
>>
>> I'm trying to package DefaultEncrypt:
>>
>> https://www.emacswiki.org/emacs/DefaultEncrypt
>>
>> I've made a package definition (see attached patch), and it builds
>> without error.  I've installed it into my user profile.  Per the
>> documentation, I've added the following to my ~/.emacs:
>>
>>   (require 'jl-encrypt)
>
> I recommend to never do this "hard" requirement.  As you can see, it
> may break your .emacs.  Better do it like this:
>
>   (require 'jl-encrypt nil t)
>
> or if you want some warning message:
>
>   (unless (require 'jl-encrypt nil t)
> (message "Something is not good: jl-encrypt was not loaded"))

I did not know this!  Thank you for sharing your knowledge.  I chose to
use the "unless" form so I would know if it ever failed to load.

> Note, however, that in most cases (not in this case) using "require" is
> not needed at all!  Usually it is enough to have the generated
> autoloads.  For example, if you install 'magit', you don't need to (and
> shouldn't!) put "(require 'magit)" in your emacs config.  You can use
> "M-x magit-status" right away as 'magit-status' command is "autoloaded".

That's good to know.  I guess this module didn't do the "autoload magic"
that some modules, like magit, do?

>> However, when I start Emacs, I get the following warning:
>>
>> Warning (initialization): An error occurred while loading
>> ‘/home/marusich/.emacs’:
>>
>> File error: Cannot open load file, No such file or directory, jl-encrypt
>>
>>
>> Why is this happening?  How can I fix it?  I'm still a bit of an Emacs
>> newbie, so maybe there's an obvious solution I'm unaware of.
>>
>> I've also noticed that the elisp file gets installed with the name
>> "jl-encrypt.el.el", which seems weird, but I don't know if that's
>> related to the preceding issue:
>
> This weird file name is the root of the problem: a single-package file
> should have the following file name: .  So try to add
> 'file-name' to the origin (see below).

Aha!  Yes, that fixed it.  I was so close!  Thank you for taking the
time to help me finish this up.  I am now happily using jl-encrypt.
It's automatically signing my email and protecting me from sending email
in cleartext when I should be encrypting it otherwise!  Great stuff.

Patch incoming!  :-)

-- 
Chris


signature.asc
Description: PGP signature

Re: [Mark Meyer] Re: AWS + OpenStack support

[Chris Marusich]

Mark Meyer  writes:

> Chris> Long story short, instead of starting with a base image and
> Chris> modifying it (e.g., by injecting credentials at first boot
> Chris> via the EC2 metadata service), one appealing alternative is
> Chris> to use EC2's VM import feature to actually import precisely
> Chris> the system that you want to launch:
>
> Chris> https://aws.amazon.com/ec2/vm-import/
>
> Which does not work with GuixSD (tried it). Apparently it looks into the
> image an expects stuff like fstab. I find it not very trust building
> that it actually inspects the image.

Yes, we would need to write some code that creates the kind of image (
that EC2 expects.  The documentation claims that "raw" format is
supported; I guess they have some unspoken requirements (like the fstab
thing you mentioned) that complicate matters?

https://docs.aws.amazon.com/vm-import/latest/userguide/vmimport-image-import.html#prerequisites-image

For what it's worth, if you have a support contract (even a low tier
one) with AWS, their support engineers can help answer questions.  I'm
sure they could also help figure out what the exact restrictions on the
formats are, if the documentation is not clear enough:

https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html

> Chris> Customizations, such as SSH credentials, would be specified
> Chris> in a GuixSD operating system configuration file and built
> Chris> into the VM image, so neither the EC2 metadata service, nor
> Chris> hacks like the "cloud-init" script used by some distros,
> Chris> would enter into the picture at all.
>
> Chris> Some preliminary work in a similar spirit was already done in
> Chris> the branch 'wip-deploy', but I don't think it was
> Chris> EC2-specific in any way.  Perhaps by looking there, you can
> Chris> find some inspiration?
>
> Here the immediate downside would be that stuff like auto-scaling does
> not work out of the box. Which some people consider one of the selling
> features of AWS, the prices for VM hosting being rather high.

I think auto-scaling is orthogonal to this discussion.  If we build a
way to deploy an EC2 instance from a GuixSD operating system
configuration file, then it implies that we also have the ability to
create an AMI from the operating system configuration file.  So
auto-scaling is definitely possible.  Whether or not auto-scaling works
for a given use case depends on the use case, not on the mechanism by
which the AMI used for auto-scaling was created.

> Chris> I think it would be better to spend your energy on creating a
> Chris> mechanism that allows an individual to build a GuixSD image
> Chris> from their own operating system configuration file, import
> Chris> that into EC2, and then launch an instance from it.  If such
> Chris> a feature were available in GuixSD, you could do it once from
> Chris> a desktop/laptop with a slow internet connection to create a
> Chris> "control server" in the cloud (with a fast internet
> Chris> connection), and then you could run it from the control
> Chris> server as needed to quickly spin up whatever other instances
> Chris> you might need.
>
> I think the above steps could be shortened somewhat and automated, if
> you know you're running on ec2.
>
> I don't see a way to cleanly import an image into AWS. This is however
> different for OpenStack, there you have an image service that does just
> what we need.

I haven't tried it myself, but I suspect that the "VM Import" feature is
the right approach.  I think it's probably the best thing to try first.
We would need to implement the mechanism for building a GuixSD system in
whatever VM format EC2 requires, and we would need to implement a Guile
interface for EC2 (or at least wrap the AWS CLI).

> I'll try my hand at optimizing these steps on the weekend.

Good luck!  If you need anything, I'm happy to talk.

Finally, I'd like to mention that although I work at AWS, this email
correspondence is entirely my own personal opinion and does not reflect
the views or opinions of my employer.

-- 
Chris


signature.asc
Description: PGP signature