Re: Accessibility in Guix
Hi Julien, > I think in order to reach out to more people, accessiblity is an > important topic. I've talked with Irina during the Perl and Guile days, > and fixed orca (it didn't work because of failures when loading > pyatspi). That’s great! > In order to make our system accessible from the start, we obviously > need an accessible installer. With Irina and later with Jean-Phillipe > from Hypra, I collected a list of items we should have in the installer > for blind and visually impaired people: […] These are all good points and I’m glad you brought them up. Feel free to open issues in the bug tracker to coordinate the work. -- Ricardo
Re: Help needed fixing linux-libre-5.2 on aarch64
Hi Mark! Mark H Weaver writes: > The 'kernel-updates' includes a preliminary commit to update linux-libre > to version 5.2. Berlin has built it successfully on all supported > architectures except for aarch64, where it fails: > > https://ci.guix.gnu.org/build/1448778/details > > I would be grateful if someone with access to aarch64 hardware could > debug this and propose a fix. Until then, I'm reluctant to push this > update to 'master'. > > See below for the relevant excerpt from the build log. > > Thanks, >Mark > > > --8<---cut here---start->8--- > CC [M] arch/arm64/lib/xor-neon.o > In file included from > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:34:0, > from > /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33, > from ./arch/arm64/include/asm/neon-intrinsics.h:33, > from arch/arm64/lib/xor-neon.c:11: > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-intn.h:27:19: > error: conflicting types for 'int64_t' > typedef __int64_t int64_t; >^~~ > In file included from ./include/linux/list.h:5:0, > from ./include/linux/module.h:9, > from arch/arm64/lib/xor-neon.c:10: > ./include/linux/types.h:114:15: note: previous declaration of 'int64_t' was > here > typedef s64 int64_t; >^~~ > In file included from > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:37:0, > from > /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33, > from ./arch/arm64/include/asm/neon-intrinsics.h:33, > from arch/arm64/lib/xor-neon.c:11: > /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-uintn.h:27:20: > error: conflicting types for 'uint64_t' > typedef __uint64_t uint64_t; > ^~~~ > In file included from ./include/linux/list.h:5:0, > from ./include/linux/module.h:9, > from arch/arm64/lib/xor-neon.c:10: > ./include/linux/types.h:112:15: note: previous declaration of 'uint64_t' was > here > typedef u64 uint64_t; >^~~~ > make[1]: *** [scripts/Makefile.build:285: arch/arm64/lib/xor-neon.o] Error 1 > make: *** [Makefile:1071: arch/arm64/lib] Error 2 > --8<---cut here---end--->8--- I have access to some hardware at the moment so I thought I'd give this a shot and yeah, I can reproduce it! I have access to a softiron board (that's the same as what's on berlin.guixsd.org right?) running Ubuntu with guix installed on top. The strange thing is, the failure only happens with building using guix, I can build linux on the board from source just fine: ``` # From a local checkout of linux (not linux-libre) ~/linux ((v5.2))$ guix environment -C linux-libre ~/linux [env]$ make defconfig ~/linux [env]$ make -j8 # OK ``` Whereas with `guix build linux-libre` I can see the error. And it still happens if I keep the build around with `guix build -K linux-libre`: ``` /tmp/guix-build-linux-libre-5.2.drv-0/linux-5.2$ source ../environment-variables /tmp/guix-build-linux-libre-5.2.drv-0/linux-5.2$ make -j8 CALLscripts/atomic/check-atomics.sh CALLscripts/checksyscalls.sh CHK include/generated/compile.h ./scripts/mkcompile_h: line 47: hostname: command not found CC [M] arch/arm64/lib/xor-neon.o In file included from /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:34:0, from /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu /7.4.0/include/arm_neon.h:33, from ./arch/arm64/include/asm/neon-intrinsics.h:33, from arch/arm64/lib/xor-neon.c:11: /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-intn.h:27:19: error: conflicting types for 'int64_t' typedef __int64_t int64_t; ^~~ In file included from ./include/linux/list.h:5:0, from ./include/linux/module.h:9, from arch/arm64/lib/xor-neon.c:10: ./include/linux/types.h:114:15: note: previous declaration of 'int64_t' was here typedef s64 int64_t; ^~~ In file included from /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/stdint.h:37:0, from /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/lib/gcc/aarch64-unknown-linux-gnu /7.4.0/include/arm_neon.h:33, from ./arch/arm64/include/asm/neon-intrinsics.h:33, from arch/arm64/lib/xor-neon.c:11: /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/include/bits/stdint-uintn.h:27:20: error: conflicting type s for 'uint64_t' typedef __uint64_t uint64_t;
Re: Help needed fixing linux-libre-5.2 on aarch64
> And if I remove it then the error goes away! The build hasn't finished
> yet for me, but it's gone past the offending xor-neon.c file so we
> /should/ be good.
>
> I'm not really sure why though, do you know why this phase was required
> at the time? I haven't tested that linux-libre still builds on x86 with
> this phase removed yet, trying it now.
OK, I've now built kernels with the attached patch on the kernel-updates
branch for x86_64 and aarch64! I've also tested with
--system=armhf-linux on the softiron and --system=i868-linux on my x86
desktop, it all looks good!
>From db0cd6773c54d9a8f9dd332cb20abab770e29a51 Mon Sep 17 00:00:00 2001
From: Pierre Langlois
Date: Sun, 14 Jul 2019 12:47:06 +0100
Subject: [PATCH] gnu: linux-libre: Fix build on aarch64.
* gnu/packages/linux.scm (make-linux-libre)[arguments]: Remove
'work-around-gcc-7-include-path-issue phase.
---
gnu/packages/linux.scm | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 41991c9e45..d63755d791 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -35,6 +35,7 @@
;;; Copyright © 2019 Tim Gesthuizen
;;; Copyright © 2019 Maxim Cournoyer
;;; Copyright © 2019 Stefan Stefanović
+;;; Copyright © 2019 Pierre Langlois
;;;
;;; This file is part of GNU Guix.
;;;
@@ -355,11 +356,6 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
(substitute* (find-files "." "^Makefile(\\.include)?$")
(("/bin/pwd") "pwd"))
#t))
- (add-before 'configure 'work-around-gcc-7-include-path-issue
- (lambda _
- (unsetenv "C_INCLUDE_PATH")
- (unsetenv "CPLUS_INCLUDE_PATH")
- #t))
(replace 'configure
(lambda* (#:key inputs native-inputs target #:allow-other-keys)
;; Avoid introducing timestamps
--
2.22.0
Re: Help needed fixing linux-libre-5.2 on aarch64
On 2019-07-14 14:24, Pierre Langlois wrote: And if I remove it then the error goes away! The build hasn't finished yet for me, but it's gone past the offending xor-neon.c file so we /should/ be good. I'm not really sure why though, do you know why this phase was required at the time? I haven't tested that linux-libre still builds on x86 with this phase removed yet, trying it now. OK, I've now built kernels with the attached patch on the kernel-updates branch for x86_64 and aarch64! I've also tested with --system=armhf-linux on the softiron and --system=i868-linux on my x86 desktop, it all looks good! Nice work! -- Cheers Swedebugia
Re: 01/01: guix: node-build-system: Use guile-json instead of a custom parser.
Hi Julien, guix-comm...@gnu.org skribis: > commit 8eb0ba532ebbebef23180e666e0607ea735f9c1a > Author: Julien Lepiller > Date: Sun Jul 14 14:50:21 2019 +0200 > > guix: node-build-system: Use guile-json instead of a custom parser. > > * guix/build/json.scm: Remove file. > * Makefile.am: Remove it. > * guix/build/node-build-system.scm: Use (json parser) instead of (guix > build json). > * guix/build-system/node.scm: Idem. This commit log doesn’t spell out all the variables and entities that were modified. Please consider doing it next time, for clarity. > +++ b/guix/build-system/node.scm > @@ -18,7 +18,6 @@ > > (define-module (guix build-system node) >#:use-module (guix store) > - #:use-module (guix build json) >#:use-module (guix build union) >#:use-module (guix utils) >#:use-module (guix packages) > @@ -27,6 +26,7 @@ >#:use-module (guix build-system) >#:use-module (guix build-system gnu) >#:use-module (ice-9 match) > + #:use-module (json parser) >#:export (npm-meta-uri > %node-build-system-modules > node-build > @@ -40,8 +40,8 @@ registry." > (define %node-build-system-modules >;; Build-side modules imported by default. >`((guix build node-build-system) > -(guix build json) > (guix build union) > +(json parser) The effect of this change is to import the (json parser) from the host side into the build side. As a result, if I have installed Guile-JSON 1.2 and you have Guile-JSON 3.1, we’ll end up building different derivations (and one of them won’t build :-)). The solution here would be to do the equivalent of ‘with-extensions’ for gexps. However, given that that’s annoying to do without gexps, and given that the plan is to move build systems to gexps Real Soon, I’d be in favor of simply reverting this commit and using the custom JSON parser. We can add a TODO/FIXME explaining that we’ll replace it with Guile-JSON as soon as build systems are rewritten to use gexps. How does that sound? Apologies if I overlooked it in your initial patch submission! Thank you, Ludo’.
Re: Organizing packages
Hello!
Jesse Gibbons skribis:
> I noticed that a few files have only one package definition and are
> named for that package. I think these packages can be organized better.
> Might I suggest the following rules:
>
> 1. if a package is a library for a particular language $LANG (like
> Python, Perl, etc.) it goes in ${LANG}-xyz.scm. If it is a library built
> for a particular PURPOSE, it may go into LANG-PURPOSE.scm with those
> packages.
>
> 2. If the package defines a compiler or interpreter for a language
> $LANG, it may go into ${LANG}.scm
>
> 3. If the package is part of a large divisible project $PROJ like gcc or
> texlive, it may go into ${PROJ}.scm
>
> 4. If the package is maintained a part of a large desktop environment
> $DE like GNOME or KDE, it may be put in ${DE}.scm
>
> 5. When in doubt, the package must go into a file named after its
> $PURPOSE, ${PURPOSE}.scm. For example, if the package is a game (like
> supertuxracer), it goes into games.scm; if it is for undirected
> fun (like sl), it goes into toys.scm; if it is for audio
> control or audio production, it goes into audio.scm; if it is for
> drawing or producing graphics, it goes into graphics.scm; etc. Projects
> that can be described with multiple purposes (like fortune) may go into
> any of those files.
I had experience with Nixpkgs, which has a decision tree for where to
put packages:
https://nixos.org/nixpkgs/manual/#sec-hierarchy
In the end I didn’t find it to be helpful in any way: you’d always have
to open ‘top-level/all-packages’, a file that lists all the packages, to
find out where the package you’re looking for lives.
I believe ‘guix edit’ greatly solves that (along with Helm or similar
editor support for grepping.)
> I think this will make searching easier because not everything has an
> obvious name, and when I `guix search` for a purpose (like drawing) I
> often get unrelated results.
I don’t think the module hierarchy should be thought of as a tool for
users to search for packages.
So really, ‘guix search’ is the tool that should be improved. It’s been
discussed many times, and improving it turns out to be difficult without
resorting to external sources of information (e.g., list of command
names, popularity database, etc.)
What we can do is look at specific examples to see if there’s something
we can improve on the current scoring system (with the understanding
that sometimes the answer is that we cannot do any better.)
For example, ‘guix search drawing program’ shows Tux Paint as the first
result, which is good; but ‘guix search drawing’ and ‘guix search
drawing application’ are much less useful. In this particular example,
it’s not clear to me what can be done.
One suggestion that was made before and that might help here is to
increase the score of leaf packages (applications).
Food for thought!
Ludo’.
Re: Help needed fixing linux-libre-5.2 on aarch64
Pierre Langlois writes:
>> And if I remove it then the error goes away! The build hasn't finished
>> yet for me, but it's gone past the offending xor-neon.c file so we
>> /should/ be good.
>>
>> I'm not really sure why though, do you know why this phase was required
>> at the time? I haven't tested that linux-libre still builds on x86 with
>> this phase removed yet, trying it now.
>
> OK, I've now built kernels with the attached patch on the kernel-updates
> branch for x86_64 and aarch64! I've also tested with
> --system=armhf-linux on the softiron and --system=i868-linux on my x86
> desktop, it all looks good!
> * gnu/packages/linux.scm (make-linux-libre)[arguments]: Remove
> 'work-around-gcc-7-include-path-issue phase.
> ---
> gnu/packages/linux.scm | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
> index 41991c9e45..d63755d791 100644
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -35,6 +35,7 @@
> ;;; Copyright © 2019 Tim Gesthuizen
> ;;; Copyright © 2019 Maxim Cournoyer
> ;;; Copyright © 2019 Stefan Stefanović
> +;;; Copyright © 2019 Pierre Langlois
Whoops, I hadn't realized I had edited this file before, see attached
for a fixed patch.
>From 1f855451dfd4c3068eebcc09cacf79bb6df97cc8 Mon Sep 17 00:00:00 2001
From: Pierre Langlois
Date: Sun, 14 Jul 2019 12:47:06 +0100
Subject: [PATCH] gnu: linux-libre: Fix build on aarch64.
* gnu/packages/linux.scm (make-linux-libre)[arguments]: Remove
'work-around-gcc-7-include-path-issue phase.
---
gnu/packages/linux.scm | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index 41991c9e45..c1a5bbebc0 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -30,7 +30,7 @@
;;; Copyright © 2018 Pierre-Antoine Rouby
;;; Copyright © 2018 Brendan Tildesley
;;; Copyright © 2018 Manuel Graf
-;;; Copyright © 2018 Pierre Langlois
+;;; Copyright © 2018, 2019 Pierre Langlois
;;; Copyright © 2018 Vasile Dumitrascu
;;; Copyright © 2019 Tim Gesthuizen
;;; Copyright © 2019 Maxim Cournoyer
@@ -355,11 +355,6 @@ for ARCH and optionally VARIANT, or #f if there is no such configuration."
(substitute* (find-files "." "^Makefile(\\.include)?$")
(("/bin/pwd") "pwd"))
#t))
- (add-before 'configure 'work-around-gcc-7-include-path-issue
- (lambda _
- (unsetenv "C_INCLUDE_PATH")
- (unsetenv "CPLUS_INCLUDE_PATH")
- #t))
(replace 'configure
(lambda* (#:key inputs native-inputs target #:allow-other-keys)
;; Avoid introducing timestamps
--
2.22.0
Re: Website translation
Hi, "pelzflorian (Florian Pelz)" skribis: > 3) We could write our own PO file writer and MO file reader and use it > with either Christopher’s lego translation and sirgazil’s format > strings to use whatever format we want for developers and translators. Note that “lego translation” is what we should _not_ do because it gives translators fragments of sentences, which does not allow them to correctly translate text. As long as we use xgettext, we have to stick to a format-string-like approach like what sirgazil proposes. Writing a custom xgettext kind of tool wouldn’t help much because gettext is fundamentally text oriented: you give it a string and it returns a string. So I think the alternative is: • use gettext, and in that case stick to a format-string-like mechanism, or: • use a completely new tool that would be able to consume and produce sexps (trees). The latter doesn’t seem reasonable to me. :-) BTW, there might also be ideas to borrow from GNUN: https://www.gnu.org/software/gnun/ Thanks, Ludo’.
Re: Website translation
On Sun, Jul 14, 2019 at 04:12:41PM +0200, Ludovic Courtès wrote: > Note that “lego translation” is what we should _not_ do because it gives > translators fragments of sentences, which does not allow them to > correctly translate text. > Format strings are something we can try. If they are too fragmented for translators, we can still use a custom tool to convert them and their fragments to a single string which gets passed to gettext. Regards, Florian
Re: We should disable dmesg for unprivileged users by default
Hi, Alex Vong skribis: > I think we should set /proc/sys/kernel/dmesg_restrict to 1 by default to > prevent unprivileged users from reading the kernel ring buffer (since it > could expose sensitive information about the system). We could have a ‘dmesg-restrict’ service that would write to that file as part of system activation, and we’d add it to ‘%base-packages’. WDYT? That way, people could easily remove it from ‘%base-packages’ if they don’t want it. (I might do that on my laptop for instance. :-)) Thanks, Ludo’.
Re: rsa4096/0x090B11993D9AEBB5 2014-08-11 [SC] [expired: 2019-07-08]
Hi, Tobias Geerinckx-Rice skribis: > Your key on Savannah expired on the 8th, causing scary warnings for > end users. Could you update it? I’ve updated it (actually yesterday or the day before) so we should be fine now. It’d be great to have a tiny Guile program that does the right POST request to Savannah somehow. Otherwise I’ll have to update manually every so often and I’m bound to forget at one point. Thanks, Ludo’.
Re: Help needed fixing linux-libre-5.2 on aarch64
Hello, Pierre Langlois skribis: > OK, I've now built kernels with the attached patch on the kernel-updates > branch for x86_64 and aarch64! I've also tested with > --system=armhf-linux on the softiron and --system=i868-linux on my x86 > desktop, it all looks good! > > From db0cd6773c54d9a8f9dd332cb20abab770e29a51 Mon Sep 17 00:00:00 2001 > From: Pierre Langlois > Date: Sun, 14 Jul 2019 12:47:06 +0100 > Subject: [PATCH] gnu: linux-libre: Fix build on aarch64. > > * gnu/packages/linux.scm (make-linux-libre)[arguments]: Remove > 'work-around-gcc-7-include-path-issue phase. Any idea why this hack is no longer needed, and also why things behaved differently on AArch64? Thanks for working on this! Ludo’.
Re: 01/01: guix: node-build-system: Use guile-json instead of a custom parser.
Le Sun, 14 Jul 2019 15:40:43 +0200, Ludovic Courtès a écrit : > Hi Julien, > > guix-comm...@gnu.org skribis: > > > commit 8eb0ba532ebbebef23180e666e0607ea735f9c1a > > Author: Julien Lepiller > > Date: Sun Jul 14 14:50:21 2019 +0200 > > > > guix: node-build-system: Use guile-json instead of a custom > > parser. > > * guix/build/json.scm: Remove file. > > * Makefile.am: Remove it. > > * guix/build/node-build-system.scm: Use (json parser) instead > > of (guix build json). > > * guix/build-system/node.scm: Idem. > > This commit log doesn’t spell out all the variables and entities that > were modified. Please consider doing it next time, for clarity. > > > +++ b/guix/build-system/node.scm > > @@ -18,7 +18,6 @@ > > > > (define-module (guix build-system node) > >#:use-module (guix store) > > - #:use-module (guix build json) > >#:use-module (guix build union) > >#:use-module (guix utils) > >#:use-module (guix packages) > > @@ -27,6 +26,7 @@ > >#:use-module (guix build-system) > >#:use-module (guix build-system gnu) > >#:use-module (ice-9 match) > > + #:use-module (json parser) > >#:export (npm-meta-uri > > %node-build-system-modules > > node-build > > @@ -40,8 +40,8 @@ registry." > > (define %node-build-system-modules > >;; Build-side modules imported by default. > >`((guix build node-build-system) > > -(guix build json) > > (guix build union) > > +(json parser) > > The effect of this change is to import the (json parser) from the host > side into the build side. > > As a result, if I have installed Guile-JSON 1.2 and you have > Guile-JSON 3.1, we’ll end up building different derivations (and one > of them won’t build :-)). > > The solution here would be to do the equivalent of ‘with-extensions’ > for gexps. > > However, given that that’s annoying to do without gexps, and given > that the plan is to move build systems to gexps Real Soon, I’d be in > favor of simply reverting this commit and using the custom JSON > parser. We can add a TODO/FIXME explaining that we’ll replace it > with Guile-JSON as soon as build systems are rewritten to use gexps. > > How does that sound? > > Apologies if I overlooked it in your initial patch submission! > > Thank you, > Ludo’. OK, sorry for pushing this patch then... I've reverted it in a4bb18921099b2ec8c1699e08a73ca0fa78d0486. Thanks for the explanation!
Re: 01/01: guix: node-build-system: Use guile-json instead of a custom parser.
On 14. Jul 2019, at 20:19, Julien Lepiller wrote: > > Le Sun, 14 Jul 2019 15:40:43 +0200, > Ludovic Courtès a écrit : >> The effect of this change is to import the (json parser) from the host >> side into the build side. >> >> As a result, if I have installed Guile-JSON 1.2 and you have >> Guile-JSON 3.1, we’ll end up building different derivations (and one >> of them won’t build :-)). >> >> The solution here would be to do the equivalent of ‘with-extensions’ >> for gexps. >> >> However, given that that’s annoying to do without gexps, and given >> that the plan is to move build systems to gexps Real Soon, I’d be in >> favor of simply reverting this commit and using the custom JSON >> parser. We can add a TODO/FIXME explaining that we’ll replace it >> with Guile-JSON as soon as build systems are rewritten to use gexps. >> >> How does that sound? >> >> Apologies if I overlooked it in your initial patch submission! >> >> Thank you, >> Ludo’. > > OK, sorry for pushing this patch then... I've reverted it in > a4bb18921099b2ec8c1699e08a73ca0fa78d0486. Thanks for the explanation! It’s a bit my fault, for remarking on the fact that the cargo build system does use guile-json. I suppose that’s not worth fixing either at this point? Cheers Robert
Re: Help needed fixing linux-libre-5.2 on aarch64
Hi, Pierre Langlois wrote: > OK, I've now built kernels with the attached patch on the kernel-updates > branch for x86_64 and aarch64! I've also tested with > --system=armhf-linux on the softiron and --system=i868-linux on my x86 > desktop, it all looks good! Thank you Pierre, this is much appreciated. I went ahead and pushed the 5.2 update and your fix to 'master'. Ludovic Courtès wrote: > Any idea why this hack is no longer needed, and also why things behaved > differently on AArch64? I'm not sure. I added that workaround in the commit that enabled compilation of GCC plugins in our 'linux-libre' packages, and also enabled use of GCC-7 on all architectures, whereas previously GCC-7 was used only on x86_64 and i686. In general, that kind of workaround was often needed when compiling packages with GCC-7, because the C include path generated by 'set-paths' was somehow breaking some uses of "#include_next" in the C standard library, maybe because the path elements were in the wrong order. I don't remember the precise details. Here's the relevant commit, for the record: commit ce899af10901bf9ed06fe0528b8c4f628ebba4fd Author: Mark H Weaver Date: Mon Dec 31 22:33:33 2018 -0500 gnu: linux-libre: Build with GCC-7 on all systems. * gnu/packages/linux.scm (make-linux-libre)[native-inputs]: Include GCC-7 unconditionally. Previously it was included only on Intel systems. Add GMP, MPFR, and MPC. [arguments]: Add 'work-around-gcc-7-include-path-issue' phase. Anyway, thanks again Pierre! Mark
We reached 10.000 package
Hurrah! GNU Guix now provides 10,026 packages (updated July 12, 2019). Congratulations! And many thanks to everybody who contributed to this great project! -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: We reached 10.000 package
On Sun, 14 Jul 2019 23:21:37 +0200 Hartmut Goebel wrote: > Hurrah! > > GNU Guix now provides 10,026 packages (updated July 12, 2019). > > Congratulations! > > And many thanks to everybody who contributed to this great project! > This is big news for Guix. Very much worth a small slice of banana bread in celebration. Yet there is still a lot to do. How many of these packages work as intended? Some of them have an error when guix builds them, some of them immediately crash, and some of them take so long to build that it is impractical to try to install them with guix. If you show me a list of packages that don't build correctly or immediately crash on startup, I will work on fixing them. I have no doubt some volunteers are willing to do the same. If I had access to a good server I would be willing to work on packages that take more than a day to build like guile-emacs.
Fixing evolution-data-server on core-updates
Hi all,
While testing core-updates I found that evolution-data-server does not
build due to test failures. The tests fail because
evolution-data-server does not accommodate newer versions of ICU.
Here’s the upstream bug report [1]. I’ve attached a patch that uses
“substitute*” to work around the problem (it’s rather simple). I think
we should wait to hear from upstream, and if they don’t get to it in a
few days, use the patch.
[1] https://gitlab.gnome.org/GNOME/evolution-data-server/issues/137
-- Tim
>From bcd753f777687c52bba6b9bf4184879e69990118 Mon Sep 17 00:00:00 2001
From: Timothy Sample
Date: Sun, 14 Jul 2019 23:47:44 -0400
Subject: [PATCH] gnu: evolution-data-server: Fix locale issue.
* gnu/packages/gnome.scm (evolution-data-server)[arguments]: Add a phase
that patches the source code to fix a locale issue.
---
gnu/packages/gnome.scm | 15 +++
1 file changed, 15 insertions(+)
diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index eb251498e9..a34adc4006 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -5168,6 +5168,21 @@ Exchange, Last.fm, IMAP/SMTP, Jabber, SIP and Kerberos.")
"tests/libedata-cal/test-cal-cache-utils.c")
(("/bin/rm") (which "rm")))
#t))
+ ;; This phase fixes locale canonicalization and prevents a few test
+ ;; failures. The bug has been reported upstream:
+ ;; .
+ (add-after 'unpack 'patch-locale-canonicalization
+ (lambda _
+ (substitute* "src/libedataserver/e-collator.c"
+ (("len = uloc_canonicalize \\(posix_locale,.*" x)
+((lambda (xs) (string-join xs "\n" 'suffix))
+ (list
+ "if (g_ascii_strcasecmp(posix_locale, \"C\") == 0 ||"
+ "g_ascii_strcasecmp(posix_locale, \"POSIX\") == 0) {"
+ " posix_locale = \"en_US_POSIX\";"
+ "}"
+ x
+ #t))
(add-before 'configure 'dont-override-rpath
(lambda _
(substitute* "CMakeLists.txt"
--
2.22.0
