Re: Having trouble packaging DefaultEncrypt for Emacs
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"))
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".
> 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).
[...]
> +(define-public emacs-default-encrypt
> + (package
> +(name "emacs-default-encrypt")
> +(version "4.3")
> +(source
> + (origin
> + (method url-fetch)
> + (uri (string-append
> + ;; A versioned, signed copy of this package is avialable on the
> + ;; home page, but 'guix download' fails to download it.
> +
> "https://github.com/emacsmirror/emacswiki.org/raw/master/jl-encrypt.el";))
Why do you use this third-party unversioned file instead of the original
source from the upstream? (it even has a GnuPG signature!):
https://www.informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt4.1/jl-encrypt.el
I found it on the home-page.
Add the following line here to fix ".el.el" problem:
(file-name (string-append "jl-encrypt-" version ".el"))
> + (sha256
> +(base32
> + "16i3rlfp3jxlqvndn8idylhmczync3gwmy8a019v29vyr48rnnr0"
> +(build-system emacs-build-system)
> +(home-page
> "https://www.informationelle-selbstbestimmung-im-internet.de/Emacs.html";)
> +(synopsis "Automatically encrypt and sign Gnus messages")
> +(description
> + "DefaultEncrypt is designed to be used with Gnus. It automatically
> +encrypts messages that you send (e.g., email) when public keys for all
> +recipients are available, and it protects you from accidentally sending
> +un-encrypted messages. It can also be configured to automatically sign
> +messages that you send. For details and instructions on how to use
> +DefaultEncrypt, please refer to the home page or read the comments in the
> +source file, @file{jl-encrypt.el}.")
> +(license license:gpl3+)))
--
Alex
Re: Having trouble packaging DefaultEncrypt for Emacs
Alex Kost (2017-04-10 13:10 +0300) wrote: > Chris Marusich (2017-04-08 17:21 -0700) wrote: [...] >> +(define-public emacs-default-encrypt >> + (package >> +(name "emacs-default-encrypt") >> +(version "4.3") >> +(source >> + (origin >> + (method url-fetch) >> + (uri (string-append >> + ;; A versioned, signed copy of this package is avialable on the >> + ;; home page, but 'guix download' fails to download it. >> + >> "https://github.com/emacsmirror/emacswiki.org/raw/master/jl-encrypt.el";)) > > Why do you use this third-party unversioned file instead of the original > source from the upstream? (it even has a GnuPG signature!): > > > https://www.informationelle-selbstbestimmung-im-internet.de/emacs/jl-encrypt4.1/jl-encrypt.el Sorry, I failed to read your comment above the URL :-) So the error is: --8<---cut here---start->8--- 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 --8<---cut here---end--->8--- 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 -- Alex
Re: 02/02: gnu: certbot: Share python-acme's arguments.
On Mon, Apr 10, 2017 at 12:48:27AM +0200, Marius Bakke wrote: > Not to pick on this patch, since this problem was present before..but: > > "install-file" has an unspecified return value, so I don't think it's > safe to use in an "and" block. The attached patch should be more > correct. WDYT? > > From e3bd8d6df932986c35a2f8088c491eb6f89ee6d5 Mon Sep 17 00:00:00 2001 > From: Marius Bakke > Date: Mon, 10 Apr 2017 00:26:45 +0200 > Subject: [PATCH] gnu: certbot, python-acme: Build documentation in separate > phase. > > * gnu/packages/tls.scm (python-acme)[arguments]<:phases>: Add > 'build-documentation' phase. Rename 'docs' phase to 'install-documentation'. > (certbot)[arguments]<:phases>: Adjust accordingly. LGTM, thanks for being picky :) signature.asc Description: PGP signature
AWS + OpenStack support
Hi list, is anybody interested in having support for running guix on AWS and/or OpenStack? I've GuixSD running on AWS. The way to get there was somewhat contrived, but it worked well. Basically these `cloud' environments provide some form of instance configuration. You're supposed to create an image of your OS and it'll self configure upon (first) boot. This includes more than enabling DHCP. Generally AWS will provide a so called metadata server. The important thing serves are your public keys. You'll generally specify a set of public keys on instance startup. 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))) Despite this the only thing that is required to run on AWS is basically an SSH implementation and a DHCP configuration. To get GuixSD running on AWS I did the following: - Build a disk-image out of my local GuixSD installation, enable OpenSSH and DHCP. Create a custom user and set the password. - Copy the disk-image to S3 - Create an IAM role that includes read-only access to S3 - Start an `Amazon Linux' instance as an intermediate, I used Amazon Linux but anything else will just work as well. Attach the IAM role, when creating the instance and also attach a 2GB sized EBS volume. - Log into the intermediate, download the disk-image from S3 onto local disk, then dd the image onto the attached 2GB EBS volume. - Do a snapshot of the 2GB volume, then register that as an AMI, setting the virtualization type to `HVM'. You could do without the S3 storage in the middle, but I like it better this way, since my internet access is not the fastest and you need to transfer 1~2GB. Is anybody interested in publicly accessible AMIs for AWS? An AMI is an Amazon Machine Image. When you got an AMI for your system, you can spin up an instance with minimal configuration. I would like to do the aforementioned steps during the next weekend, which will be a four day weekend in my country, so there's some time to kill. Let me know what you think, don't forget to CC me, since I'm not on the list. Cheers, Mark
Re: 03/06: gnu: Add python-django-allauth.
Mark H Weaver writes: > k...@openmailbox.org (Kei Kebreau) writes: > >> kkebreau pushed a commit to branch master >> in repository guix. >> >> commit e1f06e1192f57551bcb67d93411affb9d497e30c >> Author: ng0 >> Date: Wed Feb 15 10:09:24 2017 + >> >> gnu: Add python-django-allauth. >> >> * gnu/packages/django.scm (python-django-allauth): New variable. >> >> Signed-off-by: Kei Kebreau > > Both variants of this package failed to build on Hydra. > > 'python-django-allauth' was a dependency failure, for failure to build > the duplicate 'python-openid' package that you added. > > https://hydra.gnu.org/build/1974947 > https://hydra.gnu.org/build/1974947/nixlog/1/raw > > 'python2-django-allauth' failed while apparently trying to download > python-openid. > > https://hydra.gnu.org/build/1974907 > > I'm concerned at the number of problems in this batch of commits. > Did these packages build successfully on your machine? > > Mark They did build successfully on my machine. signature.asc Description: PGP signature
Re: 02/06: gnu: Add python-openid.
Mark H Weaver writes: > k...@openmailbox.org (Kei Kebreau) writes: > >> kkebreau pushed a commit to branch master >> in repository guix. >> >> commit ccda56886625af84d34ebf1f26b22345e5dbe235 >> Author: ng0 >> Date: Wed Feb 15 10:09:23 2017 + >> >> gnu: Add python-openid. >> >> * gnu/packages/python.scm (python-openid): New variable. >> >> Signed-off-by: Kei Kebreau > > We already have 'python-openid'. It's right above the one you just > added. I reverted this commit. > > Please be more careful. > > Thanks, > Mark Aw, man. :-( The really sad part is that I remember spotting this when I tested this patch a few weeks ago. Your advice is noted. signature.asc Description: PGP signature
[PATCH] gnu: emacs-ag: build/install info
Info source was included but not previously being built.
>From 5b757a33ffb1528621027aeecff07a7b95c5df39 Mon Sep 17 00:00:00 2001
From: George Clemmer
Date: Mon, 10 Apr 2017 18:31:52 -0400
Subject: [PATCH] gnu: emacs-ag: build/install info
* gnu/packages/emacs.scm (emacs-a): build/install info
---
gnu/packages/emacs.scm | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index cc14fd228..4e788830c 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -56,6 +56,7 @@
#:use-module (gnu packages gtk)
#:use-module (gnu packages gnome)
#:use-module (gnu packages ncurses)
+ #:use-module (gnu packages python)
#:use-module (gnu packages tex)
#:use-module (gnu packages texinfo)
#:use-module (gnu packages tls)
@@ -1125,9 +1126,23 @@ than @code{electric-indent-mode}.")
("ag-executable"
(string-append (assoc-ref inputs "the-silver-searcher")
"/bin/ag")))
- #t)
+ #t))
+ (add-before 'install 'make-info
+ (lambda _
+ (with-directory-excursion "docs"
+ (unless (zero? (system* "make" "info"))
+ (error "makeinfo failed")
+ (add-after 'install 'install-info
+ (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(info (string-append out "/share/info")))
+ (install-file "docs/_build/texinfo/agel.info" info)
+ #t))
(inputs
`(("the-silver-searcher" ,the-silver-searcher)))
+(native-inputs
+ `(("python-sphinx" ,python-sphinx)
+ ("texinfo" ,texinfo)))
(propagated-inputs
`(("dash" ,emacs-dash)
("s" ,emacs-s)))
--
2.12.2
Re: 04/06: gnu: Add python-django-gravatar2.
On Sun, 09 Apr 2017 04:04:34 -0400 Mark H Weaver wrote: > k...@openmailbox.org (Kei Kebreau) writes: > > > kkebreau pushed a commit to branch master > > in repository guix. > > > > commit 14d8f6538f3af04c2bc879837f94f0bc54177aed > > Author: ng0 > > Date: Wed Feb 15 10:09:25 2017 + > > > > gnu: Add python-django-gravatar2. > > > > * gnu/packages/django.scm (python-django-gravatar2): New > > variable. > > Signed-off-by: Kei Kebreau > > python-django-gravatar2 fails to build on Hydra: > > https://hydra.gnu.org/build/1974931 (x86_64-linux) > https://hydra.gnu.org/build/1974902 (i686-linux) > > The python2-* variants build successfully. > This seems to be a test failure, but I believe that the tests can be disabled. When testing python2-django-gravatar2 manually, the success message reports running "0 tests in 0.000s." signature.asc Description: PGP signature
Re: [PATCH 2/5] gnu: Add python-radon
On Wed, Apr 05, 2017 at 10:01:48AM +0300, Muriithi Frederick Muriuki wrote: > * gnu/packages/python.scm (python-radon): New variable. Hi, this patch series includes patches 2 through 5. Can you re-send it to with patch 1?
Re: [PATCH 2/5] gnu: Add python-radon
On Mon, Apr 10, 2017 at 11:53:26PM -0400, Leo Famulari wrote: > On Wed, Apr 05, 2017 at 10:01:48AM +0300, Muriithi Frederick Muriuki wrote: > > * gnu/packages/python.scm (python-radon): New variable. > > Hi, this patch series includes patches 2 through 5. Can you re-send it > to with patch 1? I noticed these patches don't seem to depend on patch 1, so they could be applied almost as-is. Comments to follow...
Re: [PATCH 2/5] gnu: Add python-radon
On Wed, Apr 05, 2017 at 10:01:48AM +0300, Muriithi Frederick Muriuki wrote: > * gnu/packages/python.scm (python-radon): New variable. LGTM, but can you add a Python 2 variant if it supports Python 2 as well? We typically do this for all Python packages. [0] [0] https://www.gnu.org/software/guix/manual/html_node/Python-Modules.html#Python-Modules
Re: [PATCH 4/5] gnu: Add python-pytest-httpbin
On Wed, Apr 05, 2017 at 10:01:50AM +0300, Muriithi Frederick Muriuki wrote: > * gnu/packages/python.scm (python-pytest-httpbin): New variable. If it supports Python 2, can you add a Python 2 variant? > +(version "0.0.7") Can you add a brief code comment explaining why we need this older version of pytest-httpbin?
Re: [PATCH 5/5] gnu: Add python-sphinx-rtd-theme-0.1.9
On Wed, Apr 05, 2017 at 10:01:51AM +0300, Muriithi Frederick Muriuki wrote: > * gnu/packages/python.scm (python-sphinx-rtd-theme-0.1.9): New variable. > +(define-public python-sphinx-rtd-theme-0.1.9 Can you add a comment about what requires this old version? Even if the dependent packages are not in Guix, a note like "Some software requires older versions of python-sphinx-rtd-theme." will be helpful to future readers.
Re: AWS + OpenStack support
Mark Meyer writes: > Hi list, is anybody interested in having support for running guix on AWS > and/or OpenStack? I think it'd be awesome if this were easier to do! This topic has come up before: https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00757.html https://lists.gnu.org/archive/html/help-guix/2016-11/msg00075.html Long story short, instead of starting with a base image and modifying it (e.g., by injecting credentials at first boot via the EC2 metadata service), one appealing alternative is to use EC2's VM import feature to actually import precisely the system that you want to launch: https://aws.amazon.com/ec2/vm-import/ Customizations, such as SSH credentials, would be specified in a GuixSD operating system configuration file and built into the VM image, so neither the EC2 metadata service, nor hacks like the "cloud-init" script used by some distros, would enter into the picture at all. Some preliminary work in a similar spirit was already done in the branch 'wip-deploy', but I don't think it was EC2-specific in any way. Perhaps by looking there, you can find some inspiration? > Basically these `cloud' environments provide some form of instance > configuration. You're supposed to create an image of your OS and it'll > self configure upon (first) boot. This includes more than enabling > DHCP. Generally AWS will provide a so called metadata server. The > important thing serves are your public keys. You'll generally specify a > set of public keys on instance startup. At first I thought that doing what you suggest was a good idea, but now I think it'd be better to implement the plan I mentioned above. > 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))) I don't think a "first boot" service like this is a good idea. To learn more about why, please read the following conversation between myself (marusich) and Dave (davexunit) on IRC: https://gnunet.org/bot/log/guix/2016-11-30 > Is anybody interested in publicly accessible AMIs for AWS? An AMI is an > Amazon Machine Image. When you got an AMI for your system, you can spin > up an instance with minimal configuration. I think it would be better to spend your energy on creating a mechanism that allows an individual to build a GuixSD image from their own operating system configuration file, import that into EC2, and then launch an instance from it. If such a feature were available in GuixSD, you could do it once from a desktop/laptop with a slow internet connection to create a "control server" in the cloud (with a fast internet connection), and then you could run it from the control server as needed to quickly spin up whatever other instances you might need. > I would like to do the aforementioned steps during the next weekend, > which will be a four day weekend in my country, so there's some time to > kill. Even if you just figured out a way to construct a VM image of the kind that can be imported into EC2, I think it would be a great first step in the right direction! Thank you for taking the time to look into this! -- Chris signature.asc Description: PGP signature
Some suggestion about "Contributing" documents.
"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" --
[Mark Meyer] Re: AWS + OpenStack support
Sorry, didn't go to the list. --- Begin Message --- > "Chris" == Chris Marusich writes: Chris> Mark Meyer writes: Chris> I think it'd be awesome if this were easier to do! This Chris> topic has come up before: Chris> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00757.html Chris> https://lists.gnu.org/archive/html/help-guix/2016-11/msg00075.html Ah. I completely missed the latter discussion. 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. 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. 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'll try my hand at optimizing these steps on the weekend. Cheer, Mark -- Mark Meyer m...@ofosos.org --- End Message --- -- Mark Meyer m...@ofosos.org
