Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
I think perhaps that we should be more selective in the certs we add to ca-certificates.crt. Debian has a configuration file /etc/ca-certificates.conf, and only adds certificates that are explicitly listed there to ca-certificates.crt. Several of the certs in /etc/ssl/certs have comments like this: # alias="Bogus Global Trustee" # trust= # distrust=CKA_TRUST_CODE_SIGNING CKA_TRUST_EMAIL_PROTECTION CKA_TRUST_SERVER_AUTH # openssl-distrust=codeSigning emailProtection serverAuth So it seems that the NSS certificate store may include known-bogus certificates, perhaps to allow displaying a more severe security warning than the common case of an unknown CA (e.g. self-signed certificates). We should find out whether these Bogus untrusted CA certificates are present in Debian's /etc/ssl/certs, and whether they are present in its ca-certificates.conf. We should also determine whether OpenSSL and GnuTLS pay attention to those "distrust" comments (see above) in the single-file certificate bundle, and whether they pay attention to them in the smaller *.pem and hash-named files. I will investigate later today, but if anyone is inspired to investigate sooner and report their findings, feel free. It could be that 993300f6c and/or e979e6dd523 should be reverted. Mark
Re: [PATCH 3/8] gnu: Add djvulibre.
Mark H Weaver skribis: > Paul van der Walt writes: > >> * gnu/packages/pdf.scm (djvulibre): New variable. >> --- >> gnu/packages/pdf.scm | 20 >> 1 file changed, 20 insertions(+) > > The package looks good, but I'm not sure it belongs in pdf.scm. Maybe > the answer is to rename pdf.scm to something more general, perhaps > documents.scm? Or maybe this belongs somewhere else. Thoughts? > > I'd like to hear some opinions on this before okaying the push. Maybe just djvu.scm? Other than that LGTM. Thanks, Ludo’.
Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
On Tue, Mar 03, 2015 at 03:27:57AM -0500, Mark H Weaver wrote: > I think perhaps that we should be more selective in the certs we add to > ca-certificates.crt. Debian has a configuration file > /etc/ca-certificates.conf, and only adds certificates that are > explicitly listed there to ca-certificates.crt. Actually I wondered about the question during the recent Comodo scandal: Should we remove the Comodo CA certificates from our store? If we decide to remove certificates, this should not only be done in the aggregation phase into one file. They should be removed at the end of the nss-certs build, so that also the single certificate files will disappear. What is left over can be collected into one file as is done now. Thanks for looking into this! Andreas
Re: [PATCH 3/3] gnu: Add ghc.
Federico Beffa skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>>> +(substitute* (list "testsuite/timeout/Makefile"
>>> + "testsuite/timeout/timeout.py"
>>> + "testsuite/timeout/timeout.hs"
>>> + "testsuite/tests/rename/prog006/Setup.lhs"
>>> + "testsuite/tests/programs/life_space_leak/life.test")
>>> + (("/bin/sh") (which "sh"))
>>> + (("/bin/rm") "rm"))
>>
>> Perhaps (find-files "testsuite" ".*") would be enough?
>
> Somehow find-files appears to have problems with a file. This happens
> even if I install the en_US.UTF-8 locale:
[...]
>?: 1 [regexp-exec # "hello\x00 world\n" 0 0]
> In ice-9/boot-9.scm:
> 106: 0 [# args)> misc-error ...]
>
> ice-9/boot-9.scm:106:20: In procedure # ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: string contains #\nul character: "hello\x00 world\n"
Right, that’s because ‘regexp-exec’ uses libc’s regexp functions, for
which the nul character marks the end of the string.
This file presumably cannot be patched with ‘substitute*’. Is it a problem?
>> This phase installs bootstrap binaries to $out/bin and adds them to
>> $PATH, right? Wouldn’t it be enough to install them to $TMPDIR/bin and
>> add that to $PATH?
>
> That is what is happening :-).
OK, sorry for the confusion.
>>> +(lambda* (#:key inputs outputs #:allow-other-keys)
>>> + (let* ((binaries
>>> + (list
>>> + "./utils/ghc-pwd/dist-install/build/tmp/ghc-pwd"
>>> + "./utils/hpc/dist-install/build/tmp/hpc"
>>> + "./utils/haddock/dist/build/tmp/haddock"
>>> + "./utils/hsc2hs/dist-install/build/tmp/hsc2hs"
>>> + "./utils/runghc/dist-install/build/tmp/runghc"
>>> + "./utils/ghc-cabal/dist-install/build/tmp/ghc-cabal"
>>> + "./utils/hp2ps/dist/build/tmp/hp2ps"
>>> + "./utils/ghc-pkg/dist-install/build/tmp/ghc-pkg"
>>> + "./utils/unlit/dist/build/tmp/unlit"
>>> + "./ghc/stage2/build/tmp/ghc-stage2"))
>>
>> Could we just list base names and do
>>
>> (append-map (lambda (program)
>> (find-files "." (string-append "^" program "$")))
>> '("ghc-pwd" "hpc" ...))
>
> Here I'm puzzled. If I test the command that you suggest by displaying
> the generated list (during the phase execution), I see that it produces
> the same list as the original one (at least as displayed on screen).
>
> In spite of this, differently than with the explicit list, the phase
> fails because somehow the listed files do not get patched by
>
> (for-each
>(cut system* "patchelf" "--set-interpreter" ld-so <>)
>binaries)
>
> Unless you understand what's happening, I would propose for now to
> keep the explicit lists.
Weird, but OK then.
Thanks,
Ludo’.
Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
Mark H Weaver skribis: > I think perhaps that we should be more selective in the certs we add to > ca-certificates.crt. Debian has a configuration file > /etc/ca-certificates.conf, and only adds certificates that are > explicitly listed there to ca-certificates.crt. Based on what you write, I agree we should be more selective, but I’m not sure how we can do that. So far the approach has been to trust Mozilla’s bundle, which is apparently not such a great idea. But what can we trust here? > Several of the certs in /etc/ssl/certs have comments like this: > > # alias="Bogus Global Trustee" > # trust= > # distrust=CKA_TRUST_CODE_SIGNING CKA_TRUST_EMAIL_PROTECTION > CKA_TRUST_SERVER_AUTH > # openssl-distrust=codeSigning emailProtection serverAuth > > So it seems that the NSS certificate store may include known-bogus > certificates, perhaps to allow displaying a more severe security warning > than the common case of an unknown CA (e.g. self-signed certificates). > > We should find out whether these Bogus untrusted CA certificates are > present in Debian's /etc/ssl/certs, and whether they are present in its > ca-certificates.conf. We should also determine whether OpenSSL and > GnuTLS pay attention to those "distrust" comments (see above) in the > single-file certificate bundle, and whether they pay attention to them > in the smaller *.pem and hash-named files. Yes. If not, we may have to look for ‘distrust’ lines in our own code and get rid of such certificates. > I will investigate later today, but if anyone is inspired to investigate > sooner and report their findings, feel free. It could be that 993300f6c > and/or e979e6dd523 should be reverted. That seems orthogonal to me. What we could do is to change ‘x509-certificates’ to default to an empty bundle, if NSS is deemed untrustworthy. Ludo’.
Re: [PATCH 3/8] gnu: Add djvulibre.
On 2015-03-03 at 13:19, quoth Ludovic Courtès: > Mark H Weaver skribis: > >> Paul van der Walt writes: >> >>> * gnu/packages/pdf.scm (djvulibre): New variable. >>> --- >>> gnu/packages/pdf.scm | 20 >>> 1 file changed, 20 insertions(+) >> >> The package looks good, but I'm not sure it belongs in pdf.scm. Maybe >> the answer is to rename pdf.scm to something more general, perhaps >> documents.scm? Or maybe this belongs somewhere else. Thoughts? >> >> I'd like to hear some opinions on this before okaying the push. > > Maybe just djvu.scm? Yeah why not. If nobody objects i'll do that. > Other than that LGTM. Thanks. p.
Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver skribis: >> >>> In order to support multiple packages containing CA certs, it would be >>> good to handle creation of the single-file cert bundle in the profile >>> generation code, analogous to our handling of info "dir" files. This >>> would allow us to create additional cert packages (e.g. one for >>> CAcert.org). >>> >>> I think it belongs in the profile generation code for the benefit of >>> users running Guix packages on top of another distro, where they might >>> not have root access. They can simply set GIT_SSL_CAINFO and >>> SSL_CERT_FILE to ~/.guix-profile/etc/ssl/ca-certificates.crt >>> >>> What do you think? >> >> It’s a good but as of yet unimplemented idea. >> >> Although I now realize we could perhaps simple move the >> ‘certificate-bundle’ procedure to (guix profile), add the certificate >> package to the system profile, and make /etc/ssl a symlink to >> /run/current-system/profile/etc/ssl. > > I've attached patches that implement this. They assume that 993300f and > e979e6d are first reverted. Comments and suggestions welcome. Both look good to me. > It would also be good to add search-path-specifications for > SSL_CERT_FILE to 'openssl' and GIT_SSL_CAINFO to 'git' in core-updates, > but I'm not sure how best to do that. Would you be willing to do it, > Ludovic? I just checked the source and OpenSSL itself does not use SSL_CERT_FILE nor SSL_CERT_DIR at all. Lynx does use SSL_CERT_FILE, but that’s really in Lynx, not in libssl. So I don’t think there should be a search path specification for OpenSSL. This is unfortunate, but it looks like we can’t do much. We could add that variable to Lynx itself, but it’s not actually a search path but just a file name. Thoughts? > +# These variables are honored by OpenSSL (libssl) and Git. Replace “OpenSSL (libssl)” by “some applications such as Lynx”. Thanks, Ludo’.
Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
On Tue, Mar 03, 2015 at 01:43:38PM +0100, Ludovic Courtès wrote:
> I just checked the source and OpenSSL itself does not use SSL_CERT_FILE
> nor SSL_CERT_DIR at all. Lynx does use SSL_CERT_FILE, but that’s really
> in Lynx, not in libssl. So I don’t think there should be a search path
> specification for OpenSSL. This is unfortunate, but it looks like we
> can’t do much.
I just did a "strings" and "grep" on the binaries and libs. SSL_CERT_DIR
appears in bin/c_rehash and lib/libcrypto.so, and SSL_CERT_FILE also appears
in the latter.
In the source code,
$ find -type f -exec grep -H SSL_CERT_DIR {} \;
yields:
./crypto/cryptlib.h:# define X509_CERT_DIR_EVP"SSL_CERT_DIR"
./tools/c_rehash.in:} elsif($ENV{SSL_CERT_DIR}) {
./tools/c_rehash.in:@dirlist = split /$path_delim/, $ENV{SSL_CERT_DIR};
./tools/c_rehash:} elsif($ENV{SSL_CERT_DIR}) {
./tools/c_rehash: @dirlist = split /$path_delim/, $ENV{SSL_CERT_DIR};
./doc/apps/c_rehash.pod:processed in turn. If not, then the B
environment variable
./doc/apps/c_rehash.pod:=item B
and
$ find -type f -exec grep -H SSL_CERT_FILE {} \;
privat@debian:/tmp/openssl-1.0.2$ find -type f -exec grep -H SSL_CERT_FILE {} \;
./crypto/cryptlib.h:# define X509_CERT_FILE_EVP "SSL_CERT_FILE"
So I think it is used and our search path is fine.
By the way, in the next core-updates round, we may wish to erase the empty
directories ssl/certs and ssl/private.
Andreas
Re: [PATCH] gnu: Add audacity.
l...@gnu.org (Ludovic Courtès) writes:
>> - It tries to find libid3tag and libmad via pkg-config even though they
>> don't install .pc files. Perhaps we can generate them manually in the
>> install phase of those packages, or maybe they just don't get
>> installed due to a bug. Perhaps they just need 'pkg-config' as an
>> input? I might try that next.
>
> That would be surprising. Perhaps the Audacity developers were using a
> distro that adds .pc files for these two libs?
Apparently Debian indeed adds .pc files. I added patches to them to do
the same.
>> - Audacity apparently uses PortAudio version 19, but the in-tree one has
>> a function which the upstream one doesn't. It would be strange if
>> they had an API change without changing the version, so no idea what's
>> going on there.
>
> Could you try to find out what the story of this function is? It would
> be best to avoid using the bundled PortAudio.
Apparently it's from a patch that has been waiting forever to be merged
into PortAudio and it's questionable whether it ever will. I applied it
to our PortAudio package.
>> - Dynamic loading of FFmpeg fails and I couldn't figure out why (it
>> didn't print any errors when I ran Audacity and normally it's pretty
>> verbose) so I just passed --disable-dynamic-loading and it was fine.
>
> OK.
By the way this came out to be a known problem among Audacity folks.
>> - The test suite fails due to some missing portaudio.h file. I didn't
>> come far trying to figure out why this happens so I just disabled the
>> test suite.
>
> Perhaps that problem would magically vanish when using system’s
> PortAudio because headers would be in $CPATH.
Indeed. Sadly the test suite seems to have other issues, and I've been
told it isn't "well exercised" so I disabled it for now. (FWIW it also
fails in the upcoming Audacity 2.1.0 which is now entering RC2 phase and
will be released soon.)
> The rest of the patch looks good to me; just the PortAudio issue needs
> to be resolved.
Updated patches below.
Note also it's in audacity.scm now and not audio.scm, because it depends
on ffmpeg, which is in video.scm, which now imports audio.scm, so
audio.scm cannot import video.scm.
We might want to just wait for 2.1.0 to be released by the way, since it
should be out in a couple days. The FFmpeg dynamic loading and test
suite issues aren't resolved, so the only difference will be the
version; feel free to review this patch as if it were for 2.1.0.
>From 3853b807f69fbd4b0cfe8116cc0d934c941df6aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
Date: Sun, 1 Mar 2015 21:52:23 +0100
Subject: [PATCH 1/3] gnu: mp3: Add .pc files to libmad and libid3tag.
* gnu/packages/mp3.scm (libmad, libid3tag): Add .pc files to installations.
* gnu/packages/patches/libid3tag-add-pc-file.patch: New file.
* gnu/packages/patches/libmad-add-pc-file.patch: New file.
* gnu-system.am (dist_patch_DATA): Add them.
---
gnu-system.am| 2 ++
gnu/packages/mp3.scm | 25 +---
gnu/packages/patches/libid3tag-add-pc-file.patch | 16 +++
gnu/packages/patches/libmad-add-pc-file.patch| 16 +++
4 files changed, 56 insertions(+), 3 deletions(-)
create mode 100644 gnu/packages/patches/libid3tag-add-pc-file.patch
create mode 100644 gnu/packages/patches/libmad-add-pc-file.patch
diff --git a/gnu-system.am b/gnu-system.am
index da19b9b..7e9d06a 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -450,6 +450,8 @@ dist_patch_DATA = \
gnu/packages/patches/libcanberra-sound-theme-freedesktop.patch \
gnu/packages/patches/libevent-dns-tests.patch \
gnu/packages/patches/liboop-mips64-deplibs-fix.patch \
+ gnu/packages/patches/libid3tag-add-pc-file.patch \
+ gnu/packages/patches/libmad-add-pc-file.patch \
gnu/packages/patches/libmad-mips-newgcc.patch \
gnu/packages/patches/librep-rules.mk.patch \
gnu/packages/patches/libtheora-config-guess.patch \
diff --git a/gnu/packages/mp3.scm b/gnu/packages/mp3.scm
index 55ab4b4..229edc5 100644
--- a/gnu/packages/mp3.scm
+++ b/gnu/packages/mp3.scm
@@ -50,7 +50,8 @@
(sha256
(base32
"14460zhacxhswnzb36qfpd1f2wbk10qvksvm6wyq5hpvdgnw7ymv"))
-(patches (list (search-patch "libmad-mips-newgcc.patch")
+(patches (list (search-patch "libmad-mips-newgcc.patch")
+ (search-patch "libmad-add-pc-file.patch")
(build-system gnu-build-system)
(arguments
`(#:phases
@@ -59,7 +60,14 @@
(lambda _
;; remove option that is not supported by gcc any more
(substitute* "configure" ((" -fforce-mem") "")))
- %standard-phases)))
+(alist-cons-after
+ 'install 'install-pc-file
+ (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+
Re: Some macros to make package definitions prettier
l...@gnu.org (Ludovic Courtès) writes: > I’ve applied it locally and will push shortly. It might be too late, but I have a nitpick on my macro: the implicit quoting of phase names 1. makes it impossible to provide them dynamically (e.g. procedure argument), 2. might give an illusion that they're sort of compile-time constants (like the 'delete', 'add-before', etc. tokens are). I guess it's fine since they are literal symbols in pretty much all cases (or really all cases) so far, but it bothered me so I wanted to share; it might be best to avoid such implicit-quoting in the future. Another nitpick would be that standards-compliant syntax-rules won't match the 'delete', 'replace', etc. literal tokens if they have a different binding during use than during definition of the macro. (The identifier is matched by symbol name (i.e. "unhygienically") only if it's unbound during both definition and use.) But I think this is really a problem in the Scheme standard, because this kind of macro is probably ubiquitous in Scheme code "in the wild." (And psyntax usually does it the way we expect.) Regarding the automatic conversion, I'll look into your recommendation, and also ponder on a hand-baked solution in Guile or Elisp, but I wonder if it will be possible to cover all edge-cases, especially comments. On the upside, we can auto-verify the results (sans comments and code formatting) by comparing package objects for equality before and after the transformation, since a use of 'modify-phases' should have the exact same result as the direct alist mangling... Taylan
Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> I think perhaps that we should be more selective in the certs we add to
>> ca-certificates.crt. Debian has a configuration file
>> /etc/ca-certificates.conf, and only adds certificates that are
>> explicitly listed there to ca-certificates.crt.
>
> Based on what you write, I agree we should be more selective, but I’m
> not sure how we can do that.
>
> So far the approach has been to trust Mozilla’s bundle, which is
> apparently not such a great idea. But what can we trust here?
The problem was not Mozilla's certificate bundle, it's how we were using
it. We initially assumed that it would only contain trusted
certificates, but this is not the case. They annotate the certificates
with trust metadata that we need to pay attention to.
Debian's ca-certificates package uses a variant of 'certdata2pem.py'
that only outputs trusted certificates. The variant of that script that
we're using from Fedora outputs untrusted certificates as well, but
Fedora then takes care to install only the trusted ones.
The trust information is more than just a simple boolean. There are
many distinct "trust types" that can be assigned, e.g. server-auth,
code-signing, email-protection, etc.
Fedora's system for handling CA certificates seems to be vastly more
sophisticated than Debian's. All of the single-file bundles are
considered "legacy", and Fedora is able to produce multiple bundles
containing certs trusted for different purposes.
Doing this job properly will require more research, but it seems to me
that we should be looking to Fedora for guidance:
http://pkgs.fedoraproject.org/cgit/ca-certificates.git
http://pkgs.fedoraproject.org/cgit/openssl.git
http://pkgs.fedoraproject.org/cgit/gnutls.git
Andreas Enge writes:
> If we decide to remove certificates, this should not only be done in the
> aggregation phase into one file. They should be removed at the end of the
> nss-certs build, so that also the single certificate files will disappear.
> What is left over can be collected into one file as is done now.
Agreed. For now, I've pushed my recently proposed commits (to support
certificate stores in profiles) along with changes to our 'nss-certs'
package to only install certificates that are annotated with a non-empty
"openssl-trust=" comment by our 'certdata2pem.py' (from Fedora).
> On Tue, Mar 03, 2015 at 01:43:38PM +0100, Ludovic Courtès wrote:
>> I just checked the source and OpenSSL itself does not use SSL_CERT_FILE
>> nor SSL_CERT_DIR at all. Lynx does use SSL_CERT_FILE, but that’s really
>> in Lynx, not in libssl. So I don’t think there should be a search path
>> specification for OpenSSL. This is unfortunate, but it looks like we
>> can’t do much.
>
> I just did a "strings" and "grep" on the binaries and libs. SSL_CERT_DIR
> appears in bin/c_rehash and lib/libcrypto.so, and SSL_CERT_FILE also appears
> in the latter.
>
> In the source code,
> $ find -type f -exec grep -H SSL_CERT_DIR {} \;
> yields:
>
> ./crypto/cryptlib.h:# define X509_CERT_DIR_EVP"SSL_CERT_DIR"
[...]
> ./crypto/cryptlib.h:# define X509_CERT_FILE_EVP "SSL_CERT_FILE"
Right. I've forgotten the details, but about a year ago I looked
through the maze of OpenSSL code and determined that at least in some
cases, OpenSSL would honor those variables. I guess the application can
specify whether or not to load the system trust store.
Mark
Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
Mark H Weaver skribis: > Fedora's system for handling CA certificates seems to be vastly more > sophisticated than Debian's. All of the single-file bundles are > considered "legacy", and Fedora is able to produce multiple bundles > containing certs trusted for different purposes. > > Doing this job properly will require more research, but it seems to me > that we should be looking to Fedora for guidance: > > http://pkgs.fedoraproject.org/cgit/ca-certificates.git > http://pkgs.fedoraproject.org/cgit/openssl.git > http://pkgs.fedoraproject.org/cgit/gnutls.git Indeed, this looks like a useful source of inspiration. > Andreas Enge writes: >> If we decide to remove certificates, this should not only be done in the >> aggregation phase into one file. They should be removed at the end of the >> nss-certs build, so that also the single certificate files will disappear. >> What is left over can be collected into one file as is done now. > > Agreed. For now, I've pushed my recently proposed commits (to support > certificate stores in profiles) along with changes to our 'nss-certs' > package to only install certificates that are annotated with a non-empty > "openssl-trust=" comment by our 'certdata2pem.py' (from Fedora). Good. BTW, since the ‘x509-certificates’ is now gone, I think we should add ‘nss-certs’ to ‘%base-packages’ to get that works-out-of-the-box property. WDYT? Thanks, Ludo’.
Re: [PATCHES] profiles: Produce a single-file CA certificate bundle
Andreas Enge skribis:
> privat@debian:/tmp/openssl-1.0.2$ find -type f -exec grep -H SSL_CERT_FILE {}
> \;
> ./crypto/cryptlib.h:# define X509_CERT_FILE_EVP "SSL_CERT_FILE"
Indeed, I stand corrected.
And Lynx does fiddle with it, but only when built with GnuTLS:
#ifdef USE_GNUTLS_INCL
if ((certfile = LYGetEnv("SSL_CERT_FILE")) != NULL) {
> So I think it is used and our search path is fine.
There’s still the problem that none of these is a search path, though it
works OK for the recommendation that’s printed when installing in a
profile.
So I’ve pushed this as commit da69977 in ‘core-updates’, but we’ll have
to extend ‘search-path-specification’ to describe things like that that
are not search paths.
Thanks,
Ludo’.
Re: [PATCH] gnu: Add audacity.
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>>> - It tries to find libid3tag and libmad via pkg-config even though they
>>> don't install .pc files. Perhaps we can generate them manually in the
>>> install phase of those packages, or maybe they just don't get
>>> installed due to a bug. Perhaps they just need 'pkg-config' as an
>>> input? I might try that next.
>>
>> That would be surprising. Perhaps the Audacity developers were using a
>> distro that adds .pc files for these two libs?
>
> Apparently Debian indeed adds .pc files. I added patches to them to do
> the same.
Sorry for not being clear: I think we should avoid diverging from
upstream in this way, especially if there’s just one package that makes
the incorrect assumption. So I would rather not add those .pc files.
If Audacity uses Autoconf and pkg.m4, I guess you could just pass
PKG_CONFIG=true as a configure flag, or {LIBID3TAG,LIBMAD}_{CFLAGS,LIBS}
and it will just work.
>>> - Audacity apparently uses PortAudio version 19, but the in-tree one has
>>> a function which the upstream one doesn't. It would be strange if
>>> they had an API change without changing the version, so no idea what's
>>> going on there.
>>
>> Could you try to find out what the story of this function is? It would
>> be best to avoid using the bundled PortAudio.
>
> Apparently it's from a patch that has been waiting forever to be merged
> into PortAudio and it's questionable whether it ever will. I applied it
> to our PortAudio package.
OK.
(I’d normally recommend relying on upstream but in this case, if the
choice is between not having Audacity and adding this patch, I think the
latter makes more sense.)
>>> - The test suite fails due to some missing portaudio.h file. I didn't
>>> come far trying to figure out why this happens so I just disabled the
>>> test suite.
>>
>> Perhaps that problem would magically vanish when using system’s
>> PortAudio because headers would be in $CPATH.
>
> Indeed. Sadly the test suite seems to have other issues, and I've been
> told it isn't "well exercised" so I disabled it for now. (FWIW it also
> fails in the upcoming Audacity 2.1.0 which is now entering RC2 phase and
> will be released soon.)
OK.
>> The rest of the patch looks good to me; just the PortAudio issue needs
>> to be resolved.
>
> Updated patches below.
>
> Note also it's in audacity.scm now and not audio.scm, because it depends
> on ffmpeg, which is in video.scm, which now imports audio.scm, so
> audio.scm cannot import video.scm.
It actually can, but it’s fine (and safer) the way you propose. :-)
> We might want to just wait for 2.1.0 to be released by the way, since it
> should be out in a couple days. The FFmpeg dynamic loading and test
> suite issues aren't resolved, so the only difference will be the
> version; feel free to review this patch as if it were for 2.1.0.
Your call!
> From 3853b807f69fbd4b0cfe8116cc0d934c941df6aa Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>
> Date: Sun, 1 Mar 2015 21:52:23 +0100
> Subject: [PATCH 1/3] gnu: mp3: Add .pc files to libmad and libid3tag.
>
> * gnu/packages/mp3.scm (libmad, libid3tag): Add .pc files to installations.
> * gnu/packages/patches/libid3tag-add-pc-file.patch: New file.
> * gnu/packages/patches/libmad-add-pc-file.patch: New file.
> * gnu-system.am (dist_patch_DATA): Add them.
Rather no.
> From fe095e3aebcaaa9e88587610832db3f65f7ec015 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>
> Date: Mon, 2 Mar 2015 01:06:35 +0100
> Subject: [PATCH 2/3] gnu: portaudio: Patch for Audacity compatibility.
>
> * gnu/packages/audio.scm (portaudio): Add a patch for Audacity compatibility.
> * gnu/packages/patches/portaudio-audacity-compat.patch: New file.
> * gnu-system.am (dist_patch_DATA): Add it.
[...]
> +++ b/gnu/packages/patches/portaudio-audacity-compat.patch
> @@ -0,0 +1,322 @@
> +Description: Add features needed to make portmixer work with audacity.
> +Author: Audacity Team
> +Last-Update: 2011-12-07
Could you add a link to PortAudio’s bug tracker or list?
Other than that OK.
> From b14e4eb8e276a2dd98c189c1edd18b7cc57dcb52 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
>
> Date: Fri, 20 Feb 2015 21:52:21 +0100
> Subject: [PATCH 3/3] gnu: Add audacity.
>
> * gnu/packages/audacity.scm: New file.
> * gnu-system.am (GNU_SYSTEM_MODULES): Add it.
> * gnu/packages/patches/audacity-fix-ffmpeg-binding.patch: New file.
> * gnu-system.am (dist_patch_DATA): Add it.
LGTM!
Apologies for the extra work.
Thank you!
Ludo’.
Re: Some macros to make package definitions prettier
taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> I’ve applied it locally and will push shortly. > > It might be too late, but I have a nitpick on my macro: the implicit > quoting of phase names 1. makes it impossible to provide them > dynamically (e.g. procedure argument), 2. might give an illusion that > they're sort of compile-time constants (like the 'delete', 'add-before', > etc. tokens are). > > I guess it's fine since they are literal symbols in pretty much all > cases (or really all cases) so far, but it bothered me so I wanted to > share; it might be best to avoid such implicit-quoting in the future. I actually agree. Well, next round? > Another nitpick would be that standards-compliant syntax-rules won't > match the 'delete', 'replace', etc. literal tokens if they have a > different binding during use than during definition of the macro. (The > identifier is matched by symbol name (i.e. "unhygienically") only if > it's unbound during both definition and use.) But I think this is > really a problem in the Scheme standard, because this kind of macro is > probably ubiquitous in Scheme code "in the wild." (And psyntax usually > does it the way we expect.) In think Guile 2.1 is standards-compliant in that respect though. A related problem will be the ‘_’ procedure of (guix ui) that will need to be renamed (which is annoying at worst, but OK.) ‘delete’ might be more of a problem. > Regarding the automatic conversion, I'll look into your recommendation, > and also ponder on a hand-baked solution in Guile or Elisp, but I wonder > if it will be possible to cover all edge-cases, especially comments. On > the upside, we can auto-verify the results (sans comments and code > formatting) by comparing package objects for equality before and after > the transformation, since a use of 'modify-phases' should have the exact > same result as the direct alist mangling... Yes, but the package object contains quoted code, so we can’t directly compare them for equality in this case. That said, any problems would be easily spotted I guess. Thanks, Ludo’.
Bash completions
Hello!
I’m considering applying this so that Bash completions would work
out-of-the-box. Apparently handling of completions is not fully
standardized; this approach is based on the suggestions of the
‘bash-completion’ package on one hand the the Bash manual on the other.
Thoughts?
Thanks,
Ludo’.
diff --git a/gnu/system.scm b/gnu/system.scm
index 5a3842f..45d1424 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -355,6 +355,8 @@ explicitly appear in OS."
e2fsprogs kbd
+ bash-completion
+
;; The packages below are also in %FINAL-INPUTS, so take them from
;; there to avoid duplication.
(map canonical-package
@@ -461,6 +463,23 @@ export GIT_SSL_CAINFO=\"$SSL_CERT_FILE\"
# Allow Aspell to find dictionaries installed in the user profile.
export ASPELL_CONF=\"dict-dir $HOME/.guix-profile/lib/aspell\"
"))
+
+ (bashrc(text-file "bashrc" "\
+# Bash-specific initialization.
+
+# The 'bash-completion' package.
+if [ -f /run/current-system/profile/etc/profile.d/bash_completion.sh ]
+then
+ source /run/current-system/profile/etc/profile.d/bash_completion.sh
+fi
+
+# Automatic completion loading from the user profile
+# (info \"(bash) Programmable Completion\").
+_completion_loader()
+ {
+ . \"$HOME/.guix-profile/etc/bash_completion.d/$1.sh\" >/dev/null 2>&1 && return 124
+ }
+complete -D -F _completion_loader -o bashdefault -o default\n"))
(skel (skeleton-directory skeletons)))
(file-union "etc"
`(("services" ,#~(string-append #$net-base "/etc/services"))
@@ -474,6 +493,7 @@ export ASPELL_CONF=\"dict-dir $HOME/.guix-profile/lib/aspell\"
("skel" ,#~#$skel)
("shells" ,#~#$shells)
("profile" ,#~#$profile)
+ ("bashrc" ,#~#$bashrc)
("hosts" ,#~#$hosts-file)
("localtime" ,#~(string-append #$tzdata "/share/zoneinfo/"
#$timezone))
Re: [PATCH] gnu: Add audacity.
l...@gnu.org (Ludovic Courtès) writes:
> Sorry for not being clear: I think we should avoid diverging from
> upstream in this way, especially if there’s just one package that makes
> the incorrect assumption. So I would rather not add those .pc files.
All clear. (No worries; it was my idea to copy Debian's patches.)
> If Audacity uses Autoconf and pkg.m4, I guess you could just pass
> PKG_CONFIG=true as a configure flag, or {LIBID3TAG,LIBMAD}_{CFLAGS,LIBS}
> and it will just work.
The latter option seems to work. (I suppose the former was meant to be
"PKG_CONFIG=false"? That seems to break the whole library search.)
Updated patch is attached; please tell me if the style is correct.
>> Note also it's in audacity.scm now and not audio.scm, because it depends
>> on ffmpeg, which is in video.scm, which now imports audio.scm, so
>> audio.scm cannot import video.scm.
>
> It actually can, but it’s fine (and safer) the way you propose. :-)
Does Guile support circular imports? (video.scm imports audio.scm on
the meanwhile, in case I wasn't clear about that, so I think we'll have
to avoid importing video.scm from audio.scm.)
>> +++ b/gnu/packages/patches/portaudio-audacity-compat.patch
>> @@ -0,0 +1,322 @@
>> +Description: Add features needed to make portmixer work with audacity.
>> +Author: Audacity Team
>> +Last-Update: 2011-12-07
>
> Could you add a link to PortAudio’s bug tracker or list?
Added a link to
in the patch header.
Updated patches:
>From 9d3ae472c1c31400753bfe89ef5d612ba6998cab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?=
Date: Mon, 2 Mar 2015 01:06:35 +0100
Subject: [PATCH 1/2] gnu: portaudio: Patch for Audacity compatibility.
* gnu/packages/audio.scm (portaudio): Add a patch for Audacity compatibility.
* gnu/packages/patches/portaudio-audacity-compat.patch: New file.
* gnu-system.am (dist_patch_DATA): Add it.
---
gnu-system.am | 1 +
gnu/packages/audio.scm | 19 +-
.../patches/portaudio-audacity-compat.patch| 324 +
3 files changed, 341 insertions(+), 3 deletions(-)
create mode 100644 gnu/packages/patches/portaudio-audacity-compat.patch
diff --git a/gnu-system.am b/gnu-system.am
index 0497fe1..33f3ae1 100644
--- a/gnu-system.am
+++ b/gnu-system.am
@@ -494,6 +494,7 @@ dist_patch_DATA = \
gnu/packages/patches/pingus-sdl-libs-config.patch \
gnu/packages/patches/plotutils-libpng-jmpbuf.patch \
gnu/packages/patches/polkit-drop-test.patch \
+ gnu/packages/patches/portaudio-audacity-compat.patch \
gnu/packages/patches/procps-make-3.82.patch \
gnu/packages/patches/pulseaudio-CVE-2014-3970.patch \
gnu/packages/patches/pulseaudio-fix-mult-test.patch \
diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index 5a23618..bda173e 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -1005,15 +1005,28 @@ portions of LAME.")
(string-map (lambda (c) (if (char=? c #\.) #\_ c)) version)
".tgz"))
(sha256
-(base32 "0mwddk4qzybaf85wqfhxqlf0c5im9il8z03rd4n127k8y2jj9q4g"
+(base32 "0mwddk4qzybaf85wqfhxqlf0c5im9il8z03rd4n127k8y2jj9q4g"))
+ (patches (list (search-patch "portaudio-audacity-compat.patch")
(build-system gnu-build-system)
(inputs
;; TODO: Add ASIHPI.
`(("alsa-lib" ,alsa-lib)
("jack" ,jack-2)))
(native-inputs
- `(("pkg-config" ,pkg-config)))
-(arguments '(#:tests? #f)) ;no 'check' target
+ `(("autoconf" ,autoconf)
+ ("automake" ,automake)
+ ("libtool" ,libtool)
+ ("pkg-config" ,pkg-config)))
+(arguments
+ '(#:phases
+ ;; Autoreconf is necessary because the audacity-compat patch modifies
+ ;; .in files.
+ (alist-cons-after
+'unpack 'autoreconf
+(lambda _
+ (zero? (system* "autoreconf" "-vif")))
+%standard-phases)
+ #:tests? #f));no 'check' target
(home-page "http://www.portaudio.com/";)
(synopsis "Audio I/O library")
(description
diff --git a/gnu/packages/patches/portaudio-audacity-compat.patch b/gnu/packages/patches/portaudio-audacity-compat.patch
new file mode 100644
index 000..9f239ad
--- /dev/null
+++ b/gnu/packages/patches/portaudio-audacity-compat.patch
@@ -0,0 +1,324 @@
+Description: Add features needed to make portmixer work with audacity.
+Author: Audacity Team
+Last-Update: 2011-12-07
+
+See .
+
+--- a/include/pa_win_ds.h
b/include/pa_win_ds.h
+@@ -89,6 +89,21 @@
+
+ }PaWinDirectSoundStreamInfo;
+
++/** Retrieve the GUID of the input device.
++
++ @param stream The stream to query.
++
++ @return A pointer to the GUID, or NULL if none.
++*/
++LPGUID PaWinDS_GetStreamInputGUID( PaStream* s );
++
++/** Retrieve the
Re: Some macros to make package definitions prettier
l...@gnu.org (Ludovic Courtès) writes: > I actually agree. Well, next round? If you want. :-) I thought it might be too much to have a second commit that touches all recipes where 'modify-phases' is used, but maybe I'm being too pedantic. > In think Guile 2.1 is standards-compliant in that respect though. A > related problem will be the ‘_’ procedure of (guix ui) that will need > to be renamed (which is annoying at worst, but OK.) ‘delete’ might be > more of a problem. Hm, if Guile 2.1 intends to have a fully hygienic syntax-rules by default, I would expect it to offer a way to enable the alternative behavior for a given syntax-rules usage, because AFAIK it's quite common (if not more common) that unhygienic matching is desired. Otherwise, we could just use slightly different identifiers: phase-delete, phase-replace, phase-add-before, phase-add-after. > Yes, but the package object contains quoted code, so we can’t directly > compare them for equality in this case. Ah, I didn't think of that. Taylan
Re: [PATCH 2/2] gnu: Add AlsaModularSynth.
Mark H Weaver writes: >> From dbf194fdfd5baf9b79ebc7ba3c60835421cce12a Mon Sep 17 00:00:00 2001 >> From: Ricardo Wurmus >> Date: Sun, 1 Mar 2015 13:35:06 +0100 >> Subject: [PATCH 1/2] gnu: Add clalsadrv. >> >> * gnu/packages/audio.scm (clalsadrv): New variable. >> --- >> gnu/packages/audio.scm | 43 +++ >> 1 file changed, 43 insertions(+) >> [...] >> +(alist-cons-after >> + 'install >> + 'install-symlink >> + (lambda _ >> + (symlink "libclalsadrv.so" >> +(string-append (assoc-ref %outputs "out") >> + "/lib/libclalsadrv.so.2"))) > > On Hydra, this 'symlink' call is failing on both x86_64 and mips64el. > See: > > http://hydra.gnu.org/build/263381/log/tail-reload > http://hydra.gnu.org/build/263382/log/tail-reload > > Can you look into it? The problem here is that the library is not installed to /lib, but to /lib64 or /libmips64. I'll see if I can coerce it to install the library to /lib on all platforms. ~~ Ricardo
Re: [PATCH 2/2] gnu: Add AlsaModularSynth.
Ricardo Wurmus writes: > The problem here is that the library is not installed to /lib, but to > /lib64 or /libmips64. I'll see if I can coerce it to install the > library to /lib on all platforms. zita-alsa-pcmi has the very same problem. I'll take care of both of them. ~~ Ricardo
