Re: Having trouble packaging DefaultEncrypt for Emacs

[Alex Kost]

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.

-- 
Alex

Re: A Suggestion about guix-devel-mode

[Alex Kost]

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?

> 2. Install/upgrade the package defined by the current variable definition.
> 3  Remove package defined by the current variable definition.

Hm, interesting idea, I need to think about it, thanks!

-- 
Alex

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

[Mark H Weaver]

l...@famulari.name (Leo Famulari) writes:

> lfam pushed a commit to branch master
> in repository guix.
>
> commit 69121e95cd5568238a0f207dfab708501ec4a753
> Author: Leo Famulari 
> Date:   Tue Apr 11 13:09:03 2017 -0400
>
> gnu: libressl: Update to 2.5.3.
> 
> * gnu/packages/tls.scm (libressl): Update to 2.5.3.

This failed to build on Hydra on both x86_64 and i686 (the only builds
that have been attempted so far):

  https://hydra.gnu.org/build/1976679  (x86_64)
  https://hydra.gnu.org/build/1976657  (i686)

In both cases 26 out of 60 tests failed, and from a quick glance it
seems to be the same set of failures in both cases, so this doesn't
appear to be a non-deterministic problem.

Could you take a look?

 Mark

Re: libxml2: Wrong separator in XML_CATALOG_FILES?

[Maxim Cournoyer]

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. I could find at least one source
which said it should be spaces [1], and another one suggested that
both the column and spaces should work, at least on Unix [2]. I guess
to get a definitive answer one would have to dive in the code of
libxml2.

I suggest we stick to what is known to work, i.e., using the space as
the separator for XML_CATALOG_FILES.

[1] Effective XML: 50 Specific Ways to Improve Your XML, by Elliotte
Rusty Harold 
(https://books.google.co.jp/books?id=GBT61nOT058C&pg=PA259&lpg=PA259&dq=xsltproc+XML+CATALOG+FILES+space+separated&source=bl&ots=UHr4NuXm1C&sig=9GgLW41OUmNOC9cRvyNyM6d3lYw&hl=en&sa=X&ved=0ahUKEwiq1tu2jp_TAhXCx7wKHazGDpMQ6AEIOTAD#v=onepage&q&f=false)

[2] Discussion on Gnome mailing list:
https://mail.gnome.org/archives/xml/2002-October/msg00028.html

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

[Leo Famulari]

On Wed, Apr 12, 2017 at 05:15:32AM -0400, Mark H Weaver wrote:
> l...@famulari.name (Leo Famulari) writes:
> > gnu: libressl: Update to 2.5.3.
> > 
> > * gnu/packages/tls.scm (libressl): Update to 2.5.3.
> 
> This failed to build on Hydra on both x86_64 and i686 (the only builds
> that have been attempted so far):
> 
>   https://hydra.gnu.org/build/1976679  (x86_64)
>   https://hydra.gnu.org/build/1976657  (i686)

The failures look like this:

[...]
FAIL: arc4randomforktest.sh
PASS: asn1test
PASS: base64test
../test-driver: line 107:  6370 Killed  "$@" > $log_file 2>&1
FAIL: bntest
PASS: bftest
PASS: asn1time
PASS: bytestringtest
PASS: chachatest
../test-driver: line 107:  6397 Killed  "$@" > $log_file 2>&1
FAIL: cipherstest
../test-driver: line 107:  6402 Killed  "$@" > $log_file 2>&1
FAIL: cipher_list
../test-driver: line 107:  6410 Killed  "$@" > $log_file 2>&1
[...]

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?


signature.asc
Description: PGP signature

Re: Problem installing Guix on OpenVZ host that uses zfs

[Leo Famulari]

On Tue, Apr 11, 2017 at 10:07:30PM +0200, Stefan Reichör wrote:
> 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

This comes from DerivationGoal() in 'nix/libstore/build.cc'.

I'm not sure what it's trying to do with `/' and I'm also not familiar
with that rather long function, so can you try attaching to the daemon
with strace [0] and letting us know exactly where it fails?

[0] Something like:
$ strace -f -p $(pgrep guix-daemon | head -n1)


signature.asc
Description: PGP signature

Re: Issues while updating fossil to 2.1

[Leo Famulari]

On Tue, Apr 11, 2017 at 10:44:12AM +, ng0 wrote:
> 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

We are still building packages with OpenSSL-1.0.2, so we can ignore this
issue for now, right?

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

We *should* have sqlite 3.18 after the next core-updates cycle,
hopefully by June 15.


signature.asc
Description: PGP signature

Re: Issues while updating fossil to 2.1

[Leo Famulari]

On Tue, Apr 11, 2017 at 10:32:31AM +, ng0 wrote:
> 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?).

Has fossil made a release that depends on sqlite 3.18? I think we will
offer this version of sqlite before most distros, but not immediately;
it was released only 2 weeks ago.

Re: Use OpenSSH in the bare-bones GuixSD template [was Re: how to "install" guixsd on a digitalocean server]

[Leo Famulari]

On Sun, Apr 09, 2017 at 02:21:50PM +, ng0 wrote:
> Leo Famulari transcribed 1.4K bytes:
> > On Sun, Apr 09, 2017 at 09:08:45AM +, ng0 wrote:
> > > What you added here is opensshd listening on port  with
> > > password-logins allowed, correct?
> > 
> > Yes, and the rest of the defaults can be found here:
> > 
> > https://www.gnu.org/software/guix/manual/html_node/Networking-Services.html#index-openssh_002dconfiguration
> > 
> > My intention is that it behaves the same way as the current bare-bones
> > template using lsh-service.
> 
> Okay, I was just making sure what your intentions are. I know the
> openssh service.
> 
> The changes look good to me.

I've pushed the change as eea2f45369f49d244e99257fcc71a9f367fdf0fd.

Re: Issues while updating fossil to 2.1

[ng0]

Leo Famulari transcribed 0.8K bytes:
> On Tue, Apr 11, 2017 at 10:32:31AM +, ng0 wrote:
> > 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?).
> 
> Has fossil made a release that depends on sqlite 3.18? I think we will
> offer this version of sqlite before most distros, but not immediately;
> it was released only 2 weeks ago.
> 

https://fossil-scm.org is always running the HEAD of fossil, and because
they are very closely connected to sqlite I think that's the reason why
the implement use of new versions as soon as possible. No release has
been published, but commits are already made with 3.18.
-- 
PGP and more: https://people.pragmatique.xyz/ng0/

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

[Alex Kost]

myglc2 (2017-04-10 18:56 -0400) wrote:

> Info source was included but not previously being built.
>
> From 5b757a33ffb1528621027aeecff07a7b95c5df39 Mon Sep 17 00:00:00 2001
> From: George Clemmer 
> Date: Mon, 10 Apr 2017 18:31:52 -0400
> Subject: [PATCH] gnu: emacs-ag: build/install info
>
> * gnu/packages/emacs.scm (emacs-a): build/install info
> ---
>  gnu/packages/emacs.scm | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index cc14fd228..4e788830c 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -56,6 +56,7 @@
>#:use-module (gnu packages gtk)
>#:use-module (gnu packages gnome)
>#:use-module (gnu packages ncurses)
> +  #:use-module (gnu packages python)
>#:use-module (gnu packages tex)
>#:use-module (gnu packages texinfo)
>#:use-module (gnu packages tls)
> @@ -1125,9 +1126,23 @@ than @code{electric-indent-mode}.")
> ("ag-executable"
>  (string-append (assoc-ref inputs "the-silver-searcher")
> "/bin/ag")))
> - #t)
> + #t))
> + (add-before 'install 'make-info
> +   (lambda _
> + (with-directory-excursion "docs"
> +   (unless (zero? (system* "make" "info"))
> + (error "makeinfo failed")

This error is not needed, just (zero? ...)

> + (add-after 'install 'install-info
> +   (lambda* (#:key inputs outputs #:allow-other-keys)
  ^^
'inputs' variable is not needed here as it is not used in the body.

> + (let* ((out  (assoc-ref outputs "out"))
> +(info (string-append out "/share/info")))
> +   (install-file "docs/_build/texinfo/agel.info" info)
> +   #t))
>  (inputs
>   `(("the-silver-searcher" ,the-silver-searcher)))
> +(native-inputs
> + `(("python-sphinx" ,python-sphinx)
> +   ("texinfo" ,texinfo)))
>  (propagated-inputs
>   `(("dash" ,emacs-dash)
> ("s" ,emacs-s)))

I added a copyright line for you and committed:

http://git.savannah.gnu.org/cgit/guix.git/commit/?id=99517d92709ee979c3507994caeb18db1eed08a6

Thanks!

-- 
Alex

Re: Problem installing Guix on OpenVZ host that uses zfs

[Stefan Reichör]

Hi Leo,

> On Tue, Apr 11, 2017 at 10:07:30PM +0200, Stefan Reichör wrote:
>> 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
>
> This comes from DerivationGoal() in 'nix/libstore/build.cc'.
>
> I'm not sure what it's trying to do with `/' and I'm also not familiar
> with that rather long function, so can you try attaching to the daemon
> with strace [0] and letting us know exactly where it fails?
>
> [0] Something like:
> $ strace -f -p $(pgrep guix-daemon | head -n1)

Cool trick :-)

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


Stefan.

Re: A Suggestion about guix-devel-mode

[Chris Marusich]

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!

-- 
Chris


signature.asc
Description: PGP signature

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

[myglc2]

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

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

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

Re: Getting rid of alpha label

[Christopher Allan Webber]

Pjotr Prins writes:

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

I thought we were in beta?  That's what the website homepage says now...

Re: Getting rid of alpha label

[Pjotr Prins]

On Wed, Apr 12, 2017 at 10:43:12PM -0500, Christopher Allan Webber wrote:
> I thought we were in beta?  That's what the website homepage says now...

Was I wearing my reading glasses? Even beta we should remove for the
packages.

Pj.
--