Re: [PATCH] gnu: Add python-xopen.

[Ben Woodcroft]

On 18/12/16 11:00, Tobias Geerinckx-Rice wrote:

Marius,

On 16/12/16 17:09, Marius Bakke wrote:

Pypi archives are sometimes smaller than the raw sources

Oh, I didn't know that.


or otherwise "prepared", but I guess no inherent benefits.

Good point. I can certainly see people relying too heavily on GitHub
(and similar) tarball auto-generation, while uploading a better one to
PyPI that they've actually bootstrapped.

Since this one builds fine, and the GitHub project is the official home
page for better or worse, I'd vote against adding an ‘additional
dependency on PyPI infrastucture’ as I think someone on the list put it.


Another reason for using pypi is that the github updater ignores tagged 
but not released 'releases', such as this. Perhaps we should change 
that, do others have an opinion?


Since using pypi is the way Python users expect to be able to install 
packages, making developers less concerned about their github releases 
than their pypi ones, I reckon sticking with pypi-uri is the way to go.


ben

Re: [PATCH] gnu: Add python-xopen.

[Tobias Geerinckx-Rice]

Marius,

On 16/12/16 17:09, Marius Bakke wrote:
> Pypi archives are sometimes smaller than the raw sources

Oh, I didn't know that.

> or otherwise "prepared", but I guess no inherent benefits.

Good point. I can certainly see people relying too heavily on GitHub
(and similar) tarball auto-generation, while uploading a better one to
PyPI that they've actually bootstrapped.

Since this one builds fine, and the GitHub project is the official home
page for better or worse, I'd vote against adding an ‘additional
dependency on PyPI infrastucture’ as I think someone on the list put it.

A glance at the Guix commit log suggests you're far more knowledgable
than I about anything Python, though.

Kind regards,

T G-R



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] gnu: r: Update to 3.3.2

[Ben Woodcroft]

On 17/12/16 17:52, Ben Woodcroft wrote:


Hi Raoul, good to see you here.


On 17/12/16 03:16, Ra wrote:

* gnu/packages/statistics.scm (r): Update to 3.3.2.


I successfully built R and all of its 243 dependencies on x86_64, and 
except for the previously failing shogun, all built successfully. So I 
think it is OK for master.


Unless anyone objects, I'll push it to master tomorrow.



I added at attribution line and pushed as 
a1814e4a27aa2e99283d381ec7e090706fa1031d.

Re: [PATCH] gnu: star: Update to 2.5.2b.

[Ben Woodcroft]

On 17/12/16 23:28, Ben Woodcroft wrote:

Hi,

On 17/12/16 18:25, Ra wrote:


---
 gnu/packages/bioinformatics.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


Thanks for the patch. I pushed this as 
'c9e9154e993f055a438e2e43518bbd0740aaaf24' after modifying the commit 
message and removing the extra precompiled binary it is now bundled with.


I forgot about adding an attribution line for you. Fixed in 
3fffabce2a0e7013379d090a72199df703d5e66d.

Re: Back from the Reproducible Build Summit, 2nd edition

[Chris Marusich]

Hi Ludo!

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

> Here’s a report from the 2nd Reproducible Build Summit that took place
> this week!
>
>   
> https://gnu.org/software/guix/news/reproducible-build-summit-2nd-edition.html

Thank you for sharing these notes.  I see you mentioned some follow-up
tasks, like hopefully supporting the "k out of n" substitute policy by
the next summit.  Are we tracking tasks like that somewhere?

-- 
Chris


signature.asc
Description: PGP signature

[PATCH] Update emacs-org.

[Nicolas Goaziou]

Hello,

The following patch updates emacs-org to its latest version.

Regards,

-- 
Nicolas Goaziou0x80A93738
>From fef548e5b623fd182d3ea0acdb705b38fdf6d5d3 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou 
Date: Sat, 17 Dec 2016 23:29:09 +0100
Subject: [PATCH] gnu: emacs-org: Update to 20161214.

* gnu/packages/emacs.scm (emacs-org): Update to 20161214.
---
 gnu/packages/emacs.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index eea20d0..547c440 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -3266,14 +3266,14 @@ passive voice.")
 (define-public emacs-org
   (package
 (name "emacs-org")
-(version "20161118")
+(version "20161214")
 (source (origin
   (method url-fetch)
   (uri (string-append "http://elpa.gnu.org/packages/org-;
   version ".tar"))
   (sha256
(base32
-"1w9g8r08kaiw9f4fjsj0hbffzq85rj734j5lxvbaafbnz7dbklk1"
+"0pa9d0l6axif5wlzi7lvxl0fpjwwvc79cy9d37z7md4hxyjdvwzm"
 (build-system emacs-build-system)
 (home-page "http://orgmode.org/;)
 (synopsis "Outline-based notes management and organizer")
-- 
2.10.1

[PATCH] gnu: maxima: Update to 5.39.0.

[Kei Kebreau]

This was supposed to be a simple version bump for Maxima, but it has
come to my attention that Maxima hasn't built reproducibily for quite a
while now (since version 5.36.1 according to my tests, possibly
further). Is there any particular reason why? I can't seem to pinpoint
the cause.


From 0c43d0a7838d3b1133265dc4137451cc8986c02d Mon Sep 17 00:00:00 2001
From: Kei Kebreau 
Date: Sat, 17 Dec 2016 16:03:46 -0500
Subject: [PATCH] gnu: maxima: Update to 5.39.0.

* gnu/packages/maths.scm (maxima): Update to 5.39.0.
---
 gnu/packages/maths.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm
index ce7eecfa7..7ce00c8dc 100644
--- a/gnu/packages/maths.scm
+++ b/gnu/packages/maths.scm
@@ -1857,7 +1857,7 @@ to BMP, JPEG or PNG image formats.")
 (define-public maxima
   (package
 (name "maxima")
-(version "5.38.1")
+(version "5.39.0")
 (source
  (origin
(method url-fetch)
@@ -1865,7 +1865,7 @@ to BMP, JPEG or PNG image formats.")
version "-source/" name "-" version ".tar.gz"))
(sha256
 (base32
- "1p6646rvq43hk09msyp0dk50cqpkh07mf4x0bc2fqisqmcv6b1hf"))
+ "1cvignn5y6qzrby6qb885yc8zdcdqdr1d50vcvc3gapw2f0gk3zm"))
(patches (search-patches "maxima-defsystem-mkdir.patch"
 (build-system gnu-build-system)
 (inputs
-- 
2.11.0



signature.asc
Description: PGP signature

Re: [PATCH] gnu: utox: Fix description.

[Leo Famulari]

On Thu, Dec 15, 2016 at 07:21:44PM +, ng0 wrote:
> * gnu/packages/messaging.scm (utox): Fix description.

Please re-submit this patch with the revised patches for c-toxcore, etc.

Re: [PATCH 2/2] gnu: utox: Update to 0.11.0.

[Leo Famulari]

On Thu, Dec 15, 2016 at 07:14:15PM +, ng0 wrote:
> * gnu/packages/messaging.scm (utox): Update to 0.11.0.
> [source]: Update source uri.
> [build-system]: Change to cmake-build-system.
> [arguments]: Remove previous content and disable tests,
> add two new phases.
> [inputs]: Remove libtoxcore, add c-toxcore.
> [native-inputs]: Remove it.

Overall LGTM, but can you give some more information about the changed
source location?

> - (uri (string-append "https://github.com/GrayHatter/uTox/archive/v;
> + (uri (string-append "https://github.com/uTox/uTox/archive/v;
>   version ".tar.gz"))

Re: [PATCH 1/2] gnu: Add c-toxcore.

[Leo Famulari]

On Thu, Dec 15, 2016 at 07:14:14PM +, ng0 wrote:
> * gnu/packages/messaging.scm (c-toxcore): New variable.

> +(version "0.1.0")

I see a new release:

https://github.com/TokTok/c-toxcore/tree/v0.1.1

> +(source
> + (origin
> +   (method url-fetch)
> +   (uri (string-append "https://github.com/TokTok/c-toxcore/archive/v;
> +   version ".tar.gz"))

Is this the canonical source of c-toxcore? What is its relationship to
?

> +(arguments
> + `(#:phases
> +   (modify-phases %standard-phases
> + (add-after 'unpack 'autoconf
> +   (lambda _
> + (zero? (system* "autoreconf" "-vfi")

Is there no bootstrapped tarball? Okay if not, I'm just wondering.

Re: [PATCH] gnu: Add asunder.

[Leo Famulari]

On Sat, Dec 17, 2016 at 01:20:40AM -0800, Chris Marusich wrote:
> * gnu/packages/cdrom.scm (asunder): New variable.

Thanks!

> +(home-page "http://www.littlesvr.ca/asunder/index.php;)

I agree with the other reviewers about the home-page.

> +(inputs `(("gtk+-2" ,gtk+-2)
> +  ("glib" ,glib)
> +  ("libcddb" ,libcddb)
> +  ("cdparanoia" ,cdparanoia)
> +  ("lame" ,lame)
> +  ("vorbis-tools" ,vorbis-tools)
> +  ("flac" ,flac)
> +  ("opus" ,opus)
> +  ("wavpack" ,wavpack)
> +  ("libmpcdec" ,libmpcdec)))

I checked the references of the built package:
$ guix gc --references $(./pre-inst-env guix build asunder)
/gnu/store/1jh6z732id8w014i66abm2h2iivkwk8v-gdk-pixbuf+svg-2.34.0
/gnu/store/46kis1wxzqfk3yysaz6ds0pc7w195a3b-gtk+-2.24.31
/gnu/store/4glf79v1r1l4k7by4vf1lfldq7n0yafw-libcddb-1.3.2
/gnu/store/7m55pyfv0rm19rqrrr7xx0c2irsvaq3y-pango-1.40.1
/gnu/store/cd92wyv466fcfnavx3wcjcr8qln4ycix-atk-2.20.0
/gnu/store/cdi08kw7r6r684w8mk0xq0dkgpjhfpmd-gcc-4.9.4-lib
/gnu/store/hmc1jiyr29mk9cl2d9j0jwf0dim1q76g-freetype-2.6.3
/gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24
/gnu/store/n56vagr3zv7ildvh9b7mzvk7h4bgwjpf-shared-mime-info-1.7
/gnu/store/p56ai0sj3bbh8hdqc9qigdp91gj73brp-glib-2.48.2
/gnu/store/pkv2qqgprp4zxcqfspwwx81qm9lng0da-fontconfig-2.12.1
/gnu/store/qkw4zrwfybxww8f56nkb6hggxambk89b-bash-4.4.0
/gnu/store/y30l675nz41p87pmvzscqhhyhik626na-cairo-1.14.6
/gnu/store/zfm6sgn6mpv8yqfjwk23i7hnjib2rc30-asunder-2.8

Several inputs are missing from this list, so they will be garbage
collected when the user runs `guix gc`. Can you look into that?

> +;; Asunder can also encode to AAC using neroAacEnc and to Monkey's audio
> +;; using mac, but we do not include those libraries as they are non-free.

This comment isn't necessary, in my opinion.

> +(description
> + "Asunder is a graphical Audio CD ripper and encoder.  It can save audio

Does audio need to be capitalized here?

Re: [PATCH] doc: Mention "guix pull" during installation.

[Leo Famulari]

On Fri, Dec 16, 2016 at 09:38:02AM +0100, Petter wrote:
> good experience because of this. Proposing a patch to add this to the
> manual.

Thanks for looking out for the new user experience, which one tends to
forget as time passes :)

> * doc/guix.texi (Proceeding with the Installation): Add "guix pull".

> +At this point it is advisable to update the system, especially if the
> +installer is more than a few weeks old. Then most, if not all, packages
> +will be available as substitutes.
> +
> +@example
> +guix pull
> +@end example

So far, in practice, this seems to become necessary as a given release
grows old. This is a negative side effect of some limitations of our
build farm infrastructure.

Specifically, we start to garbage collect the substitutes that
correspond to a release as time goes by, for two reasons: we need the
disk space, and more importantly, our method of registering garbage
collector roots [0] is still rather crude.

Some of us are working on a different method of registering garbage
collector roots that will allow us to tell Hydra, "Keep the substitutes
for release X", or "Keep the substitutes for the master branch in the
last 3 months".

I've recently gave an explanation of why I think using `guix pull`
before installing GuixSD should not be recommended unconditionally:

http://lists.gnu.org/archive/html/bug-guix/2016-11/msg00047.html

In the specific case of installing GuixSD 0.11.0 today, `guix pull` is
necessary, because we lack the substitutes, and some packages can't be
built at all now [1]. But, adding these lines to the manual now won't
make it show up in the 0.11.0 installer manual.

I think we should work on improving our infrastructure in the next
release cycle, and revisit this change to the manual if we are still
having problems before the 0.13.0 release.

What does everyone think?

[0]
https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-gc.html

[1] For example:
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=d404a6f9711c8dcc1cc6cf55d8c07901aa450192

Re: [PATCH] gnu: tor: Recommend torsocks.

[Kei Kebreau]

Hartmut Goebel  writes:

> Am 15.12.2016 um 11:37 schrieb ng0:
>> -applications based on the TCP protocol.")
>> +applications based on the TCP protocol.
>> +To @code{torify} applications (to take measures to ensure that an
>> application,
>> +which has not been designed for use with Tor such as ssh, will use
>> only Tor for
>
> Even if his is already pushed: An empty line for making the new text
> another paragraph would be fine.

I agree; that change would make it more readable. I'll commit it at my
soonest oppurtunity provided someone doesn't beat me to it. Thanks, Hartmut.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add asunder.

[Hartmut Goebel]

Am 17.12.2016 um 10:20 schrieb Chris Marusich:
> +(home-page "http://www.littlesvr.ca/asunder/index.php;)

I'd leave of the "index.php" here. Its uselass and ugly :-)

-- 
Regards
Hartmut Goebel

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

Back from the Reproducible Build Summit, 2nd edition

[Ludovic Courtès]

Hello GNU folks!

Here’s a report from the 2nd Reproducible Build Summit that took place
this week!

  https://gnu.org/software/guix/news/reproducible-build-summit-2nd-edition.html

Ludo’.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: star: Update to 2.5.2b.

[Ben Woodcroft]

Hi,

On 17/12/16 18:25, Ra wrote:


---
 gnu/packages/bioinformatics.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


Thanks for the patch. I pushed this as 
'c9e9154e993f055a438e2e43518bbd0740aaaf24' after modifying the commit 
message and removing the extra precompiled binary it is now bundled with.

ben

Re: [PATCH 6/6] gnu: Add grub-efi.

[Marius Bakke]

> For anyone following along at home, I've attached the patches I'm using
> for UEFI GuixSD. The latter two probably won't work properly on a
> non-UEFI system, needs testing.

Never mind the last part, 'guix system vm-image' works fine with these
patches.


signature.asc
Description: PGP signature

Re: NetworkManager doesn't "Connect automatically"

[Chris Marusich]

Thomas Haller  writes:

> On Wed, 2016-12-14 at 01:38 -0800, Chris Marusich wrote:
>> Hi Thomas,
>> 
>> Thank you for the quick response!
>> 
>> Thomas Haller  writes:
>> 
>> > Did you build NetworkManager yourself? Is session-tracking properly
>> > enabled to use systemd-logind or consolekit.
>> 
>> Yes, I'm building it from source [1].  It looks like we might need to
>> adjust the way we build it to enable session-tracking, like you've
>> suggested.  Am I correct in understanding that I should only need to
>> pass the option "--with-systemd-logind=yes" to the configure script
>> to
>> enable session tracking via systemd-logind?  Is anything else
>> required?
>
> Hi,
>
> No, that should be enough.
>
> Possibly it was already enabled before, detected automatically?
>
> Thomas

OK.  Thank you for confirming my understanding.

In GuixSD, we actually use elogind [1] instead of systemd for session
tracking.  This requires us to patch the NetworkManager source to use
elogind instead of systemd libraries.  For example, we do this sort of
patching successfully when packaging polkit [2].

I tried the same thing with NetworkManager [3], but it didn't quite work
out.  There are a lot of references to systemd in NetworkManager, and I
think I'm just not familiar enough with NetworkManager, systemd, or
elogind to know for sure what needs to be patched to trick
NetworkManager into using elogind instead of systemd for session
management.  For now, we've committed the package definition as-is, but
until somebody figures out exactly how to patch it to work with elogind,
users must use the previously mentioned work-around (make the connection
available to all users) if they want to enable automatic connection.

Thank you again for your help.  Hopefully soon we'll figure out how to
get NetworkManager working with elogind in GuixSD!

[1] https://github.com/wingo/elogind
[2] 
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/polkit.scm?id=51b1d5398793bf717a9d2cb6478efc7a173754fa#n53
[3] 
http://git.savannah.gnu.org/cgit/guix.git/commit/gnu/packages/gnome.scm?id=fd070f35d3db24ecdfe68a18332339827bb7a259

-- 
Chris


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add asunder.

[John Darrington]

On Sat, Dec 17, 2016 at 01:20:40AM -0800, Chris Marusich wrote:

 +(define-public asunder
 +  (package
 +(name "asunder")
 +(version "2.8")
 +(home-page "http://www.littlesvr.ca/asunder/index.php;)
 +(source (origin
 +  (method url-fetch)

It's unueual to have the home-page field here.  Most package definitions place 
it just
before the synopsis.

J'

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: [PATCH 3/6] file-systems: Suppress fsck status completion bar.

[Marius Bakke]

Danny Milosavljevic  writes:

> Hi,
>
> why not just use "fsck -t xxx" instead? It will filter out "-C" for
> fscks which don't support it.

I think pending a proper solution for handling fsck commands, offloading
it to util-linux is a decent compromise. Ludo, WDYT?


signature.asc
Description: PGP signature

Re: [PATCH 6/6] gnu: Add grub-efi.

[Marius Bakke]

Ludovic Courtès  writes:

> Hi Marius,
>
> Marius Bakke  skribis:
>
>> Ludovic Courtès  writes:
>>
>> From 940c03c7dcddec019e27f6eb1470aeab4db57799 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke 
>> Date: Thu, 20 Oct 2016 17:26:52 +0100
>> Subject: [PATCH] gnu: Add grub-efi.
>>
>> * gnu/packages/grub.scm (grub-efi): New variable.
>
> [...]
>
>> +(name "grub-efi")
>> +(synopsis (string-append (package-synopsis grub) " (UEFI version)"))
>
> Please use a literal string for ‘synopsis’; use of ‘string-append’ like
> this prevents i18n.
>
>> + `(#:tests? #f ; FIXME: 40 failures, 24 skipped, 17 passed.
>
> It would be good to investigate, especially if the tests pass in the
> ‘grub’ package.
>
> Also, what’s the rationale for making ‘grub-efi’ separate instead of
> incorporating the changes in ‘grub’ proper?  Are there issues around the
> portability of ‘efibootmgr’, or an increased closure size?

 This is a good point. The only difference with "--with-platform=efi" is
 that another directory is created in place of the i386-pc directory. It
 is perfectly possible to build multiple platforms and copying the
 platform-specific stuff to $out/lib -- grub will pick the correct
 platform at runtime. This is what the Gentoo ebuild does.
>>>
>>> Are you saying that a GRUB compiled with UEFI support will no longer
>>> work out-of-the-box on non-UEFI machines, unless platform-specific stuff
>>> is moved like you suggest?
>>
>> Ha, no, it was just a long-winded and intoxicated way of saying what you
>> proposed should work fine. :)
>
> It turns out I have an immediate need ;-), so I pushed this as commit
> 3eee16130d858ae96510ec1c7d38d31290de2699.  Let me know if that doesn’t
> seem right!
>
> Now there are things I didn’t quite get.  Apparently you’re supposed to
> have a /boot/efi as a vfat partition, and ‘grub-install’ is supposed to
> detect it and install the EFI stuff, or so I thought (info "(grub)
> Installing GRUB using grub-install").
>
> However, ‘grub-install’ still seems to be installing for “i386-pc”
> instead of EFI.
>
> What am I missing?

For anyone following along at home, I've attached the patches I'm using
for UEFI GuixSD. The latter two probably won't work properly on a
non-UEFI system, needs testing.



signature.asc
Description: PGP signature
>From 0a7c923618e8323c684ac8328ea6aa498b8cb13c Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Thu, 3 Nov 2016 09:58:34 +
Subject: [PATCH 1/5] linux-initrd: Support FAT filesystems.

* gnu/system/linux-initrd.scm (base-initrd): When a FAT filesystem is
present: Add fatfsck/static in 'helper-packages'; and add nls_iso8859-1
in 'linux-modules'.
---
 gnu/system/linux-initrd.scm | 9 +
 1 file changed, 9 insertions(+)

diff --git a/gnu/system/linux-initrd.scm b/gnu/system/linux-initrd.scm
index 174239a56..a787072ba 100644
--- a/gnu/system/linux-initrd.scm
+++ b/gnu/system/linux-initrd.scm
@@ -29,6 +29,7 @@
 #:select (derivation->output-path))
   #:use-module (guix modules)
   #:use-module (gnu packages compression)
+  #:use-module (gnu packages disk)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages guile)
   #:use-module ((gnu packages make-bootstrap)
@@ -193,6 +194,9 @@ loaded at boot time in the order in which they appear."
   ,@(if (find (file-system-type-predicate "9p") file-systems)
 virtio-9p-modules
 '())
+  ,@(if (find (file-system-type-predicate "vfat") file-systems)
+'("nls_iso8859-1")
+'())
   ,@(if volatile-root?
 '("fuse")
 '())
@@ -205,6 +209,11 @@ loaded at boot time in the order in which they appear."
   file-systems)
 (list e2fsck/static)
 '())
+  ,@(if (find (lambda (fs)
+(string-suffix? "fat" (file-system-type fs)))
+  file-systems)
+(list fatfsck/static)
+'())
   ,@(if volatile-root?
 (list unionfs-fuse/static)
 '(
-- 
2.11.0


>From fbddad884b553b6a70ae4da0ee47f29599958704 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Thu, 3 Nov 2016 11:08:57 +
Subject: [PATCH 2/5] file-systems: Suppress fsck status completion bar.

* gnu/build/file-systems.scm (check-file-system): Drop "-C" argument
from fsck for compatibility with other fscks.
---
 gnu/build/file-systems.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm
index 431b287d0..b8dbe499d 100644
--- a/gnu/build/file-systems.scm
+++ b/gnu/build/file-systems.scm
@@ -415,7 +415,7 @@ the following:
   (define fsck
 (string-append "fsck." type))
 
-  (let ((status (system* fsck "-v" "-p" "-C" "0" device)))
+  (let 

Re: NetworkManager doesn't "Connect automatically"

[Chris Marusich]

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

> Following Andy’s advice I committed both with slightly-tweaked commit
> logs.  That’ll give lurkers out there an incentive to give it a try.
> ;-)
>
> Thank you Chris!
>
> Ludo’.

Thank you!  When I find some time, I'll look into modifying the polkit
rules for network manager so that the work-around (make the network
connection available to all users) works without requiring root to have
a password.  In the meantime, at least one can temporarily give root a
password, make the change, and then remove root's password.

Hopefully someone with more NetworkManager experience can help figure
out exactly what to patch to get the elogind support working right.

-- 
Chris


signature.asc
Description: PGP signature

Add Asunder

[Chris Marusich]

The following email contains a patch for Asunder.  I've tested it and verified
that it works in GuixSD for ripping a CD to OGG files.  (Note that you must be
able to read the CD-ROM device file, e.g., by being a member of the cdrom
group.)

- Chris

Re: Emacs-Guix released outside from Guix

[Alex Kost]

I have committed 'emacs-guix' package, so after "guix pull" or if you
use the git checkout, you may try it with:

  guix package -i emacs-guix

Just make sure it has a priority over the elisp code from Guix.
"M-x list-load-path-shadows" should help you to figure it out.

Now a bit about the changes.

1. At first, there are 2 new commands:

- M-x guix-help

  I think it may be the most useful command as it shows a summary of all
  the rest available commands.

- M-x guix-profiles

  It displays a list of your Guix profiles.  It's probably not very
  useful if you have a single profile, but if you manage multiple
  profiles, it can be really helpful (well, it's my favourite command as
  I use several profiles).  To add more profiles, set 'guix-profiles'
  variable.

  In this list you can display packages/generations with "P"/"G" keys.
  See also the manual entry: (info "(emacs-guix) Profiles")

2. Secondly, you may be surprised that RET does not display packages
anymore in a list of generations (M-x guix-generations) or licenses (M-x
guix-licenses).  Now "P" key can be used anywhere (where appropriate,
i.e. in a list of profiles, generations, licenses or locations) to
display packages.

3. Also I should mention that 'guix-devel-mode' and
'guix-build-log-minor-mode' are not enabled in scheme/shell buffers by
default.  If you still wish to have them enabled, use:

  (add-hook 'scheme-mode-hook 'guix-devel-mode)
  (add-hook 'shell-mode-hook 'guix-build-log-minor-mode)

in your emacs config.

4. The rest changes are either visible or internal or not important.
You may look at NEWS file for more or less the full list of changes:
.

Thanks for reading this far :-)

-- 
Alex

Re: Emacs-Guix released outside from Guix

[John Darrington]

On Sat, Dec 17, 2016 at 11:38:13AM +0300, Alex Kost wrote:

 > It would be a great loss and a technical hindrance if guix.el was 
moved
 > out of Guix.  I don???t want that to happen, so let me know what the
 > ransom should be!  ;-)
 
 There shouldn't be any ransom!  I just didn't feel I had enough freedom
 when I was working on it inside Guix.


Could you elaborate here?  What circumstances made you feel this way?  Have 
there
been specific events which made you feel your freedom was being limited?  What
would you have liked to have seen done differently?

J'
 
 

-- 
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.



signature.asc
Description: Digital signature

Re: Emacs-Guix released outside from Guix

[Alex Kost]

Ricardo Wurmus (2016-12-16 01:37 +0100) wrote:

> Hi Alex,
>
> Ludovic Courtès  writes:
>
>> Alex Kost  skribis:
>>
>>> Hello, I've been working on Emacs interface outside from the Guix repo
>>> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(
>>>
>>> The main reason, is, well, inconvenience for me: I don't like to bother
>>> people with patches, etc.  I tried to explain it at
>>> .
>>
>> As someone who’s always trusted you to do the right thing, I’m of course
>> disappointed that we Guix folks didn’t get notified nor consulted before
>> the fact.  I would also have loved a reply to my message back then¹.
>> That’s your choice though.
>>
>> ¹ https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01110.html
>
> First of all, let me tell you that I really appreciate your work on
> guix.el!  It’s excellent and makes me feel even more at home in Emacs.
>
> I whole-heartedly second what Ludo wrote and just now and back then:
>
> It would be a great loss and a technical hindrance if guix.el was moved
> out of Guix.  I don’t want that to happen, so let me know what the
> ransom should be!  ;-)

There shouldn't be any ransom!  I just didn't feel I had enough freedom
when I was working on it inside Guix.

> We’d love for guix.el to stay.  You can already modify the code as you
> deem appropriate without having to worry about a veto from any of us.

Sorry, but I have already pushed too much effort making it a separate
project, and it has changed quite a lot comparing to what we have in a
Guix repo.

>> Breakage will occasionally occur as the Guix APIs change, which will
>> make us all a bit sad.  What are your thoughts?
>
> This is the biggie for me.  Having the Emacs interface so closely
> integrated with the rest of Guix ensured that we wouldn’t have to worry
> about breakage.

How could we be ensured?  When a breakage happened in the past, an
according fix had to be done in the guix repo, and it wasn't available
for users until updating 'guix-devel' package.  Now when a breakage will
happen, an according fix will be done in the emacs-guix repo, and it
will be available for MELPA/Quelpa users right away.

> In my opinion this move increases the friction for the
> users that most care about guix.el for the dubious improvement of
> offering a slimmer guix.el to people who … don’t use Guix.

People can use Guix, but they can still prefer to install Emacs packages
via elpa, not via Guix.

>> I’ll let you take care of the actual removal, along with update to the
>> Texinfo cross-references and doc/htmlxref.cnf (assuming the manual will
>> be available on-line.)  I think it would help users to keep
>> cross-references between the two manuals.
>>
>> We need to see what Ricardo thinks and whether or not this can be done
>> before 0.12, which is slated for sometime next week.
>
> Yes, I’ll start preparing for the release (going through the motions) on
> the weekend, so that the actual tagging and uploading can happen on the
> 20th (busy on the 19th) if all goes well.
>
> If you go through with the move please double check that the Guix
> sources are in a state that’s ready for release.  It would be terrible
> to have a botched release.  (Frankly, I’m a little uncomfortable about
> such a big change right before the release, but maybe I’m just being
> nervous about doing the release myself this time…)

I'm going to send "removal" patches after the release.  BTW thank you
for taking care of the release!

-- 
Alex

[PATCH] gnu: star: Update to 2.5.2b.

[Ra]

---
 gnu/packages/bioinformatics.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/bioinformatics.scm
b/gnu/packages/bioinformatics.scm
index 3e9c82f..1b6532b 100644
--- a/gnu/packages/bioinformatics.scm
+++ b/gnu/packages/bioinformatics.scm
@@ -4924,7 +4924,7 @@ application of SortMeRNA is filtering rRNA from
metatranscriptomic data.")
 (define-public star
   (package
 (name "star")
-(version "2.5.2a")
+(version "2.5.2b")
 (source (origin
   (method url-fetch)
   (uri (string-append "
https://github.com/alexdobin/STAR/archive/;
@@ -4932,7 +4932,7 @@ application of SortMeRNA is filtering rRNA from
metatranscriptomic data.")
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32
-"0xjlsm4p9flln111hv4xx7xy94c2nl53zvdvbk9winmiradjsdra"))
+"1na6np880r1zaamiy00hy8bid5anpy0kgf63587v2yl080krk2zq"))
   (modules '((guix build utils)))
   (snippet
'(begin
-- 
1.9.1

Re: Emacs-Guix released outside from Guix

[Alex Kost]

Ludovic Courtès (2016-12-15 18:39 +0100) wrote:

> Hi Alex!
>
> Alex Kost  skribis:
>
>> Hello, I've been working on Emacs interface outside from the Guix repo
>> for some time, I mean I'm not going to maintain it inside Guix, sorry :-(
>>
>> The main reason, is, well, inconvenience for me: I don't like to bother
>> people with patches, etc.  I tried to explain it at
>> .
>
> As someone who’s always trusted you to do the right thing, I’m of course
> disappointed that we Guix folks didn’t get notified nor consulted before
> the fact.  I would also have loved a reply to my message back then¹.
> That’s your choice though.
>
> ¹ https://lists.gnu.org/archive/html/guix-devel/2016-07/msg01110.html

I'm sorry for not answering, I thought I was clear at the time.  I
always feel uncomfortable to send patches or to push commits to the Guix
repo.  I can't explain it properly, it's just painful all the time; but
more importantly, it slowed down the development, as I often decided not
to do small changes.  Contrary, I made more commits to the Emacs-Guix
source tree in the past month, than to the Guix repo during the whole
year.

>> There are 2 more reasons above that:
>>
>> - I'd like to make it available on MELPA (people asked about it several
>>   times in the past);
>
> This is surprising: I’d expect Guix users to install it with Guix, and
> non-Guix users to, well, not care about Guix.

It's not surprising for me: there are people who prefer to install Emacs
packages using Emacs build system, so providing this way to install
"guix.el" seems the right thing for me.

>> - Currently, to be able to use it on non-GuixSD system, a user has to
>>   install 'guix' package into their profile.  This has never looked good
>>   to me (installing a whole guix only for a small part of it). I would
>>   prefer to make "guix package -i emacs-guix" possible instead.
>
> OK.
>
> This change will prevent joint feature development (updating
> completions, ‘emacs-build-system’ and how it interacts with the Emacs
> UI, M-x guix, cross-cutting changes to the UI, and so on).  This isn’t
> good news for users.
>
> Breakage will occasionally occur as the Guix APIs change, which will
> make us all a bit sad.  What are your thoughts?

Well, I was going to make a release and to update the 'emacs-guix'
package after fixing such a breakage.  Actually this way doesn't look
worse for me: when breakages happened in the past, the only way to fix
it was to update 'guix-devel' package.

>> So I'd like to add 'emacs-guix' package (the current patchset) and to
>> remove it from the Guix source tree, if you don't mind.
>
> I think “if you don’t mind” is misplaced.

No, it's not misplaced; not sure what you mean.

>> I'm also sending the following patches:
>>
>> [PATCH 1/2] gnu: Add emacs-bui.
>> [PATCH 2/2] gnu: Add emacs-guix.
>
> OK!

Thanks!  Applied.

> I’ll let you take care of the actual removal, along with update to the
> Texinfo cross-references and doc/htmlxref.cnf (assuming the manual will
> be available on-line.)

Ahem, it will not, at least not soon.

> I think it would help users to keep
> cross-references between the two manuals.

Emacs-Guix manual has many links to the Guix manual, but I think a
single mention of Emacs-Guix in the Guix manual will be enough.  I have
not looked at updating cross-references in the Guix manual yet, though.

> We need to see what Ricardo thinks and whether or not this can be done
> before 0.12, which is slated for sometime next week.

I think this removal can be made later.

> Keep up the great Emacs work.  Long live guix.el!

Thanks, I keep up.

-- 
Alex

Re: Emacs-Guix released outside from Guix

[Alex Kost]

Ludovic Courtès (2016-12-16 17:44 +0100) wrote:

> Howdy!
>
> Ricardo Wurmus  skribis:
>
>> If you go through with the move please double check that the Guix
>> sources are in a state that’s ready for release.  It would be terrible
>> to have a botched release.  (Frankly, I’m a little uncomfortable about
>> such a big change right before the release, but maybe I’m just being
>> nervous about doing the release myself this time…)
>
> It’s fine to postpone the change until after the release if we’re afraid
> of last-minute breakage (which is not unlikely).

I agree, removing "guix.el" code and related changes can happen later,
no hurry about it, thanks!

-- 
Alex