Re: Having trouble packaging DefaultEncrypt for Emacs

[Chris Marusich]

Alex Kost  writes:

> Alex Kost (2017-04-11 23:04 +0300) wrote:
>
>> 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)
>
> Oops, I forgot one thing:
>
>   (autoload 'mml-secure-encrypt-if-possible "jl-encrypt")
>   (autoload 'mml-secure-check-encryption-p "jl-encrypt")
>
>> 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.

Neat!  I didn't know much about the "autoload" stuff.  I've read the
section in the manual, and thanks to these examples, it makes more
sense.  Thank you!

-- 
Chris


signature.asc
Description: PGP signature

Progress and todos for Jave maven

[Hartmut Goebel]

Hello,

TL;DR: some progress on packaging maven; still a lot todo; need help
from Java-developers.

1) Some progress on packaging maven

I spent quite some on packaging maven again. This time I took a
different approach which looks promising; maven comes with a list of
transitive dependencies and includes a "build.xml" for bootstrapping via
ant. So I started re-implementing the ant-tasks in guix (which are a few
simple one only) and packaging the transitive dependencies.

My first idea was to merge all sources into one big source tree. But
this showed up to lead to an uggly and complicated (and thus hard to
maintain) package definition. (And afterwards I discovered this would
not even work since some meta-data file would need to be merged.) So I
started building "bootstrap" packages for the dependecies.

Packaging the dependencies showed up to be tricky, since for compiling
these packages, other unlisted packages are required. That's a mess! So
I started deleting classes (files) under the assumption that this
code-part will not be used by maven since the dependency is not listed.
Some code can not be removed or would lead to more and more code to be
removed, so needed to package the dependency.

One package (googe guice) includes another ant-task which is delivered
as a jar-file. Luckily this jar includes the source files, too, but
there seems to be no source-repository for this ant-task.

maven also requires some source to be generated at build-time using
"modello". It took me two days to make this work, I even needed to set
up a Eclipse development environment and step through the code, just to
find out that "could not find plugin" actually means: "plugin found, but
initiating it failed due to x.y.z missing". Even increasing the
debug-level did not show this. What crap!

While I'm now confident to make this work, is is quite time-consuming :-(


2) Still a lot todo / roadmap

After we managed to have some bootstrap-maven, these are the next tasks:

  * write a maven-build-system (see below)
  * package all the dependencies of maven using the maven-build-system
and the bootstrap-maven and including all code. This means to
package a lot more complicated dependencies.
  * Decide on naming conventions, repository structure, which data to be
kept in poms, etc. (see below for all of these)
  * Clean up all the clutter, e.g. find official sources, homepage,
descriptions, etc. for all packages,


3) Help needed from Java-Developers

I'll write this in a separate mail :-)
 

P.S.: My respect on the Java development community has vanished
completely. I've never seen another programming language having thus a
crappy source infrastructure: projects without home-page, packages
without source, packages not able to bootstrap itself, outdated links,
and thus. Bootstrapping (well, what they call bootstrapping) maven using
ant downloads 67 MB, many jars are fetches in five different version,
for one I counted even 12 versions! This is how unmaintainable software
grows!

-- 
Regards
Hartmut Goebel

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

Need help from Java-developers

[Hartmut Goebel]

Hi,

as bootstrapping maven progresses (see my other post), the need for help
from Java-developers arises.

To finish all the work to be done after maven bootstrapping, some
experienced Java developers are needed. The following questions need to
be answered.

  * Designing the maven-build-system as follows:
  o How to maven commands map to our build phases? Should they map,
should there be new ones?
  o Is there a need to clean up the pom-files prior to building,
e.g. remove version numbers?
  o How to make the maven-build-system to never ever include other
jar? Perhaps we need to post-process the generated jars.
  o How to handle pom-files (see below)

  * Which naming conventions should be used for packages? Maven has the
notion of "group-id" and "atrtifact". Should this be kept? OTOH,
there are very common packages like "commons-io" aka
"apache-commons-io".

  * Where should the repo-files be kept in Guix? Debian seems to bot
them into a dir-structure which I assume is leaned on some
file-structure in the maven central repository. See

 and


  * Where to keep the pom-files? Are there other files we need (I've
seen "effective pom", and "maven-fragments" in other distros)? Can
or should we strip these files, like Debian seems to to with the
maven-repo-helper? If so: What do we need? can this be done in guix,
is there a maven-plugin, or …?

  * Help finding official sources, homepages, etc. for all packages. For
many packages the data in the pom is outdated, since e.b.
codehaus.org and code.google.com are gone.


Please comment!

-- 
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

potluck in the house

[Andy Wingo]

Hi!

This is an update on "guix potluck", an attempt to support a more
decentralized way of developing Guix packages, as a complement to the
main package set.

I have a number of packages that I never packaged for external use, at
least beyond putting them in a git repo somewhere.  Here's an example of
packaging one of these with guix potluck.  Guile-Present is a library
that lets you write presentations in Texinfo and uses Cairo to render
nthat to slides.

I dug up the repo and pushed it to gitlab at
https://gitlab.com/wingo/guile-present.  Then in the root directory of
that checkout I ran:

  guix potluck init

and it carps, saying

  guix potluck init: wrong number of arguments
  usage: guix potluck init [OPT...] REMOTE-GIT-URL
  Try 'guix potluck --help' for more information.

If you run help you see you need a URL for the public git repo.  Cool, I
have that:

  guix potluck init https://gitlab.com/wingo/guile-present

Now it says:

  guix potluck: error: init: missing --build-system; try --build-system=help 
for options

OK, I do that:

  guix potluck: Available build systems:
antThe standard Ant build system
asdf/ecl   The build system for ASDF binary packages using ECL
asdf/sbcl  The build system for ASDF binary packages using SBCL
asdf/sourceThe build system for ASDF source packages
cargo  Cargo build system, to build Rust crates
cmake  The standard CMake build system
dubDUB build system, to build D packages
emacs  The build system for Emacs packages
glib-or-gtkThe GNU Build System—i.e., ./configure && make && 
make install,
augmented with definition of suitable environment variables for glib and 
gtk+
in program wrappers.
gnuThe GNU Build System—i.e., ./configure && make && 
make install
haskellThe standard Haskell build system
ocaml  The standard OCaml build system
perl   The standard Perl build system
python The standard Python build system
r  The standard R build system
ruby   The standard Ruby build system
trivialTrivial build system, to run arbitrary Scheme build 
expressions
wafThe standard waf build system

  Additionally, --autotools is like --build-system=gnu, but also indicating
  that the package needs autoreconf before running ./configure.

OK great, sounds like --autotools is what I need.

  guix potluck init --autotools https://gitlab.com/wingo/guile-present

Yaargh:

  guix potluck: error: init: missing --license; try --license=help for options

OK let's get help then with --license=help:

  guix potluck: Available licenses:
agpl1  https://gnu.org/licenses/agpl.html
agpl3  https://gnu.org/licenses/agpl.html
agpl3+ https://gnu.org/licenses/agpl.html
artistic2.0http://www.perlfoundation.org/artistic_license_2_0
asl1.1 http://directory.fsf.org/wiki/License:Apache1.1
asl2.0 http://directory.fsf.org/wiki/License:Apache2.0
boost1.0   http://directory.fsf.org/wiki/License:Boost1.0
bsd-2  http://directory.fsf.org/wiki/License:FreeBSD
bsd-3  http://directory.fsf.org/wiki/License:BSD_3Clause
bsd-4  http://directory.fsf.org/wiki/License:BSD_4Clause
cc-by-sa2.0http://creativecommons.org/licenses/by-sa/2.0/
cc-by-sa3.0http://creativecommons.org/licenses/by-sa/3.0/
cc-by-sa4.0http://creativecommons.org/licenses/by-sa/4.0/
cc-by2.0   http://creativecommons.org/licenses/by/2.0/
cc-by3.0   http://creativecommons.org/licenses/by/3.0/
cc0http://directory.fsf.org/wiki/License:CC0
cddl1.0http://directory.fsf.org/wiki/License:CDDLv1.0
cecill-c   
http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html
clarified-artistic 
http://gianluca.dellavedova.org/2011/01/03/clarified-artistic-license/
copyleft-next  
https://raw.github.com/richardfontana/copyleft-next/master/Releases/copyleft-next-0.3.0
cpl1.0 http://directory.fsf.org/wiki/License:CPLv1.0
epl1.0 http://directory.fsf.org/wiki/License:EPLv1.0
expat  http://directory.fsf.org/wiki/License:Expat
fdl1.1+https://www.gnu.org/licenses/fdl-1.1
fdl1.2+https://www.gnu.org/licenses/fdl-1.2
fdl1.3+https://www.gnu.org/licenses/fdl.html
freebsd-doc
https://www.freebsd.org/copyright/freebsd-doc-license.html
freetype   http://directory.fsf.org/wiki/License:Freetype
gfl1.0 
http://www

Re: [PATCH 1/2] gnu: hurd: Add hurd-source-url procedure.

[Ludovic Courtès]

manolis...@gmail.com skribis:

> From: Manolis Ragkousis 
>
> * gnu/packages/hurd.scm (hurd-source-url): New procedure.
>   (hurd-headers)[source]: Adjust accordingly.

LGTM!

Ludo'.

Re: [PATCH 2/2] gnu: Add the Hurd.

[Ludovic Courtès]

Hey!

manolis...@gmail.com skribis:

> From: Manolis Ragkousis 
>
> * gnu/packages/hurd.scm (hurd): New variable.
> * gnu/packages/patches/hurd-fix-eth-multiplexer-dependency.patch: New file.
> * gnu/local.mk (dist_patch_DATA): Add it.

[...]

> +(synopsis "The kernel servers for the GNU operating system")
> +(description
> + "The Hurd is the kernel for the GNU system, a replacement and
> +augmentation of standard Unix kernels.  It is a collection of protocols for
> +system interaction (file systems, networks, authentication), and servers
> +implementing them.")
> +(license gpl2+)))

Should we add a ‘supported-systems’ field here?  I suppose it can only
be built natively on GNU/Hurd in practice.

> diff --git a/gnu/packages/patches/hurd-fix-eth-multiplexer-dependency.patch 
> b/gnu/packages/patches/hurd-fix-eth-multiplexer-dependency.patch
> new file mode 100644
> index 0..4a4b9c634
> --- /dev/null
> +++ b/gnu/packages/patches/hurd-fix-eth-multiplexer-dependency.patch
> @@ -0,0 +1,26 @@
> +From def663310ba75c46a6345983e9480abc425b1c94 Mon Sep 17 00:00:00 2001
> +From: Manolis Ragkousis 
> +Date: Sat, 8 Apr 2017 16:25:14 +0300
> +Subject: [PATCH] eth-multiplexer: Fix iohelp missing dependency.
> +
> +* eth-multiplexer/Makefile (HURDLIBS): Add iohelp.

Please add a link to the upstream commit or discussion.

OK with these changes, thank you!

Ludo’.

Re: AWS + OpenStack support

[Ludovic Courtès]

Heya,

Mark Meyer  skribis:

> So I'd like to extend Shepherd with a first-boot service that runs `guix
> system reconfigure'. And as a second step I want to include a Guile
> package that queries the metadata server. You should be able to do
> something like
>
>   (user "guix-sd"
> (public-keys (metadata-get-keys)))

For this part, you can look at how we register SSH public keys (for lshd
though, not sshd) in this module:

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/people.scm

I’d like to take this functionality in GuixSD proper and also add it for
sshd.

Thanks,
Ludo’.

Re: Some suggestion about "Contributing" documents.

[Ludovic Courtès]

Hello,

"Feng Shu"  skribis:

> "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"

For #2, did you see:

  https://www.gnu.org/software/guix/manual/html_node/Defining-Packages.html

Adding a package for your own use (a private package collection) does
not fit in the “Contributing” section IMO.

Ludo’.

Re: libxml2: Wrong separator in XML_CATALOG_FILES?

[Ludovic Courtès]

Maxim Cournoyer  skribis:

> Hello Hartmut,
>
> On Tue, Apr 11, 2017 at 10:27 PM, Hartmut Goebel
>  wrote:
>>
>> 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] 
>
> From my experiences with the udisks package, the XML_CATALOG_FILES
> entries should be separated by space.

Specifically, catalog.c in libxml2 has this:

/* the XML_CATALOG_FILES envvar is allowed to contain a
   space-separated list of entries. */
cur = catalogs;
nextent = &catal->xml;
while (*cur != '\0') {
while (xmlIsBlank_ch(*cur))
cur++;

Ludo’.

Re: Problem installing Guix on OpenVZ host that uses zfs

[Ludovic Courtès]

Hello!

Stefan Reichör  skribis:

> Here is the part that triggers the problem as I assume (I can send the
> full log as well when it is needed):
>
> [pid 31032] open("/proc/self/mountinfo", O_RDONLY) = 17
> [pid 31032] read(17, "2860 2854 0:102 / / rw,noatime m"..., 4096) = 4076
> [pid 31032] read(17, "", 4096)  = 0
> [pid 31032] close(17)   = 0
> [pid 31032] mount(NULL, "/", NULL, MS_PRIVATE, NULL) = -1 EACCES (Permission 
> denied)
> [pid 31032] futex(0x7f827449c190, FUTEX_WAKE_PRIVATE, 2147483647) = 0
> [pid 31032] write(2, "while setting up the build envir"..., 97) = 97
> [pid 31032] exit_group(1)   = ?
> [pid 31028] close(16)   = 0
>
> The entry for "/" in /proc/self/mountinfo is:
> 3966 3548 0:102 / / rw,noatime master:129 - zfs 
> satazpool/data/subvol-618-disk-1 rw,xattr,posixacl

The corresponding code in nix/libstore/build.cc is this:

--8<---cut here---start->8---
/* Make all filesystems private.  This is necessary
   because subtrees may have been mounted as "shared"
   (MS_SHARED).  (Systemd does this, for instance.)  Even
   though we have a private mount namespace, mounting
   filesystems on top of a shared subtree still propagates
   outside of the namespace.  Making a subtree private is
   local to the namespace, though, so setting MS_PRIVATE
   does not affect the outside world. */
Strings mounts = 
tokenizeString(readFile("/proc/self/mountinfo", true), "\n");
foreach (Strings::iterator, i, mounts) {
vector fields = tokenizeString >(*i, " 
");
string fs = decodeOctalEscaped(fields.at(4));
if (mount(0, fs.c_str(), 0, MS_PRIVATE, 0) == -1)
throw SysError(format("unable to make filesystem `%1%' 
private") % fs);
}
--8<---cut here---end--->8---

So “fs.c_str()” evaluates to “/”, as expected.

Now maybe zfs-on-linux doesn’t implement MS_PRIVATE or has specific
constraints (is it on FUSE?).  Perhaps you should check with the
zfs-on-linux people what they think of it.

Thanks,
Ludo’.

Re: A Suggestion about guix-devel-mode

[Ludovic Courtès]

Chris Marusich  skribis:

> Alex Kost  writes:
>
>> To make it clear, this is a question about Emacs-Guix.
>>
>> Feng Shu (2017-04-12 07:10 +0800) wrote:
>>
>>> Maybe we should add three addition keybinding:
>>>
>>> 1. Force rebuild the package defined by the current variable definition.
>>
>> What do you mean?  What is the analogous guix shell command?
>
> I could be wrong, but I don't think you can in general force a rebuild.
> The only way to force a rebuild that I know of is to GC the store path
> and then rebuild the package or derivation.  If I'm wrong, someone
> please correct me!

You can also force a rebuild with “guix build foo --check”, whose main
purpose is to check for bit-reproducibility.

Ludo’.

Re: Getting rid of alpha label

[Ludovic Courtès]

Heya!

Pjotr Prins  skribis:

> 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 agree.  ;-)

After FOSDEM Ricardo removed the big blue banner that was saying Guix is
alpha/beta.  So now the only mentions of “beta” that are left are:

  1. on the “TEST” button on the home page;
  2. under GuixSD at .

I think we can remove #1.  Is this what you had in mind?

Cheers,
Ludo’.

Re: AWS + OpenStack support

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> Heya,
>
> Mark Meyer  skribis:
>
>> So I'd like to extend Shepherd with a first-boot service that runs `guix
>> system reconfigure'. And as a second step I want to include a Guile
>> package that queries the metadata server. You should be able to do
>> something like
>>
>>   (user "guix-sd"
>> (public-keys (metadata-get-keys)))
>
> For this part, you can look at how we register SSH public keys (for lshd
> though, not sshd) in this module:
>
>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/people.scm
>
> I’d like to take this functionality in GuixSD proper and also add it for
> sshd.

I'm not Mark, but I have a question.  When you say "this functionality",
which of the following do you mean?

* A first-boot service that runs 'guix system reconfigure'.

* A Guile module to facilitate querying the EC2 metadata server - this
  would provide the metadata-get-keys procedure as shown above.

* The ability to register a user's SSH public keys by declaring them in
  the operating system configuration file, as shown above.

-- 
Chris


signature.asc
Description: PGP signature

Re: A Suggestion about guix-devel-mode

[Chris Marusich]

l...@gnu.org (Ludovic Courtès) writes:

> Chris Marusich  skribis:
>
>> Alex Kost  writes:
>>
>>> To make it clear, this is a question about Emacs-Guix.
>>>
>>> Feng Shu (2017-04-12 07:10 +0800) wrote:
>>>
 Maybe we should add three addition keybinding:

 1. Force rebuild the package defined by the current variable definition.
>>>
>>> What do you mean?  What is the analogous guix shell command?
>>
>> I could be wrong, but I don't think you can in general force a rebuild.
>> The only way to force a rebuild that I know of is to GC the store path
>> and then rebuild the package or derivation.  If I'm wrong, someone
>> please correct me!
>
> You can also force a rebuild with “guix build foo --check”, whose main
> purpose is to check for bit-reproducibility.

Good to know!  Thank you for the tip.

-- 
Chris


signature.asc
Description: PGP signature

Re: 01/02: gnu: libressl: Update to 2.5.3.

[Ludovic Courtès]

Leo Famulari  skribis:

> This is libressl-portable bug #290:
>
> https://github.com/libressl-portable/portable/issues/290
>
> There is a problem with using getentropy() or getrandom() from
> glibc-2.25 with Linux < 3.17, when these syscalls where introduced.
> Basically, glibc will return ENOSYS, which applications are not handling
> properly.
>
> I expect the build to succeed on armhf, where I believe the builders
> have kernels > 3.17.
>
> In the case of libressl, the developers have closed as WONTFIX, although
> perhaps they could be persuaded to make libressl handle ENOSYS somehow.
>
> Cpython hit the same problem, and they worked around it. This means that
> the Python interpreters Hydra builds for x86_64 and i686 not use the new
> getentropy() / getrandom() syscalls, even though many Guix users and
> probably all GuixSD users have more recent kernels:
>
> https://bugs.python.org/issue29157
>
> Can we disable the build on Hydra without marking the package as
> non-substitutable?

A simple approach is to force LibreSSL to always use its non-getentropy
code, and lift this restriction once we clearly require newer kernels¹.
The attached patch does that.

Thoughts?

Thanks,
Ludo’.

¹ We currently build libc with "--enable-kernel=2.6.32", and this is
  pretty much what defines our minimal kernel version requirement.

diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm
index 1c99a3ad7..5fe35a535 100644
--- a/gnu/packages/tls.scm
+++ b/gnu/packages/tls.scm
@@ -442,6 +442,10 @@ required structures.")
(base32
 "0c4awq45cl757fv7f7f75i5i0ibc6v7ns13n7xvfak7chv2lrqql"
 (build-system gnu-build-system)
+(arguments
+ ;; Do as if 'getentropy' was missing since older Linux kernels lack it
+ ;; and libc would return ENOSYS, which is not properly handled.
+ '(#:configure-flags '("ac_cv_func_getentropy=no")))
 (native-search-paths
   ;; FIXME: These two variables must designate a single file or directory
   ;; and are not actually "search paths."  In practice it works OK in

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

[ng0]

Andy Wingo transcribed 6.6K bytes:
> Hi,
> 
> I just "installed" GuixSD on a DigitalOcean droplet.  You can't actually
> install GuixSD; you have to mutate an existing installation into
> GuixSD.  But fine.
> 
> So I installed the latest Debian x86_64 image that they offer.  All fine
> and easy.  You tell DigitalOcean your SSH key, then you can SSH directly
> to root@your-ip.
> 
> Having done this, I proceeded to the binary Guix installation:
> Then finally:
[… ]
> guix system reconfigure os-config.scm
> 
> Now once you reboot, it works :)
> 
> That's all.  Hope yall find this useful.  Now, to clean up the remaining
> Debian bits!
> 
> Andy
> 

Could this be applied to linode as well? Or does linode function
differently?
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: potluck in the house

[Ludovic Courtès]

Hi!

Andy Wingo  skribis:

> This is an update on "guix potluck", an attempt to support a more
> decentralized way of developing Guix packages, as a complement to the
> main package set.
>
> I have a number of packages that I never packaged for external use, at
> least beyond putting them in a git repo somewhere.  Here's an example of
> packaging one of these with guix potluck.  Guile-Present is a library
> that lets you write presentations in Texinfo and uses Cairo to render
> nthat to slides.

Turns out Guile-Present is already in Guix proper, but Guile-JPEG isn’t!
:-)

> I dug up the repo and pushed it to gitlab at
> https://gitlab.com/wingo/guile-present.  Then in the root directory of
> that checkout I ran:
>
>   guix potluck init
>
> and it carps, saying
>
>   guix potluck init: wrong number of arguments
>   usage: guix potluck init [OPT...] REMOTE-GIT-URL
>   Try 'guix potluck --help' for more information.
>
> If you run help you see you need a URL for the public git repo.  Cool, I
> have that:
>
>   guix potluck init https://gitlab.com/wingo/guile-present
>
> Now it says:
>
>   guix potluck: error: init: missing --build-system; try --build-system=help 
> for options

[...]

>   guix potluck init --autotools --license=lgpl3+ 
> https://gitlab.com/wingo/guile-present
>
> And voilà:
>
>   Cloning into '/tmp/guix-directory.861r57/git-checkout'...  done.
>   Creating guix-potluck/
>   Creating guix-potluck/README.md
>   Creating guix-potluck/guile-present.scm
>
>   Done.  Now open guix-potluck/guile-present.scm in your editor, fill out its 
> "synopsis"
>   and "description" fields, add dependencies to the 'inputs' field, and try to
>   build with
>
> guix build --file=guix-potluck/guile-present.scm
>
>   When you get that working, commit your results to git via:
>
> git add guix-potluck && git commit -m 'Add initial Guix potluck files.'
>
>   Once you push them out, add your dish to the communal potluck by running:
>
> guix potluck update https://gitlab.com/wingo/guile-present master

Pretty cool!  I’m sure some of this could make sense for generic Guix
packages too.

> It builds, which is pretty cool.  (The wip-potluck branch extends guix
> build -f to recognize potluck packages.)

Oh I see, I was wondering why that was working.  :-)

Maybe we could have ‘guix potluck build’ or something?

> By default it connects to guix-potluck.org; you can use --host to
> specify a different host.  All connections to the potluck host are over
> HTTPS.  OK it spews some trash on stdout:
>
>   ERROR: In procedure get-bytevector-n:
>   ERROR: Throw to key `gnutls-error' with args `(# connection was non-properly terminated.> read_from_session_record_port)'.
>
> I don't understand this entirely; shouldn't nginx be terminating things
> fine?  I have never used the HTTP client with HTTPS though.

We’d have to debug it, but (guix build download) works fine.

> Anyway, fine.  So the server received this request, checked out that git
> repo and branch, looked for potluck packages in guix-potluck/, and added
> those packages to a "source" git repo:

Woow, that’s the really cool part.

>   (define-module (gnu packages potluck 
> https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present master guile-present)
> #:pure
> #:use-module ((guile) #:select (list quote define-public))
> #:use-module ((guix packages) #:select (package origin base32))
> #:use-module ((guix git-download) #:select (git-fetch git-reference))
> #:use-module ((guix licenses) #:select ((lgpl3+ . license:lgpl3+)))
> #:use-module ((guix build-system gnu) #:select (gnu-build-system))
> #:use-module ((gnu packages pkg-config) #:select (%pkg-config))
> #:use-module ((gnu packages texinfo) #:select (texinfo))
> #:use-module ((gnu packages autotools) #:select (libtool automake 
> autoconf))
> #:use-module ((gnu packages gtk) #:select (guile-cairo))
> #:use-module ((gnu packages guile) #:select (guile-lib guile-2.0)))

Since #:select doesn’t play well with circular dependencies among
modules, we should probably avoid it for the (gnu packages potluck …)
modules.

Also, I wonder if this should use ‘specification->package’ for packages
provided by Guix?

> Now this git repo should be able to be added to the GUIX_PACKAGE_PATH.
> It's effectively a "channel" managed by "guix potluck host-channel"
> running on guix-potluck.org.  If you have a checkout of this repo, you
> can build Guile-Present just via "guix build -L /path/to/target/checkout
> guile-jpeg".  Pretty cool, right??!!!?!?!

Pretty cool, indeed!

The nice thing is that we can pretty much unleash it on Guile users very
soon!

> Incidentally here is the configuration for that server:

We should add a potluck server service in GuixSD, too, so that this
config can be shrinked, and to make it easier to run a potluck server.

> Hi!  You scrolled down all this way, congratulations!
>
> So, remaining tasks to do:
>
>   (1) All of this is currently in a WIP branch, wip-potlu

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

[Andy Wingo]

On Thu 13 Apr 2017 17:28, ng0  writes:

> Andy Wingo transcribed 6.6K bytes:
>> I just "installed" GuixSD on a DigitalOcean droplet.  You can't actually
>> install GuixSD; you have to mutate an existing installation into
>> GuixSD.  But fine.
>
> Could this be applied to linode as well? Or does linode function
> differently?

Hi,

I think it can apply directly to linode as well:

  
http://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-distribution-supplied-kernel-with-kvm

Apparently there is the option to use DHCP as well, which is nice:

  https://www.linode.com/docs/networking/linux-static-ip-configuration

Andy

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

[ng0]

Andy Wingo transcribed 0.7K bytes:
> On Thu 13 Apr 2017 17:28, ng0  writes:
> 
> > Andy Wingo transcribed 6.6K bytes:
> >> I just "installed" GuixSD on a DigitalOcean droplet.  You can't actually
> >> install GuixSD; you have to mutate an existing installation into
> >> GuixSD.  But fine.
> >
> > Could this be applied to linode as well? Or does linode function
> > differently?
> 
> Hi,
> 
> I think it can apply directly to linode as well:
> 
>   
> http://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-distribution-supplied-kernel-with-kvm
> 
> Apparently there is the option to use DHCP as well, which is nice:
> 
>   https://www.linode.com/docs/networking/linux-static-ip-configuration
> 
> Andy
> 

Cool, thanks.
I'll write about it if it works.
One of the next steps I have in server documentation, is to ask 1984 ehf
if they have special requirements, what could work out for them in best
case scenario, etc.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

Re: potluck in the house

[Andy Wingo]

Hi :)

On Thu 13 Apr 2017 17:42, l...@gnu.org (Ludovic Courtès) writes:

> Turns out Guile-Present is already in Guix proper, but Guile-JPEG isn’t!
> :-)

Oh neat :)

>> (The wip-potluck branch extends guix build -f to recognize potluck
>> packages.)
>
> Oh I see, I was wondering why that was working.  :-)
>
> Maybe we could have ‘guix potluck build’ or something?

We could, but I was getting a bit overloaded with all the config options
you might want (substitutes, grafts, input replacements, etc) so I just
extended "build".  To do so, you just have to make the environment in
which the file is loaded also have the "potluck-package" and
"potluck-source" bindings, and then add another special case along with
package? / derivation? / etc.  WDYT?  OK or not the right thing?

>> Anyway, fine.  So the server received this request, checked out that git
>> repo and branch, looked for potluck packages in guix-potluck/, and added
>> those packages to a "source" git repo:
>
> Woow, that’s the really cool part.
>
>>   (define-module (gnu packages potluck 
>> https%3A%2F%2Fgitlab.com%2Fwingo%2Fguile-present master guile-present)
>> #:pure
>> #:use-module ((guile) #:select (list quote define-public))
>> #:use-module ((guix packages) #:select (package origin base32))
>> #:use-module ((guix git-download) #:select (git-fetch git-reference))
>> #:use-module ((guix licenses) #:select ((lgpl3+ . license:lgpl3+)))
>> #:use-module ((guix build-system gnu) #:select (gnu-build-system))
>> #:use-module ((gnu packages pkg-config) #:select (%pkg-config))
>> #:use-module ((gnu packages texinfo) #:select (texinfo))
>> #:use-module ((gnu packages autotools) #:select (libtool automake 
>> autoconf))
>> #:use-module ((gnu packages gtk) #:select (guile-cairo))
>> #:use-module ((gnu packages guile) #:select (guile-lib guile-2.0)))
>
> Since #:select doesn’t play well with circular dependencies among
> modules, we should probably avoid it for the (gnu packages potluck …)
> modules.

Is this still the case?  With Guile 2.2 we fixed
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15540 so maybe this isn't
a problem.

> Also, I wonder if this should use ‘specification->package’ for packages
> provided by Guix?

It certainly could, and indeed it could do so for all packages.
Currently it uses specification->package only if it can't resolve the
module in which a package is exported at compile-time.  I think this
probably leads to better run-time overhead when the files are compiled
to .go and a package graph that makes more sense but I don't know.

>> Now this git repo should be able to be added to the GUIX_PACKAGE_PATH.
>> It's effectively a "channel" managed by "guix potluck host-channel"
>> running on guix-potluck.org.  If you have a checkout of this repo, you
>> can build Guile-Present just via "guix build -L /path/to/target/checkout
>> guile-jpeg".  Pretty cool, right??!!!?!?!
>
> Pretty cool, indeed!
>
> The nice thing is that we can pretty much unleash it on Guile users very
> soon!

Guix users I guess you mean? :)  There is of course nothing
Guile-specific in this facility.  But yeah as a solution to the Guile
"CPAN problem", yes definitely!

>> Incidentally here is the configuration for that server:
>
> We should add a potluck server service in GuixSD, too, so that this
> config can be shrinked, and to make it easier to run a potluck server.

Yes, and improve the nginx configuration, and add a fcgiwrap service,
and add a git http service... :)

>>   (2) The host-channel facilities run user-supplied Scheme code.  To do
>>   so safely, that needs sandbox facilities from Guile.  That will
>>   need Guile 2.2.1.  For the time being I have disabled the server.
>
> Given that ‘potluck-package’ is very declarative, I was wondering
> whether it would be simpler to simply interpret it as data (have a
> ‘potluck-sexp->package’ compiler), as opposed to setting up a sandbox
> with a white-list of bindings.  Of course inert data is not as nice as
> something programmable, but in this case it looks like users would not
> really depart from what the default template.  Thoughts?
>
> Anyway, that’s really an “implementation detail.”

Yeah I don't know.  I thought that would maybe be good but then it's
also kinda cool that we provide a capability for abstraction in these
package definitions.  I can imagine interesting extensions given that
it's a programming language rather than data.  And this way we do take
advantage of cheap syntax checking via macros, pushing people to program
Scheme, and it's nice to be able to paste these definitions into a REPL
too... and we certainly want the record type!

I see what you are saying but since it doesn't seem to be necessary I am
tempted to punt, given that we can get Guix-on-Guile-2.2.1 out very soon
(a couple weeks maybe?).

> Now, I realize that none of it is Guile-specific, is it?  So there’s the
> question of the effect it can have on contributions to Guix prop

Re: AWS + OpenStack support

[Mark Meyer]

> "Chris" == Chris Marusich  writes:

Chris> l...@gnu.org (Ludovic Courtès) writes:

Chris> I'm not Mark, but I have a question.  When you say "this
Chris> functionality", which of the following do you mean?

Chris> * A first-boot service that runs 'guix system reconfigure'.

Chris> * A Guile module to facilitate querying the EC2 metadata
Chris> server - this would provide the metadata-get-keys procedure
Chris> as shown above.

Chris> * The ability to register a user's SSH public keys by
Chris> declaring them in the operating system configuration file, as
Chris> shown above.

The third one, as far as I can see :)

Cheers, Mark

Re: AWS + OpenStack support

[Mark Meyer]

> "Ludovic" == Ludovic Courtès  writes:

Ludovic> Heya, Mark Meyer  skribis:

Ludovic> For this part, you can look at how we register SSH public
Ludovic> keys (for lshd though, not sshd) in this module:

Ludovic>   
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/people.scm

Ludovic> I’d like to take this functionality in GuixSD proper and
Ludovic> also add it for sshd.

Can I take this task?

Cheers, Mark

Re: AWS + OpenStack support

[ng0]

Mark Meyer transcribed 0.5K bytes:
> > "Ludovic" == Ludovic Courtès  writes:
> 
> Ludovic> Heya, Mark Meyer  skribis:
> 
> Ludovic> For this part, you can look at how we register SSH public
> Ludovic> keys (for lshd though, not sshd) in this module:
> 
> Ludovic>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/people.scm
> 
> Ludovic> I’d like to take this functionality in GuixSD proper and
> Ludovic> also add it for sshd.
> 
> Can I take this task?
> 
> Cheers, Mark
> 

It would be very welcome. This is currently one of two blocking features
I need until I can introduce GuixSD to IN-Berlin e.V. (among other
services they run virtual servers as a non-profit).

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

Re: 01/02: gnu: libressl: Update to 2.5.3.

[Leo Famulari]

On Thu, Apr 13, 2017 at 05:08:29PM +0200, Ludovic Courtès wrote:
> A simple approach is to force LibreSSL to always use its non-getentropy
> code, and lift this restriction once we clearly require newer kernels¹.
> The attached patch does that.
> 
> Thoughts?

> + ;; Do as if 'getentropy' was missing since older Linux kernels lack it
> + ;; and libc would return ENOSYS, which is not properly handled.
> + '(#:configure-flags '("ac_cv_func_getentropy=no")))

If we are committed to building glibc with the 2.6 kernel headers, and
to providing substitutes for libressl and it's dependent packages, then
I think this patch is a good option.

But, it's a bit of a shame to leave this ~2.5 year old feature behind,
especially when the 2.6 Linux series is not even part of the Linux
long-term-support project. [0] These kernels *will* live for a long time
through support from RHEL; their most recent kernel on RHEL7 is 3.10.

However, I don't fully understand the impact of building glibc with a
newer set of headers, so my objection is a weak one :)

Personally, I don't think it's paramount to offer substitutes for the
packages in question. But I know this is an unpopular position, in
general :)

[0]
https://ltsi.linuxfoundation.org/
https://www.kernel.org/


signature.asc
Description: PGP signature

Re: AWS + OpenStack support

[Mark Meyer]

> "ng0" == ng0   writes:
ng0> It would be very welcome. This is currently one of two blocking
ng0> features I need until I can introduce GuixSD to IN-Berlin
ng0> e.V. (among other services they run virtual servers as a
ng0> non-profit).

Concerning the OpenSSH configuration, if we don't want to create files
in $HOME, it's possible to pass multiple AuthorizedKeysFile directives
to the server, so this might be:

 AuthorizedKeysFile %h/.ssh/authorized_keys /etc/ssh/%u/authorized_keys

So that guix would control /etc/ssh/%u and you can alternatively add you
own keys to $HOME/.ssh/authorized_keys.

Cheers, Mark

-- 
   Mark Meyer
   m...@ofosos.org

Re: 01/02: gnu: libressl: Update to 2.5.3.

[Leo Famulari]

On Thu, Apr 13, 2017 at 02:59:21PM -0400, Leo Famulari wrote:
> On Thu, Apr 13, 2017 at 05:08:29PM +0200, Ludovic Courtès wrote:
> > A simple approach is to force LibreSSL to always use its non-getentropy
> > code, and lift this restriction once we clearly require newer kernels¹.
> > The attached patch does that.
> > 
> > Thoughts?
> 
> > + ;; Do as if 'getentropy' was missing since older Linux kernels lack it
> > + ;; and libc would return ENOSYS, which is not properly handled.
> > + '(#:configure-flags '("ac_cv_func_getentropy=no")))
> 
> If we are committed to building glibc with the 2.6 kernel headers, and
> to providing substitutes for libressl and it's dependent packages, then
> I think this patch is a good option.
> 
> But, it's a bit of a shame to leave this ~2.5 year old feature behind,
> especially when the 2.6 Linux series is not even part of the Linux
> long-term-support project. [0] These kernels *will* live for a long time
> through support from RHEL; their most recent kernel on RHEL7 is 3.10.
> 
> However, I don't fully understand the impact of building glibc with a
> newer set of headers, so my objection is a weak one :)

After reading more, I realized that my knowledge on this topic was even
weaker than I thought. So please disregard what I wrote here.


signature.asc
Description: PGP signature