Re: website: say what Guix is at the very top

On 01/21/2018 at 15:47 Ricardo Wurmus writes: > Ludovic Courtès writes: > >> Ricardo Wurmus skribis: >> >>> It seems unfortunate to me that we have one shared website for GuixSD >>> and Guix. As much as I love GuixSD, I think Guix is the main “product” >>> and

Re: [bug#30165] [PATCH] gnu: gnurl: Add '--with-ca-bundle' path to configure-flags.

Regarding https://debbugs.gnu.org/30165 gnurl is failing to build on my system and I think this patch is to blame. Why is gnurl referencing something under the root filesystem rather something provided by an input? Shouldn't we provided ca-certificates.crt from an input and reference that? I

Re: [RFC] A simple draft for channels

On Tue, Jan 23 2018, Pjotr Prins wrote: How is it a security issue? If I can authorise any substitute server key that I want, then I can authorise my own server's key. I can then create a malicious substitute that doesn't correspond to the build recipe in Guix. I could inject whatever code

Re: weird errors; shepherd

The attached file is gnu/services/trytond.scm which successfully runs trytond. Everyone: After I've tried writing some shepherd service I have to say that writing a shepherd "start" action is way too difficult. Even now, I've not gotten to work: * Having the activation depend on any other

Re: [PATCHES] gnu: linux-libre: Full retpoline support on x86 [spectre mitigation]

On Sat, Jan 20, 2018 at 03:34:08PM -0500, Mark H Weaver wrote: > Here are two patches that: > > * Add gcc-7.3.0-RC-20180117, which includes support for retpoline. > * Use gcc-7.3 to build linux-libre on x86 systems. > > I'm currently running linux-libre-4.14.14 with full retpoline support: > >

Re: 05/05: guix: Refactor script.

l...@gnu.org (Ludovic Courtès) writes: > civodul pushed a commit to branch master > in repository guix. > > commit 6f774d481839f87178c5895ac2d661e141f879b8 > Author: Mathieu Lirzin > Date: Tue Jan 23 12:52:33 2018 +0100 > > guix: Refactor script. [...] > diff --git

Re: Porting GuixSD to ARM article.

Hello, On Tue, Jan 23, 2018 at 10:23:50AM +0100, Mathieu Othacehe wrote: > > Notice that the last section of the blog post does not solve the problem: > > As I realised by trial and error when trying to use a disk-image for a > > virtual machine, it really is only an installation-image,

Re: [RFC] A simple draft for channels

Ludovic Courtès writes: > One thing that’s still an open question is how we should treat Guix > itself in that channelized world. > > Should Guix be a “normal” channel? Guix as such should not be a “normal” channel; “(gnu packages *)”, however, could be considered a channel. I

Re: Porting GuixSD to ARM article.

Hi Ricardo, On Tue, 23 Jan 2018 12:51:28 +0100 Ricardo Wurmus wrote: > Can we automate these steps so that we have only a single image but > customized loader scripts per target? Difficult to say. What would run the loader script?

Re: [RFC] A simple draft for channels

myglc2 writes: > On 01/19/2018 at 14:41 Ludovic Courtès writes: > >> Hi! >> >> Ricardo Wurmus skribis: >> >>> As a first implementation of channels I’d just like to have a channel >>> description file that records at least the following things: […] >> One thing

Re: [RFC] A simple draft for channels

On 01/19/2018 at 14:41 Ludovic Courtès writes: > Hi! > > Ricardo Wurmus skribis: > >> As a first implementation of channels I’d just like to have a channel >> description file that records at least the following things: >> >> * the channel name (all lower case, no

Re: Include Proot-static with binary releases

Efraim Flashner skribis: > On Thu, Jan 18, 2018 at 03:21:53PM +0100, Pjotr Prins wrote: >> On Thu, Jan 18, 2018 at 11:44:03AM +0100, Ludovic Courtès wrote: >> > Including proot-static makes a lot of sense and easily done (it adds >> > 3 MiB to the result.) We’d need to

Re: Porting GuixSD to ARM article.

Mathieu Othacehe writes: >> We could ship the generic ARM image, let the user use >> qemu-system-arm to boot it and set up the correct u-boot in >> there, and only then write it to SD card. >> >> There could even be a small part in the wip-installer-2 >> that asks you

Re: Porting GuixSD to ARM article.

> We could ship the generic ARM image, let the user use > qemu-system-arm to boot it and set up the correct u-boot in > there, and only then write it to SD card. > > There could even be a small part in the wip-installer-2 > that asks you which u-boot you want and set that up. > > I'm just trying

Re: Porting GuixSD to ARM article.

Hi Mathieu, On Tue, 23 Jan 2018 10:29:52 +0100 Mathieu Othacehe wrote: > The problem with the approach of no writing u-boot is when you're > preparing a blank SD card and expect to boot from it. Right, that would be a problem sometimes. Most ARM boards I have have

Re: Porting GuixSD to ARM article.

Hi Danny, > I've also tested our new "--system" facility which allows us to build the > ARM image on x86_64 - but I'm sad to say that glibc has a bug which makes > the build fail > . Oh too bad :( > We could add a new argument to the

Re: Porting GuixSD to ARM article.

Hi Andreas, > I am reading it only now (since I wish to install GuixSD on an ARM board > of mine, but better late than never...). Very nice work and write-up! Thank you :) > But I still have a few questions: > - Now that there is a release 0.14, could the images not be made available > on

Re: [RFC] A simple draft for channels

On Tue, Jan 23, 2018 at 07:38:46AM +0100, Ricardo Wurmus wrote: > > Hi Pjotr, > > > On Fri, Jan 19, 2018 at 02:41:42PM +0100, Ludovic Courtès wrote: > >> Authorizing keys is necessarily limited to root since the store is > >> shared among all users of the machine. I don’t see any way around