[PATCH 0/1] Update libreoffice to address CVE-2015-5214.

[Leo Famulari]

This patch updates libreoffice to 5.0.3.2. This fixes the
vulnerabilities described in CVE-2015-5214.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5214

Leo Famulari (1):
  gnu: libreoffice: Update to 5.0.3.2 [fixes CVE-2015-5214].

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

-- 
2.6.2

[PATCH 1/1] gnu: libreoffice: Update to 5.0.3.2 [fixes CVE-2015-5214].

[Leo Famulari]

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

diff --git a/gnu/packages/libreoffice.scm b/gnu/packages/libreoffice.scm
index da7e275..7496a6c 100644
--- a/gnu/packages/libreoffice.scm
+++ b/gnu/packages/libreoffice.scm
@@ -676,7 +676,7 @@ and to return information on pronunciations, meanings and 
synonyms.")
 (define-public libreoffice
   (package
 (name "libreoffice")
-(version "5.0.0.2")
+(version "5.0.3.2")
 (source
  (origin
   (method url-fetch)
@@ -685,7 +685,7 @@ and to return information on pronunciations, meanings and 
synonyms.")
   "http://download.documentfoundation.org/libreoffice/src/";
   (version-prefix version 3) "/libreoffice-" version ".tar.xz"))
   (sha256 (base32
-   "0mzvxc4i5999xzmhgwrfvpvyx5772jylx5mary86drrld8klq7py"
+   "1gflcsnw7bx02jbb2x5darf56x0qgia03ylaycadk68ikibckybp"
 (build-system gnu-build-system)
 (native-inputs
  `(;; autoreconf is run by the LibreOffice build system, since after
-- 
2.6.2

Adding operating-system field for a custom /etc/profile.

[Alex Kost]

This is a continuation of the discussion beginning here:
.

To sum up: I would like to have a possibility to use my own /etc/profile
instead of the default one, but Ludovic doesn't want to provide me this
freedom :-(

Ludovic Courtès (2015-11-23 17:31 +0300) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2015-11-23 02:04 +0300) wrote:
>>
>>> Alex Kost  skribis:
[...]
 … what I suggest now is just to give an option to avoid generating the
 default /etc/profile.  What about making an 'operating-system' field for
 this file (similar to 'sudoers-file' or 'hosts-file')?  So when such
 'profile-file' is specified, it will be used instead of the default one
 (of course, it should be mentioned in the manual that it's only for
 those users who are sure what they do).
>>>
>>> I think we could make an /etc/profile-service that receives snippets
>>> meant to be glued together into the final /etc/profile.  Users could
>>> specify the top or bottom of the file.
>>>
>>> There could be a combined-search-paths-service that implements the
>>> solution I proposed here.
>>>
>>> WDYT?
>>
>> I agree, the more ways to change a default behaviour, the better.
>> Although I will not use these things if there will be ‘profile-file’
>> field that allows to specify my own "/etc/profile".
>
> [...]
>
>> Great!  So is it OK to send a patch for adding ‘profile-file’ field?
>
> Hmm, I’m not sure if we want to give direct access to /etc/profile like
> this.

Oh, no!  If there is one person (me) who wants to have a full control on
his /etc/profile, there may be the others with the same wish.

> The problem is that several things in there are here to make the system
> work, and to to make it conform to the ‘operating-system’ declaration,
> such as:
>
>
> export LANG="en_US.utf8"
> export TZ="Europe/Paris"
> export 
> TZDIR="/gnu/store/rwvf6xqgsyb8bmpi7rwk9fildnwvzrv5-tzdata-2015c/share/zoneinfo"
>
> # Tell 'modprobe' & co. where to look for modules.
> export LINUX_MODULE_DIRECTORY=/run/booted-system/kernel/lib/modules

Yes, that's why I suggest to add a note to the manual about a danger of
using this field.

> The risk I see with adding a raw ‘profile-file’ option is that newcomers
> may end up getting rid of such things without really noticing, and then
> getting a broken system.

But a newcomer will learn about this option only if (s)he reads the
manual with the warning I've mentioned.  For me, your phrase sounds
like: «We will not provide "rm" command, because a newcomer may
accidentally run "rm -rf ~"».  Please give me an opportunity to shoot
myself in the foot!

Besides will the system really be broken?  What do you mean?  Even if
/etc/profile is empty, the system will boot successfully and a user
could login, no?

> What about instead giving a way to populate the top and/or bottom of
> this file?  Controversial parts, if any, could still be turned on and
> off by adding or removing services that add these lines?

It is better than nothing, but it is not sufficient IMO.  Any part of
/etc/profile can be controversial (you'll never know what a user would
like to change), so I think providing an option to change this file
completely is essential.

But I agree that appending/prepending some lines may also be useful for
those who like to keep the default /etc/profile and who just want to add
something to it.

> I think we should open a separate bug report to discuss this.

I agree that it's not related to this bug, so I'm sending this message
to guix-devel list.

-- 
Alex

Re: Funding the build farm

[John Darrington]

On Sun, Nov 22, 2015 at 11:53:06AM +0100, Andreas Enge wrote:
 On Wed, Nov 18, 2015 at 07:29:55PM +0100, Ludovic Court??s wrote:
 > So, what can we do?  We could go to another fiscal sponsor for free
 > software projects in the US, either Conservancy or SPI, Inc., but they
 > may redirect us to the FSF because we???re GNU.

 It may still be interesting to also go via the FSF. This would mean bank
 accounts in the euro and the dollar currency spaces, and it might be easier
 for US donors to deduce donations from their taxes.

The FSF does have a EUR bank account.  However, if past experience is anything
to go by, then :

1.  The FSF will have little interest in collecting funds for specific projects.
They (with a few very special exceptions) only take donations which go into
central FSF funds to be dispersed as they think fit.

  AND

2.  The Conservancy (which normally DOES do directed funding) refuses to do so 
for
GNU projects, for fear of offending the FSF.


This is a crazy situation, but then they are American 
 
J'
 

-- 
Avoid eavesdropping.  Send strong encryted 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: Funding the build farm

[Mathieu Lirzin]

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

> Andreas Enge  skribis:
>
>> On Wed, Nov 18, 2015 at 07:29:55PM +0100, Ludovic Courtès wrote:
>>> So, what can we do?  We could go to another fiscal sponsor for free
>>> software projects in the US, either Conservancy or SPI, Inc., but they
>>> may redirect us to the FSF because we’re GNU.
>>> 
>>> We could look for something similar in Europe but I don’t know of any.
>>> 
>>> Or we could just create a bank account (I want to avoid PayPal) and
>>> possibly a non-profit and do it ourselves.  But this has drawbacks, see
>>>  for instance.
>>
>> Definitely I am in favour of creating a French "association loi 1901".
>> From what I have heard of diverse clubs I am a member of, this is rather
>> easy; but so far I have not had the time to look into it.
>
> Yeah I think it would be fine to do both, and probably more convenient
> for donors.
>
> I’m happy to join a bunch of French people to sit down and do the
> paperwork.

I think the paperwork for a French association would need the
rigorousness of a German.  ;)

--
Mathieu Lirzin

Re: Needed: Libreoffice update

[Leo Famulari]

I'll test it now.

On Mon, Nov 23, 2015, at 10:04, Mark H Weaver wrote:
> Libreoffice needs to be updated to at least 5.0.1 to fix CVE-2015-5214.
> Ideally, we'd update to 5.0.3, the latest release.
> 
> Would someone be willing to take care of this?  I wouldn't be able to
> test the build before pushing it, because our Libreoffice package
> currently builds only on x86_64 due to dependency failures, and I
> currently lack a working x86_64 machine.
> 
>   Mark
> 

Re: bug#21410: Environment containers

[Alex Vong]

Sorry for late reply. I can confirm the two tests are now skipped with
the latest master.

Cheers,
Alex

On 22/11/2015, Ludovic Courtès  wrote:
> Mathieu Lirzin  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>>
 FAIL: tests/guix-environment-container
 ==

 + set -e
 + guix environment --version
 guix environment (GNU Guix) 0.9.0
 Copyright (C) 2015 the Guix authors
 License GPLv3+: GNU GPL version 3 or later
 
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
 + tmpdir=t-guix-environment-29930
 + trap 'rm -r "$tmpdir"' EXIT
 + mkdir t-guix-environment-29930
 + guix environment --container --ad-hoc --bootstrap guile-bootstrap --
 guile -c '(exit 42)'
 guix environment: error: cannot create container: unprivileged user
 cannot create user namespaces
 guix environment: error: please set
 /proc/sys/kernel/unprivileged_userns_clone to "1"
>>>
>>> Oh I see, that part fell through the cracks.
>>>
>>> Could you confirm that the test is skipped with the attached patch?
>>
>> this test was failing on my system too, and it is skipped successfully
>> with this patch.
>
> Thanks, pushed as 6493fd0.
>
> Ludo’.
>

Needed: Libreoffice update

[Mark H Weaver]

Libreoffice needs to be updated to at least 5.0.1 to fix CVE-2015-5214.
Ideally, we'd update to 5.0.3, the latest release.

Would someone be willing to take care of this?  I wouldn't be able to
test the build before pushing it, because our Libreoffice package
currently builds only on x86_64 due to dependency failures, and I
currently lack a working x86_64 machine.

  Mark

Re: Funding the build farm

[Ludovic Courtès]

Andreas Enge  skribis:

> On Wed, Nov 18, 2015 at 07:29:55PM +0100, Ludovic Courtès wrote:
>> So, what can we do?  We could go to another fiscal sponsor for free
>> software projects in the US, either Conservancy or SPI, Inc., but they
>> may redirect us to the FSF because we’re GNU.
>> 
>> We could look for something similar in Europe but I don’t know of any.
>> 
>> Or we could just create a bank account (I want to avoid PayPal) and
>> possibly a non-profit and do it ourselves.  But this has drawbacks, see
>>  for instance.
>
> Definitely I am in favour of creating a French "association loi 1901".
> From what I have heard of diverse clubs I am a member of, this is rather
> easy; but so far I have not had the time to look into it.

Yeah I think it would be fine to do both, and probably more convenient
for donors.

I’m happy to join a bunch of French people to sit down and do the
paperwork.

Ludo’.

Re: [PATCH] gnu: Move pkg-config to native inputs.

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> Thanks to Ludo's work on Guix lint online.

Note that, for this particular checker, you may find it more convenient
to use M-x guix or M-x compile guix lint -c inputs-should-be-native RET
(runs in 1.5 second on my laptop.)

> I have made a patch but I don't know if this is safe to push it on
> master so I prefer requesting advices before.

Such changes usually require rebuilds, and a lot of them in the case of
GLib and PulseAudio.

There are some cases where such a change requires zero rebuilds though.
You can check by running, say,

  guix build glib -n

after making the change, and see if the thing would be rebuilt or if it
would be downloaded/is already on disk.  In the latter case, this means
that the change does not entail any rebuild and is safe.

> From 6a8f2286e307d5b77af3a546d5113c44bac13804 Mon Sep 17 00:00:00 2001
> From: Mathieu Lirzin 
> Date: Mon, 23 Nov 2015 10:44:53 +0100
> Subject: [PATCH] gnu: Move pkg-config to native inputs.
>
> * gnu/packages/glib.scm (gobject-introspection)[native-inputs]: Move
> pkg-config from inputs.
> * gnu/packages/pulseaudio.scm (libsndfile, libsamplerate)
> (pulseaudio)[native-inputs]: Likewise.
> * gnu/packages/xiph.scm (ao)[native-inputs]: Likewise.
> * gnu/packages/xorg.scm (xf86-video-geode)[native-inputs]: Likewise.

[...]

> -   ("pkg-config" ,pkg-config)
> ("python-2" ,python-2)))
>  (native-inputs
> - `(("glib" ,glib "bin")))
> + `(("glib" ,glib "bin")
> +   ("pkg-config" ,pkg-config)))

Most likely entails a rebuild so I’d push it to core-updates.

> --- a/gnu/packages/pulseaudio.scm
> +++ b/gnu/packages/pulseaudio.scm
> @@ -58,8 +58,9 @@
>  (inputs
>   `(("libvorbis" ,libvorbis)
> ("libogg" ,libogg)
> -   ("flac" ,flac)
> -   ("pkg-config" ,pkg-config)))
> +   ("flac" ,flac)))
> +(native-inputs
> + `(("pkg-config" ,pkg-config)))

This one might not entail a rebuild.  Please double-check, and send to
master if there’s no rebuild, core-updates otherwise.

> @@ -87,7 +88,8 @@ for reading and writing new sound file formats.")
>(base32
> "01hw5xjbjavh412y63brcslj5hi9wdgkjd3h9csx5rnm8vglpdck"
>  (build-system gnu-build-system)
> -(inputs `(("pkg-config" ,pkg-config)))
> +(native-inputs
> + `(("pkg-config" ,pkg-config)))
>  (propagated-inputs

Most likely no rebuilds, so same story here.

> @@ -162,13 +164,14 @@ rates.")
> ("dbus" ,dbus)
> ("glib" ,glib)
> ("intltool" ,intltool)
> -   ("pkg-config" ,pkg-config)
> ("m4" ,m4)
> ("libltdl" ,libltdl)
> ("fftwf" ,fftwf)
> ("avahi" ,avahi)
> ("eudev" ,eudev)   ;for the detection of hardware audio 
> devices
> ("check" ,check)))
> +(native-inputs
> + `(("pkg-config" ,pkg-config)))

Most likely a rebuild, so core-updates.

> --- a/gnu/packages/xiph.scm
> +++ b/gnu/packages/xiph.scm
> @@ -165,9 +165,11 @@ stereo encoding, and voice activity detection.")
>  ;; XXX: Should back-ends be pushed to different outputs?  For instance,
>  ;; "out" would include only the ALSA back-end, while "pulse" would
>  ;; contain 'lib/ao/plugins-4/libpulse.*'.
> -(inputs `(("pkg-config" ,pkg-config)
> -  ("alsa-lib" ,alsa-lib)
> -  ("pulseaudio" ,pulseaudio)))
> +(inputs
> + `(("alsa-lib" ,alsa-lib)
> +   ("pulseaudio" ,pulseaudio)))
> +(native-inputs
> + `(("pkg-config" ,pkg-config)))
>  (synopsis "Cross platform audio library")

OK for master because only 19 packages depend on ao.

> --- a/gnu/packages/xorg.scm
> +++ b/gnu/packages/xorg.scm
> @@ -2710,8 +2710,8 @@ framebuffer device.")
> "19y13xl7yfrgyis92rmxi0ld95ajgr5il0n9j1dridwzw9aizz1q"))
>  (patches (list (search-patch "xf86-video-geode-glibc-2.20.patch")
>  (build-system gnu-build-system)
> -(inputs `(("pkg-config" ,pkg-config)
> -  ("xorg-server" ,xorg-server)))
> +(inputs `(("xorg-server" ,xorg-server)))
> +(native-inputs `(("pkg-config" ,pkg-config)))
>  (supported-systems
>   ;; This driver is only supported on i686 systems.
>   (filter (lambda (system) (string-prefix? "i686-" system))

OK for master.

Thanks!

Ludo’.

Re: How to build a file which depends on the actual contents of store items?

[Ludovic Courtès]

宋文武  skribis:

> On 2015-11-20 22:12, l...@gnu.org wrote:
>> 宋文武  skribis:
>>
>> [...]
>>
>>> +  (define (module-path module)
>>> +(list "  ModulePath \"" module "/lib/xorg/modules\"\n"))
>>
>> [...]
>>
>>> +" (apply string-append (map module-path modules)) "
>>
>> As with NixOS, the solution is to move these computations to the “build
>> side” (info "(guix) G-Expressions").
>>
>> So you could do something like:
>>
>>   (define build
>> #~(call-with-output-file #$output
>> (lambda (port)
>>   (for-each emit-driver-stanza '#$@xorg-modules
>>
>>   (gexp->derivation "xorg.conf" build)
>>
>> Does that make sense?
> Oh, yes!  I get what I want by replace mixed-text-file with
> gexp->derivation.

You can also use ‘computed-file’, which is the non-monadic equivalent.

Ludo’.

[PATCH] gnu: Move pkg-config to native inputs.

[Mathieu Lirzin]

Hi,

Thanks to Ludo's work on Guix lint online.  I have made a patch but I
don't know if this is safe to push it on master so I prefer requesting
advices before.

TIA,

--
Mathieu Lirzin

>From 6a8f2286e307d5b77af3a546d5113c44bac13804 Mon Sep 17 00:00:00 2001
From: Mathieu Lirzin 
Date: Mon, 23 Nov 2015 10:44:53 +0100
Subject: [PATCH] gnu: Move pkg-config to native inputs.

* gnu/packages/glib.scm (gobject-introspection)[native-inputs]: Move
pkg-config from inputs.
* gnu/packages/pulseaudio.scm (libsndfile, libsamplerate)
(pulseaudio)[native-inputs]: Likewise.
* gnu/packages/xiph.scm (ao)[native-inputs]: Likewise.
* gnu/packages/xorg.scm (xf86-video-geode)[native-inputs]: Likewise.
---
 gnu/packages/glib.scm   |  4 ++--
 gnu/packages/pulseaudio.scm | 11 +++
 gnu/packages/xiph.scm   |  8 +---
 gnu/packages/xorg.scm   |  4 ++--
 4 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
index 146d3f5..c5eea22 100644
--- a/gnu/packages/glib.scm
+++ b/gnu/packages/glib.scm
@@ -251,10 +251,10 @@ dynamic loading, and an object system.")
("cairo" ,cairo)
("flex" ,flex)
("glib" ,glib)
-   ("pkg-config" ,pkg-config)
("python-2" ,python-2)))
 (native-inputs
- `(("glib" ,glib "bin")))
+ `(("glib" ,glib "bin")
+   ("pkg-config" ,pkg-config)))
 (propagated-inputs
  `(;; In practice, GIR users will need libffi when using
;; gobject-introspection.
diff --git a/gnu/packages/pulseaudio.scm b/gnu/packages/pulseaudio.scm
index d5e8aba..fe976a9 100644
--- a/gnu/packages/pulseaudio.scm
+++ b/gnu/packages/pulseaudio.scm
@@ -58,8 +58,9 @@
 (inputs
  `(("libvorbis" ,libvorbis)
("libogg" ,libogg)
-   ("flac" ,flac)
-   ("pkg-config" ,pkg-config)))
+   ("flac" ,flac)))
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
 (home-page "http://www.mega-nerd.com/libsndfile/";)
 (synopsis "Reading and writing files containing sampled sound")
 (description
@@ -87,7 +88,8 @@ for reading and writing new sound file formats.")
   (base32
"01hw5xjbjavh412y63brcslj5hi9wdgkjd3h9csx5rnm8vglpdck"
 (build-system gnu-build-system)
-(inputs `(("pkg-config" ,pkg-config)))
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
 (propagated-inputs
  `(("libsndfile" ,libsndfile)
("fftw" ,fftw)))
@@ -162,13 +164,14 @@ rates.")
("dbus" ,dbus)
("glib" ,glib)
("intltool" ,intltool)
-   ("pkg-config" ,pkg-config)
("m4" ,m4)
("libltdl" ,libltdl)
("fftwf" ,fftwf)
("avahi" ,avahi)
("eudev" ,eudev)   ;for the detection of hardware audio devices
("check" ,check)))
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
 (propagated-inputs
  ;; 'libpulse*.la' contain `-lgdbm' and `-lcap', so propagate them.
  `(("libcap" ,libcap)
diff --git a/gnu/packages/xiph.scm b/gnu/packages/xiph.scm
index 705ebe1..930fbfd 100644
--- a/gnu/packages/xiph.scm
+++ b/gnu/packages/xiph.scm
@@ -165,9 +165,11 @@ stereo encoding, and voice activity detection.")
 ;; XXX: Should back-ends be pushed to different outputs?  For instance,
 ;; "out" would include only the ALSA back-end, while "pulse" would
 ;; contain 'lib/ao/plugins-4/libpulse.*'.
-(inputs `(("pkg-config" ,pkg-config)
-  ("alsa-lib" ,alsa-lib)
-  ("pulseaudio" ,pulseaudio)))
+(inputs
+ `(("alsa-lib" ,alsa-lib)
+   ("pulseaudio" ,pulseaudio)))
+(native-inputs
+ `(("pkg-config" ,pkg-config)))
 (synopsis "Cross platform audio library")
 (description
  "Libao is a cross-platform audio library that allows programs to
diff --git a/gnu/packages/xorg.scm b/gnu/packages/xorg.scm
index 54c15dd..42422a3 100644
--- a/gnu/packages/xorg.scm
+++ b/gnu/packages/xorg.scm
@@ -2710,8 +2710,8 @@ framebuffer device.")
"19y13xl7yfrgyis92rmxi0ld95ajgr5il0n9j1dridwzw9aizz1q"))
 (patches (list (search-patch "xf86-video-geode-glibc-2.20.patch")
 (build-system gnu-build-system)
-(inputs `(("pkg-config" ,pkg-config)
-  ("xorg-server" ,xorg-server)))
+(inputs `(("xorg-server" ,xorg-server)))
+(native-inputs `(("pkg-config" ,pkg-config)))
 (supported-systems
  ;; This driver is only supported on i686 systems.
  (filter (lambda (system) (string-prefix? "i686-" system))
-- 
2.6.3

Re: How to build a file which depends on the actual contents of store items?

[宋文武]

On 2015-11-20 22:12, l...@gnu.org wrote:

宋文武  skribis:

[...]


+  (define (module-path module)
+(list "  ModulePath \"" module "/lib/xorg/modules\"\n"))


[...]


+" (apply string-append (map module-path modules)) "


As with NixOS, the solution is to move these computations to the “build
side” (info "(guix) G-Expressions").

So you could do something like:

  (define build
#~(call-with-output-file #$output
(lambda (port)
  (for-each emit-driver-stanza '#$@xorg-modules

  (gexp->derivation "xorg.conf" build)

Does that make sense?
Oh, yes!  I get what I want by replace mixed-text-file with 
gexp->derivation.


While the former is convient for concat strings and packages,
it doesn't have the '#:modules' argument, so I can't do:
  (mixed-text-file "xserver.conf"
#~(begin (use-modules (guix build utils)) ... (find-files ...



The big difference with Nix is that we use the same language on both
sides, so it’s easy to move things from one side to another, but it’s
also easy to forget about the tradeoffs.

OK, I'm more comfortable with gexp now, thanks!

Re: Lint on line

[Ludovic Courtès]

Leo Famulari  skribis:

> What is the recommended way to handle the following warning?
>
> "gnu/packages/firmware.scm:33:12: ath9k-htc-firmware-1.4.0: the source
> file name should contain the package name"

Like this:

diff --git a/gnu/packages/firmware.scm b/gnu/packages/firmware.scm
index 97f2975..271fb49 100644
--- a/gnu/packages/firmware.scm
+++ b/gnu/packages/firmware.scm
@@ -38,6 +38,7 @@
   (sha256
(base32
 "16jbj8avg5jkgvq5lxm0hdxxn4c3zn7fx8b4nxllvr024apk9w23"))
+  (file-name (string-append name "-" version "-checkout"))
   (patches (list (search-patch "ath9k-htc-firmware-objcopy.patch")
 (build-system gnu-build-system)
 (arguments

I’ll push this one.  ;-)

The goal of this rule is to make sure that checkouts are given
meaningful names.  This does not make any functional difference, but it
helps keep the store tidy.

Thanks,
Ludo’.

Re: Lint on line

[Mathieu Lirzin]

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

> Hello, Guix!
>
> Here’s a new tool!
>
>   https://www.gnu.org/software/guix/packages/issues.html

This is really useful for the scaling of the package maintenance.
Thanks!

--
Mathieu Lirzin

Re: How to use Guix.el from Git?

[Alex Kost]

Mathieu Lirzin (2015-11-23 00:15 +0300) wrote:

> Alex Kost  writes:
>
>> Mathieu Lirzin (2015-11-22 21:20 +0300) wrote:
>>
>>> When changing it with “/home/mthl” it works!  To avoid this kind of
>>> mistake in the future, a simple fix would be to change the example in
>>> the documentation, with:
>>>
>>>   (let ((dir "/absolute/path/to/your-guix-git-tree/emacs"))
>>> ...
>>>
>>> But is there a way to change the implementation to let users use
>>> relative path?
>>
>> Yes, the fix is easy.  The patch is attached, could you confirm that it
>> works?
>
> The patch works perfectly!

Pushed, thank you!

-- 
Alex

Re: Lint on line

[Alex Kost]

Leo Famulari (2015-11-23 03:22 +0300) wrote:

> What is the recommended way to handle the following warning?
>
> "gnu/packages/firmware.scm:33:12: ath9k-htc-firmware-1.4.0: the source
> file name should contain the package name"

It means that the source file name should be
"/gnu/store/…-ath9k-htc-firmware-1.4.0", while it is probably
"/gnu/store/…-git-checkout" or something.

To fix it, 'file-name' field should be added to the source origin.  Look
for example at 'minetest' or 'mars' package recipes.

-- 
Alex