Re: GNU Guix gets a mention in paper

2017-11-20 Thread Ludovic Courtès
Pjotr Prins skribis: > Robust Cross-Platform Workflows: How Technical and Scientific > Communities Collaborate to Develop, Test and Share Best Practices for > Data Analysis > > https://link.springer.com/article/10.1007/s41019-017-0050-4 > > Guix is right up there with Debian, Conda and Brew. Nic

Re: [bootstrappable] prototyping the full source bootstrap path

2017-11-20 Thread Ludovic Courtès
Heya Jan, Jan Nieuwenhuizen skribis: > Now that MesCC starts to build TinyCC that starts to pass a large set of > the mescc C tests, it's time to get walking the bootstrap path. Woohoo! > Attached*) is my initial attempt for the full source bootstrap path in > GuixSD; to try it, do > > ./p

Re: 05/06: gnu: wget: Add wget2.

2017-11-20 Thread Ludovic Courtès
Hi Rutger & Mark, Rutger Helling skribis: > From 23fd827972f26c627f4da3a90d49cd2d398e1297 Mon Sep 17 00:00:00 2001 > From: Rutger Helling > Date: Fri, 17 Nov 2017 20:35:00 +0100 > Subject: [PATCH] gnu: wget2: Switch to official URL. > > * gnu/packages/wget.scm (wget2): Switch to official URL.

RE: [bootstrappable] prototyping the full source bootstrap path

2017-11-20 Thread Orians, Jeremiah (DTMB)
> Now that MesCC starts to build TinyCC that starts to pass a large set of the > mescc C tests, it's time to get walking the bootstrap path. > Attached*) is my initial attempt for the full source bootstrap path in > GuixSD; to try it, do Very nicely done Janneke >The starting point is Jeremiah

Re: gcc-ddc

2017-11-20 Thread Jan Nieuwenhuizen
Gábor Boskovits writes: Hey Gábor! [cc: guix-devel] > I'm definietly making progress on this. Now I have a working debug build of > gcc. > Identified the critical symbols, they are: > static const char *const standard_exec_prefix = STANDARD_EXEC_PREFIX; > static const char *const standard_libe

Re: [bootstrappable] Re: prototyping the full source bootstrap path

2017-11-20 Thread Jan Nieuwenhuizen
Ricardo Wurmus writes: > Ludovic Courtès writes: > >> So the next steps in the dependency graph are: >> >> mes-boot -> mescc -> tinycc -> gcc@4.7 -> gcc >> >> Do I get this right? That has been my idea for a long time, yes...but it may not be feasible, wise or most fun. It may not be feasible

Re: [bootstrappable] Re: prototyping the full source bootstrap path

2017-11-20 Thread Jan Nieuwenhuizen
Ludovic Courtès writes: Hey Ludo' > Also, AIUI, stage0 is i386-specific. Thoughts on how we can eventually > support the other architectures Guix works on? I goofed ere. Stage0 is mainly using a VM and it has a x86_64 prototype; no x86 yet. Of course, creating the x86 hex0 is almost trivial g

RE: [bootstrappable] Re: prototyping the full source bootstrap path

2017-11-20 Thread Orians, Jeremiah (DTMB)
> Yeah, the mean reason to do it in Guix packages is that it becomes impossible > to cheat. However, coding the bootstrap path in Guix > means that we depend on some form of Guile...hmm. Easy to break, simply allow each piece to be able to be built using only a trivial shell script

Re: [bootstrappable] Re: prototyping the full source bootstrap path

2017-11-20 Thread Gábor Boskovits
We had a discussion about that on the irc channel, and it seems, that we can make a boostrap path to another architecture by using a bootstrapped toolchain and cross compiling. It is not very confortable, but I think we can extend the list of bootstrappable software considerably by that. 2017-11-2

Re: [bootstrappable] Re: prototyping the full source bootstrap path

2017-11-20 Thread Ludovic Courtès
Jan Nieuwenhuizen skribis: > Ricardo Wurmus writes: > >> Ludovic Courtès writes: >> >>> So the next steps in the dependency graph are: >>> >>> mes-boot -> mescc -> tinycc -> gcc@4.7 -> gcc >>> >>> Do I get this right? > > That has been my idea for a long time, yes...but it may not be feasible,

Re: Release!

2017-11-20 Thread Ludovic Courtès
Hello Guix, I think we can start preparing the release for good now! The situation of ‘guix pull’ is mitigated by the split of python.scm and other big files into several pieces. This is of course not ideal, but it’s an improvement over 0.13.0 anyway. I think the main tasks to prepare the relea

Re: gcc-ddc

2017-11-20 Thread Gábor Boskovits
The only problematic one seems to be standard_libexec_prefix, because that is used in line 3654 of gcc/gcc.c in a real assignment. It is also used in line 64 of gcc/gcc-ar.c. Other uses of all these other symbols could be calculated as compile time realitve paths, and if we can live with these pa

Re: [PATCH 1/1] gnu: Add ccid.

2017-11-20 Thread Marius Bakke
Mike Gerwitz writes: > Hey, Marius: > > I'm resurrecting this thread. :) Hello Mike, long time no see! :-) > On Mon, Oct 31, 2016 at 10:09:14 +, Marius Bakke wrote: >> Mike Gerwitz writes: >>> On Fri, Oct 28, 2016 at 12:27:29 +0100, Marius Bakke wrote: Packages are not allowed to writ

Re: [PATCH 1/1] gnu: Add ccid.

2017-11-20 Thread Mike Gerwitz
On Tue, Nov 21, 2017 at 02:05:26 +0100, Marius Bakke wrote: > I'd start by copying an existing (simple) service as "boilerplate", and > then write a "system test" that simply (attempts to) start the daemon. > You'll find these under "gnu/tests" and "gnu/services". Thanks for the advice. I'll give