Re: GNU Guix & GuixSD 0.16.0 released

Yesterday I gave a passionate 'I love Guix' lightning talk about Guix packages at the biohackathon in Japan. Many people after approached me and said that the website is confusing them because it looks like it is promoting a Linux distribution... I know this is an old topic, but it would be nice if

Re: Guix & IPFS

On Sun, Dec 09, 2018 at 09:19:20PM +0100, Pierre Neidhardt wrote: > I found a solution to package IPFS without gx, so go-ipfs has just hit master! That is excellent news. That means we have a way of distributing materials in a robust fashion. Pj.

Re: Long term plan for GuixSD security: microkernels, ocap, RISC-V support

Em 24/09/2018 11:14, Ludovic Courtès escreveu: > Christopher Lemmer Webber skribis: >>- There's also Google's recent work with Magenta/Fuschia. From what >> I've read, architecturally this looks right. I think the reason >> for worry here is the same difficulty the community has ha

Re: bug#33676: GuixSD on eoma68-a20?

Hello Danny, On Sat, Dec 08, 2018 at 06:12:14PM +0100, Danny Milosavljevic wrote: > Guix received one but we have so far be unable to get the GuixSD flash > image because something always breaks on Hydra before it's done although the problem seems to lie somewhere else, I would just like to point

Re: GuixSD on eoma68-a20?

Hi Danny and Ludovic, Danny Milosavljevic writes: > After the change, I get the following on Hydra > : > > --- > @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-

Re: Guix & IPFS

I found a solution to package IPFS without gx, so go-ipfs has just hit master! I'll put the "gx-download" on hold since it's not used for anything else at the moment. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

Re: 01/01: hydra: Increase image sizes for USB image and Flash image.

On Sun, Dec 09, 2018 at 05:16:58PM +0100, Ricardo Wurmus wrote: > > Ludovic Courtès writes: > > > One problem with the installation OS is that it’s pulling ALSA and all > > sorts of sound-related libraries (libsamplerate, etc.), which clearly is > > unnecessary in the installation image. That c

Re: Golang programs keeping references [gnu: go: Update default to 1.11.]

I've investigated the possible solutions to avoid including the paths into the binaries. I've found this: https://github.com/golang/go/issues/16860 It's still unresolved and only planned for Go 1.13. In the meantime, I've played with the -trimpath option to see if I could get something out of i

Re: Preparing the reduced bootstrap tarballs, take 3

Ludovic Courtès writes: Hi! > I’ve just uploaded these to > : > > linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz > linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz.sig > mescc-tools-static-0.5.2-0.bb062b0-i686-linux

Re: 01/01: hydra: Increase image sizes for USB image and Flash image.

Ludovic Courtès writes: > One problem with the installation OS is that it’s pulling ALSA and all > sorts of sound-related libraries (libsamplerate, etc.), which clearly is > unnecessary in the installation image. That comes from the alsa-utils > udev rules. We could remove those udev rules, b

CDN performance

Hello Chris, Chris Marusich skribis: > Regarding DNS, it would be nice if we could use an official GNU > subdomain. If we can't use a GNU subdomain, we should at least make > sure we have some kind of DNS auto-renewal set up so that nobody can > poach our domain names. And the operators should

Re: GuixSD on librem phone?

swedebu...@riseup.net writes: > I would like to know if there is any interest in this? I'd be interested. I bought the librem 5. Hope it turns out well.

Re: Building Bash with Geesh

Hi Jan, Jan Nieuwenhuizen writes: > Timothy Sample writes: > > Hello, > > Attached are two small patches that allow me to run the Gash test suite > with Geesh, like so > > PATH=$PATH:bin SHELL='../geesh/pre-inst-env geesh' ./check.sh > > assuming that both projects live in the same parent direc

Re: Preparing the reduced bootstrap tarballs, take 3

Hello! l...@gnu.org (Ludovic Courtès) skribis: > So, on x86_64-linux, here’s what I got: > > ludo@ribbon ~/src/guix/+core-updates-next$ ./pre-inst-env guix build > bootstrap-tarballs > /gnu/store/n8lrszv7qf0rwqhibm57d8jykj253bw2-bootstrap-tarballs-0 > ludo@ribbon ~/src/guix/+core-updates-next$ (

Re: Installer and luks support.

Hi, > Good point. Perhaps a simple hack would be to detect that /mnt is > already an overlayfs mount and in that case skip the “herd start > cow-store /mnt” step? Would that be enough? Nope sadly, it won't work because keeping the overlayfs prevent from closing the luks mapping which will con

Re: Preparing the reduced bootstrap tarballs, take 3

Hello, Jan Nieuwenhuizen skribis: > Jan Nieuwenhuizen writes: > >>> >>> >>> >>> Could you share yours so we can compare? >> >> Mine is here >> >> >> http://lilypond.org/janneke/mes/x86_64-linux/guile-static

Re: Preparing the reduced bootstrap tarballs, take 3

Hello, Jan Nieuwenhuizen skribis: > Jan Nieuwenhuizen writes: > >>> >>> >>> >>> Could you share yours so we can compare? >> >> Mine is here >> >> >> http://lilypond.org/janneke/mes/x86_64-linux/guile-static

Re: Using a CDN or some other mirror?

Hi Hartmut, Hartmut Goebel skribis: > Am 09.12.2018 um 04:33 schrieb Chris Marusich: >> Instead, we would be using a CDN as a performance optimization that is >> transparent to a Guix user. You seem unsettled by the idea of >> entrusting any part of substitute delivery to a third party, but >>

Re: bootstrapping SED-4.5, circular dependency?

Hi! Jan Nieuwenhuizen skribis: > Ludovic Courtès writes: > > Hello, > >> Jan, could it be that the ‘basename’ and ‘dirname’ implementations in >> Gash fail this test? It might be that sed is not needed if you get >> these right. > > Ah, yes! I have added some test to Gash and this > > base

Re: Installer and luks support.

Hi! Mathieu Othacehe skribis: >> I suppose that if you run “halt” or “reboot”, everything is terminated >> properly, right? I’m not sure if you should worry beyond that; in >> general, it’s reasonable to assume that people will reboot when the >> installation is over, no? > > Yes it is. My conc

Re: 01/01: hydra: Increase image sizes for USB image and Flash image.

guix-comm...@gnu.org skribis: > commit 07c791c1104db3530eb12c918043fc3b30c093be > Author: Danny Milosavljevic > Date: Sun Dec 9 00:49:54 2018 +0100 > > hydra: Increase image sizes for USB image and Flash image. > > * build-aux/hydra/gnu-system.scm (qemu-jobs) : Increase from >

Re: Using a CDN or some other mirror?

Am 09.12.2018 um 04:33 schrieb Chris Marusich: > Instead, we would be using a CDN as a performance optimization that is > transparent to a Guix user. You seem unsettled by the idea of > entrusting any part of substitute delivery to a third party, but > concretely what risks do you foresee? I have

Re: GuixSD on eoma68-a20?

After the change, I get the following on Hydra : --- @ build-started /gnu/store/scnqgfc3k4434h3gch22hnh0z8qdbvdb-disk-image.drv - x86_64-linux /var/log/guix/drvs/sc//nqgfc3k4434h

Re: Installer and luks support.

Mathieu Othacehe ezt írta (időpont: 2018. dec. 9., V, 12:15): > > > Hi Gábor, > > > Can't we offer here the option to retry the failed step? i.e. guix system > > init > > in this case? I mean we have everything set up to simply retry. Does > > that make sense? > > Yes that could be a viable optio

Re: Installer and luks support.

Hi Gábor, > Can't we offer here the option to retry the failed step? i.e. guix system init > in this case? I mean we have everything set up to simply retry. Does > that make sense? Yes that could be a viable option. We could allow the user to launch again the install command, but we cannot allo

Re: Installer and luks support.

Hello Mathieu, Mathieu Othacehe ezt írta (időpont: 2018. dec. 9., V, 2:15): > > > Hey Ludo, > > > I suppose that if you run “halt” or “reboot”, everything is terminated > > properly, right? I’m not sure if you should worry beyond that; in > > general, it’s reasonable to assume that people will r

Re: Using a CDN or some other mirror?

Hi Ludo, Am 07.12.2018 um 15:05 schrieb Ludovic Courtès: > However, Guix is very different from these: on the build farm, we build > several new store items per minute, and we aim to distribute them to our > users. > […] > For Guix I think a caching proxy […] is a better > fit: In this conste