Re: 04/48: gnu: ruby-redcarpet: Update to 3.4.0.

Hi, m...@tobias.gr (Tobias Geerinckx-Rice) writes: > nckx pushed a commit to branch master > in repository guix. > > commit 5ca48923f5d852df4a22fc989f13432f44621798 > Author: Tobias Geerinckx-Rice > Date: Thu Aug 10 23:13:33 2017 +0200 > > gnu: ruby-redcarpet: Update to

Re: Guix locales on native distro's

Hi Pjotr, Pjotr Prins skribis: > All should be well. But when I read or write an E-mail using mutt or > vim (both linked correctly) I don't get to see UTF8. I don't get > non-ASCII output (Ludo's surname, for example). Can your xterm display UTF-8-encoded text at

‘core-updates’ is back!

Hello Guix! Yup, I just created a new ‘core-updates’ branch by pushing . Enjoy! Let’s freeze in one month, say Oct. 1st? Ludo’.

Re: [go-build-system] How to access properties or keys of a package on the build side?

Ricardo Wurmus writes: > You could also access the arguments of another package with > “package-arguments”. Using the “properties” field isn’t pretty because > it is a free form alist. > > You can use “find-tail” to jump to the keyword in “arguments” and then > pick the

Re: [go-build-system] How to access properties or keys of a package on the build side?

Leo Famulari writes: > So, a Go build system needs to somehow create a symlink union of the > dependency graph, making the dependencies available at the correct paths > relative to the root of the build environment. AFAICT, we can't figure > these paths out programatically;

[go-build-system] How to access properties or keys of a package on the build side?

Recently I made some progress on finishing the prototype go-build-system from Petter [0], and I need some advice. AFAICT, building a Go program requires the program's Go dependencies to have a particular filesystem layout, which corresponds to the way these dependencies are imported by the

Re: Question about multiple licenses

On Mon, Aug 28, 2017 at 10:55:34PM +0530, Arun Isaac wrote: > > Alex Vong writes: > > > Based on the above general argument, I think we should list all the > > licenses instead of just GPLv2+ since it would be inaccurate to say that > > the whole program is under just GPLv2+. > > Listing all

Re: Question about multiple licenses

Alex Vong writes: > Based on the above general argument, I think we should list all the > licenses instead of just GPLv2+ since it would be inaccurate to say that > the whole program is under just GPLv2+. Listing all the licenses does seem like the safest thing to do. > Also, in this

Re: let's talk about SLIM

On Sun, Aug 27, 2017 at 04:08:42PM -0400, Mark H Weaver wrote: > ng0 writes: > > > It seems to me as if SLIM can be dropped once we > > have something else in place. Would you agree? > > It would be good to keep a display manager service that is lightweight > in terms of

Re: Optionally using more advanced CPU features

Hi Dave, Dave Love skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: [...] >> To some extent, I think this is a compiler/OS/upstream issue. By that I >> mean that the best way to achieve use of extra CPU features is by using >> the “IFUNC” feature of GNU ld.so,

aarch64 substitute server

For the past day and a half I've been having serious problems with my odroid-c2. I think it's had too many power losses, and it seems both the SD card and the external HDD are corrupted. They're not exactly plugged in in the best possible way, both are connected loosely through plug adapters to a

Re: Question about multiple licenses

Arun Isaac writes: > I'm packaging linkchecker. > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27468 > > Different files of linkchecker have different license headers. The > license field of the package is as follows: > > (license (list l:gpl2+ >

New French PO file for 'guix-packages' (version 0.13.0)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'guix-packages' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/guix-packages/fr.po (We can arrange