gnu-patches back log

[Pjotr Prins]

Now we have debbugs we can see there is a building back-log:

  
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches;max-bugs=100;base-order=1;bug-rev=1

A patch like this one

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25725

has been two weeks without comment. I think we should not leave patches without
feedback longer than one week - even 3 days, to be honest. It is the surest way
to kill enthusiasm.

To move forward with Guix and to recognise the effort new submitters
put in I would like to ask *all* reviewers to pick an outstanding
patch on a regular basis. If reviewers split the work it should be doable.

Would it be an idea to send out weekly E-mails with patches that had
no attention to a select list of reviewers? Or maybe to the ML as a
whole? Basically it would read:

Summary

Status
31 Outstanding
18 Resolved
Severity
49 Normal bugs
Classification
22 Patch Available
9 Unclassified

Patches older than 1 week:

gnu: mumble: Build with 'murmur' server component.  Modified 13 days ago;
gnu: Add blists.Modified 13 days ago;
gnu: Add lush2. Modified 13 days ago;
etc.

Pj.

Re: [PATCH 3/3] gnu: Add jacal.

[John Darrington]

On Mon, Feb 27, 2017 at 07:31:11PM -0500, Leo Famulari wrote:
 
 > + (replace 'configure
 > +  (lambda* (#:key inputs outputs #:allow-other-keys)
 > +(zero? (system* "./configure"
 > +(string-append "--prefix="
 > +   (assoc-ref outputs 
"out")
 
 This can be done in #:configure-flags, right?

Normally it could be.  But in this case, the ./configure script is not a 
autoconf generated one
and does not accept many of the default options that gnu-build-system sends to 
it.

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: `guix pull` over HTTPS

[Leo Famulari]

On Sat, Feb 11, 2017 at 03:28:52PM +0100, Ludovic Courtès wrote:
> Marius Bakke  skribis:
> > I think having a separate 'le-certs' package that can verify the Lets
> > Encrypt chain sounds like the easiest option. Presumably new
> > intermediates etc will be known well in advance.
> 
> That sounds more reasonable to me.  Do you know what it would take to
> get the whole LE chain in such a package?  Would you like to give it a
> try?

I tried it. The next intermediate (also called the "backup") is already
known.

I've made it available here:

https://github.com/lfam/le-certs

You can try it out:

$ echo | openssl s_client -CAfile /tmp/le-certs/le-certs.pem -CApath 
/tmp/le-certs -connect git.savannah.gnu.org:443

Your feedback is requested!


signature.asc
Description: PGP signature

export variable CONFFLAGS

[rennes]

Hello,
I am trying to export the variable 'CONFFLAGS' for 'apr' package on 
GNU/Hurd as follows:


(arguments
 #:make-flags ("CONFFLAGS+=apr_cv_struct_ipmreq=no"
(string-append "PREFIX=" %output))


This way does not work!, the Debian project does it as follows:

ifeq (hurd,$(DEB_HOST_ARCH_OS))
  CONFFLAGS += apr_cv_struct_ipmreq=no
endif

This due to the Hurd does not support multicast yet.

Thanks

[PATCH 2/2] gnu: doxygen: Update to 1.8.13.

[Leo Famulari]

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

diff --git a/gnu/packages/documentation.scm b/gnu/packages/documentation.scm
index e0713c31c..cd42bc0f3 100644
--- a/gnu/packages/documentation.scm
+++ b/gnu/packages/documentation.scm
@@ -86,14 +86,14 @@ markup) can be customized and extended by the user.")
 (define-public doxygen
   (package
 (name "doxygen")
-(version "1.8.11")
+(version "1.8.13")
 (source (origin
  (method url-fetch)
  (uri (string-append "http://ftp.stack.nl/pub/users/dimitri/;
  name "-" version ".src.tar.gz"))
  (sha256
   (base32
-   "0ja02pm3fpfhc5dkry00kq8mn141cqvdqqpmms373ncbwi38pl35"))
+   "0srzawqn3apzrg8hwycwrawdylmmjrndij4spw6xr1vspn3phrmg"))
  (patches (search-patches "doxygen-test.patch"
 (build-system cmake-build-system)
 (native-inputs
-- 
2.11.1

[PATCH 0/2] Fix doxygen build failure caused by bugs in flex

[Leo Famulari]

Doxygen fails to build on core-updates, like this:

--
[ 26%] [FLEX][scanner] Building scanner with flex 2.6.2
cd /tmp/guix-build-doxygen-1.8.11.drv-0/doxygen-1.8.11/src && 
/gnu/store/m9mw6yjjg6z0qnqmkbswwdakkniphqkx-flex-2.6.2/bin/flex  -PscannerYY 
-o/tmp/guix-build-doxygen-1.8.11.drv-0/build/generated_src/scanner.cpp scanner.l
scanner.l:7106: EOF encountered inside an action
make[2]: *** [src/CMakeFiles/_doxygen.dir/build.make:230: 
generated_src/scanner.cpp] Error 1
make[2]: Leaving directory '/tmp/guix-build-doxygen-1.8.11.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:257: src/CMakeFiles/_doxygen.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
--

Because doxygen builds fine with flex 2.6.3, I think it's related to
bugs in flex, which are mentioned in the flex 2.6.3 release notes:

https://github.com/westes/flex/commit/581ef6d17f7fccc9c538c0f0bda9b89df66c2dc3#diff-ff4e2dc4962dc25a151235322c8dR8

Leo Famulari (2):
  gnu: flex: Update to 2.6.3.
  gnu: doxygen: Update to 1.8.13.

 gnu/packages/documentation.scm | 4 ++--
 gnu/packages/flex.scm  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.11.1

[PATCH 1/2] gnu: flex: Update to 2.6.3.

[Leo Famulari]

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

diff --git a/gnu/packages/flex.scm b/gnu/packages/flex.scm
index d9abbfa4e..2d31660f3 100644
--- a/gnu/packages/flex.scm
+++ b/gnu/packages/flex.scm
@@ -32,7 +32,7 @@
 (define-public flex
   (package
 (name "flex")
-(version "2.6.2")
+(version "2.6.3")
 (source (origin
   (method url-fetch)
   (uri (string-append
@@ -41,7 +41,7 @@
 "flex-" version ".tar.gz"))
   (sha256
(base32
-"1jdjghh1qjq3z7snphshcak6p07gch2n4215vjvrkism25x460cs"
+"1an2cn2z85mkpgqcinh1fhhcd7993qm2lil1yxic8iz76ci79ck8"
 (build-system gnu-build-system)
 (inputs
  (let ((bison-for-tests
-- 
2.11.1

Re: [PATCH 3/3] gnu: Add jacal.

[Leo Famulari]

On Sun, Feb 26, 2017 at 08:42:28PM +0100, John Darrington wrote:
> * gnu/packages/maths.scm (jacal): New variable.
> * gnu/packages/patches/jacal.texi.patch: New file.

Can you rename the patch jacal-texi.patch (for consistency with the
majority of the patches) and add a comment in the patch file explaining
what it does?

> + (replace 'configure
> +  (lambda* (#:key inputs outputs #:allow-other-keys)
> +(zero? (system* "./configure"
> +(string-append "--prefix="
> +   (assoc-ref outputs 
> "out")

This can be done in #:configure-flags, right?

Re: [PATCH 1/3] gnu: Add slib.

[Leo Famulari]

On Sun, Feb 26, 2017 at 08:42:26PM +0100, John Darrington wrote:
> * gnu/packages/scheme.scm (slib): New variable.
> +(define-public slib
> +  (package
> +(name "slib")
> +(version "3b5")
> +(source (origin
> + (method url-fetch)
> + (uri (string-append 
> "http://groups.csail.mit.edu/mac/ftpdir/scm/slib-; version ".zip"))

Line too looong :)

> +   #:phases
> +   (modify-phases %standard-phases
> + (add-after 'install 'remove-bin-share
> +(lambda* (#:key inputs outputs #:allow-other-keys)
> +  (zero? (system* "rm" "-r"

How about the the Scheme procedure delete-file-recursively from (guix
build utils)?

Re: Key 69096DFDD7028BEDACC5884BC5E051C79C0BECDB "Key has been compromised"

[Leo Famulari]

On Mon, Feb 27, 2017 at 06:25:42PM -0500, Leo Famulari wrote:
> In a message on February 3 you said, "Can I regenerate a pgp key? I
> think my keys where in the gnome keyring or something, backing up
> ~/.gnupg/secring.pgp didn't keep my keys :/" [0]

Also, I'm not sure which version of GnuPG you were using, but the 2.1
series does not use '$GNUPGHOME/secring.gpg'. It uses
'$GNUPGHOME/private-keys-v1.d' [0].

So, you could lose your private key if you updated from an earlier
series and then tried to migrate your installation by coping
secring.gpg.

[0]
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration.html#index-secring_002egpg-506
https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html#index-secret_002dkeyring-304

Key 69096DFDD7028BEDACC5884BC5E051C79C0BECDB "Key has been compromised"

[Leo Famulari]

Hi David,

While looking at the Guix commit log, I noticed that your PGP key
69096DFDD7028BEDACC5884BC5E051C79C0BECDB has been revoked with a reason
of "Key has been compromised".

In a message on February 3 you said, "Can I regenerate a pgp key? I
think my keys where in the gnome keyring or something, backing up
~/.gnupg/secring.pgp didn't keep my keys :/" [0]

Can you clarify whether the key was deleted inadvertently, or if you
think it was actually "compromised". To me, key compromise means you
believe that the private key could have been copied by a 3rd party.

Leo

[0]
http://lists.gnu.org/archive/html/guix-devel/2017-02/msg00104.html

Re: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey certificates.

[Leo Famulari]

On Tue, Feb 28, 2017 at 08:16:34AM +1100, Carlo Zancanaro wrote:
> On Mon, Feb 27 2017, Ricardo Wurmus wrote
> > Also note that icedtea-6 will eventually be removed (as it will no
> > longer receive upstream updates) and the other icedtea* packages should
> > no longer use inheritance to make that possible.
> 
> The 'install-keystore phase will have to be moved to icedtea-7, then,
> where the same code will be required. The phase will have to move at
> some point anyway, so I don't think this is particularly significant
> that it's currently in icedtea-6.

Off-topic, but I'd like for this to happen ASAP. Icedtea-6 is currently
unsupported and exploitable bugs continue to be discovered.


signature.asc
Description: PGP signature

core-updates frozen!

[Leo Famulari]

On Tue, Feb 14, 2017 at 10:05:04AM +0100, Ludovic Courtès wrote:
> So, here’s a plan:
> 
>   • Once Efraim has pushed some of the aarch64 patches, do another
> evaluation of the “core” package set for that branch, and check for
> anything wrong.  From there on, forbid full-rebuild changes.

Let's freeze core-updates and try to build it. No more rebuild the world
changes except to fix breakage.

>   • Once the “core” subset builds correctly on all the supported
> platforms (those that Hydra supports), merge ‘master’.  Maybe update
> a couple of things like GnuTLS while we’re at it.  From there on
> forbid non-trivial changes.
> 
>   • Build all the packages.  (To do that, someone with access to Hydra
> must change the “subset” argument to “all” in the config of the
> ‘core-updates’ jobset.)
> 
>   • Fix things.
> 
>   • Once most regressions have been addressed and most binaries are
> available, merge ‘core-updates’ into ‘master’.
> 
> How does that sound?
> 
> Thanks,
> Ludo’.
> 

Re: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey certificates.

[Carlo Zancanaro]

On Mon, Feb 27 2017, Ricardo Wurmus wrote
> Carlo Zancanaro  writes:
>> But then I wondered, could we just change the generate-keystore phase of
>> the icedtea-6 package to log a failed certificate import without failing
>> the build? Then we could move the permissions change there, too, which
>> would give us a smaller patch that should accomplish a similar result
>> (attached).
>
> Hmm, I have a slight preference to have the build fail in those cases,
> because that prompts us to fix the underlying problem.  Roel’s fix seems
> more direct, even though it results in more lines of code.

Sure, but then we get a situation like we currently have: the build
fails, so the keystore generation is disabled (rather than fixed) and we
have a Java package that is heavily crippled (especially for development
purposes).

If it failing actually lead to people fixing the issue then I would be
fine with that, but the issue I have is that it doesn't get fixed, it
gets disabled. I'd much rather have it work for most use cases, rather
than failing on the slightest hiccup.

My issue isn't that Roel's fix is more lines of code, it's that it is
more brittle, it hard codes package information, and it results in
unnecessary duplication of code.

>> @@ -719,6 +719,15 @@ build process and its dependencies, whereas Make uses 
>> Makefile format.")
>> "/lib/security"))
>> (mkdir-p (string-append (assoc-ref outputs "jdk")
>> "/jre/lib/security"))
>> +
>> +   ;; The cacerts files we are going to overwrite are chmod'ed 
>> as
>> +   ;; read-only (444) in icedtea-8 (which derives from this
>> +   ;; package).  We have to change this so we can overwrite 
>> them.
>> +   (chmod (string-append (assoc-ref outputs "out")
>> + "/lib/security/" keystore) #o644)
>> +   (chmod (string-append (assoc-ref outputs "jdk")
>> + "/jre/lib/security/" keystore) #o644)
>> +
>
> I don’t understand this.

What don't you understand about it? If the comment is unclear then I am
happy to clarify it further.

> It also seems inelegant to make a change in “icedtea-6” for the sake
> of “icedtea-8”. Could this be done in “icedtea-8” instead?

I agree that it's inelegant, but the alternative is to duplicate the
entire phase and make the changes in icedtea-8. Given we are using
inheritance for code re-use here, I don't think it's too bad to do
something that's always valid to fix a problem in a specific case.

> Also note that icedtea-6 will eventually be removed (as it will no
> longer receive upstream updates) and the other icedtea* packages should
> no longer use inheritance to make that possible.

The 'install-keystore phase will have to be moved to icedtea-7, then,
where the same code will be required. The phase will have to move at
some point anyway, so I don't think this is particularly significant
that it's currently in icedtea-6.

Carlo


signature.asc
Description: PGP signature

Re: core-updates: Fix cups-minimal build failure

[Leo Famulari]

On Mon, Feb 27, 2017 at 09:47:47AM +0100, Andy Wingo wrote:
> > Do you have any suggestions about how to make this more concise?

> (for-each
>  (lambda (section)
>(for-each
>  (lambda (file) (chmod file #o666))
>  (find-files (string-append out "/share/man/man" section)
>  "\\.gz")))
>  '("1" "5" "7" "8"))

*copy+paste*

> Would be nice if there were a recursive find-files; oh well.

It seems that find-files is recursive. At least, it worked as expected
in d043ceedbb3ce1873db97cfe2c8806de64881f01 (gnu: cups-minimal: Fix
build failure in reset-gzip-timestamps phase.).

Re: Git-style aliases in Guix?

[Mekeor Melire]

John Darrington  writes:

> On Mon, Feb 27, 2017 at 09:30:07AM +0100, Mekeor Melire wrote:
>
>  John Darrington  writes:
>
>  > On Sun, Feb 26, 2017 at 10:15:10PM +0100, Mekeor Melire wrote:
>  >
>  >  Concerning how to implement this alias feature within Guix, I'd 
> first
>  >  like to pose a much broader question. So, on GuixSD you have a
>  >  configuration, written in Scheme, for your operating system. 
> Couldn't we
>  >  make Guix have a scheme-configuration file for itself, as well?
>  >
>  > We do.  guix/config.scm
>
>  How can you configure Guix itself in your config.scm? I'm only aware of
>  the operating-system declaration which is used to configure the OS, not
>  Guix itself.
>
> What kind of configuration had you in mind?

So, `operating-system` let's you declare an operating system. What if
there was a Scheme function called `guix` or so which allowed you to
configure Guix itself?

Then, defining Guix aliases could look as follows; maybe saved in a file
called guix.scm:

  (guix
(aliases '(
  ("p" . "package")
  ("s" . "package -s")
  ("m" . "package -m"

And similar to `operating-system`, there would be many other
configuration fields...

Re: Git-style aliases in Guix?

[John Darrington]

On Mon, Feb 27, 2017 at 09:30:07AM +0100, Mekeor Melire wrote:
 
 John Darrington  writes:
 
 > On Sun, Feb 26, 2017 at 10:15:10PM +0100, Mekeor Melire wrote:
 >
 >  Concerning how to implement this alias feature within Guix, I'd 
first
 >  like to pose a much broader question. So, on GuixSD you have a
 >  configuration, written in Scheme, for your operating system. 
Couldn't we
 >  make Guix have a scheme-configuration file for itself, as well?
 >  
 > We do.  guix/config.scm
 
 How can you configure Guix itself in your config.scm? I'm only aware of
 the operating-system declaration which is used to configure the OS, not
 Guix itself.

What kind of configuration had you in mind?

-- 
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 0/5] gnu/packages/aux-files

[Ricardo Wurmus]

Alex Kost  writes:

>> IIUC Ludovic is AFK now, so I would like to push these patches in a week
>> or so, if there will be no comments.
>
> Since there were no comments, I applied this patchset to master.

I missed this patch set the first time around and only just went over
it.  It looks good to me.  Thanks!

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey certificates.

[Ricardo Wurmus]

Carlo Zancanaro  writes:

> But then I wondered, could we just change the generate-keystore phase of
> the icedtea-6 package to log a failed certificate import without failing
> the build? Then we could move the permissions change there, too, which
> would give us a smaller patch that should accomplish a similar result
> (attached).

Hmm, I have a slight preference to have the build fail in those cases,
because that prompts us to fix the underlying problem.  Roel’s fix seems
more direct, even though it results in more lines of code.

> From b1ed0d53a72f95fdc42fa3741ae16726782ad414 Mon Sep 17 00:00:00 2001
> From: Carlo Zancanaro 
> Date: Sun, 26 Feb 2017 11:34:44 +1100
> Subject: [PATCH] gnu: icedtea-6: Modify certificate import to not fail for
>  icedtea-8.
>
> * gnu/packages/java.scm (icedtea-6)[arguments]: Fix install-keystore phase to
>   not fail the build when attempting to import unsupported certificate
>   types (which occur with icedtea-8, which inherits from icedtea-6). Also
>   ensure that the keystore is able to be written to before copying it.
> ---
>  gnu/packages/java.scm | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm
> index e7479e1b0..c7f9b9aad 100644
> --- a/gnu/packages/java.scm
> +++ b/gnu/packages/java.scm
> @@ -706,7 +706,7 @@ build process and its dependencies, whereas Make uses 
> Makefile format.")
> "-file" temp)))
>   (display "yes\n" port)
>   (when (not (zero? (status:exit-val (close-pipe port
> -   (error "failed to import" cert)))
> +   (format #t "failed to import ~a\n" cert)))
> (delete-file temp)))
>
> ;; This is necessary because the certificate directory 
> contains
> @@ -719,6 +719,15 @@ build process and its dependencies, whereas Make uses 
> Makefile format.")
> "/lib/security"))
> (mkdir-p (string-append (assoc-ref outputs "jdk")
> "/jre/lib/security"))
> +
> +   ;; The cacerts files we are going to overwrite are chmod'ed as
> +   ;; read-only (444) in icedtea-8 (which derives from this
> +   ;; package).  We have to change this so we can overwrite them.
> +   (chmod (string-append (assoc-ref outputs "out")
> + "/lib/security/" keystore) #o644)
> +   (chmod (string-append (assoc-ref outputs "jdk")
> + "/jre/lib/security/" keystore) #o644)
> +

I don’t understand this.  It also seems inelegant to make a change in
“icedtea-6” for the sake of “icedtea-8”.  Could this be done in
“icedtea-8” instead?

Also note that icedtea-6 will eventually be removed (as it will no
longer receive upstream updates) and the other icedtea* packages should
no longer use inheritance to make that possible.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: [PATCH] gnu: icedtea-8: Build keystore without id-ecPublicKey certificates.

[Roel Janssen]

Carlo Zancanaro  writes:

> On Sun, Feb 26 2017, Roel Janssen wrote
>> Great idea.  This is also a more durable solution for when certificates
>> change in nss-certs.
>
> Yeah, that was my thinking. I had tried to do it earlier, but hadn't
> noticed the incorrect permissions later on in the build (which had
> caused my attempts to fail).
>
>> I think we should add ourselves to the copyright notice.
>> Other than that, I think this patch is good to be pushed.
>
> I've added both of us to the copyright notice (I hope that isn't too
> presumptuous). Patch is attached.

Great!

Unfortunately, I don't seem to be able to apply your patch.  It errors
with the following:

error: patch failed: gnu/packages/java.scm:1
error: gnu/packages/java.scm: patch does not apply

I tried with two different machines, both resulting in the error
displayed above.

Sorry for the inconvenience, but could you redo the patch?

Kind regards,
Roel Janssen

Re: [PATCH 0/5] gnu/packages/aux-files

[Alex Kost]

Alex Kost (2017-02-18 12:21 +0300) wrote:

> Hello, as discussed at
>
>   http://lists.gnu.org/archive/html/guix-devel/2016-12/msg01174.html
>
> this patchset moves linux-libre .conf files and "guix-emacs.el" (needed
> for Emacs) to "gnu/packages/aux-files", also it modifies "guix-emacs.el"
> a bit.  These patches shouldn't change anything in a user experience.
>
> The .conf files will be called like this:
>
>   gnu/packages/aux-files/linux-libre/4.9-i686.conf
>
> or is it better to name them like this:
>
>   gnu/packages/aux-files/linux-libre/linux-libre-4.9-i686.conf   or
>   gnu/packages/aux-files/linux-libre-4.9-i686.conf
>
> or something else?
>
> IIUC Ludovic is AFK now, so I would like to push these patches in a week
> or so, if there will be no comments.

Since there were no comments, I applied this patchset to master.

-- 
Alex

Re: [PATCH 1/2] build: union: Add create-all-directory? parameter to union-build

[Huang, Ying]

iyzs...@member.fsf.org (宋文武) writes:

> "Huang, Ying"  writes:
>
> Hi, sorry for my late reply.
>
>> Danny Milosavljevic  writes:
>>
>>> Hi,
>>>
>>> yeah, I've looked at it and I see what you are trying to do.
>>>
>>> You modified 'union to replicate the directory tree and symlink
>>> only the non-directory files - in order to be able to add
>>> "fonts.dir" in those directories.
>>>
>>> The previous version symlinked entire directories, too, and you
>>> wouldn't have been able to add those "fonts.dir" files inside them
>>> later.
>>>
>>> Your fix seems kinda hacky - but I don't really see a downside.
>>>
>>> Thinking about it some more I think it looks good enough to me. I'd
>>> like a second opinion, though.
>>>
>>> Other than that, the name of the new flag "create-all-directory?"
>>> is weird. I'd like it to be something like
>>> "create-all-directories?".
>
>>>
>>> (The non-hacky solution would be to make 'union aware that there are
>>> "fonts.dir" files to go in there, too. One could do that by adding
>>> these as an input, too. I'm not sure whether that would be worth the
>>> added complexity, though - especially since the fonts.dir generator
>>> needs to have the finished union as input and not just single
>>> directories one by one. Thoughts?)
>>
>> union will only be called with create-all-directory? != nil for packages
>> have share/fonts directories.  And for these packages, we plan to remove
>> the fonts.dir and fonts.scale files, so that we need to create all
>> directories for them after all.  Is this good enough?
>>
>
> Yes, I thought so and it will work, but maybe it's better (non-hacky
> way?) to make every font package install fonts.scale and fonts.dir files
> into its own directory...
>
> IIUC, to make them useful, we have to make the fonts directories
> available to the running X server through xserver.conf (FontPath) or
> adding them using 'xset +fp'.  And since either method is limited to a
> single directory, so if we avoid the collision by putting each font
> package under an unique path ($out/share/fonts/TYPE/FONT-NAME), then the
> font-dir profile hook is not needed at all.

In the other hand, we can add these paths into xorg.conf or `xset +fp`
via font-dir profile hook too.

> We can do this in the wanted (upcoming?) 'font-build-system'.

One question, how to deal with font packages which aren't built with
font-build-system?  For example, font-terminus uses gnu-build-system.

Best Regards,
Huang, Ying

Re: [PATCH] services: dovecot: Fix unix_listeners and fifo_listeners path types.

[Clément Lassieur]

>> Well, maybe here "lmtp" is not the section name, but the path, relative
>> to "base_dir".  Sould I update the documentation to specify that "path"
>> may be relative to "base_dir" too?
>
> Sure, anyway patch LGTM.  Thanks for taking the time to explain.

My pleasure!  Here is the new version, with updated documentation:
http://lists.gnu.org/archive/html/guix-devel/2017-02/msg01112.html

Clément

Re: [PATCH] gnu: libarchive: fix issue 696 in v.3.2.1

[Carlos Sánchez de La Lama]

Hi Leo,

just found this pending issue. My patch was merged into libarchive trunk
on 11th December, too late to make it into libarchive-3.2.2. It will be
public when 3.3.x series comes out (any time soon), so I guess it does
not make sense to fix on GUIX side anymore (would be better to update
librachive version).

BR

Carlos

Leo Famulari  writes:

> On Wed, Oct 19, 2016 at 01:02:43PM +0200, Carlos Sánchez de La Lama wrote:
>> Pull request #807 has been made upstream, this fixes Issue 696 on GUIX side
>> until a new it is fixed on a libarchive release.
>> 
>> * gnu/packages/patches/libarchive-issue-696.patch: New file.
>> * gnu/local.mk: Register patch.
>> * gnu/packages/backup.scm (libarchive): Add patch.
>> (libarchive/fixed): Inherit patches from libarchive.
>
> Thanks! Let's wait to see what the libarchive developers say before we
> apply it to our package.

Re: [PATCH] services: dovecot: Fix unix_listeners and fifo_listeners path types.

[Andy Wingo]

On Mon 27 Feb 2017 10:39, Clément Lassieur  writes:

> Clément Lassieur  writes:
>
>> Andy Wingo  writes:
>>
>>> On Sun 26 Feb 2017 20:42, Clément Lassieur  writes:
>>>
 * gnu/services/mail.scm (unix-listener-configuration)[path]
   (fifo-listener-configuration)[path]: Change type from 'file-name' to 
 'string'.
 * doc/guix.texi (Mail Services): Document it.
>>>
>>> Why's that?  Is the extra checking from the file-name type (that the
>>> string start with "/") getting in the way of something?
>>
>> Yes, because the path is also used as the section name (see
>> http://wiki2.dovecot.org/Services#Service_listeners).
>>
>> So for example, this code (from gnu/services/mail.scm:445) raises an
>> error because "lmtp" doesn't start with "/":
>>
>> (service-configuration
>>  (kind "lmtp")
>>  (listeners
>>   (list (unix-listener-configuration (path "lmtp") (mode "0666")
>>
>> I don't understand how it could work before.  Maybe the check wasn't
>> done.
>
> Well, maybe here "lmtp" is not the section name, but the path, relative
> to "base_dir".  Sould I update the documentation to specify that "path"
> may be relative to "base_dir" too?

Sure, anyway patch LGTM.  Thanks for taking the time to explain.

Andy

Re: PHP on core-updates

[julien lepiller]

Le 2017-02-26 21:46, Leo Famulari a écrit :

Hi Julien,

Libgd is updated to 2.2.4 on the core-updates branch.

Can you take a look and decide what to do with gd-for-php on that
branch?


I think php-for-gd would break with the new version (it would fail to 
apply the patches), so I'd like to get rid of it, and use our gd package 
instead.


I found an issue with gd that was discovered by php, reported to gd and 
fixed in their repo. I've extracted a patch from the gd repo and would 
like to add it to our package. I found a way to "fix" the newly failing 
tests and reported them upstream. I've attached two patches I'd like to 
see in core-updates. I haven't tested them yet, though, but comments 
would be highly appreciated ;)From 6ee0afac1c72c8e92dcd0384090ead62d5e0cf8a Mon Sep 17 00:00:00 2001
From: Julien Lepiller 
Date: Mon, 27 Feb 2017 11:09:11 +0100
Subject: [PATCH 1/2] gnu: gd: Fix an issue with XBM decoding.

* gnu/packages/patches/gd-php-73968-Fix-109-XBM-reading.patch: New file.
* gnu/local.scm (dist_patch_DATA): Add it.
* gnu/packages/gd.scm (gd)[source]: Use it.
---
 gnu/local.mk   |   1 +
 gnu/packages/gd.scm|   3 +-
 .../patches/gd-php-73968-Fix-109-XBM-reading.patch | 114 +
 3 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/gd-php-73968-Fix-109-XBM-reading.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 3d9ad70..271d2c4 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -582,6 +582,7 @@ dist_patch_DATA =		\
   %D%/packages/patches/gd-fix-tests-on-i686.patch		\
   %D%/packages/patches/gd-fix-truecolor-format-correction.patch	\
   %D%/packages/patches/gd-freetype-test-failure.patch		\
+  %D%/packages/patches/gd-php-73968-Fix-109-XBM-reading.patch		\
   %D%/packages/patches/gegl-CVE-2012-4433.patch			\
   %D%/packages/patches/geoclue-config.patch			\
   %D%/packages/patches/ghc-dont-pass-linker-flags-via-response-files.patch	\
diff --git a/gnu/packages/gd.scm b/gnu/packages/gd.scm
index 8cac242..664e653 100644
--- a/gnu/packages/gd.scm
+++ b/gnu/packages/gd.scm
@@ -52,7 +52,8 @@
"1rp4v7n1dq38b92kl7gkvpvqqkw7nvdfnz6d5kip5klkxfki6zqk"))
  (patches (search-patches "gd-fix-gd2-read-test.patch"
   "gd-fix-tests-on-i686.patch"
-  "gd-freetype-test-failure.patch"
+  "gd-freetype-test-failure.patch"
+  "gd-php-73968-Fix-109-XBM-reading.patch"
 (build-system gnu-build-system)
 (arguments
  `(#:phases
diff --git a/gnu/packages/patches/gd-php-73968-Fix-109-XBM-reading.patch b/gnu/packages/patches/gd-php-73968-Fix-109-XBM-reading.patch
new file mode 100644
index 000..bfaa4ff
--- /dev/null
+++ b/gnu/packages/patches/gd-php-73968-Fix-109-XBM-reading.patch
@@ -0,0 +1,114 @@
+From 082c5444838ea0d84f9fb6441aefdb44d78d9bba Mon Sep 17 00:00:00 2001
+From: "Christoph M. Becker" 
+Date: Fri, 20 Jan 2017 22:48:20 +0100
+Subject: [PATCH] Fix #109: XBM reading fails with printed error
+
+When calculating the number of required bytes of an XBM image, we have
+to take the line padding into account.
+
+This patch has been taken from the gd repository and binary files have been
+removed from the patch because our patch procedure doesn't support that format.
+---
+ src/gd_xbm.c |   2 +-
+ tests/xbm/CMakeLists.txt |   1 +
+ tests/xbm/Makemodule.am  |   5 -
+ tests/xbm/github_bug_109.c   |  35 +++
+ tests/xbm/github_bug_109.xbm |   5 +
+ 5 files changed, 47 insertions(+), 2 deletions(-)
+ create mode 100644 tests/xbm/github_bug_109.c
+ create mode 100644 tests/xbm/github_bug_109.xbm
+ create mode 100644 tests/xbm/github_bug_109_exp.png
+
+diff --git a/src/gd_xbm.c b/src/gd_xbm.c
+index 5f09b56..c2ba2ad 100644
+--- a/src/gd_xbm.c
 b/src/gd_xbm.c
+@@ -108,7 +108,7 @@ BGD_DECLARE(gdImagePtr) gdImageCreateFromXbm(FILE * fd)
+ max_bit = 32768;
+ 			}
+ 			if (max_bit) {
+-bytes = (width * height / 8) + 1;
++bytes = (width + 7) / 8 * height;
+ if (!bytes) {
+ 	return 0;
+ }
+diff --git a/tests/xbm/CMakeLists.txt b/tests/xbm/CMakeLists.txt
+index 183cf5e..08576e0 100644
+--- a/tests/xbm/CMakeLists.txt
 b/tests/xbm/CMakeLists.txt
+@@ -1,4 +1,5 @@
+ LIST(APPEND TESTS_FILES
++	github_bug_109
+ 	github_bug_170
+ )
+ 
+diff --git a/tests/xbm/Makemodule.am b/tests/xbm/Makemodule.am
+index ba1eabd..0f5beb6 100644
+--- a/tests/xbm/Makemodule.am
 b/tests/xbm/Makemodule.am
+@@ -1,5 +1,8 @@
+ libgd_test_programs += \
++	xbm/github_bug_109 \
+ 	xbm/github_bug_170
+ 
+ EXTRA_DIST += \
+-	xbm/CMakeLists.txt
++	xbm/CMakeLists.txt \
++	xbm/github_bug_109.xbm \
++	xbm/github_bug_109_exp.png
+diff --git a/tests/xbm/github_bug_109.c 

Re: [PATCH] services: dovecot: Fix unix_listeners and fifo_listeners path types.

[Clément Lassieur]

Clément Lassieur  writes:

> Andy Wingo  writes:
>
>> On Sun 26 Feb 2017 20:42, Clément Lassieur  writes:
>>
>>> * gnu/services/mail.scm (unix-listener-configuration)[path]
>>>   (fifo-listener-configuration)[path]: Change type from 'file-name' to 
>>> 'string'.
>>> * doc/guix.texi (Mail Services): Document it.
>>
>> Why's that?  Is the extra checking from the file-name type (that the
>> string start with "/") getting in the way of something?
>
> Yes, because the path is also used as the section name (see
> http://wiki2.dovecot.org/Services#Service_listeners).
>
> So for example, this code (from gnu/services/mail.scm:445) raises an
> error because "lmtp" doesn't start with "/":
>
> (service-configuration
>  (kind "lmtp")
>  (listeners
>   (list (unix-listener-configuration (path "lmtp") (mode "0666")
>
> I don't understand how it could work before.  Maybe the check wasn't
> done.

Well, maybe here "lmtp" is not the section name, but the path, relative
to "base_dir".  Sould I update the documentation to specify that "path"
may be relative to "base_dir" too?

But anyway there's still the bug, because relative paths don't start
with "/".

Re: [PATCH] services: dovecot: Fix unix_listeners and fifo_listeners path types.

[Clément Lassieur]

Andy Wingo  writes:

> On Sun 26 Feb 2017 20:42, Clément Lassieur  writes:
>
>> * gnu/services/mail.scm (unix-listener-configuration)[path]
>>   (fifo-listener-configuration)[path]: Change type from 'file-name' to 
>> 'string'.
>> * doc/guix.texi (Mail Services): Document it.
>
> Why's that?  Is the extra checking from the file-name type (that the
> string start with "/") getting in the way of something?

Yes, because the path is also used as the section name (see
http://wiki2.dovecot.org/Services#Service_listeners).

So for example, this code (from gnu/services/mail.scm:445) raises an
error because "lmtp" doesn't start with "/":

(service-configuration
 (kind "lmtp")
 (listeners
  (list (unix-listener-configuration (path "lmtp") (mode "0666")

I don't understand how it could work before.  Maybe the check wasn't
done.

Re: [PATCH] services: dovecot: Fix unix_listeners and fifo_listeners path types.

[Andy Wingo]

On Sun 26 Feb 2017 20:42, Clément Lassieur  writes:

> * gnu/services/mail.scm (unix-listener-configuration)[path]
>   (fifo-listener-configuration)[path]: Change type from 'file-name' to 
> 'string'.
> * doc/guix.texi (Mail Services): Document it.

Why's that?  Is the extra checking from the file-name type (that the
string start with "/") getting in the way of something?

Andy

Re: [PATCH 1/2] build: union: Add create-all-directory? parameter to union-build

[Danny Milosavljevic]

Hi Mark,

On Fri, 24 Feb 2017 17:13:53 -0500
Mark H Weaver  wrote:

> If the purpose here is to facilitate mutating anything in the store,

That's not what it does. It's used in the profile hook. 'union-build is 
basically just reused to avoid code duplication. See PATCH 2/2.

> then we cannot accept this.  

> If you want to add something to your profile, e.g. fonts.dir, then use
> profile hooks for that.  See %default-profile-hooks in
> guix/profiles.scm.  However, we already have a hook to build fonts.dir,
> so I'm not sure what's missing here.

Yeah, that is the profile hook that is modified.

The reason is that there are multiple font directories that can also be shared 
by different font packages.

Currently, the hook to build fonts.dir only does it for the "truetype" 
directory.

What the patch does is merge the font trees and then call mkfontdir for each of 
the output directories (via ftw).

The modification in 'union-build is because it handles a special case of there 
just being one input directory: then 'union-build would have symlinked the 
entire directory - which would make the output (!) immutable.

In the end 'fonts-dir-file returns a derivation that is an union of the inputs 
with those fonts.dir files added.

That said, I'm not sure whether the added complexity is worth it - but it would 
be safe and it doesn't mutate existing store items in-place. It just adds 
"fonts.dir"s to the profile for all subdirs of share/fonts . It's avoiding 
symlinks in order to be able to do that without modifying the inputs in-place.

Re: core-updates: Fix cups-minimal build failure

[Andy Wingo]

On Sun 26 Feb 2017 03:25, Leo Famulari  writes:

> Do you have any suggestions about how to make this more concise?

> + ;; Make the compressed manpages writable so that the
> + ;; reset-gzip-timestamps phase does not error out.
> + (add-before 'reset-gzip-timestamps 'make-manpages-writable
> +   (lambda* (#:key outputs #:allow-other-keys)
> + (let* ((out (assoc-ref outputs "out"))
> +(man1 (string-append out "/share/man/man1"))
> +(man5 (string-append out "/share/man/man5"))
> +(man7 (string-append out "/share/man/man7"))
> +(man8 (string-append out "/share/man/man8")))
> +   (for-each (lambda (file) (chmod file #o666))
> + (find-files man1 "\\.gz"))
> +   (for-each (lambda (file) (chmod file #o666))
> + (find-files man5 "\\.gz"))
> +   (for-each (lambda (file) (chmod file #o666))
> + (find-files man7 "\\.gz"))
> +   (for-each (lambda (file) (chmod file #o666))
> + (find-files man8 "\\.gz")

(for-each
 (lambda (section)
   (for-each
 (lambda (file) (chmod file #o666))
 (find-files (string-append out "/share/man/man" section)
 "\\.gz")))
 '("1" "5" "7" "8"))

Would be nice if there were a recursive find-files; oh well.

Andy

Re: Git-style aliases in Guix?

[Mekeor Melire]

John Darrington  writes:

> On Sun, Feb 26, 2017 at 10:15:10PM +0100, Mekeor Melire wrote:
>
>  Concerning how to implement this alias feature within Guix, I'd first
>  like to pose a much broader question. So, on GuixSD you have a
>  configuration, written in Scheme, for your operating system. Couldn't we
>  make Guix have a scheme-configuration file for itself, as well?
>  
> We do.  guix/config.scm

How can you configure Guix itself in your config.scm? I'm only aware of
the operating-system declaration which is used to configure the OS, not
Guix itself.